Autore Topic: Gestione Firmware ?P Per Ponte Fotovoltaico - Parte 2  (Letto 2549 volte)

Absolute

  • Full Member
  • ***
  • Post: 261
    • Mostra profilo
    • E-mail
Gestione Firmware ?P Per Ponte Fotovoltaico - Parte 2
« il: Ottobre 03, 2008, 12:26:29 pm »
Parte 2

Ma il sistema ha soprattutto una ?intelligenza programmata? cio? ? in grado di valutare le condizioni lette e stabilire come agire in maniera autonoma. Questa parte, la pi? divertente, ? il vero cuore del sistema. Absolute in particolare ha sudato parecchio per capire e ottimizzare i vari comandi. Io ancora oggi ho bisogno di rileggermi il firmware per capire cosa ? impostato in automatico?ma ? tutta una questione di buon senso! L?obbiettivo ? solo uno! Sfruttamento dei pannelli fotovoltaici e del sole?..che scoprirete non sempre presente, anche quando ci deve essere. Una nuvoletta passeggera, un ?finto Full Batt?, una intera giornata di pioggia, o peggio l?alternanza continua di sole e pioggia?tutto quello che ci sembra normale, pu? essere causa di interventi errati e l?energia effettiva a disposizione si riduce brutalmente. Anche lo stesso carico collegato ai pannelli pu? essere un problema vista la sua variabilit?. Come vi ho detto i dati vengono memorizzati nel banco di memorie e sono una fonte inesauribile di studio. La cosa veramente simpatica ? che il dettaglio delle informazioni fornite ci permette di identificare con precisione le motivazioni dei cali di produzione e della capacit? di accumulo del sistema.  In sostanza l?analisi dei valori memorizzati dal sistema ci ha indicato in maniera chiara la strada da perseguire per sfruttare la ?sempre poca? energia fornita dal Fotovoltaico. Come strumenti principali di controllo sono previsti all?interno del firmware numerosi valori di intervento programmabili tramite PC e memorizzabili nella eeprom interna al microprocessore.
Un sistema cos? tecnologico pu? essere soggetto ad interruzioni. E? stato previsto nel firmware un sistema di controllo del regolare funzionamento dei processori, implementato anche da un hardware che sovraintende all?operazione. Il sistema, non proprio semplice, ? stato utile sul ponte UHF, dove purtroppo non mancano scariche elettrostatiche? che speriamo rimangano a dovuta distanza! E se manca l?energia da sopra e da sotto (sole/batterie-rete) SI SPEGNE TUTTO! Ma prima di spegnersi ? prevista la memorizzazione di tutti i parametri con la predisposizione della soglia di accensione. (Evitando dannosi spegnimenti e riaccensioni consecutive.) E? previsto inoltre nel sistema l?utilizzo di un UPS, la cui gestione ? devoluta interamente al firmware in base alla disponibilit? di energia. Le funzioni di attivazione e spegnimento sono integrate nella gestione dell?energia prodotta con parametri settabili direttamente dall?operatore tramite PC. Ogni parametro viene memorizzato all?interno della EEprom del microprocessore. Per ultimo tra le varie funzioni ? naturalmente possibile fare il download dei dati contenuti nelle eeprom. Questa parte del firmware ? stata un po? trascurata, anche perch? il poco spazio programma rimasto ha evitato che inserissi controlli di flusso, selezione e possibilit? di interruzione.  In realt? la nuova versione del firmware applicabile sul 18f4550 preveder? la possibilit? di selezionare la data e l?ora da cui cominciare a fare il download e altre funzioni di interruzione e controllo del flusso dei dati.
Attualmente non abbiamo avuto problemi con il download che?incomincia dalla prima fino all?ultima eeprom. I record scritti corrispondono ai record memorizzati?.ma ci siamo gi? accorti  che in lunghe tratte dove i ritardi di comunicazione possono essere ?rilevanti? si pu? presentare il problema della perdita di qualche record.
Inutile dire che il La Forge ha dovuto impegnarsi oltremodo per sincronizzare i dati in arrivo, ma devo ammettere che il suo lavoro ? veramente incredibile. A volte penso che anche lui non riesca a credere di essere riuscito a fare quello che ha fatto?.Bahhh!

