Archivi tag: elettronica

Domande dagli utenti: perché micro:bit non pilota i motori direttamente?

Nella giornata di ieri mi è arrivata una domanda molto sensata, una di quelle che prima o poi ci si pone tutti quando si prova a far muovere un robot con micro:bit o con Arduino.

“Se micro:bit riuscisse a passare da 3V a 5V si risparmierebbero i costi della scheda di espansione, nonché l’ottimizzazione degli spazi. Lei è d’accordo? Chissà perché non lo fanno: ormai tutti abbiamo bisogno di motorini.”

La risposta breve è questa:

Capisco il ragionamento, ma il vero ostacolo non è 3 V vs 5 V. Il punto è che un pin di micro:bit non è uno stadio di potenza.
Anche se la scheda fosse “a 5 V”, non potresti comunque collegare un motore direttamente ai pin in modo sicuro e affidabile.

Vediamo perché, con esempi concreti e riferimenti ai due kit che uso spesso nei corsi: Ring:bit V2 board e Kitronik :MOVE mini.

La spiegazione che segue è volutamente semplificata in quanto non necessariamente i colleghi che seguono i miei corsi sono docenti di materie di indirizzo tecnico.

Perché “alzare la tensione” non risolve il problema

Corrente: il motore chiede molta più energia di quella che un pin può dare

Un motore (anche piccolo) non “vuole solo tensione”: vuole soprattutto corrente, e ne vuole parecchia quando parte (corrente di spunto) e quando è sotto sforzo (ruote che spingono, attrito, urti).

Un pin GPIO di una scheda a microcontrollore è progettato per segnali e piccoli carichi, non per alimentare carichi elettromeccanici. Se provate a farlo, i sintomi tipici sono:

reset improvvisi della scheda,
comportamenti instabili,
surriscaldamento,
nel peggiore dei casi danni ai pin o al microcontrollore.

Disturbi e picchi: il motore “sporca” l’alimentazione e genera back-EMF

Il motore è un carico induttivo: quando viene acceso/spento o se ne cambia la velocità, può generare picchi di tensione (back-EMF) e disturbi elettrici che:

mandano in crisi la logica,
creano interferenze (anche sulla radio/BT),
degradano l’affidabilità nel tempo.

Serve un driver: lo “stadio di potenza” che separa logica e motore.

Per pilotare un motore DC, ad esempio quelli gialli che tipicamente vengono usati nei progetti didattici di robotica, serve uno stadio di potenza, cioè un driver motore, per esempio:

ponte H (per andare avanti/indietro e fare PWM in modo robusto),
oppure MOSFET + protezioni (se serve solo on/off o un verso).

Il driver fa tre cose fondamentali:

regge la corrente (anche i picchi),
gestisce la direzione e la velocità (PWM),
protegge micro:bit dai disturbi e dai picchi del motore.

Citando la richiesta dell’utente: “Ma allora perché micro:bit non è a 5V?”

In realtà molte schede “vivono” già in ambienti dove esistono 5 V (ad esempio USB), ma l’elettronica interna e i pin di I/O lavorano a bassa tensione (tipicamente 3,3 V) perché:

si riducono consumi e riscaldamento,
si protegge meglio la scheda,
si mantiene compatibilità con sensori moderni a bassa tensione,
e soprattutto (punto chiave): anche a 5 V i pin non diventerebbero “pilotamotori”.

Quindi: passare a 5 V non eliminerebbe la necessità di un driver. Cambierebbe solo alcuni dettagli di alimentazione/compatibilità, ma non la sostanza.

Il caso reale nei kit: Ring:bit V2 board e Kitronik :MOVE mini

Ring:bit V2 board: non è “la scheda che pilota motori”

La Ring:bit V2 board è principalmente una scheda di espansione/breakout:

rende più comodi alcuni collegamenti (ad esempio porte tipo GVS su P0/P1/P2),
integra un portabatterie (3×AAA) per alimentare il sistema/il robot,
fornisce un’interfaccia pratica per prototipare.

Va interpretata come interfaccia e distribuzione di alimentazione/connessioni, non come “micro:bit che pilota motori direttamente”.

Ring:bit V2

Kitronik :MOVE mini: usa servomotori, non motori DC senza elettronica di controllo integrata

La scheda Kitronik :MOVE mini può controllare due servomotori a rotazione continua. Questa scelta è utile per la didattica, perché un servo:

