www.mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik Hoelscher/Henne DMX-Empfangscode modifizieren


Autor: fgde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo zusammen,

ich arbeite gerade in einem kleinen Projekt mit der DMX-Empfangsroutine 
von Hendrik "Henne" Hoelscher (siehe 
http://www.hoelscher-hi.de/hendrik/light/ressources.htm) und hab jetzt 
ein Problem...wollte das einfach mal hier loswerdeb (auch weil ich weiß 
dass Henne hier mitliest, an dieser Stelle schonmal ein DANKE von mir 
für den Code...), und eure Meinung dazu hören:

Ich empfange DMX-Daten (insg. ein Block von 10 Kanälen) mit Henne's Code 
in der USART-ISR eines Mega644 @ 16Mhz. Ich muss aber nebenher nun noch 
ein zweites timingkritisches Protokoll bearbeiten, welches offenbar 
nicht mit den Unterbrechungen der DMX-ISR klarkommt, obwohl es mit 
9600bit eigentlich recht gemächlich unterwegs ist (oder auch gerade 
deshalb, wie mans sieht). Ich brauche so wie's aussieht effektiv gut 100 
zusammenhängende Millisekunden pro Sekunde für diese Geschichte, die mir 
DMX nicht von sich aus gibt...

Momentan fallen mir da nun zwei Ansätze ein das ganze wieder in den 
Griff zu kriegen:

Lösung 1: Ich nutze die Zeit, in der die DMX-ISR quasi sinnlos ausgelöst 
wird, nämlich wenn die zu empfangenden Bytes schon vorbei sind. Dann 
muss ich die 100ms aber doch auf min. 6 oder 7 Teile splitten - das wird 
hart, funktioniert vermutlich aber sogar, solange man eine Startadresse 
im niedrigen Bereich benutzt, die ISR sich nach dem Empfang der 
gewollten Bytes selbst deaktiviert und dafür einen Reaktivierungs-Timer 
scharfmacht - das kann man ja ausrechnen wann ungefähr wieder ein Break 
kommen muss denk ich mal...aber sobald die Adresse höher ist ists auch 
für die Tonne...

Lösung 2: Ich bin ein wenig unverschämt und mache nicht die volle 
Refreshrate von DMX mit, z.B. nur ein Frame alle 250 Millisekunden. Die 
Anwendung würde das sogar zulassen, da ist nix kritisches dabei. Dann 
müsste ich wohl so ein ähnliches Timerspielchen machen, das mir den 
USART-ISR alle 250 ms aktiviert (und natürlich muss sich die ISR nach 
dem korrekten Empfang eines Frames dann auch selbst wieder abschalten).

Was meint ihr dazu? Könnte eine der Optionen klappen? Oder brauch ich 
unbedingt noch einen Slave-µC, der nur die zweite Kommunikationsform 
abwickelt? Oder gibts noch andere Möglichkeiten?

Danke fürs Lesen + Antworten,
beste Grüße
fgde

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  fgde (Gast)

>Ich empfange DMX-Daten (insg. ein Block von 10 Kanälen) mit Henne's Code
>in der USART-ISR eines Mega644 @ 16Mhz.

Schön, da hat der AVR aber noch viel Luft.

> Ich muss aber nebenher nun noch
>ein zweites timingkritisches Protokoll bearbeiten, welches offenbar
>nicht mit den Unterbrechungen der DMX-ISR klarkommt, obwohl es mit
>9600bit eigentlich recht gemächlich unterwegs ist (oder auch gerade
>deshalb, wie mans sieht).

Das ist um den Faktor 26 langsamer. Sprich auf 26 DMX-Bytes kommt eins 
vom anderen Protokoll.

> Ich brauche so wie's aussieht effektiv gut 100
>zusammenhängende Millisekunden pro Sekunde für diese Geschichte,

Das glaube ich nicht. Das Zauberwort heißt Multitasking und 
Statemachine. Lies den Artikel, schau dir das Beispiel an und 
staune.

>Was meint ihr dazu? Könnte eine der Optionen klappen?

Beides nicht sehr schön. Siehe oben.

> Oder brauch ich
>unbedingt noch einen Slave-µC, der nur die zweite Kommunikationsform
>abwickelt?

Nö.

> Oder gibts noch andere Möglichkeiten?

Siehe oben.

MFG
Falk

Autor: fgde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Danke für deine Antwort, Falk.

Mein Problem ist dass das zweite Protokoll LANC ist und damit nicht 
wirklich asynchron. Mir da wird quasi durch einen externen Takt 
vorgegeben wann ich senden darf und wie lange das dauern darf, und zu 
allem Überfluss muss ich in jedem Fall 3 oder 4 Frames in Folge senden, 
damit mein Kommando akzeptiert wird. Und davor gilt es noch einen Break 
zu erkennen...ich meine grob über den Daumen gepeilt zu erkennen, dass 
der Gesamtzeitbedarf in einer gewissen Zeitspanne wie z.B. einer 
Sekunden nicht für das alles ausreicht, ohne einen der beiden Prozesse 
zu "beschneiden".

Damit komme ich halt gerade trotz Erfahrung mit Multitasking nicht klar, 
die Statemachine ist auch kein Problem (so wie z.B. bei DMX)...

Wäre da also nach wie vor noch dankbar für Tips, im schlimmsten Fall 
werd ich mir nen ATTiny dazubauen der stupide RS232 async in LANC 
synchron umsetzt oder so...

Danke + Gruß,
fgde

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  fgde (Gast)

>Mein Problem ist dass das zweite Protokoll LANC ist

Kenn ich nicht. Hast du einen Link, wo man da grob was drüber erfahren 
kann?

>und damit nicht
>wirklich asynchron. Mir da wird quasi durch einen externen Takt
>vorgegeben wann ich senden darf und wie lange das dauern darf, und zu
>allem Überfluss muss ich in jedem Fall 3 oder 4 Frames in Folge senden,
>damit mein Kommando akzeptiert wird.

Schon, aber allein aus der eher geringen Baudrate MÜSSEN die 
Zeitvorgaben eher "langsam" sein, sprich in der Größenordung von einigen 
Bytes. Und denk dran, ein Byte in LANC sind 26 DMX-Bytes. Eine Ewigkeit.

> Und davor gilt es noch einen Break
>zu erkennen...

Das macht auch die ISR im DMX, nebenbei.

>ich meine grob über den Daumen gepeilt zu erkennen, dass
>der Gesamtzeitbedarf in einer gewissen Zeitspanne wie z.B. einer
>Sekunden nicht für das alles ausreicht, ohne einen der beiden Prozesse
>zu "beschneiden".

Du bist noch vollkommen in deiner eingleisigen Denkweise gefangen. Lies 
den Artikel Multitasking und denk drüber nach. In Ruhe. Dann schlaf 
drüber. Und morgen kannst du wieder was posten.

>Damit komme ich halt gerade trotz Erfahrung mit Multitasking nicht klar,

Das glaub ich irgendwie nicht ;-)

