LED Matrix, grundlegende Fragen

1.  LED-Matrizen sind so verschaltet, dass pro Widerstand und Zeitpunkt 
eine konstante Zahl von LEDs (üblicherweise eine) angeschaltet ist. 
Hängen mehr LEDs am selben Widerstand, werden die anderen zu anderen 
Zeitpunkten geschaltet.  Ist nicht so kompliziert wie es klingt; schau 
Dir einfach eine ausgeführte Schaltung an.

2. Was tun Dir 24 Zyklen weh?  Musst Du sie einzeln bezahlen?  Du hast 
um die 8 Millionen oder so pro Sekunde an Zyklen zu verbraten - ob Du 
sie brauchst oder nicht.  Für die davon, die zeitkritisch sind, gibt es 
spezielle Programmiertechniken, damit Deine 24 Zyklen denen nicht in die 
Quere kommen.

3. Ein MOSFET wird anders beschaltet als ein bipolarer Transistor und 
benimmt sich anders.  Was davon man wählt, hängt erst mal von den 
gewünschten Schaltungseigenschaften und vom Preis ab und nicht davon, 
was man lieber mag.  Von Letzterem kannst Du Dich bei Deiner 
Musikauswahl leiten lassen, nicht aber bei der Bauelementewahl.

Eine 16x16-Matrix ist schon etwas Anderes als das Beispiel, auf das Du 
Dich zunächst bezogst.  Ich würde mich spätestens jetzt mit Alternativen 
beschäftigen, also den schon genannten Schieberegistern oder mehreren 
parallelen Matrizen.  Die Ströme, die Du schnell schalten musst, werden 
sonst zu unhandlich (vorausgesetzt, Du hast irgendwoher LEDs, die ihn 
verarbeiten).

LDericher schrieb:

Und um die andere Baustelle auch noch aufzumachen

> 2.
> Schieberegister.
> Kommt mir irgendwie total unpraktisch vor. Keine Ahnung, ob ich da was
> falsch verstanden habe. Noch mal also zur Klärung:
> Wenn ich zB in einem 8-bit-SR bspw. die Zahl 00000000 gespeichert habe
> bzw. ausgebe, daraus aber 10101010 machen will, brauche ich wieviele
> Prozessortakte? Wenn ich nicht irre, dann 24 Stück:
> 1 setzen, Clock hoch, clock runter, 0 setzen, wieder clock h/l, und für
> die anderen 6 bits dann auch noch. Oder gibt es da effizienteres?
> Überhaupt: Wenn ich mehrere S-Register hintereinanderschalte, kann ich
> doch in allen immer nur das Gleiche speichern, weil der Ausgang OH*
> immer den Eingangswert übernimmt. Richtig?
> Bitte sagt mir, dass ich da was falsch verstanden habe...!

Die Prozessortakte werden sogar noch mehr sein, denn du musst ja 
irgendwie auch noch entscheiden, ob da jetzt eine 1 oder eine 0 auf die 
Datenleitung muss :-)

Aber:
1) µC sind schnell.
2) mit einer Hardware SPI Unit, macht das die Hardware ganz von alleine

Zwecks Kaskadierung:

http://www.mikrocontroller.net/articles/AVR-Tutorial:_Schieberegister

LDericher schrieb:
> Okay, ich habe einen Befehl gefunden, mit dem ich wenig anfangen kann:
> ".org $60" direkt nach einem ".dseg". Was macht das? Setzt es die
> Startadresse für das Datensegment auf $60? Oder wie?

So ungefähr.
Es sagt dem Assembler, das er seine interne Bytezählung die sich durch 
die OpCodes der Befehle ergeben hat vergessen soll, das nächste was 
ausgegeben wird, soll auf Adresse $60 landen.

> Weitere Frage: Wenn ich das 16er Ding als 4 parallele Matrizen behandeln
> will (was von der Bechaltung ja schon möglich ist), muss ich dann 4 µCs
> nehmen,

du musst die Aufteilung ja nicht machen, weil der µC mit der 16*16 
Matrix nicht mehr mitkommen würde.
Du musst die Aufteilung machen, weil du sonst mit dem Strom in Regionen 
landest, die nicht mehr beherrschbar sind.

Dein µC ist schnell genug
(Hast du schon mal was mit µC gemacht? Du hast ständig Angst, das du mit 
dem Tempo nicht hinterherkommst.
Die Dinger sind schnell! Sauschnell! Noch schneller!)

> oder kann ich da auch über einen drauf zugreifen? Ich befürchte
> nämlich, dass ich dort 4 brauche, weil ich ja, um die Pulsströme zu
> verringern, auch die Zeitkomplexität verbessern muss (also nicht n^2,
> sondern n^2/4 ...?)

Du musst ja nicht alle 4 Untermatrizen hintereinander ansteuern. Es 
spricht ja nichts dagegen, wenn alle Matrizen gleichzeitig jeweils 
Spalte 0 anzeigen. Dann wird in allen 4 Matrizen Spalte 1 geladen, 
umgeschaltet und dann zeigen alle 4 Matrizen gleichzeitig Spalte 1 an. 
etc.

De Facto hast du einen 8-er Multiplex, der vielleicht nicht ganz 
Full-Speed läuft (weil du ja 4 Spalten laden musst und nicht nur eine) 
aber sagte das schon wer: Die Dinger sind schnell! Man muss es nur ein 
wenig geschickt machen.

