Dirimere i conflitti con il pensiero computazionale – educazione civica – presentazione

Esercitazione di Educazione Civica nelle ore di Laboratorio di Sistemi Elettronici

Desidero condividere la scheda di lavoro del percorso di educazione civica che avvierò oggi con i miei studenti. Come sapete, l’educazione civica è affidata a tutti i docenti del consiglio di classe e viene insegnata con un approccio trasversale e interdisciplinare. Per quanto mi riguarda, condurrò le prime tre ore di lezione a partire da oggi, integrandole con i contenuti della disciplina che insegno: Laboratorio di Sistemi Elettronici.

Condivido la scheda così come l’ho progettata nei giorni scorsi: modificatela e adattatela liberamente dove ritenete opportuno. Vi ringrazio fin d’ora se vorrete darmi un riscontro sia sulla validità della proposta sia sull’eventuale sperimentazione nelle vostre classi. La sto testando e con ogni probabilità apporterò modifiche in itinere.

Perché fare educazione civica in laboratorio di sistemi elettronici

Perché progettare un algoritmo è progettare una convivenza: si definiscono condizioni, stati, ingressi/uscite e verifiche di esito. Nel laboratorio trasformiamo i principi di costituzione, diritti e responsabilità in procedure operative che gli studenti possono vedere, toccare e migliorare.

In più, scrivere l’algoritmo e svilupparlo in gruppo porta inevitabilmente a riflettere su questi problemi, a cercare modi concreti per affrontarli e, soprattutto, a coltivare un senso di giustizia che nasce dal confronto civile. È nella pratica del “decidere insieme” e non nell’imposizione dall’alto tipica di leadership autocratiche che si progetta la pace: solo così, con regole condivise, possiamo contribuire a rendere migliore questo mondo.

Infine, in un contesto in cui il bombardamento continuo di notizie rischia di assuefarci a una falsa normalità della violenza e di farci sentire impotenti di fronte ai problemi globali, il laboratorio offre un antidoto: riflettere e progettare insieme percorsi di dialogo e cooperazione. Farlo non è solo un’opportunità didattica: è un dovere civico, un esercizio concreto di responsabilità verso il bene comune.

Ho previsto una versione base che, secondo la mia progettazione, richiede circa tre ore. Non so se durante le prossime lezioni o più avanti proporrò una versione avanzata, che integra criteri di valutazione, punteggi: questa seconda forse la farò sviluppare quando la classe avrà acquisito maggiore dimestichezza con la programmazione, ma osservo e nel caso troverete su questo sito la proposta avanzata integrata all’interno delle tre lezioni che vi condividerò settimanalmente (credo) con lo sviluppo di una proposta di soluzione del diagramma di flusso, pseudocodice e Sketch Arduino.

Scheda di lavoro

In questa attività uniamo educazione civica e competenze tecnico-scientifiche per riflettere su conflitti che toccano la nostra società: escalation di guerre, fenomeni di apartheid e discriminazione, crisi climatica, violenza verbale online e offline. Al centro c’è un’idea semplice e credo potente: molte forme di violenza nascono dal non-ascolto e dalla prevaricazione, dal non tenere conto del pensiero altrui e dei diritti delle minoranze.
Useremo il pensiero computazionale (diagrammi di flusso, pseudocodice, automazione con Arduino) per progettare procedure di dialogo e mediazione: la logica degli algoritmi diventa un modo per rendere trasparente, equo e verificabile il percorso verso una soluzione condivisa.

Obiettivi formativi

  • Civici: sviluppare ascolto attivo, rispetto reciproco, gestione non violenta dei conflitti, attenzione ai diritti e alle minoranze.
  • Tecnici: saper rappresentare un processo con diagramma di flusso e pseudocodice; tradurre la procedura in uno sketch Arduino semplice con input da seriale e feedback visivo/sonoro.
  • Metodologici: passare da opinioni generiche a passi operativi (regole, turni di parola, verifica di comprensione, decisione).

Struttura del percorso (3 lezioni)

Lezione 1 – Definizione del problema

  • Analisi di casi: conflitti quotidiani (classe, social, famiglia) e macro-temi (discriminazione, clima, linguaggi d’odio).
  • Riconoscere attori, interessi, regole e condizioni minime per un confronto sicuro.
  • Distinguere fatti da interpretazioni e formulare il problema in una frase chiara.

Lezione 2 – Diagramma di flusso e pseudocodice

  • Costruzione di una versione base dell’algoritmo di mediazione:
    controllo sicurezza del confronto > turni di parola > parafrasi reciproca > generazione di opzioni > decisione o richiesta di mediazione.
  • Stesura del pseudocodice con variabili in italiano e commenti esplicativi.

