Hallo zusammen, nach nun zwei recht frustrierenden Wochen muss ich mich doch mal mit der Bitte um Hilfe an euch wenden. Ich bin beim Räumen wieder auf meine AVR Kiste gestoßen, was meist nicht gut endet. Ziel war es eigentlich nur einen kleinen DMX empfänger zu bauen. Zusammen mit Hennes lib, bei der es ja eigentlich nicht viele Fehler zu begehen gibt sollte das auch schnell gehen, aber da begannen die Probleme... Bei der Suche im Forum bin ich schon über einige Themen dazu gestoßen, die aber leider alle in C waren und mir somit nicht viel weiter geholfen haben (ich muss dazu sagen, das ich C dabei nicht verwenden möchte, auch wenn ich in meiner Verzweiflung schonmal das ganze in C durchgespielt habe, mit ähnlichem Ergebnis). Ich habe mittlerweile schon alles in eine Datei geschrieben und soweit zusammen gepackt und Dokumentiert, dass es hoffentlich übersichtlich genug ist. Benutzte Bauteile: ATMega16@16Mhz ext. Quarz Busbaustein: SN75176BP Die Beschaltung ist recht einfach: Die Datenleitungen vom 75176 sind an Rx und TX (PD0 und PD1) sowie die Richtungsleitung an PD2. In meiner Verzweifelung ist mittlerweile auch die DMX Leitung am Board terminiert (120 Ohm) um weitere Störungen auszuschließen. Das DMX Signal ist sauber und kommt von einem DE interface oder optional von einer Easylase, um auch da Fehler auszuschließen. Die zu schaltende LED liegt auf PA4 und funktioniert auch ;-) Die Ports A,B und C sind as Ausgänge geschaltet und Theoretisch gerade zu Debugzwecken mit LEDs versehen. DIP schalter kommen nicht zum Einsatz, um da auch die Fehlerquelle ausschließen zu können. Quarz schwingt, Fuse-Bits sind in Ordnung. Jetzt zum Fehler: Die Startadresse sollte 1 sein. Es passiert nur ... nichts. Etwas verwundert hat mich allerdings, dass die LED nach kurzer Zeit anfängt zu leuchten, wenn ich Kanal 2 und 3 auf 255 stelle. Laut Debugversuchen lande ich auf jeden Fall im FE und bekomme auch das Startbyte. Wenn ich mich mal spaßeshalber immer die empfangenen Bytes auf einem Port rausschmeissen lasse, kann ich auch ganz PWM like die Daten sehen ;-). Meine erste Vermutung war eine Falsche USART Baud einstellung aber mit "3" laut Hennes berechnung und nach dem Datenblatt (Seite 171) liege ich damit richtig. Eine weitere Vermutung lag darin, die Startadresse falsch eingebaut zu haben (keine inversion, da nicht über DIPS eingelesen), was aber immernoch nicht das plötzliche leuchten der LED erklärt. Da mag aber auch ein Fehler liegen. Bevor ich es vergesse zu erwähnen: ich habe den Code auch schon mehrfach im Simulator durchgespielt, bin aber auch dort nicht auf die Lösung des Problems gestoßen. Das Board des Atmels ist fehlerfrei und funktionstüchtig mit jeglicher anderen Software. Um dem theoretischen Problemausschluss vorzubeugen, möchte ich dazu sagen, dass ich Atmels nicht fremd bin und das Verständnis des DMX Protokolls und Hennes Code eigentlich auch nicht das Problem sein sollte. Ich hoffe, nur einen kleinen Fehler übersehen zu haben. Vielen Dank schonmal für die Hilfe, Grüße, Daniel
Nochmal zum vorliegenden Signal: habe es gerade nochmal mit richtiger DMX Hardware getestet. Das Eingangssignal ist OK. Grüße, Daniel
Ist die FW von Henne nicht für ein 8515 geschrieben?
Hast du mal die DMX Empfangsroutine übersprungen? Also einfach oben in dem Interrupt Vector mal wieder ein reti rein machen. Passiert dann das selbe mit deiner LED? geht die dann trotzdem an?
Ja, die lib ist für den 8515 geschrieben, aber ich habe versucht, alles soweit zu überarbeiten, dass es auch auf dem ATMega16 laufen sollte. @Steffen Hab ich gerade mal getestet, aber da tut sich nichts. grüße, daniel
muss das nicht DMX_FIELD = 0x0060 heißen? Adresse ist doch 16bit, oder?
Ja, die LED Bleibt aus bei nicht belegtem Interrupt. also im Simulator schreibt er es an die erste Stelle vom Databereich und im Datenblatt steht, dass das SRAM im $0060 startet.
ok, auch nach einem test auf sicherheit, ist der wechsel auf 0x0060 beim SRAM start erfolglos... aber eine gute idee war es.
Der Fehler liegt irgendwo hier: dmx_startbyte: tst tempH ;if null-> Startbyte brne dmx_err inc DMXstate ;next -> start address ldi XL, low(0x0001) ;get start address for dummys. Liegt hier der Fehler? clr XH rjmp dmx_finish dmx_startadr: sbiw XH:XL, 1 brne dmx_finish ldi XH, high(DMX_FIELD) ldi XL, low(DMX_FIELD) inc DMXstate ;next-> data handler dmx_handle_byte: st X+, tempH cpi XL, low(DMX_FIELD +DMX_CHANNELS) brne dmx_finish cpi XH, high(DMX_FIELD +DMX_CHANNELS) brne dmx_finish clr DMXstate rjmp dmx_finish
Du initialisierst Pointer X mit "1" wenn du das Startbyte(0) erfolgreich gefunden hast. Beim nächsten Einsprung in den IRQ bekommst du ja schon das 1.Datenbyte von CH1. Der X-Pointer wird dann "0" und wird dadurch mit deiner Datenadresse im SRAM geladen und speichert die Date von CH1 auf den 1.Platz.
Also wenn du ein richtiges DMX-Signal hast, sollte es doch gehen.. Werd es jetzt selber mal testen.
>>Du initialisierst Pointer X mit "1" wenn du das Startbyte(0) erfolgreich >>gefunden hast. Ja, dann bin ich im DMX state 1, bzw danach 2 >>Beim nächsten Einsprung in den IRQ bekommst du ja schon >>das 1.Datenbyte von CH1. ja, und jetzt muss ich solange runterzählen, bis ich bei Null bin, um mein gewünschtes Byte zu finden. >>Der X-Pointer wird dann "0" und wird dadurch >>mit deiner Datenadresse im SRAM geladen und speichert die Date von CH1 >>auf den 1.Platz. Soweit korrekt, aber wo ist da ein Fehler? Ich lade das Byte an den Speicherplatz, wo es hin soll. Der Text ist von Henne übernommen und sollte eigentlich da keine Fehler aufweisen. Aber danke fürs direkte testen.
evtl. sollte ich das ganze nochmal from scratch bauen... aber warum immer das rad neu erfinden? :-) Ich finde Hennes Lib eigentlich Klasse, um an dieser stelle nochmal seinen Code und das Bereitstellen für alle zu würdigen.
Tja, aber in meiner Simulation wird UBBRH auf 0x8E gesetzt wenn du UCSRA beschreibst!
Ein Bug im Simulator? Eigentlich sollte doch durch UMSEL=1 UCSRA beschrieben werden.. komisch
Tja sorry, hab aber im Moment kein DMX Signal da zum testen.
hmm, ich sehe es gerade auch... irre aktion... würde sinnfreien empfang erklären... aber wie kommt das zustande?
kk, vielen Dank schonmal ich werde mal weiter mein Glück probieren. Meine Vermutung wäre jetzt, das ich eine falsche Baudrate erwische, und das 1. Byte nur finde, wenn ich 2 mal den Wert 255 auf Ch. 1 und 2 habe und das als 1. Byte empfangen wird ...
oh, kommando zurück, die 0x8E kommen durch das URSEL UCSZ0 und USBS ;-) ich bin anscheinend durcheinander...
OK, neue überprüfungen... Evtl. kann jm. damit ja etwas anfangen: füge ich in den Code bei:
1 | dmx_startbyte: |
2 | out PORTC,tempH |
3 | tst tempH ;if null-> Startbyte |
4 | brne dmx_err |
5 | inc DMXstate ;next -> start address |
6 | |
7 | ldi XL, low(0x0001) ;get start address for dummys |
8 | clr XH |
9 | rjmp dmx_finish |
das "out PORTC,tempH" ein und betrachte das Ergebnis, dann sehe ich permanent die erste LED leuchten und zeitweise die Zweite flackern (vorausgesetzt, alle Ch sind auf 0 gesetzt) ich schließe jetzt mal daraus, dass evtl. etwas mit den USART Einstellungen nicht stimmt... Wobei: URSEL stimmt UCSZ0 und UCSZ1 stimmen (8-Bit) und USBS auf 2 Stoppbits ist auch richtig...
Hi, warum ldi tempL, (1<<URSEL)|(3<<UCSZ0)|(1<<USBS) und nicht ldi tempL, (1<<URSEL)|(1<<UCSZ0)|(1<<USBS) ??? Gruß Sven
siehe Datenblatt (s. 167): UCSZ0 = 1 UCSZ1 = 1 macht 8 bit
Ok, weiter zurück. Mal nachgeschaut, was eigentlich im Main immer so compared wird und siehe da, die Speicherstelle ist definitiv immer 0x00. Es wird also schonmal nichts gespeichert. Mal weiter eingrenzen...
;-) neue Messung. wenn ich bei allen FE's einfach mal einen counter erhöhe, wie z.B. so:
1 | dmx_frame_error: |
2 | inc errors |
3 | ldi DMXstate, 1 ;FE detected as break |
4 | cbi UCSRA,FE |
5 | rjmp dmx_finish |
und den counter bei jeder abfrage der Startadresse lösche (also ein sauberes Startbyte empfangen habe) z.B. da:
1 | dmx_startbyte: |
2 | tst tempH ;if null-> Startbyte |
3 | brne dmx_err |
4 | clr errors |
5 | inc DMXstate ;next -> start address |
und das ganze mal ausgeben lasse (natürlich invertiert)... Dann habe ich einen total gechillten etwas ungleichmäßigen aber doch sehr schön anzusehenden Binärzähler... Es bleibt für mich also nur die vermutung, dass einfach nur Müll empfangen wird... SN75176 ist getauscht, ohne besserung ... Weiss jm. ob der Mega16 sonst noch irgendwelche tollen einstellungen für den USART braucht, die ich übersehen habe? Danke schonmal, Daniel
Und Du hast definitiv richtig gefused auf 16Mhz, also CKOPT steht auf 0 ?? Gruß Sven P.S.: Und zu meiner Frage weiter oben, ich hatte mich etwas unklar ausgedrückt..... Um es besser lesen zu können hätte ich so etwas vorgeschlagen: ; Frame-Format: 8 Bit in tempL,UDR clr tempL out UCSRA,tempL ldi tempL, (1<<RXCIE) | (1<<RXEN) out UCSRB, tempL ldi tempL, (1<<USBS)|(1<<URSEL)|(1<<UCSZ1)|(1<<UCSZ0); out UCSRC, tempL
Hi Daniel, mir ist noch als Fehler eingefallen, das Du vielleicht A und B am 75176 vertauscht hast ? Gruß Sven P.S.: Gib doch mal nen Status ob Du es schon gelöst hast. ;-)
Bin gerade erst von einem Event zurück ;-) Hab mich jetzt 4 Tage mit Technik rumgeschlagen und werde mich ab morgen wieder ran setzen ;-) Aber danke schonmal. Grüße, Daniel
Hi Daniel, habe den Code von Dir ein wenig verändert. 1. mega8def-File 2. die ganzen nops aus dem ISR Bereich raus 3. die letzten beiden ISR retis auskommentiert, da m8 nur 19 besitzt 4. PB1 als LED benutzt. Anode an VCC, Kathode mit Widerstand an PB1. 5. PORT A,B,C generell mal auskommentiert, und nur PB1 auf Ausgang Bus ist ganz normal über Tx,RX und PD2 (Enable) angeschlossen. Frequenz: 16Mhz Fazit: Es funktioniert ! Kanal 1 schaltet LED bei Werten >=127 ein und drunter aus. ;-) Für den Mega16 müsstest Du das def File ändern und die 2 reti wieder auskommentieren. (ISR für UART_RECV_COMPLETE liegt bei beiden an 12. Stelle ;-) ) Dann muss das gehen ;-) !!!! Gruß Sven
@ Sven K. (svenk) >Für den Mega16 müsstest Du das def File ändern >und die 2 reti wieder auskommentieren. >(ISR für UART_RECV_COMPLETE liegt bei beiden an 12. Stelle ;-) ) >Dann muss das gehen ;-) !!!! AUA! Das geht NICHT! Der Mega 8 hat 1 Word pro ISR Vektor, der Mega 16 ZWEI!!! MfG Falk
Falk Brunner schrieb: > > AUA! Das geht NICHT! Der Mega 8 hat 1 Word pro ISR Vektor, der Mega 16 > ZWEI!!! > Asche über mein Haupt. Gut dann muss er seine eigenen reti Definitionen von oben verwenden und belassen. @Falk: Danke, das Du so aufmerksam mitliest. Gruß Sven
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.