Arduino è solo un balocco e la relativa generazione di codice da FSM è anni luce lontana dai livelli di complessità di Statemate e simili, software che costano decine di migliaia di dollari.
In tal caso sarebbe perfino controproducente pensare di modellare l'intero sistema con una unica complessa FSM. Modellare i singoli elementi è di gran lunga più semplice, facile da verificare anche in modo intuitivo ed informale, facile da riusare e soprattutto adatto alle limitate capacità dell'ambiente scelto.
Alan_Reloaded ha scritto:
Infatti ho accuratamente evitato di aggiungere "grafica", lo scenario cui pensavo era proprio un microcontrollore però i MC possono avere interfacce, Arduino per primo. La FSM sarebbe indicata per evitare che l'utente trovi la pulsantiera/display poco reattivi, ma per il resto su un microcontrollore che non ha un suo SO con relativo schedulatore di processi, che tu implementi come FSM o nel modo tradizionale non fa differenza: in ogni caso stai portando avanti a rotazione tutti i processi, ciascuno un passo per volta tanto che - non serve dirlo - non ci sono problemi di accesso condiviso e così via.
Se ti serve la modularità + riusabilità, una FSM secondo me potrebbe anche essere un ostacolo perché ti spezzetta la leggibilità del flusso. Certamente in pratica ci si dovrà/potrà ricorrere perché non si sa dove si riutilizzerà il codice e in questo senso la FSM potrebbe essere un vantaggio. Ma non so dirlo dato che ho avuto un solo incarico professionale in vita mia dove ho peraltro solo sfiorato queste problematiche mentre occorrerebbe avere una certa esperienza per dire cose sensate.
In effetti, meglio evitare di sbilanciarsi su questi argomenti in assenza di una solida preparazione specifica e di una vasta esperienza. Personalmente ho programmato il mio primo microcontroller nel 1984 e negli ultimi 20 anni ho lavorato a livello multinazionale sui sistemi embedded più grandi, complessi e critici previsti dalle normative.
Ebbene, esistono sistemi altamente reattivi, in hard realtime certificato, basati su accurate combinazioni di hardware apposito, layering degli interrupt ed un banale "big loop" sequenziale, totalmente systemless... esistono perfino system on chip che incorporano core multipli gestiti da uno scheduler RR o EDF implementato su silicio, gestiti da firmware altamente semplificato e totalmente deterministico, nonostante la presenza di numerose risorse hardware condivise!
L'uso di FSM coordinate e gerarchiche, lungi dall'essere un ostacolo alla "leggibilità", è praticamente obbligatorio in casi dove si gestiscono spazi degli stati dell'ordine di 10^21 con garanzie di raggiungibilità e copertura, calcolate su supercomputer con metodi simbolici (BDD e derivate, logiche temporali) e riscontrate puntualmente nel codice generato tramite full code coverage e interpretazione astratta.
Naturalmente parliamo di livelli a distanze siderali dai sistemi di sviluppo altamente semplificati come Arduino.