LED-Matrix DIY
Moderator: T.Hoffmann
Hallo,
ich habe mir vorgenommen eine 13x13 LED-Matrix zu bauen, wobei ich einen Mikrocontroller von Atmel benutzen wollte.
Ich habe mir bei Pollin.de das Atmel-Evaluations-Board bestellt, sowie ATMega32-16PU und ATMega644-20PU, um diese auf dem Board zu programmieren und zu testen.
Ich möchte Steuerung und Matrix auf 2 Platinen unterteilen, sodass ich die mit einem Flachbandkabel verbinde.
Gibt es schon vorgefertigte Schaltpläne oder sowas für die Steuerung?
Gruß
Finn
ich habe mir vorgenommen eine 13x13 LED-Matrix zu bauen, wobei ich einen Mikrocontroller von Atmel benutzen wollte.
Ich habe mir bei Pollin.de das Atmel-Evaluations-Board bestellt, sowie ATMega32-16PU und ATMega644-20PU, um diese auf dem Board zu programmieren und zu testen.
Ich möchte Steuerung und Matrix auf 2 Platinen unterteilen, sodass ich die mit einem Flachbandkabel verbinde.
Gibt es schon vorgefertigte Schaltpläne oder sowas für die Steuerung?
Gruß
Finn
- Beatbuzzer
- Auserwählter

- Beiträge: 3177
- Registriert: Fr, 17.08.07, 11:02
- Wohnort: Alfeld / Niedersachsen
- Kontaktdaten:
Soll die Matrix einfarbig oder RGB werden?
Bei einfarbig bräuchtest du 26 Anschlüsse mit Multiplexing.
Der Schaltplan ist recht einfach, einfacher als das dazugehörige Programm.
Je nachdem wie hell das ganze werden soll, reichen bereits 26 Widerstände und 13 Transistoren als nötige zusätzliche Bauteile aus.
Bei einfarbig bräuchtest du 26 Anschlüsse mit Multiplexing.
Der Schaltplan ist recht einfach, einfacher als das dazugehörige Programm.
Je nachdem wie hell das ganze werden soll, reichen bereits 26 Widerstände und 13 Transistoren als nötige zusätzliche Bauteile aus.
- Beatbuzzer
- Auserwählter

- Beiträge: 3177
- Registriert: Fr, 17.08.07, 11:02
- Wohnort: Alfeld / Niedersachsen
- Kontaktdaten:
Habe dir mal einen Prinip-Plan erstellt für eine 4x4 Matrix.
So sieht es dann auch für eine 13x13 Matrix aus, nur halt mit mehr LEDs.
Die Anschlüsse an den Widerständen müssen dann alle an den µC dran. Über die Transistoren wird immer eine Reihe LEDs aktiviert und über die einzelnen senkrechten Pfade wird die gewünschte LED in der Reihe angesteuert.
So sieht es dann auch für eine 13x13 Matrix aus, nur halt mit mehr LEDs.
Die Anschlüsse an den Widerständen müssen dann alle an den µC dran. Über die Transistoren wird immer eine Reihe LEDs aktiviert und über die einzelnen senkrechten Pfade wird die gewünschte LED in der Reihe angesteuert.
- Beatbuzzer
- Auserwählter

- Beiträge: 3177
- Registriert: Fr, 17.08.07, 11:02
- Wohnort: Alfeld / Niedersachsen
- Kontaktdaten:
Der Schaltplan stellt nur das Verdrahtungsprinzip dar. Die Werte stimmen nicht, das kommt auf die LEDs an und auf die Transistoren.
Und welche Transistoren du brauchst, hängt wiederrum von den LEDs ab. Mit BC547/548 oder BC337 kommt man evtl. schon hin.
Welche Ports du am µC belegst, ist hierbei relativ egal. Das kannst du ja später im Programm alles zuweisen.
Und welche Transistoren du brauchst, hängt wiederrum von den LEDs ab. Mit BC547/548 oder BC337 kommt man evtl. schon hin.
Welche Ports du am µC belegst, ist hierbei relativ egal. Das kannst du ja später im Programm alles zuweisen.
- Beatbuzzer
- Auserwählter

