On 5/21/2014 1:16 AM, foreverska wrote: > Code never seems to work out of the box for me on these things. Now that I > have operational code looking at R31 I have issues putting the results int > datamemory which is just absurd. Here's the code: > > #define CONST_PRUDRAM C3 > #define TOOTH_COUNTER R5 > > lpe: > ADD TOOTH_COUNTER, TOOTH_COUNTER, 1 > QBEQ lpe, r31, 0 > > SBCO TOOTH_COUNTER, CONST_PRUDRAM, 0, 4 > > I have also done this with SBBO pointed to 0x0 with no success. In > prudebugger R5 has a non zero value but the memory comes up as 0x0 in the > debugger. The C program I have agrees with the bugger's reported values on > that value and surrounding values. Is there a setup for the pru to access > DM? That feels absurd. It is it's own local ram.
I suspect you are writing to the wrong address. Note that C3 which you use above points to the local eCAP timer, I have no idea why you think it should be writing to memory. > As an aside, a C program should be able to look down in dram and see > registers at the 0x7000 offset right? It looks empty to the bugger and my > C program. Or are those different registers than the R0-R31? Read the PRU Reference Guide. The documentation for these registers indicates they are valid while the PRU is disabled. See the RUNSTATE and ENABLE bits in the CONTROL register (section 5.4.1 of the PRU Reference Guide). -- 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]. For more options, visit https://groups.google.com/d/optout.
