Il circuito presentato è studiato per trenini Märklin, ma modificabile per adattarlo a tipologie diverse. Come vedremo, la parte di alimentazione è pensata per la corrente alternata, la modifica per adattarla a corrente continua richiede poco e, anzi, permette di ridurre le dimensioni ed il numero di componenti.

Il vantaggio che deriva da questo progetto lo si vede principalmente nel numero di cavi con cui abbiamo a che fare nel cablaggio dell’impianto. A differenza del metodo tradizionale, per cui dobbiamo prevedere 3 fili dalla centrale di comando ad ogni dispositivo (eventualmente riducibile a 2), con un circuito digitale riusciamo ad utilizzare tre soli fili comuni a tutti i dispositivi controllati. Oltre ai due di alimentazione, il terzo filo è quello su cui viaggiano i dati.

Il formato in cui vengono trasmessi i dati prevede di inviare le informazioni relative a quale operazione e quale dispositivo è chiamato a reagire.

Il funzionamento
Il controllo avviene tramite una centralina a disposizione dell’operatore (il modellista che si diverte con locomotive e trenini vari).
Ogni dispositivo viene poi controllato direttamente da un decodificatore. Il decodificatore è collegato in ingresso al BUS di comunicazione (i tre fili che partono dalla centralina) e in uscita direttamente allo scambio da controllare.
Siccome tutti i decoder sono collegati insieme, deve essere individuato un sistema per fare in modo che ciascuno riconosca il comando a cui deve rispondere. Per questo ad ogni decodificatore verrà assegnato un codice (indirizzo). Parliamo poi di “comando” per identificare l’azione che vogliamo controllare. Usando sempre lo scambio come esempio, i comandi sono due: dritto e storto.
Quando l’operatore decide di girare uno scambio, dalla centralina parte un messaggio (che arriva a tutti contemporaneamente) che contiene l’indirizzo ed il comando. In questo modo il decoder confronta l’indirizzo con il proprio e, in caso di corrispondenza, esegue il comando.
Nella realizzazione qui descritta ho implementato un protocollo seriale che prevede un solo byte per l’indirizzo. Questo significa che si possono controllare fino a 255 dispositivi differenti. In caso non siano sufficienti, si può modificare il protocollo. 2 byte estendono a 65535 il numero di dispositivi.

La centralina
La centralina è costituita da una tastiera numerica ed un display a 4 cifre. Ho utilizzato display a 7 segmenti per rendere il numero più visibile e sicuramente più “in stile” con il plastico di come sarebbe stato con un LCD, ma nessuno impedisce di fare diversamente. In questo modo va interpretata la lettura nel modo seguente: le prime tre cifre rappresentano l’indirizzo, la quarta il comando.

Esempio: se chiamiamo 1 il comando “dritto” e 7 “storto”, per raddrizzare lo scambio identificato dell’indirizzo 56, dovremo visualizzare 0561 sul display (056 indirizzo + 1 comando). Visualizzato il numero corretto, si preme “invia” e il messaggio parte dalla centralina.
Nella foto è visibile lo schema a blocchi della centralina. Oltre a quanto descritto, vi è solo l’alimentatore.

Il decodificatore
Lo schema elettrico del decodificatore è visibile qui sotto. La scelta è stata quella di dotare ogni decodificatore di un alimentatore in grado di abbassare a 5v la tensione per il microcontrollore. In questo modo si riescono ad utilizzare solo i tre fili, due dei quali sono comuni con le alimentazioni delle bobine degli scambi. Da 16 a 5 si ottiene una buona stabilizzazione per il PIC anche semplicemente alimentando tramite diodo zener e condensatore il controllore.
Siccome le dimensioni del decodificatore sono davvero contenute (tutto realizzato con componenti SMD), l’aggiunta di 3 componenti non crea grossi problemi. In alternativa, per ridurre ulteriormente le dimensioni, si può prevedere un’uscita a 5v dalla centralina e aggiungere un filo al BUS.
Il jumper serve per l’assegnamento dell’indirizzo. Il decoder funziona normalmente a contatto aperto (senza jumper). Quando presente, il decoder risponde come se avesse indirizzo 0. Dalla centralina è possibile mandare il comando 0 all’indirizzo N, che vene trasmesso come comando N all’indirizzo 0 e interpretato dal decoder che risponde a 0 come comando di assegnamento indirizzo. L’indirizzo viene memorizzato in EEPROM, quindi mantenuto anche a circuito non alimentato.

