Archivi categoria: arduino

I miei corsi per Tecnica della Scuola: Creare un kit di robotica educativa a basso costo 6ª ed.

Ogni anno rivivo la stessa situazione: colleghi motivati, studenti curiosi, qualche kit in laboratorio… e poi l’ostacolo vero, quello che nessun manuale risolve da solo: come rendere la robotica sostenibile, replicabile e davvero “per tutti”, senza dipendere da un unico carrello di materiale costoso o da una singola postazione.

Da qui nasce (e cresce, edizione dopo edizione) “Creare un kit di robotica educativa a basso costo”: un percorso pratico, laboratoriale, pensato per chi vuole costruire un set di robotica essenziale ma potente, personalizzabile e soprattutto portabile in classe con attività pronte.

L’idea chiave del corso è: non comprare un kit, imparare a costruirlo (e a farlo costruire)

Questo webinar non è una “vetrina di strumenti”: è un percorso operativo che vi guiderà a:

  • progettare un robot didattico partendo da zero, con componenti accessibili;
  • impostare un percorso di base su programmazione e robotica, con una metodologia laboratoriale;
  • creare materiali e consegne che puoi riutilizzare ogni anno, adattandole ai tuoi studenti.

Cosa cambia in questa 6ª edizione: più tempo, più attività “effetto laboratorio”

La novità più importante è che questa edizione è stata estesa a 4 lezioni (prima erano 3). Questo tempo in più non è “teoria aggiunta”: è spazio reale per attività che, nella didattica quotidiana, fanno la differenza perché diventano UDA, compiti autentici, mini-progetti e sfide.

In particolare, nella parte avanzata lavoreremo su:

  • controllo del robot con gesture recognition: addestriamo un semplice sistema di Machine Learning che riconosce i gesti dell’utente via webcam, e li trasformiamo in comandi;
  • progettazione e set-up di mini robot Sumo (con focus su regole, arena, test e iterazione);
  • realizzazione di semplici bracci robot (meccanica essenziale + servocomandi + compiti di pick&place).
  • … e molto altro

Robot “stampati” o “di cartone”: il corso resta accessibile anche senza stampante 3D

La struttura dei robot sarà basata su modelli:

  • stampabili in 3D, per chi dispone di stampante;
  • replicabili in cartone (con progetti e sagome), per chi preferisce una soluzione a costo ancora più basso o vuole lavorare in modalità maker “low-tech”.

Questa scelta non è un ripiego: è una strategia didattica. La stessa attività può vivere su materiali diversi, mantenendo invariati gli obiettivi di coding, problem solving e progettazione.

Piattaforme: BBC micro:bit (al centro) e Arduino (per estensioni e ponti)

Il corso nasce con BBC micro:bit come piattaforma centrale (perfetta per avviare coding e robotica anche con studenti al primo approccio). Useremo MakeCode / Blocks per costruire da subito comportamenti significativi e testabili.

Per alcune estensioni e per chi desidera spingersi oltre, porteremo anche esempi e varianti con Arduino, mantenendo però la stessa logica: progetti essenziali, replicabili, sostenibili.

Per micro:bit lavoreremo in particolare con:

  • Ring:bit V2
  • Kitronik :MOVE mini

Struttura del percorso: dalle basi alla costruzione completa

Il corso è progettato per accompagnarvi con progressione chiara (e riusabile in classe):

  1. micro:bit + programmazione a blocchi: basi operative e programmi tipici per gestire un robot (movimento, comandi, logiche).
  2. Tinkercad per la progettazione 3D: modellazione essenziale per creare/riadattare la struttura del robot, con esportazione dei file per stampa 3D o taglio.
  3. assemblaggio: componenti fondamentali (breadboard, motori, sensori, LED) e integrazione HW/SW fino a ottenere un robot funzionante.
  4. lezione extra (novità): ML con webcam per controllo a gesti + Sumo + braccio robot, con indicazioni pratiche su come trasformare tutto in attività valutabili.