LDericher schrieb:
> was von der Bechaltung ja schon möglich ist

Äh. Nein

Du musst die komplette Matrix schon aus 4 voneinander unabhängigen 8*8 
Teile ansehen.

Du kannst entweder die Spalten oder die Zeilen Treiber der 
Einzelmatrizen zusammenschalten und gleichzeitig ansteuern. Aber die 
jeweils anderen (Zeilen/Spalten) müssen voneinander unabhängig sein.

LDericher schrieb:

> Karl heinz Buchegger schrieb:
>> gleichzeitig
> Klingt entweder nach 16-Bit-Ausgabe, oder aber nach "quasi-gleichzeitig,
> weil die Dinger eben verdammt schnell sind!". Letzteres gefällt mir
> besser ;)

Hier heisst es tatsächlich gleichzeitig.
Wenn du eine extreme Zeitlupe hättest, würde man sehen, dass tatsächlich 
in den Submatrizen gleichzeitig jeweils Spalte 0 leuchtet und bei allen 
4 Submatrizen gleichzeitig auf Spalte 1 umgeschaltet wird.

> Also heißt das, dass ich die Spannungs/Stromquelle vierteilen muss.
> Richtig?

Wenn du das meinst, was ich denke das du meinst, dann: ja

LDericher schrieb:
> Karl heinz Buchegger schrieb:
>> Man muss es nur ein wenig geschickt machen.
>
> das klingt fast nach einem "für den LDer unschaffbar".

Das wollte ich damit nicht sagen.
Was ich sagen wollte: Nicht dem ersten Augenschein nachgeben sondern 
sich überlegen wie man es besser machen kann.

Karl heinz Buchegger schrieb:
>> ".org $60" direkt nach einem ".dseg".
> Es sagt dem Assembler, das er seine interne Bytezählung die sich durch
> die OpCodes der Befehle ergeben hat vergessen soll,

Kleine Korrektur (auch wenn ich Atmels Assembler wenig kenne, wird er 
sich wohl da nicht anders verhalten): da es sich um dseg (nicht um cseg) 
handelt, hat sich die interne Bytezählung auf Variable bezogen (nicht 
auf Opcodes von Befehlen)  und die nächste Variable (nicht der 
Programmzähler) wird um 0x60 nach hinten verlegt.

LDericher schrieb:
> Karl heinz Buchegger schrieb:
>> Hier heisst es tatsächlich gleichzeitig.
>> Wenn du eine extreme Zeitlupe hättest, würde man sehen, dass tatsächlich
>> in den Submatrizen gleichzeitig jeweils Spalte 0 leuchtet und bei allen
>> 4 Submatrizen gleichzeitig auf Spalte 1 umgeschaltet wird.
>
> Natürlich. Hab wieder das Prinzip der Schieberegister aus den Augen
> verloren~

Darum gehts hier gar nicht.

Um 4 Stück 8*8 Matrizen anzuschliessen, müsstest du 5 Stück 8-Bit Ports 
haben. Dann könntest du jeden Spalten/Zeilenanschluss direkt an den µC 
hängen.

An 4 Ports stellst du den Spalteninhalt jeder Submatrix ein (über die 
Zeilenleitungen) und am gemeinsamen Spaltenanschluss aller Matrizen 
entscheidest du in welcher Spalte die Werte der 4 Zeilenports in jeder 
Submatrix angezeigt werden sollen.

Da du aber wahrscheinlich keine 5 Stück 8-Bit Ports haben wirst, muss 
man sich die eben mit Schieberegistern selbst machen. Dann reichen zb 
für die 4 Stück Zeilenports lediglich 3 Ausgänge am µC und ob man die 8 
Spaltentreiber direkt am µC anschliesst oder ebenfalls über die SR führt 
... das muss man entscheiden, wenn feststeht was sonst noch so an den µC 
ran muss. Hat man die 8 Pins, dann würde ich da kein SR dafür nehmen, 
hat man sie nicht, dann kommt eben ein SR zusätzlich in die SR-Kette und 
man ist weiterhin bei 3 verbrauchten Pins.

Nur ne kleine alternative Sichtweise: die 4 parallelen Matrizen stell 
ich mir für die Ansteuerung lieber als eine 8x32 Matrix vor. Dabei sind 
die LEDs aber nicht in 8x32 angeordnet, sondern ein 8x16 Block ist unter 
den anderen 8x16 Block verschoben. Sichtbar ist also eine 16x16 Matrix, 
angesteuert wird eine 8x32 Matrix.

 Wenn du z.B. 4 8-Bit Schieberegister hintereinander hängst und die 
Steuerleitungen (bis auf den ser-eingang) parallel schaltest, verhalten 
sie sich genau wie ein 32-Bit Schieberegister. 4x 8 Bit = 32 Bit rein 
schieben, alle Ausgänge updaten mit RCK. Das Daten reinschieben könntest 
du mit dem Hardware-SPI des Megas machen. Der kann mit bis zur halben 
Taktrate des µC-Controllers, also bis zu 10MHz laufen. Das wird kaum 
langsamer als wenn du direkt mit Ports rausgehst. Ist allerdings 
zusätzlicher Einarbeitungsaufwand. Mir reicht das sogar für 24x32 
zweifarbige LEDs in 16 Abstufungen. Der µC hat in deinem Fall also noch 
ordentlich Luft.

Gruß, Alex