A circuito nuovo, va quindi fatto un lavoro di assegnamento indirizzo a tutti i decodificatori. Per comodità si può eseguire questa operazione non necessariamente con i decodificatori montati sul plastico, ma tenerceli comodamente a portata di mano (è più facile mettere e togliere il jumper). Rispetto alla soluzione spesso adottata dei DIP switch, questo metodo permette di ridurre dimensioni e costi del decoder. Visto che ormai il 12F519 costa circa 20 centesimi ed è dotato di memoria Eprom, si riesce a realizzare il decoder con i pochissimi componenti come mostrato nello schema per un costo totale inferiore all’euro!
Idee aggiuntive.
Vediamo ora alcuni spunti per ulteriori implementazioni o estensioni del dispositivo.
Si possono costruire decodificatori destinati a controllare altri dispositivi, in modo per esempio di controllare tramite relè l’illuminazione del plastico, o azionare automatismi come i motorini che muovono gru, piattaforme o altro.
In alternativa al PIC 12F519, per il decodificatore si può utilizzare un controllore con più piedini di uscita, in modo da controllare più di uno scambio con lo stesso decoder.

I problemi da affrontare
La scelta non è dettata esclusivamente dal linguaggio in termini di formalismo e sintattico (altrimenti immagino che tutti andrebbero sul BASIC senza troppi dubbi). Le problematiche da affrontare riguardano
– l’ottimizzazione del codice scritto in termini di risorse impiegate (memoria RAM, Program memory, tempi di esecuzione)
– il controllo diretto delle componenti a basso livello (registri, funzionalità speciali,…)
– il controllo diretto sui tempi di esecuzione necessario quando si lavora in real time
– la gestione della memoria
– la riusabilità del codice scritto e la sua portabilità su controllori differenti
– l’ergonomia nella scrittura del codice

Cosa fa un compilatore

“Il compilatore si occupa di tradurre in codice binario (o codice macchina) il programma scritto nel linguaggio che esso interpreta”. Questo è quello che macroscopicamente si associa al concetto di compilatore. In realtà un buon compilatore fa molto di più, soprattutto in relazione a quanto il linguaggio è “distante” dalla macchina. Si parla di generazione del linguaggio, pensando anche alla reale evoluzione storica che hanno avuto i linguaggi di programmazione

• 1GL (first generation language) è in effetti il codice macchina. Si tratta della rappresentazione binaria che il processore utilizza ed esegue. Nella programmazione dei controllori lo vediamo leggendo i files .hex che trasferiamo sul controllore. Il programma è costituito da una serie di caratteri binari, come descritto nel datasheet del controllore.
• 2GL (second generation language) di fatto è l’assembler (o assembly) è poco più che una traduzione in codice mnemonico dei comandi binari.
• 3GL (third generation language) linguaggi di più alto livello solitamente di tipo procedurale (per esempio C o Java). Il compilatore traduce in codice macchina, effettuando operazioni più complesse della semplice traduzione letterale come avviene per i 2GL.
• 4GL (fourth generation language) si tratta di linguaggi dalla sintassi che tende ad avvicinarsi al linguaggio naturale (SQL ne è un esempio). Lo cito solo per completezza
• 5GL (fifth generation language). Sono linguaggi di programmazione che utilizzano ambienti grafici o visuali per interfacciarsi col programmatore. Solitamente si basano comunque su linguaggi 3GL o 4GL.

Spesso si può quindi parlare di assembler e codice macchina come se fossero sinonimi.

