Archivi categoria: programmazione

Progettare bene, programmare meglio: diagrammi di flusso – Lezione 1/5

Ripasso di inizio anno – appunti per la classe.

Perché bisogna imparare a realizzare i diagrammi di flusso (anche se “programmiamo poco”)?

Quando progetti un programma per Arduino, il problema più grande non è scrivere le parentesi giuste: è decidere l’ordine delle azioni e quando prendere decisioni. Un diagramma di flusso è un disegno semplice che mostra i passi da compiere, le scelte “sì/no” e l’ordine in cui tutto accade. È usato in informatica da decenni proprio per rappresentare, passo-passo, il comportamento di un algoritmo o di un processo.

Un flowchart ti aiuta a vedere il programma prima di scriverlo: rettangoli per le azioni (es. “accendi LED”), rombi per le domande (es. “pulsante premuto?”), ovali per inizio/fine, parallelogrammi per ingresso/uscita di dati, frecce per la direzione. L’idea è sempre quella: dall’alto verso il basso, una freccia alla volta, fino all’uscita. Questa notazione è diventata uno standard di fatto e, nelle versioni “complete”, include molte altre forme utili (ne esistono decine); noi useremo solo quelle essenziali.

Dove si usano e perché ci interessano in laboratorio di sistemi

I diagrammi di flusso non servono solo a chi programma: si usano per documentare, spiegare e migliorare processi in tanti contesti (scuola, aziende, sanità, logistica). Nel nostro laboratorio li usiamo per tradurre un problema reale (una luce che si accende, un sensore che decide) in una sequenza chiara. Questo approccio è lo stesso che trovi nel project management: rappresentare un processo rende più facile pianificare, allineare il team e trovare i colli di bottiglia.

Esistono poi varianti “cugine” dei flowchart che potresti incontrare:

  • Workflow (flusso di lavoro), molto usato per capire chi fa cosa e quando;
  • Swimlane (corsie), utile quando più persone o sottosistemi collaborano;
  • Data Flow Diagram / DFD (flusso di dati), focalizzato su come circolano i dati tra parti di un sistema.

Noi partiamo dal flowchart di base (azioni/decisioni) perché è il ponte più diretto verso il codice Arduino

Buone pratiche “da prima riga di codice”

  • Definisci il problema in una frase (“Cosa voglio ottenere?”).
  • Elenca i passi e le decisioni (domande “sì/no”).
  • Disegna il flusso con poche forme standard (Inizio > Azioni > Decisioni > Fine).
  • Cerca le inefficienze: passaggi inutili, decisioni doppie, attese esagerate.
  • Condividi e rivedi: il diagramma è un documento vivo; aggiornatelo quando cambi idea.

Questa routine è identica a quella usata nei team professionali quando costruiscono o migliorano un processo.

Dalla carta al digitale (e al testo)

Puoi disegnare su carta, usare strumenti visuali come Lucidchart o Miro (trascini le forme e colleghi con frecce), oppure scrivere i diagrammi come testo con Mermaid (“diagram as code”), che si integra bene nei siti e nelle note tecniche. In questa lezione useremo Mermaid proprio per abituarci a ragionare prima in blocchi, poi in pseudocodice, poi in C/C++ per Arduino.

Mappa veloce “flowchart > Arduino”

Inizio / Setup > setup(): qui imposti i pin come INPUT/OUTPUT.
Azione → istruzioni come digitalWrite(), analogWrite(), tone().
Decisione (rombo) > if (...) { ... } else { ... }, spesso con letture da sensori: digitalRead(), analogRead().
Ciclo > loop() che ripete le azioni in sequenza.
Questa corrispondenza 1:1 rende naturale “tradurre” il disegno in codice, riducendo gli errori e il tempo di debug. (Rivedremo questa mappa in ogni esempio pratico.)

Cosa evitare all’inizio

  • Frecce che si incrociano: rendono il percorso confuso.
  • Domande ambigue: un rombo = una domanda con risposta sì/no chiara.
  • Simboli inventati: resta su 4–5 forme standard; andrai veloce e capirai tutto al volo.
  • Salti di logica: se ti perdi, torna ai passi del processo (definisci > elenca > disegna > verifica).

Un buon diagramma di flusso è come una ricetta: indica ingredienti (sensori/attuatori), passaggi (azioni), domande al cuoco (“la pasta è al dente?” > sì/no). Se la ricetta è chiara, il codice funziona e tutti in team capiscono cosa fare.

