Hallo Leute,
Vor Ewigkeiten hab ich hier mal Fragen zum Thema LED-Ansteuerung
gestellt - mittlerweile habe ich (u.A. von diesem Forum) viel
dazugelernt und bin schon ein ordentliches Stück weiter.
Was ich habe: Einen ATmega32, der via RS232 Opcodes/Daten entgegennimmt,
und in eine Verkettung von 60 (momentan Testaufbaut mit 2, Ziel sind 60)
Stück TLC5940 hineinpfeffert. Die 50 PWM-Controller steuern - man staune
- 60 * 15 = 900 LEDs an. In Wirklichkeit sind das 13m RGB-LED-Strip, die
Aufbaudetails erspar ich auch ... sobald ich fertig bin dokumentier ich
alles schön und der geneigte Leser darf es bestaunen :-)
Kurzbeschreibung des Problems: Die RS232 ist ein Bottleneck :-( Die
maximale Baudrate die ich zwischen PC und AVR zusammenkriege ist 115200,
das ergibt mit 1+8+2=11 Bits eine Rate von 10.472 Byte pro Sekunde.
Theoretisch ergibt das eine Framerate von 11,6 Frames pro Sekunde,
aufgrund eines leichten Protokoll-Overheads komme ich effektiv auf ~10
Frames pro Sekunde. Und das ist bei Fading-Effekten leider zu wenig (es
ruckelt).
Überlegte Lösungen:
-> Reduzierte Auflösung: Neben 8 bit kann ich bereits wahlweise 6, 4, 2
oder sogar 1 bit pro Kanal übertragen. Die effektiven Frameraten steigen
dann wie erwartet, doch aufgrund der geringeren Farbauflösung sind
Fading-Effekte wieder unschön. Ich tausche das eine gegen das andere,
und beides bräuchte ich... :-/
-> Datenkomprimierung: Die LEDs werde, wenn das Werkl fertig ist, wohl
irgendeine Art von beschreibbaren Mustern aufweisen (Farbverläufe,
Wiederholungen, etc.) - ich weiß jedoch ehrlich gesagt noch nicht so
genau, welche Art Muster genau, und so tu ich mir schwer bei der Auswahl
eines geeigneten Komprimierungsverfahrens - hier liegt auch der Haken,
siehe weiter unten ("ich weiß nicht was ich will").
-> Anderes Interface: Statt RS232 USB oder Ethernet zu verwenden habe
ich mir zwar überlegt, vermute aber, dass Ethernet viel zu umständlich
für eine doch relativ simple Point-to-Point-Anwendung ist, und bei USB
sowieso der gleiche Sumpf wieder rauskommt, wenn ich einen Seriellen
Port emuliere (wenn der wieder mit 115200 läuft, ist das ganze für die
Katz').
Das Hauptproblem ist: "Ich weiß nicht was ich will". Und zwar deswegen,
weil ich mir eine Anwendungs-Level-Library basteln wollte, mit der ich
mit einer akzeptablen Framerate (~20 oder mehr) alle LEDs frei steuern
kann. Ich wollte a priori keine Einschränkungen vornehmen, was die
übertragenen Daten betrifft, was eben die Kompression bzw.
Rearrangierung der Daten etwas schwierig macht. Und erst jetzt bin ich
darauf gekommen, dass der resultierende Datenstrom von 18 KB/s für RS232
zu hoch ist.
Ich würde gerne wissen, was ihr dazu sagt. Hat jemand Erfahrung in der
schnellen (wie gesagt, 18 KB/s sollten drin sein) Übertragung von Daten
an den AVR? Wenn ich USB verwende und dort einen COM-Port simuliere,
kann ich dann vielleicht höhere Baudraten wählen?
Danke im Voraus :-)
Liebe Grüße aus Wien!
Michi
Anstatt immer die komplette Information durchzubollern helfen vielleicht
befehle wie "Anzeige heller", "Anzeige dunkler", "Anzeige um1 Pixel nach
links scrollen", etc.
Du wirst wohl kaum ein Insekten-TV bauen wollen mit alle 10
Millisekunden ein komplett neues Bild?
Freilich brauchst du mit diesem Ansatz mehr Speicher als beim
Durchpust-Ansatz.
Ich würde als ersten, einfachen Ansatz auch auf USB-RS232 gehen, z.B.
Silabs CP2102. Da hast Du schon mal die 8-fache Baudrate, (921'600 Baud)
ohne dass Du das ganze bisherige Konzept auf den Kopf stellen musst.
SPI wäre noch eine schnelle Variante, wird aber der PC nicht von Haus
auf verstehen.
Mit Ethernet wirst Du auch keinen höheren Datendurchsatz hinkriegen, da
hat die SW für den TCP/IP Stack zu viel zu tun...
>Mit Ethernet wirst Du auch keinen höheren Datendurchsatz hinkriegen, da>hat die SW für den TCP/IP Stack zu viel zu tun...
TCP/IP hat mit Ethernet in dem Zusammenhang praktisch nichts zu tun.
Wenn man den PC dazu bringen kann, nur Ethernet zu benutzen, ohne die
anderen Schichten verarbeiten zu wollen, ist das nicht übermäßig
kompliziert (das heißt nicht, dass es einfach ist). Es gibt fertige
Ethernet-Controller, zum Beispiel den ENC28J60.
Als andere Möglichkeit kann man USB auch auf einem AVR programmieren,
Atmel hat dazu eine Application-Note.
"Implementation runs on very small AVR devices, from 2kBytes and up".
Das ist dann aber relativ kompliziert und zeitkritisch.
Michael Borkowski schrieb:> -> Anderes Interface: Statt RS232 USB oder Ethernet zu verwenden habe> ich mir zwar überlegt, vermute aber, dass Ethernet viel zu umständlich> für eine doch relativ simple Point-to-Point-Anwendung ist, und bei USB> sowieso der gleiche Sumpf wieder rauskommt, wenn ich einen Seriellen> Port emuliere (wenn der wieder mit 115200 läuft, ist das ganze für die> Katz').
Bei USB kannst Du Dir beispielsweise den FT245R anschauen. Der gibt
seine Daten parallel raus, d.h. Du hast dann keine serielle
Schnittstelle mehr im System. Es könnte dann aber sein, dass Du dann ein
Controller mit mehr Pins brauchst.
Bei Ethernet brauchst Du kein TCP zu machen - UDP ist viel einfacher zu
implementieren.
Und solltest Du einfach einen schnelleren Controller brauchen, wartet zB
ein PIC32MX auf Dich, mit 32 Bits, echten 80 MHz, USB (mit fertigen
USB-Stack), 10/100 Ethernet (mit fertigem IP-Stack) und anderen netten
Gimmicks - und der Chip ist auch nicht teurer als ein Mega128.
fchk
Peter S. schrieb:> Mit Ethernet wirst Du auch keinen höheren Datendurchsatz hinkriegen, da> hat die SW für den TCP/IP Stack zu viel zu tun...
Für Punkt zu Punkt braucht er keinen TCP/IP Stack. Schicht 2 reicht.
Dann geht's auch schnell.
Ich stimme Frank K. zu, der FT245 ist denke ich das was du willst. Damit
wird am PC eine virtuelle serielle Schnittstelle erzeugt. Bei der kann
man dann auch Datenraten einstellen, aber die haben keine Einfluss. Am
ATMega rufst die Daten parallel per Steuerleitungen ab. Das geht richtig
flott, da der Controller selbst die Geschwindigkeit bestimmt mit der die
Daten abgenommen werden.
Einziger Nachteil: du brauchst am einen freien Port und noch ein paar
Steuerausgänge.
was den Datenstrom angeht könnte man weitestgehend auf ein Protokoll
verzichten und per DMX einfach raus schaufeln.
Da wird nur das erste Byte per Frame Error gekennzeichnet und der Rest
dann einfach rausgepfeffert.
Ob Dein PC-Programm aber sowas schnell genug für > 20 Frames/sec schafft
... keine Ahnung.
Anderer Ansatz wäre quasi den µC in einen Interpreter zu verwandeln der
einen Ablauf, der am PC erstellt wurde und z.B. im EEPROM des µC
gespeichert wird abzuarbeiten.
> Und das ist bei Fading-Effekten leider zu wenig (es
ruckelt).
Ich würde ebenfalls auf die Variante setzen: Lass den µC das Fading
berechnen.
900 LED ist ein 30*30 Screen. Du du dich weder um PWM noch um
Multiplexen kümmern musst, hat der µC alle Zeit der Welt um die
Zwischenwerte zu errechnen.
Wenn im Controller noch ein bischen Resourcen übrig sind einfach das
Fading in den Controller verlagern. Für Sonderfälle evtl. auch mit
unterschiedlichen Modi: Standard 5Hz/ Ruhig auf 1Hz und einen
Strobemodus
OK zu spät
Wenn es um die reine Datenübertragung geht, sind 1Mbit logger drin. Wir
nutzen das in der Firma. Damit kann der AtMega bei 16 oder 20 Mhz laufen
und braucht kein Baudratenquarz (z.B. 14.76, oder 18.432 Mhz).
Allerdings nutzen wir dafür einen FTDI-USB-Seriell Wandler. Durch
einfaches anpassen der entsprechenden Bytes in der Registry kann man die
in Windows üblichen Baudraten auf andere Geschwindigkeiten umbiegen. Bei
uns läuft es so, dass man 1200 Mbit in der Software einstellt, der FTDI
aber 1Mbit raushaut. Bei der Einstellung 600 Mbit schieben wir 2Mbit
raus und bei der Einstellung 300 MBit ganze 3Mbit was das Maximum der
FTDI-Chips darstellt.
Bei Interesse kann ich das genauer Erläutern.
Danke an alle für die zahlreichen Antworten!
An alle die mir empfohlen haben, den AVR mehr als Interpreter zu
verwenden und die Effekte berechnen zu lassen: Ich weiß, das wäre der
schöne Weg. Das Problem ist, dass ich (noch) nicht weiß was genau ich
für Effekte/Modi haben will, und mich da a priori noch nicht
einschränken möchte. Deswegen möchte ich, soweit es geht, die Logik auf
der PC-Seite lassen... wohl wissend, dass der AVR eigentlich nebenbei
noch einiges tun könnte ;-)
H.joachim Seifert schrieb:> Der Flaschenhals wird am Ende der ATMega sein
Von dem was ich gemessen habe, ist der aber relativ untätig. 18 KB/s zu
verarbeiten (= an die SPI 1:1 weiterzugeben) sollte, denk ich, kein
Problem sein, zumal die SPI mit knapp 1 MBit/s betrieben wird. Aber
danke, ich werd schauen dass die Software möglichst effizient läuft!
Frank K. schrieb:> Bei USB kannst Du Dir beispielsweise den FT245R anschauen. Der gibt> seine Daten parallel raus, d.h. Du hast dann keine serielle> Schnittstelle mehr im System. Es könnte dann aber sein, dass Du dann ein> Controller mit mehr Pins brauchst.
Ich glaub', der wirds werden. Falls es wirklich stimmt, was Rangi Jones
schreibt (dass die COM-Schnittstelle dann rein virtuell ist und die
eingestellte Baudrate keinen Einfluss mehr hat), dann klingt das ja toll
und ich muss nicht viel Änderungen am System durchführen.
Ist das der gleiche, von dem Super Grobi gesprochen hat?
Nochmals danke an alle für die hilfreichen Tipps! :-)
So, zwischendurch kam ein Uni-Semester und ein Kreuzbandriss, weswegen
sich das ganze stark verzögert hat. Inzwischen hab ich mir das UM245R
DIP-Modul gekauft, damit ein wenig herumgekämpft (man sollte entweder
AVR + UM245R vom USB-5V-Pegel betreiben oder beides von einer externen
Stromversorgung, nicht gemischt!) - aber jetzt funktioniert es, die
Kommunikationsgeschwindigkeit ist mehr als ausreichend (ohne große
Optimierungen und mit einem etwas hohen Protokoll-Overhead bekomme ich
35 Hz inklusive Speicherung und Weiterverarbeitung der Datenmenge
zusammen).
Danke an alle für eure Hinweise! :-)
Liebe Grüße aus Wien,
Michi
