LED Cube - which AVR?

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

Hey Freaks,
two friends of mine and I want to build a big LED cube
I already build a 3x3x3 with a mega16. The big one will be controlled with a PC programm. My mates study informatics and will programm some cool stuff like equalizer and easy animation making.
My part will be to design the electronic parts and programm a µC.

The interface between µC and PC will be a buffer with multiple pictures stored. Let's say we use 2 color LEDs and 10x10x10. So every picture will use at least 2000 bit. Adding stuff like color mixing and brightness will increase the data.
To get 25 pictures per second the minimum datarate would be ~ 6kB/s or 50k Baud. We prolly need more.

I'm thinking about three solutions:
1.) use USB/RS232 converter chip, place it near a Mega and run his USART insanly fast.

2.) use a USB AVR

3.) get a NGW100

A) one MCU to controll all

B) one MCU controlls the Cube and reads the RAM chip. Another MCU talks to the PC and writes stuff to the RAM. Both communicate with each other to take care of:
- where is the write pointer?
- who has access to the RAM chip?

I'm not sure which way to go. I'll definatly need some serial/parralel shifters plus ULN's (or equal) to drive the cube. Or I'll get some "all in one" LED drivers, I'll see.
Anyway, 8 Bit MCUs should do the job, shouldn't they?

All thoughts welcome :)

PS: We'll have like 4 weeks vacation and say ... 300 euro. LEDs will be 2 color. Don't want to pay more than 10ct per LED

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

Nephazz,

At what rate will you need to change the LEDs?
What is an LED cube?

A

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

Andrew, google led cube, or better yet search youtube for it. Basically it is an cubic matrix of LED's. Makes for a very interesting art display piece.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

glitch,

Cool !!! :D

What determines the display?

A

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

This is not the first recent thread on this. Try a simple Forum search for "led cube"...

https://www.avrfreaks.net/index.p...
https://www.avrfreaks.net/index.p...
https://www.avrfreaks.net/index.p...
...

You can put lipstick on a pig, but it is still a pig.

I've never met a pig I didn't like, as long as you have some salt and pepper.

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

Hi andrew,
feel free to read my initial post again.

[edit]
Thanks for the links, theusch.

Last Edited: Mon. Jan 26, 2009 - 01:43 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

If you have a 3x3x3 working, then just make 27 of them, driven by a master that has a comm link to the PC.

Jim

 

Until Black Lives Matter, we do not have "All Lives Matter"!

 

 

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

Do you know how many LED's they use for the cube on the video?

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

16x16x16

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

well actually it's 16x16x16x3 as they have RGB LED's running. All I have to say is that I wouldn't want to be the pour soul that had to wire/solder that mess up!

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

16 rgb is definatly tough. I guess we'll stay with 9x and 2 colors. Soldering will be done with at least three people.

What do you guys think about the "RS232/usb chip near MCU and run USART insanly fast" to get the communication done?
Ship it or go ahead and learn to use USB AVRs?

@Jim: I consider this idea, would be definatly cool to build a 28 MCU bus :)

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

Before you deside how to do it you should:

Find a way to multiplex the LED's and match that to
the 3D of the cube so LED's in a row can share one pin, etc.
that will save a lot of time.

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

I wonder how these cubes are mechanically constructed
and what sort of wiring/multiplexing they use.

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

Most cubes use normal multiplexing... each level has a single common. And then each vertical row of LED's have the other LED pole as a common. One might be able to do it with charlieplexing, but I imagine that that will result in even more vertical wires, but fewer actual connections to the micro.

Also due to the very high number of LED's charlieplexing becomes more difficult, as you'll need to drive many LED's in parallel, to avoid flicker.

[edit log]
corrected some confusing wording

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

Last Edited: Mon. Jan 26, 2009 - 10:26 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

An other way would be to spin a 2D 'thing'.

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

glitch'

charlieplexing?

I will google it.

A

EDIT: Would this be a practical solution to driving 4096 LEDs?

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

oh no, I'm not going to charlieplex a 9x cube. It's definatly a cool and sophisticated way to save losts of pins. But the wiring will hurt my head and hands a lot.