Si capisce che un linguaggio 3GL porta delle caratteristiche che complicano la traduzione in linguaggio macchina, in particolare, le strutture tipiche di un linguaggio di programmazione:

• Variabili
• Tipi di dati complessi
• Iterazioni (o cicli)
• Scelta
• Procedure

Siccome questi linguaggi hanno l’obiettivo principale di mascherare al programmatore la gestione delle risorse a basso livello (gestione RAM e program memory), è il compilatore che si occupa di automatizzare la traduzione.

Ragioniamo per esempio alle variabili. Quando scriviamo un programma in assembler utilizziamo genericamente indirizzi di memoria per apoggiare dei valori. Se non creiamo intrecci, possiamo utilizzare la stessa locazione per scopi differenti in rami diversi del programma. Per comodità ci costruiamo una “mappa” per cui ci è chiaro l’utilizzo di ogni porzione di memoria.
In C ci limitiamo a dichiarare una variabile sapendo quale è il suo scope (la sua visibilità). La gestione della memoria (scegliere quale locazione, decidere con chi può essere condivisa, da quale ramo di codice può essere scritta, ….) è tutte ad opera del compilatore.
Ogni compilatore implementa un suo preciso meccanismo per effettuare tutte queste operazioni. È proprio qui la differenza dei compilatori.

Proviamo a semplificare il lavoro di un compilatore:

1. Analisi del codice in termini di “albero delle chiamate”. Elenco di tutte le funzioni con le relative dipendenze (chi chiama chi). Utile per vedere le funzioni che convivono e che quindi non possono condividere aree di memoria
2. Catalogazione di tutti gli oggetti (funzioni) in termini di dimensione del codice e richiesta di memoria.
3. Analisi dei parametri di input e resultcode.
4. Creazione della mappa di memoria. Solitamente viene suddivisa in segmenti logici, dedicati a diverse tipologie di esigenza (variabili, parametri, tipi di dati pi lunghi del byte, …)
5. In caso di limitazioni del compilatore effettua la gestione per mascherare le limitazioni. Ad esempio i processori di fascia bassa della Microchip hanno una limitazione sulla profondità di chiamata delle funzioni (max 2 livelli) il compilatore deve aggirare il problema. Il compilatore picc di HI-TECH si costruisce una jump table che usa per mascherare call/return con coppie di goto.

Per tutte queste gestioni il codice macchina prodotto da un compilatore contiene molte più istruzioni di quelle strettamente necessarie per eseguire le operazioni a basso livello.
Questo è il motivo per cui genericamente si dice “l’assembler è più performante del C”. Ci si riferisce allo strato di funzionalità base che il compilatore introduce, l’overhead prodotto dal compilatore.
Questo è necessario perché un linguaggio 3GL si propone come linguaggio indipendente dalla macchina fisica su cui viene eseguito. Questa “indipendenza” si paga.
Dopo questa semplificata descrizione, riassumo alcune caratteristiche dei due linguaggi:

Linguaggio C

• è un linguaggio più comodo. Offre una sintassi e una gestione procedurale che ne agevola la scrittura e la lettura da parte dell’uomo
• è pressoché indipendente dall’hardware sottostante. Attenzione: questo non significhi che TUTTI i programmi scritti in C sono effettivamente indipendenti dall’hardware. E nel caso di firmware per microcontrollori questo lo si vede spesso ed è una dell considerazioni principali nella scelta del linguaggio. A cosa mi riferisco? L’istruzione RB3 = 1; è un comando C, ma se serve per accendere un LED collegato al piedino 3 della porta B del PIC, questa è una conoscenza hardware necessaria per il funzionamento del programma. Quando programmiamo un microcontrollore non vale l’analogia con il computer. In questo caso, infatti, solitamente il programma C interagisce con il sistema operativo e difficilmente abbiamo la necessità di utilizzare direttamente componenti Hardware.
• La traduzione in codice macchina perde in efficienza
• Generalmente la scrittura di codice richiede meno tempo

Assembler

