Yes, thank-you, I already know the prompt cycle needs to run twice to pick up the write in the subsequent read cycle, no big deal there, I just enter the same vale twice and I get the feedback.
The part I am focused on is why the value from the LBBO does not seem to be used in the delay call. You may have missed my last post where the LBBO worked using the 8 bytes of offset, R2 is the third 32 bit number in my reference R0 is the first , R1 the second, *R2 the third* lbbo r2, r0, 8 ,4 works like a champ. After the lbbo I transfer the value I entered into R6 in the PRU and it comes back to me in the sbbo so I know it is working and getting to the general registers. The question now is why R2 used as a delay value does not change the delay time when it is truly reaching the PRU. Any comments on the initialization of R2 = 200,000,000 ? does that syntax lock it into a constant? On Sunday, November 27, 2016 at 7:12:38 PM UTC-7, Charles Steinkuehler wrote: > > On 11/27/2016 6:35 PM, Neil Jubinville wrote: > > > > Description of the program: > > > > An LED toggles on and off from a set delay time in R2. > > > > A separate C program loads the PRU program, starts the core and then > prompts the > > user for a Time to do a delay. Upon the user entering a time, the c > program > > writes that value to dataram and reads back the mapped memory from the > PRU to show. > > > > The PRU loop does a SBBO each time as well as a LBBO for a single R2 . > My LBBO > > call however is not returning the proper value, I am likely using the > wrong > > pointer value. > > > > Here is where I believe the problem is, how I interpret what register > address to > > start at by setting an arbitrary r9 to the start. > > > > *ldi r9, 9 // offset to the start of the third 32 bit value > * > > *lbbo r2, r9, 0 ,4 // read 4 bytes from there and store it into r2* > > First, 9 is not the proper offset for the third 32-bit value (that > would be 12, or 3 values * 4 bytes/value). > > Second, you are reading *AND* writing the memory location you are > trying to monitor in your PRU code. That means a new value will > *ONLY* be picked up if the ARM side updates the value in between the > write and the read. You should structure your code so that for any > given memory location, only one side (ARM or PRU) writes the values. > > -- > 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/a69279fd-5581-42e3-b5ad-67fb14d7d646%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
