UDA 6 — Progetto finale (verifica n. 4)

A coppie · Durata: 3 ore + lavoro nelle ore di laboratorio della UDA 5 Consegna: sorgente .asm commentato + relazione (max 2 pagine) + demo di 5 minuti + colloquio Punteggio: 10 punti — 30% della valutazione finale

Nota per il docente: la verifica è di tipo progettuale. Le proposte si assegnano (o si concordano) entro la settimana 11; la settimana 12 serve per completamento, demo e colloqui. Le due proposte più guidate sono la 1 e la 4 (hanno un esempio di riferimento completo nel menu esempio del simulatore): usale per le coppie che hanno bisogno di più appoggio, oppure come modello da modificare per le altre.

Consegna

Ogni coppia sceglie una proposta (o ne propone una equivalente, da concordare col docente entro la settimana 11) e consegna:

1. il sorgente .asm (scaricato dal simulatore) commentato, con intestazione completa;
2. la relazione (max 2 pagine) secondo il modello qui sotto;
3. la demo al simulatore (5 minuti, percorso di prova preparato);
4. il colloquio sul proprio codice (2-3 minuti a coppia).

Requisiti minimi (promemoria)

• ≥ 2 periferiche diverse usate davvero;
• ≥ 1 device in interrupt (timer, counter o keypad), con vettore < 0x80, I, im 2, ei, servizio con registri salvati, ei e reti;
• ≥ 1 subroutine con contratto documentato (ingressi / uscite / registri modificati);
• il programma principale continua a lavorare durante gli interrupt;
• casi limite provati e descritti nella relazione.

---

Proposta 1 — Colonna luminosa

Periferiche: keypad 0x80/0x81 · LED 0x20 · display 7 segmenti 0xA0 · timer 0x70/0x71

Cosa deve fare

• l’utente digita sul keypad una cifra 0-F (mostrala intanto sul display 7 segmenti 0xA1, così si vede il valore scelto);
• la “colonna” conta da 0 fino a quel valore sui LED (e su 0xA0), poi riparte da zero;
• il ritmo del conteggio arriva dal timer in interrupt IM2; il main resta libero di leggere il keypad.

Percorso di prova (osservabile)

1. da Reset, i LED non si muovono finché non premi un tasto;
2. premi 3 → i LED contano 1, 2, 3, 0, 1, … senza superare 3;
3. premi F → il conteggio arriva a 15 e riparte;
4. dimezza la costante del timer (0x10 → 0x08) → il ritmo raddoppia;
5. premi 0 → la colonna resta a zero.

Casi limite: target 0; tasti premuti in rapida sequenza; timer con costante 0x01.

Appoggio: esempio 11-progetto-colonna-luminosa.asm (stesso schema: da adattare, non copiare; cambia almeno la periferica di visualizzazione o aggiungi il secondo display).

---

Proposta 2 — Contalattine

Periferiche: counter/nastro 0xE0/0xE1 · motore 0xB0 · LCD 0xD0 · LED 0x20

Cosa deve fare

• il counter genera un interrupt ogni N passi del nastro (scegli tu N e giustificalo);
• a ogni interrupt il motore avanza di un passo e un contatore in memoria aumenta;
• l’LCD mostra il totale in cifre decimali (subroutine di conversione!);
• i LED mostrano il totale in binario (o lo stato di “in marcia”);
• il main può fermare/riprendere col primo interruttore (0x90, bit 0).

Percorso di prova (osservabile)

1. avviato il nastro, il totale sull’LCD aumenta e il motore avanza;
2. interruttore 0 = OFF → il conteggio si ferma e il motore resta fermo;
3. il totale in binario sui LED corrisponde alle cifre sull’LCD (prova con 3, 10, 16…).

Casi limite: totale 0 e “riporto” a due cifre (9 → 10); totale oltre 99 (usa almeno 3 cifre o dichiara la scelta); interruttore mosso durante l’interrupt.

Appoggio: esempio 09-motore-counter.asm (counter + motore) + esempio 05-lcd-messaggio.asm (OTIR verso LCD). La novità è la conversione binario → ASCII del totale.

---

Proposta 3 — Forno controllato

Periferiche: kiln 0xF0/0xF1 · potenziometro 0x40 · chart 0x30..0x33 · timer 0x70/0x71

Cosa deve fare

• il potenziometro fornisce il setpoint (temperatura desiderata);
• il riscaldatore (0xF1, bit 0) si accende/spegne confrontando la temperatura (0xF0);
• un timer in interrupt campiona: a ogni interrupt legge temperatura e setpoint, aggiorna il riscaldatore e scrive il campione sul chart (0x30); il main aggiorna l’LCD con i valori;
• i marker 0x31/0x32 segnano sul grafico gli eventi “riscaldatore ON/OFF”.

Percorso di prova (osservabile)

1. setpoint basso → il riscaldatore resta spento, il chart è piatto;
2. setpoint alto → il riscaldatore si accende, la curva sale e poi si stabilizza;
3. alza/abbassa il setpoint durante l’esecuzione → la curva cambia pendenza.