Lezione 3 – Sketch Arduino

  • Implementazione su Arduino con input via Serial Monitor e feedback con LED integrato (e buzzer opzionale).
  • Test guidato: simulare conversazioni e verificare come l’algoritmo aiuta a ridurre ambiguità, toni aggressivi e fraintendimenti.

Competenze attese

  • Competenze civiche e sociali: ascolto, empatia, negoziazione, responsabilità.
  • STEM: modellazione di processi, astrazione, controllo di flusso (condizioni e cicli), debugging di procedure.
  • Comunicazione: parafrasi, sintesi in una frase problema, linguaggio tecnico chiaro.

Materiali essenziali

  • PC con Arduino IDE, scheda Arduino UNO (o equivalente), cavo USB.
  • Serial Monitor per l’interazione, LED integrato (pin 13) e buzzer opzionale su pin 5.
  • Fogli per diagrammi/pseudocodice; regole di dialogo condivise.

Valutazione (formativa)

  • Qualità del diagramma di flusso (chiarezza, completezza, uso corretto di bivi e cicli).
  • Aderenza del pseudocodice al diagramma.
  • Funzionamento dello sketch e qualità dei commenti.
  • Comportamenti osservabili di ascolto e rispetto durante le simulazioni.

Inclusione e clima di classe

  • Ruoli rotanti (moderatore, portavoce, time-keeper, osservatore del linguaggio).
  • Consegnare una griglia di frasi utili per “io-messaggi” e parafrasi.
  • Tempi scanditi e check-point per favorire la partecipazione di tutti.

Progettiamo la pace 🙂

Quick References per lo studio – Nomi file & versioni

Dare un nome chiaro ai file e gestire le versioni non è pignoleria: è ciò che ti fa trovare subito ciò che cercate, capire al volo quale documento è l’ultimo e collaborare senza caos. In classe e nei progetti di gruppo capita spesso di avere decine di file chiamati “Relazione definitiva (nuova)”, “Relazione_ultimissima (1)”, “prova2_bis.pdf”. Risultato: si perde tempo, si consegna il file sbagliato, si confondono revisioni e correzioni del docente.

Un buon naming (come chiami il file) e un semplice versioning (come tenete traccia delle versioni) risolvono questi problemi perché:

  • i file sono ordinabili in modo naturale (per data, per progetto, per autore);
  • il nome racconta cosa contiene e a che punto è (v1.0, v1.1, v2.0…);
  • lavorare in gruppo diventa più semplice (ognuno segue la stessa convenzione);
  • la consegna è pulita: il docente vede subito cosa aprire, senza dubbi.

Non serve un software complicato: basta una regola condivisa e costante. Con una convenzione semplice, in 1 secondo capisci versione, tema e autore; in 2 clic trovi tutto ciò che ti serve.

Esempio sintetico:

  • Nomi coerenti = cercare e condividere senza perdersi.
  • Regola: AAAA-MM-GG_progetto-parole-chiave_vX.Y_autore.ext.
    Ordinabile per data, leggibile da tutti, facile da versionare. Evita spazi e caratteri strani; usa trattini.
  • Cartelle consigliate: /classe/materia/progetto/gruppo/.

Scarica PDF A4 della guida operativaApri il sorgente Markdown su GitHub

Se non sai cos’è il Markdown segui il link

---
title: "QR – Nomi file & versioni come i pro"
version: "1.1"
autore: "<Classe/Studente>"
licenza: "CC BY 4.0"
ultimo_aggiornamento: "2025-10-05"
---

# Perché una convenzione aiuta
- Trovi i file subito (ordinamento per data e nome).
- Capisci a colpo d’occhio contenuto e versione.
- Meno conflitti/doppioni nei lavori di gruppo.
- Consegne pulite e professionali.

## Convenzione base (da usare)
`AAAA-MM-GG_progetto-parole-chiave_vX.Y_autore.ext`

**Spiegazione**
- `AAAA-MM-GG` = data (es. 2025-10-05)
- `progetto-parole-chiave` = tema + 1–3 parole utili (senza spazi; usa trattini)
- `vX.Y` = versione (X=major, Y=minor: v1.0, v1.1, v2.0…)
- `autore` = cognome o nome-cognome / nome del team
- `ext` = estensione (.pdf, .docx, .ino, .csv, .pptx…)

## Struttura cartelle consigliata
/classe/materia/progetto/gruppo/{dati,codice,relazione,media}

