Encoder rotativo con Arduino - collegamento e codice pratico

Un encoder per Arduino è una soluzione semplice solo in apparenza: in realtà decide quanto il progetto sarà fluido, reattivo e piacevole da usare. Qui trovi come funziona, come si collega davvero, quale logica di lettura conviene usare e quali errori eviterei subito, soprattutto quando il segnale inizia a saltare o il contatore si comporta in modo incoerente.

Come funziona davvero un encoder rotativo

Un encoder incrementale lavora con due segnali, di solito chiamati A e B, che cambiano stato con un leggero sfalsamento temporale. Arduino legge l’ordine di questi cambiamenti e capisce se stai ruotando in senso orario o antiorario. È questo il punto che molti principianti sottovalutano: non si tratta di leggere un valore continuo, ma di interpretare una sequenza di impulsi.

Io lo considero una specie di manopola senza fine. Ogni scatto non dice “sei a metà corsa”, come farebbe un potenziometro, ma comunica “hai fatto un passo in più” oppure “uno in meno”. Questo lo rende perfetto per menu, selezione di opzioni, navigazione su display e regolazioni a passi piccoli e controllati.

Se il modello include anche il pulsante integrato, di solito trovi un terzo segnale separato, spesso indicato come SW. Serve per la pressione sulla manopola e non va confuso con i segnali di rotazione. La parte utile da ricordare è semplice: A e B gestiscono il movimento, SW gestisce il click. Il resto del lavoro lo fa il software, che deve trasformare questi cambiamenti in una variabile leggibile dall’utente.

Capire bene questa logica ti evita un errore classico: aspettarti un comportamento analogico da un componente che, invece, parla per impulsi. Da qui si passa subito al cablaggio, che è il secondo punto in cui si vincono o si perdono ore di debug.

Collegarlo bene al primo colpo

Il cablaggio dipende dal tipo di componente che hai in mano. Un encoder “nudo” può avere tre terminali principali, mentre un modulo breakout in stile KY-040 spesso aggiunge VCC, GND e il pulsante. In pratica, con il modulo già pronto il montaggio è più comodo; con il componente grezzo devi essere un po’ più attento alla rete di pull-up e al riferimento di massa.

Quando il modulo ha anche il pulsante, io lo tratto come un ingresso a parte, con la stessa cura che darei a un normale bottone. È un dettaglio banale solo in apparenza, perché un cablaggio ordinato e corto riduce rumore, falsi impulsi e problemi difficili da riprodurre. A questo punto il dubbio vero non è più come collegarlo, ma come leggerlo in modo robusto.

Lettura del segnale con o senza libreria

Qui ci sono tre strade, e non sono equivalenti. La prima è la lettura diretta nel loop, semplice e veloce da provare. La seconda usa gli interrupt, quindi reagisce subito ai cambiamenti di stato. La terza si affida a una libreria già pronta, che secondo me è la scelta più sensata nella maggior parte dei progetti reali.

Le librerie più usate nell’ecosistema Arduino semplificano molto il lavoro: alcune contano gli impulsi del quadrature encoder, altre aggiungono il supporto al pulsante, altre ancora gestiscono meglio la direzione e il debouncing. Io le considero una buona scorciatoia quando il progetto deve essere stabile e non voglio reinventare ogni volta la stessa logica. Per un encoder usato come input umano, questa è quasi sempre la strada più pulita.

Se lavori su un Arduino Uno, la scelta dei pin è ancora più importante: hai margine limitato e non conviene sprecarlo con una logica fragile. In un progetto con display, menu e altri sensori, una lettura manuale troppo lenta si inceppa in fretta. Da qui nasce il problema più fastidioso, che non è l’encoder in sé, ma il modo in cui il segnale viene disturbato o filtrato male.

Gli errori che fanno perdere passi e pazienza

Il primo colpevole è quasi sempre il rimbalzo dei contatti. Nei moduli meccanici economici è normale che i segnali non cambino in modo perfettamente pulito: invece di un solo fronte, arrivano più transizioni ravvicinate. Se il software interpreta ogni variazione come un passo valido, il contatore salta avanti o indietro senza controllo.

Il secondo problema è il codice bloccante. Se nel loop hai delay(), stampe seriali troppo frequenti o aggiornamenti pesanti del display, l’encoder può perdere impulsi. Io cerco di tenere la lettura rapida e separata dalla logica lenta dell’interfaccia. In pratica: acquisizione veloce, elaborazione dopo. Questa disciplina fa una differenza enorme.

