Dai e dai, sono riuscito a convincere il pollus a scrivere "qualche" riga su tutta la gestione dei ?P del sistema fotovoltaico. ci sono voluti mesi e mesi, ma alla fine si ? lanciato. posto di seguito il suo testo diviso in 2 parti.
Parte 1
Dopo le numerose insistenze da parte di Absolute, ho deciso di scrivere qualcosa anche io nel Vs. Forum. Inutile dire che il Team ha lavorato e sta lavorando con accanimento, e soprattutto st? raggiungendo tutti gli obiettivi. Io sono Paolo in arte PCaccia e seguo la parte firmware di tutto il sistema del ponte solare. Non sono un vero tecnico come Absolute, ma l?essere testardo mi ha aiutato pi? volte a risolvere i numerosissimi problemi che sono insorti in questo progetto.
Proviamo a riassumere gli obiettivi:
Il sistema nasce con lo scopo di gestire l?energia fornita da pannelli fotovoltaici limitando le inevitabili perdite e accumulando l?energia prodotta. Essendo responsabile di un ponte radio UHF da utilizzare in situazioni di emergenza (alimentato quindi da pannelli fotovoltaici) l?idea mi ? apparsa subito interessante. Naturalmente assieme a tutto il Team avevamo gi? provveduto all?installazione di pannelli fotovoltaici e di un regolatore con accumulatori, ma sinceramente dai test effettuati l?energia accumulata e gestita era molto lontana da quella attesa dai pannelli utilizzati.
Questa era l?occasione per dotarmi di uno strumento in grado di monitorare la produzione fornendomi gli elementi per ottimizzare la gestione di tutto l?impianto e soprattutto per passare il tempo con i miei amici.
Il Team ha immediatamente cominciato a produrre e mi sembra giusto presentarVi tutti i componenti:
- Il coordinatore, l?uomo Hardware Absolute (Presidente dell?Associazione ?Il mio hardware funziona sempre, i casini sono i vostri!? e regista dei films ?Io vi trover?? e ?Vi mando Fabrizio!? ndr: ) ,
- Il softwarista Windows, La Forge (contitolare con me della rivista ?IL FUNGO? (ndr: Fungo = Errore di programmazione) e Presidente Onorario dell?Associazione ?Non ? il mio programma che da questi problemi!?)
- L?addetto alla supervisione generale sofware/scale tralicci il Nuvolarenz (Laurea ad Honorem ?Sbroglio casini?, Direttore della rivista di alpinismo ?Dove sono le cime di sicurezza per arrampicarsi su sto c? di traliccio!? ma soprattutto Presidente dell?Associazione ?Amici del mare?
- Il firmwarista e addetto frequenze sotto al Ghz, io il PCaccia (Pollus).
Il sistema ? stato gi? ben descritto da Absolute per cui mi limiter? a presentarvi il mio lavoro. L?idea iniziale di utilizzare due processori nella scheda di controllo ? stata vincente. Il firmware ? stato sviluppato prevalentemente in PICBASIC PRO e in Assembler. Molti rimarranno stupiti, ma in realt? vista la complessit? del progetto l?utilizzo di un linguaggio facilmente leggibile ? stata un scelta che ho apprezzato pi? volte. I processori utilizzati il PIC16f876 e il PIC16f877 sono stati completamente all?altezza della situazione, anche se ora dopo aver apportato numerose migliorie l?877 non ha pi? spazio programma e mi preparo a sviluppare firmware sul 18f4550.
Erano anni che non mi mettevo a contare i byte di ogni riga di programma?.ma la ritengo una esperienza importante anche perch? molte istruzioni del PICBASIC PRO non sono risultate efficienti (in termini di spazio). E? vero infatti, che come linguaggio non ? molto performante ma la semplicit? di lettura e il coordinamento con Macro in Assembler rende facile e divertente fare programmi. Con un po? di pazienza (e di rassegnazione) ho cercato quella soluzione economica che permettesse al programma di girare in maniera fluida, anche a scapito della chiarezza di lettura del firmware. E? stato quindi inevitabile aggiungere numerose righe di commento per permettere ?ai posteri? e anche a me, di poter leggere il programma altrimenti difficilmente comprensibile.
Proviamo ora ad analizzare il progetto:
Cosa doveva fare di massima l?876:
- Gestire le 7 videate dei parametri su un display LCD 4 x 40
- Interfacciarsi con un apparato Ricetrasmittente per ricevere comandi tramite DTMF
- Leggere le temperature di 5 sensori
- Comunicare serialmente con l?877, scambiando i dati e visualizzando i comandi ricevuti da un eventuale PC o direttamente dall?877
- Sincronizzare l?orologio del sistema con i dati del DCF77 (attualmente non operativo).
Cosa doveva fare di massima l?877:
- Leggere 5 valori tra correnti e tensioni
- Comunicare serialmente con l?876, scambiando i dati
- Comunicare serialmente con un eventuale PC scambiando i dati
- Comunicare serialmente con una Stazione Metereologica
- Gestire un BUS I2C composto da 1 RTC DS1307 e 8 EEprom
- Memorizzare valori sulle eeprom e scaricarli
- Attivare direttamente o tramite comandi ricevuti da PC o da 876 n. 6 Uscite
- Gestire interamente in forma automatica il sistema di controllo del carico in base a parametri reimpostabili memorizzati nella eeprom interna del processore.
- Gestire reset in caso di avarie del sistema
- Gestire eventuale UPS.
Iniziamo dal firmware dell?876:
Con in mano il datasheet a modi breviario ho girato per alcuni giorni in tutte le stanze della casa, proprio tutte, e durante la pausa pranzo al lavoro . Con l?incoscienza di un bimbo di 3 mesi che si avvicina ad un precipizio ho cominciato ad impostare i parametri di configurazione, poi riga per riga a definire le variabili di comunicazione ?e il programma ha iniziato a prendere forma. Il primo problema da affrontare ? stata la gestione della comunicazione. Il team riunito con tanto di pasticcini propiziatori, ha deliberato di utilizzare comunicazioni asincrone. Perch? Vi chiederete? Semplicemente perch? le numerose comunicazioni attive non avrebbero consentito l?utilizzo dell?unica USART interna del PIC, ma soprattutto perch? una comunicazione sincrona avrebbe richiesto l?utilizzo di 4 pin per ogni collegamento mentre era utile risparmiare delle porte (e su questo Absolute non transige!).
La ?petecchia? ? stata girata tutta sulle mie spalle anche perch? non utilizzando una comunicazione seriale sincrona si presentano tra gli altri questi problemi:
1- Tutto il programma deve ?girare? dando la possibilit? alle seriali di funzionare . Non essendoci ingressi bufferizzati un processore deve inevitabilmente aspettare il momento del contatto da parte dell?altro.
2- Il firmware deve poter prevedere che un comando non venga ricevuto dal destinatario, pertanto deve riproporglielo fino ad esecuzione
3- Il programma deve ?ciclare? ad una velocit? inferiore ad un secondo al fine di ottenere pi? campionamenti dei valori letti.
Innanzitutto ho sviluppato un protocollo ?ridondante? dove per ogni comando i due microprocessori si danno conferma di ricezione e di esecuzione, poi con un po? di funambolismo, ho calcolato i tempi di esecuzione del programma per ottimizzare i tempi di attesa dei dati delle varie seriali.
Parlo di varie seriali perch? dovete ricordarVi che il comando che parte dall?876 viene ricevuto dall?877 il quale lo esegue ed insieme alle altre cose lo destina all?eventuale PC collegato?
Il passo successivo ? stato quello di gestire le videate con tutte le informazioni raccolte dal sistema. Individuati i valori da visualizzare ho semplicemente predisposto le videate su un foglio elettronico con dimensioni corrispondenti al numero dei caratteri presenti sull?LCD. Poi ho provveduto a riportare i dati direttamente sul Firmware.
Purtroppo le videate occupano molto spazio e il povero processore deve fare anche altre cose?La prima idea che mi ? venuta ? stata quella di memorizzare la parte fissa delle videate nella eeprom interna al processore, evitando quindi di occupare lo spazio programma facendo una lettura prima della presentazione della videata.
Ma l?obbiettivo era la velocit? e comporre i dati in questa maniera richiedeva ?troppo? tempo.
Allora ho provato ad usare funzioni del linguaggio di programmazione che indicizzando un vettore contenente i valori corrispondenti ai caratteri, mi permettesse di risparmiare spazio programma?.ma anche questa soluzione si ? rivelata ?lenta?.
Alla fine, gestendo un po? di subroutine e limitando i caratteri descrittivi al minimo sindacale, la soluzione ? stata quella di memorizzare tutto il contenuto all?interno del firmware di base.
Il cambio delle videate avviene in maniera sequenziale semplicemente premendo un pulsante. Solo quando viene ricevuto un carattere dall?MT8870 (Decorder DTMF) il micro si posiziona nella videata di decodifica DTMF, oppure quando viene ricevuto il segnale di sincronismo dal DCF77 c?? il posizionamento nell?apposita videata.
Il DCF77 ? stato un vero parto. Dopo aver letto non solo i datasheet, ma anche le regole del segnale trasmesso, ho provveduto a completare il firmware di decodifica. Ho provato ad integrarlo al firmware gi? esistente, ma la decodifica deve avvenire leggendo impulsi di pochi millisecondi, per una durata di 1 minuto, (per Absolute ?tempo biblico) . Ho avuto il ?coraggio? di accennare ad Absolute che avrei dovuto sospendere per la decodifica l?esecuzione del programma principale per almeno un minuto?la risposta ve la lascio immaginare.
Allora dopo lunghe trattative ho ottenuto che alle 23.00 di ogni sera la parte DCF77 si abilitasse per circa 5 minuti per ottenere un sincronismo. L?orario era favorevole alla propagazione della frequenza dei 77,5 Khz e il firmware era stato predisposto?.ma i segnali erano troppo disturbati dalle apparecchiature di Absolute per cui la decodifica risultava difficile o impossibile.
Visti gli esigui risultati, e il collegamento al computer di tutto il sistema, il Team ha deciso di accantonare temporaneamente l?applicazione di questa sezione.
La decodifica dei dati provenienti dall?MT8870 ? stata invece la parte pi? facile da gestire. La parte hardware di Absolute ha lavorato perfettamente, l?rtx per il telecontrollo, un mio amato Motorola HT600, ha lavorato e sta lavorando a tutte le temperature (anche oltre 50gradi C) senza avere problemi di sorta. Il firmware prende i dati in formato binario direttamente dalle uscite dell?MT8870 e li interpreta singolarmente. All?interno del firmware c?? un riconoscimento di ogni singola sequenza di caratteri digitati e un timeout nel caso questi caratteri non siano inseriti entro un certo tempo. L?RTX trasmette sempre un tono di conferma dell?attivazione o della disattivazione di un comando, per cui da remoto ? sempre possibile sapere lo stato del comando inviato. Naturalmente sono stati predisposti opportuni comandi per la gestione del sistema in caso di ?blocco? di un processore, comandi da usarsi come ?estrema razio? nel caso in cui il favoloso sistema automatico ideato per l?autoreset dei processori non funzioni per qualche motivo. E se si blocca anche il processore che gestisce il DTMF?il Team ha pensato anche a questo ma ne parleremo pi? avanti col firmware dell?877.
Le sequenze riconosciute sono tutti i comandi applicabili al sistema, dallo spegnimento, al reset parziale, all?attivazione delle porte, delle forzature manuali o automatiche?insomma tutto compreso anche il settaggio dell?orario dell? RTC presente sull?877?per quest?ultimo comando mi hanno dato del maniaco visto che il sistema si controlla interamente da PC.
Le letture delle temperature avvengono direttamente dagli ingressi Analogici dell?876 che, opportunamente settati, rendono l?operazione di conversione un semplice comando. Il datasheet fornisce, come sempre, tutti gli elementi per il settaggio e i tempi minimi per effettuare le conversioni. Il risultato ? stato veramente soddisfacente con tempi estremamente contenuti.
Ritorno ancora sulla comunicazione tra 876 e 877 per chiarire meglio i motivi delle scelte effettuate e per introdurre la spiegazione del firmware dell?877.
Come gi? detto, la comunicazione viene gestita opportunamente da un firmware ?demenziale? e ?completamente blindato? con controlli di ricezione e di esecuzione, che girano tra i due processori?. che passano le loro giornate a chiacchierare e a verificare di non essere bloccati?.. Ammetto che mi sarebbe piaciuto utilizzare l?USART interna dei PIC col piccolo buffer di ricezione che mi consentiva di gestire con pi? sicurezza il protocollo di comunicazione, ma come vedrete pi? avanti, l?877 ? molto appesantito di lavoro, e dovendo disabilitare gli interrupt per troppo tempo (non potendo lasciare abilitata questa possibilit? durante altre funzioni dell?877) il problema di perdere qualche comunicazione si riproponeva alla stessa maniera. Giusto per essere chiari la gestione dell?USART avviene tramite Interrupt, all?arrivo dei dati questi vengono memorizzati ?temporaneamente? in un piccolo buffer all?interno del micro e contemporaneamente viene segnalato un interrupt per consentire al processore di fermare l?esecuzione corrente e dedicare il proprio tempo alla lettura dei dati in arrivo. Terminato questo periodo di tempo il programma azzera i riferimenti dell?interrupt e procede dal punto successivo a quello in cui stava eseguendo l?ultima operazione prima dell?interrupt. Come si pu? intuire?se l?ultima operazione in esecuzione fosse ad esempio la lettura di un?altra seriale, i dati in ricezione sarebbero inevitabilmente persi durante la richiesta di interrupt dell?USART. Ed ? questo il motivo per cui si disabilitano i rilevamenti degli interrupts durante alcune funzioni del programma. E? importante ricordare che abilitando gli interrupts il firmware aggiunge ad ogni comando in cui la rilevazione dell?interrupt ? attiva, una ulteriore istruzione di verifica dell?interrupt?.e lo spazio programma si riduce inevitabilmente. Inutile dire che noi abbiamo bisogno di spazio!
L?877 ? ? l?876 con pi? porte; la programmazione delle letture delle tensioni e delle correnti, come per l?876 non hanno generato particolari problemi (grazie anche all?hardware di Absolute) il convertitore settato con una risoluzione di 10Bit ci fornisce dati veloci e precisi.
E? grazie a questi dati che il micro opera con ?logica programmata?, per cui ? importante che siano affidabili. Come gi? detto la comunicazione tra 877 e 876 ? seriale asincrona con comunicazioni ridondanti, verifica ricezione e attuazione comandi. Bisogna ricordare che:
l?877 pu? generare autonomamente comandi che dovranno essere ricevuti dall?876 e dall?eventuale PC; L?876 pu? inviare comandi all?877 e conseguentemente all?eventuale PC;
L?eventuale PC pu? inviare comandi all?877 e di conseguenza all?876;
L?877 riceve i dati da una stazione meteo e li distribuisce all?876 e all?eventuale PC.
Tutto il sistema di comunicazioni ? asincrono; la sola stazione meteo non utilizza un protocollo ridondante ma semplicemente la lettura diretta dei dati prodotti.
Solo a titolo di cronaca la stazione Meteo ? attualmente gestita da un unico PIC16F877 e fornisce Temperatura, Umidit?, Pressione, Velocit? e Direzione del vento.
Una nuova stazione meteo commerciale ? stata implementata con un piccolo PIC16F628 (successore del PIC16F84) , come interfaccia che provvede a simulare la connessione ad un PC e la serializzazione e normalizzazione dei dati provenienti dalla meteo. Questa volta ho utilizzato l?USART ed ? stato veramente divertente analizzare byte per byte il dato ricevuto. Il 628 integra anche un oscillatore interno decoroso, e con pochi componenti tutto ha funzionato al primo colpo anche se l?hardware l?ho progettato io e non ABSOLUTE eh eh eh Ma per dovere di cronaca Absolute mi ha inciso il PCB e qui il suo tocco magico c?? stato. Il modello utilizzato ? L?OREGON SCIENTIFIC WMR 928NX che malgrado la sua semplicit? rimane uno strumento sufficientemente affidabile.
E? bastato collegare uno sniffer seriale e verificare la comunicazione, i record di dimensione diversa riportano quasi tutti i dati visualizzati nel display in codifica BCD e con un po? di tempo sono riuscito a decodificare tutti i valori. In questa maniera abbiamo aggiunto anche la temperatura di rugiada, la temperatura del vento, la rilevazione delle piogge e?.. le previsioni metereologiche sulle quali io per primo nutro alcuni dubbi. Ma?..giustamente si chiamano previsioni altrimenti le chiamerebbero certezze! Comunque la piccola interfaccia prevede l?uscita di due segnali seriali di cui uno per la centralina di controllo del ponte solare e una?.per il ponte radio UHF. Il sistema di controllo del ponte radio UHF legge e analizza tutti i dati e a richiesta li pronuncia via radio con voce suadente di una signorina. Ammetto che un po? per megalomania e un po? per la poca disponibilit? di signorine compiacenti (sono sempre 170 fonemi) avevo cominciato a registrare i dati con la mia voce?.poi, non essendo disponibile ad entrare a far parte delle voci bianche, sono stato costretto a cambiarla!
?.Ma questo ? un altro progetto?e se vi interessa chiedete! Cosa ne facciamo di tutti questi dati che mulinano dentro il sistema? Li memorizziamo e li elaboriamo.
La continua ricerca della massima precisione con l?affidabilit? dei dati letti mi ha impegnato a gestire variabili a 32Bit. Inevitabile dire che il PICBASIC PRO gestisce variabili di tipo word a 16 bit quindi con un valore massimo decimale di 65.535 e considerando che almeno un decimale se non due in tutte le letture deve essere mantenuto, le variabili word disponibili in PICBASIC PRO non erano assolutamente sufficienti a gestire questa mole di dati. A questo punto ho cominciato ad informarmi su come utilizzare manualmente variabili a 32bit e?.navigando in internet ho avuto modo di raccogliere numerose informazioni rilasciate da Darrel Taylor che colgo l?occasione di ringraziare pubblicamente.
La soluzione ? in fondo semplice?basta utilizzare due variabili word disposte su un vettore di due o pi? elementi in base alla dimensione della variabile che si vuol creare. Poi basta sommare il valore al valore della seconda variabile. Se il risultato della somma ? minore del valore presente prima della somma nella seconda variabile, vuol dire che si ? superato il valore 65535 per cui ? sufficiente aggiungere 1 alla prima variabile. Il gioco ? fatto! Naturalmente questo sistema ? valido solo se si sommano variabili che siano al massimo di 16 Bit. Sistemi pi? complessi si possono sviluppare per somme e sottrazioni di variabili di dimensioni maggiori?..comunque il ns. problema ? risolto! Per poter fare le somme e le divisioni la cosa ? stata pi? semplice in quanto gi? il PICBASIC PRO ha incorporato i comandi DIV32 e * che utilizzano variabili a 32 bit anche se non direttamente disponibili dal linguaggio? sono sempre raggiungibili tramite assembler! Sono riuscito cos? ad utilizzare variabili a 32 bit per accumulare tutti i valori di sistema. Ogni minuto il firmware registra la media all?interno delle EEprom.
Le EEprom non bastano mai, Absolute in fase di eccitazione agonistica, ha previsto 8 EEprom 256K, poi quando gli ho detto che possiamo usare anche le 512K le ha immediatamente sostituite?ora girano voci che riesca a trovare anche le 1024K. Per essere sicuro di poter utilizzare tutte le dimensioni di eeprom ho provveduto ad implementare il firmware con dei parametri memorizzati nella eeprom interna al processore. Parametri che potranno essere variati direttamente tramite comandi da PC. Quanti dati possiamo memorizzare con 8 eeprom da 512k.? Vi dico solo che memorizzando un record ogni minuto possiamo memorizzare ca.22 giorni di dati?non male direi! Il ponte solare deve poter attivare anche 6 uscite. Il firmware ? in grado di gestirle senza problemi. I comandi possono essere ricevuti dall?876 (RTX) e dal PC ed ? prevista la possibilit? di utilizzare le uscite sia on/off sia temporizzate.
Segue Parte 2 =>
