Ah, you didn't mention you were synchronizing the PRUs in your first mail!
Note that use of the MAC is not that obvious, and there is (was?) little
documentation.
Some issues I found had to do with the overflow/carry flag. It seems to
lag one cycle and it cannot be cleared without clearing the entire
accumulator.
Now this information is more than a year old (11/2012), so maybe the
silicon and/or documentation have been fixed in the meantime, but be
prepared for some surprises!
-- Bas
On 17-4-2014 1:59, Lenny wrote:
Thanks for the help Bas!
I guess i found the problem:
In my code, I used PRU0 simply as a timer with the code
LOOP:
WAIT(250 cycles)
XOUT 14,r5,4 //transfer register r5 from PRU0 to PRU1
JMP LOOP
In the meantime, PRU1 did some tasks, including multiplication using
XOUT/XIN 0,r25,1 and similar instructions, and finally should have
stalled at the instruction
XIN 14,r5,4
in order to synchronize with PRU0.
However, if the timing is initially not right, it can happen that PRU0
waits for the other PRU while blocking the XCHG port with its XOUT
14,... command. If now PRU1 wants to retrieve the result of a
multiplication, e.g. execute XIN 0,r26,4, then it will wait until the
XCHG port is liberated by PRU0, which itself will wait for maximally
1024 cycles if PRU1 accepts its XOUT request while keeping the port
blocked, such that PRU1 can never get to that section in the code in
time. In this case the two PRU's block each other and the programs
runs about 1000 times slower!
Also, the controls which are run to ensure a proper transfer through
the XCHG port are quite basic: It seems to me that for a successful
transfer between two PRUs, one only needs one PRU that is willing to
write (launching XOUT 14,... ) and the other willing to read (XIN
14,...). The actual registers which are to be read or written, or the
amount of data does not have to match between the two commands. If
they dont match, I dont know what data is actually written, but at
least none of the PRUs stalls for 1024 cycles.
--
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]
<mailto:[email protected]>.
For more options, visit https://groups.google.com/d/optout.
--
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].
For more options, visit https://groups.google.com/d/optout.
