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/a05ea410-6232-41d3-b0f1-f8c1bca2147d%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.
