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
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.
Hi Neil,
The "r2 = 20" 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(20)
ldi, r2.w0 %hi_rlz(20)
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(
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.
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
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
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
Hi, check my comments inline.
On Sunday, November 27, 2016 at 10:15:00 PM UTC+2, Neil Jubinville wrote:
>
> Thx Charles, that was it. I was treating the registers as application of
> dataram memory.
>
> In the assembly loop: I did a : * sbbo r0, r0, 0 , 48*
>
> and like magic my c pru
Thx Charles, that was it. I was treating the registers as application of
dataram memory.
In the assembly loop: I did a : * sbbo r0, r0, 0 , 48*
and like magic my c pru memap dumped out values I have stuffed in some of
the registers.
see below
-
On 11/26/2016 1:33 PM, Neil Jubinville wrote:
>
> Here is my basic understanding - Focusing on PRU0:
>
> Each PRU has 8K of 'dataram' - This is where I expect R1,R2,R3 R31 to
> be
> stored. *Is this true? I see many people changing the reference at
> *0x_0n00,
> n =
*Hi All, *
My next goal is to have a have a C program on the *Main processor read and
write values into -> PRU Memory*. There are plenty of examples about this
however they are not returning my register values. Indeed I am able to
read/write somewhere and persist value into PRU memory.
12 matches
Mail list logo
