Hallo!
Wie schon der Titel sagt, will ich einen DMX512 Transmitter mit einem Atmega8 (derzeit 4MHz) realisieren. Ich habe mich schon intensiv mit dem DMX-Protokoll auseinandergesetzt, und mit Hilfe des Hardware UART-s im Double Speed Mode schaffe ich es, gültige DMX-Frames zu erstellen.
Das Problem ist aber, dass ich die Daten fürs DMX-Frame vom PC empfangen möchte, und daher muss noch eine Schnittstelle her. DMX mit Software UART geht nicht, da 250kbps benötigt wird. Zwischen PC und uC würde schon mit Software UART gehen, ich weiss nur nicht, wie viel Zeit mir dann noch für andere Sachen bleibt. Hat da wer Richtwerte?
Meine weitere Überlegung war, das SPI für DMX zu missbrauchen, jedoch kann der pro SPI-Frame nur 8 bits übertragen, ich brauche aber wegen Start- und Stopp bit 10 (besser 11 mit doppeltem Stopp bit) Bits.
Deshalb ist meine Frage, ob jemand eine grenzgeniale Idee hat, wie man die 512 x 8 Datenbits mit jeweils einem Start und zwei Stoppbits zusammenbaut, und das dann möglichst effektiv an der SPI-Schnittstelle mit 250kbps rausschiebt?
Danke im Voraus,
pongi
... und warum nimmst Du dann keinen Controller mit 2 USART's ?
Die könntest Du Dir dann so einstellen wie Du lustig bist.
Ich meine der ATMEGA 64 müsste 2 an Bord haben.
Das Teil kostet bei Reichelt 4,50€.
Der MEGA 8 kostet 1,35€.
Der Preis kann also nicht das Argument sein.
Eher schon die Bauweise ( SMD ).
Ist aber mit ein wenig Übung auch kein Problem.
Software USART würde ich nicht nehmen wollen, da kann der Datendurchsatz schnell mal zu niedrig werden.
Ja, ich hab mit dem Atmega162 schon geliebäugelt, den gibts auch als DIP. Letztendlich wirds wohl darauf auslaufen.
Es ist aber algorithmisch eine interessante Herausfordeung, die Daten mit den Start und Stop Bits passend fürs SPI zu generieren. Es muss "nur" eine passende Schleife implementiert werden, die die Daten in den SPI-Senderegister stopft.
Obwohl, jezt fällt mir grad ein, ein 512 Byte Array mit nem Atmega8 ist sowieso unmöglich, der hat ja nur 512 Byte RAM, oder? Ups..
Ich bastel gerade mit einer FAT für eine SD Karte rum.
Da brauch ich auch einen Sektorpuffer mit 512 Byte.
Das passt gerade so in einen ATMEGA 32.
Die Sende und Empfangspuffer für den USART hab ich schon auf 128Byte gestutzt.
Da ich vermute, Du willst zumindest den Emfänger für die Daten vom PC puffern, kannst Du nicht genug RAM haben.
Eine interessante Schaltung hab ich auch bei digital Enlightment : http://www.digital-enlightenment.de/usbdmx.htm gefunden.
Er hat das Komunikationsproblem mit dem PC per USB gelöst.
Hab vor das Interface demnächst aufzubauen.
Eine Anfrage wegen Platinen hab ich schon gestellt, bis jetzt aber noch keine Antwort bekommen.
Eventuell lohnt sich eine Sammelbestellung von den Platinen, da ja auch eine .brd Datei existiert ?!
Was man so hört soll das Interface nicht schlecht sein. Ausserdem wird es auch von "DMX-Control" unterstützt.
Mein Plan war, die Daten vom PC über einen USB-RS232 Wandler mit 115200bps zu senden, wobei mit Hilfe eines Protokolls nur die sich geänderten Kanäle überschrieben werden (Befehlcode + Index + Anzahl nach dem Index nacheinander zu schreibende Kanäle + Daten). Bzw. habe ich vor, für Fades auch extra ein Befehl zu implementieren (Befehl + Kanal + Startwert + Endwert + Übergangszeit). Daher würde ich am uC noch Rechenzeit neben der Kommunikation benötigen.
Da meine Tests mit einem Atmega8 erfolgreich waren bezüglich senden via UART, wirds wohl jetzt auf ein uC mit zwei UARTs rauslaufen.
Für was brauchst du bei SPI Start und Stoppbits zu generieren??? Die genutzten Daten vom DMX-Protokoll bestehen doch auch nur aus 8 Bits. Und die passen genau in acht Bits des SPI-Frames....
...wer nicht findet hat nicht gesucht...
Stimmt leider so nicht ganz.Die genutzten Daten vom DMX-Protokoll bestehen doch auch nur aus 8 Bits. Und die passen genau in acht Bits des SPI-Frames....
Es kommt ja noch das Startbit und 1 ( oder waren es 2 ? ) Stoppbits dazu.
Wenn Du also per SPI so ein Frame generieren willst, musst Du diese Bits künstlich einfügen.
Ausserdem muß dabei die SPI kontinuierlich Daten senden, da das USART Signal ja nicht getaktet wird, wie eine normale SPI Komponente.
Da ein normaler USART sehr wenig Rechenzeit braucht, würde ich dann doch lieber einen Controller verwenden, der 2 USART's hat.
Einen für die DMX Schnittstelle und einen weiteren für die Anbindung an den PC.
Die Datenübertragung vom PC zum Interface kann in der DMX Kette der Flaschenhals werden, wenn viele Kanäle gleichzeitig geändert werden sollen.
Ich Vermute, das Pongi deshalb auch "Dimm-" Kommandos in seine Befehlsstruktur einbauen will, weil das die serielle Schnittstelle ziemlich entlasten könnte.
Als künftige Option ist, durch die 2 USART's, dann auch das Empfangen von DMX Signalen problemlos möglich. Das Gerät kann also dann auch mal als DMX Merger oder Repeater verwendet werden.
Ausserdem kann man dann auch zum PC empfangene DMX Daten übertragen, bzw. Statusmeldungen des DMX Interface geliefert bekommen.
Dafür darf aber dann auch das RAM nicht zu klein sein, weil man ja schon 2x 512Byte als Puffer für die zu sendenden/empfangenen DMX Daten braucht.
Will man dann auch noch die aktuellen DMX Werte mit den vorhergehenden vergleichen, braucht man noch mal 512Byte mehr.
Also sind 2kRam eigentlich schon die untere Grenze.
@wkrug: du hast mir gerade viel Tipparbeit erspart
Ursprünglich reicht 1 Stopbit, ich wollte aber 2 verwenden, da zwischen zwei Datenbytes eine Pause von >0 us (und nicht = 0) vorzusehen ist, und da bot sich noch ein Stopbit gut an. Ich weiss nicht, wie weit diese Pause kritisch ist, vielleicht nur bei Verwendung von älteren DMX Geräten, aber da es im Standard steht, wollte ich das einfach mal implementieren.
Ich habe inzwischen auch überlegt, sowas zu verwenden: http://shop.embedded-projects.net/pr...-USB-162-.html
Da ist ein AVR drauf, der direkt USB mit der vollen Geschwindigkeit von 12MBit/s kommunizieren kann. Das einzige, was mich im Moment davon abhält, ist die Tatsache, dass ich keine Erfahrung mit dem Gerät habe, und nicht weiss, wie da die Kommunikation läuft. Außerdem weiss ich nicht, wie das vom PC erkannt wird. Wahrscheinlich nicht als virtuelle serielle Schnittstelle...
Kennt sich da wer aus?
Ich bin jetzt mit USB nicht wirklich ein Kenner aber...Wahrscheinlich nicht als virtuelle serielle Schnittstelle...
Es kommt auf den Treiber an.
Bei den FTDI Chips FT232R gibt es da 2 Verschiedene.
Einer ist für den VCP ( Virtuell Com Port ), der andere wird Direct Driver genannt.
Das Enlighment Interface meldet sich meines Wissens als HID ( Human Interface Device ) an.
Es ist also abhängig vom verwendeten Chip, sowie vom Treiber.
Ja, das schon. Aber beim Board oben ist ein AT90USB oben, der hat intern schon USB. Nix mit externem Wandler. Daher die großen Fragezeichen
Berechtigungen
Zitieren
Lesezeichen