@Sparrow: yeah those spinning displays are really beautifull. I'll definatly have to build one some day :)

[edit]
right now I'm thinking about what's the best way to produce a controlled pulse (PWM) at the row (Vcc) connections. For the purpose of controlling brightness and mixing the two colors.
Bruteforce would be some insane number of interrupts but this won't do I guess.

Building 27 3x3x3 cube could help here. Problem will be how to connect them physically. (no electric connection)

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

I was atually thinking about something that solve your dice when I talked about a spinning thing.

This is just a wild idea but if you place 4096 optical fiberes with one end where the LED's should be (for test I would use something like the "hair" that change color on some figures).
And put the other end in a matrix that get its light form a overhead projecter.
If that worked you could make 16 16x16 pictures on your PC and get them showed as a dice.

Maybe it could be done with just mirrors

Don't ask my how to do it it's just an idea that could be cool looking and easy to control :)

Have fun

Jens

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

Nephazz,

It may be worth having a look at the drivers from Supertex. They may solve some of your multiplexing issues.

A

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

thanks for the hint, I'll take a look.

Idea for discrete PWM:
- build 8 different PWM sources (12.5 %, 25 % ...)
- connect each source via one transistor to a each row
- switch the transistors via SIPO shift regs
- controll the shifters with other shifters

For a 10x two color cube that would use only:
- 26 µC pins
- 225 shifters
- about 1600 transistors
- about 3200 resistors

Well, I'll definatly have a look at those LED drivers and think about how to physically connect multiple cubes.

Last Edited: Tue. Jan 27, 2009 - 07:16 PM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

andrew99 wrote:
glitch'

charlieplexing?

I will google it.

A

EDIT: Would this be a practical solution to driving 4096 LEDs?

It could be, but it depends on what your display goal is. If you only ever light a small number of LED's at a time, then it could be. But if you need to scan the entire grid to display arbitrary images, then probably not.

For the 4096 LED example. One would need 65 control lines to address the 4096 LED's. With charlieplexing you can have, at most, 64LED's lit at any given moment. That means for 4096 LEDs, each LED will receive a 1/64 duty cycle, when the matrix is scanned. In most circumstances this is likely too low of a duty to be practical for anything more than a few bits of intensity information.

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

whoops, I ninja-edited my post

PS: with a phase shift between ever PWM source one could combine them to get more brightness values.

[edit]
note to myself: some chip with SI or PI and power PWM out

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

Unfortunatly I can't find a suitable LED driver. I need one which produces a lot of independant PWM or constant currents. I'm not sure if I understand the datasheets properly, though.

My current plan is this:
Build a 10x10x10 cube with 10 layer (GND) and 100 row (Vcc) connections. They get switched via Transistors.
A set of ... say 10 AVRs split the controlling of the rows. They are all connected via RS485 and operate as slaves. The rows are driven via PWM. The signal which Layer is currently "on" lies in the RS485 signal. Say:
- Byte0 received: L0 active
- Byte1 received: L1 active
- ...
- Byte9 received: L9 active
- Byte 10 received: L0 active
- ...

The RS485 Master is a ATUSBxxx. He is connected to a PC and to a SD card. He tells the slaves which LEDs are turned on and in which color.
He has two operation modes:

- get a datastream from a PC programm
- read the pictures out of a SD card

The SD card will be an upgrade. No real questions in this post but any thoughts are welcome :)

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

Forget the AVRs and use an XMOS chip:

http://www.xmos.com

It's one of the applications they were designed for:

https://www.xmos.com/technology/applications/intelligent-led-display-control

Leon

Leon Heller G1HSM

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

the description sound very nice ... I wonder if I should go the:
- Interface Controller = Mega w/ FTDI & RS485 (DMX)
- LED Controller = XMOS

I'll edit this post after reading a couple of datasheets :)

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

If you "only" need 1000 LED I would look into a way not to multiplex !
If you use a 4094 74HC4094 or xxx4094 you should be able
to run 1 LED pr output and the only thing you need to
add will be a resistor pr LED.
And yes you will need 125 chips (about $20 for all of them).
Hook them up as one 1000 bit shifter to the SPI on the
AVR.
If you shift with 1 MHz you can update every 1 ms.

