SEDU-Board - Software

Dieser Thread soll eine SW-Sammlung für das "hier im Forum entwickelte" SEDU-Board werden - sowohl fertige Programme für einen bestimmten Zweck, wie auch nützliche Codeschnipsel.

Da das SEDU-Board letztlich auch nur ein normaler Mega644p mit ein paar Chips drumrum ist, kann die SW natürlich auch für andere Plattformen (selbstgebaut etc.) genutzt werden - mit leichten Anpassungen auch für andere AVRs.

Der Vorteil (insb. für Anfänger) beim Einsatz des SEDU besteht darin, dass man eine einheitliche Plattform hat, sich also nicht groß Gedanken über welcher Quarz etc., was wo angeschlossen wird usw. machen muss, insb. wenn man ein zu einer bestimmten SW passendes Erweiterungsboard benutzt.

Hier folgt ein Inhaltsverzeichnis, jedes Programm wird in einem eigenen Post vorgestellt, ich bekomme neue Posts ja mit und verlinke diese dann im Inhaltsverzeichnis.

Inhaltsverzeichnis

• SEDU-SW Grundlagen und Templates
• Treiberinstallation und Software-Upload
• Protokollkonverter Mini-DMX auf WS2801/TM1804 (für Ambilight, Atmowin, DMXcontrol, Freestyler, ...) (ASM)
• 24-Kanal-PWM-Dimmer mit Steuerung über USB (Mini-DMX), zusätzlich DMX-Ausgabe (ASM)
• SEDUsetup PC-Software für Plug&Play-Ambilight-Firmware
• Umsetzung DMX auf WS2801 (Digitale Stripes/Pixel über DMX steuern) (ASM)
• Konverter tpm2 -> WS2801/WS2811/TM18x (ASM) - Matrix mit Glediator, Pixelcontroller oder Jinx! steuern
• Konverter DMX In -> tpm2 (ASM) - DMX-Daten mit dem PC empfangen, z.B. um Jinx! per DMX zu steuern

Es "darf" (bzw. *soll* sogar) jeder hier mitmachen - wer nicht in der Lobby angemeldet ist, kann mir die SW mit Beschreibung zum veröffentlichen schicken, dann poste ich sie hier, natürlich unter Nennung das Autors. Das Ganze lebt vom mitmachen, wenn nur die üblichen 2, 3 Leute hier Sachen vorstellen, die breite Masse nur runterlädt und nix wieder zurückgibt, dann ist das auch irgendwie sinnlos.

Ein paar "rechtliche" Hinweise noch:

1. SW die hier veröffentlicht wird, kann kostenlos runtergeladen und genutzt werden - es gibt aber keine Garantie auf die Funktion, Haftung falls irgendwas nicht funktioniert oder ein Schaden entsteht, oder Recht auf Support per PN oder Telefon - Funktion und Einsatz der SW wird hier bestmöglich beschrieben, wer weitergehende *sinnvolle* Fragen dazu hat, kann mir ne PN schicken, ich werde die dann (ggfs. mit Antwort) hier als FAQ dazufügen.

2. Jeder, der hier SW reinstellt, erklärt sich also auch damit einverstanden, dass diese runtergeladen und benutzt, ggfs. auch modifiziert werden kann - ohne Nachfragen oder Geld dafür zu bekommen o.ä.

3. Im Sinne des Gemeinschaftsgedankens wird dann auch erwartet, dass User, die SW hier runterladen und weiterentwickeln (damit ist neue Funktionalität o.ä. gemeint, nicht so simple Änderungen, dass irgendwas halt an nem anderen Port rauskommt o.ä.) ihrerseits diese SW auch wieder hier der Gemeinschaft zur Verfügung stellen.

4. Auch wenn es sich technisch/juristisch kaum verhindern lässt, hier vorgestellte SW ist nicht dafür gedacht, dass jemand damit ein kommerzielles Produkt erstellt dass er dann in großen Stückzahlen mit Gewinn verkauft - hat jemand sowas vor, soll er sich doch bitte an den jeweiligen Autor der SW für eine Einigung darüber wenden.

5. habe ich noch was vergessen, dann einfach fragen

Was wird hier wie veröffentlicht?

1. SW, die direkt ohne Modifikationen auf dem SEDU-Board lauffähig ist - dazu müssen nur ein paar wenige Grundvoraussetzungen beachtet werden

