Gestione del “time stamp”

Il T89C51CC01 dispone di un timer a 16bit realizzato dai due registri “CAN- TIMH” e “CANTIML” per la gestione dello stamp dei messaggi (figura 5.4).

• Il contenuto di questi due registri viene caricato rispettivamente in “CANSTMPH” e “CANSTMPL” al ricevimento o all’invio di un frame.

• In ricezione la cattura avviene quando il flag “RxOK” di “CANSTCH” viene settato.

• In trasmissione quando il flag “TxOK” di “CANSTCH” viene settato.

• Con un clock a 16Mhz come quello impiegato nella CANinterface la condizione di overrun12 _{si verifica circa ogni 24.58ms ed il micro, se} configurato opportunamente, genera un interrupt 9.

tOV ERRU N = 0.375µs x 65536 = 24.58 [ms]

La finestra temporale gestita dal timer `e piuttosto limitata, associare ad ogni singolo messaggio un riferimento temporale di transito sul bus richiede qualche cosa in pi`u rispetto a tenere sotto controllo solo i registri CANSTMP; dopo 24.58ms di acquisizione cosa si f`a?

CANsoftware deve essere informato dell’overrun e questa comunicazione deve essere sincronizzata con l’invio dei messaggi in modo tale che i valori di time stamp trasmessi vengano pesati in modo corretto come si vede in figura 5.7 (si deve rispettare la sequenza cronologica degli eventi). MICROsoftware implementa questa funzionalit`a per mezzo dell’interrupt 9 che richiama la routine di servizio “can drv it overrun” riportata nel listato 5.1 a pagina 146. Questa procedura:

12_{Il termine “overrun” viene utilizzato per indicare la condizione di overflow del registro}

Capitolo 5. Il software di CANanalyser 144 03h E8h CANTIMH CANTIML 375us 7500us 1875us 3750us 4Eh 20h 13h 88h 27h 10h

Senza prevedere alcun meccanismo ad hoc quelli indicati lato sarebbero gli stamp da associare ai 4 messaggi.

L’ordine di arrivo non sarebbe rispettato.

Messaggio n.1

Messaggio n.2

Messaggio n.3

Messaggio n.4

Ordine di arrivo dei messaggi e ordine di invio al PC

Interrupt 9

FFh FFh

Interrupt 9

FFh FFh

Figura 5.7: MICROsoftware: sincronizzazione dei “CAN messagge” l’invio del comando di overrun.

• setta il bit “OvrRun” dell’ultimo elemento di “CodaRX” (Quello pun- tato dall’indice di inserimento “Ins”);

• se si `e verificato l’overflow dei canali o se il bit “OvrRun” precedente `e gi`a impostato si predispone (la variabile globale “OvrRunFlag” viene settata) per l’invio del comando di overrun per mezzo della funzione “send cmdOvrRun()”.

Quindi la condizione di “overrun” viene notificata a CANsoftware in due maniere: durante l’invio dei “CAN message” con il primo byte che contie- ne il bit “OvrRun” mostrato in figura 5.6 (CANsoftware controlla questo bit e se lo trova settato incrementa opportunamente la variabile che uti- lizza per gestire il “time stamp” assoluto dei messaggi), oppure attraverso l’invio di un “comando” cio`e di una sequenza di byte che CANsoftware ri- conosce ed utilizza per gestire di conseguenza la funzionalit`a. In figura 5.8 e 5.9 sono schematizzate le tre casistiche nelle quali `e necessario inviare il comando di overrun attraverso la funzione “send cmdOvrRun()” o il co- mando di “send cmdOvrBuf” precedentemente descritto; di seguito diamo la spiegazione dei tre casi a cui si st`a facendo riferimento.

• E’ necessario inviare il comando “send cmdOvrRun()” se l’overrun si `e verificano almeno due volte mentre “CodaRX” era vuota, sono cio`e passati pi`u di 49ms dalla ricezione dell’ultimo frame.

• Se “CodaRX” `e completamente occupata ed in questa condizione si ve- rifica l’overflow del CAN timer deve essere inviato il comando di overrun “send cmdOvrRun()” non prima per`o che siano stati inviati al PC tutti e 15 i canali, affinch´e anche in questo caso venga rispettata la sequenza cronologica degli eventi. E’ altres`ı necessario che lo svuotamento di tutte le mailbox avvenga prima che si verifichi un nuovo overflow del CAN timer13_.

• Se si `e verificato l’overflow dei canali le mailbox non vengono pi`u ria- bilitate e la coda viene mano a mano svuotata. La situazione `e simile alla precedente in cui per`o le mailbox erano tutte occupate ma non si era verificato l’overflow: se si verifica un overrun, al termine dello svuotamento dovrebbe essere inviato un “send cmdOvrRun()” in que- sto caso invece viene inviato un comando il comando di overflow tramite

13_{Nel caso peggiore l’invio di 15 canali richiede un tempo stimato in circa 23.18ms}

((1.5ms + 45µs) x 15) dove si sono considerati i tempi di esecuzione di 15 interrupt 7 e i tempi di invio di un messaggio composto da 16byte (1.5ms `e una stima in forte eccesso). Questo tempo `e inferiore a quello con cui si ripete ciclicamente l’overflow del timer

Capitolo 5. Il software di CANanalyser 146 Estrazione Inserimento CodaRX vuota 1 IDXCH_vuoto msb Not Used Not Used Not Used lsb Interrupt 9 n.1 Interrupt 9 n.2 send_cmOvrRun()

Figura 5.8: MICROsoftware: overrun in condizione di “CodaRX” vuota.

la funzione “send cmdOvrBuf” con cui si trasmette il valore attuale dei registri di time stamp. CANsoftware con questo dato e conoscendo i tempi di riabilitazione dell’interfaccia `e in grado di superare anche la condizione di overflow e fornire un riferimento di tempo assoluto.

1 void can_drv_it_overrun ( void ) 2 {

3 Uchar ovr ;

4

5 if (( ElemCodaRX == DIM_CODARX ) || OvrBufFlag )

6 OvrRunFlag = 1;

7 else

8 {

9 ovr = CodaRX [ Ins ] & 0 x10 ;

10 if (! ovr ) 11 CodaRX [ Ins ] |= 0 x10 ; 12 else 13 OvrRunFlag = 1; 14 } 15

16 CANGIT &= ∼MSK_CANGIT_OVRTIM ;

17 }

CodaRX piena Estrazione Inserimento 9h 0 Ah 0 Bh 0 Ch 1 4h 0 5h 0 6h 0 Fh 0 2h 1 3h 0 CodaRX Estrazione Inserimento Ah 0 Bh 0 Ch 1 4h 0 5h 0 send_msg_to_pc(1) send_msg_to_pc(2) send_msg_to_pc(3) send_msg_to_pc(4) send_msg_to_pc(5) send_msg_to_pc(1) send_msg_to_pc(2) send_msg_to_pc(8) send_msg_to_pc(9) send_msg_to_pc(10) send_msg_to_pc(15) send_msg_to_pc(14) send_msg_to_pc(13) send_msg_to_pc(12) send_msg_to_pc(11)

Interrupt 9 send_cmOvrRun(16) Interrupt 9 send_cmOvrBuf(6)

Interrupt 9 send_cmOvrBuf(7)

Figura 5.9: MICROsoftware: overrun in condizione di “CodaRX” piena.