ETPU - Shifting CBPA and CBPAE

取消
显示结果 
显示  仅  | 搜索替代 
您的意思是: 
已解决

ETPU - Shifting CBPA and CBPAE

跳至解决方案
494 次查看
mertk
Contributor IV

Hello @davidtosenovjan and @johndiener,

I am working on AN4907 application on a development board.The memory processes with CBPAE is confusing my mind. 

Here the code block is: 

mertk_0-1672044893820.png

And here the resulting values of CBPA ve CBPAE:

mertk_1-1672044941544.png

How CBPAE gets 0xC3FCC3E0? I think it must gets 0xC3FC93E0 because of the result of the arithmetic process of 0x4000 >> 2 is 0x1000.

Same thing is occuring while writing to channel parameters. 0x249F0 value is written into ptr_untCPBAE + 0x14 not ptr_untCPBAE + 0x5. 

Is it normal?

Best regards,

Mert.

0 项奖励
1 解答
480 次查看
johndiener
Contributor IV

Hello Mert,

It isn't shown in your code snippet, but I assume the type of 'ptr_untCPBAE' is 'int32_t*' (or 'uint32_t*') - this means when 0x1000 element steps are added to it, this transforms to a byte address offset of 0x4000 (sizeof int32_t is 4 bytes).

The last line of code displays similar behavior with converting a byte offset to a word offset by shifting right by 2 bits. It also uses an eTPU 24-bit address offset of 0x15 and converts it to a host-side byte address offset by subtracting 1 - this is typical of host code interacting with 24-bit data in the eTPU memory.  Note that it would probably be better if the constant 0x15 was represented by an address offset macro generated out of the eTPU tools.

John Diener

在原帖中查看解决方案

2 回复数
476 次查看
mertk
Contributor IV

Hello John, 

Yes, your assume is correct. Data type of ptr_untCPBAE is uint32_t*. Now, I understand what I missing when I see your answer. This is pointer arithmetic.

Thank you for your helps.  

Best regards,

Mert.

0 项奖励
481 次查看
johndiener
Contributor IV

Hello Mert,

It isn't shown in your code snippet, but I assume the type of 'ptr_untCPBAE' is 'int32_t*' (or 'uint32_t*') - this means when 0x1000 element steps are added to it, this transforms to a byte address offset of 0x4000 (sizeof int32_t is 4 bytes).

The last line of code displays similar behavior with converting a byte offset to a word offset by shifting right by 2 bits. It also uses an eTPU 24-bit address offset of 0x15 and converts it to a host-side byte address offset by subtracting 1 - this is typical of host code interacting with 24-bit data in the eTPU memory.  Note that it would probably be better if the constant 0x15 was represented by an address offset macro generated out of the eTPU tools.

John Diener