Archivi tag: ESP32-S3

OpenStudy Desktop Companion: costruire uno strumento per imparare a gestire il tempo di studio

Lascia una risposta

Un progetto con ESP32-S3 ed e-paper che nasce con un duplice obiettivo: realizzare un dispositivo realmente utile e trasformarne la costruzione in un’attività di laboratorio per gli studenti

Da qualche settimana sto lavorando a un nuovo progetto che unisce alcuni temi che ricorrono spesso nelle attività che sviluppo: elettronica, making, progettazione di interfacce, tecnologie per lo studio e didattica laboratoriale, il progetto si chiama:

OpenStudy Desktop Companion.

Si tratta di un piccolo dispositivo da scrivania dotato di display e-paper che sto sviluppando per accompagnare sessioni intenzionali di studio e lettura.

La domanda da cui sono partito è molto semplice:

perché costruire un dispositivo dedicato allo studio quando uno smartphone può già fare praticamente tutto?

Posso impostare un timer sul telefono, installare applicazioni per la tecnica Pomodoro, registrare quanto studio e consultare statistiche estremamente dettagliate, proprio qui, però, si trova anche il problema.

Quando porto lo smartphone sulla scrivania non porto soltanto un timer, porto notifiche, messaggi, social network, applicazioni e un dispositivo progettato per richiamare continuamente la mia attenzione.

OpenStudy Desktop Companion nasce quindi da un’idea diversa: provare a costruire una tecnologia che faccia poche cose, ma in modo intenzionale, e che possa restare sulla scrivania senza diventare un’ulteriore fonte di distrazione.

Piccolo dispositivo OpenStudy Desktop Companion con display e-paper acceso accanto a un libro e a un quaderno.

OpenStudy Desktop Companion sulla scrivania durante una normale sessione di lavoro.

Non soltanto misurare il tempo, ma imparare a gestirlo

Uno degli aspetti che mi interessa maggiormente riguarda proprio il rapporto con il tempo.

OpenStudy non nasce con l’obiettivo di dire semplicemente allo studente:

“devi studiare per 25 minuti”.

Vorrei che diventasse invece uno strumento attraverso il quale allenarsi progressivamente a compiere alcune scelte:

che cosa sto per fare? Quanto tempo penso di poter dedicare a questa attività? Riesco a mantenere l’impegno che ho scelto? Alla fine della sessione, come è andata?

Il timer diventa quindi soltanto una parte del processo.

Prima della sessione c’è una scelta intenzionale, durante la sessione c’è la gestione del tempo, alla fine c’è una breve riflessione e rimane una traccia del lavoro svolto.

Questo passaggio mi interessa particolarmente dal punto di vista didattico perché la gestione del tempo di studio non è una competenza che possiamo dare per acquisita, può essere osservata, discussa e allenata ed è proprio qui che emerge il secondo obiettivo del progetto.

Un dispositivo da usare, ma anche da costruire

OpenStudy Desktop Companion ha infatti per me due obiettivi paralleli:

  • il primo è costruire un oggetto realmente utilizzabile per accompagnare studio e lettura.
  • il secondo è trasformare progressivamente il progetto in una attività laboratoriale per gli studenti.

Non vorrei quindi consegnare semplicemente agli studenti un dispositivo finito dicendo loro come utilizzarlo. L’obiettivo più interessante è portarli, progressivamente, a comprenderne e costruirne almeno una parte.

Questo permette di lavorare contemporaneamente su elettronica e programmazione, ma anche su problemi molto concreti di progettazione.

  • Come deve essere organizzata una schermata di soli 200 × 200 pixel?
  • Quali informazioni sono realmente necessarie?
  • Quando deve essere aggiornato un display?
  • Come si gestisce un’interfaccia touch?
  • Come si conserva un’impostazione anche dopo lo spegnimento?
  • Come si registra localmente una sessione?
  • Come si leggono temperatura e umidità da un sensore?
  • Come si gestiscono data e ora attraverso un RTC?

E, soprattutto:

stiamo costruendo una funzione perché possiamo farlo oppure perché serve realmente alla persona che utilizzerà il dispositivo?

Quest’ultima domanda, dal punto di vista didattico, vale probabilmente più di molte spiegazioni puramente tecniche.

OpenStudy Desktop Companion accanto a un computer con Visual Studio Code utilizzato per lo sviluppo del firmware.

