HILFE DMX-Empfang mit ATmega8 und Hoelscher

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)

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

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 :-(