contiene già la propria elettronica di pilotaggio,
si controlla con un semplice segnale PWM (impulsi “stile servo”),
prende l’energia dal pacco batterie/board del kit, non dai pin di micro:bit.

In pratica:

micro:bit invia il comando (PWM),
il servo esegue, usando la sua alimentazione dedicata.

Questo è il motivo per cui, con :MOVE mini, si riesce ad avere un robot “semplice” e robusto senza introdurre subito il tema dei ponti H per motori DC.

:MOVE mini

Cosa vedremo nel corso: motori DC “veri” e driver dedicati

Durante il corso mostrerò anche l’altro scenario, quello tipico quando si usano i classici motori gialli da 6 V (motori DC con riduttore), dove il driver è obbligatorio.

motore TT

Lavoreremo in particolare con:

L298N (ottimo per capire il concetto di ponte H e cablaggi, anche se non è la soluzione più efficiente in assoluto),
Motor:bit di ELECFREAKS (più compatta e didattica, comoda per micro:bit).

Obiettivo: far capire chiaramente la differenza tra:

“motore DC” (serve driver + alimentazione adeguata),
“servo” (driver interno, controllo PWM più diretto).

Regola utile sempre: alimentazione separata e masse in comune

Quando si entra nel mondo motori/attuatori, una buona pratica è:

alimentare i motori/servi con una linea robusta (batterie/pack dedicato),
e mantenere massa (GND) in comune tra microcontrollore e driver/attuatori (quando richiesto), così i segnali di controllo hanno un riferimento corretto.

Questa singola regola elimina moltissimi “misteri” (reset, comportamenti casuali, servo che impazziscono).

Qualche precisazione in più sui motori DC o motori senza elettronica di controllo integrata

Troverete spesso la dicitura motori bare DC motor in pratica sono motori che hanno solo due terminali (o due fili):

fornite tensione > girano
togliete tensione > si fermano
invertite la polarità > invertono il verso di rotazione (se lo permettete elettricamente)

In ambito tecnico anglofono è abbastanza comune parlare di “bare DC motor” per indicare un motore senza elettronica di controllo integrata (cioè “il solo motore”, tipicamente a due fili) e spesso anche senza riduttore/struttura accessoria.

Esempi tipici:

i classici motori gialli TT 3–6 V usati nei robot economici
motorini DC “a spazzole” da modellismo o recuperati da giocattoli

I bare DC motor non hanno al loro interno:

driver di potenza
protezioni contro i picchi (back-EMF)
logica per interpretare un segnale di controllo

Quindi, per farli funzionare con micro:bit, serve aggiungere elettronica esterna:

un ponte H (es. L298N, TB6612, DRV8833) se vuoi avanti/indietro + PWM
oppure un MOSFET + diodo se ti basta on/off (e magari un solo verso)

L298N

TB6612

DRV8833

Differenza con un servo (o un motoriduttore “intelligente”)

Un servomotore (anche a rotazione continua) invece non è senza elettronica di controllo perché contiene già:

elettronica di pilotaggio
circuito di potenza
logica che interpreta il comando (impulsi PWM stile servo)

Per questo il micro:bit può “comandare” un servo con un semplice segnale, mentre con un motore DC senza elettronica di controllo deve essere gestito da un driver.

Buon Making a tutti 🙂

Meditazione da Maker: un supporto DIN per prototipare in fretta (e con ordine)

Lascia una risposta

5 minuti da Maker del fine settimana.

In queste settimane devo prototipare velocemente e rispondere ai dubbi di studenti di classi diverse: c’è chi inizia a “giocare” con l’elettronica e chi, più grande, pensa già ai progetti per la maturità. Risultato? Un continuo montare e smontare circuiti… e l’ordine che vacilla.

Per la mia attività di making del weekend ho deciso di dare forma a un supporto di prototipazione basato su guide DIN (guide omega), utilissime in elettronica e automazione. Chi mi segue sa che in passato ho realizzato vari supporti, trovate esempi sul mio sito e su Thingiverse, soprattutto per esercitazioni con PLC e microcontrollori.

Oggi pomeriggio, stanco dei moduli sparsi sul banco, ho sfruttato solo materiale di recupero per costruire una base pratica che mi permetta di passare da un’esercitazione all’altra in pochi minuti. Ho trattato l’attività come una piccola “Meditazione da Maker”: due ore di musica in sottofondo, progettazione e realizzazione. Missione compiuta nei tempi.