## Regole d’oro
- Usa trattini `-` o underscore `_` (no spazi, accenti, emoji).
- Minuscole coerenti; nomi descrittivi.
- Incrementa solo la parte necessaria della versione.
- Esporta un PDF finale per le consegne.

## Versioning semplice
- Inizio: v1.0 (prima consegna “completa”)
- Piccole correzioni: v1.1, v1.2 …
- Cambio sostanziale: v2.0
- Se arrivano commenti del docente: crea una nuova versione (non sovrascrivere)

## Modelli pronti (copia e incolla)
- Relazione (PDF): `AAAA-MM-GG_relazione-_vX.Y_.pdf`
- Codice Arduino: `AAAA-MM-GG__vX.Y_.ino`
- Dataset CSV: `AAAA-MM-GG_dati--_vX.Y_.csv`
- Presentazione: `AAAA-MM-GG_presentazione-_vX.Y_.pptx`
- Immagine/Figura: `AAAA-MM-GG_fig--_vX.Y_.png`

## Esempi rapidi (solo nomi, da imitare)
- 2025-10-05_relazione-arduino_stazione-ambientale_v1.0_rossi.pdf
- 2025-10-05_codice-sensore-luce_v1.3_rossi.ino
- 2025-10-05_dati-luce-umidita-aula3_v0.3_teamB.csv

## Checklist finale
- [ ] Stesso formato per tutti i file del progetto
- [ ] Versione aggiornata (vX.Y) coerente
- [ ] Niente duplicati “finale_definitivo(3).docx”
- [ ] PDF esportato per la consegna

Esempio 01 – Consegna di gruppo (Arduino)

  • Cartella: /3B/info/stazione-ambientale/teamB/
  • File:
    2025-11-12_relazione-stazione-ambientale_v1.2_teamB.pdf
    2025-11-12_dati-luce-umidita-aula3_v1.0_teamB.csv
    2025-11-12_codice-lettura-sensori_v1.3_teamB.ino
    2025-11-12_fig-01-schema-cablaggio_v1.0_teamB.png

Esempio 02 – Correzioni del docente > nuova versione

  • Prima: 2025-11-12_relazione-stazione-ambientale_v1.2_teamB.pdf
  • Dopo correzioni: 2025-11-15_relazione-stazione-ambientale_v1.3_teamB.pdf
  • Changelog (facoltativo): “2025-11-15 v1.3: aggiunte unità SI; rigenerato grafico con etichette leggibili.”

Home Assistant a scuola: la guida “a puntate” per elettronica & automazione – 02


Prima di iniziare con l’installazione del software procediamo con la configurazione base dell’hardware, nel mio caso dispongo a scuola di un Raspberry Pi 4 Model B – 4 GB RAM e su questa versione opereranno gli studenti, ovviamente la scelta di un modello superiore con maggior memoria è consigliabile, ciò che ho fatto per la mia versione casalinga con un un Raspberry Pi 5 – 8 GB RAM.

Questa prima parte è estremamente semplice e richiede pochissime competenze tecniche, installeremo le alette di raffreddamento e la ventola di raffreddamento collegandola ai pin di alimentazione che troviamo sulla GPIO.

Note per chi inizia: Cos’è la GPIO del Raspberry Pi

GPIO = General Purpose Input/Output: è il pettine a 40 pin sulla scheda che vi permette di leggere/scrivere segnali digitali e, quando necessario, usare funzioni: come I²C, SPI, UART, PWM ecc. Sulla Pi 4 solo 28 sono utilizzabili per la programmazione. La GPIO del Pi 4 è identica, per posizione e funzioni base, a quello dei modelli precedenti con header a 40 vie: quindi HAT e cablaggi restano compatibili. Al termine della guida è indicato la piedinatura della GPIO ed i pin a cui connettere la ventola di raffreddamento.

Raspberry Pi 4 offre molta più potenza dei modelli precedenti e, sotto carico sintetico (cioè durante test artificiali che stressano intenzionalmente CPU/GPU per misurare il “la situazione peggiore di utilizzo”), può scaldare rapidamente fino a innescare il throttling (taglio automatico della frequenza per protezione termica). Le misure ufficiali con il firmware iniziale mostrano picchi fino a 72,1 °C in 60 s e l’avvio del throttling dopo circa 65 s; gli aggiornamenti firmware successivi hanno ridotto consumi/temperature e posticipato il momento in cui il taglio di frequenza interviene, ma in carichi intensi il rischio resta. Per chi usa il Pi 4 in modo continuativo (es. Home Assistant), aggiungere alette di raffreddamento + ventola aiuta a mantenere la CPU sotto soglia, evitando cali di prestazioni e migliorando stabilità e longevità del sistema.