Calendario e modalità: 4 webinar live (2 ore ciascuno) + registrazioni

4 incontri in diretta, 2 ore ciascuno, per un totale di 8 ore:

  • Venerdì 16 gennaio 2026 (17:00–19:00)
  • Martedì 20 gennaio 2026 (17:00–19:00)
  • Martedì 27 gennaio 2026 (17:00–19:00)
  • Martedì 3 febbraio 2026 (17:00–19:00)

Il corso è in modalità webinar con docente dal vivo e possibilità di interazione via chat. Inoltre, potrete rivedere le registrazioni senza limiti di tempo e scaricare i materiali dalla piattaforma.

Materiali inclusi: quello che ti serve per replicare in autonomia

Durante il percorso verranno forniti:

  • schede didattiche di approfondimento;
  • file/sorgenti per stampa 3D o taglio delle strutture;
  • codici di programmazione;
  • attività di laboratorio da svolgere con gli studenti.

Il corso è pensato per docenti della primaria (classe quinta) e della secondaria di I e II grado.

È adatto sia a chi parte da zero, sia a chi vuole finalmente mettere ordine e trasformare esperimenti sporadici in un percorso continuativo.

Iscrizione

Se volete iniziare l’anno con un percorso concreto, che vi lascia un kit replicabile e attività spendibili da subito, trovate tutte le informazioni e l’iscrizione nella pagina ufficiale del corso seguendo il link.

N.B. Pubblicherò ulteriori post dove fornirò suggerimenti operativi che vi saranno utili per realizzare con me tutte le attività programmate.

Buon Making a tutti 🙂

Configurare Arduino UNO R4 WiFi per Arduino Cloud

Nelle prossime settimane svolgeremo una serie di attività di laboratorio dedicate alla realizzazione di semplici applicazioni IoT con Arduino Cloud, utilizzando come scheda di riferimento Arduino UNO R4 WiFi. Per lavorare in modo ordinato ed efficace, questa guida introduttiva nasce con un obiettivo preciso: accompagnare gli studenti passo dopo passo nella configurazione della scheda e nel collegamento al Cloud, così da essere operativo fin da subito.

Queste attività sono importanti perché ci permetteranno di passare dal classico circuito “che funziona sul banco” a un sistema realmente utile e osservabile: potremo monitorare da computer o da dispositivi mobili lo stato dei sensori (temperatura, luce, presenza, umidità, ecc.), visualizzare i dati su dashboard, registrare misure nel tempo e, quando necessario, intervenire da remoto attivando uscite e comandi (ad esempio LED, relè o attuatori). In altre parole, costruiremo piccoli prototipi che riproducono lo stesso schema operativo di molte soluzioni industriali e domotiche: sensore > rete > dashboard > controllo, con attenzione a affidabilità, leggibilità dei dati e sicurezza di base.

Questa guida è tratta dalla guida ufficiale su cui ho apportato alcune mie modifiche e le ho rese “più didattiche”.

Di seguito dettaglio la procedura essenziale per portare Arduino UNO R4 WiFi “online” collegandola all’Arduino Cloud.

Arduino UNO R4 WiFi, come già dettagliato in precedenti tutorial, integra un modulo radio dedicato (ESP32-S3) che mette a disposizione la connettività WiFi: grazie a questo componente la scheda può collegarsi a Internet e dialogare con i servizi Cloud senza hardware aggiuntivo. Da qui nasce il passaggio chiave dei nostri laboratori: non ci limiteremo a far “funzionare un circuito”, ma impareremo a pubblicare dati, visualizzarli su una dashboard e, quando serve, inviare comandi da remoto.

Al termine della configurazione potrete:

  • caricare sketch anche via rete (OTA, over-the-air) quando previsto dal flusso Cloud,
  • costruire dashboard consultabili da PC o smartphone,
  • monitorare variabili e sensori in tempo reale e, in prospettiva, realizzare prototipi utili per domotica, automazione e telemetria.

