33 replies to this topic

[sHINE]

Hi! I've just registered to the forums because I would like to evaluate the netduino for driving large led matrix-displays. I am a Software Architect using VB.Net as my main language and playing with these displays in my spare time using BASCOM (Basic-Compiler) and some Atmel Atmega's. Now that VB.Net has become available to the .net MF I would like to know if I could use this architecture to control my displays. Almost all industrial matrix-displays generally use regular shift-registers (i.e. HC595) for the columns and some 3-to-8 or 4-to-16 line-decoders for the rows. My problem is the speed of the bascom-compiler/the atmega chips. I'm not able to control a Bi-Color-Display (RG) larger than 64x32 because the data is shifted out too slowly to achieve an accurate framerate. The task itself is quite easy: Select first row, shift red/green data out, latch the registers and go on with the next row...This must be done as fast as possible to get the POV-Effect. Maybe there's someone who have some experience in driving these displays. I've read an article on how to drive a matrix using a maxim7221-chip but that's a completely different way. Thanks for any tips and excuse my weird english Jan

[Stefan]

Hi Jan, Welcome to the Netduino community! I have experienced a very high performance with only 74HC595s over the Netduino's SPI-bus. See this topic for schematic and code: http://forums.netdui...h-the-netduino/ There are also several other ways to run those IC's, with even a better performance perhaps. It's also possible to port the driver to VB, or just use a DLL-version in VB.NET. See this topic for a small how-to: http://forums.netdui...ivers-in-vbnet/ I never tried large LED displays though, mainly because I don't have one Your name, Jan, sounds Dutch. If you live close to me, and you have such a display already, we could try it out on my netduino in my workshop if you like. Would be a funny experiment!

[sHINE]

Hi Stefan, thanks for your answer, I'll buy a netduino soon and try to let my display's shine... I live in Germany so I cannot jump across the garden-fence to meet you But I would send you a small display (40x16, RG) using "easy-to-use" 1/16 scanning-mode so you can hook it up to your board and start playing around with it... Please PM me your address if you're interested. Would be great if you can support me with that, because my next task will be the implementation of a nice protocol to send data efficiently to the display...and I think that's anything but easy Regards Jan

[Stefan]

I live in Germany so I cannot jump across the garden-fence to meet you

Would be a big garden-fence Been in Germany a couple of times for the Cebit, lovely country! You know about the Embedded World-event next year? Big chance I'll be there.

But I would send you a small display (40x16, RG) using "easy-to-use" 1/16 scanning-mode so you can hook it up to your board and start playing around with it...
Please PM me your address if you're interested. Would be great if you can support me with that, because my next task will be the implementation of a nice protocol to send data efficiently to the display...and I think that's anything but easy

You got a PM

A nice protocol, do you want to have a text interface or pixelized interface?

[Nevyn]

Stefan, Would be interested in the results. Just started playing with POV in the last few weeks and found that driving the LEDs with a byte array was faster than my ShiftRegister class. Regards, Mark

[sHINE]

It should be a "pixelized" interface so I can control every pixel using a simple x,y,c command-scheme. Sure with some high-level-methods, i.e. DrawBitmap(byval bitmap as Bitmap) or DrawString(byval message as String)...

In Bascom I wrote some high-level-methods to light up a LED like this: SetLED(x,y,c) where 'c' is the color of the led.
Vice versa there's a function to get the state by calling GetLED(x,y) which returns the color of the LED.

By using this it's easy to implement some graphic-functions like the bresenham-algorithm etc... Here are some explainations of these: Bresenham's Line-Algorithm and Midpoint-Circle-Algorithm

Next step is to implement some pwm to allow grayscales but early test's just hit the capabilities of the atmegas, especially with some larger displays (64x32 RG)...There are other chips, like the TI TLC59116 or TLC5940 that can do the "PWM-Part" but that's out of scope now.

I will send you an old display that you may use to dive into the wonderful world of LED-Displays It uses a very easy connection scheme so it will be an easy task to display your first animations on it

Regards
Jan

[sHINE]

Hey Stefan, just connected two of my old display's to show you how it looks like Will send you one of them tomorrow. Cheers, Jan

