Can you help me, I've installed UHD but Uhd_find_devices and Uhd_probe nothing :( Please help
On Fri, Aug 7, 2015 at 4:18 AM, William Hermans <[email protected]> wrote: > *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. > -- Apriliani Herlina Hutagaol -- 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.