Cosa serve

  • Arduino UNO R4 WiFi
  • Arduino Cloud (account gratuito e accesso alla piattaforma)

Configurazione e procedura

Prima di iniziare, se non avete mai utilizzato Arduino Cloud, vi consiglio di dare un’occhiata alla guida “Getting Started With the Arduino Cloud” che vi aiuterà a capire i concetti base e vi farà risparmiare tempo durante la configurazione, però durante le lezioni che seguiranno vi fornirò tutte le indicazioni.

Continua a leggere

Sensori e attuatori lontani da Arduino: guida pratica al cablaggio corretto

Metto in evidenza la mia risposta ad una domanda di un utente in riferimento ai problemi causati dalla lunghezza delle linee che collegano Arduino ai dispositivi elettronici.

Marco sei gentilissimo, grazie 🙂
Immagino che tu ti stia riferendo ai collegamenti diretti dei tuoi dispositivi elettronici ad Arduino, è un problema tipico che mi trovo spesso ad affrontare, inoltre l’attività di automazione del controllo di un plastico di trenini è qualcosa che spesso viene svolto a scuola.

Di seguito ti faccio una lista di problemi e soluzioni in riferimento alle problematiche di collegamento, sono molto sintetiche perché sono tratte dalle slide per i miei studenti, quindi sono quasi un copia ed incolla dalle slide sono strutturate a lista puntata con sintesi di spiegazione spero sia sufficiente per risolvere il tuo problema.

Spero di non spaventare con la risposta, in realtà mentre scrivo è diventata una guida sulle possibili cause del problema che stai riscontrando, credo che tu possa risolvere seguendo i 3 passi che trovi alla fine di questa risposta, (al fondo dove scrivo: “ATTENZIONE giusto per non spaventare“), credo che risolverai al PASSO 1.

Allora come dici: perché “allungando i fili di 2 metri il giochino non funziona più?”

Le cause possono essere:

1. Caduta di tensione sui cavi (power)
A 2 m il cavo introduce resistenza: se il dispositivo assorbe corrente (anche solo un relè, un servo o una striscia LED), la tensione arriva più bassa al carico.
Sul banco hai 5V applicati al dispositivo, sul plastico può diventare “4.4–4.7 V” e alcuni moduli iniziano a fare cose strane (reset, letture errate, relè che non agganciano, servo che impazziscono).

Sintomi tipici: Arduino che si resetta quando scatta un relè/servo, sensori instabili, moduli che “a volte sì a volte no”.

2. Disturbi elettromagnetici e ritorni di massa (ground)
Nel plastico ci sono spesso motori, bobine, elettromagneti, alimentatori switching: generano disturbi. Con cavi lunghi aumenta l’area del “loop” e quindi la sensibilità ai disturbi.
In più, se la massa (GND) non è distribuita bene, il riferimento logico “0 V” non è più uguale dappertutto: per Arduino un “HIGH” può non essere più così HIGH 🙂

Sintomi tipici: ingressi digitali che cambiano da soli, finecorsa che “rimbalzano” anche senza toccarli, comunicazioni che falliscono.

Precisazione: quando dico area di “loop” intendo l’area racchiusa dal percorso andata + ritorno della corrente

  • andata: dal pin Arduino (o dall’alimentazione) verso il componente tramite il filo del segnale o del +V
  • ritorno: dal componente che torna a GND (massa) e rientra verso Arduino/alimentatore

Questi due fili (andata e ritorno) formano, di fatto, una spira. Più i due conduttori sono lontani tra loro, più la spira ha area grande.

Una spira con area grande:

  • capta disturbi (si comporta come un’antenna “ricevente”)
  • irradia disturbi (si comporta anche come un’antenna “trasmittente”), soprattutto se nel loop scorrono correnti impulsive (relè, motori, servo)

Ti faccio un esempio pratico che riguarda il tuo progetto:

  • caso “peggiore”: cavo del segnale che va da solo lungo il plastico, e il ritorno GND passa da un’altra parte (magari su una barra massa distante). Loop grande > più problemi.
  • caso “migliore”: segnale e GND viaggiano vicini (idealmente intrecciati). Loop piccolo > molto più robusto.

