mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik HILFE DMX-Empfang mit ATmega8 und Hoelscher


Autor: Jürgen P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt Patt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen P. (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Benedikt Patt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Benedikt Patt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...wer lesen kann ist klar im Vorteil ;)
Die Frage nach der Hardware dürfte sich ja fast erledigt haben, habe 
gerade erst STK500 gelesen...

Autor: Benedikt Patt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Jürgen P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...jetzt hab ich zu schnell geantwortet!!

was meinst Du damit genau?

Gruß

Autor: Benedikt Patt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hast du meinen letzten Beitrag bezügl. der Funktion get_dips übersehen?

Autor: Benedikt Patt (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
...war auch zu schnell;)
else
  {
  UCSRB &= ~(1<<RXCIE);            //disable Receiver if start address = 0
  for (Temp=0; Temp<DMX_CHANNELS; Temp++)
    {
    DmxField[Temp]= 0;
    }
  }

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

Autor: Jürgen P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.....

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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!!

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Sven K. (svenk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Jürgen P. (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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ß

Autor: Pattek (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Sven Stefan (stepp64) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: testit (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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)

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@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)

Autor: testit (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
aber der Code ansich schaut ganz gut aus,
tippe daher auf Hardware Fehler.
GND nicht mit durchverbunden, fehlender
Abschlusswiderstand ... welchen Schnittstellenbaustein
verwendest Du?

Autor: henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Pattek (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: matthias.buerkle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: matthias.buerkle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: matthias.buerkle (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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???????

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Florian (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hat sich erledigt. Wie auch immer es hat passieren können, aber D+ und 
D- am DMX Buss waren vertauscht :-(

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.