Hallo, ich habe ein Problem mit dem angehängten Quelltext, den ich mit Hilfe der DMX-Tutorials von http://www.hoelscher-hi.de/hendrik/ erstellt habe. Das Problemt besteht darin, dass das erste DMX-Byte als Startbyte interpretiert wird. Das heißt: Der Code funktioniert soweit. Wenn ich Die Adresse auf Kanal 1 eingestellt habe, reagiert das Teil erst auf DMX-Kanal 2. Die Kanäle sind also um eins versetzt. Sobald DMX-Kanal 1 einen anderen Wert als 0 hat, wird nichts mehr empfangen. Ich habe mal testweise den Quelltext so geändert, dass das Startbyte mit 255 verglichen wird. dann werden nur DMX-Daten empfangen, wenn ich Kanal 1 am Pult auf 255 stelle. Irgendwie wird da ein Byte verschluckt. Vielleicht sieht ja einer von euch einen Fehler. Vielen Dank im Voraus! Gruß Benedikt Patt
Da gibt es keinen Fehler, das ist das "normale" DMX-Verhalten: * StartCode, muss NULL sein * Datenbytes, bis zu 512 * Break * Mark after Break Aus meinem Strand-Lighting DMX-Manual: ...for this reason, a dimmer receiver must not accept as 8-bit level data, any packet with START CODE other than NULL START following the RESET. Also, frei übersetzt: wenn das erste Byte NICHT NULL ist, dann darf der Dimmer die Daten nicht annehmen. Mit was erzeugst Du denn Deine DMX-Signale? Gruß, Stefan
Hallo, Danke erst mal für deine schnelle Antwort! Das das Startbyte Null sein muss, ist mir klar. Mein Problem ist nur, dass der erste DMX-Kanal von meinem Pult (habe auch schon andere Pulte getestet) als Startbyte interpretiert wird und der 2.Kanal erst als erstes Datenbyte. Daher denke ich, dass das 'echte' Startbyte irgendwo verschluckt wird. Im Simulator funktioniert das alles ganz toll... Gruß benne
Vielleicht empfängst Du mehr als einen Frame-Error. Das würde Dein Problem jedenfalls erklären. Benutzt Du einen Quarz für den AVR? Ändere doch mal Deinen Code so ab: frame_error: clr dmx_status ;dmx_status definiert auf 1 setzen inc dmx_status ;(damit sind auch mehrere Frame_Error mögl.) cbi UCSRA,FE ;clear flag clr dmx_byte_counter ;dmx_byte_counter zuruecksetzen ldi Ramh_write,0x00 ;RAM Adresse für DMX Werte setzen ldi Raml_write,0x60 reti Noch besser wäre es, wenn Du bei einem Frame-Error das empfangene Byte auf NULL testest und bei <> NULL den dmx_status auf NULL setzt. Und BITTE! formatiere Deinen Code anständig. Wenn schon Assembler, dann wenigstens von der Formatierung einigermassen lesbar. Auf Code ohne eine einzige Einrückung werde ich nicht mehr antworten. Gruß, Stefan
Danke für deinen Tipp! Also für den AVR verwende ich einen 8MHz Quarz. Ich habe den Code abgeändert und auch eingerückt ;-) Sorry, das war mein erster ASM-Code, da habe ich noch nicht so drauf geachtet... wobei das natürlich besser gewesen wäre. Ich kann den Code leider heute Abend erst testetn. Ich bin mir nicht mehr sicher, ob ich die genannte Änderung nicht schonmal gemacht habe. Ich melde mich dann nochmal, ob's funktioniert hat. Gruß Benedikt
Hallo Benedikt,
ich glaube, ich habe Deinen Fehler gefunden. Schau mal im Datenblatt
ATmega16 auf Seite 154 unter "Receiver error Flags":
"Due to buffering of the error flags, UCSRA must be read before the
receive buffer (UDR), since reading of the UDR I/O location changes the
buffer read location."
Auf Deutsch:
Das FE-Flag gibt es nicht nur einmal, sondern für jedes Byte des
Eingangspuffers (der UART des mega ist doppelt gepuffert). Liest Du
jetzt zuerst UDR und dann UCSRA, dann holst Du das falsche FE-Bit.
Drehe mal
get_byte:
in dmx_Byte,UDR ;get data
in temp,UCSRA ;get USART state
so um:
get_byte:
in temp,UCSRA ;get USART state
in dmx_Byte,UDR ;get data
Viele Grüße, Stefan
Hallo Stefan, du hast mein Problem gelöst! Nun funktioniert alles. Für alle die es Interessiert, habe ich den funktionsfähigen Code nochmals angehangen. Abhängig von den DMX Werten werden die Ausgänge von Port B an oder aus geschaltet. Vielen dank nochmal!! Gruß Benedikt
Herzlichen Glückwunsch! Du hast meinen Code geschreddert, hast mit Hilfe des Forums die übelsten Bugs gefunden und implizierst, dass dieses Konstrukt nun irgendwie brauchbarer wäre als der Ausgangscode... Ich weiß, dass ist jetzt nicht wahnsinnig konstruktiv und Du bist von deiner Leistung wahrscheinlich völlig begeistert - für mich ist dieser Thread allerdings ziemlich frustrierend. Hendrik PS: Bitte haltet Euch (wenigstens zunächst) an den Ursprung: www.hoelscher-hi.de/hendrik/light/ressources.htm (und packt dann ggf. mit 'st X+, dmx_byte' die Daten in das Array ;-)
>Du hast meinen Code geschreddert, hast mit Hilfe des Forums die >übelsten Bugs gefunden und implizierst, dass dieses Konstrukt nun >irgendwie brauchbarer wäre als der Ausgangscode... Hat er das behauptet? Ich kann das jedenfalls nicht aus dem OP herauslesen. Er verweist doch extra auf Deine Seite. Vielleicht hat er einfach nur selbst versucht, das ganze "Konstrukt" zu verstehen und hat dann hier nachgefragt. Ich finde da gar nichts frustrierendes... Naja, nur mein Senf ;-)
@Patrick: Hast Recht. Ich sollte nach 2h Kleinkrieg mit dem gcc nicht mehr posten... Grüße, Hendrik
Vielleicht solltest Du ja auch einfach mal fragen... ;-)
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.