Hallo zusammen, ich richte heute voller Hoffnung meine Bitte an Euch: Gibt es jemand der mir dabei helfen kann, das von Hoelscher für den Atmega8515 geschriebene Programm auf einen Atmega8 anzupassen? Oder auch ein ähnliches. Ich dreh langsam durch!!! Seit über einer Woche bin ich an diesem Thema dran und anscheinend wirklich zu blöd das alleine zu schaffen. Mein Ziel ist es, den ATmega8 derart zu programmieren, dass dieser DMX-Signale vom Kanal 1 (NOCH keine variable Adresseinstellung nötig) empfängt und ab >127 eine LED leuchten lässt. Das hört sich eigentlich sehr primitiv an, ich scheitere aber massiv daran. Und bitte glaubt mir: Ich habe ALLES an Tutorials und Vorlagen im Nezt durchwühlt. Wie man sieht Ergebnislos!!! Mein Equipment: WinAVR-20080512 AVRStudio 4.13 STK500 ATmega8 mit externem Clock von 8MHz Ich wäre Euch sehr dankbar. Beste Grüße Jürgen P.
Hallo, wo genau hast du denn Probleme? Eigentlich sollte das mit dem DMX Tutorial von Hendriks Seite zu machen sein. Da steht ja alles über den Empfang drin. Alles was du sonst noch brauchst solltest du im AVR Tutorial auf dieser Seite finden. Gruß Benedikt
Hallo Benedikt, vielen Dank für Deine Antwort. Wo genau ich das Problem habe, weiß ich leider nicht. Sonst würde es ja funktionieren. Ich habe mittlerweile mind. fünf Ansätze versucht. Leider ohne Erfolg. Im Anhang siehst Du den aktuellen Code. Ursprünglich von Hendrik Hölscher, ein wenig angepasst. Das DMX-Singal ist übrigens i. O. ich hab ein Oszi dran mit dem ich es analysieren kann. Vielleicht fällt Dir was auf, was ich ändern muss um endlich ein Erfolgserlebnis zu erhalten. Ich hab schon so oft drüber geschaut, dass ich wahrscheinlich schon resistent bin. Danke und Grüße Jürgen P.
Hallo Jürgen, den Code habe ich gerade nur mal ganz schnell überflogen, sah aber auf den ersten Blick ganz gut aus. Ist die Hardware denn in Ordnung? Schwingt der Quarz? Fuse-Bits in Ordnung (vielleicht ist der interne Oszillator noch aktiv)? Gruß Benedikt
...wer lesen kann ist klar im Vorteil ;) Die Frage nach der Hardware dürfte sich ja fast erledigt haben, habe gerade erst STK500 gelesen...
Habe doch gerade etwas Zeit gehabt den Code genauer anzusehen. In der Funktion get_dips wird der Empfänger deaktiviert wenn keine Adresse über die DIP-Schalter eingestellt ist. Die Funktion musst du natürlich auch anpassen, wenn du keine DIPs verwendets. Gruß Benedikt
Ich finde leider auch keinen Fehler im Code!!! Von der Hardware ist auszugehen, dass sie wirklich i. O. ist. Ist ja kaum was dran. Lediglich ein Bus-Transceiver, der auch macht was er soll und die LEDs vom Eval-Board. Der Quarz schwingt, die Fuse-Bits sind folgendermaßen eingestellt: - Boot Flash section size = 1024 ....... - Brown-out detection level at VCC_2.7V........... - Ext. Crystal/Resonator High Freq.; Start-up time: 16K + 64ms........ Ist daran evtl. was falsch? Allerdings hat mein letztes Projekt mit gleichem Board und gleichem µC funktioniert. Jedoch mit RS232/9600. Und andere Programme laufen auch auf dem Controller (Testprogramme mit LEDs usw.) was ja voraussetzt, dass der Takt i. O. ist, oder? Hast Du oder jemand aneres auch noch eine andere Idee? Danke im Voraus Gruß
...jetzt hab ich zu schnell geantwortet!! was meinst Du damit genau? Gruß
Hast du meinen letzten Beitrag bezügl. der Funktion get_dips übersehen?
...war auch zu schnell;)
1 | else
|
2 | {
|
3 | UCSRB &= ~(1<<RXCIE); //disable Receiver if start address = 0 |
4 | for (Temp=0; Temp<DMX_CHANNELS; Temp++) |
5 | {
|
6 | DmxField[Temp]= 0; |
7 | }
|
8 | }
|
Der Interrupt wird ausgeschaltet wenn die Adresse die über PINC eingelesen wird = 0 ist. Die Funktion muss also angepasst werden. Dein DmxAddress= 100; wird auch nur ausgeführt wenn eine Adresse eingestellt ist. Gruß Benedikt
So sieht meine get_dips(); nun aus:
****************************************************************
void get_dips(void)
{
#ifdef USE_DIP
uint16_t Temp= (255-PINC); //invert DIP state
Temp = 1;
if (!(PINE &(1<<2)))
{
Temp= Temp +256; //9th bit
}
if (Temp != 0)
{
DmxAddress= Temp;
if (!(UCSRB &(1<<RXCIE))) //if receiver was disabled ->
enable and wait for break
{
gDmxState= IDLE;
UCSRB |= (1<<RXCIE);
}
}
else
{
UCSRB &= ~(1<<RXCIE); //disable Receiver if start address =
0
for (Temp=0; Temp<DMX_CHANNELS; Temp++)
{
DmxField[Temp]= 0;
}
}
#endif
}
*************************************************************
Ich habe zum Testen Temp = 1; gesetzt. Geht aber leider immer noch
nicht.
Ich beginne gleich furchtbar zu heulen.....
Wieso kommentierst Du nicht einfach USE_DIPS aus und setzt DmxAddress während der Initialisierung z.B. auf 1? Ich finde Deine Version derzeit nicht gerade übersichtlich. Hat der Quarz 8MHz? Kommen Daten am USART an? Passt der Interrupt-Vektor? Wie bist Du in der vergangenen Woche beim systematischen Debugging vorgegangen? Das lässt sich alles binnen 10min simulieren... VG, Hendrik
Hallo Henne, vielen Dank, dass Du Dich in diesem Thread beteiligst!! Zu Deinem Beitrag: >> Ich finde Deine Version derzeit nicht gerade übersichtlich. Ich auch nicht. Ich hab das Ganze ja ziemlich original von Hölscher übernommen. Einfach aus dem Grund, dass ich noch nicht so viel Erfahrung habe und mein Ziel ist, dass ich dahinter steige und den Code für meine Ansprüche anpassen/erweitern kann. >>Hat der Quarz 8MHz? Ja, hat er. >>Kommen Daten am USART an? Wenn Du damit den RxD, also PD0 meinst, dann ja. >>Passt der Interrupt-Vektor? Keine Ahnung!! Genau das sind die Dinge, die ich mir erhoffe, von Euch zu lernen. >>Wie bist Du in der vergangenen Woche beim systematischen Debugging vorgegangen? Das Debugging in der letzten Woche bestand vielmehr aus Code ändern, draufladen und dann enttäuscht feststellen, dass es nix gebracht hat. Ich wüsste auch nicht, wie ich debuggen sollte. On-Chip-Debugging kann ich nicht machen. >>Das lässt sich alles binnen 10min simulieren... Wie? Bitte habt Geduld mit mir!!
evtl. könnte auch das noch etwas weiterhelfen: http://dmxcontrol.de/wbb2/thread.php?threadid=2237 Didaktisch weniger wertvoll als von mir geplant - aber immer noch besser als gar nichts. VG, Hendrik (Hölscher)
Hallo, also ich gehe davon aus das Hendrik die Header-Dateien seiner Lib mit normalen Frequenzen belegt hat. Wieso findet sich in code.c -> #define F_OSC 8000 Das sind keine 8Mhz. Gruß Sven
Doch - ich hatte das für mich mal in kHz definiert. Würde ich auf die Frequenz in Hz des Makefiles zugreifen, könnte das bei Anfängern noch mehr Verwirrung stiften... VG, Hendrik
Hallo zusammen, ich denke, dass mein Problem in erster Linie darin liegt, die richtige Startadresse zu definieren. Ich habe nun einen DIP-Switch folgendermaßen integriert: PB2 PB1 PB0 PC5 PC4 PC3 PC2 PC1 PC0 256 128 64 32 16 8 4 2 1 Allerdings funktioniert die Kombination der beiden Ports noch nicht wirklich. Ich denke, das wird die nächste Hürde. F_OSC mit 8000 passt eigentlich schon. War anfangs zwar verwirrend weil nicht üblich aber passt mit den verwendeten Formeln schon. Gruß
Hallo ich hab da mal eine Frage zum DMX empfang und zwar verstehe ich nicht ganz wie die Datenempfangen werden. Ich habe ja mehrere Kanäle, möchte aber nur den ersten kanal nutzen und jetzt meine Frage: Wie muss ich das programmieren das halt nur der erste Kanal abgefragt wird??? Habe auch das C-Programm vonHoelscher verwendet, funktionoiert nur nicht:( Ich hoffe ihr könnt mir helfen. Lg
Indem du die Bytes zählst, welche nach dem Break gesendet werden. Nach dem Break kommt das Startbyte, welches normalerweise 0 ist. Dann fangen die einzelnen Kanäle an. Also wäre dein Kanal 1 das zweite Byte nach dem Break-Signal (oder das 1. nach dem Startbyte). So schwer ist das DMX-Protokoll ja nun auch nicht... Sven
Die Anzahl der benötigten Bytes werden über die Größe von DmxRxField festgelegt. Das erste Byte für Dein Gerät liegt dementsprechend in DmxRxField[0]. VG, Hendrik
Bin jetzt zwar nicht C-fest, geb aber trotzdem meinen Senf dazu. DMX-in ist im Prinzip recht einfach. Man nehme die UART und konfiguriere auf 250000 Baud 8n2 ... die 2 ist wichtig !!! Dann erstelle man eine URXC Interruptroutine in welcher der FE-Flag abgefragt wird ... FE = Frame Error Flag. Diesen brauchts um den Break zu erkennen. Dann fragt man nach FE-Error das erste kommende Byte ab ob dies 0 ist ... ist dies der Fall setzt man seinen Framecounter auf 1 zurück, weil dies ja der erste Frame war. Nun zählt man einfach nur noch die ankommenden Bytes durch bis die gewünschte Adresse ankommt ... danach braucht einen die UART nicht mehr interessieren, da man ja seinen gewünschten Frame empfangen hat, verwurstelt diesen in der Mainloop und beim nächsten Frame Error geht das Ganze von Vorne los. :o)
Außerdem: WAS funktioniert genau nicht? Bist Du die State Machine im Simulator mal komplett durchgegangen? Stimmen alle Konstanten? Sämtliche Fehlerbeschreibungen in diesem Thread sind nicht hilfreich oder zielführend! Wie soll man da helfen? Und wenn ihr nicht keine Ahnung vom AVR-Studio oder von AVRs habt, dann fangt doch erst mal mit Lauflichtern oder auf Basis der Original-HW an, bevor es mit Portierungen losgeht. Hendrik
@testit: Genau das tut die Lib. Genau das steht in der AN. Genau das habe ich in einem Flussdiagramm aufgemalt. Hilft scheinbar Einigen trotzdem nicht. Leider weiß ich auch nicht, wo es genau hakelt. (Meine Vermutungen sind: Baudrate, RXC-Vektor)
aber der Code ansich schaut ganz gut aus, tippe daher auf Hardware Fehler. GND nicht mit durchverbunden, fehlender Abschlusswiderstand ... welchen Schnittstellenbaustein verwendest Du?
Die üblichen Verdächtigen: Max481, wenn ich sicher gehen will SN75176 im Normalfall Das ist aber auch im Schaltplan aufgeführt. Die Terminierung wirkt sich bei mir erst auf langen Leitungen oder RDM aus. Die billigsten XLR-Verbinder von reichelt produzieren bei mir mittlerweile übrigens Wackelkontakte. Das hat dann unkontrolliertes Flackern zur Folge - und eine stundenlange Fehlersuche in der FW... VG, Hendrik @Fragende: Lest Ihr eigentlich die zugehörige AN? Sonst lohnt es sich eigentlich nicht, über weitere Hinweise darin nachzudenken.
Hi AVR Gemeinde, dass das Protokoll einfach ist ist mir klar, aber es hat einfach nicht funktioniert und ich war mir einfach nicht mehr sicher. Ob ich das alles richtig verstanden habe, habe aber jetzt den fehler gefunden. Es lag am Quarz. Lg und danke für die posts
Hi, ich weis, dass das Thema schon etwas älter ist, aber mein Problem passt hier wahrscheinlich am besten rein. Ich habe die Original-Hardware von Hölscher. Die fertigen Programme von Hendrik habe ich bereits aufgespielt und getestet. Die laufen. Jetzt wollte ich die Ausgänge etwas anders Programmieren und habe die rxd-File von Hendrik heruntergeladen. Darin ist zunächst einfach nur die Ansteuerung der roten LED sobald der erste ausgewertete Kanal größer oder gleich "127" ist. Das funktioniert soweit auch. Mein Problem ist jetzt aber, dass die rote LED nicht konstant anbleibt wenn ich bei meinem Lichtpult (Eurolite Scene Setter 24) den entsprechenden Fader voll aufziehe. Die LED blinkt mit einer geschätzten Frequenz von 4 bis 7 Hz. Die Fusebits habe ich schon mehrfach kontrolliert. Der Code wurde bisher nicht abgeändert. Vielleicht kann man jemand einen Tip geben, an was es liegen könnte oder wo ich bei der Fehlersuche am besten anfange. Danke Matthias
ich tippe auch auf den Watchdog. Den könntest Du in den fuses ausschalten oder in der Firmware bei jedem Durchlauf der Hauptschleife zurücksetzen. Ansonsten fällt mir nichts ein. VG, Hendrik
Hi Henne, danke für deine schnelle Antwort. Ich hab in den Fusebits den Watchdog deaktiviert. Jetzt ist das Flackern der LED weg. Danke nochmals Matthias
Hi, ich habe nochmal eine Frage zu dem DMX-Transreceiver von Hendrik Hölscher. Wäre es möglich aus dem Board ein USB-DMX Adapter zu bauen? Falls ja, was müsste man dabei beachten? Könnte man mit der USB-Buchse z.B. an die Spare-Eingänge anschließen und das Board dann als DMX-Sender betreiben? Danke Matthias
Dieses Board sähe dann so aus wie das DE-IF ;-) Bei also einfach dieses Projekt nach... (www.digital-enlightenment.de) Viel Erfolg, Hendrik Ansonsten gibt es MiniDMX, DWorkin, µDMX, usw. Eigentlich fehlt noch ein IF auf Basis eines USBAVR - die Frage ist nur, ob die Welt wirklich noch auf ein weiteres DMX-Interface wartet... Eigentlich ist das DE-IF schon ziemlich nah an "perfekt" dran.
Hallo Jungs, ich habe ein sehr ähnliches Problem. Ich habe die Original Hardware von Hendrik Hölscher und verwende die original HEX Datei von Hendrik (Switchpack). Auf meinem DMX Bus sendet ein Ethernetinterface von e:cue. Alle anderen Devices auf dem Bus 4 LED Pars und 2 LED Bars funktionieren wunderbar. Problem mit dem Switchpack: Sende ich ein DMX Signal per e:cue mit sehr wenig Traffic, dann schaltet die LED meistens richtig (Wenn der Switchpack eine sehr niedrige DMX Adresse hat). Sobald der Traffic durch Ansteuerung der anderen Devices steigt, oder der Switchpack eine höhere DMX Adresse bekomtm geht alles in die Hose. Die LED schaltet dann sporadisch ein und aus. Ziehe ich das Datenbyte für die LED des Switchpack langsam von 0 bis 255, schaltet die LED auch Mehrfach. Ich werde heute Abend noch die Fuses und den Watchdog testen, aber dann bin ich Ratlos. Ideen???????
Florian schrieb: > Problem mit dem Switchpack: > > Sende ich ein DMX Signal per e:cue mit sehr wenig Traffic, dann schaltet > > die LED meistens richtig (Wenn der Switchpack eine sehr niedrige DMX > > Adresse hat). Sobald der Traffic durch Ansteuerung der anderen Devices > > steigt, oder der Switchpack eine höhere DMX Adresse bekommt geht alles > > in die Hose. Die rote Status LED blink auch doppelt was einen DMX Fehler signalisiert.
Hat sich erledigt. Wie auch immer es hat passieren können, aber D+ und D- am DMX Buss waren vertauscht :-(
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.