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.go...@gmail.com> 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> 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+unsubscr...@googlegroups.com. >> 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. > -- 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.