Di seguito due immagini della scheda realizzate con la termocamera in fase di test.

Per maggiori informazioni vi rimando all’articolo tecnico che trovate sul sito Rapberrypi.org

Situazione in fase di riposo

Raspberry Pi 4 VLI, SDRAM (idle)

Situazione in fase di load

Raspberry Pi 4 VLI, SDRAM (load)

Di cosa abbiamo bisogno

  • Kit dissipatore in alluminio per Raspberry Pi 4 (molti includono doppia ventola + thermal pad + viteria).
  • Cacciavite a croce di piccole dimensioni.
  • Alcol isopropilico + panno morbido (per pulire i chip prima del fissaggio delle alette).
  • Facoltativo: fascette/clip per gestire i cavi.

Sicurezza e prevenzione

Sembra banale, ma meglio specificarlo, soprattutto per i giovani studenti che iniziano attività laboratoriali:

  1. Scollegare l’alimentazione del Raspberry Pi.
  2. Lavorare su superficie pulita; toccate una parte metallica messa a terra per scaricare l’elettricità statica (se disponete di un braccialetto antistatico meglio).
  3. Pulire delicatamente CPU/RAM/controller USB con un panno leggermente inumidito di alcol isopropilico e lascia asciugare.

Applicare le alette di raffreddamento

Sono acquistabili su qualsiasi store online, andranno montate sulla CPU, sulla RAM e sul Bridge PCI e USB 3.0. Incollate, come indicato nelle foto che seguono, le alette di raffreddamento, ogni aletta è dotata di nastro biadesivo.

Serraggio e alimentazione della ventola

In funzione del kit che avete acquistato o stampato in 3D la ventola di raffreddamento, alimentata a 5V è da fissare sulla struttura mediante 4 viti autofilettanti.

L’alimentazione della ventola avviene direttamente connettendo direttamente i pin di alimentazione della GPIO secondo quanto indicato dall’immagine che segue.

Poiché potrebbe servire in altre applicazioni condivido la mappa della GPIO del Raspberry Pi 4.

Per alimentare la ventola utilizzerò il +5V, preso sul pin 2 ed il pin 6 per il GND, come indicato nell’immagine che segue (datasheet Raspberry Pi 4)

Nell’immagine che segue è ben evidente il collegamento:

Procedere al servaggio della ventola al vetro supporto.

Buon Making a tutti 🙂

Quick References per lo studio – Prototipi hardware: sicurezza & ordine

 

In laboratorio sicurezza = metodo + ordine. Un prototipo ben organizzato non è solo più “bello”: è più sicuro, più facile da testare e più veloce da riparare. Lavoriamo con alimentazioni, correnti, componenti sensibili: le buone abitudini proteggono persone, strumenti e risultati.

  1. Preparazione dell’area
  • Banco pulito: via oggetti non necessari, liquidi lontani, cavi non incrociati.
  • Illuminazione adeguata, seduta stabile, spazio per notebook/strumenti.
  • Documenti a portata: schema, pinout, datasheet; cartellina con buste (evita “pezzi sparsi”).
  1. Alimentazione: scelte e verifiche
  • Parti sempre disalimentato: cabla a cavo staccato.
  • Tensione e corrente: verifica che la sorgente regga (es. 5 V/2 A per moduli + motori).
  • Polaritá corretta: segna rosso = +, nero = GND; no fili volanti senza colore.
  • Protezione: preferisci alimentatori con limite di corrente o fusibili rapidi; imposta limiti sul banco di alimentazione.
  • GND comune: con più sorgenti, i riferimenti di massa vanno uniti (salvo isolamenti voluti).
  1. Cablaggio e componenti
  • Cavi corti e fissati (fascette/nastro): riduce falsi contatti.
  • Breadboard: limiti (resistenza di contatto, cadute, correnti basse). Per correnti > 200–300 mA, evita breadboard → morsetti/stripboard.
  • Sezione dei fili adeguata (motori ≠ jumper sottili).
  • Polarità di LED, elettrolitici, moduli. Diodo di ricircolo con carichi induttivi (relè/motori).
  • ESD (sensori e IC): tocca massa prima di maneggiare, se possibile usa bracciale ESD.
  1. Strumentazione e misure
  • Multimetro: inizia sul fondo scala più alto; controlla sonde e modalità (V, A, Ω).
  • Misure “prima di accendere”: continuità su alimentazione (niente corto), verifica resistenze sospette.
  • Misure “dopo”: V su pin chiave, I assorbita dal sistema, calore (dito/misuratore IR).
  • Log: annota valori e condizioni (tensione di alimentazione, carico, ambiente).
  1. Procedura di test (incrementale)
  • Un passo alla volta: prima l’alimentazione, poi un sensore, poi un attuatore…
  • Stato noto ad ogni passaggio: se qualcosa “salta”, sai dove guardare.
  • Rollback: se peggiori, torna alla versione stabile precedente.
  1. Chiusura lavori (safety & ordine)
  • Spegni/disalimenta, scollega, lascia un post-it con lo stato del prototipo (“sensore X instabile; rifare cablaggio domani”).
  • Rimetti a posto componenti (sacchetti etichettati), attrezzi, cavi avvolti.
  • Backup: foto cablaggi, schema aggiornato, commit del codice con messaggio chiaro.
  1. Rischi tipici & prevenzione
  • Surriscaldamento: dissipatori/pad termici, correnti entro specifiche.
  • Corto accidentale: fili spelati, breadboard usurate, stagnature “a goccia” → isola e rifinisci.
  • Rumore elettrico: twist dei cavi segnale, condensatori di bypass (0.1 µF vicino ai Vcc), massa stellare.
  • Batterie Li-ion/LiPo: carica solo con circuiti dedicati, non perforare o piegare, mai cortocircuitare, storage a ~3.8 V.
  • Meccanica: bordi vivi, parti in movimento: occhiali protettivi se c’è rischio.

