LED scan is not matrix style?

T&E Engineer

I am begining to work on a new long term LED Display project that uses cascaded RGB Display modules (16x8). However, it does not use a traditional scanning method of an X-Y matrix and simply uses straight outputs to the LEDs themselves. It uses the MBI5024GF which runs at 5vdc but somewhat equivalent to the Toshiba TB62726F (attached - runs at 3.3vdc). This means there are 32 ICs (1 for each LED set of 16) and each color Red1, Red2, Green1, Blue1 for each 16x8 pixel module. Lot's of data needs to be pushed through. Since there are only 32 of these IC's - according the datasheet for the module, then I would think that·DATA0 and DATA1 must be multiplexed or shared.

Is this something the SX can handle (or will multiple SX's need to be used)?

It's just a lot of SPI devices like 74HC595s (any limit on the amount of outputs) - then these 16x8 modules could then be cascaded together to get bigger and bigger. Also since they have RGB, then PWM (256 shades) will need to be worked into the mix too.

Post Edited (T&E Engineer) : 9/8/2008 12:35:34 PM GMT

Zoot

You should be able to cascade these (serial in to serial out) and feed 32 words to the whole cascade. I think your bigger challenge (if using a single SX) is setting up your data so it's not a memory hog. Certainly if you want alphanumerics, you'll need bitmaps for each character so you can feed strings and the like. So, *if it were me* I would use a single SX and an external EEPROM (perhaps 128k) -- the EEPROM would hold the bitmaps, strings, and other data so I'm not using code space on the SX that might be put to better use managing the data out to the LED drivers.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

T&E Engineer

Thanks Zoot. I was already planning on using EEPROM(s) (I have some 24LS256's) . Since this has Red,·Green and Blue·leds, that will take some time to get up to speed reading the posts about·PWM too. This will be used·as a·large data·display (with video input) and not necessarily·for character display per say.

I mainly wanted to know if it looked possible to do this with a single SX28/48 for multiple cascaded 16x8 pixel modules or if I should dedicate a single·SX28/48·for each 16x8 pixel module. Since scanning a matrix is not an issue, I think it should be possible to use a single SX28/48 depending on how the refresh rate is to get back to the begining module again.

Zoot

Still, you're just talking about shifting out 32 words, right? I see no reason to use more than one SX -- the thing to do is check the datasheet and see how fast the latches can accept shiftedin data -- then crank up your SHIFTOUTs as fast as they can go.... since this is clocked data you should be able to feed the registers data *really* fast.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

T&E Engineer

Not quite 32 words. There are 128 LED outputs for R1, 128 for R2, 128 for G1 and 128 for B1 LED outputs on (1) 16x8 pixel module. Since SHIFTOUT can shift out an 8 bit byte, then 16 SHIFTOUTs will be looped for the R1 and 16 for the R2 LEDs, 16 for the G1 LEDs and 16 for the B1 LEDs. That is only for (1) 16x8 pixel module so this means 4 sets of 16 SHIFTOUT statement loops. If cascaded, it would be multiplied even more.

Zoot

Shoot, sorry, I misread and was just counting the "base" 32 16-bit driver registers. So it's 128 words total counting both banks of leds and both colors * 16, right?

So doing some simple math "out loud":

256 bytes * 8 bits = 2048 bits for the screen "frame" to be refreshed.

Say you can really crank the clock on the shiftout up, giving you maybe 1mhz (see SHIFTIN/SHIFTOUT for the SpeedMult parameter).

1,000,000 clocks / 2048 bits. That leaves me with a refresh rate of 448. Then cut that *in half* to allow for time to read data in as well.

That would more than adequate, except for the pesky PWM part. E.g., if PWM wants to be from 0...255, then, well it's undoable (~1hz refresh). 4 levels of PWM might be more reasonable: 220/4 = ~55hz. Not great, but certainly a maybe. That might make it easier to store PWM values depending on whether or not PWM is per bank, color, grid tile, individual LED, etc. Still not great....

So.... the "equivalent" Toshiba doc you posted shows the drivers being able to accept up to 20mhz clock. You could try 4mhz shift clock with 4-16 levels of PWM at a pretty good refresh rate (over 100hz), but you could hit problems with noise. Others here can probably speak better to serial clock speeds that high (if memory serves, Peter, pjv and Guenther have all done commercial-grade projects with very fast serial comms. between devices). I've gone to about 500khz w/o problems (even on a breadboard) but I don't think I've run a clock speed that fast. Try it and see.

Actually looking over the datasheet again, if it *were me* (and it's not ) I would use the enable pins of each driver for PWM, limiting me, unfortunately, to a single brightness value for whatever LEDs are on that driver as a "group", and then all my shifted data needs to determine is off/on state. Then I could have a very fast refresh rate, using 3 pins (clock, do->di, \cs) for the driver cascade, 32 (or 16) pins of 256 level PWM out for the enable pins (on an SX28 I would probably tie all my upper/lower drivers together, and handle each column/color group as one PWM, on an SX48 there'd be enough pins).

If you wanted PWM all the LEDs individually, aside from refresh rate vs. serial clock compromises, you'd need to take into account possible ram management of current PWM values. A four level PWM has an advantage in that 4 leds worth of PWM values can be packed into a single byte.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

T&E Engineer

That's a lot to consider. From what I have read, these·modules are cascaded by the 100's and·are used in the big outdoor signs. They go into a special PC card with DVI video connections that I supose converts the video data into data streams into these modules. I'm gathering data to look at the possibilities of using these modules for something much bigger being cascaded.

Once module has 32 of the ICs which should allow:

8 Red1 LED Data 0 streams

8 Red2 LED Data 0 streams

8 Green1 LED Data 0 streams

8 Blue1 LED Data 0 streams

8 Red1 LED Data·1 streams

8 Red2 LED Data·1 streams

8 Green1 LED Data·1 streams

8 Blue1 LED Data·1 streams

This would indicate the need for 64 bytes.

So there are 4 LEDs (R1, R2, G1 and B1) that make up 1 pixel for a 16x8 pixel module.

But since there are 2 Data streams (Data 0 and Data 1), then the Data streams must be shared or tied together somehow. If you look at the attached last page of the data flow this will be more apparent.

So looking at the diagram on the last page, it shows that there are·(8 sets of 16 pixels or 128 pixel sets·of R1, R2, G1 and B1 LEDs)·or 512·total LEDs.

Each of the (32) MBI5024GF LED driver ICs has 16 LED cathode outputs (=512 total LED outputs).

So each LED color uses (8) MBI5024GF LED driver ICs (which is 128 R1 LED outputs, 128 R2 LED outputs, 128 G1 LED outputs and 128 B1 LED outputs)

Since a SHIFTOUT statement can do 8 bits then 128 bits (or 8 bytes) need to be shifted for each colored LED. 64 Bytes will need to be shifted out for all (4) LED colors worth of data.

64 Bytes of color data will have to be in EEPROM or DATA statements to get 1 screen displayed.

With the information·laided out like this, is individual PWM (256 shades) now possible with an SX?

It apparently is possible according to the attached datasheet with some other micro-controller.

Zoot

OK, right. Boy, I wish I could look at one of these on my bench...

I see now -- yeah, 512 bits per module. But how about this -- you've got TWO data lines -- I would bit bank a really simple shiftout that shifts to both sets of CASCADED data lines... that cuts your throughput in half. And don't think of shiftout as "byte" based; you can shift as many bits as you want. So if you split the data lines to two pins, then your throughput needs to shift out 256 bits per module (per pin). That's certainly not bad. How many modules are you gonna use? I don't think multiplexing is the issue here at all.

I think the two primary issues may be:

1. how many levels of PWM and what compromises might you make (i.e. using enable lines on the modules). Although if you get things down to 128 bits per module (using 4 data lines, see below) I see no reason why you couldn't do 256 levels of PWM with a fast serial clock speed.

2. the bottleneck of reading incoming data may be a bigger issue than shifting out. Even if you are sending to a bunch of modules, the bits can certainly be clocked out on both data lines really really fast w/o trouble.

Oh, another thought -- you could split up the modules into more data line "groups" -- again I would bit-bang a simple shiftout that places data onto 4 pins simulataneously for each clock pulse -- this cuts your output time by another factor of 2.

I don't know enough about these kinds of displays -- what are the two reds for? Are they generally both used as if they were "one" red led to match brightness to red/green? Or is that to get higher def in red only???

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

pjv

Zoot;

Something that worked for me a several years ago (in assembler and with one of my RTOS schedulers mind you), was to embed the brightness control into the multiplexing, so it came along for "free". Almost no extra overhead to the multiplexing code. This way I was able to dim or brighten any one particular digit (or group for that matter) for the purpose of identifying which one in a display I was applying a "raise/lower" push button to. It worked extremely well, and was very little code. It just took a little "strange thnking" is all.

It allowed me to use only two push buttons to enter values into the micro, much as you do any standard digital alarm clock; push both buttons for left digit selection/rotation, and when the desired digit is brightened (or dimmed) use one button for raising the value of the selected digit, and the other button for lowering it. Then again both buttons to shift to the next digit. It even had a "speed up" function so if either button remained pushed, the incrementing/decrementing time speeded up.

Very compact numeric data input.

Cheers,

Peter (pjv)

T&E Engineer

The 2 DATA lines are for the upper 4 and lower 4 rows of the module. There are 4 DATA 0·pins (1R0, 2R0, G0, B0) and 4 DATA 1 pins (1R1, 2R1, G1 and B1). All of these share OE, ST and CL pins.

Zoot said...
Oh, another thought -- you could split up the modules into more data line "groups" -- again I would bit-bang a simple shiftout that places data onto 4 pins simulataneously for each clock pulse -- this cuts your output time by another factor of 2.

I'm assuming the 4 pins simulataneously are either the DATA 0 or the DATA 1 set of 4 pins for the 4 colors. Right?


I will start with just trying to display a data pattern first and work in the other LED colors later. I haven't even applied power yet as Im in the process of moving to my first house later this week, so I may have to get back to this next week.

The 2 reds are: one is a "virtual" red LED which somehow adds an illusion of higher definition from what little I have read about it.

Zoot

No, what I meant was you don't *have* to cascade all DO0 -> DI0 and DO1 -> DI1. You *could* set up your modules so that half of them are tied together D1 and D0 and the other half are tied together D1 and D0. This would give you two huge "banks" of modules each of which have a D1 and D0 cascade. The only reason to do this is if throughput on the output side needs to faster (I still think throughput on the input side will be your bottleneck).

Now that I think this over more, while I think this is totally doable with an SX, depending on how much data you want to suck in at once, a Propeller may be a better bet -- you would have plenty of room for a display buffer, output, pwm, input and an 8k or so input buffer -- so you'd always have data ready for output even if the data input (say from an EEPROM) is lagging.

But again, some of this depends on the input schema from memory, etc., if you are encoding actual color in your data, or just changing color algorithmically as you dump data to the modules, etc.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php

T&E Engineer

Does anyone know if there such a device (box or component) that can take composite or DVI based video in and and·separate it·into Red, Green and Blue data streams that can be read into the SX or inputs to send it out to the display modules? - OR is it going to take an A/D converter (or built into the SX?) to do this?

Zoot

There are number of converters for taking Vid signals and outputting data streams, but:

- all seem to be surface mount

- very very fast clocks on output data streams (10-270 mhz)

- you better know your video (I can't say I do!)

One example: search.digikey.com/scripts/DkSearch/dksus.dll?Detail?name=568-3594-ND

You might want to try over in the Prop forums where a lot of folks are doing video work (both in and out). A Prop is probably a better solution for this project, to be honest.

▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
When the going gets weird, the weird turn pro. -- HST

1uffakind.com/robots/povBitMapBuilder.php
1uffakind.com/robots/resistorLadder.php