• permette accesso diretto all’hardware
• è possibile gestire con precisione i tempi di esecuzione di ogni istruzione
• la programmazione richiede una buona conoscenza del processore su cui il codice viene eseguito
• richiede molta attenzione e precisione nella definizione delle strutture.

Indipendentemente dal linguaggio, scrivendo firmware sui controllori è necessario avere la conoscenza del processore con cui stiamo lavorando. Per applicazioni più semplici e avendo a disposizione una buona libreria, con il C possiamo facilmente cavarcela anche senza conoscere i dettagli dell’hardware

La mia scelta
Innanzi tutto va tenuto conto che da hobbista utilizzo strumenti non professionali. Non ho intenzione di spendere migliaia di euro quando con un po’ di lavoro in più (si tratta sempre di passione) posso ottenere ottimi risultati gratis.
I miei strumenti sono MPLAB ed il compilatore Picc di HI-TECH versione freeware.
A meno di intervenire pesantemente su parametri di configurazione del compilatore, avere a disposizione compilatori con buona ottimizzazione e avere una conoscenza del compilatore più dispendiosa della conoscenza del processore, ci sono molte operazioni che non sono di fatto possibili in C.
Cito un esempio: le routine di trasmissione seriale. Scritte in C e compilate per i controllori PIC baseline funzionano senza problemi. Compilando lo stesso codice su controllori di fascia diversa, il compilatore cambia i criteri di ottimizzazione (che sono poi legati a effettive differenze hardware) e smettono di funzionare. C’è una spiegazione. Nella comunicazione seriale (bit banging) è richiesta una precisa gestione del tempo. L’overhead introdotto dal compilatore nel secondo caso è tale per cui sarebbe richiesta una ricalibrazione dei ritardi introdotti nel codice.

Abbiamo un’alternativa, la stessa scelta che è stata fatta nel mondo dei computer. Ormai a costi bassi possiamo trovare controllori sempre più potenti, che offrono come funzionalità base quasi tutto quello che serve, con memoria pressoché illimitata. Quindi per far lampeggiare un LED scriviamo un semplice programma in C e lo facciamo girare su un controllore 1 32bit dotato di porta USB, Ethernet, con 32k di program memory, 256k memoria RAM, gestione nativa del BUS I2C e SPI, 32 convertitori A/D, …
Forse è un po’ eccessivo? È comunque una possibilità. Con i computer hanno fatto così!

Io preferisco identificare il processore più adatto allo scopo e dimensionarlo correttamente, disegnare il circuito e dimensionare il tutto in base alle effettive esigenze.
Come linguaggio utilizzo insieme il C e l’assembler: ho costruito una buona libreria di funzioni base in assembler che utilizzo chiamandole da funzioni C. Solitamente il main lo scrivo in C, scrivo in C funzioni che non richiedono particolare ottimizzazione, uso le funzioni assembler e sto sempre attento alla percentuale di risorse utilizzate. Quando sforo, mi tocca sempre convertire in assembler alcune delle funzioni C.

Purtroppo mi sono trovato in questa necessità e le routine fornite di esempio con il compilatore PICC di Hitech (il compilatore che utilizzo di solito) non sono riuscito a farle funzionare. Non so se perché errate, o se per colpa dell’ottimizzazione che nella versione freeware non è garantita.

Lavorando a basso livello è infatti avere la massima ottimizzazione.
Pazienza: dovendo lavorare con il 16F506 per il mio progetto, le ho dovute riscrivere. Il file i2c.h è scaricabile qui e contiene il codice che implementa le funzioni di base in linguaggio C.
Va notato l’utilizzo del registro TRIS. Essendo un registro in sola scrittura nel 16F506, per valorizzarlo ho utilizzato una variabile di appoggio in cui memorizzo il valore (m_TRIS). Con processori differenti è necessario modificare la gestione del registro. Per questo motivo nel file si trova nella parte iniziale e modificabile agendo sulle definizioni di SCL_IN, SCL_OUT, SDA_IN e SDA_OUT.
Ecco un esempio di come utilizzare la libreria:
i2c_init();

