Mein Dekoder für RC-5 in C im Interruptbetrieb

[Klebwax]

Rückmeldungen sind erwünscht.

Nur mal eine Sache: Du bist sehr großzügig mit volatile. Ist das wirklich nötig? Das bremst den Optimizer komplett aus. Und du gibst Strings im Interrupt-Handler über die serielle aus. Das könnte dir deinen 50µs Interrupt ziemlich aus dem Tritt bringen.

MfG Klebwax

[oberallgeier]

Danke Klebwax für Deine Rückmeldung.

.. Du bist sehr großzügig mit volatile. Ist das wirklich nötig? Das bremst den Optimizer komplett aus ..

Es ist sicher nicht immer nötig. Ach wenns nur das wäre. Meine C-Kenntnisse gehen ja zurück auf einen autodidaktischen Crashkurs vor etlichen Jahren. Wenig gelernt und inzwischen manches vergessen; ich nenne das ja eher Cäh als C. Ja, vergessen ist keine Entschuldigung - und manchmal mühe ich mich wegen irgendwelcher (mir) unerklärlicher Fehler lange ab . . . In meinem Fall macht selbst Übung nicht mehr den Meister. Deiner Anmerkung werde ich aber mal gewissenhaft nachgehen.

.. du gibst Strings im Interrupt-Handler über die serielle aus. Das könnte dir deinen 50µs Interrupt ziemlich aus dem Tritt bringen ..

Das tuts sicher - auch wenn ich z.B. mein PingPong-Display mit 256 KBd anspreche. Dabei ist der Standardstring drei Zeichen lang - an die 120 µs - siehe hier. Abgesehen von dieser Display-Anzeige wird im Standardbetrieb kaum was über UART gesendet, da läuft fast alles per I²C - sicher auch nicht problemlos. Allerdings meine ich, dass meine Zeitmessung den Verlust von manchem Takt verkraften kann bzw. verkraftet - jedenfalls merke ich den meisten Bewegungen von archie nicht wirklich irgendwelche Taktlosigkeiten an.

.. Das könnte dir deinen 50µs Interrupt ziemlich aus dem Tritt bringen ..

Noch schlimmer: meine Regelungsroutine läuft alle 10 ms >innerhalb< der ansonsten sehr kurzen Timer-ISR. Dazu mal n Zitat aus meinem Laborbuch (-file) :

............30. August 15; MoC4_x26 Messung Umfangsgeschwindigkeit
........................// Der Zeitbedarf für die Regelung wurde gemessen: MoC4_tmr26.c, GOULD 20 MHz
........................// rgl_nn-Aufruf und regelpre..=0 ohne Regelung 1,5 µs, mit Regelung 5,1 µs
............Bei Aufruf Regelung void rgl_12(void) OHNE Geschwindigkeitsvorgabe (bzw sspeed <= 3) wird
............ja die Funktion sofort wieder verlassen, siehe Quellcode in ~mot~.
............Die gemessene Zeit ist unabhängig davon, ob in den Regelfunktionen rgl_nn der Interrupt erlaubt
............wird (sozusagen nested interrupts) oder nicht ! ! !

Aber meine Controller laufen ja mit 20 MHz; fast durchwegs Atmel, auch nanoclones etc.

Danke Klebwax!

[Moppi]

Meine Faustregel:

Volatile immer bei allen Variablen, die in einer Interrupt-Service-Routine genutzt werden, außerhalb der ISR deklariert sind (Zählervariablen z.B.) und deren Inhalt nicht verloren gehen darf, wenn die ISR beendet wird.

Variablen die nur innerhalb der ISR gebraucht werden, solange die ISR ausgeführt wird, würde ich, für mich, innerhalb der ISR deklarieren (ohne volatile). Dann könnten sie vom Compiler optimiert werden, dass evtl. nur Register- statt Speicherzugriffe stattfinden.

Ich habe ein RETURN gefunden, ich glaube, das ist nicht notwendig:

// - - - - - - - - - - - - - - -
return; //
} // Ende ISR(TIMER2_COMPA_vect)

MfG

- - - Aktualisiert - - -