2. Es ist dabei egal, in welcher Sprache (C, Bascom, Assembler) die SW geschrieben wurde, nützlich wäre es, wenn die Sprache gleich im Titel genannt wird.

3. Normal wird davon ausgegangen, dass die SW komplett veröffentlicht wird, also inkl. Quelltext, und auch fertig kompiliertem .hex-File, so dass Anwender diese sofort ohne selbst kompilieren zu müssen, per Bootloader auf den SEDU laden können

4. Wenn jemand hier ne SW zur Verfügung stellen, aber aus welchen Gründen auch immer den Quelltext nicht veröffentlichen will, kann er auch nur das .hex-File hier posten

5. Es sollte immer eine möglichst ausführliche Beschreibung dabei sein, was die SW wie macht (in der Art einer Bedienungsanleitung) und welche Voraussetzungen dazu nötig sind, insb. auf HW-Seite - also für die HW ein Schaltplan (ideal auch noch Layout) dazu - ist das Ganze in Form eines Aufsteck-/Ansteckboards gestaltet, dann bitte auch dieses in dem zugehörigen Thread vorstellen und kreuzverlinken.

6. Da man das SEDU-Board auf versch. Arten konfigurieren kann, sollte auch noch eine Beschreibung dazu, welcher Jumper wie gesetzt werden muss, dazu werde ich eine Vorlage reinstellen, auf der man einfach mit Paint o.ä. markieren kann, welche Jumper gebrückt werden müssen

7. habe ich noch was vergessen, dann einfach fragen

Hier ein paar Infos zur Erstellung von SW für das SEDU-Board:

• Das Board ist letztlich nur ein Mega644p mit ein paar ICs und Steckverbindern drumrum, daher ist es Ratsam, das Datenblatt des Mega644p für Infos zu Timern, Speicher, Ports etc. zu konsultieren - Hier vorgestellte SW läuft nicht nur exclusiv auf dem SEDU, sondern auf jedem Mega644p mit entsprechender Beschaltung.
  

  
  

• Verbauter µC: Atmega644p mit 20 MHz Quarz
  

  
  

• Daraus abgeleitet kann für die Kommunikation über den FT232 eine Baudrate von 250.000, 500.000 oder 1.000.000 genutzt werden, andere Baudraten sind aufgrund von "krummen" Teilern nicht möglich - bei dem offiziellen Treiber für den SEDU wird ein "Trick" angewendet, so dass man am PC auch 115.200 Baud einstellen kann, die Kommunikation dann aber tatsächlich mit 250 k läuft - so kann man den SEDU auch mit DMXcontrol, Processing, o.ä. nutzen
  

  
  

• für den FT232 muss auf PC-Seite ein Treiber installiert werden, siehe dazu den nächsten Post für eine Anleitung.
  

  
  

• es können prinzipiell alle Ports/Pins des Mega644p benutzt werden, ein paar davon (alle auf PortD, in der SW-Vorlage "SEDU_Port" genannt) sind auf dem SEDU-Board über Jumper ggfs. festen Funktionen zugeteilt:

PortD 0 = USB oder RS485 (z.B. DMX) Rx (Empfang)
PortD 1 = USB oder RS485 (z.B. DMX) Tx (Senden)
PortD 2 = RS485 (z.B. DMX) Rx (Empfang)
PortD 3 = RS485 (z.B. DMX) Tx (Senden)
PortD 4 = CTS (Clear to Send, hiermit kann dem PC über den FT232 Empfangsbereitschaft signalisiert werden)
PortD 5 = Status-LED (die LED oben zwischen USB- und Hohlbuchse wird mit dem zugehörigen Jumper an PortD5 angeschlossen)
PortD 6 = DMX Direction, hiermit kann - wenn der Jumper geschlossen ist - der Bustreiber auf dem Board per SW von Senden auf Empfangen umgeschaltet werden

Um diese Funktionen an die Ports zu koppeln, müssen die entsprechenden Jumper geschlossen werden - wenn alle Jumper offen sind, sind sämtliche Pins mit ihren Funktionen ohne weitere Beeinflussung über die Stiftleiste "PortD" verfügbar.

Die restlichen Ports A-C werden direkt auf dem SEDU-Board nicht benutzt, und können mit ihren sämtlichen Funktionen (SPI, TWI, Analog in, etc.) über die Stiftleisten genutzt werden.

Funktionen der Jumper