Il firmware di OpenStudy Desktop Companion viene sviluppato in C++ con framework Arduino, Visual Studio Code e PlatformIO.

L’hardware: perché ho scelto la Waveshare ESP32-S3-Touch-ePaper-1.54 V2

Per questo prototipo sto utilizzando una Waveshare ESP32-S3-Touch-ePaper-1.54 V2, la scelta non è stata determinata semplicemente dalla potenza dell’ESP32-S3, ci sono molte schede con le quali sarebbe possibile costruire un dispositivo simile, ciò che mi interessava era soprattutto il livello di integrazione.

In un oggetto estremamente compatto questa scheda mette a disposizione:

  • ESP32-S3-PICO-1-N8R8, con 8 MB di Flash e 8 MB di PSRAM;
  • display e-paper bianco e nero da 1,54 pollici, 200 × 200 pixel;
  • interfaccia touch;
  • RTC PCF85063 per mantenere data e ora;
  • sensore SHTC3 per temperatura e umidità;
  • slot microSD;
  • codec audio ES8311, altoparlante e microfono;
  • USB-C e gestione della batteria al litio;
  • Wi-Fi e Bluetooth disponibili attraverso l’ESP32-S3, anche se al momento non vengono utilizzati dalle funzioni del Companion.

Questa integrazione permette di ridurre notevolmente cablaggi e componenti esterni e, soprattutto nella fase di prototipazione, consente di concentrare molto del lavoro sul firmware e sull’esperienza d’uso.

Dal punto di vista laboratoriale trovo inoltre interessante avere nello stesso progetto tecnologie differenti: bus I²C, touch, sensori, RTC, memoria persistente, microSD, audio e display e-paper.

OpenStudy può quindi diventare anche una sorta di laboratorio compatto di sistemi embedded.

Continua a leggere→

Related posts:

  1. Companion per la sperimentazione e lo studio – analizziamo PaperMono – M5Stack
  2. I miei corsi: Apprendimento attivo con Raspberry Pi e Arduino
  3. Apnea e un po’ di robotica
  4. EduRobot – ASL (Alternanza Scuola Lavoro) – Manuale di costruzione – 2/3

ESP32-C3 Super Mini vs ESP32-S3 Super Mini: differenze e quale scegliere

Lascia una risposta

In riferimento al post pubblicato la scorsa settimana, mi è arrivato un messaggio da parte di un lettore: cercando la stessa schedina in rete ha notato che, oltre alla versione ESP32-C3 Super Mini, viene proposta anche la ESP32-S3 Super Mini e mi ha chiesto, che cosa cambia tra le due schede.

La domanda è più che legittima, perché a colpo d’occhio le due board sembrano quasi identiche: stesso formato compatto, stesso uso tipico in progetti IoT e didattici. In realtà le due schede si differenziano in molte cose: architettura della CPU, prestazioni, numero di GPIO disponibili, gestione USB, e (in molti modelli S3) perfino dettagli pratici come la presenza dei pad per collegare direttamente una batteria Li-Po con ricarica via USB.

In questo articolo metto quindi a confronto ESP32-C3 Super Mini e ESP32-S3 Super Mini, prima indico le differenze elettroniche (quelle che dipendono dal chip), poi evidenzio le differenze che dipendono dalla specifica schedina e dal produttore, così da capire subito quale scegliere in base al progetto e agli obiettivi didattici.

Premessa importante: “Super Mini” non è uno standard

“Super Mini” descrive un form factor molto diffuso, ma non è un nome “ufficiale” che garantisce caratteristiche identiche tra produttori.

Quindi:

  • le differenze C3 vs S3 (CPU, USB, risorse) sono reali e dipendono dal chip;
  • dettagli come LED onboard, pin esposti, flash/PSRAM, pad batteria possono variare a seconda del lotto e del venditore.

In questo post separo volutamente:

  • differenze elettroniche del chip;
  • differenze dipendenti dal produttore.

Confronto tra le due schede

Nella tabella che segue vengono indicate le differenze tra le due schede:

Aspetto ESP32-C3 Super Mini ESP32-S3 Super Mini
CPU RISC-V single-core (tipicamente fino a 160 MHz) Xtensa LX7 dual-core (tipicamente fino a 240 MHz)
Potenza percepita ottima per IoT “snello” migliore su web UI ricche, log, parsing, multitasking
GPIO disponibili in genere meno margine in genere molti più GPIO “utili”
USB molto comoda per programmazione/debug USB OTG (progetti USB “creativi”) + programmazione
Progetti tipici sensori/attuatori, MQTT/HTTP, BLE semplice progetti più “ricchi”, USB, più periferiche insieme
Batteria (su molte board) spesso richiede gestione esterna spesso include pad batteria + ricarica USB (dipende dal modello)

