Macchine a stati di programmazione integrate

8

Sto cercando di implementare una macchina a stati finiti non banale (specificata come uno statechart gerarchico UML) su una MCU a 32 bit con gcc.

Ci sono delle regole empiriche che funzionano meglio e che funzionano meno bene? Il mio istinto dice che un'implementazione basata su switch (o anche calcolata goto) dovrebbe essere leggermente più performante mentre una tabella di transizione basata su puntatore a funzione è generalmente ritenuta più mantenibile.

Inoltre: qualcuno ha valutato Boost MSM per applicazioni integrate? So che Boost MSM è generalmente considerato molto efficiente, ma per le applicazioni integrate l'efficienza potrebbe essere misurata in modo diverso rispetto al mondo della programmazione per PC.

Qualcuno sa che aspetto ha il motore della macchina a stati compilato di MSM? Più come un interruttore a scorrimento o più come una tabella di transizione del puntatore a funzione? Utilizza l'allocazione dinamica della memoria o può essere utilizzato staticamente?

embedded programming state-machines

— ARF
fonte

Starei lontano da Boost MSM (e dai template C ++ in generale) mentre fanno esplodere le dimensioni del codice molto velocemente.

— jms

Ci sono altri gotchas in C ++ di cui essere a conoscenza ...

— Matt Young,

@jms È come dire che un taglialegna dovrebbe stare lontano da strumenti affilati e usare un martello perché con strumenti affilati potrebbe tagliarsi. I modelli sono uno strumento affilato che, se usato nel modo giusto, può aumentare la velocità e ridurre le dimensioni del codice, in particolare per i microcontrollori. Se usato nel modo sbagliato - beh, qualsiasi strumento può essere usato nel modo sbagliato!

— Wouter van Ooijen,

8

Sarei sorpreso se ci fosse una grande differenza in un MCU a 32 bit. Evitare i rami condizionali potrebbe salvarti alcuni cicli, ma riuscirai davvero o fallirai in base a pochi cicli? Il numero di stati di attesa su RAM e ROM è probabilmente altrettanto importante. Quindi è impostato il set di istruzioni della CPU.

L'ottimizzazione prematura è la radice di tutti i mali. Inizia con ciò che è più facile da implementare e gestire e ottimizza solo dove necessario in base alla profilazione.

— Adam Haun
fonte

Mi aspetterei che l'influenza sulle prestazioni di un quadro di macchine statali (sia fai-da-te che da qualche libary) - in opposizione alle azioni - è molto piccola. Quindi, come dice Adam: codice per prima leggibilità. Un secondo. E terzo. (A in decima posizione: profilo. L'ottimizzazione locale è molto inferiore a quella.)

— Wouter van Ooijen

3

Per un'implementazione di UML su embedded, dai un'occhiata al framework QP -> http://www.state-machine.com . Sono disponibili entrambe le varianti C e C ++. La GUI (QM) di accompagnamento consente persino di codificare usando la notazione UML. Il framework è abbastanza piccolo da funzionare su Arduino; I 32 bitter sono facili.

— Oleg Mazurov
fonte