- Beiträge: 3177
- Registriert: Fr, 17.08.07, 11:02
- Wohnort: Alfeld / Niedersachsen
- Kontaktdaten:
VCC und GND also Pin 10 und Pin 11. Da müssen die 5V Versorgung dran.
Für den Takt reicht hier der interne Oszillator. Also bleiben XTAL1 und XTAL2 unbeschaltet.
Der Analogkomparator wird ebenfalls nicht benötigt, also bleiben AVCC und AREF ebenfalls offen.
Und an die Ports PA..x bis PD..x kannst du deine Leitungen zur Matrix ziehen.
Für den Takt reicht hier der interne Oszillator. Also bleiben XTAL1 und XTAL2 unbeschaltet.
Der Analogkomparator wird ebenfalls nicht benötigt, also bleiben AVCC und AREF ebenfalls offen.
Und an die Ports PA..x bis PD..x kannst du deine Leitungen zur Matrix ziehen.
Kleine Anmerkung...
Ohne zusätzliche Schalttransistoren musst Du die max. Stromstärke für den ganzen ATMega sowie diejenigen für einzelne PORTs beachten:
DC Current VCC and GND Pins 200 mA (PDIP) and 400.0 mA (TQFP/MLF)
PDIP Package:
1] The sum of all IOL, for all ports, should not exceed 200 mA.
2] The sum of all IOL, for port A0 - A7, should not exceed 100 mA.
3] The sum of all IOL, for ports B0 - B7,C0 - C7, D0 - D7 and XTAL2, should not exceed 100 mA.
Also mehr als etwa 3-10mA (3mA für die Transistoren und 10mA für die LEDs) pro Pin (an den 26 notwendigen Pins) geht nicht bei einem Standard PDIP Chip. 8 LEDs also über einen Vorwiderstand (berechnet auf 10mA Strom!) an PORTA, den 'Rest' kannst Du im Prinzip verteilen wie Du magst. Um die Software möglichst einfach zu gestalten würde ich noch 5 Outputs für die verbleibenden LEDs am PORTB vorsehen und 8 Outputs von PORTC sowie 5 Outputs von PORTD für die Transistoren verwenden.
Bei einer 13x13 Matrix sind bei dieser 'Standardbeschaltung' die LEDs auch immer nur 1/13 der Multiplexzeit eingeschaltet. Dementsprechend 'dunkel' sind die dann auch. Für reine 'Anzeigezwecke' reicht das bei hellen LEDs vmtl. immer noch, wenn das aber als 'Show-Beleuchtung' dienen soll, dann reicht es sicher nicht. Man kann bei einem duty cycle von weniger als 1/10 die LEDs problemlos mit 100mA Strom betreiben, aber dann sind natürlich zusätzliche Schalttransistoren für die 'senkrechten Pfade' in Beatbuzzers Beispielschaltung erforderlich.Je nachdem wie hell das ganze werden soll...
Ohne zusätzliche Schalttransistoren musst Du die max. Stromstärke für den ganzen ATMega sowie diejenigen für einzelne PORTs beachten:
DC Current VCC and GND Pins 200 mA (PDIP) and 400.0 mA (TQFP/MLF)
PDIP Package:
1] The sum of all IOL, for all ports, should not exceed 200 mA.
2] The sum of all IOL, for port A0 - A7, should not exceed 100 mA.
3] The sum of all IOL, for ports B0 - B7,C0 - C7, D0 - D7 and XTAL2, should not exceed 100 mA.
Also mehr als etwa 3-10mA (3mA für die Transistoren und 10mA für die LEDs) pro Pin (an den 26 notwendigen Pins) geht nicht bei einem Standard PDIP Chip. 8 LEDs also über einen Vorwiderstand (berechnet auf 10mA Strom!) an PORTA, den 'Rest' kannst Du im Prinzip verteilen wie Du magst. Um die Software möglichst einfach zu gestalten würde ich noch 5 Outputs für die verbleibenden LEDs am PORTB vorsehen und 8 Outputs von PORTC sowie 5 Outputs von PORTD für die Transistoren verwenden.
- Beatbuzzer
- Auserwählter

