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