Continue to Site

Welcome to our site!

Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

  • Welcome to our site! Electro Tech is an online community (with over 170,000 members) who enjoy talking about and building electronic circuits, projects and gadgets. To participate you need to register. Registration is free. Click here to register now.

Want to learn about PWM for SPI type RGB LED display

Status
Not open for further replies.
please forgive my ignorance if im a mile off - and my lack of technical terms - but on the data sheet it says the clock can be pulse on/off in 20ns, therfore 20ns on,20 ns off = 40ns per pulse

40ns * 64 = 2560ns (2.56ms i think)
+ say 40ns for the latch = 2.6ms

at a refresh rate (for the single module) of 20Hz (should be ok for video), that is 40ms between refreshes

therefore you have 40/2.6 = 15 (and some change) chances to turn each led on or off per refresh

so by dividing the brightness of each pixel by 15, and sending an 'on' for that pixel for that many cycles you have 15 levels of brightness for that led.

sorry i cant explain better:- but if you want a pixel at half brightness, then from the start of the refresh you send a 'on' the first 8 times, then an 'off' the remaining 7 times.

that would give you a half brightness led

repeat that for all 4 pixels and you get (15^4) thats 15 brigness ^ 4 leds = 50625 colours (not as many as youd like) but a start

please dont flame me too much - im a newbie and i dont read chinese


EDIT:

just re-read the diagram, same principle but it clocks in 8 lines simultainously * 64 bits (on the driver board) , and does each colour led independently

but still do-able
 
Last edited:
SMUGangsta,

This is certainly a new approach not thought of and may be doable. However, I'm not following everything you say. Can you be a bit more specific or break it down for me more to understand a little more.

You also say that it clocks in 8 lines simultaneously. Remember that these boards can be cascaded to dozens or a hundred or more display boards so clock or a latch or an /OE affects ALL MBI5024GF LED driver chips and subsequently all of the cascaded display boards attached (not just 8 you see in the drawing).

There are 2 data streams on each 16x8 module (upper 4 rows and lower 4 rows with 16 columns for each pixel set of R, R2, G and B leds = 16 columns * 8 rows * 4 LED pixel sets = 512 LEDs per module). So 512 LEDs / 16 outputs per MBI5024GF LED driver = (32) MBI5024GF LED drivers per each 16x8 module. This means there the CLOCK, LATCH and /OE are going to (32) MBI5024GF LED drivers for each 16x8 module. Remember if they are cascaded (like I have 2 of them cascaded - but many many more could be for a huge display), the CLOCK, LATCH and /OE goes out to ALL OF THE MBI5024GF LED drivers not just 8 lines. So I don't understand what you meant by that. Please clarify.

Currently I am just toggling the clock signal at the speed of the SX28 micro-controller running with a 20 MHz resonator. However, I could use a 50 MHZ resonator if needed.

However, if the CLOCK should be on for 20 ns and off for 20 ns, it should be possible. I could do something like this in SXB for the SX28 chip:

CLOCK = 1
PAUSEUS 0.02 'a 20 ns pause
CLOCK = 0
PAUSEUS 0.02 'another 20 ns pause

SO your next calculation is a bit off I thinK.

40ns * 64 = 2560ns (2.56ms i think)
+ say 40ns for the latch = 2.6ms


I think it should be:

40 ns * 64 * 2 (upper and lower data streams = 128) = 5.12 uSec (-not mS-)
+ 40 nS for the latch = 5.12 uSec + 0.00004 uSec = 5.12004 uS (Right?)

You then state:

at a refresh rate (for the single module) of 20Hz (should be ok for video), that is 40ms between refreshes

Where did you get these numbers from?
Is 20Hz a calculation or stated on the data sheet somewheres?

I think you are on to something if we can work through these numbers.

Waiting for your reply!

Thanks so much.
 
20 Hz is based on the fact that 20Hz is an accptable rate for viewing video, although we are used to 25Hz on our tv. For an LED tv - 20Hz should be more than enough.