Il progetto è ancora migliorabile, quindi per ora non condivido i sorgenti: li pubblicherò a breve. Dalle immagini si capisce comunque quanto sia semplice replicarlo. La base misura 22×22 cm, una scelta dettata dal pannello già a disposizione e la struttura che ospita le barre DIN riprende i miei progetti precedenti, con qualche variazione mirata.

Nei prossimi giorni arriveranno sorgenti e dettagli, tornate a trovarmi. 🙂

Arduino – istruzione “do…while” – soluzione esercizi proposti

Lascia una risposta

In riferimento alla lezione: Arduino – istruzione “do…while”: eseguire almeno una volta, poi verificare pubblico una possibile soluzione agli esercizi proposti.

Esercizio 01 – Attendi pulsante

Consegna: attendere che un pulsante su D2 venga premuto; durante l’attesa far lampeggiare il LED integrato.
Vincoli: usare while come attesa in ingresso (while(digitalRead(…)==HIGH)).
Extra: al termine, stampare “OK” e fermarsi.

Soluzione

/*
  Prof. Maffucci Michele
  data: 27.10.25

  Soluzione esercizio 01 - Attendi pulsante
  Hardware:
    - Pulsante su D2 con INPUT_PULLUP (un capo a D2, l'altro a GND)
    - LED integrato (pin 13)
  Obiettivo:
    - Lampeggiare il LED mentre si attende la pressione del pulsante
    - Usare while(digitalRead(PIN_BTN) == HIGH) come attesa
    - Quando il pulsante viene premuto -> stampare "OK" e fermarsi
*/

// PIN_BTN dichiarato come byte e non come int per occupare meno spazio di memoria
// collegare il pulsante a GND (INPUT_PULLUP)

const byte PIN_BTN = 2;

void setup() {
  pinMode(LED_BUILTIN, OUTPUT);
  pinMode(PIN_BTN, INPUT_PULLUP);
  Serial.begin(9600);
  Serial.println("Premi il pulsante per continuare...");
}

void loop() {
  // Attesa attiva: finché il pulsante NON è premuto (HIGH con pull-up)
  // il LED_BUILTIN (13) lampeggia
  while (digitalRead(PIN_BTN) == HIGH) {
    digitalWrite(LED_BUILTIN, HIGH);
    delay(150);
    digitalWrite(LED_BUILTIN, LOW);
    delay(150);
  }

  // Debounce semplice per elimina rimbalzi meccanici
  // realizzato con piccolo ritardo
  delay(30);
  
  while (digitalRead(PIN_BTN) == LOW) {  // resta qui finché è tenuto premuto
  }

  Serial.println("OK");
  digitalWrite(LED_BUILTIN, HIGH);      // lascia il LED acceso come conferma
  while (true) {}                       // ferma la demo
}

Esercizio 02 – Svuota buffer seriale

Consegna: quando l’utente invia testo, fare echo e svuotare tutti i caratteri residui.
Vincoli: usare while(Serial.available()>0).
Extra: contare quanti byte sono stati letti e mostrarli.

Soluzione

/*
  Prof. Maffucci Michele
  data: 27.10.25

  Soluzione esercizio 02 — Svuota buffer seriale
  Obiettivo:
    - Appena arriva del testo, fare echo di TUTTI i caratteri presenti nel buffer
    - Usare while(Serial.available() > 0) per svuotare il buffer
    - Contare i byte letti e mostrarli
  Ricordare:
    - Impostare il Serial Monitor a 9600 baud
*/

void setup() {
  Serial.begin(9600);
  Serial.println("Scrivi una riga di testo e premi invio...");
}

void loop() {
  if (Serial.available() > 0) {
    int conteggioByte = 0;

    Serial.print("Echo: ");
    // Legge TUTTO ciò che è attualmente in buffer
    while (Serial.available() > 0) {
      char c = Serial.read();     // leggi un byte
      Serial.write(c);            // echo (stampa il carattere così com'è)
      conteggioByte++;            // conta i byte letti
      // piccola attesa facoltativa per dare tempo al buffer di riempirsi
      delay(1);
    }
    Serial.println();
    Serial.print("Byte letti: ");
    Serial.println(conteggioByte);
    Serial.println("----");
  }
  // Se serve introdurre qui altro codice non bloccante
}