Scarica PDF A4 della guida operativaApri il sorgente Markdown su GitHub

Se non sai cos’è il Markdown segui il link

---
title: "QR – Prototipi hardware: sicurezza & ordine"
version: "1.2"
autore: "<Classe/Studente>"
licenza: "CC BY 4.0"
ultimo_aggiornamento: "2025-10-05"
---

## 1) Preparazione dell’area
- [ ] **Banco pulito** (via liquidi/oggetti inutili), **luce buona**, sedia stabile.
- [ ] **Documenti a vista**: schema, pinout, datasheet (cartella o busta trasparente).
- [ ] PC/Notebook con IDE aperto e cavo **funzionante**.
- [ ] Foto “prima” del banco (torna utile per confronto e relazione).

## 2) Alimentazione (scelte & verifiche)
- [ ] Cabla **a cavo staccato**; alimenta **solo a fine controllo**.
- [ ] Tensione/ corrente **coerenti** con il carico (es. 5 V/2 A).
- [ ] **Polaritá marcata**: rosso = +V, nero = GND; niente fili volanti non isolati.
- [ ] Se possibile, **limite di corrente** sull’alimentatore o fusibile rapido.
- [ ] Con più sorgenti, **GND comune** (salvo isolamenti voluti).

## 3) Cablaggio e componenti
- [ ] **Cavi corti e fissati** (fascette/nastro); evitare anelli e incroci inutili.
- [ ] Breadboard ok per segnali/ piccole correnti; per >300 mA usa morsetti/stripboard.
- [ ] Sezione fili adeguata (motori ≠ jumper sottili).
- [ ] **Polarità**: LED/elettr. corretta; **diodo di ricircolo** con relè/motori.
- [ ] **ESD**: tocca GND prima di maneggiare IC/sensori; se possibile usa bracciale.

## 4) Strumentazione & misure
- [ ] Multimetro: scala corretta (V, A, Ω) e **sonde ben inserite**.
- [ ] **Prima di accendere**: continuità tra +V e GND (no corto).
- [ ] **Dopo**: misura V su pin chiave, **corrente assorbita**, temperatura (dito/IR).
- [ ] Logga dati e condizioni (V aliment., carico, ambiente).

## 5) Procedura di test (incrementale)
1. **Alimenta** → verifica solo la parte di potenza.
2. **Aggiungi** un modulo alla volta (sensore → attuatore).
3. **Stato noto** a ogni passo; se peggiori, **rollback** alla versione stabile.
4. Una modifica per volta (HW *o* SW), poi test.

## 6) Chiusura lavori
- [ ] **Spegni e scollega**.
- [ ] **Post-it** di stato: “sensore X instabile; rifare cablaggio domani”.
- [ ] Riponi componenti/attrezzi; avvolgi cavi.
- [ ] **Backup**: foto cablaggio, schema aggiornato, commit codice con messaggio chiaro.

