In effetti la macchina a stati mi sembra sia rappresentabile più intuitivamente con questa simbologia.
Questo è un disegno dei primi anni '80 che rappresenta la procedura di allineamento trama di un multiplatore Pcm 140 Mbit/s.
Amichevolmente è definito pallogramma.
Ciao
Debounce software interrupt esterno
Moderatori: MassimoB,
WALTERmwp,
xyz
49 messaggi
• Pagina 4 di 5 • 1, 2, 3, 4, 5
0
voti
GioArca67 ha scritto:L'array tabT raccoglie lo stato (fase) futuro per ogni possibile stato presente, riga, ed ogni possibile ingresso, colonna.
Grazie per l' aiuto, ma credo di essere ancora lontano, dovro studiarmi la macchina a stati e la rappresentazione con la matrice.
Piuttosto

Va beh, non sono così presuntuoso da voler capire tutto,


Per ora, ho "risolto" usando delayMicroseconds(), che invece, a quanto ho capito dovrebbe funzionare correttamente entro certi tempi.
Resta il fatto che c' è un delay all' interno di una ISR che non è il massimo, ma un minimo di ritardo prima di leggere lo stato dei pin mi serve e in altro modo non sono stato in grado di farlo.

0
voti
Io avevo sempre letto che all'interno delle ISR bisognava mettere il meno possibile, credo (ma non ne sono sicuro) perche' mentre e' in una ISR alcune cose non funzionano, per cui meno ci rimane e meglio e' .
Per curiosita' , avevi poi provato con il debounce hardware a vedere se il problema si risolveva (che cosi non dovevi usare nesun delay da nessuna parte), o lo hai scartato a prescindere ?
Chiedo perche' le poche volte che ho usato encoder, con la soluzione hardware non mi ha mai dato problemi.
Per curiosita' , avevi poi provato con il debounce hardware a vedere se il problema si risolveva (che cosi non dovevi usare nesun delay da nessuna parte), o lo hai scartato a prescindere ?
Chiedo perche' le poche volte che ho usato encoder, con la soluzione hardware non mi ha mai dato problemi.
"Sopravvivere" e' attualmente l'unico lusso che la maggior parte dei Cittadini italiani,
sia pure a costo di enormi sacrifici, riesce ancora a permettersi.
sia pure a costo di enormi sacrifici, riesce ancora a permettersi.
-
Etemenanki
7.669 3 6 10 - Master
- Messaggi: 4805
- Iscritto il: 2 apr 2021, 23:42
- Località: Dalle parti di un grande lago ... :)
0
voti
Al momento no, ma come dicevo in [9], altre volte si, proprio con questo tipo di encoder ee ero riuscito discretamente.Etemenanki ha scritto:Per curiosita' , avevi poi provato con il debounce hardware a vedere se il problema si risolveva (che cosi non dovevi usare nesun delay da nessuna parte), o lo hai scartato a prescindere ?
Chiedo perche' le poche volte che ho usato encoder, con la soluzione hardware non mi ha mai dato problemi.
Come dicevo, ho voluto provare via software come si diceva nella discussione di cui si parla in [7] [8] [9].
Etemenanki ha scritto:Io avevo sempre letto che all'interno delle ISR bisognava mettere il meno possibile, credo (ma non ne sono sicuro) perche' mentre e' in una ISR alcune cose non funzionano, per cui meno ci rimane e meglio e' .
In effetti lo sapevo anch' io, ma quello è un problema che deriva dalla mia incapacità di scrivere del codice decente, non dal fatto di usare gli interrupt e di fare il debounce via software.

Comunque sia, per i tempi in gioco, mi pare che funzioni decentemente anche così, senza perdere scatti o prendere rimbalzi.
0
voti
lucaking ha scritto:Per ora, ho "risolto" usando delayMicroseconds(), che invece, a quanto ho capito dovrebbe funzionare correttamente entro certi tempi.
Resta il fatto che c' è un delay all' interno di una ISR che non è il massimo, ma un minimo di ritardo prima di leggere lo stato dei pin mi serve e in altro modo non sono stato in grado di farlo.
Nell'ISR metti solo alcuni flag o incrementi delle variabili, poi leggi tutto nel loop in un if attivato dal flag impostato nell'ISR
0
voti
Etemenanki ha scritto:Io avevo sempre letto che all'interno delle ISR bisognava mettere il meno possibile, credo (ma non ne sono sicuro) perche' mentre e' in una ISR alcune cose non funzionano, per cui meno ci rimane e meglio e' .
Certo, meno roba metti nei service di interrupt e meglio è, anche solo per una questione di efficienza di codice.
-
PietroBaima
88,9k 7 12 13 - G.Master EY
- Messaggi: 12031
- Iscritto il: 12 ago 2012, 1:20
- Località: Londra
0
voti
no, ti è stato ripetuto più volte: togli quei ritardi dalla routine, altrimenti diviene inutile il ricorso stesso all'interrupt.lucaking ha scritto:(...) Per ora, ho "risolto" usando delayMicroseconds(), che invece, a quanto ho capito dovrebbe funzionare correttamente entro certi tempi.
Resta il fatto che c' è un delay all' interno di una ISR che non è il massimo, ma un minimo di ritardo prima di leggere lo stato dei pin mi serve e in altro modo non sono stato in grado di farlo.
Cosa fare in alternativa è stato scritto: nella ISR modifichi una variabile, fuori dalla ISR(cioè nel loop) ne controlli il valore ed in funzione del test agisci di conseguenza, il che dovrebbe comportare l'attivazione di una temporizzazione(per il debounce ...), magari tramite interrupt.
Saluti
W - U.H.F.
-
WALTERmwp
29,5k 4 8 13 - G.Master EY
- Messaggi: 8763
- Iscritto il: 17 lug 2010, 18:42
- Località: le 4 del mattino
1
voti
WALTERmwp ha scritto:Cosa fare in alternativa è stato scritto: nella ISR modifichi una variabile, fuori dalla ISR (cioè nel loop)
Anche se l'ho indicato sopra mi piace pochissimo nel caso in esame.
Ok solo per eventi radi e loop abbastanza veloce, altrimenti diventa un polling.
49 messaggi
• Pagina 4 di 5 • 1, 2, 3, 4, 5
Chi c’è in linea
Visitano il forum: Nessuno e 20 ospiti