Pinout ESP32 S3 Super mini

Differenze elettroniche

CPU: single-core vs dual-core

Questa è la differenza più importante:

  • ESP32-C3: single-core > perfetto per progetti ripetibili, sensori e automazioni;
  • ESP32-S3: dual-core > più margine quando ad esempio uniamo web server + gestione rete + periferiche + log + UI; quindi con S3 possiamo gestire programmi di dimensioni più grandi e più complessi.

Utilizzo esteso dell’USB

  • Con C3 la USB è “comoda” perché semplifica upload e debug (senza chip USB-serial esterno);
  • con S3 poiché è supportato il mondo USB OTG: potete progettare dispositivi che si presentano al PC come periferiche USB (a seconda delle librerie e della configurazione).

GPIO e periferiche

S3 offre in genere:

  • più GPIO disponibili (più alternative di cablaggio);
  • più margine quando usate più bus/linee insieme (SPI, I2C, UART multiple, ecc.).

Differenze dipendenti dal produttore

LED onboard

Su molte ESP32-C3 Super Mini il LED onboard:

  • è su un pin specifico (spesso GPIO8),
  • può essere in logica invertita (active-LOW: LOW = acceso, HIGH = spento).

Per evitare confusione (e rendere gli esempi robusti tra lotti), io consiglio di dichiarare due costanti:

const int PIN_LED = 8;     // esempio tipico: verificate sul vostro modello
const int LED_ON  = LOW;   // se il LED è active-LOW
const int LED_OFF = HIGH;

void setup() {
  pinMode(PIN_LED, OUTPUT);
  digitalWrite(PIN_LED, LED_OFF);
}

void loop() {
  digitalWrite(PIN_LED, LED_ON);
  delay(300);
  digitalWrite(PIN_LED, LED_OFF);
  delay(300);
}

Se sulla vostra scheda il LED non è invertito, basta scambiare LED_ON/LED_OFF e il resto del codice rimane identico.

S3: LED RGB

Molte schede ESP32-S3 Super Mini (in generale vale per tutte quelle che ho usato ed acquistate su diversi store) includono un LED RGB (tipo WS2812) molto utile per “stati” e debug (Wi-Fi ok, errore, modalità AP, ecc.).
Attenzione: pin e presenza dipendono dalla board. Prima di copiare uno sketch per la gestione del led RGB, verificate sullo schema/pinout del vostro modello.

Batteria e ricarica

Modello ESP32-S3 Super Mini (nel mio caso acquistato su Amazon)

Su questa scheda, nello schema sono indicati i pin/pad a cui saldare la batteria. In altre parole: su questa versione è previsto il collegamento diretto di una Li-Po 1S (3,7 V nominali) tramite piazzole dedicate.
Nella maggior parte delle Super Mini S3 che supportano batteria trovate (di solito sul retro) due pad del tipo:

B+ > positivo batteria
B- > negativo batteria (GND)

In molte varianti, come quella acquistata da me, insieme ai pad batteria, è presente anche un circuito di ricarica via USB-C e un LED di stato legato alla carica (gestito dal circuito di power/charge, non via GPIO). Lo schema del venditore è sempre il riferimento migliore per capire cosa è effettivamente presente sulla tua board.

Avvertenze pratiche molto importanti

  • Usate solo batterie 1S (Li-Po/Li-Ion 3,7 V nominali; 4,2 V a fine carica).
    Controllate la polarità prima di saldare: inversione o corto su una Li-Po può danneggiare scheda e batteria;
  • consiglio di non saldare direttamente la batteria al PCB, potete saldare ai pad un cavetto con connettore (es. JST) così la batteria diventa removibile e riducete stress meccanici sulle piazzole.

Buon Making a tutti 🙂

Related posts:

  1. Organizzatore modulare per cavetti Dupont anche su barra DIN
  2. I miei corsi: Apprendimento attivo con Raspberry Pi e Arduino
  3. 5 minuti da Maker – contenitore per spugna di ottone per pulizia saldatore
  4. EduRobot – ASL (Alternanza Scuola Lavoro) – Manuale di costruzione – 2/3