Nota per i lettori (studenti e non): nei paragrafi successivi troverai la pipeline completa che useremo sempre: Problema > Diagramma (Mermaid) > Pseudocodice > Sketch Arduino, con esempi concreti (LED, pulsante, LDR, buzzer). Questa struttura è pensata per classi che iniziano: potete seguirla anche se non hai mai scritto una riga di codice.

Simboli nei diagrammi di flusso: poche forme bastano

L’elenco delle forme può sembrare infinito, ma non serve conoscerle tutte. Ogni simbolo indica un tipo di passaggio preciso e ha un contesto d’uso ben definito. Quando disegni, se ti senti perso, torna all’essenziale: per la grande maggioranza dei diagrammi bastano davvero alcune forme base; le altre servono in casi specifici. Qui sotto trovi quelle più ricorrenti.

Forme comuni del flowchart

Simbolo del diagramma di flusso Nome Descrizione
Inizio/Fine Segna il punto di avvio o la conclusione del flusso; delimita i confini del processo.
Processo / Azione Indica un passo operativo: un’attività, una funzione o un’elaborazione che “fa qualcosa”.
Decisione Rappresenta una domanda binaria (sì/no, vero/falso) che dirama il percorso su esiti diversi.
Input/Output (Dati) Mostra un ingresso (dato in arrivo, misura, comando) o un’uscita(risultato, messaggio, documento).
Linea di flusso Definisce la direzione della sequenza tra le forme; chiarisce l’ordine dei passi.
Sottoprocesso / Processo predefinito Collega a una procedura già definita altrove o a un gruppo di azioni consolidate.
Connettore in pagina Unisce parti lontane dello stesso schema senza incrociare frecce; migliora la leggibilità.
Connettore fuori pagina Collega a un continua su un’altra pagina; spesso include un riferimento o un codice.
Documento Indica la produzione o l’uso di un documento (ordine, report, lettera, promemoria).
Documenti multipli Come sopra, ma per più documenti generati/gestiti nello stesso passaggio.
Input manuale L’utente digita o inserisce dati a mano (es. login, compilazione di un campo).
Operazione manuale Passo che richiede intervento umano (non automatizzato) per proseguire.
Database / Archivio dati Dati archiviati in modo strutturato e interrogabili (lettura/scrittura/filtri).
Memoria interna Dati conservati all’interno del sistema/dispositivo durante l’elaborazione.
Attesa / Ritardo Indica una pausa temporale o un ritardo prima del passo successivo.
Commento / Nota Aggiunge chiarimenti al lettore; si collega con linea tratteggiata alla parte pertinente.

Alcune varianti di forma e naming possono cambiare leggermente a seconda dello strumento o dello standard adottato; l’insieme di base rimane comunque coerente tra le principali piattaforme.

Nella prossima lezione vedremo quali tool utilizzare per disegnare diagrammi di flusso.

Buon Coding a tutti 🙂

Comprensione del testo tecnico – Escape game didattico con Arduino UNO R4 – icebreaker per l’inizio dell’anno scolastico

Da tempo sperimento l’escape game nelle attività di laboratorio: è una modalità estremamente coinvolgente, orienta l’attenzione all’obiettivo, aumenta la concentrazione e riduce il rumore non costruttivo. Quello che si sente in aula è il brusio utile di chi discute, prova, sbaglia e ci riprova per risolvere un problema. La sfida di questi mesi è renderla significativa anche per studenti un po’ più grandi, con competenze tecniche talvolta “disordinate” e bisogno di nuova motivazione.

Capisco che qualcuno possa considerarla una scelta poco adatta a un istituto tecnico, richiamando l’idea che la scuola debba puntare solo su abilità pratiche e nozioni da trasferire in vista del lavoro o dell’università. A mio avviso è una visione superata: la scuola è cambiata, gli studenti sono diversi, né peggiori né migliori di “noi”, i ragazzi vivono in un mondo che offre moltissimo, ma spesso lascia poco spazio alla creatività o, meglio, non la allena. Non devo convincere nessuno: da insegnante sento la responsabilità di cercare strategie efficaci per aiutare i ragazzi e, insieme ai colleghi, fornire loro gli strumenti per diventare cittadini consapevoli. Questo post è il mio diario di bordo: metto per iscritto ciò che sperimento in classe per farne memoria e, se può essere utile, per condividerlo.

