Encoder rotativi

[Allanon]

• 

Ciao ragazzi,
stavo cercando su internet informazioni su come multiplexare gli encoder rotativi ma sembra che non sia una passeggiata, avete qualche info o consiglio, oppure ridimensiono il mio progetto a 8 encoder anzichè 16?

EIDT:
Gli encoder che vorrei prendere hanno due led interni per illuminare il perno trasparente (verde/rosso) ed un pulsante che si chiude alla pressione del perno.

[Z80Fan]

• 

Puoi indicare il modello di encoder che hai scelto?
Ci sono varie tipologie di encoder, quindi magari se hai già scelto un modello particolare possiamo provare a lavorare su quello.

[Allanon]

• 

Di definitivo non c'è nulla, sono in fase decisionale ancora, infatti inizialmente avevo pensato di utilizzare dei potenziometri ma dal momento che vorrei implementare la possibilità di salvare e caricare delle "scene", ossia dei valori già assegnati ai controller, sono passato agli encoder rotativi.

Avevo pensato a questo qua

Mentre il multiplexer (anche questo inizialmente pensato per i potenziometri) era questo, se ho capito bene che la lettura degli encoder avviene attraverso due pin/bit da leggere contemporaneamente suppongo che ci vogliano due Mux, uno per ogni pin di ogni encoder. Il doppio led non è indispensabile, ne posso fare a meno, ma il pulsante sull'encoder invece sarebbe molto utile, ad esempio per passare il controllo da un parametro all'altro.

Il progetto punterebbe a realizzare un pannello per pilotare una serie (svariata) di parametri del mio synth via MIDI, assieme agli encoder rotativi ci saranno anche degli slider per i volumi dei canali e una serie (ancora da decidere) di pulsanti hardware.

per adesso utilizzerei la gameduino come dispositivo di input/output e la mega2560, tuttavia nel progetto finale vorrei inserire un LCD 16x2 oppure un OLED piccolo da usare come strumento di feedback per quando i parametri vengono variati.

Data la natura programmabile dell'attrezzo, sarebbe una stupidaggine rimappare i controlli per qualsiasi altro dispositivo MIDI.

[Z80Fan]

• 

Ok allora...

