Automa a stati finiti

[WALTERmwp]

Ciao paofanello, penso che quanto riportato da TardoFreak, nella sostanza, è ciò che serve.
Per quanto ne so, ma mi pare tu l'abbia compreso, lo ha spiegato bene.
Ridotta ai minimi termini una macchina a stati finiti è proprio uno switch, mettici anche solo tre case, ed hai un automa a stati.
Io scriverei "ode alla macchina a stati finiti", è un metodo che se ben impiegato ti consente di risolvere tante implementazioni e ti evita di "farti male" nel caso tu volessi articolare il codice diversamente ma senza sapere bene come.

E' un criterio che può essere impiegato in molte applicazioni e nello sviluppo di programmi specifici come, per esempio, un driver di comunicazione.
Uno dei tanti pregi di un codice scritto in tal modo, a mio parere, è quello di poter intervenire a posteriori e modificare, senza alcun patema d'animo, quanto già funzionante.

Lo sperimentai in ambito industriale, nella gestione di una macchina/impianto: praticamente ci feci tutto (o quasi tutto) quello che volevo e che si sarebbe potuto immaginare di fare su quell'impianto.
Fu davvero una grande soddisfazione (personale).

Chiaro che far aderire il principio a certi processi o a parte di questi può richiedere una certa attenzione, deve essere ben chiaro il criterio e l'approccio: estremizzando, se hai una colata continua non è che la puoi "congelare" un momentino per ripartire successivamente.

Potrebbe tornare utile anche questa discussione: ti invito a leggere il codice che aveva riportato l'utente.

Saluti

[speedyant]

Interessante. Avete qualche "riferimento cartaceo" a livello di istituto tecnico?

[TardoFreak]

Vorrei aggiungere una mia impressione su questo modo di scrivere programmi.
Non è molto che lo utilizzo perché non ho mai studiato seriamente gli automi (DFA,NFA), l'ho fatto ora perché serve per un esame.
Studiarli per studiarli ho preferito studiarli bene e poi ho provato ad applicarli in pratica, prima per il riconoscimento di stringhe e poi per i programmi su microcontrollore.
Immagino che ad ingegneria queste cose vengano spiegate più che bene (li ho visto applicati alle logiche programmabili con software che traducono le macchine a stati in sorgenti VHDL) quindi ho sicuramente scoperto l'acqua calda.
Ancora una volta ho dovuto disimparare il mio modo di lavorare "poca carta e molta tastiera" per utilizzare ancora una volta un approccio "molta carta, poca tastiera".
Con buona pace per lo smanettone che è in me, devo dire che questo è un approccio molto più rigoroso, con solide basi teoriche, affidabile e estremamente efficiente.
E nel lavoro affidabilità vuol dire molte rogne in meno, efficienza vuol dire risparmio di tempo, quindi di denaro e riduzione dei tempi di uscita dei prodotti (t.t.m.).
Dulcis in fundo ho ancora avuto l'ennesima riprova della mia abissale ignoranza.

[Candy]

Non e` detto che il tutto si riduca ad un semplice switch - case. Se si puo` usarlo il codice e` certamente ordinato e facile da leggere, ma capita spesso che vari stati siano da risolvere in task diversi, di un sistema multitasking. Le cose si complicano parecchio...

Ricordo che una volta esisteva anche il grafcet, che, a quanto pare non piace piu` a nessuno. Un linguaggio grafico che rappresenta molto bene le azioni e le transizioni tra gli stati.

[paofanello]

capita spesso che vari stati siano da risolvere in task diversi, di un sistema multitasking. Le cose si complicano parecchio...

Io ci provo a chiederlo...
Immagino sia difficile fare qualche esempio, vero?

[fairyvilje]

Più che altro se compare la concorrenza si preferiscono le reti di Petri agli automi a stati finiti. In questo modo la gestione delle risorse è esplicitata e si riescono a riconoscere condizioni di deadlock.

[Candy]

Immagino sia difficile fare qualche esempio, vero?

Personalmente stavo pensando, e mi riferivo, a diverse "logiche" residenti in sistemi diversi, che devono lavorare in modo coordinato, tramite una o piu` forme di comunicazione.

Un esempio abbastanza comune: A e` un oggetto che si muove nello spazio, e puo` "parlare" solo con B. C e` un altro oggetto, che si muove nello stesso spazio di A, ed a sua volta anche questi "parla" solo con B.
A e C non devono mai invadere contemporaneamente lo stesso spazio.

[WALTERmwp]

Interessante. Avete qualche "riferimento cartaceo" a livello di istituto tecnico?

posso suggerirti, se non lo hai fatto, di andare a quel thread che ho linkato, qualche cosa da guardare lo trovi.
Se non erro GuidoB aveva riportato dei riferimenti interessanti.
Poi, cercando si trovano altri thread(s), ma materiale didattico non ce l'ho sotto mano.

Non e` detto che il tutto si riduca ad un semplice switch - case (...)

si può spingere il principio e integrare le schedulazioni di parti di programmi (o processi, chiamateli come più congruo) sino a gestire (o confondersi) con un piccolo sistema operativo.
Comunque è un metodo che ti porta ad utilizzare un po' più di risorse rispetto ad un altro, ma per me sono tutte "spese" più che bene.
Il grafcet della Siemens (tool di programmazione con interfaccia grafica) segue il principio della FSM e ti vincola all'utilizzo di determinati simboli per realizzare la sequenza logica; per fare questo si riserva aree di memoria (risorse) che direttamente non utilizzi ma servono proprio all'interprete, di quanto è stato raffigurato, per poterlo tradurre in codice gestendo i passaggi (transizioni).
Queste risorse (nel grafcet) possono essere assimilate, riducendo l'esempio ai minimi termini, alla variabile che si impiega nello statement dello switch (... quello del linguaggio C).

Tornando alla diretta scrittura del programma ...
oltre che apparentemente, e quindi nella sostanza, si scrive quasi certamente più codice, si usa quindi più memoria programma e dati: in un microcontrollore, ma anche in un PLC, la questione può arrivare a rivestire una certa importanza ma in compenso l'evoluzione dell'applicazione risulta abbastanza veloce o comunque più veloce rispetto a quanto ci si potrebbe immaginare con tutto quello che si è scritto.
Chiaro, si tratta di tempi di ciclo, ma le risposte in termini prestazionali credo siano apprezzabili.

Saluti

[Candy]

Dico solo che il grafcet non e` una questione di Siemens, che tiri in ballo sai solo tu perche`.
Per quel che ricordo, si usava il Grafcet indipendentemente dai PLC, ma e` passata troppa acqua sotto i ponti.

[WALTERmwp]

(...) che tiri in ballo sai solo tu perche` (...)

semplice, perché lo riconduco a quell'esperienza, tutto qui; io, come qualcun altro forse, non abbiamo osservato il mondo intero.
Chi invece ha una veduta più ampia dispone certamente di più argomenti.

Saluti