first off i thought it was a single 64 bit train that controlled it, then i realised that its not - each of the 8 inputs (R1A,R1B,G1,B1)bottom (R2A,R2B,G2,B2)top are are clocked at the same, so you are actually clocking in 64Bytes every latch.

oooooo - now thats a problem I messed up and your right, it does go from nano to micro to milli, in which case what are you waiting for??? because the 40ms between refreshes is right, so you would theoretically flash each led 15625 times between refreshes.

you could flash each and every led 256 times betweens refreshes - thus 4294967296 possible colours??

it was late when i did the maths, so my brain was melting, but i think the theory is good

that massive gap between micro and milli will let you udate a whole lot more displays and keep a high refresh rate
 
20 Hz is based on the fact that 20Hz is an accptable rate for viewing video, although we are used to 25Hz on our tv. For an LED tv - 20Hz should be more than enough.

20Hz is probably a little on the low side, some people can see flickering on normal 50Hz TV's (25 frames per second) - dropping to 20Hz is going to mean a LOT more people will see the flickering.
 
We have th big LED TVs in swansea town centre (BBC NEWS24), as well as they spinning video screens, and they flicker very visibly, but as a start having 20Hz would at least be a video, and if the time left between refreshes (after fetching data and processing it) is enough you can up the refresh rate, who knows - if you can process the incoming data fast enough you could mabey get 30Hz.

My appologies Nigel, I never realised that 50Hz was only 25 frames, where I have specifed 20HZ i was meaning 20 Frames per second. Out of curiosity why is this, do we have interlaced frames in the UK
 
My appologies Nigel, I never realised that 50Hz was only 25 frames, where I have specifed 20HZ i was meaning 20 Frames per second. Out of curiosity why is this, do we have interlaced frames in the UK

As far as I'm aware all the world have interlaced TV?, the UK and Europe has 50 interlaced fields giving 25 frames, and the USA has 60 interlaced fields giving 30 frames. For HD there are essentially two formats, 1080i (interlaced fields) and 720P (progressive single field) - plus 1080P, used by BluRay, and not a broadcast format.

Just as with CRT sets, LCD's are now available as 100Hz, and the very latest Sony is 200Hz - but there's no flickering problems with LCD/Plasma anyway, as they aren't scanned.
 
OK - Lets do this again.

tw(CLK) = 20 nS on time and 20 nS off time = 40 nS total CLOCK pulse time

40 nS total CLOCK * 64 bits (or 8 bytes) per RGB input (which is 8 RGB inputs to cover both upper and lower data streams) = 40 nS * 64 * 8 = 20.48 uS
Add to this total CLOCK time (20.48 uS) the 40 nS for the single Latch (20.48 uS + 40 nS) = 20.52 uS to clock through data for (1) 16x8 RGB LED module.

In the US, TV scanning is at 60 Hz so Time = 1/Freq = 1/60 Hz = 16.67 mS refresh rate.

16.67 mS refresh / 20.52 uS = 812 chances to turn on each LED on / off per refresh.

So by dividing the brightness of each pixel by 812, and sending an 'on' for that pixel for that many cycles you have 812 levels of brightness for each led.


I can't figure out the rest of your calculations to get the colors and other factors. Can you break down the calculations?

If I have more 16x8 modules cascaded, then all would be multipled out too.

Do I have this right?
 
Yeah you seem to have the jist of what I was trying to say (im very impressed because I dont understand it - lols)

