Ich betrachte die Implementierung einer nicht trivialen endlichen Zustandsmaschine (spezifiziert als hierarchisches UML-Zustandsdiagramm) auf einer 32-Bit-MCU mit gcc.
Gibt es Faustregeln, was besser und was weniger gut funktioniert? Mein Bauchgefühl sagt, dass eine Switch-basierte (oder sogar berechnete Goto) Implementierung etwas performanter sein sollte, während eine auf Funktionszeigern basierende Übergangstabelle allgemein als wartungsfreundlicher gilt.
Außerdem: Hat jemand Boost MSM für eingebettete Anwendungen evaluiert? Ich weiß, dass Boost MSM allgemein als sehr effizient gepriesen wird, aber bei eingebetteten Anwendungen wird Effizienz möglicherweise anders gemessen als in der Welt der PC-Programmierung.
Weiß jemand, wie die kompilierte Zustandsmaschinen-Engine von MSM aussieht? Eher wie eine Switch-Sprungtabelle oder eher wie eine Funktionszeiger-Übergangstabelle? Verwendet es dynamische Speicherzuordnung oder kann es statisch verwendet werden?
Ich wäre überrascht, wenn es auf einer 32-Bit-MCU einen großen Unterschied gibt. Das Vermeiden bedingter Verzweigungen könnte Ihnen einige Zyklen ersparen, aber werden Sie wirklich erfolgreich sein oder scheitern, basierend auf ein paar Zyklen? Die Anzahl der Wartezustände in Ihrem RAM und ROM ist wahrscheinlich mindestens genauso wichtig. Ebenso der CPU-Befehlssatz.
Vorzeitige Optimierung ist die Wurzel allen Übels. Beginnen Sie mit dem, was einfacher zu implementieren und zu warten ist, und optimieren Sie nur dort, wo es notwendig ist, basierend auf Profiling.
Für eine UML-Implementierung auf Embedded werfen Sie einen Blick auf QP Framework -> http://www.state-machine.com . Es sind sowohl C- als auch C++-Varianten verfügbar. Die begleitende GUI (QM) erlaubt sogar die Codierung in UML-Notation. Das Framework ist klein genug, um auf Arduino zu laufen; 32-Bitter sind einfach.
jms
Matt Jung
Wouter van Ooijen