## 7) Rischi tipici & prevenzione
- **Surriscaldamento** → dissipatori/pad; rispetta correnti massime; ventilazione.
- **Corto** → rifinisci stagnature; isola punti nudi; sostituisci breadboard usurate.
- **Rumore elettrico** → twist cavi segnale, **bypass 0.1 µF** vicino a Vcc, massa a stella.
- **Batterie Li-ion/LiPo** → carica **solo** con circuiti dedicati; non perforare/piegare; mai in corto; storage ~3.8 V.

Esempio – “Il motore non parte e il driver scotta”

Setup

  • Alimentazione 12 V (banco da laboratorio, limite corrente 1.5 A).
  • Driver ponte H (es. L298N o similare), motore DC 6–12 V, Arduino UNO.
  • Cavi: alimentazione 0.5–0.75 mm², segnale jumper corti.

Sintomi

  • A “start”, motore fermo o vibra; driver caldo dopo pochi secondi; LED di alimentazione ok.

Procedura di diagnosi

01. Isola blocchi

    • Scollega Arduino → alimenta solo il driver e il motore in manuale: ponticella IN1=HIGH, IN2=LOW (o usa enable).
    • Se ancora fermo, il problema è driver/motore (non il codice).

02. Verifica alimentazione

    • Misura V_motore a vuoto: ~12 V?
    • Cala a 5–6 V quando provi a muoverlo? → alimentatore in current limit (motore richiede più spunto).
    • Soluzione: alimentatore con corrente di picco più alta o soft-start (PWM graduale).

03. Controlla cablaggio e polarità

    • GND comune tra Arduino e driver.
    • Sezione fili verso motore sufficiente (evita jumper sottili).
    • Diodi di ricircolo: presenti/integrati? Se driver ne è privo, aggiungili.

04. Assorbimento & termica

    • Misura corrente di spunto (metti multimetro in serie): >1.5–2 A? Il L298N satura e scalda.
    • Opzioni: driver più efficiente (MOSFET, es. BTS7960 o ponte H moderno), abbassa tensione o usa PWM limitato all’avvio.

05. Test incrementale

    • Motore scollegato > misura V ai morsetti del driver con PWM 30/60/100%.
    • Se V è stabile e driver non scalda → il problema è carico (motore duro/ingranaggi).
    • Lubrifica/controlla meccanica; prova con un motore “buono”.

Checklist “fatto”

  • Motore avvia fluido a PWM 30→60→100%.
  • Driver < 70 °C dopo 2′ di lavoro (dito o termometro IR).
  • Alimentatore non entra in limit; cavi non scaldano.
  • GND comune, fili fissati, schema aggiornato con modello driver.

Note didattiche

Mostrare agli studenti foto prima/dopo del cablaggio, la tabella di misure (V/I a step di PWM) e un grafico corrente-tempo allo spunto: è evidente perché alcuni driver scaldano.

Progettare bene, programmare meglio: pseudocodice e diagrammi per sistemi elettronici – lezione 5/5


Ripasso di inizio anno – appunti per la classe.

Di seguito un mini vocabolario, come sempre stampatelo e mettetelo nel tuo quadernone (alcune cose le abbiamo viste anche nella lezione precedente):

Useremo un dialetto semplice.

  • Una istruzione per riga.
  • Parole chiave in MAIUSCOLO e con i due punti : quando aprono un blocco:
    • SE … ALLORA: … ALTRIMENTI:
    • MENTRE (condizione):
    • PER i da A a B:
    • FUNZIONE nome(parametri): RITORNA valore
  • Indentazione (rientro) di 2–4 spazi per il contenuto dei blocchi.
  • Commenti: usa // all’inizio della riga.
  • Nomi chiari per variabili e costanti: sogliaLuce, tempoGiallo, pinLed.

Mini-vocabolario

  • IMPOSTA x a 10: assegna un valore
  • LEGGI x: prendi un input (da Serial o da sensore)
  • SCRIVI …: stampa (su Serial o su un display)
  • ATTENDI 500 ms: pausa
  • ESCI DAL CICLO: interrompi MENTRE o PER
  • OperatorI: ==, !=, <, >, >=, <=, AND, OR, NOT

Mappa mentale

Pseudocodice Arduino (C/C++)
IMPOSTA x a 10 int x = 10; oppure x = 10;
LEGGI da Serial parseInt()/readStringUntil('\n')
LEGGI digitale pin digitalRead(pin)
LEGGI analogico pin analogRead(pin)
SCRIVI su Serial Serial.print()/println()
ACCENDI LED digitalWrite(pin, HIGH)
SPEGNI LED digitalWrite(pin, LOW)
ATTENDI t ms delay(t)
PER i da 1 a N: for (int i=1; i<=N; i++) { ... }
MENTRE (condizione): while (condizione) { ... }
SE / ALTRIMENTI if (...) { ... } else { ... }
FUNZIONE tipo nome(params){...}
RITORNA return

