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
Mit nem USB/RS232 oder 485-Adapter schaffst du deutlich mehr als 115k. Der Flaschenhals wird am Ende der ATMega sein.
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.
Hi ich habe da nicht so viel Ahnung, aber kannst du das nicht mit einem "ArtNetNode" machen. Schau mal beim Radig vorbei http://www.ulrichradig.de/home/index.php/avr/dmx-avr-artnetnode
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! :-)
Wenn du nicht weisst was du willst, hilft vielleicht ein Bootloader? Dann "komprimierst" du deinen Effekt als compiliertes Programm...
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
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.