Un tastierino matriciale porta un vantaggio semplice ma decisivo: ti fa inserire codici, menu e comandi fisici senza occupare tanti pin e senza complicare il progetto. Questo articolo prende il caso più comune del keypad arduino e lo porta su un piano pratico: come funziona davvero, come si collega, quale libreria usare, quali errori evitare e quando conviene scegliere un’alternativa più elegante.
In breve, il tastierino giusto dipende da pin disponibili, numero di tasti e tipo di progetto
- Un tastierino 3x4 usa 7 collegamenti e basta per PIN e menu semplici.
- Un 4x4 aggiunge tasti utili, ma richiede 8 collegamenti in totale.
- La libreria Keypad gestisce scansione, lettura e debounce senza codice pesante.
- Con pochi pin liberi, la variante su I2C riduce il cablaggio.
- Se vuoi emulare una tastiera per il PC, servono schede con USB nativo.
Perché un tastierino matriciale risolve un problema reale
Io lo uso quando il progetto deve ricevere input locale, ma non ha senso montare una tastiera completa o un pannello complesso. Il principio è semplice: invece di assegnare un pin a ogni tasto, il tastierino mette i contatti in una matrice di righe e colonne. L’Arduino scansiona le righe, legge le colonne e capisce quale tasto è stato premuto.
Il vantaggio vero non è solo risparmiare pin. È anche ottenere un’interfaccia fisica più robusta di un encoder improvvisato o di una serie di pulsanti sparsi. Per un allarme con PIN, un menu di configurazione, una cassetta di sicurezza o un piccolo strumento da banco, funziona meglio di quanto molti principianti si aspettino. Non è invece la scelta giusta per scrivere testo libero: per quello la frizione cresce subito e conviene un dispositivo diverso.
La libreria Keypad trattata nella documentazione ufficiale di Arduino nasce proprio per questo scenario e, nelle versioni più recenti, supporta anche più pressioni contemporanee. Nel caso normale, però, basta leggere un tasto alla volta e il codice resta molto pulito. Da qui in poi, il punto è scegliere il cablaggio più sensato.
Come collegarlo senza occupare troppi pin
Un tastierino 3x4 standard richiede 7 linee totali: 4 righe e 3 colonne. Un 4x4 ne richiede 8. Nei moduli a membrana i pin non sono sempre numerati nello stesso modo da un produttore all’altro, quindi io controllo sempre la disposizione prima di saldare o infilare i jumper. È il tipo di dettaglio che sembra banale, ma salva un’ora di prove a caso.
| Soluzione | Collegamenti | Vantaggio principale | Limite reale | Quando la scelgo |
|---|---|---|---|---|
| Tastierino 3x4 diretto | 7 pin | Cablaggio semplice e costo basso | Meno tasti disponibili | PIN, conferme, piccoli menu |
| Tastierino 4x4 diretto | 8 pin | Più funzioni e tasti dedicati | Usa più I/O della scheda | Shortcut, menu più ricchi, comandi rapidi |
| Tastierino su I2C | 4 fili totali | Risparmia pin e semplifica il layout | Serve un modulo dedicato | Progetti già pieni di sensori o display |
Se il tuo progetto usa già bus I2C, questa seconda strada è spesso la più pulita. Se invece hai pin liberi e vuoi la massima semplicità, il collegamento diretto resta il migliore: meno componenti, meno punti di guasto.
Il dettaglio che conta davvero è la corrispondenza tra righe e colonne. Se l’ordine non coincide con la mappa usata nel codice, i tasti sembrano “sbagliati” anche se elettricamente tutto è corretto. Per questo io tengo sempre una tabella dei collegamenti accanto al banco di lavoro. Una volta scelto il cablaggio, il passo successivo è scrivere uno sketch essenziale che confermi subito se tutto risponde come deve.
Il codice minimo che rende il tastierino subito utilizzabile
La parte bella è che non serve inventarsi un algoritmo complicato. Installo la libreria Keypad dal Library Manager, definisco la mappa dei tasti e leggo la pressione nel loop. Questo approccio funziona bene perché separa hardware e logica: la libreria gestisce la scansione della matrice, io mi occupo solo di cosa fare quando arriva un carattere.
#include
const byte ROWS = 4;
const byte COLS = 4;
char keys[ROWS][COLS] = {
{'1', '2', '3', 'A'},
{'4', '5', '6', 'B'},
{'7', '8', '9', 'C'},
{'*', '0', '#', 'D'}
};
byte rowPins[ROWS] = {9, 8, 7, 6};
byte colPins[COLS] = {5, 4, 3, 2};
Keypad keypad = Keypad(makeKeymap(keys), rowPins, colPins, ROWS, COLS);
void setup() {
Serial.begin(9600);
keypad.setDebounceTime(25);
keypad.setHoldTime(800);
}
void loop() {
char key = keypad.getKey();
if (key) {
Serial.println(key);
}
} Se il tasto arriva doppio, io alzo il debounce a 30 o 40 ms. Se invece il progetto deve distinguere tra pressione breve e pressione lunga, il valore di hold time diventa utile. Per un PIN classico tengo la logica più semplice possibile: il codice legge il carattere, lo mostra sul monitor seriale e poi lo passa alla routine che confronta la password.
Se il tuo tastierino ha una disposizione diversa, cambia solo l’arraykeys. Il resto del codice può restare uguale. È proprio questa l’idea forte della libreria: una volta che la matrice è descritta bene, il progetto diventa stabile e facile da mantenere. Prima però conviene conoscere gli errori più frequenti, perché sono quelli che fanno perdere più tempo.
Gli errori che fanno perdere tempo ai principianti
- Scambiare righe e colonne. Il risultato è un tastierino che sembra “impazzito”, ma in realtà sta solo leggendo una mappa diversa da quella prevista.
- Usare una disposizione dei pin data per scontata. Due modelli visivamente simili possono avere l’ordine dei contatti differente.
- Lasciare il debounce troppo basso. Con tasti economici o cavi lunghi, una lettura troppo aggressiva produce doppi input.
- Premere più tasti insieme senza aver previsto il ghosting. In una matrice senza diodi possono comparire combinazioni false.
- Trattare il tastierino come se fosse una tastiera completa per scrivere testo. Non è il suo terreno naturale e il progetto si complica inutilmente.
Il ghosting compare quando premi più tasti contemporaneamente su una matrice non protetta da diodi: il controller può leggere una combinazione falsa. Per un PIN questo non è quasi mai un problema; per una macchina da gioco o per scorciatoie multiple sì, e lì bisogna progettare con più attenzione.
Un altro errore che vedo spesso è voler usare il tastierino come se fosse una mini tastiera per PC. Non è il suo ruolo naturale. Se ti serve davvero un dispositivo che scriva su un computer, conviene cambiare architettura invece di forzare il progetto. Ed è qui che entrano in gioco le varianti I2C e USB nativo.
Quando conviene usare I2C o una scheda con USB nativo
Se Arduino deve limitarsi a ricevere input e gestire un dispositivo locale, il collegamento diretto è perfetto. Se invece i pin scarseggiano o hai già una rete di sensori, l’I2C libera spazio e semplifica il layout. La documentazione ufficiale di Arduino segnala anche un’altra strada: le funzioni Keyboard per le schede con USB nativo, utili quando il tastierino deve comportarsi come una vera tastiera verso un computer.
| Scelta | Quando la uso | Vantaggio principale | Limite reale |
|---|---|---|---|
| Tastierino diretto | Progetti semplici, pochi componenti, massimo controllo | Nessun modulo extra, debug immediato | Assorbe più pin digitali |
| I2CKeyPad | Quando voglio ridurre il cablaggio e lasciare liberi gli I/O | Quattro fili totali e layout più ordinato | Serve un modulo compatibile e un po’ più di attenzione nella configurazione |
| Keyboard su USB nativo | Quando il tastierino deve inviare input a un PC | Comportamento da tastiera vera | Funziona solo su schede adatte, non su ogni Arduino classico |
La libreria I2C dedicata è comoda per tastierini 4x4 o più piccoli quando vuoi tenere il progetto pulito. Per contro, se usi una scheda classica e ti bastano pochi tasti, non c’è motivo di aggiungere un altro modulo solo per risparmiare due o tre righe di codice. Io scelgo in base al contesto, non per moda tecnica.
Se il tuo obiettivo è un pannello di controllo, un blocco PIN o una piccola interfaccia di configurazione, la soluzione più lineare resta quasi sempre la più solida. Quando invece il progetto cresce e ogni pin conta, I2C diventa una scelta sensata. A quel punto la decisione è molto più chiara.
La configurazione che sceglierei per un progetto pulito e affidabile
Se dovessi partire oggi, per un allarme domestico o un menu di configurazione io sceglierei un 3x4 diretto se mi bastano numeri e pochi simboli, oppure un 4x4 se voglio tasti funzione e maggiore flessibilità. In entrambi i casi partirei con la libreria Keypad, un debounce moderato e una mappa tasti verificata con calma prima di passare alla logica applicativa.
- Per un PIN o un comando singolo, il 3x4 è spesso la scelta più pulita.
- Per scorciatoie e menu più articolati, il 4x4 offre più margine.
- Per un progetto già affollato, l’I2C riduce subito il caos dei fili.
- Per interagire con un computer, conviene valutare una scheda con USB nativo.
La parte che fa davvero la differenza non è la libreria in sé, ma la cura di tre dettagli: mappa corretta, cablaggio ordinato e debounce sensato. Se questi tre elementi sono a posto, il tastierino smette di essere un componente “semplice” e diventa una vera interfaccia utente per il progetto. E, nei lavori pratici, è proprio questo che conta di più.
