> > *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.* >
I do not know git very well either. It's something I've been putting off for a while( learning about ), but eventually I think all software developers need to learn, and use git. It's been keeping me from sharing my current code for the project I'm working on, but it's currently a mess anyway heh ! I have not even updated my blog in a couple years . . . which has been on my mind too. Lots of energy to invest in such thing though - When you would rather be doing something else like learning some new software / hardware aspect, etc. I would not mind seeing your work sometime, but could not say when I would get the time to look. If a blog post or similar I probably read a couple a day so would not be a problem - But reading through, and understanding someones code . . . is another story. Especially since my ASM is very rusty, and my ARM ASM knowledge is non existent. On Thu, Aug 6, 2015 at 2:10 PM, Carlos Novaes <[email protected]> wrote: > > 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. > -- 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.