I rotary encoder sono una figata, solo che sono relativamente difficili da usare "da soli" (ovvero senza un controller già pronto). Praticamente il principio di funzionamento di quel encoder è che hai due segnali digitali (A e B) che, quando il perno viene ruotato, generano due onde quadre uguali ma in quadratura (ovvero le loro fasi sono sfasate di 90°); in sostanza, se vedi un falling/rising edge prima su A e poi uno su B, allora capisci che si è ruotato di uno step in senso orario, mentre se ne vedi uno prima su B e poi su A allora è ruotato in senso antiorario (ovviamente devi verificare sul datasheet del preciso encoder che vuoi usare qual'è il pattern che usa).

Questo vuol dire che non puoi semplicemente dire all'encoder "hey, in che posizione sei?" e lui ti risponde "a 48°": tutta l'informazione che hai è che l'encoder si è mosso di uno step in senso orario o in senso antiorario, e se vuoi capire quanto si è spostato devi contare tutti i vari step. Puoi immaginare che se non controlli abbastanza velocemente, se uno gira troppo la manopola rischi di perdere step e di andare fuori sincronia con quella che è la posizione fisica dell'encoder (questo non è un problema se la manopola non ha nessuna indicazione di posizione, ma se ha una freccia o altre tacche lo è).

Se non usi un controller hardware che traccia questi impulsi per te e ti fornisce un numero "comodo" da usare, devi scriverti delle routine per leggere manualmente i due segnali e, conoscendo il loro stato precedente, capire come sono cambiati e aggiornare lo stato della tua applicazione.

Usare il multiplexer non è difficile: l'algoritmo è circa:

Codice: [Seleziona]

Per ogni X da 0 a NumeroEncoder-1:
    - Metti il multiplexer per la linea A sulla posizione X
    - Metti il multiplexer per la linea B sulla posizione X
    - Leggi i valori di A e B
    - Paragonali al precedente stato di A e B per l'encoder X (i.e. capisci come si è mosso)
    - Aggiorna lo stato interno dell'encoder X
    - ripeti.
Un polling di questo genere porta via una discreta quantità di elaborazione e, se hai X encoder, hai X volte più lavoro da fare.

L'altra modalità è usare una piccola FPGA che implementa X controller per gli X encoder direttamente in hardware; in questo modo garantisci che ogni encoder ha un suo controller dedicato e non perde mai uno step, e avere lato Arduino/applicazione un'interfaccia comoda con cui hai indietro direttamente il valore numerico della posizione. Ovviamente questa soluzione richiede che aggiungi l'FPGA come componente al tuo sistema, e ti richiede di imparare a programmare questo tipo di sistemi che è relativamente abbastanza diverso da programmare un sistema sequenziale (in realtà un controller per encoder è abbastanza piccolo come progetto, quindi se avevi mai intenzione di far qualcosa con una FPGA questo potrebbe essere un progettino comodo).

[Allanon]

• 

Grazie Z80Fan della delucidazione, più o meno avevo intuito la problematica, ma sta cosa di programmare la FPGA mi sega le gambe perchè già sono scarso con Arduino & Co. figuriamoci se mi dovessi mettere a studiare come programmare una FPGA 
Che tu sappia ci sono soluzioni già "confezionate" in giro? E poi un'altra domanda: se volessi provare a gestire, diciamo... 8 encoder rotativi (alla vecchia maniera, con interrupt senza controller), 8 slider (loop normale senza interrupt), una decina di pulsanti normalmente aperti e pilotare un LCD, secondo te la 2560 ce la fa?
Altrimenti dovrò passare ad altre alternative tipo questa qua: MIDI CPU, anzi, già che ci sei potresti dirmi cosa ne pensi?

[Z80Fan]

• 

Che tu sappia ci sono soluzioni già "confezionate" in giro?

Non so, non mi ero mai interessato fin'ora... da una veloce ricerca non ho trovato niente (usano tutti un microcontrollore programmato apposta).

E poi un'altra domanda: se volessi provare a gestire, diciamo... 8 encoder rotativi (alla vecchia maniera, con interrupt senza controller), 8 slider (loop normale senza interrupt), una decina di pulsanti normalmente aperti e pilotare un LCD, secondo te la 2560 ce la fa?

Per farcela credo si, anche abbondantemente, però dipende più che altro quanto pesante è il resto della tua applicazione, ovvero (se ho capito bene), generare i comandi MIDI e inviarli al sintetizzatore e aggiornare l'interfaccia grafica.
Non conosco il protocollo MIDI e non so quanto complesso è (anche se non credo molto), quindi non so dirti con esattezza se ce la farà o meno; lato LCD, se usi uno normale stile 2x16 a caratteri non è molto pesante, ma se decidi di usarne uno grafico (tipo un 64x128) devi mettere in conto molta più occupazione della cpu.

Intanto puoi iniziare a fare un prototipo, e in caso se vedi che non ce la fa puoi acquistare una board più potente, come la Teensy 3.1 che si programma allo stesso modo di Arduino, ha un processore ARM molto più veloce e capace e non costa tanto (intorno ai 20 euro in base a dove la compri).

Altrimenti, se già possiedi qualche altro Arduino o un'altra scheda simile, puoi usarne una per leggere solo gli input, e l'altra per elaborare il MIDI e l'LCD.

Altrimenti dovrò passare ad altre alternative tipo questa qua: MIDI CPU, anzi, già che ci sei potresti dirmi cosa ne pensi?

Boh, non conosco bene queste cose (e il fatto che il sito dice quasi niente senza doversi leggere il manuale non aiuta), però vedi te: se vuoi costruirti un sistema totalmente personalizzabile alle tue necessità, e nel mentre imparare qualcosa sull'elettronica digitale e programmazione embedded, allora continua sulla strada attuale; altrimenti, se il tuo scopo primario è avere qualcosa che quasi certamente funziona al primo colpo, e non ti dispiace spendere quella cinquantina di euro, vai per quella scheda.

Forse ti ho dato l'impressione che quello che vuoi fare è qualcosa di impossibile ; realisticamente, non credo che avrai tante difficoltà a tirar fuori qualcosa che funziona, ma ho voluto darti una visuale sui possibili problemi che potresti teoricamente avere, così puoi essere preparato in caso te li ritroverai davati.

[Allanon]

• 

Ok, grazie 1000 per le info, credo che per ora ordinerò un o' di robetta per sperimentare un po': 4 encoder, 4 slider, connettori midi e LCD, poi metto "in ascolto" l'arduino sulla porta MIDI e provo a fargli spedire qualche stringa ai miei dispositivi.
Il protocollo MIDI non è complesso e poi ci sono tonnellate di librerie già pronte che posso utilizzare come base di partenza

L'obiettivo è costruire qualcosa per le mie esigenze ma che ovviamente possa essere adattato facilmente con pochi colpi di codice, se un domani dovessi cambiare synth vorrei poter riutilizzare il progetto.
Terrò aggiornato il thread con i nuovi sviluppi!

[AmigaCori]

• 

 

lo vedo brutto il nostro Allanon.

[Allanon]

• 

Sto spulciando un po' di roba della Teensy, è una figata 
FPGA bocciata: non ho le competenze e come dice @legacy non ho l'attrezzatura adeguata
L'approccio PIC32 mi sembra un po' troppo complesso per le mie capacità 

Niubbo Forever
 

[Allanon]

• 

La Teensy sembra proprio faccia al caso mio anche perchè l'ambiente di sviluppo è praticamente lo stesso della arduino, vedo in giro un sacco di progetti simili a quello che dovrei fare io, quindi materiale di studio non manca 
Al più presto la ordino assieme agli encoder (senza led) + display