Casi limite: setpoint uguale alla temperatura; kiln già caldo al Reset; interrupt molto frequenti (il servizio deve restare breve: fai il minimo, il resto nel main).

Appoggio: esempio 10-kiln-chart.asm (kiln + chart, in polling) — qui la difficoltà è portare il campionamento in interrupt e separare servizio/main.

---

Proposta 4 — Pianola

Periferiche: keypad 0x80/0x81 · beeper 0x60 · LCD 0xD0

Cosa deve fare

• il keypad in interrupt segnala la pressione; il servizio legge il tasto e lo lascia in una casella in memoria (mailbox) — lavoro breve;
• il main consuma la casella: aggiunge la nota alla melodia e la mostra sull’LCD;
• ogni nota produce un beep con una pausa calibrata (le note basse durano di più);
• il tasto F riproduce tutta la melodia (con una subroutine nota riusata);
• quando la melodia è piena (16 note), i tasti nuovi non la allungano più (e lo si vede).

Percorso di prova (osservabile)

1. premi 5 → compare 5 sull’LCD e si sente un beep;
2. premi 2, poi 0 → la melodia cresce sull’LCD, note con durate diverse;
3. premi F → risentì l’intera sequenza e l’LCD non cambia;
4. “svuota” (a scelta: un tasto E cancella la melodia) → F non suona nulla.

Casi limite: F con melodia vuota; 17ª nota; tasti premuti durante la riproduzione.

Appoggio: esempio 12-progetto-pianola.asm (schema mailbox, subroutine aggiungi, ascii, nota). Estensioni: tasto “cancella”, ottava più alta sul secondo display, ecc.

---

Proposta 5 — Proposta libera

La coppia propone un sistema di controllo che integri ≥ 2 periferiche e ≥ 1 device in interrupt, entro la settimana 11. Servono: una traccia scritta di mezza pagina (obiettivo + periferiche + comportamento), l’approvazione del docente, e poi la stessa consegna delle altre proposte. Verranno valutati anche l’originalità della proposta e la chiarezza dei requisiti.

---

Modello di relazione (max 2 pagine)

# Progetto: <nome>            Coppia: <nome1> - <nome2>, <classe>

## 1. Obiettivo
Cosa fa il sistema, in 3 righe.

## 2. Schema delle porte
| Periferica | Porta | Direzione | Uso |

## 3. Architettura
Chi fa cosa: main, servizio, stato condiviso. Diagramma a blocchi
(evento → servizio → stato → main → uscita).

## 4. Prove e collaudo
Checklist dell'unità con esito + casi limite provati.

## 5. Difficoltà e soluzioni
Almeno due problemi veri e come li avete risolti.

## 6. Possibili sviluppi (facoltativo)

---

Colloquio

2-3 minuti a coppia, sul proprio listato. Domande tipiche:

• Mostratemi il servizio: perché avete salvato proprio quei registri?
• Cosa succede se il tasto resta premuto / se non arriva mai l’interrupt?
• Dov’è lo stato condiviso tra main e servizio? Perché non in un registro?
• Cosa cambia se la costante del timer passa da 0x10 a 0x40?
• Perché qui avete usato il polling e là l’interrupt?
• Cosa fa questa istruzione? (indicata a caso nel listato)

---

Griglia di correzione

Indicatore	0	1-2	3-5	Punti
Funzionamento	non funziona	funziona in parte / con aiuto	funziona come richiesto	4
Periferiche e interrupt	nessuno	1 periferica, nessun interrupt	2 periferiche di cui 1 in interrupt, main attivo	3
Codice e documentazione	illeggibile / assente	poco commentato, relazione minima	chiaro, commentato, contratto delle subroutine, relazione completa	2
Colloquio	non risponde	parziale	risponde leggendo il codice, spiega le scelte	1

(Totale: 4 + 3 + 2 + 1 = 10. Il docente può riconoscere fino a +1 per una gestione solida dei casi limite o per una proposta libera ben motivata, senza superare 10.)

Criteri minimi di sufficienza (5/10): il programma assembla ed esegue senza errori; usa almeno una porta di ingresso e una di uscita; il progetto integra almeno 2 periferiche; la coppia sa spiegare i blocchi principali del proprio codice.

---

Note per il docente

• Formazione delle coppie: alterna chi ha più autonomia; suggerisci la proposta 1 o 4 alle coppie in difficoltà e la 2 o 3 a quelle più sicure. La proposta 5 premia chi si è distinto.
• Verifica tecnica rapida: i due schemi di riferimento (timer → LED/display; keypad → mailbox → LCD/beeper) sono coperti dai test tests/progetto-e2e.test.ts: se la classe usa il simulatore, il comportamento atteso dei modelli è già garantito. Puoi chiedere di modificare un parametro di un esempio di riferimento e prevederne l’effetto.
• Osservazione in laboratorio: valuta la scheda di debug (dove sono / cosa mi aspettavo / cosa vedo) e la rotazione dei ruoli nella coppia: sono gli indicatori dell’autonomia.
• Demo: anche una demo incompleta ma spiegata (con il punto esatto in cui si blocca e un’ipotesi di causa) va riconosciuta: è il metodo che stiamo insegnando.