Unfortunately I have not dealt with python for Pru. On Tuesday, November 29, 2016 at 1:18:50 AM UTC+2, Neil Jubinville wrote: > 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/9075dbd1-1786-4230-bcfe-3b168917a03c%40googlegroups.com. For more options, visit https://groups.google.com/d/optout.
