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
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.