Thx, correct on many accounts. I found it strange that there was no default way load in a 32 bit value given it is the default register size.
Love the macro! I am going to adopt it :) I'll likely now dig into the next level up which implementing the same in pru-gcc / c code vs assembly. Going even higher level , do you know if there are core bindings to the pruMemMap in python? I know PRU Speak works a bit but not sure if it does the memory mapping parts. Neil On Monday, November 28, 2016 at 10:25:57 AM UTC-7, [email protected] wrote: > > Hi Neil, > > The "r2 = 200000" syntax does *not* load a value in a register. It is > for setting symbols - see > https://sourceware.org/binutils/docs/as/Setting-Symbols.html#Setting-Symbols > . You probably meant to load r2 with a constant integer: > ldi r2, %lo(200000) > ldi, r2.w0 %hi_rlz(200000) > > > > The %lo(X) returns the lower 16 bits of a 32-bit constant integer. The > "%hi_rlz(X) returns the higher 16-bits of a 32-bit integer, and marks the > instruction for possible elimination if those higher bits are all zero. You > may want to declare and use the following helper macro: > .macro ldi32 rx, expr > ldi \rx, %lo(\expr) > ldi \rx\().w2, %hi_rlz(\expr) > .endm > > ; Use like this: > ldi32 r2, 200000 > > > Please note that "sp" (Stack Pointer) is an alias for "r2", and "ra" > (Return Address) is an alias for "r3". Hence R3 is used whenever you use > the "call" instruction to store the return PC address. > > I also don't think that "lbbo r2, r2, 0 4" is correct. You are overwriting > the R2 address with a value, which value you are using as an address in the > next iteration. Equivalent C code: > uint32_t *r2; > r2 = (uint32_t)(*r2); > > > Also, $lo(r6/4) is probably not what you meant. %lo expects a constant > integer as an argument. If you want to copy a register, simply use mov: > mov r2,r6 > > Regards, > Dimitar > > > On Monday, November 28, 2016 at 7:39:38 AM UTC+2, Neil Jubinville wrote: >> >> Ok I got it working, the part I changed is commented out. >> >> Essentially I used my r6 debug register that had the correct one in it. >> Now I can dial in the blinky action! fun! >> >> So for some reason even though we were setting the r2 form the lbbo it >> just did not like this syntax. >> >> *ldi r14, %lo( r6/4 )* >> * ldi r14.w2, %hi_rlz(r6/4)* >> >> *Seemed to always load the old initial value. I have to search for the >> %lo and %hi_rlz meaning I know it is used to load a high and low set of >> bytes due to limitations of ldi to a max of 65535 but it was probably >> messing things up.* >> >> >> >> lbbo r2, r0, 8 ,4 >> mov r6, r2 // to prove in the c program that data arrived and >> is correct when displayed R2 should equal R6- debug >> >> >> sbbo r0, r0, 0 , 48 // copy all 12 registers to memory >> R0...R11 . >> >> >> // the goal is for R2 to get set in a C program outside theis >> assembly. Thus changing the speed of the >> // blinking LED - defualt is set to 1 second = 200,000,000 >> cycles in CPU delay. >> >> >> // led on >> mov r30, r1 >> mov r14,r6 >> call delay_n2_cycles >> >> >> // led off >> mov r30, r0 >> mov r14, r6 >> call delay_n2_cycles >> >> >> /* >> // led on >> mov r30, r1 >> ldi r14, %lo( r6/4 ) >> ldi r14.w2, %hi_rlz(r6/4) >> call delay_n2_cycles >> >> >> // led off >> mov r30, r0 >> ldi r14, %lo(r6/4) >> ldi r14.w2, %hi_rlz(r6/4 ) >> call delay_n2_cycles >> */ >> >> >> >> >> >> >> On Sunday, November 27, 2016 at 10:09:55 PM UTC-7, Neil Jubinville wrote: >>> >>> 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 >>>> [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/ef00c6f8-c846-41a5-9e84-16903ce01d8e%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
