4

I am building a Persistence of Vision project with 120 RGB leds (=360 total lines to be controlled). We have settled on the TLC5940 for driving the LEDs (and could be open to changing this), however, now we have a problem getting the data fast enough to the LED driver chips. Currently we are using ATmega328/ATmega128-class chips which top out at 20Mhz, and we aren't able to process the data to be loaded onto the TLC5940s fast enough. Should we consider another uC? The desiderata are:

  • Low cost/uC
  • Low startup costs (For instance, CPLDs require a certain initial investment to get started with)
  • 3.0-5.0V
  • Ideally available in a DIP package for easy prototyping
  • 30+ GPIO lines (to load the LED controllers in parallel)

This question may be an intellectual poor cousin of this question, however, I think our requirements are somewhat different.

Details: why ATmega328 isn't fast enough (so far)

In the ideal world, we should be able to load the data for all LEDs in under 746uS (that's the project requirements), and again, in theory, if we bitbang at 2clocks/bit we should be able to do it in 108uS @20Mhz, however, all the bit shifting to decide what intensity to send to each LED right now gives us 1536uS load times. This is with avr-gcc OPTLEVEL=2 or OPTLEVEL=3, all sorts of loops manually unrolled, parallel loading of all LED controllers, and every time-saving technique we can think of.

Community
  • 1
angelatlarge
  • 3,611
  • 22
  • 37
  • 2
    Why are you bit-banging the clock? Use the built-in SPI or USART modules. That should be plenty fast. – Connor Wolf Mar 31 '13 at 18:16
  • The main reason is that with bitbanging I can put up to 8 data lines (one for each driver) on each port, then load 8 bits at once by trying their clock lines together. This ends up being faster than loading them serially, I think. In any case, it isn't so much "pushing the bits out the ports" that takes up most of the time, it is deciding what bits should go here: lots of bit twiddling that takes up a bunch of time. Perhaps I should post the code for that? – angelatlarge Mar 31 '13 at 18:28
  • In that case, you should perhaps be more clear that you're CPU constrained, not IO constrained. As such, "fast GPIO" isn't really relevant, you primarily need more CPU power. – Connor Wolf Mar 31 '13 at 18:32
  • I think you are right. Subject changed accordingly. Thank you. – angelatlarge Mar 31 '13 at 18:52
  • 1
    Maybe have a look at the [Parallax Propeller](http://www.parallax.com/propeller/), also available in DIP @ around €10 per unit. – JimmyB Apr 03 '13 at 22:47
  • Yes, it sounds promising. - Btw, are you programming in C? Coding parts in assembler may greatly improve performance, especially when it comes to bit-wise operations by taking full advantage of all flags in the SREG. – JimmyB Apr 03 '13 at 23:46
  • Yeah, I am taking a look at that. – angelatlarge Apr 03 '13 at 23:50

4 Answers4

7

I would step up to a cheap ARM. You can get the Freedom Board which is a Cortex-M0+ which can run up to 48Mhz. Also being an arm you will get 32 bit registers so you can do more per op-code. Also it has a DMA engine so you might be able to off load the loading of the LEDs to DMA while the processor updates the memory. You can get them from Digikey as well as the other usual suspects.

As for development tools there is CooCox, mbed and CodeWarrior.

Rex Logan
  • 901
  • 1
  • 8
  • 12
  • This board also supports the mbed platform, which is an easy to use development platform with a tools,libraries and large community similar to arduino. It'll get you started in no time. http://mbed.org/handbook/mbed-FRDM-KL25Z – hulkingtickets Apr 01 '13 at 09:50
1

The Atmel XMEGA line is rated up to 32 MHz, is fairly cheap, and comes in up to 100-pin packages.

Sparkfun has a pre-made breakout for the xmega128A1 for prototyping: https://www.sparkfun.com/products/9546 -- there are also a bunch of dev kits including Atmel's XPLAIN board.

jpwr
  • 301
  • 1
  • 10
  • We considered XMega, however, given that it is less than 2x the clock speed of ATmega it seemed like it wasn't going to be an ideal solution given that we need to load the LEDs twice as fast. – angelatlarge Mar 31 '13 at 18:51
1

I would probably look into the mbed platform. You might be able to use one of their DIP modules as your "uC DIP", though it will contain the necessary surrounding peripherals as well (crystal, power, etc). While this will be significantly more expensive than buying bare microcontroller chips, it sounds like you're not producing this in mass so that shouldn't be too much of an issue..

There is a large developer community and the hardware can definitely meet your I/O and speed requirements. Due to the readily accessible development tools these rather complex microcontrollers will still have almost no start-up time.

NickHalden
  • 4,167
  • 3
  • 31
  • 40
  • ARM, yes. But probably not mbed, as that just delays spending the few days needed to learn to work with the bare parts - better to get that out of the way upfront and not have any pending surprises. TQFP's are quite approachable. – Chris Stratton Mar 31 '13 at 19:20
0

The PIC24EP256GP204 is a 16-bit machine, can run at 70 MIPS and has 35 I/O lines. Unfortunately it's not available in DIP.

It doesn't need an external oscillator and is a 3.3V device. It can be in-circuit programmed with low-cost programmers like PICkit3 (around $70), has a free non-optimizing C-compiler (XC16 - licensing it gets you optimization) and two free IDEs with simulators (MPLAB 8 and MPLAB X).

It's been my experience that working in assembly on this part isn't that bad - I use the free version of the compiler and hand-optimize in assembly where necessary.

Adam Lawrence
  • 32,921
  • 3
  • 58
  • 110