Tabellone Elettronico

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:

  1. dimensione contenuta, portabile a mano
  2. tastiera di interfaccia economica (eventualmente sostituibile)
  3. visibile da distante (almeno dalle tribune)
  4. deve ammettere possibilità di errore (cavi scollegati, errata pressione tasti)
  5. semplice da usare
  6. 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.

 

 

Schema generale

Uno schema di massima del progetto è riportato in figura

Schema generale

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.

 

Software&Hardware

Il programma caricato dentro la memoria Flash del ATmega16 è schematizzabile in due "processi" separati, a diversa priorità:

  1. 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
  2. routine di gestione del cronometro; la priorità maggiore è gestita attraverso interruzioni al flusso principale lanciate ogni secondo di gioco attraverso l'overflow del Timer2

Flusso del programma

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:

  1. conversione da protocollo PS/2
  2. comunicazione con periferica SPI verso i display
  3. gestione interrupt provenienti dal Timer2
  4. 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:

volatile uint8_t secondi, minuti;
volatile uint8_t punti_casa, punti_ospiti, falli_casa, falli_ospiti, periodo;
volatile uint8_t in_gioco;

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

void scrivi(uint8_t display, uint8_t valore)

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

scrivi(DISP_SECONDI_UNITA, secondi % 10);
scrivi(DISP_SECONDI_DECINE, secondi / 10);

 

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)

 

Scarica subito una copia gratis

7 Commenti

  1. Avatar photo acvin 25 Aprile 2012
  2. Avatar photo acvin 25 Aprile 2012
  3. Avatar photo acvin 24 Aprile 2012
  4. Avatar photo slovati 24 Aprile 2012
  5. Avatar photo telegiangi61 24 Aprile 2012
  6. Avatar photo pasweb 6 Febbraio 2014
  7. Avatar photo Davide Spigolon 27 Gennaio 2016

Scrivi un commento

Seguici anche sul tuo Social Network preferito!

Send this to a friend