David, William's suggestion of the PRU is a really good one. I know there are examples on the forum for using them - even though I personally haven't looked at them. You should be able to do everything inside the PRU - You only need 144 bytes per buffer (assuming 1 color / 1 bpp). So even having multiple buffers shouldn't be an issue. You should even still be able to leverage the SPI interface if desired. I understand that bit-banging via the PRU is much more efficient than even bare metal inside the CPU.
The UNC5821 driver has a much simpler interface than the ws28xx serial lighting chips. It's an old retired chip that is essentially a shift register and a latch. Which makes it quite suitable for SPI as you really only need clk and data to send info to it. It's also not as timing dependent - 800KHz - 1 wire timing. These parts are also forgiving if you get word boundary bound that you can always just push extra data through the chain - leaving valid data in the register behind it. So for instance if you end up having to do 32-bit xfers into a 144 bit chain, you can shift out 160 bits (5 xfers) and just have the 1st 16 bits be don't care. The remaining 144 will remain in register and get xfer'd when latched. This is a fairly high power chip - haven't looked to see if there is a new version for new designs - so I'm expecting that you (David) must be recycling an old display. If not, there are a bunch of similar chips out there - most are 16-bits wide - see TI, ST Micro, Silicon Touch, Macroblock, Toshiba... Good Luck, Matt On Tuesday, March 22, 2016 at 12:12:31 AM UTC-5, William Hermans wrote: > > The way I see it is that you have two options. You could use the PRUs, or > you could use the McSPI hardware module. I would attempt to help you but I > really do not have any experience with the ws28xx style serial protocol > that many seem to use with external lighting of this type. > > I can tell you that a very simple, and cheap msp430g2553 project would be > more that enough to do all this - bare metal. So no needs for a cpld or > FPGA or anything fancy like that. But again as mentioned by Matt above, you > have to design a PCB, + circuit and the costs add up despite the fact that > a G2553 is only about $2-$3 sold as singles. > > Anyway, maybe someone here knows the McSPI module well enough to comment > on "shifting out" data to your matrix ? As in actually knowing what they're > talking about . . . > > How does this buffer work anyhow ? Is this like a bit field in both > dimensions, or what ? Kind of hard to grasp on a simple code glancing ;) > > On Mon, Mar 21, 2016 at 4:36 PM, David Good <david...@gmail.com > <javascript:>> wrote: > >> Yes, I would love for someone to give me tips on setting up a periodic >> timer interrupt. What I have might be the only way to really do it, but I >> would assume not. >> >> Thanks for your tips on ghosting. I will use it when I start to see real >> data in the buffers rather than my simple test patterns. >> >> About using SPI. Yes, this is what I was doing on the Raspberry Pi, but >> haven't done it on the Beaglebone yet. I will definitely give it a shot. >> Bit banging the clock and data looks like it's costing me ~1ms per row as >> currently implemented. >> >> On the topic of dedicated hardware offloading the workload, I suppose >> that this is exactly what the PRUs are designed for. Perhaps it's time to >> say Hello World to one of them. Since this is a personal project, there >> aren't any real design requirements, so any option is open to me right >> now. I was planning to layout a PCB to clean things up a bit because right >> now I have a hand soldered perf board with ribbon cables :) >> >> Thanks for the suggestions! Let's see if someone can answer about a >> kernel timer interrupt. >> >> --David >> >> On Mon, Mar 21, 2016 at 6:07 PM, CEinTX <mpo...@gmail.com <javascript:>> >> wrote: >> >>> David, >>> >>> Without seeing your circuit of how you are setting up your rows & >>> columns to be driven, I'll take a blind stab at your issue. >>> To get rid of artifacts / ghosting / etc... >>> 1) Shift out all your data >>> 2) Turn off your drivers and row power if that is available >>> 3) Delay ~20us >>> 4) Latch the data into your drivers >>> 5) Delay ~20us or more >>> 6) Change your row address >>> 7) Enable your outputs and/or row power >>> >>> You must have some dead time between rows or you will get artifacts / >>> ghosting / whatever you choose to call it. >>> You might get away with less than 20us but also you might need more >>> depending on your circuit. >>> Too much dead time and you will get flicker - not enough and you guessed >>> it - artifacts/ghosting. >>> >>> For what it seems like you are doing, I'd use the SPI interface to shift >>> out your data in blocks of 16-bits - 9 xfers gets you 144 bits out. >>> You obviously could bit bang this but why when you have built-in >>> hardware that will do it for you. I'd think it would be fast enough in an >>> ISR. I should think less than 250 us. >>> Use the gpio for toggling your latch and output enable and addr/row >>> select - these are low speed signals - so no problem >>> There are definitely easier ways to do this with external hardware, but >>> for this size matrix it would be a waste of $. Yes, a $1-2 cpld will do the >>> trick - but then you need a pcb etc... >>> Setup a periodic timer interrupt to sync your shifts / rows of data - >>> take your refresh rate (suggest 55-80Hz to avoid flicker) & divide by # of >>> rows (timer => 440 to 640 Hz / row) >>> Use the time between interrupts to setup your next buffer for display >>> >>> Get someone here to help you with the timer/interrupt under Linux - I >>> have no idea on that one. Would like to though - so maybe someone will >>> respond with how to do that. >>> >>> Hope that helps. >>> >>> Good Luck, >>> Matt >>> >>>> >>>> -- >>> 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 beagleboard...@googlegroups.com <javascript:>. >>> 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 beagleboard...@googlegroups.com <javascript:>. >> 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 beagleboard+unsubscr...@googlegroups.com. For more options, visit https://groups.google.com/d/optout.