L?esecuzione attuale del firmware prevede:
Ogni secondo:
-    ca. 3 campionamenti al secondo dei valori
-    lettura dei dati della seriale relativa all?876
-    lettura dei dati della seriale relativa all?eventuale PC
-    lettura dei dati della seriale relativa alla Meteo
-    lettura bus I2c per il Real Time Clock
-   rilevamento Full Batt
-   rilevamento stato pannelli
-   rilevamento 1 soglia batterie scariche
-   rilevamento 2 soglia batterie scariche
-   allarme intrusione
-   segnale di sopravvivenza microprocessore
Ogni minuto:
-   rilevamento della media dei valori letti e calcoli con variabili a 32bit
-   memorizzazione nelle EEprom su Bus I2c dei valori calcolati e rilevati
Occasionalmente:
-   comandi provenienti da RTX dell?876
-   comandi provenienti dall?eventuale PC
-   comandi generati dalla ?logica programmata? del firmware
-   invio messaggi di errore all?876
-   download dati eeprom

Come potete vedere il lavoro dell?877 ? molto pesante ma ad essere sinceri siamo tutti molto soddisfatti del risultato. Grazie all?analisi dei dati abbiamo fatto un nuovo passo avanti ponendoci questa domanda:. Perch? quando la batteria ? ? completamente carica? il sistema di controllo dei pannelli deve gettare energia e non sfruttarla per ?forzare la carica delle batterie? e soprattutto alimentare direttamente il carico? L?utilizzo di una batteria di switching ? stata la risposta per sfruttare proprio quell?energia prodotta dai pannelli fotovoltaici non richiesta dagli accumulatori (perch? in Full Batt), ma utilizzata dal carico connesso al sistema.
Absolute ha predisposto immediatamente i circuiti e grazie ad un altro PIC16F876 stiamo gestendo questa nuova risorsa. Il firmware raccoglie i dati dalle porte analogiche interne al processore e offre la possibilit? all?operatore PC di manipolare i parametri di controllo per una gestione pi? performante. L?unica novit? ? stata la gestione di tre sonde della temperatura del tipo DS18b20. Mi sono pi? volte pentito di averle utilizzate, ma gli evidenti pregi generati dalla poca componentistica necessaria al funzionamento e all?utilizzo di una sola porta per pi? sensori, mi ha portato ad accettare i ?lunghi? tempi di campionamento e la predisposizione di un firmware ad hoc per la gestione di queste sonde di temperatura. Il programma per la gestione deve prevedere inoltre la funzione di ricerca delle sonde (che sono numerate con un codice a 64bit) e l?assegnazione delle stesse. In sostanza sono stato costretto a  far prevedere ad Absolute un jumper con cui il firmware esegue la ricerca delle sonde e memorizza i relativi codici a 64bit nella eeprom interna al processore. Tutto questo solo per evitare l?assegnazione random delle sonde ad ogni avvio del processore, permettendomi quindi di identificarle nello svolgimento del programma. Le informazioni per la gestione del BUS 1 wire come quello del DS18b20 sono fortunatamente abbastanza reperibili, e con un po? di acrobazie (?e qualche necessaria parolaccia) tutto funziona perfettamente. Naturalmente i collegamenti seriali sia di questa scheda switching sia della scheda di controllo avvengono utilizzando dei moduli rs232/Ethernet?.ed ? tutto ?magicamente? in rete.
 
Continuano i test e lo sviluppo?.ci sentiremo per aggiornamenti.

Di seguito, porto ad esempio di programmazione, alcune macro del programma. Nello spirito di condivisione delle informazioni, augurandomi che a qualcuno possano risolvere problemi senza doversi sbattere l?anima a reperire info ed esempi.

GESTIONE COMPLETA RTC (REAL TIME CLOCK) DS1307
Non amo particolarmente gli IC prodotti dalla Dallas/Maxim? ma devo ammettere che questo piccolo integrato lavora veramente molto bene.
Questa ? una semplice subroutine per la gestione delle comunicazioni col DS1307.
E? la versione non ottimizzata ?ma se avete spazio... risulta pi? facilmente leggibile?

'*********************************************************
' GESTIONE COMPLETA COMANDI LETTURA E SCRITTURA RTC DS1307
'*********************************************************

LEGGI_RTC:
    I2CREAD SDAI2C,SCLI2C, RTCC, RTCADR, [RTCSEC, RTCMIN, RTCORE, RTCGS, RTCGG, RTCMM, RTCAA, RTCCTR ]
    RTCCK = RTCSEC.7                     ' DECODIFICA i valori letti DA formato BCD
    SECONDI = ((RTCSEC>>4)&$07)*10 + (RTCSEC&$0f)
    MINUTI = ((RTCMIN>>4)&$07)*10 + (RTCMIN&$0f)
    ORE = ((RTCORE>>4)&$03)*10 + (RTCORE&$0f)   
    GG = ((RTCGG>>4)&$03)*10 + (RTCGG&$0f)
    MM = ((RTCMM>>4)&$01)*10 + (RTCMM&$0f)
    AA = 2000 +((RTCAA>>4)&$0f)*10 + (RTCAA&$0f)