Funzioni di aiuto per leggere dal Monitor Seriale

Blocchi riutilizzabili

// ---------------------------
// Aiuti per I/O seriale
// ---------------------------

// Legge un intero dalla Serial (es.: 42, -17).
// Attende che ci siano dati disponibili, usa parseInt()
// e poi "pulisce" il buffer fino al newline '\n' per preparare
// la prossima lettura.
int leggiInt() {
  // Attende finché il buffer seriale è vuoto.
  // Serial.available() restituisce quanti byte sono pronti da leggere.
  while (!Serial.available()) {
    // ciclo di attesa attivo: resta qui finché non arriva almeno 1 byte
  }

  // parseInt():
  //  - salta automaticamente spazi e caratteri non numerici iniziali;
  //  - legge opzionalmente il segno (-);
  //  - si ferma quando incontra un separatore (es. spazio, '\n', ecc.)
  //  - rispetta Serial.setTimeout(): se i numeri arrivano "a pezzi", attende fino al timeout.
  int v = Serial.parseInt();

  // Dopo parseInt possono essere rimasti caratteri nel buffer
  // (ad es. l'utente ha premuto Invio, quindi c'è '\n' o anche "\r\n").
  // Questo while consuma tutto ciò che c'è fino a trovare '\n' e poi esce,
  // in modo da "allineare" la prossima lettura all'inizio della riga seguente.
  while (Serial.available()) {
    // Legge un carattere dal buffer
    if (Serial.read() == '\n') break; // esce quando trova il newline
    // Nota: se volessi trattare anche '\r' come fine riga su sistemi Windows,
    // potresti controllare anche '\r' (carriage return).
  }

  // Restituisce il valore intero letto.
  return v;
}

// Legge una riga di testo fino al newline '\n' e la restituisce come String.
// Esempio di input: "ciao mondo\n" -> "ciao mondo" (senza newline né spazi finali).
String leggiLinea() {
  // Attende che arrivi almeno un byte.
  while (!Serial.available()) {
    // attesa attiva
  }

  // Legge i caratteri fino al delimitatore '\n' (newline).
  // Il newline non viene incluso nella String risultante.
  String s = Serial.readStringUntil('\n');

  // trim():
  //  - rimuove spazi iniziali/finali, tab e ritorni a capo residui.
  //  - Utile se su alcune piattaforme l'invio produce "\r\n" (Windows):
  //    readStringUntil('\n') rimuove '\n', ma può restare '\r' in coda; trim() lo elimina.
  s.trim();

  // Restituisce la riga "pulita".
  return s;
}

Codice senza commenti da copiare ed incollare:

// ——— Aiuti per I/O seriale ———
int leggiInt() {
  while (!Serial.available()) {}
  int v = Serial.parseInt();
  while (Serial.available()) {
    if (Serial.read() == '\n') break;
  }
  return v;
}

String leggiLinea() {
  while (!Serial.available()) {}
  String s = Serial.readStringUntil('\n');
  s.trim();
  return s;
}

Esempi guidati pseudocodice > sketch Arduino

Esempio 01 – Saluto con nome (solo Serial)

Scopo: input/output base, variabili stringa.

Pseudocodice – esempio 01

SCRIVI "Come ti chiami?"
LEGGI nome
SCRIVI "Ciao, " + nome + "!"

Arduino – esempio 01 – con commenti

void setup() {
  Serial.begin(9600);          // Inizializza la seriale a 9600 baud (Monitor Seriale deve avere lo stesso valore).

  while (!Serial) { ; }        // Attende che la porta seriale sia pronta (utile su schede con USB "native", es. UNO R4).
                               // Su UNO R3 spesso non serve, ma non fa danni.

  Serial.println("Come ti chiami?"); // Messaggio iniziale: l’utente vede la richiesta nel Monitor Seriale.

  Serial.setTimeout(60000);    // Imposta il "tempo massimo di attesa" a 60 s per funzioni come readStringUntil/parseInt.
                               // Se l’utente impiega tempo a digitare, la lettura aspetta fino a 60 s prima di rinunciare.
}

