Capability of Serial Comm.

Go To Last Post
15 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I am designing a RGB array. I am currently planning on using attiny2313s to control 4 RGB leds a piece. Each one basically running 12 software driven PWM channels, one for each R, G, and B LED.

I was thinking of hooking 25 or so of these 2313's up on the same UART. A master uC can send out a two byte message for every one of the 100 or so LEDs. One addressing the individual LED, and the other to specify a 256 value color.

The hardware UART and Interrupt on each of the 2313's will process the LED ID and ignore everything except for the 4 leds it is responsible for. If the message happens to address one of its leds it will process the second byte and set the PWM values accordingly.

My question is whether with the 2313's running around 16-20Mhz and the controller uC running at that or a little faster, can an array of 100 or 200 leds / 25 - 50 2313's can be refreshed at a reasonable rate. I'm not sure what Baud Rate that can effectively been achieved. If anyone has any comments or suggestions regarding anything that I talked about I would really appreciate it.

Thanks!
Andy

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Can't you use the MAX6947ATE+ or something similar ? Small, programmable via I2C, 10 led outputs, no serial resistor per led needed, output current AND pwm programmable and an automatic fading possibility.
But not in an easy-soldering package and I2C is not very fast.
Is that maybe option for you ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I have looked into PWM LED Drivers, but the overarching theme with those are that they generally cost more and can control less LEDs than a 2313.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess your question of bandwidth is going to depend entirely on how often you need to update each LED. Obviously, in the absence of communcation telling it to change any LED can just continue display the last received RGB levels so it totally depends on the desired rate of change and will all 100 LEDs all be changing in every "frame time" ?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The idea is to display patterns on display where each pixel is about 3" by 3" that move to the music. so I guess 4 times per sec would be the absolute max. Can anyone think of a better communication structure?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

I guess my question is will the UART of the uC's get bogged down by this structure, and if so, is there a better structure?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to my computations, the setup requires
transmitting up to 16*100*4=6,400 data bits per second.
9,600 baud would seem sufficient.

Edit:
I missed a factor of 3 here: each of the 100 "LEDs" has 3 LEDs.
19,200 data bits per second> 9,600 baud.
A UART is still practical though.
IIRC 9,600 baud is slow lately.
Even so, 9,600 baud would almost work
if one dropped the address byte.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

Last Edited: Wed. Dec 3, 2008 - 09:06 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
6,400 data bits per second.
9,600 baud would seem sufficient.
Which would take about 6.4 seconds as each byte takes about 1ms.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

js wrote:
Quote:
6,400 data bits per second.
9,600 baud would seem sufficient.
Which would take about 6.4 seconds as each byte takes about 1ms.
You might want to fix your units: bit/sec != byte .

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:
bit/sec != byte .
:oops: Got confused, how unusual for me. :shock:

To unconfuse me I will talk about bytes. So 2 bytes per led takes about 2ms at 9600 baud, 100 leds will take 200ms or a refresh rate of 5 times per second. etc.

Now depending on how far the micros are apart you can go a lot faster. If the micros are metres apart and you use cable in between then you will need some kind of driver chip for faster data rates.

John Samperi

Ampertronics Pty. Ltd.

www.ampertronics.com.au

* Electronic Design * Custom Products * Contract Assembly

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

What is the issue with having the uC's far apart? And I could theoretically increase the baud up to Fosc/8 correct (assuming that number is at least close to a known baud)? I am planning on having the micros at most 2 meters apart.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

agoessling wrote:
What is the issue with having the uC's far apart? And I could theoretically increase the baud up to Fosc/8 correct (assuming that number is at least close to a known baud)? I am planning on having the micros at most 2 meters apart.
Capacitance.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

For the matrix (ie. simultaneously updating), it would be more efficient to send a start marker (preferably a reserved value), followed by all the pwm values. All the micros receive all the values, but a given micro stores only the 3-4 bytes for its assigned pixel, followed by another start marker.
When the start marker is received, the micros copy the stored value into the pwm generators, making them all update simultaneously. At 115kbps, with 200 leds * 3 values, this gives something like 29 updates per second.

The marker might just be a period of bus silence, or it could be a BREAK.

If you use the cheapest RS485 transceivers you can find, and add a (cable matching) termination resistor across the far end of the twisted pair cable, you should have no trouble running with ~1km of cable.

/Kasper

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

So a particular uC would just count the number of bytes received after the start char and only store the bytes that pertain to it?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

agoessling wrote:
So a particular uC would just count the number of bytes received after the start char and only store the bytes that pertain to it?
That is roughly the idea,
but the marker wouldn't have to be a char.
As mentioned, the marker could just be a gap in the byte stream.
If you use a 9-bit byte,
the marker could be a 1 in the high bit.
Making the marker a special 8-bit value could cause
problems if that value occurs as ordinary data.

"Demons after money.
Whatever happened to the still beating heart of a virgin?
No one has any standards anymore." -- Giles