Driving serial led driver

Do you have a question? Post it now! No Registration Necessary

Translate This Thread From English to

Threaded View
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

Re: Driving serial led driver
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ó:

Quoted text here. Click to load it


Re: Driving serial led driver
Quoted text here. Click to load it
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

Re: Driving serial led driver
El Mon, 24 Nov 2003 14:51:34 -0800, Ronny Svensson escribió:

Quoted text here. Click to load it
today,
Quoted text here. Click to load it

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.


Re: Driving serial led driver
Quoted text here. Click to load it
... snip ...
Quoted text here. Click to load it

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 ( snipped-for-privacy@yahoo.com) ( snipped-for-privacy@worldnet.att.net)
   Available for consulting/temporary embedded and systems.
We've slightly trimmed the long signature. Click to see the full one.
Re: Driving serial led driver
El Tue, 25 Nov 2003 06:22:23 +0000, CBFalconer escribió:

Quoted text here. Click to load it



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.



Re: Driving serial led driver
Quoted text here. Click to load it


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
We've slightly trimmed the long signature. Click to see the full one.
Re: Driving serial led driver
Quoted text here. Click to load it
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

Re: Driving serial led driver
snipped-for-privacy@hotmail.com (Ronny Svensson) wrote in message
Quoted text here. Click to load it

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.

Re: Driving serial led driver
shoppa@trailing-edge.com (Tim Shoppa) wrote in message
Quoted text here. Click to load it
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

Re: Driving serial led driver
snipped-for-privacy@hotmail.com (Ronny Svensson) wrote in message
Quoted text here. Click to load it
companies
Quoted text here. Click to load it

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.

Re: Driving serial led driver

Quoted text here. Click to load it

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







Re: Driving serial led driver
snipped-for-privacy@hotmail.com (Ronny Svensson) wrote in message
Quoted text here. Click to load it

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.

Site Timeline