Come risolvere in questo caso

Per ogni collegamento “lungo”:

  • porta SEMPRE insieme segnale + GND (o +V + GND) nello stesso cavo
  • meglio ancora: usa doppino intrecciato (twisted pair): riduce l’area del loop e quindi la sensibilità ai disturbi

3. Linee di segnale troppo “deboli” (capacità + riflessioni)

Un cavo lungo aggiunge capacità e a volte riflessioni/ringing (fronti ripidi su linee non terminate).
Se stai usando bus come I²C o SPI, 2 metri sono spesso già fuori specifica senza accorgimenti.

Sintomi tipici: sensori I²C che non vengono più visti, display che si bloccano, letture non valide, bus che va in errore.

Vediamo ora come risolvere

Continua a leggere

Dirimere i conflitti con il pensiero computazionale – educazione civica – sketch Arduino – lezione 03

Ora traduciamo lo pseudocodice in uno sketch Arduino. Usiamo input da Serial Monitor per simulare le scelte e il LED integrato (e un buzzer opzionale) per avere feedback fisico. L’obiettivo non è “automatizzare i conflitti”, ma allenare il pensiero procedurale e la gestione consapevole dei passi. Si faccia riferimento alla lezione precedente (seguire il link) in cui è stato mostrato il diagramma di flusso nella modalità Mermaid e classica.

Nella dimostrazione viene usato un Arduino UNO R4 WiFi.

Di seguito una possibile soluzione, il funzionamento lo trovate nei commenti.

/* Prof. Maffucci Michele
  data: 18.11.25
  Risoluzione di un conflitto
  Input da Serial Monitor

  - LED integrato (pin 13) usato come feedback visivo
  - Buzzer opzionale su pin 5 (beep brevi)
  Istruzioni:
  1) Aprire la Serial Monitor (115200 baud).
  2) Rispondere alle domande con i tasti indicati (y/n, a/f) o premi invio quando richiesto.
*/

const int pinLed = LED_BUILTIN;  // pin 13
const int pinBuzzer = 5;         // pin a cui è connesso il Buzzer
int numeroBeep = 0;

bool chiaveMsg = 0;  // per controllo stampa msg

// emissione della nota
void beep(int durataMs) {
  tone(pinBuzzer, 880);  // nota La4
  delay(durataMs);
  noTone(pinBuzzer);
}

// sequenza di beep ripetuta all'avvio del programma
void sequenzaAvvio() {
  for (int i = 0; i < 10; i++) {
    beep(100);
    delay(100);
  }
}

// Attende che ci sia almeno un carattere sulla seriale e lo legge (minuscolo)
char leggiChar() {
  while (!Serial.available()) {
    // lampeggio lento del LED per indicare "in attesa"
    digitalWrite(pinLed, HIGH);
    delay(200);
    digitalWrite(pinLed, LOW);
    delay(200);
  }

  // Legge un solo byte dalla seriale e lo mette in c (di tipo char).
  // Questo è il primo carattere che l’utente ha inviato.
  char c = Serial.read();

  // Svuota il buffer rimanente leggendo tutto quello che è ancora arrivato
  // (ad esempio il \n dell’invio, o più caratteri se l’utente ha incollato del testo).
  while (Serial.available())
    Serial.read();
  if (c >= 'A' && c <= 'Z')  // Conversione in minuscolo se il carattere è una lettera maiuscola.
    c = c - 'A' + 'a';
  return c;
}

// -- Utility: attende qualsiasi tasto (usata come "invio per continuare")
// “un puntatore a char costante”, cioè una stringa in stile C non modificabile
// (tipicamente una stringa letterale come "Ciao").