hierzu ein Beispiel für ein "Standard-Setup", das mit den meisten hier veröffentlichten Firmwares funktioniert: USART0 ist an USB angeschlossen, USART1 an den RS485-Treiber (z.B. für DMX), die Richtung (senden/empfangen) kann per SW umgeschaltet werden. Versorgung über USB, die Status-LED ist angeschlossen.

Unten anbei die Vorlage für die Jumper, es sollte beim Vorstellen von SW hier im Thread dann immer die Grafik mit dazu, wie die Jumper für die Anwendung gesetzt werden müssen.

Genauere Erläuterung der Jumper im Einzelnen:

"LED": klar, hiermit wird die Status-LED oben an PortD5 angeschlossen

"Vcc": hier wird entschieden, wie der µC etc. auf dem Board versorgt wird: entweder über USB, oder extern über die Hohlbuchse
dabei wird bei externer Versorgung die Spannung über einen 78L05 für den µC geregelt, es können also (je nach Last) 7-24 V eingespeist werden.
der Jumper "bypass" dient zum Überbrücken des 78L05, dadurch können auch stabile 5 V von extern eingespeist werden
Achtung! hier unbedingt auf richtige Polung und Spannung achten, sonst kommt es zur Beschädigung des Boards!
der FT232 wird immer über den USB-Port versorgt, unabhängig von der Jumper-Einstellung

"USART": hier kann der Usart0 des Mega644p (Rx und Tx einzeln) entweder auf den FT232 oder den Bustreiber für DMX geroutet werden
Es sind div. Kombinationen möglich, z.B. empfangen über USB und senden per DMX, oder andersrum, es ist auch möglich, bei Tx alle drei Pads zu verbinden, und so gleichzeitig Daten über den Bustreiber wie auch über USB an den PC zu senden - bei Rx dürfen nur 2 Pads verbunden werden!

"CTS" verbindet den CTS-Steuereingang des FT232 mit PortD4 des Mega16

"ATm644p only": hier kann der 2. Usart des Mega644p auf den DMX-Bustreiber geroutet werden
Es is darauf zu achten, dass in diesem Fall bei USART der entsprechende Pin *nicht* auf "DMX" gelegt wird, da hierdurch sonst 2 Pins des Mega644p verbunden werden, was zur Beschädigung führen kann.

Anmerkung: Die Bezeichnung stammt noch vom "alten" Board, auf dem der Mega644p optional war, im Prinzip müsste es besser "USART1" heissen, und statt "USART" dann "USART0"

"DMX": Hier wird die Richtung des Bustreibers festgelegt: entweder fest auf senden, oder fest auf empfangen, oder per SW (über PortD6) einstellbar
Achtung! Hier darf immer nur ein Jumper geschlossen werden, keinesfalls 2 oder alle drei, da es sonst zum Kurzschluss der Versorgung bzw. Beschädigung des µC kommt.

Leider programmieren hier so wenige in Assembler, ich werde trotzdem dann noch eine SW-Vorlage reinstellen, in der dann schon mal alle Definitionen, IR-Vektor-Tabelle etc. drin sind...

Das SEDU-Board verwendet zur Kommunikation mit dem PC einen FT232-USB/Seriell-Brückenchip - für diesen muss auf dem PC ein Virtueller-Com-Port-Treiber (VCP) installiert werden, dieser stellt dann einen Com-Port zur Verfügung, über den mit dem SEDU kommuniziert werden kann (Terminal, Atmowin, Processing, DMXcontrol, ...)

den Treiber gibt es z.B. hier auf der SEDU-Board-Seite - es empfiehlt sich, diesen zu nehmen, aus zwei Gründen:

1. wird der SEDU dann im Gerätemanager auch als "SEDU-Board" angezeigt, nicht als "USB serial port" wie mit dem Original-FTDI-Treiber, und ist also schneller zu finden.

2. der Treiber wurde so modifizeirt, dass der FT232 mit 250 kBaud sendet/empfängt, wenn man am PC 115,2 k einstellt - dadurch kann man auch Processing, DMXcontrol, Freestyler etc. mit dem SEDU-Board benutzen, diese Programme stellen den VCP fest auf 115,2 k ein.

Der Treiber muss dazu "manuell" (also ohne Plug&Play-Erkennung) installiert werden, sonst nimmt Windows evtl. den falschen (also eben den Original-Treiber, falls der schon mal installiert wurde, oder bei bestimmten Windows-Versionen schon dabei ist). In XP geht das so:

Entweder Windows fragt beim ersten Anstecken nach dem Treiber, oder es installiert in automatisch - dann muss man in die Systemsteuerung gehen, Geräte-Manager, SEDU-Board anklicken (steht dann evtl. als "USB serial port" in der Liste), "Eigenschaften", und "Treiber neu installieren".

in dem dann sich öffnenden Fenster (dieses kommt auch, wenn man das Board das erste Mal ansteckt, und noch kein Treiber installiert ist) dann eben nicht automatisch erkennen lassen, sondern manuell installieren:

Dann muss man Windows noch mal sagen, dass es nicht suchen soll:

im folgenden Fenster dann einfach auf "Datenträger" klicken:

und hier dann auf "Durchsuchen":

dann kommt ein "Öffnen"-Dialog, in dem man die richtige Datei auswählen kann:

Die richtige ist eben die Datei "ftdiport.inf" in dem von der SEDU-Board.de runtergeladenen Ordner (den natürlich erst auspacken, ist ja gezippt).

Dann fragt er beim installieren evtl. noch nach weiteren Dateien ("ft2ser.sys" etc.), diese sind alle in dem Installationsordner zu finden. Ebenso kommt die Meldung, dass der Treiber nicht signiert ist, diese einfach ignorieren...

*** SW ist für "altes" SEDU-Board mit Mega16, die Version für das neue folgt noch ***

Hier nun mal die erste SW für SEDU in diesem Thread - eine Umsetzung von Mini-DMX auf WS2801/TM1804-Ausgabeprotokoll. Sprache: Assembler.

Damit können an den SEDU angeschlossene WS2801/TM1804 Strips/Pixelplatinen vom Rechner aus über mini-DMX gesteuert werden. SW am PC ist dafür z.B. Atmowin, mit dem sich ein Mehrkanal-Ambilight aufbauen lässt, oder DMXcontrol, Freestyler, etc. mit dem man über diese SW direkt WS2801-Pixelstrips steuern kann.

Es gibt auch hier im Forum eine SW, mit der man über Mini-DMX (also über dieses Teil hier dann eben WS2801/TM1804-Pixel) eine Matrix ansteuern kann, *ähnlich* wie Madrix, 2 Player, in die man jeweils versch. Animationen laden kann, überblenden, Effekte, etc. super Sache!

Der ZIP-Ordner enthält das komplette (Mini-)Projekt, die SW macht eigentlich nichts weiter, als ständig in einer Schleife die Daten aus dem RAM an die WS2801 bzw. TM1804 (für diese einfach nur Data anschließen) auszugeben, empfangen werden sie im Interrupt, immer wenn ein Byte rein kommt, wird dieses gleich verarbeitet.

Die Sende- (damit ist die gemeint, die die Daten an die WS2801/TM1804 raus schickt) und Empfangsroutine sind jeweils in einer eigenen Datei (mit Doku, welche Register benutzt werden etc.), können so also auch ganz einfach für andere Projekte verwendet werden.

Die Empfangsroutine wertet das Framesize-Byte von Mini-DMX aus, empfängt also automatisch 96, 256 oder 512 Kanäle wie angegeben - zusätzlich ist das Framesize-Byte 0xB0 implementiert, für 768 Bytes Nutzdaten (= 256 RGB-Pixel). Diese muss im Interrupt ausgeführt werden, immer wenn ein Byte empfangen wurde (Rx complete).

dazu gehört die Routine "_ISR_Byte_Transmitted.inc", diese muss ebenfalls im Interrupt (Tx complete) ausgeführt werden, diese schickt den Mini-DMX-Ack raus.

Die Senderoutine kann zusätzlich die Farbreihenfolge tauschen (bei manchen Strips stimmt die nicht, ist also nicht RGB) und mehrere LEDs zu einem Pixel zusammenfassen (das wurde bei der Ambilight-SW für größere TVs so gemacht). Wird diese aufgerufen, schickt sie den kompletten Datenblock raus, danach muss ca. 1 ms bis zum nächsten Aufruf gewartet werden, damit die WS2801 die Daten übernehmen.

Natürlich kann die Sende-Routine auch z.B. in nem Timer-Interrupt 25x pro Sekunde aufgerufen werden o.ä., damit der µC in der Wartezeit noch andere Dinge machen kann.