>die Statemachine ist auch kein Problem (so wie z.B. bei DMX)...

>Wäre da also nach wie vor noch dankbar für Tips, im schlimmsten Fall
>werd ich mir nen ATTiny dazubauen der stupide RS232 async in LANC
>synchron umsetzt oder so...

Siehe oben. In der Ruhe liegt die Kraft. Du musst dich von deiner 
engstirnigen, vorgefestigten Meinung lösen.

MFG
Falk

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Das hier?

http://www.boehmel.de/lanc.htm

uups, da hab ich oben noch einen Fehler drin. 1 Byte bei 9k6 sind ja 
über 1ms, also 16.000 Takte für den AVR. Das ist schnarchlangsam! 20ms 
Paketwiederholrate, ach herje. ;-)

Gähn

Dein AVR fragt dich dann dauernd, "When can I go to sleep today".

MFG
Falk

Autor: fgde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hi Falk,

ja, das ist das richtige LANC...und ja, es ist wirklich so langsam :-)

Ich glaub ich versteh schon auch worauf du hinauswillst mit dem 
Multitasking, das war eigentlich auch mein allererster intuitiver 
Ansatz, das ganze in möglichst atomare kleine Operationen aufzusplitten 
und die dann in der DMX-ISR zwischenzustreuen...
Ich glaube mein Denkfehler liegt an der Stelle, an der das 
"Verhältnistiming" zwischen LANC und DMX den Worst Case annimmt - der 
IMHO dann ist wenn mein erstes DMX-Byte das ich haben will exakt mit dem 
Startbit zusammenfällt welches vom LANC kommt...

