Ciao a tutti,
ultimamente l'autore si è lasciato trascinare dal lato sistemistico del suo carattere, dimenticandosi che in realtà sono un elettronico e non un sistemista. Pertanto, mi sento di condividere con il mondo il progetto che più ho sviluppato negli ultimi due anni: il "misuratore di temperatura" (aka termometro, ma quando ho avviato il progetto stranamente non mi è venuto in mente). L'idea è nata un bel giorno di quarta superiore, in cui il buon Sanzio spiegò il comparatore ad isteresi (o trigger di Shmitt) realizzato con amplificatori operazionali. Esso è in pratica un blocco comparatore (velocemente: se Ingresso<soglia l'uscita vale 0, altrimenti 1) con isteresi, ovvero soglia è un intervallo di valori (2,4-2,6 [V] ad esempio).

La prima versione

Obiettivi posti e specifiche di progetto

Mi venne subito un quesito: il riscaldatore del mio acquario funziona con un comparatore normale o ad isteresi? E' da questa premessa (del cavolo, nda di tre anni dopo) che nacque il progetto del primo termometro. Esso doveva:

  • Visualizzare la temperatura su (siccome il display alfanumerico non lo sapevo ancora usare) tre display a sette segmenti
  • Campionarla ad intervalli di un minuto e salvarla su una memoria flash
  • Confrontarla con delle soglie, per poi suonare nel caso che le temperature andassero fuori dall'intervallo stabilito
  • Collegarsi al computer tramite porta seriale (sfruttata anche per la programmazione) e scaricare il contenuto della memoria in un file .txt
  • Il quale file txt, importato in un foglio di calcolo, avrebbe ricostruito l'andamento della temperatura nell'ultimo mese.

Il riscaldatore avrebbe continuato a gestirsi "da solo", il primo progetto serviva solo a monitorare il sistema.

Schema a blocchi e descrizione funzionale

(qui ci andrebbe uno schema a blocchi).
Il sensore di temperatura dava in uscita un segnale analogico che, nel blocco condizionatore, veniva adattato al convertitore AD presente nel pic. Esso veniva poi letto e trasferito sui dispaly mediante le decodifiche. Ad intervalli di 1 min un timer generava un interrupt ed il dato veniva salvato sulla memoria flash. I dati venivano poi scaricati su un pc tramite collegamento seriale premendo un pulsante sul termometro per iniziare la comunicazione.

Il sensore di temperatura LM355

Il sensore di temperatura scelto era un LM355. Produce un segnale in tensione che varia di 10m[V] per grado Kelvin. Pertanto, nel range di temperature che dovevo misurare (10-35.5 °C) , il segnale da acquisire era compreso tra 2,83 e 3,03 [V], mentre il range di tensioni dell'AD era 0-5 [V]. Essendo un convertitore ad 8bit, la mia misura sarebbe variata tra 148 e 152, troppo poco per poter misurare 25,5€. Ciò rendeva necessario un blocco di condizionamento.

Blocco condizionatore

Tale blocco era composto da un sommatore algebrico a due ingressi: uno invertente ed uno non invertente. La sua funzione era di rendere compatibile il segnale con il convertitore condizionando il segnale. In particolare doveva sottrarre 10° di offset ed amplificare la differenza con un guadagno di 14. Il ramo invertente serviva invece per sottrarre l'offset. Per farlo aveva guadagno 1 ed ingresso 2.83 [V], questo per rendere più facili le regolazioni. Tale segnale veniva fornito dal blocco di alimentazione.

Blocco alimentatore

In principio questa parte doveva solo generare il segnale di offset. Infatti per far funzionare correttamente un operazionale (ovvero per avere in uscita 0 [V] e non 0,qualcosa) sono necessarie due tensioni di alimentazione di segno opposto. Solitamente si ovvia a queste problematiche in due modi: sommando al segnale da analizzare una componente continua, in modo da mantenerlo sempre positivo; oppure si ricorre alla massa virtuale, ovvero all'utilizzo di un riferimento diverso dalla massa reale del circuito, generato da un buffer ad amp op. Una soluzione del genere funziona se non ci sono praticamente carichi; nel mio caso tutto il circuito (display e pic compresi) avrebbe dovuto utilizzare tale riferimento, pertanto scartai quest'ipotesi. Per non dover costruire un doppio alimentatore o non affiancarne due, mi appoggiai ad un alimentatore da computer. Nota interessante: le tensioni nominali (+-12[V] ad esempio) sono solo indicative: (11,5[V] e ben -10,5[V] !), pertanto non sfruttabili come riferimento per il pic, ma comunque valide per alimentare i display. Per farla breve dal punto di vista circuitale, per stabilizzare i 5[v] mi sono affidato ad uno stadio a 7805, mentre per il VOffset mi sono affidato ad un LM317.

Blocco decodifica e display

Le decodifiche erano alimentate direttamente dall'alimentatore per non caricare eccessivamente il 7805. Per questo progetto scelsi le 9368, che convertivano una cifra binaria a 4bit nei segnali necessari a pilotare i display, disegnando la cifra esadecimale corrispondente. Altra caratteristica interessante era un latch posto davanti all'ingresso: in questo modo era possibile appoggiare più decodifiche sullo stesso bus e pilotarle una ad una tramite l'apposito segnale. La trasmissione era quindi seriale, dalla cifra meno significativa a quella più significativa. Purtroppo tali decodifiche oggi sono fuori produzione, rendendo arduo trovare dei ricambi adatti. Oltre che riportare la temperatura, i display venivano usati anche per riportare lo stato della connessione con il pc.

Blocco di memoria

Tali collegamenti avevano lo scopo di scaricare i dati registrati lungo un mese di attività all'interno di una memoria flash. Tale memoria aveva una capacità di 512KB (di cui venivano usati solamente 64K perchè il picaxe non permetteva variabili più grandi) e veniva utilizzata mediante protocollo SPI. Non mi accorsi subito che SPI in realtà era un bus standard, pertanto implementai la connessione in software. Per quanto fosse più lenta di una connessione hardware, ciò mi consentì di padroneggiare il protocollo SPI (e conseguentemente i2c). Siccome la memoria andava alimentata a 3,3 [V] non era possibile interfacciarla direttamente al pic, ma un opportuno buffer rese possibile la connessione.

Nella prossima puntata verrà introdotto il software lato periferica e lato pc e verrà analizzato il protocollo di comunicazione seriale.