My assumptions on colours is that the number of times you can turn on/off an led (brigtness) between each refresh defines how many differnt shades of led colour is possible (within reason - obviously on for 1ns isnt going to work) so if we say (as per your calculation that a refresh happens every 16.67ms, then you take that and divide it by a sensible number of shades (256 springs to mind) so the led 'on' or 'off' period would be 65uS, so for 50% brightness it would be on for 65uS * 127 (half of 256 available shades) = 8255uS out of the 16670uS available between refresh. << thats your (16.67mS)

we have 256 shades of say red = 256 ^ 1 = 256 Colours possible 256
and 256 shades of red2 = 256 ^ 1 = 256 Colours possible = 256 * 256
and 256 shades of green = 256 ^ 1 = 256 Colours possible = 256 * 256 * 256
and 256 shades of blue = 256 ^ ` = 256 Colours possible = 256 * 256 * 256 * 256

or 256 ^ 4 depending on your preffered way of writing it

256 ^ 4 = 4294967296 possible colours

That is unless both reds need to be on simultainiously, in which case it would just be 256 ^ 3 or 16777216 colours which is 24bit colour - more than enough for a tv (at least until you get it all working properly)


As i stated im not a technical person - just trying to be logical.
 
OK - To recap:

tw(CLK) = 20 nS on time and 20 nS off time = 40 nS total CLOCK pulse time

40 nS total CLOCK * 64 bits (or 8 bytes) per RGB input (which is 8 RGB inputs to cover both upper and lower data streams) = 40 nS * 64 * 8 = 20.48 uS
Add to this total CLOCK time (20.48 uS) the 40 nS for the single Latch (20.48 uS + 40 nS) = 20.52 uS to clock through data for (1) 16x8 RGB LED module.

In the US, TV scanning is at 60 Hz so Time = 1/Freq = 1/60 Hz = 16.67 mS refresh rate.

16.67 mS refresh / 20.52 uS = 812 chances to turn on each LED on / off per refresh.

So by dividing the brightness of each pixel by 812, and sending an 'on' for that pixel for that many cycles you have 812 levels of brightness for each LED.

A sensible number of shades is 256 so the LED on or off period would be:
16.67 mS / 256 shades = 65.104 uS.

For 50% brightness this would be 65uS * 127 (1/2 of the 256 shades) = 8.268 mS.

So this gives us 8.268 mS available from the 16.67 mS for 50% brightness.

We have 256 shades of say red = 256 ^ 1 = 256 Colors possible = 256
and 256 shades of red2 = 256 ^ 1 = 256 Colors possible = 256 * 256
and 256 shades of green = 256 ^ 1 = 256 Colors possible = 256 * 256 * 256
and 256 shades of blue = 256 ^ ` = 256 Colors possible = 256 * 256 * 256 * 256

or 256 ^ 4

So 256 ^ 4 = 4,294,967,296 possible colors = 32 bit color

That is unless both reds need to be on simultainiously, in which case it would just be 256 ^ 3 or 16,777,216 colors which is 24bit color - more than enough for a video based LED display.

-------

So now we know how it may be possible to get 32 bit color ON A SINGLE 16x8 RGB LED DISPLAY MODULE (even though it is possible somehow to get 36 bits - but I'm more than happy with 24 or 32 bit), How do I apply this?

I stated before to add in delays or pause statements of 20 nS for the Clock on and 20 nS for Clock off. And probably want to do this also for the Latch.

How can this be information be applied to the /OE to get the 256 shades per LED?
 
Ok, I have attached a few pictures, that is one module (16x8) enlarged for clarity, i have also attached the same picture divided into its constituent parts, eg RED, GREEN, BLUE. I am making the assumption that boths reds need to be on together.

On the pictures i have circled an area (4x4) for bottom part amd (4x4) for the top part.

Below is that section converted to binary (starting at the bottom right, working left and up as in the datasheet, but thinking about it now it probably needs reversed due to the way data is SHIFTED in, but it wont affect the explanation)

Code:
R1A: 91,124,109,111,91,79,88,113,58,52,157,242,64,92,111,95
R1B: 91,124,109,111,91,79,88,113,58,52,157,242,64,92,111,95
G1 : 78,109,95,98,86,73,73,76,64,52,148,227,79,97,105,81
B1 : 87,116,94,89,82,73,78,95,78,62,151,224,118,117,107,72
R2A: 110,153,84,153,114,146,136,146,107,144,255,106,149,142,170,94
R2B: 110,153,84,153,114,146,136,146,107,144,255,106,149,142,170,94
G2 : 128,154,73,136,123,136,118,128,105,126,242,96,143,124,160,98
B2 : 176,175,69,118,162,147,108,108,126,124,232,87,143,112,158,110

These are the BRIGHTNESS levels for the section highlighted for each of the RED,GREEN and BLUE leds.

to reproduce the image:

this is psudo code: in a basic type syntax



Code:
For X=0 to 255 (this is the brightness)
 For Y=0 to 63 (This is the Rows) (only 16 shown above cos i dont have the time)
    load in the colum (y) from the array above

    if R1A <= X then OUTPUT_R1A = 1 else OUTPUT_R1A = 0
    if R1B <= X then OUTPUT_R1B = 1 else OUTPUT_R1B = 0
    if G1 <= X then OUTPUT_G1 = 1 else OUTPUT_G1 = 0
    if B1 <= X then OUTPUT_B1 = 1 else OUTPUT_B1 = 0
    if R2A <= X then OUTPUT_R2A = 1 else OUTPUT_R2A = 0
    if R2B <= X then OUTPUT_R2B = 1 else OUTPUT_R2B = 0
    if G2 <= X then OUTPUT_G2 = 1 else OUTPUT_G2 = 0
    if B2 <= X then OUTPUT_B2 = 1 else OUTPUT_B2 = 0

    clock the latch
  next y
  delay 65uS  (obviously this would be smaller as there is no account for overhead)
next x

that would (should) give you the image attached as 'color', with 24bit colour

can you see from that code snippet how the colours are achieved?

output_XXX is an outpin connected to the relevent pin on your module
 

Attachments

  • color.png
    color.png
    1.5 KB · Views: 225
  • Red2.png
    Red2.png
    1.4 KB · Views: 179
  • Green2.png
    Green2.png
    1.4 KB · Views: 167
  • Blue2.png
    Blue2.png
    1.4 KB · Views: 164
This looks very interesting I will try and convert my SXB program into this format tonight.

The DATA statements I have in my original SXB program are the lower and upper halves (for the upper and lower data streams) of a Smiley face and there are 2 sets because I have 2 cascaded 16x8 modules.

Where did you get the data information from for your data below?
Code:
R1A: 91,124,109,111,91,79,88,113,58,52,157,242,64,92,111,95
R1B: 91,124,109,111,91,79,88,113,58,52,157,242,64,92,111,95
G1 : 78,109,95,98,86,73,73,76,64,52,148,227,79,97,105,81
B1 : 87,116,94,89,82,73,78,95,78,62,151,224,118,117,107,72
R2A: 110,153,84,153,114,146,136,146,107,144,255,106,149,142,170,94
R2B: 110,153,84,153,114,146,136,146,107,144,255,106,149,142,170,94
G2 : 128,154,73,136,123,136,118,128,105,126,242,96,143,124,160,98
B2 : 176,175,69,118,162,147,108,108,126,124,232,87,143,112,158,110


I see no mention of the /OE line. Is this just turned on (active low) when the data gets latched - as it does in my original SXB program - OR was this missed and something special happens to it?

Thanks - I will share my results tonight!
 
that table is made from the grey values for each of the RED,GREEN,BLUE channels from the original picture (the colour one) - the grey value represents how bright that led needs to be on each channel to get the desired colour.

I noticed a problem with my code sample, although it does have the right amount of 'on' time, it is in one chunk, when it should be spaced with the off time. Its a function of 256/colour value - i had it in my mind on the drive home - but ive lost it now. Will think about it more tomorrow :D


do you understand my concept now?

The /OE i guess just turns the display on or off - i havn't looked into it - but thats not used for my method of drawing the display
 
Last edited:
I tried to incorporate your code idea into my original SXB program which is attached as a TEXT file so you can view it with Notepad or something. I have commented out unused or modified original SXB program code.

This program does nothing but display a smiley face in red, red2, green and blue LEDs. See attached picture. See how they are offshifted for the different LED colors.

I tried adding a PAUSEUS 0.020 between the CLOCK and ST statements and varried the amounts dramatically and saw no differences. I also adjusted the differences of the PAUSEUS after the OE = 0 and this sort of did something with brightness (low number like PAUSEUS 1 was dim and higher number like PAUSEUS 100 or more was brighter). However when trying to add a nested loop caused such an increase in delay that no changes in the brightness PAUSEUS statement made any difference (just stayed bright).

Anyway - perhaps you can modify the working SXB program to see how I am acheiving the SPI routine.

Let me know...Thanks!
 

Attachments

  • Absen-OF20V_2CascadedColor_v1a.txt
    9.2 KB · Views: 210
  • DSC01147.jpg
    DSC01147.jpg
    130.5 KB · Views: 224
How can this be information be applied to the /OE to get the 256 shades per LED?
It can't. As I mentioned earlier, applying a PWM signal to the /OE inputs will allow you to adjust the overall display brightness.

Also, as you're looking at solutions for full RGB color control, consider this; You're basically talking about sending 512 bits of data (64 bytes) to the display latches 256 times during a 16.67 msec period. That's 16,384 bytes for a 24 bit color 'still' frame, assuming redundant red LEDs. If you can send 64 bytes to the latches every 65.1 usecs (1/256th of the frame rate) and you can buffer a 16KB 'still' frame in Flash you're in good shape. Otherwise, you're looking at compressing the 'still' image, perhaps using 2048 bytes of 0..255 LED PWM values, and building each 64 byte update stream from that but I doubt you're going to be able to do that within 65.1 usecs.

I can't help wondering if 8 bits per color (256 colors) might be a better target?

Good luck. Mike
 
Last edited:
Mike,

Thanks again for your input!

The more I am working on this project, the more I beleive that the SX28 is just not the right choice for this due to limitations in PWM, RAM, etc. I am "possibly" wanting to look at PIC or AVR or other semi-easy BASIC methods to better acheive this goal. Any ideas?

I just like the SX28 as I know it the best and a bit hesitant on starting from scratch with a new micro-controller to learn again.

Thanks,

Tim
 
Hi Tim,

Yeah, I saw your other thread. Not sure what microcontroller to suggest. What you're trying to accomplish is certainly "pushing the envelope" and I can't imagine trying to do it in BASIC.

Good luck. Mike
 
Last edited:
Mike,

I don't know if it really is pushing the envelope. For just sending out SPI based data, it is a piece of cake. The problem has come in when trying to get shades of Red, Green and Blue LEDs on these SPI based modules - or what I beleive is refered to as PWM.

We know that it is possible to get all of this done.

Normally these modules are daisy chained together in the dozens or more. The output jacks connect to the input jacks on the incomming modules next in line. However, the first input jack normally goes to a "receiving board". I don't have this board but trying to have my client ship one to me to look at. This may be the missing link in how this is done. This board then sends out the R1A, R2A, R1B, R2B, G1, G2, B1, B2, CLOCK, LATCH, /OE and GND signals to the first input jack. Some kind of controller is on this "receiving board" to do this PWM. It also has Ethernet and would then normally goes to a "Full Color" controller card that plugs into a PCI slot on a PC. It has Ethernet input jacks, DVI connectors to plug into the PC's DVI connector and so on.

I am trying to (I guess) tap into the these modules and somewhat replace the "receiving board" and maybe the "Full Color" controller card.

Since simple SPI data is being pushed through the cascaded modules, it is very possible to do this with a micro-controller. However, it may need something more robust than a Parallax SX28 or SX48 chip for PWM, RAM, Eithernet(?), other features, etc..

This is where my delema is. I hope I have explained it better now.
 
hi, do you mind if I ask how much these modules are - and where from, as itd be so much easier if i had one to play with - and who knows id quite like a video wall :D

have you looked at microElectronica BASIC, it is a basic compiler for the pic, would let you stick to a language your used too. but for the time critical bits you probably need some inline assembler. i assume your sx is something like a basic stamp, where the code is interpreted on the chip. mE compiles to native pic code. you can download a demo from their site, limited to 2k program on the demo - which is quite big.
 
There is NO pwm on these modules, the only way to set the brightness of each individual led (colours) is to turn them on and off in quick succession through your spi.

your spi can run at up to 25MHz, so thats more than enough, so its basically down to the software.
 
Status
Not open for further replies.

Latest threads

New Articles From Microcontroller Tips

Back
Top