Aber meine Controller laufen ja mit 20 MHz; fast durchwegs Atmel, auch nanoclones etc.!

Würde ich prüfen, ob das notwendig ist. Ich meine, mit steigernder Geschwindigkeit steigt i.R. auch der Strombedarf. Muss man mal im Datenblatt schauen.

[oberallgeier]

Nur mal eine Sache: Du bist sehr großzügig mit volatile. Ist das wirklich nötig? Das bremst den Optimizer komplett aus ..

So, die Geschichte mit dem volatile hab ich mal (wieder :-/ ) durchgeackert. Ich hoffe, dass ich dieses Typenattribut (type qualifier) zukünftig auf wirklich notwendige Fälle beschränken werde und mit der Zeit die vorhandenen, unnötigen Fälle vollständig entferne. Ich halte es im Auge.

.. Ich habe ein RETURN gefunden, ich glaube, das ist nicht notwendig ..

Stimmt, unnötig. Ein Relikt aus gaaanz frühen Jahren. Aber ein Vergleich der *.lls-Datei zeigt, dass der Compiler sich damit zu keiner unnötigen Aktion verleiten lässt.

.. Controller laufen ja mit 20 MHz; .. prüfen, ob das notwendig ist .. mit steigernder Geschwindigkeit steigt i.R. auch der Strombedarf ..

Was heißt notwendig? Die ganze Controllersammlung im archie (aktuell neun Platinen - ein Master und 8 Slaves) hat ne Menge zu tun. Zusammen mit den Motoren ist der gesamte Leistungsbedarf bei knapp 10 Watt - in Ruhe, bei Bewegung (Gestik) bis über vierzig Watt, im Fahrbetrieb darüber - da sind ein paar Milliwatt mehr ohne Bedeutung. Der Vorteil liegt nicht zuletzt darin, dass z.B. die Kommunikation UART und I²C durch den gleichen, hohen Quarztakt nach meiner Erfahrung ziemlich sicher wurde - trotz der Durchseuchung mit Interrupts.

[Moppi]

Was heißt notwendig?

Manchmal braucht man die hohe Frequenz für die Aufgaben gar nicht, da tut es auch weniger.
Wenn es um Störanfälligkeit geht, wird es mit zunehmender Frequenz i.R. nicht besser, sondern eher ist das Gegenteil der Fall.


MfG

[Klebwax]

Volatile immer bei allen Variablen, die in einer Interrupt-Service-Routine genutzt werden, außerhalb der ISR deklariert sind (Zählervariablen z.B.) und deren Inhalt nicht verloren gehen darf, wenn die ISR beendet wird.

Da hat volatile nichts zu suchen und bewirkt auch nichts. Variablen, die die Laufzeit einer Funktion überleben sollen ansonsten aber nur von ihr verwendet werden, erzeigt man local und macht sie static.

Volatile ist dann nötig, wenn sowohl main() als auch der Interrupthandler sie verwenden. Oder wenn zwei Interrupthandler auf sie zugreifen. Allgemeiner, wenn man damit rechnen muß, daß sich eine Variable außerhalb des gerade laufenden Programmkontextes ändert, muß sie volatile (unbeständig) deklariert werden.

MfG Klebwax

[oberallgeier]

.. Volatile ist dann nötig, wenn .. Oder wenn zwei Interrupthandler .. Allgemeiner, wenn man ..

Ich freue mich. Ich habs ja nur mit den Quellen Kernighan/Ritchie, im microcontroller.net (z.B. hier), im RNWissen, z.B. hier und bei den AVR-Freaks durchgearbeitet. Aber ziemlich so hatte ich das verstanden (Verwendung in UND ausserhalb einer ISR und so . . .).

[oberallgeier]

Die Redewendung ".. hinten keine Augen haben .." ist dudenkonform und beschreibt eine Eigenschaft die uns zu Eigen ist - und manchmal hinderlich.

Meist oder immer hinderlich ist diese Eigenschaft bei Robotern - wenn man die mit einer optischen Fernsteuerung bedienen will. Bei meinem Archie hatte ich mich rausgewunden durch zwei getrennte Sensoren deren Signalausgänge ich miteinander verbunden hatte (wired or), siehe hier. Beide "linsten" in zwei entgegengesetzte Richtungen, aber ihre Signale gingen auf ein und denselben Eingangspin. Es gab manchmal Störungen, einige Störungen konnten auf Abschattungen zurückgeführt werden, meist lief es.