Attenzione!

Può capitare che vengano contati due byte in più, ciò accade perché la Serial Monitor (in basso a destra)
aggiunge automaticamente i caratteri di fine riga quando premete invio.

entrambi NL & CR (Both NL & CR) > aggiunge due byte: \r (CR, 13) e \n (LF, 10) → ecco il tuo +2 costante;
a capo NL (Newline) > aggiunge un byte: \n > +1;
ritorno carrello (CR) (Carriage return) > aggiunge un byte: \r > +1;
nessuna fine riga (No line ending) > +0 (il conteggio coincide con i caratteri digitati, salvo caratteri non ASCII).

Esercizio 03 – Timer regressivo

Consegna: da un valore t letto da Serial (es. 5..20), eseguire un countdown finché t>0.
Vincoli: usare while(t>0) con t– e stampa del tempo.
Extra: beep finale + messaggio “Decollo!”.

Soluzione

/*
  Prof. Maffucci Michele
  data: 27.10.25

  Soluzione esercizio 03 — Timer regressivo
  Obiettivo:
    - Leggere un intero t (5..20) dal Serial Monitor
    - Eseguire while(t > 0) con stampa del tempo e t--
    - Al termine: beep su D5 e messaggio "Decollo!"
  Note:
    - Usa Serial.parseInt() per semplicità (attende un numero)
    - Per maggior informazioni sull'uso di parseInt() consultare il link:
      https://wp.me/p4kwmk-4Ah
*/

const int PIN_BUZ = 5;  // collegare un buzzer piezo (se disponibile)

void setup() {
  Serial.begin(9600);
  pinMode(PIN_BUZ, OUTPUT);
  Serial.println("Inserisci un numero intero t tra 5 e 20 e premi invio:");
}

void loop() {
  int t = 0;

  // Attendi un numero valido nell'intervallo [5..20]
  while (t < 5 || t > 20) {
    if (Serial.available() > 0) {
      t = Serial.parseInt();  // legge il primo intero disponibile
      // Svuota residui (ad es. '\n')
      while (Serial.available() > 0) Serial.read();

      if (t < 5 || t > 20) {
        Serial.println("Valore non valido. Inserisci un numero tra 5 e 20:");
      }
    }
  }

  // Countdown con while(t > 0)
  while (t > 0) {
    Serial.print("T-");
    Serial.println(t);
    delay(1000);  // 1 secondo
    t--;
  }

  // Fine: beep + messaggio
  tone(PIN_BUZ, 880, 350);  // beep di 350 ms
  Serial.println("Decollo!");

  while (true) {}  // ferma la demo
}

Buon lavoro.

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

Lascia una risposta

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.

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”).

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).

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.

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).

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.

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.

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 operativa – Apri 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.

Lezione 10 – Corso di Elettronica Creativa con Arduino Sensor Kit

Lascia una risposta

Cenni teorici

Cos’è la pressione atmosferica?

La pressione atmosferica è la forza esercitata dall’aria su ogni unità di superficie. Viene misurata in pascal (Pa) o, più comunemente, in hectopascal (hPa) dove 1 hPa = 100 Pa.

Il sensore BMP280

Il BMP280 è un sensore barometrico assoluto prodotto da Bosch Sensortec. Le sue caratteristiche principali:

Campo di misura: 300 – 1100 hPa (≈ -500 m / +9000 m s.l.m.)
Accuratezza assoluta tip. ±1 hPa; accuratezza relativa ±0.12 hPa (≈ ±1 m)
Interfacce: I²C (fino a 3.4 MHz) e SPI
Consumo: 2.7 µA @ 1 Hz in modalità normale
Range termico: –40 … +85 °C

Collegamenti

Collegate il cavo Grove tra il connettore del sensore e la porta I²C (qualsiasi) sullo shield.

Installazione libreria

Sicuramente è un’operazione che avete già eseguito, in ogni caso lo ricordo:

Arduino IDE > Gestione librerie > cerca “Arduino_SensorKit”.
Installate la libreria (include automaticamente LPS22HB, HTS221, OLED, ecc.)

Esempio 01: Sketch base – Lettura e stampa dati su Serial Monitor

/*
  Prof. Maffucci Michele
  02.10.2025
  LPS22HB del Sensor Kit
  Stampa valori su Serial Monitor
*/