Jens

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

Remember this is a cube, so you are proposing he have 1000+ vertical wires? Simple multiplexing reduces that down to 110 vertical wires. charlieplexing reduces the verticals even further, at the expense of more complicated internal wiring.

The XMOS suggestion is an interesting one, but my opinion is that the XMOS chip is overkill for this scenario. Besides this is an AVR forum, so let's keep the suggestions AVR based. (an AVR is perfectly capable of driving this size of matrix)

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Problem is: Putting the $100 XMOS demo PCB into the cube would nearly double its cost. (like $150 for 1000 two color LEDs and some bucks for misc)
plus: having a bunch of micros hooked up on a bus is always cool^^

using a 1000 bit shifter would definatly be worth soldering 125 sockets, but not 1000 wires and building a cube of 1000 isolated LEDs. In fact it would be 250 chips and 2000 wires -.-
But maybe I could go with only one AVR and some shifters to expand his I/O.
Comes down to:
- build a bus and sync the Layer displaying
or:
- use one AVR and 12 SIPOs but mess around with producing good PWMs at the end of the shifters.

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

Quote:

1000+ vertical wires

It depends.
It's just one long chain.
That way you don't need any high current parts, and no problems controlling the PWM levels etc.
I would make a narrow PCB to carry : + GND Data CLK strobe, and a place to solder the 8 LED's pr chip.

But yes this is just one way to do it :)

And yes 8 is a bad number for 10x10x10

Jens

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

Nephazz wrote:
Problem is: Putting the $100 XMOS demo PCB into the cube would nearly double its cost. (like $150 for 1000 two color LEDs and some bucks for misc)
plus: having a bunch of micros hooked up on a bus is always cool^^

using a 1000 bit shifter would definatly be worth soldering 125 sockets, but not 1000 wires and building a cube of 1000 isolated LEDs. In fact it would be 250 chips and 2000 wires -.-
But maybe I could go with only one AVR and some shifters to expand his I/O.
Comes down to:
- build a bus and sync the Layer displaying
or:
- use one AVR and 12 SIPOs but mess around with producing good PWMs at the end of the shifters.

It all depends how much your time is worth. The XMOS solution will save a great deal of time.

Leon

Leon Heller G1HSM

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

sparrow2 wrote:
Quote:

1000+ vertical wires

It depends.
It's just one long chain.
That way you don't need any high current parts, and no problems controlling the PWM levels etc.
I would make a narrow PCB to carry : + GND Data CLK strobe, and a place to solder the 8 LED's pr chip.

But yes this is just one way to do it :)

And yes 8 is a bad number for 10x10x10

Jens

well yes it is ultimately one long chain. The cube needs to be as "airy" as possible, so PCB's in the cube might be too much of a visual obstruction, killing the effect.

Also your current requirements will be VERY high. While you may not need any high current components (other than the power supply) you do need to transport an enormous amount of current through the cube. 1000x the individual LED current. So if he's using 20mA LED's.. that means he needs a 20A supply just to drive the LED's!