Den abgekündigten SFH5110 habe ich ja mittlerweile durch den TL1838 ersetzt. Die etwas dünne Dokumentation habe ich für mich durch eigene Messungen (und Variation der Beschaltung) erweitert. Beste Ergebnisse bekam ich mit nem Vorschaltwiderstand von etwa 100 Ω und einem Pullup von (16 bis) 20 kΩ. Nun noch ein zweites Auge hintendran, beide Schaltungen auf ein "Brettchen montiert", ein dreipoliges Kabel dran: GND, Vcc und SigOut (sozusagen Belegung à la Modellbauservo) - und schon läufts. Sauber, fast keine toten Winkel, offensichtlich besser als vorher.

......Bild hier  
......© 2020 by oberallgeier (höhere Auflösung im Bild verlinkt)

Vielleicht hilft das dem einen oder andern.

[oberallgeier]

Hallo Klebwax, danke für Deine Hinweise:

Nur mal eine Sache: Du bist sehr großzügig mit volatile. Ist das wirklich nötig? Das bremst den Optimizer komplett aus ..

Puhhh - so. Die unnötigen (unsauberen) Deklarationen "volatile" sind bereinigt. Schon einiges Arbeit (bis man draufkommt wie das schnell geht).
Dann compiliert mit -Os - wie zuvor. Der Vergleich "vorher" "nachher" gab keine Unterschiede aber selbst wenns so wäre - sauber(er) programmiert ist die Sache den Aufwand dann doch wert.
Zusätzlich wurden unnötige Definitionen bereinigt/entfernt - War schon längst angedacht . . .

.. Und du gibst Strings im Interrupt-Handler über die serielle aus. Das könnte dir deinen 50µs Interrupt ziemlich aus dem Tritt bringen ..

Ich hatte (einige, wenige) Stellen die mir kritisch vorkamen getestet und hatte die Zeit für diese Stringausgaben gemessen (Ausgang war low, Testanfang - Ausgang high - Stringausgabe - Ausgang low) und Oskar angeguckt (ok ok, *lls Auswerten wäre direkter). Ich blieb dabei im Zeitrahmen. Übrigens hatte ich manche Programmaufrufe (z.B. Regelung!!) auf Zeitbedarf getestet (Oszi, *.lls) um Störungen im "eigentlichen" Betrieb möglichst auszuschließen. 100%igen Erfolg kann ich natürlich nicht garantieren. Es wäre mir auch nicht klar, wie ich das sicherstellen könnte. UND - wenns möglich ist (z.B. beim PingPong-Display) wird UART auch mit ziemlichem Speed gefahren (PingPong wurde extra auf Quarzbetrieb umgelötet).

Die Regelung. Es werden ja beide Antriebe voneinander getrennt geregelt - Geradeauslauf z.B. wird durch gleiche Strecken-/Speed-Vorgaben angestrebt (erhofft - leider nicht garantiert aus vielerlei Gründen). Und genau da spielt die Laufzeit ne Rolle und genau deswegen wird die 100/s-Regelfrequenz dadurch erreicht dass mit 200/sec geregelt wird - aber eben jeweils alternierend nur einer der beiden Antriebe. Die Regelfrequenz liegt dann im Bereich der Motorzeitkonstanten von 10 ms .. 12 ms der Antriebe (die "as build" gemessen wurden). Insbes. beim MiniD0 (die 0,15-Liter-Coladose) ist der Gleichlauf ziemlich gut zu sehen [/Selbstlob].

Bestimmte Ausgaben dauern länger als dieser 50µs Interrupt. Das kommt z.B. vor bei Testfahrten von u.A. Servo von A nach B fahren um Positionen zu testen und Ähnliches. Dabei wurden natürlich auch der Zeitbedarf für bestimmte Gesten erfasst. Aber für das Auge spielen >im "Normalbetriieb"< evtl. Interrupt-Störungen keine Rolle (sprich: ich seh da nix).