Dopo aver progettato escape analogiche, digitali e fisiche, voglio consolidare l’approccio nella didattica curricolare. Comincio da qualcosa di semplice: un escape “ice breaking” di inizio anno. Quella che segue è l’attività, volutamente essenziale; se l’esperimento continuerà a funzionare, pubblicherò anche le prossime tappe.

Siamo all’inizio dell’anno scolastico, come dicevo sopra, ho rimodellato il mio “ice breaking” per il laboratorio di sistemi trasformandolo in una breve esplorazione individuale in stile escape. Nell’attività l’obiettivo non è “programmare bene”, ma osservare come gli studenti cercano informazioni, leggono testi tecnici e narrativi, e trasferiscono ciò che capiscono in un prodotto visivo semplice. Ho scelto un oggetto per loro nuovo, mi sono concentrato sulla matrice 12×8 dell’Arduino UNO R4 WiFi, ho creato una piccola situazione di disorientamento produttivo: un compito che per la loro fascia di età è elementare, però non è mai stato affrontato, da risolvere attingendo esclusivamente alla documentazione ufficiale sul sito Arduino.cc. La sequenza di indizi li ha costretti a leggere con attenzione, a verificare i prerequisiti, a selezionare ciò che serviva e a ricomporre la soluzione anche con un po’ di “copia e incolla consapevole” dagli strumenti ufficiali (come l’Editor della matrice). Chiudendo il percorso, ogni studente ha mostrato il simbolo di sblocco sulla matrice di LED ed ha guadagnato il badge, successivamente siamo passati ad un breve debrief collettivo in cui abbiamo esplicitato strategie efficaci, fraintendimenti e punti chiave tecnici per giungere alla consapevolezza di non avere completa dimestichezza nelle tecniche per risolvere un problema.

L’attività si è svolta in circa 90 minuti di lavoro, nella parte introduttiva ho dato alcune indicazioni operative dopo di che ho osservato e preso appunti sul loro modo di operare e farmi un’idea più precisa delle loro capacità.

Vi condivido l’attività che spero possa essere migliorata.

Materiali necessari per ogni allievo

  • N.1 scheda Arduino UNO R4
  • N. 1 PC per allievo
  • N. 1 Sito per creare l’escape game realizzato con Google Site, trovate il link al fondo di questo post.

Scheda di presentazione dell’attività didattica (per il docente/formatore)

“Sblocca il laboratorio” è un escape game didattico con ingresso morbido e motivante nell’ecosistema Arduino UNO R4 WiFi: lo studente deve mostrare un Simbolo di Sblocco sulla matrice 12×8 integrata sulla scheda, ma la chiave non è “scrivere codice da zero”; è trovare, capire e applicare le informazioni giuste dentro la documentazione ufficiale. L’attività allena così la ricerca dell’informazione tecnica (orientarsi tra Getting Started, Tutorial, Hardware; scegliere un esempio pertinente ed utilizzare l’editor della matrice), la comprensione del testo narrativo (tradurre la storia-missione in azioni concrete e verificabili) e la comprensione del testo tecnico (prerequisiti come installazione driver, concetti essenziali della LED Matrix, flusso operativo “disegna > esporta > carica”). In classe tutto ciò si traduce in problem solving consapevole: riconoscere i punti critici, correggere il percorso, giustificare le scelte di fonte e di metodo.
Funziona bene anche con gruppi fragili o demotivati perché il feedback è immediato. Lo scaffolding è naturale: la documentazione guida passo dopo passo e l’editor di icone riduce il carico cognitivo mantenendo il controllo del risultato. Il compito rimane breve, chiaro e gratificante: un unico output visivo con criteri di riuscita espliciti, abbastanza sfidante da dare senso alla ricerca, ma sufficientemente accessibile da permettere a tutti di arrivare in fondo e raccontare come ci sono arrivati. In questo modo la valutazione non riguarda solo l’esito, ma la qualità del percorso: dove hanno cercato, cosa hanno capito, come lo dimostrano.

Sito Escape per svolgere l’attività: “sblocca il laboratorio”

Se serve ho realizzato una versioni in lingua inglese del gioco escape in modo che si posa realizzare un’attività trasversale tra l’insegnamento dell’inglese e la disciplina tecnica, il link al sito è:

Unlock the Lab

Attenzione il badge è nascosto come link (il colore del testo si confonde con lo sfondo pagina) nell’ultima pagina, questa informazione deve essere fornita agli studenti solamente quando  hanno mostrato il codice sulla matrice LED dell’Arduino R4.

