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
@ 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
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
@ 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
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
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
@ 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
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
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.
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
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?
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?cPath=145_125_131_215
Bis später + Danke schonmal,
fgde
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
@ 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
@ 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
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
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
