To make the experience fit your profile, pick a username and tell us what interests you.
The goal of this Project is to build a very tiny 8x8 RGB LED Matrix. This Matrix will be controlled by UART and/or i2c (not decided yet). Beside this there will be some "demo-Modes" for a standalone operation. The PCB for the LEDs and the firmware of the used Microcontroller are part of this project. There will be also documentation available about the the protocol used to control this Matrix.
[Image: Rendered project idea on a US quarter Dollar coin. made with sketchup]
For another of my projects ( #384:LED) I did order the wrong LEDs. So I do have now some of these tiny 0404 RGB LEDs left over:
These LEDs and my wish to design a four Layer board was the motivation to start this project. On the board there will be at least a microcontroller to control all LEDs and perhaps some other stuff to make it smarter.
To control all 192 LED chips individually I use normal multiplexing. The Matrix is divided into 16 row with 16 (=3*4) columns. Both a directly connected to the Microcontroller (yes I know this is NOT the best way, but very space effective). There is also no current limiting for the LEDs so the on pulses are to be short.
As mentioned the Matrix is organize in 16 lines and 4 columns. The order of the columns are inverted for the lower half of the rows. In the following figure you can see how the physical 8x8 Matrix is mapped.
Organisation of pixels [ROW, COL]: [0,0] [0,1] [0,2] [0,3] [ 8,3] [ 8,2] [ 8,1] [ 8,0] [1,0] [1,1] [1,2] [1,3] [ 9,3] [ 9,2] [ 9,1] [ 9,0] [2,0] [2,1] [2,2] [2,3] [10,3] [10,2] [10,1] [10,0] [3,0] [3,1] [3,2] [3,3] [11,3] [11,2] [11,1] [11,0] [4,0] [4,1] [4,2] [4,3] [12,3] [12,2] [12,1] [12,0] [5,0] [5,1] [5,2] [5,3] [13,3] [13,2] [13,1] [13,0] [6,0] [6,1] [6,2] [6,3] [14,3] [14,2] [14,1] [14,0] [7,0] [7,1] [7,2] [7,3] [15,3] [15,2] [15,1] [15,0]
This is looking a little Bit strange but made the layouting much easier (or maybe also possible).
Beside the Microcontroller and the LEDs there are not much more Parts:
Talking about programming: All pins needed for the ISP are break out on test pads. For programming R1 (more a solder bride than a resistor) needs to be open, other wise the Programming signals could drive some LEDs. This could disturb the programming. But with R1 open all programming signal are not connected to anything or just to a cathode of a LED.
The PCB is square with 677,5 mil or 17,2085mm edges. This makes the PCB fit nearly on a quarter US-Dollar coin as seen in the image at the top ( I will also make test with Euro-coins, but there were not available as models in Sketchup). The LEDS are in a 85 mil (~2,16 mm) grid. The dimension are measured in a way that multiple PCBs can get used to built bigger display. On the backside is the microcontroller. I am planning to use a ATmega 16/32 or compatible newer AVR like the ATmega 324.
I am planing to use UART for controlling this Matrix from some Master Device, but first I will run it stand alone. There are also both pins of the i2c bus as test pads available.
Well, this is still to do....
I will publish the whole project under the CC BY-NC-SA 4.0 license. So this project qualifies not as open Hardware as the OSHWA defines it, because I decided to add the NC (=non commercial) tag. I wanted to publish it only for non commercial use. If you would like to use this in any commercial way, please contact me.
In the Github repository you will find additional files for this project.
Portable Network Graphics (PNG) - 111.50 kB - 05/03/2016 at 18:33
Follow-Up /Redesign here: #192:LED redesign
Today I saw a new chip: The IS31FL3733. It is a 192 Led matrix driver. So far it looks like designed for 192:LED. The big improvement over the microcontroller would be: Some real current limiting, which would end up in more consistent brightness; not programming needed (i2c interface to main/host controller); simpler circuit maybe. And you could control more than one 192:LED-module over the same i2c Bus.
I am thinking of changing the PCB design to fit with this driver IC.
In the last log I wrote about a quite complicated way to load images to the display. I now have improved the octave script. it no loads the image itself to the display:
This is done by using the instrument-control package of octave:
function IMG_test pkg load instrument-control if (exist("serial") != 3) disp("No Serial Support"); endif myImage = imread("image.png"); #read 8x8 pixel image # the image is vreatet with MS paint. At least there each # pixel is encoded into three bytes (R,G,B) this could be # normal for png. At least I hope so # now to the conversation magic red = uint8(bitshift(myImage(:,:,1), -5)); green = uint8(bitshift(myImage(:,:,2), -5)); blue = uint8(bitshift(myImage(:,:,3), -5)); #add the three colors to one byte togehter img8trueColor= bitshift(red,5) + bitshift(green,2) + blue; #transpose the image - needed to save it correctly img8trueColor=img8trueColor.'; #write it to display direct in octave no more a file output s1 = serial("\\\\.\\COM12"); set(s1, 'baudrate', 38400); srl_flush(s1); srl_write(s1, img8trueColor); endfunctionThe source code is also in the github repository.
helpful links for octave and uart:
http://wiki.octave.org/Instrument_control_package
http://www.edn.com/design/analog/4440674/Read-serial-data-directly-into-Octave
http://projectsfromtech.blogspot.de/2015/03/serial-port-communication-with-gnu.html
WARNING: This will get some more and complicated...
I did broke out the RX pin on the PCB to get the possibility to sent images over UART to the display. And this is now also working. I also want to offload most of the processing to the UART sender (now just a PC with USB-UART bridge, but later perhaps some master Microcontroller/FPGA) . So I decided to just send the image as it is also coded internally:
The UART part was made fast and easy, but getting the needed data was complicated. I found no graphic program which saves images in 8 bit true color. So I decided to script some matlab/octave to that:
function IMG_test myImage = imread("image.png"); #read 8x8 pixel image # the image is vreatet with MS paint. At least there each # pixel is encoded into three bytes (R,G,B) this could be # normal for png. At least I hope so # now to the conversation magic red = uint8(bitshift(myImage(:,:,1), -5)); green = uint8(bitshift(myImage(:,:,2), -5)); blue = uint8(bitshift(myImage(:,:,3), -5)); #add the three colors to one byte togehter img8trueColor= bitshift(red,5) + bitshift(green,2) + blue; #show the reult (just for visual inspection) imshow(img8trueColor); #transpose the image - needed to save it correctly img8trueColor=img8trueColor.'; myFile=fopen("out.txt", "w"); fwrite(myFile,img8trueColor); fclose(myFile); #{ The out put file now should look like this: 07 E0 00 1A 1A 1A E0 1C 07 E0 00 1A 00 1A E0 1C 07 00 00 1A 1A 1A 00 1C 07 00 00 1A 00 1A 00 1C 07 00 23 00 F2 F2 00 1C 07 00 23 00 00 F2 00 1C 07 00 23 00 00 F2 00 1C 07 E0 23 23 00 F2 E0 1C The first eigt bytes (first line) are the top line of the display also. #} endfunctionThis small script is some kin of user unfriendly, but working. My workflow now is:
So now some result and images:
This is my in step 1 created image:
My octave script create me now this file:
07 E0 00 1A 1A 1A E0 1C 07 E0 00 1A 00 1A E0 1C 07 00 00 1A 1A 1A 00 1C 07 00 00 1A 00 1A 00 1C 07 00 23 00 F2 F2 00 1C 07 00 23 00 00 F2 00 1C 07 00 23 00 00 F2 00 1C 07 E0 23 23 00 F2 E0 1C00 is black; 07 is blue; 1C is green and so on.....
After sending this to the display the display looks like this:
The colors are at least similar as in the original image. Maybe I will add some kind of color correction to the octave script.
So with a fas enough master device, which has lots of (or multiplexed) UART outputs and some more image (or video) software on it, I could now build big displays with this.
After some rework it is now working. There was also something wrong with the 0201 Capacitors. They are the load capacitors for the crystal. Maybe just the value was wrong. But it also works without them, so I did no further investigation yet.
The missing red LEDs on the picture are because the one red column is not connected. This is because the IO pin is shared with MOSI. To activate them I have to bridge a jumper and this is not done.
Next will be to add some annimations or adding a controll interface.
Just a quick update. The top side with it's 64 RGB LEDs is also soldered:
The Grid in the background is 1mm. I hope it will work. But to test that I have to write some firmware first. I made A video while placing and soldering, maybe I will made a Timelapse video of that.
The bottom side is soldered. It was quite difficult to get the 0201 capacitors (the two next to the crystal) soldered correctly. The dimension of crystal is 2 x 1.6 mm.
Next Task is to solder the to side with its 64 RGB Leds. But I will not do that today. One side a day extreme soldering is enough. And then I hope it will also work.
What is the cheapest way to get Microcontrollers? Well desolder them from other boards is often quite cheap. A suitable Controller is also on the MMMR-70 radio Modules. I bought ten of them some time ago (see #Yet another MMR-70 project). And for 0.7€ you can not get a new ATmega32.
You should only take care about the fuse settings of the controller. I did reprogrammed them to default before desolder the ATmega from the MMR-70 board.
Both was in the mail today:
The board does look really similar (beside of the color) to the rendering a made before:On the left is a photo the right is the rendering. Luckily I found a real ¼US$ coin at home.
Create an account to leave a comment. Already have an account? Log In.
There is is no real current limiting. Because of the multiplexing the LEDs are pulsed. In this way they are also capable of more current. There will be also some current limiting caused by the maximal drive strength of the IO-pins of the Microcontroller.
[this comment has been deleted]
well, that could be a problem, if you run it at full brightness over longer time. I am planning to dim the LEDs so far down, so that heat is not a problem.
You want to be careful on the break out as the solder mask is less accurate especially for cheaper board houses. So they use a larger solder mask opening around the pads to compensate for it. Parts of the breakout traces might also be exposed. If your breakout are off at an angle, that might pull the LED off a bit during reflow due to surface tension. e.g. There are a few that have a via off at the corner.
Thanks for your advice!
I will consider this during the further design progress. If I understand you right it would be better to place a via in the centre of a pad than in a corner. For some vias it will be also possible to place them off the the pad, because the vias will get smaller.
Don't put vias in pads. Solder can get sucked into vias or flux trapped in vias and they bubble off the solder. Also leave 10 mils tracks (or whatever board house say) between the via and pad. They need a minimum width of stop mask.
You want all the breakouts traces to be the same. Either go out diagonally or 90 degrees. Choose one and be consistent so that the all pull the same way. Any of them off at an angle, then the force is not balance and your LED might not line up with the others.
For a display project, that wouldn't look good.
if you are talking about 768:LED, this will be possible with using four 192:LED. I am planing to make them so small that you can attach multiples together without disturbing the grid of the LEDs.
Well and I think I can bring you four till the next Berlin Maker Faire.
to follow this project and never miss any updates
How is the current limiting for the LEDs done?