Buon lavoro 🙂

Guida all’uso di millis() – Lezione 1

Credo che una delle problematiche più ostiche da gestire soprattutto per i neofiti è l’utilizzo degli intervalli di tempo in cui eseguire operazioni con Arduino, mi riferisco all’uso e all’abuso improprio del delay(). Infatti gli studenti scoprono che, sebbene la funzione delay() sia facile da usare, ha degli effetti collaterali importanti; il principale è che ferma l’esecuzione dello sketch Arduino fino a quando non è trascorso il periodo di delay. Quando ciò accade, di solito chi spiega indirizza lo studente sull’esempio di defaut sulla temporizzazione non bloccante che troviamo nell’IDE di Arduino: BlinkWithoutDelay.

Molto spesso però questo confonde ancora di più le idee perché in realtà non si vuole solo far lampeggiare un LED ma si vogliono eseguire più operazioni contemporaneamente, quindi è bene comprendere a fondo il principio di funzionamento del BlinkWithoutDelay prima di poterlo applicare alla propria situazione.

Ho pensato quindi di realizzare qualche post tematico sull’uso di millis(), prendendo spunto dalle spiegazioni che realizzo per gli studenti.

Per usare millis() per la temporizzazione è necessario registrare il momento in cui un’azione si è verificata (ad esempio accensione di un LED ritardata alla pressione di un pulsante) affinché possiate iniziare a contare il tempo trascorso da tale evento, dovrete quindi controllare ad intervalli regolari se il periodo richiesto è trascorso.
Se tale intervallo di tempo non è trascorso allora il vostro programma potrà fare altro fino al prossimo controllo.

Nei programmi che seguono userò i commenti all’interno dello sketch per spiegare l’utilizzo delle varie parti del programma.

Ma cos’è millis()?

La funzione millis() restituisce il numero di millisecondi trascorsi dall’avvio del programma corrente su una scheda Arduino. Questo valore è restituito come un numero di tipo unsigned long.

Come Funziona

  • Incremento Automatico: il conteggio inizia automaticamente quando il microcontrollore sulla scheda Arduino viene alimentato o resettato. Il conteggio continua ad aumentare fino a che la scheda rimane alimentata.
  • Overflow: poiché millis() utilizza una variabile di tipo unsigned long, che ha una dimensione di 32 bit su Arduino, il valore massimo che può raggiungere è 4,294,967,295, dopo aver raggiunto questo valore, si andrà in overflow (ovvero Arduino non è in grado di memorizzare un numero più grande) e il valore restituito da millis() ripartirà da zero. Questo avviene dopo circa 49 giorni e 17 ore dall’ultimo reset della scheda.

Utilizzi di millis()

Di seguito una lista non esaustiva di alcuni utilizzi della funzione millis():

  • Temporizzazione non bloccante: a differenza di delay(), che ferma l’esecuzione del programma per un periodo specificato, millis() può essere utilizzato per realizzare pause o attese senza bloccare altre operazioni. Questo è particolarmente utile in applicazioni multitasking dove altre attività devono continuare ad essere eseguite.
  • Debounce: viene spesso usata per implementare il debounce di pulsanti o switch, riducendo gli effetti dei rimbalzi meccanici che possono causare letture multiple per una singola pressione.
  • Esecuzione di azioni a intervalli regolari: può essere utilizzata per eseguire specifiche azioni a intervalli regolari, come leggere sensori, aggiornare display, o inviare dati.

Pratica di utilizzo

Per utilizzare millis() per la temporizzazione, il vostro sketch deve conoscere il valore attuale del tempo (valore restituito da millis()) e questa rilevazione può essere fatto quando volete, in più punti dello sketch ovviamente dovrebbe essere fatta quando serve, ma vediamo cosa vuol dire.

Tipicamente il valore di millis() conviene registrarlo in una variabile ad inizio loop() o all’interno del setup() in questo modo:

millisCorrente = millis();

Regola di utilizzo:

  1. La variabile millisCorrente deve essere stata precedentemente dichiarata.
  2. Deve essere di tipo unsigned long perché millis() restituisce un intero long senza segno.

Regole generali che valgono per tutti i programmi che realizzerete, lo scrivo perchè puntualmente durante le correzioni qualcuno dimentica questa due regolette:

  1. Il nome della variabile, così come accade per tutte le variabili dovrebbe essere autoesplicativa, quindi il suo nome deve dare informazioni: “a cosa serve”
  2. Inoltre è buona regola utilizzare la notazione Camel Case per gestire nomi di variabili composte da più parole, ciò vale anche per le funzioni.

