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

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