Interesting idea, if only pwm. I did not write it before, but pru1 will also read five incremental encoders and report the positions back to the arm side. So I have some free time on pru1 to manage pru0 and arm communication, but can't dedicate it exclusively for that. Also, there are two digital outputs and two digital inputs (on off).
Le jeudi 6 août 2015 18:04:11 UTC-3, Carlos Novaes a écrit : > > The Prus are pretty powerfull for driving the io pins and their > deterministic nature are very useful. But it was a little hard for me to > learn each topic. Gpio access, interrupts, memory mapping and the > scratchpad. > In the process of learning, I have written a small library, I called it > libpru. It is composed of pru assembly include file and c++ counterpart for > the arm processor. Maybe it can be useful to other people, I do not know > git very well but maybe I will uploaded it somewhere. > > > Le mardi 4 août 2015 18:30:12 UTC-3, William Hermans a écrit : >> >> Hello Carlos, >> >> Thanks for sharing. Personally I'm always interested in what others are >> doing, and like to see "progress reports". Not that anyone has to report >> anything to me personally, but I still like reading about what others are >> doing. >> >> I expect some day in the future I will be investing some time getting to >> know the PRU's as well. But as a hobby, I have the luxury of doing so, when >> I get around to it ;) Anyway, I've always found the PRUs interesting . . >> .maybe that will be my next "pet" project ? >> >> On Tue, Aug 4, 2015 at 12:03 PM, Carlos Novaes <[email protected]> wrote: >> >>> Hello everyone. This is just an update. >>> >>> I tried the direct connection mode but it is more suitable for syncing >>> the two PRUs. Anyway, my previous approach will work. As Lenny said: >>> In case that one PRU reads from the scratchpad and in the same cycle the >>> other PRU writes to it, I am pretty sure that there will be no conflicts. >>> It is the standard behaviour when you program sequential logic with a >>> hardware description language. However, the read operation will yield the >>> "old" data from the scratchpad, that is the ones from before the write >>> operation. >>> >>> That's exactly what happens. no extra delays or any type of conflict. >>> >>> Thank you Lenny, and everyone else. >>> >>> Carlos Novaes >>> >>> >>> PS: If it is of interest to someone here comes my test experiment: >>> I had PRU0 and PRU1 with cycle register enabled and counting clock >>> cycles. Over each iteration on a total of twenty, the cycle register was >>> read and stored into one register from r0 to r19. This on both PRUs >>> On PRU0 I also read r23 from scratch pad and the store its lower word >>> (r23.w0) into the upper word (rx.w2) of one of r0 to r19. Total cycle >>> counting is 6 for each iteration. >>> On PRU1 I store the lower word of r23 into the upper word of one of r0 >>> to r19 (according to the iteration) and also increment r23 and store it on >>> the scratchpad. Total cycle counting is 7 for each iteration. >>> Then, on both PRUs, write r0 to r19 into the shared ram and signal the >>> ARM. >>> On the ARM side, wait for signals from PRU0 and PRU1, read the shared >>> ram (data from both PRUs), calculate the cycle offset of each iteration and >>> print the results. There are no stall on any PRU, all iteractions takes >>> exactly 6 cycles on PRU0 and 7 cycles on PRU1. At each 7 iteractions, PRU0 >>> will repeat the previous value of r23. >>> Here comes the output from console: >>> >>> ::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::: >>> PRU0 :::::: >>> PRU1 : >>> Value : Cycle : Cycle Offset :::::: Value >>> : Cycle : Cycle Offset : >>> 1 : 58960: ------------------ :::::: 1 >>> : 16: ------------------ : >>> 2 : 58966: 6:::::: 2 >>> : 23: 7: >>> 3 : 58972: 6:::::: 3 >>> : 30: 7: >>> 4 : 58978: 6:::::: 4 >>> : 37: 7: >>> 5 : 58984: 6:::::: 5 >>> : 44: 7: >>> 6 : 58990: 6:::::: 6 >>> : 51: 7: >>> 7 : 58996: 6:::::: 7 >>> : 58: 7: >>> 7 : 59002: 6:::::: 8 >>> : 65: 7: >>> 8 : 59008: 6:::::: 9 >>> : 72: 7: >>> 9 : 59014: 6:::::: 10 >>> : 79: 7: >>> 10 : 59020: 6:::::: 11 >>> : 86: 7: >>> 11 : 59026: 6:::::: 12 >>> : 93: 7: >>> 12 : 59032: 6:::::: 13 >>> : 100: 7: >>> 13 : 59038: 6:::::: 14 >>> : 107: 7: >>> 13 : 59044: 6:::::: 15 >>> : 114: 7: >>> 14 : 59050: 6:::::: 16 >>> : 121: 7: >>> 15 : 59056: 6:::::: 17 >>> : 128: 7: >>> 16 : 59062: 6:::::: 18 >>> : 135: 7: >>> 17 : 59068: 6:::::: 19 >>> : 142: 7: >>> 18 : 59074: 6:::::: 20 >>> : 149: 7 >>> >>> >>> >>> Le dimanche 2 août 2015 21:21:10 UTC-3, Carlos Novaes a écrit : >>> >>>> Hi Lenny. Sorry for the delay. >>>> Usually, PRU1 will have new data received from the ARM before PRU0 >>>> complete one PWM sample, this is the key point. If the ARM sporadically >>>> could not deliver a control action in time, the PWM should just repeat the >>>> last values, so reading the old data is desirable. >>>> I really did not think in use direct PRU transfer and I don´t know why. >>>> Maybe because at my first readings this seemed unsafe. I will give it a >>>> try, thank you for the idea. >>>> >>>> >>>> >>>> >>>> Le dimanche 2 août 2015 12:04:04 UTC-3, Lenny a écrit : >>>>> >>>>> Oh sorry, I didn't see your PS ;) >>>>> >>>>> In case that one PRU reads from the scratchpad and in the same cycle >>>>> the other PRU writes to it, I am pretty sure that there will be no >>>>> conflicts. It is the standard behaviour when you program sequential logic >>>>> with a hardware description language. However, the read operation will >>>>> yield the "old" data from the scratchpad, that is the ones from before >>>>> the >>>>> write operation. >>>>> >>>>> But as you have lots of time to waste on one PRU, it might be a better >>>>> idea to use direct PRU transfer (XIN/XOUT with device 14), without the >>>>> scratchpad in between. Lets say your PRU0 (the time-critical one) >>>>> executes >>>>> N instructions per loop. Then just let PRU1 make an update of the >>>>> important >>>>> registers every M cycles (with M<N) so that data for PRU0 will always be >>>>> fresh and PRU0 will never have to wait for PRU1. The advantage is that >>>>> your >>>>> PWM will run perfectly deterministic, that is there will never be any >>>>> irregularities in the output signal due to the interrupt. The data will >>>>> be >>>>> updated every PWM cycle, and all this only costs you one instruction per >>>>> PWM loop cycle. >>>>> >>>>> >>>>> >>>>> On Sunday, August 2, 2015 at 4:39:21 PM UTC+2, Lenny wrote: >>>>>> >>>>>> Hi Carlos, >>>>>> >>>>>> have you looked at the PruReferenceGuide section 5.2.4.2 (p.34-35)? >>>>>> Let me copy paste here: >>>>>> >>>>>> >>>>>> A collision occurs when two XOUT commands simultaneously access the >>>>>> same asset or device ID. >>>>>> Table 20 shows the priority assigned to each operation when a >>>>>> collision occurs. In direct connect mode >>>>>> (device ID 14), any PRU transaction will be terminated if the stall >>>>>> is greater than 1024 cycles. This will >>>>>> generate the event pr<1/0>_xfr_timeout that is connected to INTC. >>>>>> >>>>>> Table 20. Scratch Pad XFR Collision Conditions >>>>>> >>>>>> Operation Collision Handling >>>>>> PRU<n> XOUT (→) bank[j] >>>>>> If both PRU cores access the same bank simultaneously, PRU0 >>>>>> is given priority. PRU1 will temporarily stall until the PRU0 >>>>>> operation completes. >>>>>> >>>>>> PRU<n> XOUT (→) PRU<m> If PRU<n> >>>>>> executes XOUT before PRU<m> executes XIN, then >>>>>> PRU<n> will stall until either PRU<m> executes XIN or the stall >>>>>> is greater than 1024 cycles. >>>>>> >>>>>> PRU<n> XIN (←) PRU<m> If PRU<n> executes XIN before PRU<m> executes >>>>>> XOUT, then >>>>>> PRU<n> will stall until either PRU<m> executes XIN or the stall >>>>>> is greater than 1024 cycles. >>>>>> >>>>>> >>>>>> I used the direct XOUT / XIN with device ID=14 to synchronize the two >>>>>> PRU's. There were no unexpected problems, everything like described in >>>>>> the >>>>>> manual. >>>>>> >>>>>> Let me know if this wasnt your problem. Bests, Lenny >>>>>> >>>>>> >>>>>> -- >>> 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. >>> >> >> -- 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.