#include &lt;Arduino_SensorKit.h&gt;   // include unico per tutti i sensori

void setup() {
  Serial.begin(9600);
  Pressure.begin();              // inizializza il barometro
}

void loop() {
  // La libreria restituisce:
  // - pressione in pascal
  // - temperatura in gradi Celsius
  // - altitudine in metri rispetto a 1013,25 hPa

float pressionePa  = Pressure.readPressure();
  float temperaturaC = Pressure.readTemperature();
  float altitudineM  = Pressure.readAltitude();

// conversione pa → hPa per leggibilità
  float pressioneHpa = pressionePa / 100.0;

Serial.print(F("Pressione: "));
  Serial.print(pressioneHpa, 2);
  Serial.print(F(" hPa\tTemperatura: "));
  Serial.print(temperaturaC, 2);
  Serial.print(F(" °C\tAltitudine: "));
  Serial.print(altitudineM, 1);
  Serial.println(F(" m"));

delay(1000);
}

Ricordo che, come già indicato nelle precedenti lezioni, la F(…) (maiuscola), inserita all’interno delle Serial.print(), è una macro di Arduino che serve a mettere una stringa letterale in memoria flash (PROGMEM) invece che copiarla nella SRAM al momento della stampa.

Perché è utile utilizzare F

Le board come Arduino UNO (AVR) hanno poca SRAM (2 KB).
Senza (), ogni stringa tra virgolette ("Pressione: ") viene copiata in SRAM prima di stamparla > spreco di RAM.
Con F("Pressione: "), la stringa resta in flash e Serial.print() la legge direttamente da lì > RAM risparmiata.

Come si usa

Funziona con tutte le funzioni che derivano da Print (es. Serial.print, Serial.println, spesso anche display che usano print in stile Arduino):

Serial.print(F("Pressione: "));
Serial.println(F(" hPa"));

Quando usarla

Frasi/titoli/menu costanti e ripetute (log su Serial, messaggi di errore, etichette).
Con progetti in cui si ha scarsa disponibilità di RAM (UNO/Nano classici) può fare la differenza.

Limiti

Non puoi concatenare direttamente elementi come F(“A”) + F(“B”).
Evitare di mescolarla con String in modo implicito (meglio stampare pezzi separati).
Funzioni come sprintf non leggono da flash; su AVR esistono versioni “_P” (es. sprintf_P) per farlo.

La struttura delle funzioni (Pressure.begin(), Pressure.readPressure(), ecc.) è la stessa mostrata negli esempi ufficiali di Arduino.

Esempio 02: Lettura e stampa dati su Serial Monitor e display OLED

Abbiamo già visto l’uso del display OLED nella lezione: Lezione 9 – Corso di Elettronica Creativa con Arduino Sensor Kit vediamo ora come mostrare i valori di: pressione, temperatura e altitudine anche sul display OLED.

/*
  Prof. Maffucci Michele
  02.10.2025
  BMP280 - Arduino Sensor Kit
  Stampa valori su Serial Monitor e OLED
*/

#include <Arduino_SensorKit.h>  // include unico per tutti i sensori

void setup() {
  Serial.begin(9600);
  Pressure.begin();  // inizializza il barometro

Oled.begin();
  // Inizializza il display OLED.
  // Fa partire la comunicazione I2C e manda al display la sequenza di avvio.
  // Senza questa riga lo schermo non mostra nulla.

Oled.setFlipMode(true);
  // Ruota il contenuto di 180° (utile se lo vedi capovolto).
  // Se nel tuo caso appare già dritto, puoi mettere false: Oled.setFlipMode(false);

Oled.setFont(u8x8_font_chroma48medium8_r);
  // Sceglie il font (carattere) 8x8.
  // Con un font 8x8 il display 128x64 si comporta come una griglia 16 colonne × 8 righe.
  // Significa che setCursor(colonna, riga) userà numeri tra 0..15 (colonne) e 0..7 (righe).

Oled.clear();
  // Pulisce lo schermo (cancella tutto quello che c’era prima).
}

