Author Topic: Modifiche e miglioramenti alla logica del master  (Read 343 times)

Offline I2NOS

  • Full Member
  • ***
  • Posts: 179
Modifiche e miglioramenti alla logica del master
« on: February 03, 2018, 03:21:32 PM »
Ciao Fabio,
dopo aver tribulato un bel po' con la radio frequenza dei baofeng, e non averla ancora vinta, ti metto al corrente delle modifiche fatte che sono abbastanza grosse.

1: I file di descrizione contengono adesso anche parametri (che dopo ti spiego); ho aggiunto anche un altro file (che dopo ti spiego)

2: Ho creato blocchi di controllo per poter gestire meglio i parametri, il flusso del programma e le possibili espansioni. Alcune delle modifiche vanno a sostituirsi alle tue, per cui poi gli dai una occhiata e aggiusti o tagli

3: non esistono più ileggibat, vleggibat e altre funzioni varie sostituite da altre (che dopo ti spiego)

4:ho modificato una serie di pannelli per poter aggiustare alle nuove funzionalita';

5: ho messo una serie di parametri in eeprom.

6:modificato orologio di sistem

E adesso inizio le spiegazioni.
I blocchi di controllo li ho creati per avere una gestione modulare e rispecchiano i vari snodi della parte di power management.
Uno dei concetti che ho tentato di realizzare è quello di separare la parte interattiva via radio dal motore vero e proprio che invece e'
a livello sistema. Per cui da pannello interagisci con lo strato sotto, ma quello è comunque il posto dove stanno le definizioni e le routine che girano.
Ho creato il blocco uAccum che contiene tutte le informazioni relative agli accumulatori (al posto di batterie - dettaglio dopo).
Ho creato il blocco uLoad che contiene tutte le informazioni relative ai carichi (dettaglio dopo).
Ho creato il blocco uSwitch che contiene tutte le informazioni relative agli interruttori (dettaglio dopo).
Ho creato il blocco uSensor che contiene tutte le informazioni per gestire i parametri,formule,porte dei sensori(dettaglio dopo).
Ho creato il blocco uPort che contiene tutte le informazioni relative alle porte(la porta è quella che sta sullo slave da 0 a 15).
Ora la cosa più innovativa è uSensor, in quanto attraverso questo si ottiene una astrazione tra informazioni e dove queste si trovano, mi spiego meglio:
attraverso una chiamata a dreadsensor numero sensore ottengo il valore richiesto, se questo sensore è un sensore di tensione, avro' un valore relativo alla tensione già corretta
d tutti i parametri relativi a quel sensore, se e' di corrente  la stessa cosa, se è un input digitale avro' lo stato, se è temperatura.... etc.
attraverso una chiamata a dwritesensor scrivo sul sensore (in questo caso al momento ho solo switch).
Quindi ho praticamente una tabella di n sensori al momento 16 sensori per 2 slave = 32, ma i sensori non sono necessariamente legati agli slave.
il sensore a sua volta si appoggia, se e' necessario, al blocco uPort per trovare dove richiedere/inviare la richiesta del dato.
I blocchi uAccum, uLoad e uSwitch, contengono al loro interno le informazioni su quali sensori utilizzare per ottenere/dare le informazioni di pertinenza.
Vediamo un po' meglio
 uAccum[4] (definita in pmsycommon.c ) e' una matrice di 4 accumulatori, per ogni accumulatore e' previsto:
0 ovviamente il suo numero di matrice
1 (u8accumid)un ID numero che viene utilizzato per i display (iniziare con 0 non è bello, per cui in generale l'id e' n.matrice + 1) ;
2 (u8Vserviceid) il numero del servizio da passare per ottenere la tensione
3 (u8Iserviceid) il numero del servizio per ottenere la corrente
4 (u8SWid)il numero del servizio dello switch che connette l'accumulatore al carico
5 (u8accumgood) il flag che indica che l'accumulatore è in buone condizioni è deve essere inserito nel ciclo di alimentazione
6 (u8autoserv)il flag che indica la rimessa in servizio automatica dell'accumulatore  (prima era scarico era stato messo fuori servizio automaticamente, se adesso e' carico lo rimetto in servizio automanticamente o aspetto un consenso manuale?)
si possono aggiungere informazioni quali valore tensione minima, massima, carico medio nel periodo, etc.
Questa matrice di parametri di definizione (0,1,2,3,4,5,6), e'caricata in fase di boot dal file ACCDESC.TXT ( tramite vInitAccuValue definita in pmsycommon.c ).
Quando per una batteria voglio saper che tensione c'e' invoco dreadsensor passando u8Vserviceid e ottengo la mia tensione, se vogli sapere lo stato dello switch invoco dreadsensor passando u8SWid e ottengo 1 o 0, etc.
In maniera equivalente ho la tabella dei carichi
uLoad[6] (definita in pmsycommon.c ) con 6 carichi, di cui attivi solo 2. Per ogni load è previsto:
0 ovviamente il suo numero di matrice
1 (u8aloadid)un ID numero che viene utilizzato per i display (iniziare con 0 non è bello, per cui in generale l'id e' n.matrice + 1) ;
2 (u8Vserviceid) il numero del servizio da passare per ottenere la tensione
3 (u8Iserviceid) il numero del servizio per ottenere la corrente
4 (u8SWid)il numero del servizio dello switch che connette l'accumulatore al carico
5 (u8loadgood) il flag che indica che il carico puo' essere attivato.
Anche qui si possono aggiungere altri tipi di informazioni relativi ai carichi.
Questa matrice di parametri di definizione (0,1,2,3,4,5), e'caricata in fase di boot dal file LOADESC.TXT ( tramite vInitLoadValue definita in pmsycommon.c ).