void attendiConferma() {
  const char* messaggio = "Premi invio per continuare";
  Serial.println(messaggio);
  while (!Serial.available()) {
    digitalWrite(pinLed, HIGH);
    delay(150);
    digitalWrite(pinLed, LOW);
    delay(150);
  }
  // svuota
  while (Serial.available())
    Serial.read();
  beep(100);
}

// -- Utility: domanda sì/no
bool domandaSiNo(const char* domanda) {
  Serial.println(domanda);
  Serial.println("Digita 'y' per SI, 'n' per NO");

  //ripetiamo finché l’utente non inserisce una risposta valida.
  // Il ciclo si interrompe con un return (es. quando l’utente digita ‘y’ o ‘n’).
  for (;;) {
    char c = leggiChar();
    if (c == 'y') {
      Serial.println("Hai risposto: SI");
      beep(100);
      return true;
    }
    if (c == 'n') {
      Serial.println("Hai risposto: NO");
      beep(100);
      return false;
    }
    Serial.println("Risposta non valida. Usa 'y' o 'n'.");
  }
}

// Pausa "simulata breve" al posto di 2 minuti reali
void pausaBreve(const char* motivo, int secondi = 5) {
  Serial.print("Pausa: ");
  Serial.print(motivo);
  Serial.print(" (");
  Serial.print(secondi);
  Serial.println("s)");
  for (int i = 0; i < secondi; i++) {
    digitalWrite(pinLed, HIGH);
    delay(300);
    digitalWrite(pinLed, LOW);
    delay(700);
    Serial.print(".");
  }
  Serial.println();
  beep(100);
}

void setup() {
  pinMode(pinLed, OUTPUT);
  Serial.begin(115200);
  delay(1000);
  Serial.println("=== Risoluzione Conflitto - VERSIONE BASE ===");
  Serial.println("Benvenuto! Segui le istruzioni sul Serial Monitor.");
  pinMode(pinBuzzer, OUTPUT);
  sequenzaAvvio();
}

void loop() {
  // 1) Sicurezza del confronto
  bool sicuro = false;
  do {
    sicuro = domandaSiNo("E' sicuro parlare adesso?");
    if (!sicuro) {
      Serial.println("OK, facciamo un time-out breve al posto di 2 minuti.");
      pausaBreve("time-out", 5);
    }
  } while (!sicuro);

  // 2) Definizione del problema
  Serial.println("Definisci il problema in UNA frase (in classe va bene scriverla su carta).");
  attendiConferma();

  // 3) Turni + Parafrasi
  bool parafrasiOk = false;
  do {
    Serial.println("Turno A (60s simulati).");
    attendiConferma();
    Serial.println("Turno B (60s simulati).");
    attendiConferma();
    parafrasiOk = domandaSiNo("Parafrasi reciproca corretta?");
  } while (!parafrasiOk);

  // 4) Opzioni di soluzione (almeno 2)
  int numeroOpzioni = 0;
  Serial.println("Genera almeno 2 opzioni di soluzione.");
  for (;;) {
    Serial.println("a = aggiungi opzione, f = fine (consentita solo se >= 2 opzioni)");
    char c = leggiChar();
    if (c == 'a') {
      numeroOpzioni++;
      Serial.print("Opzione aggiunta. Totale: ");
      Serial.println(numeroOpzioni);
      beep(100);
    } else if (c == 'f') {
      if (numeroOpzioni >= 2) {
        Serial.println("OK, passiamo alla decisione.");
        beep(100);
        break;
      } else {
        Serial.println("Servono almeno 2 opzioni prima di terminare.");
      }
    } else {
      Serial.println("Scelta non valida. Usa 'a' o 'f'.");
    }
  }

  // 5) Decisione finale
  bool accordo = domandaSiNo("C'e' accordo su una opzione?");
  if (accordo) {
    Serial.println("Piano d'azione: definire chi/fa/cosa/entro quando (scrivere su carta).");
    Serial.println("Promemoria: verifica dopo 24 ore.");
    Serial.println("FINE. Riavvio tra 5 secondi...");
    pausaBreve("chiusura", 5);
  } else {
    Serial.println("Coinvolgi un mediatore o rinvia il confronto.");
    Serial.println("Ritorno al controllo 'E' sicuro parlare?'.");
    pausaBreve("ritorno", 3);
  }
}

