Hi, check my comments inline.
On Sunday, November 27, 2016 at 10:15:00 PM UTC+2, Neil Jubinville wrote:
>
> Thx Charles, that was it. I was treating the registers as application of
> dataram memory.
>
> In the assembly loop: I did a : * sbbo r0, r0, 0 , 48*
>
> and like magic my c pru memap dumped out values I have stuffed in some of
> the registers.
>
> see below
>
> -------------------------------------
> value R0 = 0
> value R1 = 65535
> value R2 = 8192
> value R3 = 16
> value R4 = 777
> value R5 = 25
> value R6 = -136853601
> value R7 = 2146680819
> value R8 = 1
> value R9 = -45491713
> value R10 = -89
> value R11 = -1345356802
>
> ------------------------------------
>
> I do have a more basic question though about the value in R2 = 8192. My
> understanding is the general purpose registers are 32 bit.
>
> In my assembly I set
>
> *r2 = 0x0BEBC200 // *decimal 200,000,000 to reflect the core
> frequency.
>
> however as you can see the R2 after the mem copy to dataram shows 8192.
> Why is it not reading 200,000,000 in R2 after the transfer?
>
Could you share your full source code?
>
> ---------
>
> Also, another question. Syntax wise the first *r0 *in the statement
> below 'should' have &r0 but I get unknown register error when compiling.
> If I leave out the & it works and the transfer does occur. Is this a
> nuance of the gcc-pru compiler vs a direct pasm compile?
>
> *sbbo r0, r0, 0 , 48*
>
Yes, the & is not needed for pru-gcc. But for the sake of compatibility
I'll make it optional with the next release.
>
>
> Yet another question: the second argument of *r0* reflects the starting
> address point in dataram. I would have expected dataram as a free for all
> address space that I managed. Is the reference of an Rn type syntax
> simply a convenience for addressing in dataram and dataram has the notion
> of its own register mapping?
>
Dataram has no register mapping. It is simply memory. Consider the
following example:
ldi r1, 101
ldi r2, 64
sbbo r1, r2, 0, 4
Converted to C syntax, it would look like:
unsigned int r1 = 101;
unsigned int *r2 = (void *)64;
r2[0] = r1;
>
>
> <https://lh3.googleusercontent.com/-PR6M_jNKhu4/WDs-tnOriEI/AAAAAAAAASU/VTpqCAMst9wgqHo1G8r1mmuserz0ZOprwCLcB/s1600/Screen%2BShot%2B2016-11-27%2Bat%2B1.13.55%2BPM.png>
>
>
>
> *Thx! *
>
>
>
>
>
>
> On Saturday, November 26, 2016 at 12:43:37 PM UTC-7, Charles Steinkuehler
> wrote:
>>
>> On 11/26/2016 1:33 PM, Neil Jubinville wrote:
>> >
>> > Here is my basic understanding - Focusing on PRU0:
>> >
>> > Each PRU has 8K of 'dataram' - This is where I expect R1,R2,R3 ----
>> R31 to be
>> > stored. *Is this true? I see many people changing the reference at
>> *0x0000_0n00,
>> > n = c24_blk_index[3:0], do I need to set where the Rn's lay down in
>> memory?
>>
>> NO
>>
>> The data ram is what it says...data ram. The registers are what they
>> say...registers. Registers are *NOT* data ram. If you want the
>> register values to appear in memory, you have to write them out using
>> the SBBO instruction.
>>
>> > Docs also state that the PRU 0 Data ram starts at *0x4a300000*;
>> >
>> > int registerStart;
>> > registerStart = *(int*)0x4a300000;
>> > printf("--> R0 = %d" + registerStart);
>> >
>> > However I get a seg fault trying to print what is in R0 that way. That
>> was more
>> > to just do a direct look see if possible and go around all the
>> interfaces.
>>
>> 0x4a300000 is a physical address. You can use that if you are
>> directly accessing memory (via /dev/mem, bus-mastering DMA, or
>> something that doesn't use an MMU like the PRU core). If you try to
>> access a physical address from a standard application that has not
>> been mapped into your process memory space, the MMU will forbid access
>> and your program seg-faults.
>>
>> To access the PRU memory in your application, use the address provided
>> to you by the prussdrv_map_prumem function.
>>
>> --
>> Charles Steinkuehler
>> [email protected]
>>
>
--
For more options, visit http://beagleboard.org/discuss
---
You received this message because you are subscribed to the Google Groups
"BeagleBoard" group.
To unsubscribe from this group and stop receiving emails from it, send an email
to [email protected].
To view this discussion on the web visit
https://groups.google.com/d/msgid/beagleboard/c2030086-f837-4957-ad35-d9d87cc54da4%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