Attached Files

•  IMG_1071-1024.jpg   79.15KB   58 downloads

[Stefan]

Looks very nice! Keep in mind that the TLC5940 is grayscale as far as I know, which implies that the leds can't have different PWM duty cycles, but all share the same.

[Mario Vernari]

Hi Jan, Stefan and Mark. About the project, I would point that the Netduino should drive in real-time the led matrix, at the same time the board should calculate some geometries. Stefan is right about the speed of the SPI, but there is the problem to scan the rows (if the columns are driven by a set of HC595). That would not work automatically, and it should be done via a dedicated thread. Let's write some number... Supposing a matrix of 64x32 led: bi-color means having 128x32 led matrix (cols x rows). The eye persistence forces a complete screen (i.e. 32 rows) to be complete in as low as 50ms (20Hz). The analog TV scan is 25Hz for EU and 30Hz for US. As Jan point, the rows are selected via a demux: 5-to-32. That means the Netduino should switch row-by-row every about 2ms. My experience tells that is too fast for the Netduino. A row-scan is *NOT* only a switch to the demux, but a preset for the stream that will be sent as the columns via SPI. Finally, the software should calculate the pixels in the same time... Instead I suggest a dedicated hardware for the led matrix, as any LCD does. Basically what you're looking for is the same as a normal graphic LCD module, but any of these have a chip doing the dirty work for you. The software has only to send trivial command as "setpixel", "drawrect", etc. You may try to do it with a normal microcontroller programmed with native code, so that will be very fast. Once you done it, there's no reason to touch it in the future. It will be a kind of "driver" and nothing more. Instead, the "artistic" stuffs should be managed with a Netduino, that is very easy to program. Cheers PS: before I'll die, I must visit Hamburg and Bremen!

[Nevyn]

That would not work automatically, and it should be done via a dedicated thread.