Come spesso accade durante le attività di laboratorio, lascio come semplicissimo esercizio per lo studente il desumere i componenti utilizzati e connessioni dagli sketch di esempio, quindi fate riferimento a quanto indicato in ogni singolo programma, si tratterà semplicemente di connettere dei LED con in serie un resistore da 220 Ohm. Per quanto riguarda l’ultimo esempio fate riferimento al link indicato che rimanda ad un altro post su questo sito.

Siete ora pronti per seguire le spiegazioni successive.

Continua a leggere

Visualizzare i dati inviati da un micro:bit ad un computer via seriale con un emulatore di terminale

Durante le attività di sperimentazione del mio prossimo corso sui laboratori green mostrerò l’uso di RTC per la rilevazione automatica dei dati provenienti da sensori, sarà quindi necessario leggere i dati ricevuti dal micro:bit ed inviati al micro:bit attraverso un PC via seriale USB. Per leggere le informazioni che transitano sulla seriale è possibile usare qualsiasi emulatore di terminale. Seguendo il link: Outputing serial data from the micro:bit to a computer trovate la documentazione dell’help online di microbit.org che mostra l’utilizzo di alcuni emulatori terminali per i diversi sistemi operativi.

Una modalità estremamente semplice e che vi tornerà utile anche in altre occasioni, è quella che fa uso della Serial Monitor di Arduino, vediamo di seguito come fare questa operazione.

Configurazione

Passo 1
Qualche tempo fa avevo indicato come usare l’IDE di Arduino per programmare micro:bit, seguite la procedura indicata nel link

Passo 2
Impostare la scheda

Passo 3
Impostare la porta a cui è connesso il micro:bit

Passo 4
Aprire uno sketch vuoto e fare click sull’icona Monitor Seriale

Passo 5
Impostate la velocità di comunicazione a 115200 baud

Il risultato che vedete nell’immagine è quello che deriva dalla realizzazione di un programma scritto in Blocks con l’IDE grafico di micro:bit in cui viene inviato ogni minuto sulla seriale:

  • la data della misurazione
  • l’ora della misurazione
  • la temperatura rilevata dal sensore di temperatura del micro:bit e la temperatura rilevata dal sensore disposto sull’RTC DS3231.

Ovviamente questi dati potranno essere inviati ad altri dispositivi con modalità di trasmissione diverse, tutto questo sarà approfondito durante il corso.

Buon Making a tutti 🙂

Sperimentazioni didattiche: Pair Cooperative Learning

Fonte: Wikimedia

Come molti insegnati “di una certa età” 🙂 anche io mi trovo a ricoprire la funzione di docente tutor per colleghi neoassunti e con loro devo svolgere diverse attività: osservazione, insegnamento cooperativo nel condurre la lezione e molto altro.
Come proposta di attività di sperimentazione didattica mi sono inventato in questa settimana un metodo che nasce da un suggerimento del mio amico, compagno di studi e per anni compagno di lavoro, Paolo Sasso che durante una chiacchierata mi suggeriva di sperimentare a scuola una tecnica di organizzazione della produzione del software molto interessante che suo figlio sta utilizzando durante l’attività di “stage aziendale” remunerato che gli studenti delle università inglesi svolgono al 4′ anno di corso. Nel caso specifico si tratta di una progettazione di un software industriale sviluppato in team a distanza.

La tecnica utilizzata è quella del Pair programming, trovate indicazioni seguendo il link e da cui ho tratto per scrivere questo post. Si tratta di una tecnica di produzione del software agile condotta in coppia in cui due programmatori lavorano su una sola postazione.
I due programmatori, in modo periodico ed alternato assumono le funzioni di: conducente (driver) e navigatore (navigator).
Il conducente si occupa di scrivere il codice, mentre l’osservatore svolge il ruolo di supervisore e di revisione istantanea del codice.
Il conducente ha l’obiettivo di portare a termine una soluzione funzionante del problema, mentre il navigatore si occupa di segnalare errori o proporre alternative di soluzione al conducente e come indicato sopra i due programmatori cambiano spesso ruolo.

Come utilizzare questa metodologia durante lo sviluppo di un’attività di laboratorio a scuola?