• Rimbalzo non gestito: filtralo con buon senso, non in modo aggressivo al punto da perdere rotazioni rapide.
• Massa instabile: collega bene GND e tieni i cavi corti, soprattutto sui prototipi su breadboard.
• Ordine dei canali sbagliato: se il verso è invertito, non è un disastro, è quasi sempre una correzione semplice.
• Loop troppo lento: evita funzioni pesanti mentre stai leggendo la manopola.
• Stato iniziale ignorato: all’avvio leggi sempre una condizione di partenza coerente, così non parti già con un errore accumulato.

Una precisazione importante: non serve “pesare” il debouncing all’infinito. Con gli encoder rotativi il trucco non è cancellare tutto ciò che cambia, ma distinguere i cambi reali dal rumore. Se esageri con i filtri, ottieni il problema opposto: la manopola diventa lenta e perde precisione. A quel punto è naturale chiedersi se questo componente sia davvero la scelta migliore rispetto ad altre soluzioni di input.

Quando conviene più di un potenziometro

Il confronto con il potenziometro è inevitabile, perché i due componenti si assomigliano solo a prima vista. Il potenziometro ti dà una posizione assoluta e immediata, mentre l’encoder ti dà un movimento relativo. Per questo il primo è perfetto quando vuoi leggere un valore preciso all’istante, il secondo quando vuoi spostare un valore su o giù senza limiti di corsa.

Io scelgo l’encoder quando voglio un’interazione più “da strumento” e meno “da manopola analogica”. Per esempio, in un menu di configurazione, ruoti finché arrivi alla voce giusta e poi premi per confermare. È un flusso naturale, economico e comodo da usare anche con un solo dito. Il potenziometro invece resta superiore quando la posizione deve essere letta subito e senza dipendere da software o memoria.

C’è però un limite importante che non va ignorato: un encoder non sa dov’è all’accensione. Se il sistema deve ripartire esattamente da un valore preciso, devi salvare quello stato in memoria o costruire una procedura di riallineamento. Questa differenza, da sola, spesso decide quale componente ha davvero senso nel progetto.

Come scegliere il modulo giusto senza complicarti la vita

Nel 2026 l’offerta è ampia, ma la logica della scelta non cambia molto: per un prototipo da banco basta un modulo economico e ben documentato, mentre per un uso più intenso io guardo soprattutto alla qualità meccanica e alla chiarezza degli scatti. La sensazione al tatto conta più di quanto sembri, perché un encoder troppo morbido o incerto rende l’interfaccia meno precisa già dopo pochi minuti di uso.

Se il progetto è una semplice interfaccia di menu, preferisco moduli con detent ben percepibili e pulsante integrato. Se invece devo usarlo spesso, magari su un pannello frontale o in un piccolo strumento da laboratorio, controllo con più attenzione la solidità dell’albero, la stabilità del contatto e la facilità di montaggio sul pannello. Un componente comodo da cablare ma fragile non è una vera scorciatoia.

• Prototipo rapido: modulo economico e cablaggio semplice.
• Menu e interfacce: scatti netti e pulsante di conferma.
• Uso intensivo: meccanica più solida e segnali meno rumorosi.
• Progetto con poco spazio: controlla bene l’ingombro e la disposizione dei pin.

In pratica, io cerco sempre un equilibrio tra facilità di montaggio e affidabilità del segnale. Spendere poco può andare benissimo, ma solo se non ti costringe poi a inseguire falsi impulsi o problemi di pressione del pulsante. Da qui l’ultimo passaggio utile: le regole che, nei miei test, fanno davvero la differenza quando il progetto smette di essere una prova da banco.

Le scelte che fanno funzionare bene un progetto vero

Se dovessi ridurre tutto a poche regole operative, partirei così: collegamento pulito, lettura rapida, logica separata dall’interfaccia. Non mi interessa costruire il circuito più elegante del mondo; mi interessa che la manopola risponda bene ogni volta, anche quando il codice cresce e il progetto si riempie di altre funzioni.

• Parto sempre con un test minimale sul monitor seriale, prima di aggiungere display e menu.
• Uso le pull-up interne solo se il modulo lo consente davvero e il segnale resta stabile.
• Evito di mescolare lettura dell’encoder e funzioni lente nello stesso blocco di codice.
• Passo a una libreria dedicata non appena il prototipo diventa un’interfaccia reale.

Quando questi quattro punti sono in ordine, l’encoder smette di essere un componente “capriccioso” e diventa un input preciso, economico e molto più naturale di tanti controlli analogici improvvisati. È proprio qui che Arduino rende bene: pochi fili, logica chiara e un’interazione che sembra semplice solo perché dietro è stata progettata nel modo giusto.