Arduino esercizi – Base marziana ELYSIUM – correzione fase 1 – solo pulsante

In riferimento alla lezione: Arduino esercizi – Base marziana ELYSIUM, riporto di seguito tre possibili soluzioni, nei commenti di ogni sketch la spiegazione sul funzionamento.

Fase 1 – solo pulsante

// Prof. Maffucci Michele
// data 12.11.25
// Base marziana ELYSIUM - fase 1 - solo pulsante

const int PIN_LED = 9;
const int PIN_PULSANTE = 2;  // pull-down esterno: HIGH quando premuto

void setup() {
  pinMode(PIN_LED, OUTPUT);
  pinMode(PIN_PULSANTE, INPUT);  // nessun pull-up interno
  digitalWrite(PIN_LED, LOW);
}

void loop() {
  int statoPulsante = digitalRead(PIN_PULSANTE);

  if (statoPulsante == HIGH) {    // pulsante premuto
    digitalWrite(PIN_LED, HIGH);  // accendo la luce di cortesia
    delay(1500);                  // 1,5 s
    digitalWrite(PIN_LED, LOW);  // spengo
    delay(50);                   // piccolo anti-rimbalzo
  }
}

Con questa soluzione alla pressione del pulsante il LED si accende e se rilasciate si spegne, però se mantenete premuto il pulsante notare un veloce spegnimento ed una riaccensione del LED ovvero ciò che stiamo facendo e riaccendere immediatamente il LED.

Per evitare ciò bisogna implementare la versione che evita il retrigger.

Evitare il retrigger significa impedire che, tenendo il pulsante premuto, il ciclo riparta subito dopo lo spegnimento del LED e lo riaccenda di nuovo. Per evitarlo, dopo la sequenza (LED acceso per 1,5 s > LED spento) si controlla se il pulsante è ancora premuto: finché lo è, si rimane dentro un ciclo while bloccante che attende il rilascio. Solo quando il pulsante torna allo stato di riposo si esce dal while, si applica un breve anti-rimbalzo (es. 50 ms) e il programma riprende il loop normale.

ATTENZIONE

il while è bloccante ciò vuol dire che blocca l’intera esecuzione del programma. Va benissimo per questo esercizio semplice; in progetti più complessi è preferibile preferisce rilevare il fronte di salita (variabile di stato) o un approccio non bloccante con millis() che ancora non conoscete (mi sto rivolgendo ai ragazzi di 3′) e che vedremo più avanti.

Fase 1 – solo pulsante – evita il retrigger con while bloccante

// Prof. Maffucci Michele
// data 12.11.25
// Base marziana ELYSIUM - fase 1B - solo pulsante
// evitare il retrigger

const int PIN_LED = 9;
const int PIN_PULSANTE = 2;  // pull-down esterno: HIGH quando premuto

void setup() {
  pinMode(PIN_LED, OUTPUT);
  pinMode(PIN_PULSANTE, INPUT);  // nessun pull-up interno
  digitalWrite(PIN_LED, LOW);
}

void loop() {
  int statoPulsante = digitalRead(PIN_PULSANTE);

  if (statoPulsante == HIGH) {    // pulsante premuto
    digitalWrite(PIN_LED, HIGH);  // accendo la luce di cortesia
    delay(1500);                  // 1,5 s
    digitalWrite(PIN_LED, LOW);   // spengo

    // attendo il rilascio per evitare retrigger continui
    while (digitalRead(PIN_PULSANTE) == HIGH) {
      delay(10);
    }
    delay(50);                    // piccolo anti-rimbalzo
  }
}

Attenzione alla parte di codice:

...
while (digitalRead(PIN_PULSANTE) == HIGH) {
      delay(10);
    }
...

potreste essere tentati di scrivere:

...
while (statoPulsante == HIGH) {
      delay(10);
    }
