Re: [beagleboard] Is it a bug? control flow instruction of PRU does not make right comparison with negative number

[zlw8844]

Thank you Charles. Is it a known issue only for control flow logic? When I 
use MOV command to save a negative number (MOV r1, -1), then save r1 into 
shared RAM, then into a txt file, I do see -1 is saved into the txt file 
correctly.

On Tuesday, October 31, 2017 at 9:13:31 AM UTC-4, Charles Steinkuehler 
wrote:
>
> On 10/30/2017 4:53 PM, zlw...@gmail.com  wrote: 
> > I am trying to use QBLT to compare two numbers and found out when one 
> > number is negative, the QBLT logic does not seem make right comparison. 
> In 
> > the following code, before QBLT, r3 =1-4 = -3, and r2 = 10, so r3 < r2, 
> > then the code should execute MOV r3, -1. However, when I run this macro, 
> r3 
> > is set to 1. 
> > Anyone notices this issue? Any idea how to fix it? 
>
> This is a known issue, the PRU supports *ONLY* unsigned integers. 
>
> Write your code properly for unsigned data types and you will not have 
> any problems. 
>
> -- 
> Charles Steinkuehler 
> cha...@steinkuehler.net  
>

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/859b4ea7-a3a6-430d-a715-b5d24ccc6a09%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Is it a bug? control flow instruction of PRU does not make right comparison with negative number

[zlw8844]

I am trying to use QBLT to compare two numbers and found out when one 
number is negative, the QBLT logic does not seem make right comparison. In 
the following code, before QBLT, r3 =1-4 = -3, and r2 = 10, so r3 < r2, 
then the code should execute MOV r3, -1. However, when I run this macro, r3 
is set to 1.
Anyone notices this issue? Any idea how to fix it?

.macro LOGTEST
MOV r7, 1
MOV r8, 4
SUB r3, r7, r8
MOV r2, 10
QBLT LESS, r2, r3
MOV r3, 10
JMP XXX
LESS:
  MOV r3, -1
XXX:
.endm

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/9d82bb20-36c1-4447-855b-8edb58cf47fe%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.

[beagleboard] Re: ADC reading by PRU

[zlw8844]

I agree, and I found the same data repeat problem using the continuous 
code, it does not look like a data loss. I do a 3.6 kHz sampling rate and 
observed that every 7 samples, I can see the value of two adjacent samples 
are very close to each other (see the figure below). Anyway, would you mind 
sharing your code with us to solve the problem? Thanks very much in advance.





On Tuesday, May 26, 2015 at 9:39:38 AM UTC-4, marcelo...@gmail.com wrote:
>
> I was wrong about the number 1, actually after some experiments I noticed 
> that I'm still losing samples, even after setting the ACK_CLKDIV to 
> something that divides the 24MHz by 3. Anyway it is useful to know that you 
> can obtain higher sample rates by setting a lower value to that register. 
>
> I'd also like to add that the continuous mode that you set on the step 
> config seems not good. I noticed it after sampling higher frequency waves, 
> however even on low frequency ones there's a noticeable step on the 
> sampling: every 14-15 samples had approximately the same value... I solved 
> that by setting STEPCONFIG it to the default one-shot mode and then the PRU 
> request a sample when it thinks it's time to. To request a sample, re-set 
> the bit on the STEPENABLE register. 
>
> My last step is to discover how to solve the lost samples problem... 
> When I'm sampling at 300kSps I noticed I lose 358 samples every 5005 
> samples. At 30kSps the proportion was 5 to 500.

-- 
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 beagleboard+unsubscr...@googlegroups.com.
To view this discussion on the web visit 
https://groups.google.com/d/msgid/beagleboard/75de1e0b-a477-46dc-b47f-addba90f3f5e%40googlegroups.com.
For more options, visit https://groups.google.com/d/optout.