- Beiträge: 3177
- Registriert: Fr, 17.08.07, 11:02
- Wohnort: Alfeld / Niedersachsen
- Kontaktdaten:
Hab das mal mithilfe von Paint hier ergänzt.
Die Transistoren oben müssen aber PNP Typen sein. Die Transistoren an der Seite bleiben NPN Typen.
Die Widerstände oben unter den Transistoren werden für 5V berechnet (5V minus 2,3V LED geteilt durch 20mA Strom).
Die Basiswiderstände an den Transistoren können 1kohm groß sein, wenn BC327 und BC337 Transistoren verwendet werden. Im Programm ist zu beachten, dass ein NICHT gesetzter Ausgang bei den PNP Typen als Schaltsignal erkannt wird.
Bei den NPN Typen ist ein gesetzter Ausgang ein Schaltsignal.
Wenn man wirklich mit 100mA pulst und eine komplette Reihe LEDs ist an, bedeutet das schon 1,3A für die seitlichen Transistoren. Dafür sind die BC337 nicht geeignet. Ich empfehle dann dort schon auf FETs (IRLZ34N) umzusteigen.
Die Transistoren oben müssen aber PNP Typen sein. Die Transistoren an der Seite bleiben NPN Typen.
Die Widerstände oben unter den Transistoren werden für 5V berechnet (5V minus 2,3V LED geteilt durch 20mA Strom).
Die Basiswiderstände an den Transistoren können 1kohm groß sein, wenn BC327 und BC337 Transistoren verwendet werden. Im Programm ist zu beachten, dass ein NICHT gesetzter Ausgang bei den PNP Typen als Schaltsignal erkannt wird.
Bei den NPN Typen ist ein gesetzter Ausgang ein Schaltsignal.
Wenn man wirklich mit 100mA pulst und eine komplette Reihe LEDs ist an, bedeutet das schon 1,3A für die seitlichen Transistoren. Dafür sind die BC337 nicht geeignet. Ich empfehle dann dort schon auf FETs (IRLZ34N) umzusteigen.
ok.
ich habe jetzt das amtel evaluationboard v 2.01 bekommen, den µc auf den sockel eingesetzt und das usb-rs232-kabel und die spannungsversorgung angeschlossen.
welches programm soll ich nehmen??? winavr? ponyprog? avrstudio4?
wie stelle ich die verbindung zwischen programm und board bzw. µc her?
ich habe jetzt das amtel evaluationboard v 2.01 bekommen, den µc auf den sockel eingesetzt und das usb-rs232-kabel und die spannungsversorgung angeschlossen.
welches programm soll ich nehmen??? winavr? ponyprog? avrstudio4?
wie stelle ich die verbindung zwischen programm und board bzw. µc her?
Das von Pollin?amtel evaluationboard v 2.01
Das von Pollin geht nicht mit USB. Da muss es eine 'echte' RS232 Schnittstelle am Rechner sein. USB-RS232 Adapter funktionieren nicht (oder fast nie).usb-rs232-kabel
Welche Sprache Du verwenden willst (Basic, C, Assembler) musst Du schon selbst wissen. Um nur was (fertiges Hex File) auf den Chip zu schreiben, wird beim Pollin Board üblicherweise Ponyprog verwendet.
jopp das von pollin.
ah gut zu wissen. gibt es da probleme wegen des chips vom adapterkabel (RS323 auf USB)?
wie muss denn das programm für den µc aufgebaut sein? für den test wollte ich den einen taster auf dem pollin board verwenden zum starten benutzen und dann von rechts nach links die einzelnen leds ansteuern.
ah gut zu wissen. gibt es da probleme wegen des chips vom adapterkabel (RS323 auf USB)?
wie muss denn das programm für den µc aufgebaut sein? für den test wollte ich den einen taster auf dem pollin board verwenden zum starten benutzen und dann von rechts nach links die einzelnen leds ansteuern.
- Beatbuzzer
- Auserwählter

