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? --------- 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* 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? <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 > cha...@steinkuehler.net <javascript:> > -- 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 beagleboard+unsubscr...@googlegroups.com. To view this discussion on the web visit https://groups.google.com/d/msgid/beagleboard/e23a71fb-8ebf-4fc2-8259-b1a95ec707fb%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