Hier sind für Anfänger die wichtigsten Einstellungen in einer eigenen Datei ("settings.inc") zusammengefasst, können dort geändert und dann das Projekt neu assembliert werden:

; ================================================================================================
; SEDU-Ambilight/mDMX-Receiver
;
; benutzerdefinierte Einstellungen
; ================================================================================================


.equ BAUD_MDMX			= 250000		; Baudrate Mini-DMX-Empfang


.equ RGB_ORDER			= 0			; RGB-Reihenfolge:
							; 0 = nicht tauschen
							; 1 = tauschen RGB -> GRB
							; 2 = tauschen RGB -> RBG
							; 3 = tauschen RGB -> BGR
							; 4 = tauschen RGB -> BRG
							; 5 = tauschen RGB -> GBR


.equ PIX_REPEAT			= 1			; LEDs pro logischem Pixel


.equ Pix_COUNT			= 256			; Pixel-Anzahl (1-256)
.equ Pix_PORT 			= PortC			; Ausgabeport WS2801/TM1804-Daten
.equ Pix_DDR 			= DDRC			; DDR WS2801/TM1804-Daten
.equ Pix_SDO			= 0			; Ausgabepin WS2801/TM1804 Data
.equ Pix_SCO			= 1			; Ausgabepin WS2801 Clock


; ================================================================================================

Im Ordner ist auch eine fertige Datei (.hex), die über den Bootloader auf den SEDU übertragen werden kann, mit obigen Standardeinstellungen.

Die Jumper müssen hierfür auf USB-Betrieb stehen:

wobei die Stromversorgung natürlich auch von extern kommen kann. Ich persönlich würde hier den SEDU über USB versorgen, und die Pixel/Strips dann extra über ein externes NT. Wichtig dabei: GND des externen NT und GND vom SEDU müssen natürlich auch verbunden werden.

Da immer wieder nach einer einfachen Möglichkeit gefragt wird, "mal ein paar LEDs über USB zu steuern", habe ich dazu mal was gemacht.

Die SW erzeugt 24 Kanäle SW-PWM mit 306 Hz, man kann damit also 24 einzelne LEDs dimmen, oder 8x RGB, oder 6x RGBW, oder 8 Gruppen RGB-Stripes, auch gemischt, halt einfach ein 24-Kanal-Dimmer.

Gesteuert wird das Teil über USB mit dem Mini-DMX-Protokoll - auf PC-Seite kann man also Standard-SW verwenden wie z.B. Freestyler, DMXcontrol, PCdimmer, o.ä., halt alles, was Mini-DMX ausgeben kann. Auch eigene SW z.B. mit Processing zu machen ist ganz einfach, weil das Protokoll wirklich total simpel ist.

Mit den entsprechenden Plugins zur jeweiligen SW lässt sich damit dann auch "Sound2Light" machen, also dass die Lichtprogramme z.B. passend zur in Winamp abgespielten Musik ablaufen o.ä. - Wem 8 Kanal Ambilight reicht, der kann damit auch per Atmowin normale RGB-Strips in 8 Zonen ansteuern, braucht also keine "digitalen Strips"...

Zusätzlich gibt die SW alle empfangenen Kanäle per normalem DMX aus - man kann also ohne weitere zusätzliche HW (Auf dem SEDU ist ja bereits ein RS485-Treiber drauf) dann zusätzliche DMX-Geräte ansteuern - oder das auch gleich nur als DMX-Interface benutzen.

Die DMX-Kanäle, auf die die 24 Ausgänge reagieren, lassen sich frei zuweisen, mittels einer Tabelle (Datei "DMX_Patchtable.inc"):

; ================================================================================================
; 24-Kanal-PWM mit Mini-DMX-Empfang für SEDU-Board V2.0
; Patchtabelle DMX-Kanäle -> PWM-Outputs
; ================================================================================================


DMX_PATCHTABLE:


	.dw     1,   2,   3,   4,   5,   6,   7,   8	; PortA 0-7
	.dw     9,  10,  11,  12,  13,  14,  15,  16	; PortB 0-7
	.dw    17,  18,  19,  20,  21,  22,  23,  24	; PortC 0-7


; ================================================================================================

heisst hier also: DMX-Kanal 1 kommt an PortA0 raus, Kanal 2 an PortA1, usw., bis Kanal 24 an PortC7