- Beiträge: 3177
- Registriert: Fr, 17.08.07, 11:02
- Wohnort: Alfeld / Niedersachsen
- Kontaktdaten:
Der Punkt ist, dass die serielle Schnittstelle nicht wirklich als solche verwendet wird, sondern sie dient nur als Verbindung zum µC.Finnchi89 hat geschrieben:jopp das von pollin.
ah gut zu wissen. gibt es da probleme wegen des chips vom adapterkabel (RS323 auf USB)?
Normalerweise hat die serielle Schnittstelle ein Protokoll.
Ein USB-Adapter simuliert jetzt dieses Protokoll an der seriellen Buchse.
Kommt man jetzt mit einer Programmiersoftware daher und will über die Schnittstelle ganz andere Daten übertragen, kann der USB-Adapter damit nichts anfangen, da er ja nur das Standard-Protokoll kennt.
Genauso verhält es sich mit USB-Parallelport-Wandlern. Die funktionieren auch nur für Drucker und nicht für Relaisplatinen oder Schrittmotorkarten oder sowas, weil diese Steuerung vom normalen Protokoll abweicht.
Ponyprog ist keine Programmiersprache sondern nur eine Art Terminalprogramm was ein fertiges Programm (schon als Maschinencode) in den Flash-Speicher des µC laden kann. Programmiersprachen wären:
Bascom (ein Basic für µCs)
C (in Form von einer speziellen gcc Variante)
Assembler (nur eine Art 'Oberfläche' um den Maschinencode direkt zu schreiben)
Vielleicht solltest Du hier mal ein wenig lesen:
http://www.mikrocontroller.net/articles/AVR-Tutorial
Ein Matrix-Beispiel in Bascom ist z.B. das LED-Cube Projekt. Ist (wenn Du den Cube 'flach' machen würdest) nichts anderes als eine 3x9 LED-Matrix
Schau es Dir mal an: viewtopic.php?f=31&t=5666&
Bascom (ein Basic für µCs)
C (in Form von einer speziellen gcc Variante)
Assembler (nur eine Art 'Oberfläche' um den Maschinencode direkt zu schreiben)
Vielleicht solltest Du hier mal ein wenig lesen:
http://www.mikrocontroller.net/articles/AVR-Tutorial
Ein Matrix-Beispiel in Bascom ist z.B. das LED-Cube Projekt. Ist (wenn Du den Cube 'flach' machen würdest) nichts anderes als eine 3x9 LED-Matrix
Schau es Dir mal an: viewtopic.php?f=31&t=5666&
danke für die tipps
hab mir heute auch ein serielles kabel geholt und mit der verbindung klappt es.
jetzt bin ich dabei ein programm zum testen zu schreiben. also mit dem einem taster das abwechselnde blinken der beiden leds auf dem board zu starten und mit dem zweiten das zu stoppen. die makefile datei habe ich mit dem maker von winavr gemacht, jetzt gehts nur noch um die programmierung.
hab mir heute auch ein serielles kabel geholt und mit der verbindung klappt es.
jetzt bin ich dabei ein programm zum testen zu schreiben. also mit dem einem taster das abwechselnde blinken der beiden leds auf dem board zu starten und mit dem zweiten das zu stoppen. die makefile datei habe ich mit dem maker von winavr gemacht, jetzt gehts nur noch um die programmierung.
so hab es soweit geschafft, dass ich kein problem mehr mit dem makefile
habe und habe mir gestern eine .c-datei ausm internet rausgesucht um
einen einfachen wechsel mal zu testen. ich hab meinen programmablauf so
weit weitergeschrieben:
#include <stdlib.h>
#include <avr/io.h>
#include "avr/delay.h"
// delay a little bit more then _delay_ms does
// time = 1/10 s
void delay_10th_s(uint16_t time);
void delay_10th_s(uint16_t time)
{
uint16_t i;
uint16_t delay_time;
delay_time = time / 100;
for(i = 0; i < 100; i++)
{
_delay_ms(delay_time);
}
}
int main(void)
{
DDRD |= _BV(PD2);
DDRD |= _BV(PD5);
DDRD |= _BV(PD6);
DDRD |= _BV(PD7);
if ( PIND & (!(1 << PD2)))
{
PORTD ^= _BV(PD5);
delay_10th_s(100);
PORTD ^= _BV(PD6);
delay_10th_s(100);
PORTD ^= _BV(PD7);
delay_10th_s(100);
PORTD ^= _BV(PD5);
delay_10th_s(100);
PORTD ^= _BV(PD6);
delay_10th_s(100);
PORTD ^= _BV(PD7);
delay_10th_s(100);
}
else
{
while(1)
{
PORTD ^= _BV(PD5);
PORTD ^= _BV(PD6);
PORTD ^= _BV(PD7);
delay_10th_s(100);
PORTD ^= _BV(PD5);
PORTD ^= _BV(PD6);
PORTD ^= _BV(PD7);
delay_10th_s(100);
}
return (0);
}
}
nur habe ich probleme mit den eingängen also hauptsächlich PD2. das
programm springt sofort in den else teil, aber sobald ich PD2 drücke
springt dieser nicht in den if teil. woran liegt es???
habe und habe mir gestern eine .c-datei ausm internet rausgesucht um
einen einfachen wechsel mal zu testen. ich hab meinen programmablauf so
weit weitergeschrieben:
#include <stdlib.h>
#include <avr/io.h>
#include "avr/delay.h"
// delay a little bit more then _delay_ms does
// time = 1/10 s
void delay_10th_s(uint16_t time);
void delay_10th_s(uint16_t time)
{
uint16_t i;
uint16_t delay_time;
delay_time = time / 100;
for(i = 0; i < 100; i++)
{
_delay_ms(delay_time);
}
}
int main(void)
{
DDRD |= _BV(PD2);
DDRD |= _BV(PD5);
DDRD |= _BV(PD6);
DDRD |= _BV(PD7);
if ( PIND & (!(1 << PD2)))
{
PORTD ^= _BV(PD5);
delay_10th_s(100);
PORTD ^= _BV(PD6);
delay_10th_s(100);
PORTD ^= _BV(PD7);
delay_10th_s(100);
PORTD ^= _BV(PD5);
delay_10th_s(100);
PORTD ^= _BV(PD6);
delay_10th_s(100);
PORTD ^= _BV(PD7);
delay_10th_s(100);
}
else
{
while(1)
{
PORTD ^= _BV(PD5);
PORTD ^= _BV(PD6);
PORTD ^= _BV(PD7);
delay_10th_s(100);
PORTD ^= _BV(PD5);
PORTD ^= _BV(PD6);
PORTD ^= _BV(PD7);
delay_10th_s(100);
}
return (0);
}
}
nur habe ich probleme mit den eingängen also hauptsächlich PD2. das
programm springt sofort in den else teil, aber sobald ich PD2 drücke
springt dieser nicht in den if teil. woran liegt es???
Ich hab zwar von C nicht so viel Ahnung, aber AFAIK macht while(1) eine Endlosschleife. Wie soll das Programm da 'rauskommen'? IMHO wird PIND einfach nicht mehr geprüft, sobald das Programm in der while(1) Schleife 'festhängt'.
- Beatbuzzer
- Auserwählter

- Beiträge: 3177
- Registriert: Fr, 17.08.07, 11:02
- Wohnort: Alfeld / Niedersachsen
- Kontaktdaten:
Ich schalte mich auch noch mal ein:
Die Muttersprache von Borax ist Basic, soweit ich weiss
.
Ich kenn mich auch nur in Basic ein bisschen aus. Programm dazu wäre BASCOM.
Kannst du die Abfrage des Pins nicht mit in die Schleife packen? Sodass bei jedem Durchlauf der Pin überprüft wird.
Sobald der Pin gesetzt ist, verweisst du dann auf eine Stelle ausserhalb der Schleife.
Die Muttersprache von Borax ist Basic, soweit ich weiss
Ich kenn mich auch nur in Basic ein bisschen aus. Programm dazu wäre BASCOM.
Kannst du die Abfrage des Pins nicht mit in die Schleife packen? Sodass bei jedem Durchlauf der Pin überprüft wird.
Sobald der Pin gesetzt ist, verweisst du dann auf eine Stelle ausserhalb der Schleife.