void loop() {
  String nome = leggiLinea();  // Legge una riga di testo inserita dall’utente fino al tasto Invio (newline '\n').
                               // Esempio: se scrivo "Michele" e premo Invio, nome = "Michele".

  Serial.print("Ciao, ");      // Stampa senza andare a capo...
  Serial.print(nome);          // ...stampa il nome letto...
  Serial.println("!");         // ...e chiude la riga con il punto esclamativo + newline.

  while (true) {}              // Ferma il programma qui (loop infinito).
                               // Serve per NON chiedere nuovamente il nome in un ciclo senza fine.
                               // Se vuoi che ripeta la domanda, rimuovi questa riga.
}

Arduino – esempio 01 – senza commenti

void setup() {
  Serial.begin(9600);
  while (!Serial) {;}
  Serial.println("Come ti chiami?");
  Serial.setTimeout(60000);
}

void loop() {
  String nome = leggiLinea();
  Serial.print("Ciao, ");
  Serial.print(nome);
  Serial.println("!");
  while (true) {}  // fine
}

Esercizio aggiuntivo: chiedi anche l’età e rispondi “Sei maggiorenne/minorenne”.

Esempio 02 – Blink (LED lampeggiante)

Collegamenti: LED con resistenza su pin 13 (o usa quello onboard).

Pseudocodice – esempio 02

IMPOSTA pinLed a 13
IMPOSTA periodo a 500 ms
MENTRE (vero):
    ACCENDI LED
    ATTENDI periodo
    SPEGNI LED
    ATTENDI periodo

Arduino – esempio 02

const int pinLed = 13;
const int periodo = 500;

void setup() {
  pinMode(pinLed, OUTPUT);
}

void loop() {
  digitalWrite(pinLed, HIGH);
  delay(periodo);
  digitalWrite(pinLed, LOW);
  delay(periodo);
}

Esercizio aggiuntivo: leggi periodo da Serial.

Esempio 03 – Pulsante accende/spegne LED

Collegamenti: pulsante su pin 2, modalità INPUT_PULLUP; LED su pin 8.
Nota: il pulsante chiude a GND (premuto = LOW).

Pseudocodice – esempio 03

IMPOSTA statoLed a SPENTO
MENTRE (vero):
    LEGGI pulsante
    SE (pulsante premuto) ALLORA:
        ATTENDI 20 ms  // anti-rimbalzo semplice
        SE (ancora premuto) ALLORA:
            inverti statoLed
            applica stato al LED
            ATTENDI rilascio

Arduino – esempio 03

const int pinBtn = 2;
const int pinLed = 8;
bool statoLed = false;

void setup() {
  Serial.begin(9600);
  pinMode(pinBtn, INPUT_PULLUP);
  pinMode(pinLed, OUTPUT);
}

void loop() {
  if (digitalRead(pinBtn) == LOW) {  // premuto
    delay(20);                       // debounce base
    if (digitalRead(pinBtn) == LOW) {
      statoLed = !statoLed;  // toggle
      digitalWrite(pinLed, statoLed ? HIGH : LOW);
      // Attendi rilascio
      while (digitalRead(pinBtn) == LOW) {}
      delay(20);
    }
  }
}

Esercizio aggiuntivo: Estensione: stampa su Serial “ON/OFF” ad ogni pressione.

Esercizi

Esercizio 01 – Potenziometro > luminosità (PWM)

Obiettivo: Regolare mediante potenziometro l’intensità luminosa del LED.
Collegamenti: potenziometro su A0; LED su pin PWM 9.

Esercizio 02 – LED ON per 3 secondi quando premo il pulsante

Obiettivo: premo il pulsante > il LED rimane acceso per 3 secondi > poi si spegne.
Evitare ripetizioni mentre si tiene premuto (debounce base).

Componenti & Collegamenti

  • 1 × LED + 1 × resistenza (220–330 Ω) su pin 8 → GND
  • 1 × pulsante su pin 2 con INPUT_PULLUP (l’altro capo del pulsante a GND)

Esercizio 03 — LDR: accendi il LED quando è buio

Obiettivo: leggo la luce con una LDR. Se il valore è sotto una soglia (buio), accendo il LED; altrimenti lo spengo. Stampo i valori su Serial.

Componenti & Collegamenti

  • LDR in partitore su A0 (esempio: 5V — LDR — A0 — resistenza 10 kΩ — GND)
  • LED + resistenza su pin 9 → GND

Esercizio 04 – Potenziometro > luminosità LED (PWM)

Obiettivo: con il potenziometro regolo la luminosità del LED usando analogWrite (PWM).

Componenti & Collegamenti

  • Potenziometro 10 kΩ su A0 (estremi a 5V e GND, cursore ad A0)
  • LED + resistenza su pin ~9 (pin PWM) > GND

Buon Coding a tutti 🙂