Simili solo gli switch, uSwitch[6] (definita in pmsycommon.c ), che al momento hanno una tabella di 6 elementi. Per ogni switch è previsto
0 ovviamente il suo numero di matrice
1 (u8switchid) un ID numero che viene utilizzato per i display
2 (u8SWWserviceid) il numero del servizio da passare per inviare il comando di switch
3 (u8SWRserviceid) numero da passare per sapere lo stato dello switch
4 (u8SWgood) flag di switch operativo.
Anche qui si possono aggiungere altri tipi di informazioni relativi ai carichi.
Questa matrice di parametri di definizione (0,1,2,3,4), e'caricata in fase di boot dal file SWDESC.TXT ( tramite vInitSwitchValue definita in pmsycommon.c ).

Per sensori la tabella e' più complicata e prevede una serie di parametri di funzionamento aggiustabili in corso d'opera, parte di questi parametri risiedono in eeprom e
vengono caricati in fase di boot 1)da codice la prima volta che viene eseguito (al momento tramite flag nel codice), 2) da eeprom tutte le altre volte.
Questi parametri possono essere modificati da pannello. uSensor[32] (definita in sysservice.c) prevede
0 il suo numero di matrice
1 (stype) con un numero che indica il tipo di sensore
   - SENSV tensione
   - SENSI corrente
   - SENSSW command switch
   - SENSDIG i/o digitale
   - SENSTEMP temperature
   - SENSHUM umidita'
   - SENSRESCNT contatore reset
   si possono aggiungere altri servizi)
2 (port) numero che indica quale porta usare per inviare/ricevere il dato
3 (vref) tensione di riferimento o digital negate
4 (r1) valore di r1 nei partitori di tensione, disponibile da codificare nel caso di altri sensori
5 (r2) valore di r2 nei partitori di tensione, disponibile da codificare nel caso di altri sensori
6 (lvconv) fattore di conversione in caso di tensione(per velocizzare i calcoli);disponibile da codificare nel caso di altri sensori
7 (ioffset) Current offset dell'acs758, disponibile da codificare nel caso di altri sensori
8 (iacs758sens) sensibilità dell'acs758, disponibile da codificare nel caso di altri sensori
le funzioni dreadsensor e dwritesensor utilizzando i dati di cui sopra sono in grado di fare tutti i calcoli per restituire i valori corretti.
I parametri in eeprom sono fissati in EEPROM_MAP.h e inizializzati in fase di boot da vParam_init.

Le porte uPort sono codificate in una tabella di costanti in memoria tramite in sysservice.c e semplicemento hanno
0 numero di matrice
1 slave
2 port

I file parametri non sono più a lunghezza fissa ma campi separati da ;

Le funzioni  impattate dalle modifiche sono state aggiustate per riflettere la nuova logica.
I menu per la consultazione di Accumulatori, Load, switch, e comandi di commutazione switch sono stati aggiornati. Ovviamente se non ti piaciono puoi modificarli.
Il menu per lettura/modifica dei valori eeprom si trova in 3.4
I menu' per la gestione dei parametri degli Accumulatori, Load, Switch sono ancora da implementare, per permettere di impostare i flag di accumulatore good, autoservice, load good, switch good.

L'orologio di sistema adesso è tutto software, ma al boot legge il clock dell'rtc, che nel mio caso si sballa alla velocità della luce, per cui volevo decidere
se sincronizzare l'rtc con quello di sistema o se cambiare l'rtc.

Il ciclo di switch degli accumulatori adesso verifica anche la tensione della batteria e se la tensione è sotto i 10V esclude la batteria dal giro. Devo ancora mettere a posto l'autoservice, ma è una sciocchezza.

Ho inserito il test che volevi per vedere la corrente del carico dopo lo switch e mi sembra che funzioni correttamente.
Non funziona lo switch del log dopo i 10K, forse mi sono mangiato un pezzo di codice. Adesso verifico.

Testiamo il tutto e poi se soddisfatti andiamo avanti con la parte di pianificazione giornaliera.