...

se agite in questo modo, dopo la prima accensione e il successivo spegnimento non riuscirete più ad accendere il LED con successive pressioni del pulsante.

Considerate statoPulsante come uno “scatto fotografico” fatto ad inizio loop(), pertanto se scrivete:

while (statoPulsante == HIGH) { ... }

la condizione resta sempre vera (perché non non viene mai aggiornata).
Risultato: si resta bloccati per sempre in quel while dopo la prima attivazione > il LED si accende una volta e poi il programma non torna più al loop().

Fase 1 – solo pulsante – evita il retrigger senza while bloccante

Fornisco un’altra soluzione in cui non si fa uso del while bloccante.

Invece di “restare fermi” dentro un while finché il pulsante non viene rilasciato, leggiamo il pulsante ad ogni giro del loop e facciamo scattare l’azione solo quando cambia da NON premuto a premuto. Questo momento si chiama fronte di salita.

// Prof. Maffucci Michele
// data 12.11.25
// Base marziana ELYSIUM - fase 1C - solo pulsante
// evitare il retrigger senza while bloccante
// con variabile di stato

const int PIN_LED      = 9;
const int PIN_PULSANTE = 2;   // pull-down esterno: HIGH = premuto

bool premutoPrima = false;

void setup() {
  pinMode(PIN_LED, OUTPUT);
  pinMode(PIN_PULSANTE, INPUT);   // nessun pull-up interno
}

void loop() {
  // Snapshot della lettura
  int statoPulsante = digitalRead(PIN_PULSANTE);

  // Converto HIGH/LOW in booleano
  bool premuto;
  if (statoPulsante == HIGH) {
    premuto = true;    // pulsante premuto
  } else {
    premuto = false;   // pulsante rilasciato
  }

  // Fronte di salita: ora premuto, prima no
  if (premuto && !premutoPrima) {
    digitalWrite(PIN_LED, HIGH);
    delay(1500);
    digitalWrite(PIN_LED, LOW);
    delay(50); // anti-rimbalzo semplice
  }

  // Aggiorna lo stato per il prossimo giro
  premutoPrima = premuto;
}

Come funziona il programma

  • premuto = stato attuale del pulsante (TRUE se è premuto ora, FALSE altrimenti).
  • premutoPrima = stato del pulsante al giro precedente del loop.
  • Condizione di innesco: premuto == true e premutoPrima == false > significa “hai appena iniziato a premere”.

Quando la condizione è vera:

  1. esegui l’azione (es. LED acceso 1,5 s, poi spento),
  2. non restate bloccato: il loop continua a girare,
  3. finché tenete premuto, la condizione non si ripete (perché ora premutoPrima è anch’esso TRUE),
  4. quando rilasciate, premuto torna FALSE; alla prossima pressione avrete di nuovo il fronte di salita.

Questa soluzione offre i seguenti vantaggi:

  • Niente blocchi: il programma continua a leggere ingressi/aggiornare uscite mentre il LED è stato gestito (utile in progetti più grandi).
  • No retrigger con pressione prolungata: scatta una sola volta all’inizio della pressione.
  • Struttura “a eventi”: reagisce ai cambiamenti, non al livello costante del pulsante.

Di seguito la tabella “fronte di salita” (versione con pull-down: HIGH = premuto)

Fase Descrizione Lettura pin premuto (ora) premutoPrima (prima) Condizione premuto && !premutoPrima Azione
T0 Riposo prima della pressione LOW FALSE FALSE FALSE Nessuna
T1 Inizio pressione (fronte salita) HIGH TRUE FALSE TRUE Esegui sequenza LED
T2 Tenuto premuto HIGH TRUE TRUE FALSE Nessuna
T3 Rilascio LOW FALSE TRUE FALSE Nessuna (solo aggiornamento stato)
T4 Nuova pressione (nuovo fronte) HIGH TRUE FALSE TRUE Esegui sequenza LED

Buon Coding a tutti 🙂