void loop() {
  // La libreria restituisce:
  // - pressione in pascal
  // - temperatura in gradi Celsius
  // - altitudine in metri rispetto a 1013,25 hPa

float pressionePa = Pressure.readPressure();
  float temperaturaC = Pressure.readTemperature();
  float altitudineM = Pressure.readAltitude();

// conversione pa → hPa per leggibilità
  float pressioneHpa = pressionePa / 100.0;

// --- Intestazione ---

Oled.setCursor(0, 0);             // colonna 0, riga 0
  Oled.println("STAZIONE METEO");   // stampa la stringa e va a capo
  Oled.println("P - Pressione");    // stampa la stringa e va a capo
  Oled.println("T - Temperatura");  // stampa la stringa e va a capo
  Oled.println("A - Altitudine");   // stampa la stringa e va a capo

Oled.setCursor(0, 5);         // colonna 0, riga 2
  Oled.print("P: ");            // stampa la stringa P:
  Oled.print(pressioneHpa, 2);  // stampa valore della pressione con 2 numeri decimali

Oled.setCursor(0, 6);         // colonna 0, riga 3
  Oled.print("T: ");            // stampa la stringa T:
  Oled.print(temperaturaC, 2);  // stampa valore della temperatura con 2 numeri decimali
  Oled.refreshDisplay();

Oled.setCursor(0, 7);        // colonna 0, riga 4
  Oled.print("A: ");           // stampa la stringa A:
  Oled.print(altitudineM, 2);  // stampa valore dell'altitudine con 2 numeri decimali
  Oled.refreshDisplay();

// Aggiorna fisicamente il display (altrimenti potresti non vedere le modifiche).
  delay(60);

Serial.print(F("Pressione: "));
  Serial.print(pressioneHpa, 2);
  Serial.print(F(" hPa\tTemperatura: "));
  Serial.print(temperaturaC, 2);
  Serial.print(F(" °C\tAltitudine: "));
  Serial.print(altitudineM, 1);
  Serial.println(F(" m"));

delay(1000);
}

Buon Coding a tutti 🙂

Michele Maffucci

… my stories, life and work

Archivi tag: elettronica

Domande dagli utenti: perché micro:bit non pilota i motori direttamente?

Perché “alzare la tensione” non risolve il problema

Disturbi e picchi: il motore “sporca” l’alimentazione e genera back-EMF

Il caso reale nei kit: Ring:bit V2 board e Kitronik :MOVE mini

Cosa vedremo nel corso: motori DC “veri” e driver dedicati

Regola utile sempre: alimentazione separata e masse in comune

Differenza con un servo (o un motoriduttore “intelligente”)

Meditazione da Maker: un supporto DIN per prototipare in fretta (e con ordine)

Arduino – istruzione “do…while” – soluzione esercizi proposti

Esercizio 01 – Attendi pulsante

Soluzione

Esercizio 02 – Svuota buffer seriale

Soluzione

Esercizio 03 – Timer regressivo

Soluzione

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

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

Setup

Sintomi

Procedura di diagnosi

Checklist “fatto”

Note didattiche

Lezione 10 – Corso di Elettronica Creativa con Arduino Sensor Kit

Cenni teorici

Cos’è la pressione atmosferica?

Il sensore BMP280

Collegamenti

Installazione libreria

Esempio 01: Sketch base – Lettura e stampa dati su Serial Monitor

Perché è utile utilizzare F

Come si usa

Quando usarla

Limiti

Esempio 02: Lettura e stampa dati su Serial Monitor e display OLED

Perché “alzare la tensione” non risolve il problema

Disturbi e picchi: il motore “sporca” l’alimentazione e genera back-EMF

Il caso reale nei kit: Ring:bit V2 board e Kitronik :MOVE mini

Cosa vedremo nel corso: motori DC “veri” e driver dedicati

Regola utile sempre: alimentazione separata e masse in comune

Differenza con un servo (o un motoriduttore “intelligente”)

Related posts:

Related posts:

Esercizio 01 – Attendi pulsante

Soluzione

Esercizio 02 – Svuota buffer seriale

Soluzione

Esercizio 03 – Timer regressivo

Soluzione

Related posts:

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

Setup

Sintomi

Procedura di diagnosi

Checklist “fatto”

Note didattiche

Related posts:

Cenni teorici

Cos’è la pressione atmosferica?

Il sensore BMP280

Collegamenti

Installazione libreria

Esempio 01: Sketch base – Lettura e stampa dati su Serial Monitor

Perché è utile utilizzare F

Come si usa

Quando usarla

Limiti

Esempio 02: Lettura e stampa dati su Serial Monitor e display OLED

Related posts: