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] > <javascript:>> 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] <javascript:>. >> 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.