[note that he actually wants to use bi-colour LED's do the component, and current requirements are actually double]

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

Thanks for the tip. The XMOS chip looks way overkill to me, and fairly expensive, but quite likely simple to use. Essentially, it looks like a well implemented parallel design with event support, the sort that Propeller and Xmega begin to hint at. I'd get one for experimenting if I hadn't blown my device budget for the next few months already.

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

I built a 2D IR Led matrix a while back...

For control, I used the freeware program DMX-Control...
The matrix was physically quite large at about 3 x 3 meters with 64 clusters of IR leds...

It had a Tiny2313 running software PWM for 8 channels...
Each Tiny2313 received 8 DMX channels and output the PWM to 8 IR LED clusters...

If your going the DMX route, you would need multiple DMX universes as DMX will support upto 512 8bit commands per universe...

The USB to DMX converter is very simple, an FTDI chip with the drivers from the FTDI website...

Anyhow, the control program has nice plugin for RGB matrices...
I didn't use the plugin however as my LEDs were not RGB...
I could have used it if I rewrote the DMX interface to discard the 2 extra channels...

If you want the code and schematic, I can post it...
You can find some videos of it in action on youtube...
The video quality really negates the effect...
Might want to watch in HQ mode...
This was used at a club, with live music and projected onto the club wall with a DLP projector..
The video isn't from the club....
http://www.youtube.com/watch?v=0L_4gY14C0k

Michael

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

To glitch:
It a dice so no power wire need carry more than 10 LED
And if the pcb is about 2 mm wide it would work.
But the main benefit is no need for high power peaks.

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

@krazatchu:
yes, I'd like to see your schematics and code. We already thought about the "512 channels problem". One solution would be:
- save a bunch of animations on an EEPROM
- use DMX channels to tranfer command bytes. Like which animations, speed of picture change, order of animations, general brightness.
Or maybe my friends can tinker out some leet compressing which could be decompressed by the Interface controller which prolly will be a AT90USB1287, leaving enough calc power after driving the USB and internal RS485. If not: gosh, we already have a bus in it, lets put in a µC only for algo calc ;) ^^

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

while DMX is limited to 512 channels, it is only so due to it's specification. One could certainly adapt the DMX protocol to support more channels, or develop their own protocol from the ground up. The only downside is that you would not have any standard reference applications to test against, or use as reference.

Another thing to consider is, how many levels (bits) of brightness are you looking for at each LED?

DMX 512 as is could support:
4096 LED's at 1 bit/LED
2048 LED's at 2 bits/LED
1024 LED's at 4 bits/LED

Writing code is like having sex.... make one little mistake, and you're supporting it for life.

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

I think the easiest fix with the limitations of DMX is just to use more universes...
That lets you use whatever off the self control software you want...

Although, I have never seen any control software to intuitively handle 3D matrices, there are some very nice programs like Madrix and ArKaos that will do 2D...

Some DMX fixtures use 2 sequential 8bit channels to increase accuracy, like in moving lights...
But as glitch said, a custom interface can work too...
The DMX bus is also limited to 250kbs while the RS485 it's riding on can go up to 2MHz IIRC...

I'll wrap up the project in a zip and post it shortly...
The board was done in Eagle, the code in GCC...
The USB to DMX interface was the reference design from the FTDI website... It works with most DMX software...
You can find the schematic in a few places...
http://www.nextec.co.uk/Free-USB-DMX-Hardware-Project/Free-DMX-Project-Schematic-download.html
http://www.enttec.com/index.php?main_menu=Products&pn=70303&show=downloads
I'd recommend the newer FTDI232 chip, the RL not the BM as it doesn't require the EEPROM...
And the MAX487 parts are expensive compared to the 76SN176...

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

Here are the files, in a zip...
Some pics included...

I think these are the right files but I didn't organize them well...

On the schematic, I substituted some parts as they weren't in the lib...
I used the 76SN176 chip for RS485
The darlington array is a ULN2803
The xtal is 20Mhz...

Attachment(s): 

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

Here's a demo of the XMOS chip controlling an LED array.

https://www.xmos.com/content/videos

Leon

Leon Heller G1HSM

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

wow, that vertical pic looks nice :)

@Leon: yup, using a XMOS here is prolly like shooting missles at birds

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

While I know nothing of XMOS, I have to agree there must be something more ideal than using an AVR for every 8 channels..

In my case it was allright, with the design constraints and the spacing...
But with a cube I would think there must be some kind of i2c/twi led driver chip that would be more suitable...

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

Good news:
I've just found this beautiful app note :)

PS: M644 will be used for prototyping.

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

AVR136 is what I used to create the DMX to 8 channel soft PWM on the Tiny2313....

On page 2 of this thread you can find the complete project files...
You will notice the direct similarity between the example code for AVR136 and my project...

As it states in the appnote "up to 24 channels", but I think the PWM base frequency drops with each additional channel...
I may be wrong, it was a while since I did the calculations...
IIRC I was getting about 300Hz as the base frequency...

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

jupp, me too. (20 MHz / 0xFFFF)
Should be enough I guess .. but I'll definatly do some calc's and experiments soon