i2c_start();
i2c_tx(0xA2);
i2c_tx(0x02);
i2c_tx(0x00);
i2c_stop();

L’esempio riportato mostra come scrivere un valore nella EEPROM. La lettura avviene in modo analogo:
i2c_start();
i2c_tx(0xA2);
i2c_tx(0x02);

i2c_start();
i2c_tx(0xA3);
Putch (i2c_rx(1));
Putch (i2c_rx(1));
Putch (i2c_rx(0));
i2c_stop();

Questo codice invece legge dalla memoria e trasmette i valori letti sulla seriale utilizzando le librerie RS232 qui descritte

Con questa libreria è possibile quindi controllare tutti i dispositivi I2C (RTC, memorie EEPROM, …)

Come tutti i dispositivi I2C, dobbiamo ragionare per locazioni di memoria: scriviamo o leggiamo valori da indirizzi precisi. Questo sensore di temperatura utilizza 4 locazioni differenti:
00h – contiene il valore della temperatura. Il valore è a 12 bit, quindi dobbiamo effettuare due letture

i2c_put_read_address(temp_addr + a)
i2c_get_data(tempMSB)
i2c_put_ack
i2c_get_data(tempLSB)
i2c_put_nack
i2c_put_stop

01h – registro di configurazione. Lo scriviamo con la configurazione desiderata (di seguito il dettaglio)

Gli altri due servono per controllare il termostato e hanno entrambi la stessa struttura a 12 bit del registro temperatura
02h – temperatura isteresi del termostato. Rappresenta la soglia di intervento. Il termostato è attivo al di sotto della temperatura impostata. Si disattiva al raggiungimento di tale valore per riattivarsi quando la temperatura scenda al di sotto del valore di isteresi.
03h – Valore della temperatura del termostato

Codifica della temperatura
Il valore della temperatura viene rappresentato in questo modo:

Questo significa che la parte intera la otteniamo dal primo byte che leggiamo. Il valore letto nel byte meno significativo va shiftato di 4 a destra e moltiplicato per 0.0625 per ottenere la parte decimale della temperatura. I bit sono effettivamente utilizzati in base alla risoluzione impostata. Di default la risoluzione è a 9 bit, quindi abbiamo letture valide solo per il primo bit (0.5?C)

Byte di configurazione (02h)

SD: quando portato a 1 il convertitore va in stand-by, restando in ascolto solo sul BUS I2C. A 0 (default) il dispositivo effettua continuamente rilevazione della temperatura

TM: seleziona il modo operativo del termostato. 0 funziona nella modalità descritta nell’esempio che ho fatto parlando di isteresi. A 1 il funzionamento è “a interrupt”, cioè partendo dal valore alto che indica la situazione normale, l’uscita viene abbassata ad ogni evento significativo (temperatura sopra la soglia o sotto l’isteresi). Il valore resta basso fino a che non viene effettuata una lettura I2C.

POL indica il significato di “attivo” dell’uscita. Se POL vale 1, attivo significa 1, altrimenti 0

F0-F1 indica il numero di letture da effettuare prima di considerare valido il cambio stato quando si opera in modalità interrupt.

R0-R1 indica la risoluzione del termometro

Indirizzi
Trattandosi di un dispositivo I2c, dobbiamo parlare di indirizzo. L’indirizzo è necessario per effettuare la comunicazione. Diversamente da quanto solitamente avviene per altri dispositivi (per esempio le EEPROM seriali) per il DS1775 l’indirizzo è unico e cablato nel processore, composto da due parti.

• una parte fissa: 1001
• altri 3 bit determinabili dal part number dell’integrato, in particolare:
  DS1775R/TRL 000
  DS1775R/TR1 001
  DS1775R/TR2 010
  DS1775R/TR3 011
  DS1775R/TR4 100
  DS1775R/TR5 101
  DS1775R/TR6 110
  DS1775R/TR7 111

Va quindi prestata attenzione al momento dell’acquisto