potenziometro o encoder

[venexian]

In generale hai ragione, ma non credo sia questo il caso di questo forum in cui sono tre giorni che si discute di come "far girare una manovella" che comunque in un modo o nell'altro tutti hanno sempre fatto funzionare.

Ho specificato che non mi riferivo al caso specifico. La chiave sta proprio nelle tue parole 'in un modo o nell'altro' qui sopra: nell'utilizzare il lavoro svolto da altri, non ci si preoccupa di capire, ma solo che 'in un modo o nell'altro' si riesca ad ottenere qualcosa di funzionante. Io trovo sia una cosa molto negativa, ma è un mio parere.

Il caso che tu proponi è giusto, la interrupt non capisce in quale stato si è e se anche si è fuori quadratura per lei è corretto.

No, no, no e ancora no! Il sistema con l'interrupt non funziona anche in casi assolutamente leciti, non solo quando l'encoder fornisce dati inverosimili!

Questa è la parte più importante della questione, per questo motivo quella soluzione è inaffidabile!

Prendiamo il caso descritto dal seguente diagramma

Enc2.png (7.82 KiB) Osservato 2126 volte

Se l'angolo di rotazione ha variazioni minime intorno al punto di transizione del segnale connesso all'interrupt, si ha errore di conteggio anche se l'encoder si comporta in modo assolutamente corretto.

[dadduni]

forse sbaglio e non ho capito qualcosa di importante, ma l'impulso che genra il n+2 non è mica un caso lecito, no?

[venexian]

Ho seguito passo passo la macchina a stati e, sarà un mio limite, ma ci vedo lo stesso sistema delle interrupt che triggera su entrambi i fronti.

Qui si apre un altro mondo: se il sistema 'a interrupt' triggera su entrambi i fronti, l'errore non è più quello dei conteggi doppi di cui si è parlato finora, ma molto molto più subdolo. Cerco di spiegarlo...

Come regola generale, quando ci si aspettano eventi ripetuti a frequenza imprevedibile, non è lecito gestirli con routine di interrupt che facciano affidamento sulla certezza della loro cattura. Questo perché mentre si è all'interno della routine di interrupt, successivi interrupt dello stesso tipo vengono ignorati o, al massimo, viene memorizzato il primo di loro e ignorati i seguenti.

Nel caso specifico, le vibrazioni angolari attorno all'angolo di commutazione dell'encoder portano alla generazione di un numero imprevedibile di impulsi che il sistema 'a interrupt' non è in grado di assicurare la cattura. Inserendo filtri all'ingresso e operando con ingressi a trigger, questo problema viene mitigato, ma si tratta sempre di 'pezze', non di buona progettazione.

Non voglio dire una fesseria ma credo che nella sequenza
1) 0 0
2) 1 0
3) 1 1
4) 0 1
io ci vedo un solo incremento invece la macchina a stati ne vede due

Certo! Perché, oltre a essere quella che funziona, la macchina a stati legge l'encoder a piena risoluzione, mentre il sistema a interrupt lo legge con risoluzione dimezzata!

[venexian]

forse sbaglio e non ho capito qualcosa di importante, ma l'impulso che genra il n+2 non è mica un caso lecito, no?

E' un caso assolutamente lecito (per l'encoder).

[EcoTan]

1) Il polling non è un uso massiccio del micro

Può essere addirittura più veloce dell'interrupt perché non salva i registri.
Tuttavia se poi vogliamo fare anche altre cose, magari connesse, il polling può ingarbugliarsi seriamente, mentre l'interrupt consente di programmare distintamente su due livelli: ISR per lo HW e sue ricadute immediate, main per la gestione generale del sistema. Non ho mai studiato teoricamente questa roba, addirittura non so che cosa esista, lo dico proprio per esperienza.

[venexian]

[il polling] Può essere addirittura più veloce dell'interrupt perché non salva i registri.

Vero!

Tuttavia se poi vogliamo fare anche altre cose, il polling può ingarbugliarsi seriamente...

Anche no: questo tipo di polling dovrebbe essere eseguito su interrupt di un timer, che assicura la ripetibilità degli intervalli di campionamento e la certezza della loro esecuzione. Se la restante parte del codice non ha vincoli di esecuzione temporale la si può lasciare così com'è. Se invece ci sono più parti del programma con vincoli temporali concorrenti, è necessario realizzare uno scheduling che assegni alle varie routine degli slot temporali predefiniti.

[elfo]

perché non si può fare come ha proposto xyz?

Ha gia' ben risposto venexian al post [31]

elfo, non capisco perché sia necessario interporre fra il microcontrollore e l’encoder della logica, quando scrivendo un paio di righe di codice in più sull’HAL se ne possa fare a meno

Il concetto che volevo far passare e che ha sempre espresso venexian nel post [37]

è un globale andamento di sciatteria generale nella progettazione. Non ci si preoccupa più di fare un lavoro 'fatto bene' e, prima di tutto, di capire perché si debba utilizzare una soluzione invece di un'altra

e' che

negli anni '90 ... sia in logica discreta sia IC e la tecnica gia' allora era ben consolidata

il "problema" era gia' stato ampiamente risolto.
Oggi e' possibile, con maggior liberta', implementarla anche in SW ma solo dopo aver capito "bene" il problema.

[dadduni]

sono contento di questa conversazione, mi ero fermato alla prima soluzione ragionevole non avevo idea di questo mondo che c'era dietro

[lelerelele]

(*) In realtà, l'idea ce l'ho. Non è certo il caso specifico di lelerelele, ma è un globale andamento di sciatteria generale nella progettazione. Non ci si preoccupa più di fare un lavoro 'fatto bene' e, prima di tutto, di capire...

Di questo sono perfettamente d'accordo.
Evito commenti in merito alle possibili cause perché off-topic
saluti

[dadduni]

Evito commenti in merito alle possibili cause perché off-topic

facci sapere la tua idea!