I've done some proof of concept work and it looks possible to do what I'm aiming for although the full project may prove taxing (but I have a contingency plan which won't add too much to the cost). Mind you, I'm only dealing with 8 banks of LEDs.

Regards,
Mark

[Stefan]

PS: before I'll die, I must visit Hamburg and Bremen!

Add Breda, The Netherlands to the list and you're most welcome. I owe you one for all the help you've given me in the past

I've done some proof of concept work and it looks possible to do what I'm aiming for although the full project may prove taxing (but I have a contingency plan which won't add too much to the cost). Mind you, I'm only dealing with 8 banks of LEDs.

I indeed would love to try, but without guarantees. I think Mario could have a good point. Especially when I look at his passed record; he knows much about things

[sHINE]

Keep in mind that the TLC5940 is grayscale as far as I know, which implies that the leds can't have different PWM duty cycles, but all share the same.

The TLC is not the problem, it's the fact that my displays are already assembled with simple shift-registers so I need to increase the number of cycles if I want some brightness levels. So for a small 8x8-matrix the interrupt must be called 32 times instead of 8 times to achive 4 brightness levels. That's possible with such a small display and an atmega but not with an 64x32 RG-Display where the number of cycles raises from 32 to 128...and that's not all: You must remember that you need to shift-out 64 Bits of red-data + 64 Bits of green-data between the cycles...

If I want to build a big display by myself I would use a special controller-ic that manages the multiplexing stuff.
I could use plenty of available chips for that...i.e. the MAX695x-Series from maxim or the TLC's or even an Atmega or a rainbowduino. All of them take care of the multiplexing and are easily controllable via an SPI or I²C-Interface.
In fact, the already-assembled displays in size 64x32 use the aforementioned HC595 and some line-decoders like the HC138 or 238 so we just need a "displaydriver"-duino that takes care of the multiplexing and provides an easy to use interface...
Maybe it's possible to use a netduino mini for each 64x32 RG-Display and develop a library with some "high-level" commands that does the communication with the mini's, maybe with SPI or I²C...

[Mario Vernari]

@Jan:
I completely missed the ability to control the brightness.
So you have a 64x32x2 led matrix, having 4 brightness level. That means at least 8192 bits, or 2K bytes, although it is an uncommon structure having 2 colored pixels for byte. Let's say a better architecture of 1 px per byte, so 4Kbytes.
Perhaps a arduino-like board will not fit so much memory.

Don't shoot at me, but I'd consider a microprocessor based management. I don't think the overhead would be significant as it could appear. Also should be a cheap way.

Add Breda, The Netherlands to the list and you're most welcome.

For sure, Stefan!
I've had a long holiday in NL about 15 yrs ago, and it was amazing!

However, for any of you is planning a trip to Venezia (or nearby), drop me an email: I'll give you some tip to enjoy the stay (and save money too)
Cheers

[Stefan]

The TLC is not the problem, it's the fact that my displays are already assembled with simple shift-registers so I need to increase the number of cycles if I want some brightness levels.

I see another possibility. The shift registers work from 2 to 5.5V. Perhaps toying with that can give a small brightness window. Led brightness can be defined by PWM but also by different currents.

Maybe it's possible to use a netduino mini for each 64x32 RG-Display and develop a library with some "high-level" commands that does the communication with the mini's, maybe with SPI or I²C...

That's something to look at. Indeed a mini as main display processor and the TTL serial interface to talk with, and putting all other logics in a normal Netduino. I can try that, got a couple of netduinos on my desk

However, for any of you is planning a trip to Venezia (or nearby), drop me an email: I'll give you some tip to enjoy the stay (and save money too)

Perhaps next year. In September I'm going to Turkey and in December I'm going to New York. A very nice guy offered me a couch in NYC.

[Mario Vernari]

I think it would be hard to manage the brightness-per-pixel within a matrix by using the PWM technique. Jan is right about a multipass-technique: it is easy and it requires no additional hardware. However the driver must be fast enough. There is another consideration about the led driver. Normally a led is light flowing as low as 10mA, but it may takes even 50mA. Well, also depends on the led type. Anyway, since here is a multiplex circuit, the matrices' rows and columns need a stronger current than a simple IC can afford. As in the usual example of 64x32x2 leds, the frame refresh could be at 20Hz. However, it will be 80Hz because the 4x overscan for the brightness: that is 12.5ms for every vertical pass. At this point, the time should be divided into 32 slices, so about 390us. Supposing to want a led at full-brightness (equivalent at 30mA static), we must feed at least 30mA*32 = 960mA peak for every single column! I don't think this project would be as easy as a walk in the park! Cheers

[Stefan]

Should the brightness be defined per pixel or per display? Just wondering Indeed, it wouldn't be easy, and perhaps not even possible, but we can't know for sure without trying I suppose

[Mario Vernari]

If I understand well, Jan wish to control the brightness per-pixel. His idea is very good: the "PWM" should act in the "third dimension"... Suppose you want to display half of the matrix at full-brt, and the other half at 50%. If you want a vertical scanning frequency at least of 20Hz to avoid flickering, the trick is to scan much faster, let's say 4x, so 80Hz. So far, every "nominal frame" is composed of 4 physical frames. When you render the 1st and the 2nd frames, all the leds should be turned on. During the 3rd and the 4th frame, only an half has still the leds shining. The overall effect is an half at 50% of brightness, due the eye persistence. About the hardware driver, Jan didn't point how is, or whether that is his own task to solve. I understand that the led modules are pre-built, so the hardware driver should be already present. I don't want to dig further, but it was a point about the relatively high current need for each led. The led *must* be driven by a transistor or a fet, by using a proper circuit pattern to limit the components overheat (leds included). Cheers

[Nevyn]

That's something to look at. Indeed a mini as main display processor and the TTL serial interface to talk with, and putting all other logics in a normal Netduino.

That's what I was thinking about as a contingency - if the mini did not work then another board ending in uino was my thought.

Supposing to want a led at full-brightness (equivalent at 30mA static), we must feed at least 30mA*32 = 960mA peak for every single column!

I suppose a question for Jan - do the boards you are working with have the shift registers and decoding logic built in?

If they do then surely the manufacturers have taken the power loads into consideration and this problem becomes one of driving the data into the board at the right rate to achieve the results.

Regards,
Mark

[sHINE]

Hey guys!

Your're right, the display's are fully assembled with proper FET's (FZT751) to handle the higher current.

Please take a look at the following code snippet. It's written in Bascom and allows controlling an 8x8 RGB-Display with a simple 2-Bit-Pseudo-PWM without external logic (except the led-drivers for sure). Maybe this explains better what I mean in my previous posts Sorry but it's in German, hope you understand it a bit...

Regards
Jan

btw. Stefan, Display is on it's way...(Hermes)

'*** Version 0.2 - 16.01.2008
'*** by Jan W.
'*** Hardware: 1x ATMEL ATMega32 / 64x RG-LED - Display
'*** 4x 74HC595 8-Bit Schieberegister

'*** Release-Notes:
'*** Fehler im Array-Zugriff in Zeile 97 behoben (Array's 1-basiert) = Aktueller_pixel => Pixel_array(led + 1)
'*** Fehler im Bitzugriff in Zeile 101 behoben (Ab zweitem Durchlauf led > 7, somit kein Zugriff auf einzelne Bits möglich) => Led1 = Led Mod 8
'*** Code ist getestet und funktioniert!
'*** ES IST NOCH KEINE SCHNITTSTELLE NACH AUSSEN VORHANDEN!
'*** DAS DATA-ARRAY MÜSSTE MAN VOR DEM TEST AUCH FÜLLEN (ARRAY IM EEP ABLEGEN, BEIM START KOPIEREN)
'--------------------------------------------------------------------------------------------------


$regfile = "m32def.dat" ' specify the used micro
$crystal = 16000000 ' used crystal frequency
$hwstack = 64 ' default use 32 for the hardware stack
$swstack = 64 ' default use 10 for the SW stack
$framesize = 64
$baud = 9600
'Die Fuses des ATTiny2313 auf 8MHz interner Oszillator stellen und Clockdivision ausmachen
'Gesetzte Fuses: SPIEN / SUTO / CKSEL3 / CKSEL1 / CKSEL 0

'Die Pins für die serielle Kommunikation festlegen...
Ddrb = &B00011111

Sr_clk Alias Portb.0 'SHIFTOUT CLK-Pin = CLOCK
Sr_set Alias Portb.1 'SHIFTOUT STROBE-Pin = Strobe, Latch out
Sr_pin Alias Portb.3 'SHIFTOUT DATA-Pin = Serial In
Sr_oe Alias Portb.2 'SHIFTOUT OE-Pin = Output Enable
Sr_clr Alias Portb.4 'SHIFTOUT SCLR-Pin = Serial Clear


Sr_oe = 0 'Output immer an, nur zu Testzwecken
Sr_clr = 1 'Serial Clear immer disabled, nur zu Testzwecken

'Jede Menge Variablen definieren...
Dim Erste_led As Byte 'Start-Pointer für den Array-Zugriff
Dim Letzte_led As Byte 'End-Pointer für den Array-Zugriff
Dim Led As Byte 'Gerade aktive LED
Dim Led1 As Byte 'Hilfsvariable für Bitzugriff in LED-Schleife
Dim Aktueller_pixel As Byte 'Enthält den Pixel, der gerade verwurstet wird
Dim Rot_out As Byte 'Ausgabe-Variable der roten Pixel einer Zeile
Dim Gruen_out As Byte 'Ausgabe-Variable der grünen Pixel einer Zeile
Dim Blau_out As Byte 'Ausgabe-Variable der blauen Pixel einer Zeile
Dim Farbe As Byte 'Gerade aktive Farbe
Dim Farbe_out As Byte 'Bearbeitungs-Container für die aktuelle Farbe einer Spalte
Dim Durchlauf As Byte 'Durchlauf der Spalte (immer 4x für 2-Bit-PWM)
Dim Spalte As Byte 'Gerade aktive Spalte
Dim Spalte_out As Byte

Dim Pixel_array(64) As Byte

Pixel_array(1) = &B01000000 'RRGGBB00
Pixel_array(2) = &B10000000
Pixel_array(3) = &B11000000

Pixel_array(5) = &B00010000
Pixel_array(6) = &B00100000
Pixel_array(7) = &B00110000

Pixel_array(19) = &B01010000
Pixel_array(20) = &B10100000
Pixel_array(21) = &B11110000


Do

Erste_led = 0 'Erster zu lesender Array-Eintrag
Letzte_led = 7 'Letzter zu lesender Array-Eintrag
Spalte_out = 1 'Wir fangen in der 1. Spalte an '1

For Spalte = 1 To 8 'Acht Spalten '1 to 8
For Durchlauf = 1 To 4 'Vier Durchgänge pro Spalte = 2 Bit-PWM
For Farbe = 0 To 4 Step 2 'Es werden immer R/G/B für jeden Pixel ermittelt
For Led = Erste_led To Letzte_led 'Und zwar immer eine Farbe für alle 8 LEDs, dann die nächste Farbe

Aktueller_pixel = Pixel_array(led + 1) 'Ersten Pixel aus dem Array holen
Rotate Aktueller_pixel , Left , Farbe 'Verschieben, damit die gewünschten Bits vorne stehen
Aktueller_pixel = Aktueller_pixel And 11000000 'Nur die ersten zwei Bit maskieren

Led1 = Led Mod 8 'Quadratischen Rest errechnen, um Zugriff aufs korrekte Bit zu gewährleisten

Select Case Aktueller_pixel
Case &B00000000 '0% Helligkeit - nie an
Reset Farbe_out.led1
Case &B01000000 '25% Helligkeit - nur beim 1. mal an
If Durchlauf = 1 Then 'Beim 1. Durchgang wird das Bit gesetzt, sonst nicht
Set Farbe_out.led1
Else
Reset Farbe_out.led1
End If
Case &B10000000 '50% Helligkeit - beim 1. und 3. mal an
Select Case Durchlauf
Case 1 : Set Farbe_out.led1 'Im 1. und 3. Durchgang leuchtet die LED, im 2. und 4. nicht
Case 2 : Reset Farbe_out.led1
Case 3 : Set Farbe_out.led1
Case 4 : Reset Farbe_out.led1
End Select
Case &B11000000 '100% Helligkeit - immer an
Set Farbe_out.led1
End Select
Next Led 'Für die anderen 7 LEDs der Spalte wiederholen

Select Case Farbe 'Ermitteln, welche Farbe bearbeitet wurde
Case 0
Rot_out = Farbe_out
Rot_out = Rot_out Xor &B11111111 'Entsprechendes Byte schreiben 'Hier xor'ed, da coloumn-anode display
Case 2
Gruen_out = Farbe_out
Gruen_out = Gruen_out Xor &B11111111
Case 4
Blau_out = Farbe_out
Blau_out = Blau_out Xor &B11111111
End Select

Next Farbe 'Für die zwei weiteren Farben wiederholen

Shiftout Sr_pin , Sr_clk , Rot_out , 0 'Das Schieberegister befüllen
Shiftout Sr_pin , Sr_clk , Gruen_out , 0 'MUSS NOCH GENAU FESTGELEGT WERDEN!
Shiftout Sr_pin , Sr_clk , Blau_out , 0
Shiftout Sr_pin , Sr_clk , Spalte_out , 0

Set Sr_set 'Den Schieberegister-Inhalt aktivieren
Waitus 100 'MUSS NOCH GENAU FESTGELEGT WERDEN!
Reset Sr_set

Next Durchlauf 'Jede Spalte 4x anzeigen (für 2-Bit-PWM)

Erste_led = Erste_led + 8 'Die Pixel der nächsten Spalte wählen
Letzte_led = Letzte_led + 8

If Spalte_out < 128 Then
Spalte_out = Spalte_out * 2
Else
Spalte_out = 1 '1
End If

Next Spalte 'Und den ganzen Zauber mit der nächsten Spalte veranstalten....

Loop 'Für immer!

End 'END sollte man immer fein (passend!) einbauen,
'ansonsten kann sich das Programm schonmal komisch verhalten!

[Stefan]

I can't speak nor write German, but it looks a bit like my native language when reading it I see that's an RGB display, so 3 leds per pixel actually. Curious how it will work out, but I'm pleased to give it a try!