Mi sono inventato una metodologia che ho chiamato: Pair Cooperative Learning che si basa sul Pair programming e a questo ho aggiunto un metodo per gestire i momenti in cui avviene lo scambio dei ruoli il tutto calato in una realtà didattica.
In realtà chiamarla forse metodologia è troppo, ma poiché mi diverte trovare strategie nuove di insegnamento mi piace elevarla al livello di metodologia 🙂

Ho sperimentato in questa settimana con la mia classe 4A Elettronica il metodo e ne ho perfezionato oggi, documentandone precisamente le fasi di azione in un mio documento personale. Condivido con voi il pensiero anche perché questa strategia sarà quella che mostrerò al collega neoassunto e che proporrò di sperimentare in alcune sue classi da solo ed insieme a me.

Per chi mi segue, sa che utilizzo da sempre la tecnica del Pomodoro per gestire il mio tempo di lavoro e in alcune occasioni anche il tempo di svolgimento delle esercitazioni che faccio svolgere in laboratorio agli studenti.

Lo sviluppo è quindi:

  • modalità di sviluppo: Pair programming;
  • modalità di gestione del tempo di lavoro: Tecnica del Pomodoro.

Ciò vuol dire che i ruoli si scambieranno ogni 25 minuti di attività in modalità Pair programming seguiti da 5 minuti di pausa vera in cui gli studenti devono riposare. Nei 25 minuti di lavoro in Pair programming non devono esserci distrazioni, quindi vietato chiedere: “Prof. posso andare a prendere un caffè?”, “Prof. posso andare al bagno?”, è vietato utilizzare smartphone e smartwatch, quindi bisogna allontanarli, non in tasca altrimenti si può venir distratti dalla vibrazione delle notifiche, ma riponendoli sulla cattedra o nello zaino personale.
Allo scadere dei 25 minuti ci saranno 5 minuti di pausa vera in cui riposarsi o andare al bagno.
Durante i 25 minuti non è possibile rivolgere domande al docente sulla svolgimento dell’attività, a meno che non si tratti di problematiche tecniche non conosciute dagli allievi. Dopo 4 pomodori (4 momenti lavorativi da 25 minuti) gli studenti sono obbligati a svolgere 15 minuti di pausa.

Per svolgere questa attività, adesso che sono in fase di sperimentazione, mi concentrerò su attività di laboratorio che possono essere iniziate e concluse in 2 o 3 ore continuative di lavoro.

Vantaggi rilevati:

  • concentrazione;
  • riduzione della distrazione;
  • capacità di suddivisione dei momenti produttivi da quelli di riposo;
  • imparare, a lungo termine, a valutare quanti “pomodori” sono necessari per svolgere una specifica attività;
  • percepire che si è protagonisti del proprio apprendimento;
  • percepire di aver risolto un problema;
  • cooperare con compagni di classe che solitamente non si sceglie per studiare e lavorare.

La formazione delle coppie di lavoro può avvenire in diverse modalità e sarà funzione sul livello di competenze raggiunto da ogni singolo allievo, pertanto potrà avvenire:

  • in modo casuale per ogni esercitazione e la casualità la si può ottenere con un programma facendo attenzione che in ogni esercitazione si formino sempre coppie diverse;
  • a scelta da parte del docente scegliendo in funzione delle competenze degli studenti.

Per velocità di sperimentazione questa settimana la scelta delle coppie di studenti è stata fatta da me ed un’altro collega.

Applicherò questa strategia venerdì prossimo nella mia 5B Automazione in cui gli studenti dovranno risolvere un problema di automazione mediante l’uso di PLC Siemens. L’attività, nei primi 25 minuti, prevederà un’analisi del sistema mediante lo sviluppo di un diagramma di flusso e nei successivi 25 minuti la produzione del codice in LADDER o FBD dell’automazione che dovrà essere poi simulata. La conclusione deve avvenire durante due ore di lezione.

Il metodo ovviamente è applicabile anche ad altri livelli scolastici, potrebbero essere ad esempio lo sviluppo di un’attività di Storytelling con Scratch 3 per allievi di scuola media o dei primi anni delle superiori, o ancora potrebbe essere un’attività non informatica in cui il processo può essere condotto in Pair Cooperative Learning.

Spero che questa mia sperimentazione possa essere utile anche ad altri colleghi e nel caso di vostre variazioni e migliorie vi chiedo la cortesia di comunicarmele in modo che a mia volta possa adottarle nelle mie classi.

Grazie Paolo per il suggerimento.

Buona didattica a tutti 🙂