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 >> cha...@steinkuehler.net >> > -- 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/c2030086-f837-4957-ad35-d9d87cc54da4%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.