Wäre es dann quasi doch der richtige Ansatz, den DMX-USART wie gehabt 
ISR-getrieben zu handhaben, und diese ISR dann gleichzeitig als Polling- 
bzw. Action-Schleife für das LANC-Interface zu mißbrauchen? Du hast ja 
da schon recht, innerhalb eines Bits auf dem LANC-Interface laufen 26 
Bits an DMX rein, da müsste man dazwischen schon noch halbwegs agieren 
können...

Danke für Deine Hilfe, beste Grüße,
fgde

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  fgde (Gast)

>Ich glaube mein Denkfehler liegt an der Stelle, an der das
>"Verhältnistiming" zwischen LANC und DMX den Worst Case annimmt - der
>IMHO dann ist wenn mein erstes DMX-Byte das ich haben will exakt mit dem
>Startbit zusammenfällt welches vom LANC kommt...

Ja und? Den Datenempfang auf dem LANC macht der 2. UART allein. Die CPU 
macht das nicht.

>Wäre es dann quasi doch der richtige Ansatz, den DMX-USART wie gehabt
>ISR-getrieben zu handhaben, und diese ISR dann gleichzeitig als Polling-
>bzw. Action-Schleife für das LANC-Interface zu mißbrauchen?

Nein.

> Du hast ja
>da schon recht, innerhalb eines Bits auf dem LANC-Interface laufen 26
>Bits an DMX rein, da müsste man dazwischen schon noch halbwegs agieren
>können...

Wer sagt denn, dass du LANC mit einem Software-UART machen sollst? Es 
gibt Dutzende uCs mit zwei Hardware UARTs.

MfG
Falk

Autor: Michael Roek (mexman) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo Falk,

ich denke, dass er aber durchaus SW UART benutzen kann..... so kritisch 
ist das timing wirklich nicht.
Er hat zum polling zumindest alle 4uS Zeit, waehrend DMX das zweite - 
ueberfluessige - Stopbit schickt.

Gruss

Michael

Autor: ein (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Michael Roek-ramirez schrieb:
> Er hat zum polling zumindest alle 4uS Zeit, waehrend DMX das zweite -
> ueberfluessige - Stopbit schickt.

Ein Garant für tollen, wartbaren Code. Aber sollte man unbedingt machen, 
wenn man 4 Cent bei Stückzahl 1 sparen kann.

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
;-)

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Die DMX-RX ISR ist schon recht effizient und sollte bei 16MHz in der 
Regel mit <3us pro Byte auskommen. Das wäre der Jitter, mit dem LNC 
leben müsste.

Alternativ könnte man nach dem Einlesen des UDR globale IRQs wieder 
freigeben und somit interrupt nesting erlauben. (Eigentlich ziemlich 
eklig...)

Ich befürchte, dass der LANC-Stack nicht sauber implementiert wurde und 
irgendwelche Warteschleifen für das Timing genutzt werden an Stelle 
eines Timers. (Bei hohen Baudraten wie DMX bleibt für Timer wenig Zeit - 
hier sieht die Welt anders aus...)

Wenn LANC halbwegs verbreitet und nützlich sein sollte, können wir ja 
den Stack zusammen aufsetzen. Ich würde ihn dann gern mit ein paar 
Erklärungen bei mir einpflegen. Bei DMX und RDM scheinen die 
Fragen/Schwierigkeiten ja wirklich langsam abzunehmen...