das ist insbesondere hilfreich, um das Layout zu vereinfachen, z.B. eine RGB-LED hängt vom Layout besser passend "durcheinander" an PA0, PB4 und PB7, soll aber die DMX-Kanäle 1-3 belegen, dann lässt sich das hier zuordnen - oder man hat nur noch verstreute Adressen frei, z.B. von 1-6, und dann erst wieder ab 64, kein Problem, lässt sich beliebig zuordnen...

so lange keine Daten empfangen wurden, zeigt die SW eine Grundeinstellung an, diese lässt sich hier (Datei "Startup-Colours.inc") einstellen:

; ================================================================================================
; 24-Kanal-PWM mit Mini-DMX-Empfang für SEDU-Board V2.0
; Standalone-Farben nach Reset
; ================================================================================================


STARTUP_COLOURS:


	.db    128, 128, 128, 128, 128, 128, 128, 128	; PortA 0-7
	.db    128, 128, 128, 128, 128, 128, 128, 128	; PortB 0-7
	.db    128, 128, 128, 128, 128, 128, 128, 128	; PortC 0-7


; ================================================================================================

eben wieder die Werte der Reihe nach für die Ports, da kann es dann natürlich "durcheinander gehen", wenn die RGB-Kanäle nicht aufeinander folgen - aber dafür dann noch mal ne Patchtabelle zu machen, wäre auch Blödsinn... hier im Beispiel sind eben alle Kanäle nach dem Einschalten auf halber Helligkeit...

Die Status-LED wird nach Empfang eines kompletten Frames getoggelt, flackert also mit halber fps-Frequenz und gibt so einen Überblick, wie schnell die Daten rein kommen, bzw. ob überhaupt - es läuft ein Timer mit, nach 1 Sek. ohne Datenempfang geht die Empfangsroutine auf "Start".

In diesem Zustand sucht sie auch nach dem Bootstring "seduboot", man kann also dann neue SW mit dem Bootloader flashen, ohne den Reset-Knopf drücken zu müssen - dies soll in Zukunft bei jeder SEDU-Firmware so sein, oft ist das Teil ja in nem Gehäuse verbaut, so dass man schlecht an den Reset-Knopf hin kommt... sollte das Wort zufällig mal im Datenstrom vorkommen (Wahrscheinlichkeit 1 zu 18.446.744.073.709.551.616 :D), dann macht das nichts, darauf wird nur geprüft, nachdem mind. 1 Sek "Sendepause" war...

Hier noch die Belegung der Löt-Jumper:

wobei man die Stromversorgung natürlich auch von extern machen kann, so dass der SEDU auch komplett ohne PC angeschlossen zumindest die Grundeinstellung zeigt - DMX wird jedoch erst gesendet, nachdem was empfangen wurde, das läuft direkt synchron...

Dafür wird dann noch ein Aufsteckboard mit 3x ULN2803 kommen, sowie eins mit 24x MOSFET (für "mehr Power"), das ergibt dann eben nen schönen kompakten Plug&Play-Controller, mit dem man LEDs vom PC aus steuern kann, ohne z.B. extra DMX-Interface und dann wieder DMX-Receiver dazu...

Geplant ist ausserdem noch eine Version mit 27 Kanälen (die dann ohne DMX-Ausgabe, zu wenig Pins), wäre dann genau richtig für eine 3x3-RGB-Moodlight-Matrix.

Sowie eine Version, die per Multiplexen 48 Kanäle macht (dann mit 150 Hz, immer noch besser als die üblichen China-Controller), damit kann man dann z.B. ne 4x4 RGB-Matrix ansteuern...

Da schon paar mal danach gefragt wurde, hier eine SW, die DMX empfängt, und damit WS2801-Pixel ansteuert.

die ist noch nicht ganz fertig, es soll noch ein Standalone-Programm (Rainbowfader, feste Farbe o.ä.) rein, das dann abläuft, wenn keine Daten empfangen werden. Ausserdem die DMX-Adresse per DIP einstellbar, wenn man nur ein paar Kanäle braucht... das kommt dann später noch.

Momentan setzt sie alle 510 (= 170 Pixel, zwei Byte bleiben "über") Kanäle um ab Startadresse 1 - das sollte auch für viele so passen, meist steuert man ja gleich einen Haufen Pixel also eh' (fast) ein ganzes Universe an - ansonsten kann man die Startadresse in der Datei "Definitions.inc" ändern und neu assemblieren...

