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/68862907-815c-47a2-88a2-f1632766a8a1%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