VG,
Hendrik

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Du willst einen Sony-Player oder -Verstärker fernsteuern :-/
Das könnte allenfalls für den Theaterbereich bei Soundeffekten 
interessant sein...

Das geht jedenfalls auch direkt mit dem Transceiver und dem m8515 @8MHz.

Stellst Du hier mal Deinen bisherigen Code rein?

Autor: fgde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo alle zusammen,

vielen Dank für das doch zahlreiche Feedback...ich habe mehrere Gründe 
wieso ich das wirklich gerne in SoftUART-Form machen würde wenn elegant 
möglich, bin aber leider grade unterwegs und hab wenig Zeit. Werde mich 
dazu heute abend nochmal in ausführlicherer Form rückmelden...

@ Henne, LANC ist mittlerweile wesentlich weiter verbreitet als nur 
Sony-Verstärker und -Player, nur allein das Protokoll kommt ursprünglich 
aus der Ecke. Heute wird das aber hauptsächlich zur Steuerung von 
Consumer- und Semipro-Videokameras verschiedener Marken eingesetzt, wie 
z.B. mit so etwas: 
http://www.pr-video.de/shop/catalog/index.php?cPat...

Bis später + Danke schonmal,
fgde

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Fein.

Code?

Autor: fgde (Gast)
Datum:
Angehängte Dateien:

Bewertung
0 lesenswert
nicht lesenswert
So, sorry zusammen, der Tag war etwas lang insgesamt...aber jetzt ist 
noch Zeit ein wenig detaillierter zu erklären...

@ Alle: Ich möchte aus verschiedenen Gründen eigentlich wenn vermeidbar 
nicht den zweiten UART des Mega644 benutzen:

1. Ist der im Moment für das Debugging der Geschichte im Einsatz und 
sollte das nach Möglichkeit auch später noch tun, wenn nicht brauch ich 
ja da wieder nen Soft-UART...

2. Kommt der Code per Bootloader (weil Arduino-Derivat) und ich weiß 
nicht ob ich LANC ohne Änderungen in der Außenbeschaltung schaffe 
(Invertierung? RX und TX auf einer Ader?), somit könnte ich dann aber 
nix mehr per Bootloader flashen (Firmware-Upgrade etc.)...

3. Würde gerne auch unabhängig davon eben diese Außenbeschaltung 
generell vermeiden, was ja mit einem/zwei Portpins eigentlich auch ganz 
gut geht...aber dann muss es eben ohne UART gehen.


@ Henne: Das betreffende Codefile ist im Anhang...wie oben schon erwähnt 
benutze ich die Arduino-Libraries, allerdings vermischt mit normalen 
C-Code-Konstrukten (ISRs etc.) und einer aufgebohrten Hardwarevariante 
gegenüber dem originalen Arduino (Mega644P). Ich denke aber der Code ist 
trotzdem quasi selbsterklärend...

Der Code selbst kommt zum größten Teil aus einer bestehenden 
Implementation, weil ich auch erstmal das Hardwareinterfacing testen 
musste...er funktioniert aber anstandslos, wenn ich denn die DMX-ISR 
deaktiviere...

Ich weiß nicht ob das für Dich nun überhaupt Sinn macht als 
General-Purpose-Library, aber falls ja können wir uns da auch 
selbstverständlich auf pures C beschränken, ich kann ja dann wie bei 
deinem DMX-Code auch später wieder die Arduino-Anpassungen einfließen 
lassen wenn nötig...


Danke schonmal + beste Grüße,
fgde

Autor: Falk Brunner (falk)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@  fgde (Gast)

>@ Alle: Ich möchte aus verschiedenen Gründen eigentlich wenn vermeidbar
>nicht den zweiten UART des Mega644 benutzen:

naja . . .

>2. Kommt der Code per Bootloader (weil Arduino-Derivat) und ich weiß