Die Ausgaberoutine ist fest auf 170 Pixel eingestellt, hierzu noch folgender Hinweis: Die Daten werden in einer ISR per DMX empfangen, bei komplettem Frame an die Pixel ausgegeben - da die Ausgabe wesentlich schneller erfolgt als das empfangen eines Frames über DMX, entsteht so die nötige 500 µs-Pause für die WS2801 "automatisch".

Schickt der DMX-Sender aber deutlich weniger Kanäle als 512 raus (z.B. kleines Lichtpult o.ä., die schicken oft nur die benutzten 4-24 Kanäle raus) muss die Pixel-Anzahl bei der Ausgabe auch verringert werden, da sonst die Ausgabe evtl. länger dauert als das empfangen, und somit die Pause für die Datenübernahme wegfällt.

Das macht man über die Angabe von PIX_Count ebenfalls in der Datei "Definitions.inc" (momentan auf 170 eingestellt).

Hier noch die Jumper als Beispiel, die Status-LED toggelt bei jedem empfangenen Frame, der Bustreiber wird per SW auf Empfangen umgeschaltet:

DMX wird dann unten an diese 3-polige Stiftleiste für RS485 angeschlossen. WS2801-Signal kommt an PortC raus, 0 = Data, 1 = Clock.

Hier nun eine SW, die das hier im Forum entwickelte Protokoll tpm2 empfängt, und die Daten an Pixel/Stripes mit WS2801/WS2811 oder TM1804 etc. ausgibt.

Damit lassen sich Matrizen aus solchen Pixeln mit der SW "Glediator" steuern, oder über den Artnet/tpm2-Node von jeder SW, die Artnet ausgeben kann (Siehe Forum "LED Schaltungen, Treiber und µC").

Ausserdem lässt sich die SW in Verbindung mit "digitalen Stripes" und entsprechender SW auf dem Rechner (Boblightd, DFAtmo, SEDUAtmo, ...) als Mehrzonen-Ambilight nutzen.

EDIT 18.11.2012: Da hier von Besitzern eines alten SEDUs nachgefragt wurde, unten noch die .hex-Dateien für den alten SEDU mit Mega16 (M16) - bei einer Version Rot und Blau getauscht. da gehen dann 250k, 500k und 1Mbit als Baudraten.

Projekt wie üblich komplett anbei - die .hex kann direkt mit dem Bootloader auf's SEDU geladen werden, wer am Quellcode rumschnitzen will, sehr gerne, bitte dann auch wieder hier veröffentlichen.

Wie üblich kann man div. Sachen in der Datei Settings.inc einstellen:

; ================================================================================================
; Konverter von tpm2-Protokoll auf WS2801/WS2811/TM1804
; Benutzerdefinierte Einstellungen
; ================================================================================================


.equ USB_BAUD			= 1		; Baudrate USB-Empfänger (0 = 250k, 1 = 500k, 2 = 1,25M)


.equ DATA_FRAMESIZE_MAX	= 3072			; Maximale Größe tpm2-Datenframe (fest lassen!)


.equ PIX_COUNT			= 1024		; WS2801-Pixel-Anzahl (logische Pixel, max. 1024)
.equ PIX_PORT 			= PortC		; Ausgabeport WS2801/TM1804-Daten
.equ PIX_DDR 			= DDRC		; DDR WS2801/TM1804-Daten
.equ PIX_SDO			= 0		; Ausgabepin WS2801/TM1804 Data
.equ PIX_SCO			= 1		; Ausgabepin WS2801 Clock


.equ RGB_ORDER			= 0	; Farbreihenfolge WS2801-Pixel:
						; 0 = nicht tauschen
						; 1 = tauschen RGB -> GRB
						; 2 = tauschen RGB -> RBG
						; 3 = tauschen RGB -> BGR
						; 4 = tauschen RGB -> BRG
						; 5 = tauschen RGB -> GBR


.equ START_R			= 0		; Startfarbe Rot
.equ START_G			= 0		; Startfarbe Grün
.equ START_B			= 100		; Startfarbe Blau


.equ SA_R			= 0		; Standalonefarbe Rot
.equ SA_G			= 0		; Standalonefarbe Grün
.equ SA_B			= 100		; Standalonefarbe Blau


; ================================================================================================