RETURN



SCRIVI_RTC:
    RTCSEC = %00000000                    ' CODIFICA i valori letti IN formato BCD
    RTCMIN = MINUTI / 10
    RTCMIN = (RTCMIN << 4) + (MINUTI // 10)
    RTCORE = ORE/10
    RTCORE = (RTCORE << 4) + (ORE //10)   
    RTCGS = %00000101
    RTCGG = GG /10
    RTCGG = (RTCGG << 4)+ (GG //10)
    RTCMM = MM /10
    RTCMM = (RTCMM << 4)+ (MM  //10)
    RTCAA = (AA - 2000) /10
    RTCAA = (RTCAA << 4) + ((AA - 2000) //10)
    RTCCTR = %00010000

    I2CWRITE SDAI2C, SCLI2C, RTCC, RTCADR, [RTCSEC, RTCMIN, RTCORE, RTCGS, RTCGG, RTCMM, RTCAA, RTCCTR ]   
    PAUSE 10
RETURN
   

 
Subroutine/Macro per il caricamento di una variabile a 32bit  nello spazio riservato dal Picbasic Pro al risultato della moltiplicazione.
Vi ricordo infatti che il risultato della moltiplicazione in PicBasic Pro ? a 32 bit, mentre ? possibile gestire solo variabili a 16 bit.
Caricando i valori in questa variabile ? possibile utilizzare la funzione PicBasic Pro DIV32 mantenendo la massima precisione nel risultato.
Per questa ed altre Subroutines/Macro devo ringraziare Darrel Taylor che mi ? stato di riferimento in molte difficili situazioni.

Asm
PutMulResult?D macro Din
    MOVE?BB   Din, R2
    MOVE?BB   Din + 1 , R2 + 1
    MOVE?BB   Din + 2, R0
    MOVE?BB   Din + 3, R0 + 1
    RST?RP
  endm
EndAsm

 
Come gestire una variabile  a 32bit (o pi?) in Picbasic Pro.
Viene creato un vettore composto da 2 variabili word (16bit). Si effettuano le somme direttamente sul primo elemento del vettore. Se il valore del primo elemento dopo la somma risulta inferiore al valore sommato?basta aggiungere 1 al secondo elemento del vettore.
Naturalmente i valori da sommare devono essere contenuti in variabili da 16bit ?ma con un piccolo trucco ? possibile sommare anche variabili di dimensioni maggiori ?

       IVBAT (0) = IVBAT(0) + VBAT
   IF IVBAT(0) < VBat then IVBAT (1) = IVBAT (1) + 1


Un saluto a tutti. PCaccia (Pollus).  :-)
« Ultima modifica: Ottobre 03, 2008, 12:31:03 pm da Absolute »

DjByte

  • Administrator
  • Hero Member
  • ******
  • Post: 2429
    • ICQ Messenger - 484438253
    • Mostra profilo
    • Sperimentazioni con l'energia solare
    • E-mail
Re: Gestione Firmware ?P Per Ponte Fotovoltaico - Parte 2
« Risposta #1 il: Ottobre 03, 2008, 09:32:00 pm »
Veramente un ottimo progetto, frutto dello sforzo di un ottimo team.
In confronto, il mio progetto ? roba da scuole medie  :cry:... per? ci sono solo io a portarlo avanti...
Avessi solo un terzo delle vostre capacit?...

Byte
Due sono le cose infinite: l'universo e la stupidit? dell'uomo... Della prima per? non ne sono sicuro! [Albert Einstein]

Absolute

  • Full Member
  • ***
  • Post: 261
    • Mostra profilo
    • E-mail
Re: Gestione Firmware ?P Per Ponte Fotovoltaico - Parte 2
« Risposta #2 il: Ottobre 04, 2008, 09:51:43 pm »
ti capisco Dj....se non avessi potuto contare sull'aiuto di LaForge, Nuvolarenz e soprattutto del Pollus, non avrei mai potuto neppure avvicinarmi alla complessit? che ha raggiunto questo progetto. il mio controllo in HW si limitava alle tensioni di soglia...che come ben sappiamo per una gestione del genere ? un sistema decisamente rudimentale. la gestione avanzata, fatta invece con l'aiuto di un processore che controlla in continuazione la situazione della potenza, ? decisamente un altro pianeta.
considerando che ci? che tu hai fatto, l'hai fatto sviluppandolo da solo e probabilmente con meno tempo a disposizione di me (io ce ne ho speso veramente molto nell'ultimo anno e 1/2), hai ottenuto comunque, risultati decisamente ottimi.  :-D