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.