Wirklich interessant sind hier nur die Farbreihenfolge, sowie die Startfarbe, die angezeigt wird, bevor das Teil zum ersten Mal Daten bekommt.

Ausgegeben werden diese an Port C, C0 ist Daten, C1 ist Clock, bei WS2811 und TM1804 nur C0 verwenden.

Die Baudrate ist erst mal auf 500 k eingestellt, damit gehen sinnvoll um die 600 Pixel bei 30 fps, das passt für die meisten "Zuhause-Matrizen" - ausgegeben werden immer 1.024 Pixel, das ist dann auch das Maximum - wenn man weniger anschließt, macht das nix, die "überschüssigen" Bits werden einfach "in's Leere geschoben".

Update 12.11.2012: Es wurde noch ein Timeout-Zähler eingebaut, wenn der Datenstrom für mind. ca. 1 Sekunde aussetzt, wird ein Standalone-Programm aktiviert, dies besteht i.M. aus einer festen Farbe, die auf allen Pixeln angezeigt wird.

Ausserdem wird jetzt die Zahl der empfangenen Bytes für die Ausgaberoutine übernommen, es werden immer so viele Pixel ausgegeben, wie empfangen wurden - der Eintrag in der Settings.inc ist nur noch für Startfarbe und Standalone-Programm relevant.

Es kommt dann noch ein weiteres Update, bei dem man diese ganzen Parameter (Farben tauschen, Startfarbe, Standalone-Farbe) per tpm2-Befehlen einstellen kann.

Ich habe hier spaßeshalber mal ne automatische Baudratenerkennung eingebaut - die kann natürlich nicht *alle* Baudraten einstellen (geht von der HW her auch garnicht), sie schaut halt, gibt es Frame Errors, dann stimmt was nicht, dann wird die nächste Baudrate ausprobiert, bis es passt - habe ich ausgiebig getestet, in Glediator hin- und her geschaltet, dauert max. 1, 2 Frames, dann ist die Baudrate umgestellt.

Leider kann das Teil (wegen dem Systemtakt 20 MHz) nicht auf 1 Mbit empfangen (die für 1.024 Pixel am Eingang nötig wären), es geht hier "nur" 1,25 MBit - das kann Glediator nun ab Version 1.1 ausgeben!

hier noch die Vorschläge für die Jumper, wichtig ist halt, dass der USART0 an USB dran ist, der Rest mehr oder weniger wurscht (wie's halt gewünscht ist, Versorgung über USB oder extern, direkt 5 V oder mehr, ...)

Hier mal eine einfache SW, um mit dem PC DMX-Daten empfangen zu können - wurde hauptsächlich deswegen gemacht, weil man die Matrix-Steuer-SW "Jinx!" so auch per DMX steuern kann.

immer wenn ein DMX-Frame empfangen wird (wird anhand des Startbytes erkannt), wird der vorangegangene Frame weiter geschickt. Der letzte empfangene also nicht mehr. Da DMX drauf ausgelegt ist, dauerhaft zu senden, macht das aber nichts. Das ging nicht anders, da bei unbekannter Kanalzahl nicht festgestellt werden kann, wann denn nun ein DMX-Frame komplett empfangen wurde.

Die Daten kommen dann im PC über USB im Format tpm2 rein, und können dort weiter verarbeitet werden. Das ist schon alles was die SW macht und kann, reicht ja auch

Damit man im PC nicht sehr viele Daten empfangen muss, wenn eigentlich nur ein paar interessieren, kann man in der SW auch die Anzahl der zu empfangenden Kanäle (DMX_CHANNELS) und Startadresse (DMX_STARTADRESS) einstellen (in der Datei Definitions.inc, dann neu assemblieren) - es wäre auch denkbar, das über DIPs zu machen, oder Konfiguration per tpm2-Befehle, o.ä.

Es ist auch ein Bootloader-Suport dabei, beim Chip45-Bootloader einfach den Bootstring "seduboot" verwenden, so kommt man auf das Teil, ohne den Reset-Knopf drücken zu müssen.

anbei das komplette Projekt inkl. .hex-Datei, es ist auch eine dabei, die nur 3 Kanäle ab Adresse 1 empfängt (z.B. für Jinx!)

Und hier wieder die Jumper als Beispiel, die Status-LED toggelt bei jedem empfangenen Frame, der Bustreiber wird per SW auf Empfangen umgeschaltet: