Driving serial led driver

I need to drive a chain of serial led drivers (Micrel MIC5400) @ 5 mHz. The total number of leds in the chain is around 7500. When sending to the MIC5400 one sends 36 bits to each chip - 18 bits per pixel. The chip controls 16 leds so one must send 8 times to update all leds. And the clock must keep running all the time as it is used by the MIC5400.

The update time from my cpu isn't critical (could be a couple of seconds) but if my cpu sends the data that slow to the MIC5400 it will be visible when sending the 8 parts.

As my cpu can't handle 5 mHz I was thinking about making a small board with 2 shift registers. One shift register for my cpu to send the data for all leds as fast as my cpu can send it, saving it in one of two ram send buffers on the board. One shift register for the board to send the data from the active send buffer buffer to the leds @ 5 Mhz reading back the response from the MIC5400 saving it in one of two receive buffers where my cpu can read it back at it's own speed later.

The question is what type of hardware to use? FPGA, small cpu or something else.

Is this something that maps well on to a FPGA? The buffers need to be almost 128K. And I need to learn programming FPGA:s or hire someone to do it.

It should also be possible to solve with a fast microcontroller with

128k ram and 8 i/o lines - 2 times din, clk, load, dout.

Does small fast microcontrollers with 128k ram exist?

Ronny

Reply to
Ronny Svensson
Loading thread data ...

Hi,

In my opinion -to this project- FPGAs are "the best solution available" today, I have working a screen with near 1 millon leds using Xilinx FPGAs, but be carefull is not starting FPGA project.

One comment, When using FPGAs, you made a hardware design and load a FPGA, not "programming FPGAs".

Walter.

El Fri, 21 Nov 2003 10:04:19 -0800, Ronny Svensson escribió:

Reply to
Walter Daniel Gallegos

You should be able to do this easily using the Atmel AT91R40008. It has 256 kB RAM and runs at 66 MHz for 60 MIPS. Does not have the SPI, but you can easily do 5 MHz in Software It is easier to debug C than VHDL. Free GCC compilers The AT91R40008 development board is called EB40A

--
Best Regards
Ulf at atmel dot com
These comments are intended to be my own opinion and they
may, or may not be shared by my employer, Atmel Sweden.
Reply to
Ulf Samuelsson

Do you have to use the MIC5400? There are serial drivers from other companies (TI and Allegro come to mind) that can do on/off (but not necessarily the brightness variation) and are far easier to use.

Nothing against the MIC5400, it's a cool driver for RRGB picture displays, but it's not the only fish in the pond if you aren't doing RRGB pictures.

Tim.

Reply to
Tim Shoppa

The biggest problem for me (as a programmer) is keeping a steady clock running and not being able to send down the led values and update all the leds at once (but must do it in 8 parts - can't be too slow before beeing visible). But we need a serial driven chip (for simple daisy-chain - no 8-bit like TI). Each led must have individual intensity control - that normally leads to pwm. Invisible led test a plus. Is there other chips that do this?

Ronny

Reply to
Ronny Svensson

As this is a "micro-program" and me not being a C-programmer is it feasible to program the ARM in assembly (just for this fixed problem)? How long time do you think is needed to "get started"? Having done some assembly programming on 386, H8, 68000 etc. Normally programming H8S2357 in Forth (and some assembly).

Ronny

Reply to
Ronny Svensson

Being a programmer and looking a little at Verilog it's easy to miss the hardware bit...

For me the cpu approach is the natural - no surprises.

But the scalability of FPGA:s is appealing - and the possibility to do more than one thing at a time...

The hardware designer isn't very interested so the question is: Is it easier for a programmer (like me) to master FPGA:s than it is for a hardware designer working with circuit board layout and fixed logic?

When it is so "program like" is it still a normal hardware design process?

Ronny

Reply to
Ronny Svensson

7500 LEDS and 18 bits -> 128K bits. This is doable in either FPGA or uC.

Modern FPGA have enough block RAM to buffer the pixels, and any FPGA with sufficent RAM, will have LOGIC resource to burn. Probably to the point of overkill, as your logic needs are trivial.

Or, look at larger RAM uC, Philips LPC21xx have 16/32/64KBYTES of SRAM & SPI, which is plenty. So you can think of the LPC2106 as 'Smart Serial Bridge RAM' in a nice small package LQFP48. You may even be able to discard the 'other cpu' :)

-jg

Reply to
Jim Granville

El Mon, 24 Nov 2003 14:51:34 -0800, Ronny Svensson escribió:

today,

Ronny

Hardware is hardware and software is software...

VHDL, Verilog and others are hardware description language. You can't code in HDLs as you code in Oberon, Pascal or C.

Hardware design metodology is very diferent to software design.

Walter.

Reply to
Walter Daniel Gallegos

... snip ...

I disagree, possibly because I went from hardware to software. I had no choice :-) FPGAs etc. are new-fangled ways of approaching hardware.

Software can be looked at as being clocked hardware, with the clock being the instruction execution rate. Any reverse mapping requires a herd of new concepts, such as massively parallel machines. The hardware is much more capable than the software, but nowhere near as flexible.

--
Chuck F (cbfalconer@yahoo.com) (cbfalconer@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
     USE worldnet address!
Reply to
CBFalconer

companies

The TI TLC5922 does all of this, and AFAICT is true daisy-chain 1-bit serial data. OK, dead LED detection is more complicated than pure serial data, but I'm guessing that you'd do this with some sort of wired-OR feedback to the microcontroller.

And I don't think that internally that it's PWM: it seems to really be analog current regulation through a 7-bit D/A on each output driver. So you don't have to clock all the time to do PWM. This will probably help you with FCC RFI emissions in the end too.

I think Allegro has a similar (although not identical) part but I don't know it off the top of my head.

At some point, for larger arrays, you may abandon 1-bit daisy chain in favor of 8-bit wide daisy chain. It sounds to me like you're near a bandwidth bottleneck already.

Tim.

Reply to
Tim Shoppa

Most microcontrollers have synchronous UART/USART ports with some buffering. The buffer often isn't very deep, but if your software can't keep up with some buffering, it probably won't keep up with deep buffers either. (I'm being cynical here!)

Tim.

Reply to
Tim Shoppa

El Tue, 25 Nov 2003 06:22:23 +0000, CBFalconer escribió:

I don't have a good english, but you disagree what ?

To continue we need start a new topic, here we are "out of topic";

Walter.

Reply to
Walter Daniel Gallegos

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.