picmicro675:
Progetto modellismo ferroviario Enea
********************************************************************************
Secondo la mia visione e come è stato iniziato si potrebbe disegnare come segue:
1) una console operatore supportata da un micro che gestisce la comunicazione
con altri 5 micro-controllori, designati come slaves.
Per questo si avrà un micro ad interfaccia operatore assegnato come master
per una comunicazione I2C con i 5 slaves.
2) Per la console si prevede un display 16x2 caratteri, alcuni pulsanti ed
eventuali potenziometri per regolazione lineare di alcune uscite.
3) Gli slaves possono avere ingressi ed uscite programmate dal master. Il quale
determina le operazioni tramite una stringa di bytes con la comunicazione I2C.
4) Quindi gli slaves possono avere una uscita in modulazione di ampiezza (PWM)
che gestisce la velocità dei locomotori per un certo ramo da governare.
Ci possono essere anche un o più canali analogici per il controllo di velocitÃ
magari differenziati in entrambe i sensi.
Ci possono essere canali digitali per ingressi. Quindi possiamo prevedere
che una porta sia assegnata a quello. Preferibilmente la PORTB che offre
l' utilizzo di interrupt, che si possono configurare con la apposita routine
Basi di sviluppo del programma
********************************************************************************
a) Il master interroga in ciclo gli slaves, aggiorna l' LCD e legge i segnali di
interfaccia con l' operatore.
Questo implica che ci sia una trasmissione di dati a sufficienza per determinare
quali operazioni eseguire.
b) Gli slaves prendono il pacchetto e controllano che non ci siano stati difetti
durante la comunicazione.
Per questo è buona intenzione mettere un controllo di integrità del pacchetto
ricevuto e rimetterlo al master.
c) Gli slaves hanno la capacità di porre in atto i valori acquisiti ai rispettivi
piedini e anche di aggiornare i valori dei piedini di ingressi.
Disegno di un pacchetto di comunicazione
********************************************************************************
Suddivisione del pacchetto
z) 1 word per impostazione del canale PWM dello slave-
Dovrebbe contenere il valore da scrivere direttamente nel registro di PWM.
Il master dovrebbe fare il calcolo per riportare il valore, che magari si
vuole vedere in percentuale. Eventualmente si potrebbe far passare il calcolo
ad ogni slave per alleviare il volume di lavoro del master.
v) 1 o 2 word di ritorno per lettura analogica-
Similmente a quanto detto per controllo PWM, si possono prendere delle letture
analogiche dagli ingressi degli slave. Forse per poter gestire singolarmente
la velocità di ogni ramo. Addirittura potrebbe anche essere girato direttamente
al controllo PWM e dare solo l' informazione al master del valore impostato.
u) 1 byte per segnali digitali in ingresso, indirizzabile direttamente a PORTB
Dal master si possono prendere valori da rilevare alla PORTB, quali finecorsa
e/o pulsanti.
In locale si potrebbe implementare una routine di antirimbalzo e quindi dare
il segnale di ritorno al master.
t) 1 byte di segnali digitali in uscita, indirizzabile direttamente a PORTC
In questo modo il carico dello slave è minimo, per eseguire attuazioni del
tipo acceso spento.
s) 1 word per segnali di controllo, separato in singoli flags.
Flags utilizzabili per singolo bit che determinano alcuni stati di trasmissione
come: errori, mancato pacchetto, collisione, slave impegnato, salta un ciclo,
inizio fine di un temporizzatore.
r) 1 word per il controllo di validità pacchetto (CRC)
Semplice routine che determina se tutto il pacchetto è arrivato integro al
destinatario.
q) 1 o 2 word da assegnare a temporizzatori, del quale si potrebbe indicare lo
stato nella word del punto s.
p) 1 word per futuri sviluppi
Già con la word del punto s, si possono utilizzare molte varianti, comunque
ci potrebbero essere dei miglioramenti che alla fine danno ragione di aver
lasciato un po di spazio. Del resto potrebbe anche variare lo schema del
pacchetto per un modello più ampio, sempre che non inficia i tempi che si usa
per servire tutti gli slave.
Analisi di tempi di servizio
********************************************************************************
Sarebbe difficile determinare a priori quanto possa durare un ciclo principale.
Questo ciclo è quello che in fondo deve ripetersi all' infinito per servire tutte
le parti del progetto.
Si comincia a definire che ogni istruzione (in linguaggio macchina) prende un
microsecondo. Questo è determinato dal fatto di utilizzare solo l' oscillatore
interno a 4 MHz, che poi viene diviso per 4.
Seguendo le direttive che sono state scritte nella Application Note No. 736A,
della Microchip, si percepisce che la trasmissione avviene tramite hardware. In
questo modo, non ci sarebbero deterioramenti di trasmissione. Da ciò si calcola
che per la trasmissione di un pacchetto si avrà un tempo massimo di 8 x 12 bytes.
Questo si calcola che a 100 kHz di trasmissione si trasmette un byte in 9 impulsi
da 10 uS, quindi il calcolo Sarebbe 96 bytes x 90 us = 8640 uS. Arrotondiamo ad
un mS.
Ammesso di fare per tutti e cinque gli slaves, si dovrebbe impiegare un periodo
di 10 mS c.a.(calcolato che ci sarebbe anche la fase di risposta. Dando anche un
50% di margine tutti gli slaves saranno soddisfatti 15 mS.
Di seguito si considera l' elaborazione dei segnali ricevuti, che può essere
puramente intuitivo, ma diamone una figura di 2 mS (ovvero almeno 2000 istruzioni
macchina).
Possibile che alcuni calcoli siano a carico degli slaves, quindi anche per uno
slave, ci sono quasi 17 mS di tempo per operare, prima che necessiti di servire
la chiamata successiva dal master. Magari diventerà trasparente se si implementa
nella routine di servizio interruzione.
Di seguito il master potrebbe aver bisogno di un lavoro di aggiornamento della
console di comando, per questo si può stimare che il display e ingressi analogici
richiedano almeno 3 mS. Un caso particolare potrebbe essere quello di prendere
i segnali di ingresso di qualche pulsante. Coi i pulsanti si deve far fronte agli
effetti di vibrazione dei contatti, per evitarli si usa una sistema di filtro
da software. Questo consiste nel rilevare lo stato del pulsante che attiva un
contatore, fintanto che il pulsante rimane allo stato logico prefissato.
periodicamente si verificherà che il contatore del periodo abbia raggiunto il
valore voluto. Da questo punto si determina un segnale di validità . Se invece
lo stato logico cambia il contatore verrà azzerato e la verifica invalidata.
Per approssimazione, si considera che la stima è di 20 millisecondi per completare
un ciclo principale. Per tanto converrà mettere un ritardo per l' aggiornamento
del display, in modo da non intasare di richieste il controllore del dispositivo.
Questo no significa che il ritardo deve bloccare gli altri processi. Il metodo
da adottare è quello di controllore se il contatore del proprio processo ha raggiunto
o superato il valore richiesto.
Analisi di gestione eventi
********************************************************************************
Nella previsione che tutte funzioni possano avere una propria allocazione di
tempo, è ragionevole utilizzare una base tempi che servirebbe ad indicare se un
evento ha raggiunto il periodo voluto.
Per questo c'è a disposizione 3 timers nell' hardware. Se il presente disegno non
avanza grandi pretese, consiglierei di prendere il Timer0 che utilizza 8 bit di
conteggio. Si può quindi impostare con il prescaler a 1:64 e la ricarica a 99,
che determina una interruzione ad ogni 10 millisecondi (approssimativamente).
Con questo metodo si scandisce le operazioni da servire in modo che procedano di
pari passo.
Visto che per fare tutte le funzioni si impiegano 20 millisecondi, si potrebbe
stabilire che per ogni singola funzione si alloca una cadenza di 30 mS. Ne
risulta che non ci dovrebbero essere sovrapposizioni tra le singole funzioni.
Si può capire che con l' interruzione a 10 mS, non si ha un carico eccessivo della
routine di servizio interruzioni. Anche dal fatto che il calcolo del contatore
prende un solo ciclo macchina. Per necessità di valori più piccoli si potrebbe
implementare una seconda variabile che calcola i millisecondi e le frazioni che
sono rilevate dal registro del TMR0.
Se si desidererà una cadenza più celere, allora si potrà cambiare il prescaler
a 1:32 e raddoppiare il contatore. Così da ottenere una cadenza di 5 mS, senza
appesantire il tempo di incremento della variabile di conteggio.
Eventualmente si potrebbe avviare anche il Timer1 a contare a ciclo continuo senza
attivare le interruzioni. Lo scopo sarebbe di prendere una misura di tempo non
superiore a 65535 microsecondi, che potrebbe servire come filtro anti-rimbalzo.
Oppure anche utilizzabile per determinare periodi minori al millisecondo.
Concluso.....
Se servono correzioni scrivetemi.
