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

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