Tabellone BastArcola
Idea
L'idea iniziale è legata ad una necessità mista a sfida: costruire un segnapunti elettronico per le partite di casa della mia squadra, partecipante al campionato UISP di pallacanestro.
Le specifiche sono semplici, legate a limiti di costo:
- dimensione contenuta, portabile a mano
- tastiera di interfaccia economica (eventualmente sostituibile)
- visibile da distante (almeno dalle tribune)
- deve ammettere possibilità di errore (cavi scollegati, errata pressione tasti)
- semplice da usare
- e perchè no, anche presentabile.
Nonostante l'ambito specifico di progetto, le soluzioni adottate sono riutilizzabili per altri scopi
ad esempio:
- la modalità di comunicazione con i display può essere riutilizzata in un generico tabellone luminoso, anche alfanumerico (si veda sezione su display LCD)
- anche per sport diversi dalla pallacanestro
- con un numero maggiore di display (limitato dalle uscite del demux, ma all'occorrenza espandibili)
- etc..
Di seguito cercherò di riportare le varie fasi di progetto, seguendo (più o meno) l'ordine temporale in cui sono state eseguite.
Si parte da uno schema a blocchi di principio, dove verranno analizzate le prime problematiche da affrontare e soprattutto la separazione del flusso di lavoro in tre aree: una prima di sviluppo software per il uC, una seconda puramente hardware, legata allo sviluppo dei ciruiti stampati e al conseguente lavoro di saldatura; una finale di costruzione e assemblaggio dell'involucro esterno (molto importante, visto l'utilizzo in un ambiente "ostile").
La struttura in legno e Plexiglass non è stata realizzata da me, ma da due altri componenti della squadra, molto più esperti di me nel bricolage, Marcello e Giacomo.
Uno schema di massima del progetto è riportato in figura
Al centro della figura, viene utilizzato un microcontrollore Atmel ATmega16 con incarichi di:
- gestione tempo (effettuata con precisione grazie ad un quarzo esterno "da orologio")
- comunicazione attraverso protocollo PS/2, utilizzato dalle comuni tastiere per PC
- controllo e aggiornamento valori su display 7 segmenti e interfaccia al tavolo (su LCD)
- segnalazione fine tempo attraverso sirena bitonale
Le comunicazioni sono gestite attraverso un bus seriale sia per quanto riguarda l'interfaccia a schermo, sia per la comunicazione con la tastiera PS/2.
I display sono a 7 segmenti, di due diverse dimensioni: per i punteggi e il tempo sono da 5", mentre per il periodo e falli da 3.5".
La dimensione "maggiorata" è necessaria per avere una buona visibilità, ma porta con se due aspetti "scomodi" (rispetto a un display 7seg standard da 0.5"): una maggiore tensione di alimentazione e (in conseguenza) maggior consumo.
L'immagine a lato riporta lo schema interno di singoli segmenti (A,B, ..etc); ogni singola barra è formata da 5 led rossi in serie, portando la soglia minima di accensione a circa
2,2 (caduta per ogni led) x 5 = 11V
ed un consumo, nel caso peggiore (tutte le cifre accese degli 11 display) di
7 (segmenti) * 11 (display) * 20mA (dato indicato dal produttore) = 1,54A
Questo ha reso necessaria la ricerca di una sorgente di alimentazione capace di erogare almeno 2A ad una tensione maggiore di 12V; la scelta è caduta su un alimentatore per portatile ASUS, con uscita a 19V e 4A max (va bene anche un qualsiasi altro alimentatore switching, con stesso amperaggio e tensione non inferiore ai 15V).
Per quanto riguarda il display LCD da tavolo, è stato utilizzato un dispositivo HD44780-compatibile, su display alfanumerico a 16 caratteri su due righe, retroilluminato. La configurazione è effettuata tramite un bus parallelo su 8bit e 3 segnali di controllo R/W, CS, D/I.
Il programma caricato dentro la memoria Flash del ATmega16 è schematizzabile in due "processi" separati, a diversa priorità:
- flusso principale di di gestione dell'interfaccia a tastiera, interrompibile attraverso Interrupt. Si occupa del controllo della periferica USART integrata nel microcontrollore e dell'eventuale aggiornamento dei dati in memoria
- routine di gestione del cronometro; la priorità maggiore è gestita attraverso interruzioni al flusso principale lanciate ogni secondo di gioco attraverso l'overflow del Timer2
In rosso sono riportate le funzionalità di maggior importanza, quali la gestione della seriale e l'aggiornamento dei display a 7 segmenti attraverso l'interfaccia SPI-demultiplexer.
Nel complesso il software è suddiviso in 4 sezioni:
- conversione da protocollo PS/2
- comunicazione con periferica SPI verso i display
- gestione interrupt provenienti dal Timer2
- aggiornamento dati di gioco (punteggi, falli, tempo, ...)
1. Conversione da protocollo PS/2
Il protocollo PS/2 rientra nella categoria delle comunicazioni seriali sincrone; l'invio dei dati è effettuato serialmente su un unico pin di IO (SDA) e sincronizzato da un segnale di clock (SCL) generato dallo slave, in questo caso la tastiera.
Ogni pacchetto è formato da 8bit dati, 1bit di parità, 1bit di stop.
In rete ho trovato soluzioni puramente software, ovvero l'acquisizione del singolo bit è regolata direttamente dalla CPU, magari a seguito di un interrupt hardware all'inizio della trasmissione.
Per non introdurre ritardi nella gestione del cronometro, ho preferito una versione che fa uso della periferica interna USART, configurata in modalità Seriale Sincrona (da questa funzionalità deriva la S in USART).
In questo modo, l'intero pacchetto di 8bit trasmesso dalla tastiera è caricato nel registro UDR, contemporaneamente ne viene verificata la parità, il tutto senza alcun intervento della CPU.
Ciclicamente il programma controlla il bit RXC, di completamento ricezione, se attivo il contenuto di UDR è il codice identificativo del tasto premuto.
L'ultimo passo da eseguire è il confronto del codice con una tabella di conversione, per capire quale sia l'azione da svolgere associata ad un determinato tasto. In questo caso vengono utilizzati solamente i tasti del tastierino numerico, mappati in questo modo:
La gestione del protocollo PS/2 è più complessa di quanto illustrato qui sopra, per chi volesse approfondire rimando al link IBM (azienda sviluppatrice originale) riportato in fondo.
Riporto di seguito alcuni aspetti importanti del protocollo e le loro implicazioni sul software:
- all'avvio la tastiera invia un codice di "completamento inizializzazione" (BAT), da gestire via software perchè non corrisponde ad alcun tasto premuto (il BIOS dei PC non gestisce questo aspetto, infatti se si scollega la tastiera PS/2 spesso occorre riavviare il sistema per riutilizzarla)
- se il tasto viene mantenuto premuto, la tastiera continua ad inviare lo stesso codice (con frequenza impostata di default a 50ms), mentre al rilascio viene inviata la sequenza "0xF0" "0xcodicetasto". Il software deve poter distinguere pressione e rilascio del tasto; in pratica riconosce come valida solo la prima pressione, mentre attende il suo rilascio per tornare ad ascoltare nuovi comandi da tastiera.
- E' possibile anche inviare dati alla tastiera, per scrivere nei registri di configurazione interni o per accendere i led presenti (BLOC NUM, ...). Questa funzionalità non è utilizzata, ma sarebbe gestibile anch'essa dalla periferica USART, configurata come master in una comunicazione seriale sincrona
2. Comunicazione con periferica SPI verso i display
Il microcontrollore ATmega16 prevede un massimo di 32 I/O, mentre solo l'utilizzo degli 11 display a 7 segmenti richiederebbe l'uso di 77 pin di uscita (per non parlare dei pin aggiuntivi per la tastiera, la sirena e LCD da tavolo).
La soluzione adottata è di utilizzare un registro a caricamento seriale ad uscita parallela (SIPO), comandato dalla periferica interna SPI. Il caricamento avviene serialmente, sfruttando la velocità della periferica (lasciata al massimo della velocità, 4Mbit/s, ovvero la metà del clock di sistema) senza alcun aggravio di tempo per la cpu durante la trasmissione.
Per l'estensione del concetto agli 11 display + LCD si è utilizzato il medesimo schema, con l'introduzione di un decoder, in fuzione Demultiplexer. Così facendo il flusso dati dalla SPI può essere "incanalato" verso uno specifico dispositivo, mantenendo inalterato il contenuto degli altri registri non abilitati.
La figura sottostante rappresenta il funzionamento del sistema di comunicazione SPI nel suo complesso:
La parte in viola rappresenta l'operazione di demultiplexing del solo segnale di clock.
Il segnale dati MOSI è a comune con tutti i registri, mentre l'indirizzamento del segnale SCK consente di modificare lo stato di un registro alla volta, mentre gli altri mantengono il valore caricato precedentemente.
Questo aspetto è importante perchè consente di aggiornare un singolo display alla volta, con gli altri accesi sull'ultimo valore inserito. L'operazione di caricamento può quindi avvenire in maniera sequenziale, magari aggiornando solo i display per i quali il dato in memoria ha subito un aggiornamento (per esempio il tempo che scorre, l'incremento di un punteggio, etc..).
A questo punto si capisce il perchè della sezione critica inserita nel diagramma di flusso del software:
una volta che la scrittura è abilitata su un dispositivo, ad esempio il Display3, viene configurato il demux per indirizzare SCK verso il registro a scorrimento numero 3; a questo punto parte la trasmissione.
Se un interrupt viene lanciato in questo momento, verrebbero modificati i bit di indirizzamento del demux quando ancora l'invio dei dati verso il Display3 non è completato.
La sezione critica prevede la disabilitazione degli interrupt durante il singolo trasferimento tramite periferica SPI; in tutti gli altri casi, un eventuale interrupt rallenta semplicemente il funzionamento ma non pregiudica la congruenza dei dati.
LCD tavolo
Per la comunicazione con l'LCD alfanumerico è stata utilizzata la stessa procedura SPI-ShiftRegister, con l'unica aggiunta di 3 pin di cui 2 dedicati al controllo del HD44780 montato sulla scheda esterna.
Unica variante, rispetto al controllo dei 7 segmenti, è legata alla distinzione tra SRCK e RCK sul registro a scorrimento.
Quando il registro viene caricato attraverso il bus SPI, le uscite non "seguono" il valore temporaneo durante il caricamento, ma mantengono il valore precedente. Al termine del pacchetto da 8bit dalla SPI, viene inviato un impulso sul pin RCK e il contenuto del registro è imposto sulle uscite.
note sui componenti utilizzati
Il supporto delle correnti e tensioni richieste dai display a 7 segmenti, 20mA a 13V, sono tali da non poter essere sostenute da componenti standard, a questo scopo sono utilizzati componenti della serie TPIC6B595, shift register di potenza realizzato da Texas Intruments anche in package PDIP a 20pin.
In uscita offrono un dispositivo open-drain che può supportare 50V e fino a 150mA, con una Ron di circa 8ohm, perfetto quindi come sink di corrente controllato (non può erogare ma solo assorbire).
Nel display LCD invece è necessario un dispositivo simmetrico in uscita, per poter imporre valore logico 1 o 0 senza pull-up esterni. L'utilizzo di un "normale" 74HC595 è perciò consigliabile (non deve erogare corrente significativa.
3. Gestione interrupt Timer2
Il corretto scorrimento del tempo è gestito attraverso il Timer2 configurato in modalità asincrona (registro ASSR), con clock esterno quarzato da 32768KHz.
Con il prescaler abilitato con divisione per 128, si ottiene un overflow del Timer2 ogni:
All'overflow del timer2 (T2_OVF) viene lanciato il vettore di interrupt in modo da aggiornare il tempo in memoria e sui display.
Eventuali istanti a tempo fermo sono gestibili attraverso il controllo di una variabile booleana in_gioco, che agisce disabilitando il prescaler del Timer2, ovvero ferma il conteggio verso l'overflow. (il timer viene arrestato, ma il contenuto attuale del TCNT2 resta invariato per tenere memoria del tempo trascorso).
4. Aggiornamento dati di gioco
Le informazioni sui dati di gioco sono mantenute in memoria attraverso variabili globali, con attributo volatile dovuto all'utilizzo di interrupt. Ad esempio, sono mantenute in memoria:
Ad ogni variabile sono associati 2 display a 7 segmenti, uno per le decine, uno per le unità (ecetto periodo, che su singolo display). Il caricamento su display è gestito tramite una funzione dedicata
dove come argomenti troviamo: il display sul quale scrivere, semplicemente un numero che identifica il display (legato alle connessioni sul demux) e valore che è il numero da mostrare (intero a 8bit).
Un esempio di utilizzo può essere il seguente
Aggiornamento dei secondi in due trasmissioni distinte, per decine e unità. Lo stesso metodo è applicabile per tutte le altre variabili.
Sviluppo PCB
Viste le dimensioni del tabellone, è impensabile realizzare tutto su un'unica scheda che comprenda logica di controllo e di potenza per i display.
Il problema è stato separato in moduli di dimensione ridotta, specializzati su una determinata funzione:
sono state realizzate 11 schede modulo7seg 5x5 cm per il controllo del 7 segmenti, da montare direttamente dietro ogni display e una modulocentrale 5x10 cm per la logica di controllo.
Di seguito i rendering su kicad delle schede
Sulla sinistra ATmega16 (DIP40) sulla destra il 74HC154 (decoder DIP20)
Costuzione e assemblaggio
Il lavoro di saldatura delle schede, per come sono state realizzate, non è stata sicuramente la più semplice. Tra schede, connettori a LCD, componenti sono circa 500 le saldature da realizzare..
Di seguito sono riportate le varie fasi di lavoro (in allegato trovate alcune foto aggiuntive)
ecco le 11 schede modulo7seg e la modulocentrale
Su alcune sono già montate le resistenze utilizzate per imporre una tensione di 20mA nei singoli segmenti dei display
Saldature da realizzare per ogni modulo
modulo7segmenti in confronto ad un display 7seg "piccolo" da 3 pollici
Inizia il collegamento delle schede sul retro della struttura.
E finalmente una vista frontale del lavoro...
Per finire, un'immagine del modulo ancora in fase di test, LCD per i dati al tavolo
Ad oggi...
Il "tabellone" è stato inaugurato il 20 gennaio 2012 e tutt'ora segue tutte le partite di casa del BastArcola...
Approfondimenti
Protocollo PS/2 ---> link esterno
TPIC6B595 ---> datasheet
A breve vorrei approfondire alcuni aspetti del progetto, come software, costruzione e altro, sul mio sito personale acvin.it
(non approfonditi qui per motivi di spazio)
E’ un aspetto al quale non avevo pensato, vista la necessità di rendere visibili al massimo i display dalle tribune.
Anche in questo caso è possibile aggiungere questa funzionalità, appunto gestendo con una PWM tutti i pin G dei TPIC595.
Con l’aggiunta di due tasti “controllo luminosità” su tastiera, si regola il consumo-luminosità.
In un ambito diverso dallo sport è sicuramente una funzionalità necessaria! (con una piccola modifica ai PCB per gestire anche il pin G).
Grazie dell’appunto
Certo, è possibile in teoria avere tempi fino 99′ e 99″, e 9 frazioni di gioco.
Magari aggiungendo una funzionalità da tastiera, come un tasto di “selezione sport”.
Il conteggio di default è alla rovescia (per l’uso nel basket), anche in questo caso è facilmente configurabile nei due sensi (magari sfruttando il tasto “selezione sport”).
Ciao,
il prezzo è legato prevalentemente ai display 7 segmenti (8 da 5″ e 3 da 3.5″) e alla realizzazione dei PCB.
Si aggira attorno ai 140€, considerando tutta la componentistica utilizzata (ATmega16, TPIC6B595, regolatori, alimentatore).
I display li ho trovati da un rivenditore su Ebay, cercando sotto “7 segment display 5”
Ottimo progetto, complimenti. Mi chiedevo se è possibile modificare la durata di ogni tempo di gioco per adattarla a altri sport, potendola selezionare prima di avviare il contatempo (as es. per la pallamano si usano tempi da 20, 25, o 30 minuti, a seconda della categoria o età). Si può anche prevedere un conteggio alla rovescia?
Ciao, complimenti per la realizzazione, molti anni fa mi occupavo di farne di simili a display o a matrice di led, anche RGB e il problema dell’assorbimento massimo si affrontava modulando il pin di Enable dei 595 (io usavo gli hc595 uniti ai line driver uln2004) in PWM (in genere da 25 a 100hz), magari anche con un semplice 555 come multivibratore astabile, vedi http://it.emcelettronica.com/il-555-duty-cycle-variabile-linearmente-si-presta-le-funzioni-pwm.
Rimanendo sul tuo progetto pilotando i pin G dei TPIC595 con un pin dell’ATmega configurato come output PWM sarebbe possibile ridurre l’assorbimento ed eventualmente ridurre la luminosità del pannello con un paio di tasti speciali della tastiera PS/2.
Realizzando pannelli informativi o di emergenza, anche in ambienti aperti, spesso per mantenere costante entro certi limiti la loro luminosità, si modulava il PWM attraverso una fotoresistenza che dava informazioni sull’ambiente (pieno sole, cielo coperto, nebbia, buio etc).
Ciao, ho apprezzato molto il tuo articolo. Complimenti!
Dovrei realizzare un tabellone simile per la società di pallavolo in cui gioca mio figlio.
Mi invieresti gli schemi elettrici del progetto?
grazie mille
Pasquale
Mi invieresti gli schemi elettrici del progetto?