Ah ok software radio, gnuradio etc. But yes like Carlos said start a new topic of your own.
On Thu, Aug 6, 2015 at 6:31 PM, William Hermans <[email protected]> wrote: > Ultra High Definition Television ? Pretty sure the BBB can not do 4k video > . . . > > On Thu, Aug 6, 2015 at 5:30 PM, Carlos Novaes <[email protected]> wrote: > >> I don´t know UHD. If there are any usb device connected, lsusb and dmesg >> will show it. You better start a new and specific topic anyway. >> >> Le jeudi 6 août 2015 18:41:32 UTC-3, April Hutagaol a écrit : >>> >>> 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. >> > > -- 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.