Jaja, ISP ist ja auch soooo schlimm.

>3. Würde gerne auch unabhängig davon eben diese Außenbeschaltung
>generell vermeiden, was ja mit einem/zwei Portpins eigentlich auch ganz
>gut geht...aber dann muss es eben ohne UART gehen.

Was zum Geier ist an ein paar einfachen Bauteilen so schlimm?
Du hast die falschen prioritäten.

>@ Henne: Das betreffende Codefile ist im Anhang...wie oben schon erwähnt

Naja, das mit den diversen Delays verträgt sich nicht wirklich mit DMX, 
klar. Man könnte dass ggf. umstricken auf einen Timer mit Input Capture 
und Output Compare. Damit wird a.) das Timing besser und b) die CPU 
entlastet. Ist aber schon etwas Entwicklungsaufwand.

MfG
Falk

Autor: fgde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
@ Falk: Ich bin Dir dankbar für deine Denkanregungen und sehe das 
ständige Hinterfragen auch positiv, aber es gibt trotzdem einige Dinge 
die ich (und alle die versuchen mir zu helfen) leider mehr oder weniger 
als gegeben annehmen müssen.
Dazu zählt u.a. die Tatsache dass ISP keine Option für die 
Firmwareupdates ist, weil von dem Gerät wenns mal halbwegs fertig ist 2 
Stück in jeweils 800 km Entfernung zum Test eingesetzt werden, und meine 
Kollegen die das machen haben einfach weder die Lust noch die Zeit sich 
einen halbwegs stabilen ISP-Adapter zu bauen, wohingegen serielle 
Adapter sowieso schon vorhanden sind, u.a. auch weil wie gesagt die 
Debugwerte da raus kommen (die die Herren ggf. dann an mich senden).

Was die externe Beschaltung angeht, das wäre zur Not natürlich schon 
machbar, aber ich versuche das ganze so simple & stupid wie möglich zu 
halten - unter anderem deshalb weil die Lösung dadurch generischer wird 
und vielleicht später bei mir oder bei jemand anders eher nochmal zum 
Einsatz kommt. Abgesehen davon beißt sich das ja aber eh mit dem oben 
genannten (ISP vs. RS232), insofern ist die Frage müßig.

Zum Ansatz mit den Timern, so was in die Richtung probiere ich jetzt 
gerade, wobei ich allerdings im Moment die DMX-ISR als Timer mißbrauche, 
was ganz gut geht solange die DMX-Rate ausreichend hoch ist...das lässt 
sich ja dann später immer noch umstricken...mal sehen...

Danke dennoch + Grüße
fgde

Autor: Henne (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
DMX ist keine Zeitbasis.
Bitte verwende einen freien 8bit-Timer.

Mit den Arduino-Erweiterungen kann ich nicht viel anfangen und auch 
deren HW habe ich nicht verfügbar - von daher kann ich auch nicht 
helfen.

Falls die Geschichte mal in größerem Maßstab eingesetzt werden soll, 
möchte ich noch einmal an die Spielregeln der GPL erinnern.


Viel Erfolg,
Hendrik

Autor: fgde (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Ja, ich weiß, das ist ne höchst wacklige Angelegenheit...war auch mehr 
eine (erfolgreiche!) Proof-of-concept-Konstruktion. Werde das dann aber 
wohl doch via Timer und Zustandsmaschine regeln müssen, immerhin muss 
ich nicht den kompletten Empfang auch noch mitnehmen - mir reicht eine 
Erkennung des ersten Bytes damit ich senden kann...

Was die GPL angeht, nein es wird zwar keine größere Geschichte (3 
Exemplare für mich und 2 Bekannte), aber wenn das mal stabil läuft wird 
das Projekt trotzdem auch publiziert inkl. Sourcen und Design...wird 
sicherlich für andere auch interessant sein.

Dann werde ich mal mein Glück versuchen :-)

Beste Grüße + Danke,
fgde

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.