Il Main del flusso di testing

Adesso verrà commentata la parte principale “main ( )” del programma che realizza il diagramma di flusso di testing descritto nel paragrafo 6.2.2.

………..

#define MICRO_16L //a seconda del microcontrollore impiegato selezionare il

//define associato //#dedime MICRO_128 // ………. int main(void) { ………..

Il preprocessore è un programma, o quella parte del compilatore, che si occupa di pre-elaborare un sorgente prima della compilazione vera e propria. In pratica, permette di generare un nuovo sorgente prima che questo venga compilato effettivamente.

L'utilità della presenza di un preprocessore, nle nostro firmware sta nella possibilità di definire gruppi di istruzioni alternativi a seconda del microcontrollore usato.

Quella sotto riportata è la sezione di preprocessore, le direttive difine interne all’istruzione ifdef/endif definiscono delle MACRO (ovvero simboli) ai quali vengono associati registri o ai pin di ciascun microcontrollore. Il preprocessore legge la

definizione della MACRO e, ogni volta che ne incontra il nome all'interno del file sorgente SOSTITUISCE al simbolo il corrispondente; a seconda della define attiva (MICRO_16L, MICRO_128) quindi verra compilata solamente l’istruzione ifdef relativa al microcontrollore selezionato.

………

*---*

#ifdef MICRO_16L

#define DDR_PWM DDRD #define DDR_SPI DDRB #define FOCA FOC1A #define FOCB FOC1B

#define SPIDI 6 // PB6 (pin7): data in (dati provenienti dall'accelerometro)

#define SPIDO 5 // PB5 (pin6): data out (dati inviati all'accelerometro)

#define SPICLK 7 // PB7 (pin8): clock

#define SPICS 4 // PB4 (pin5): accelerometro chip select

#endif

#ifdef MICRO_128

#define DDR_PWM DDRB #define FOCA COM1C1 #define FOCB COM1C0

#define SPIDI 3 // PB3 (pin13): data in (dati provenienti //dall'accelerometro)

#define SPIDO 2 // PB2 (pin12): data out (dati inviati all'accelerometro)

#define SPICLK 1 // PB1 (pin11): clock

#define SPICS 0 // PB0 (pin10): accelerometro chip select #endif

*---*

ADCL=0;

sbi(DDRA,1); //uscita per il controllo di direzione dei motori

sbi(PORTA,1); //fisso una direzione come avanti

adc_init(); //

SPI_init(); // SETUP delle porte ADC, SPI, PWM

pwm_init(); //

……….

E’ necessario, prima di avviare il ciclo relativo al diagramma di flusso, impostare i registri dell’accelerometro in modo che esso fornisca dati coerenti alle nostre esigenze.

Questa operazione viene fatta richiamando la funzionewrite_register( ) e andando a scrivere nei registri di configurazione (x20h, x21h, x22h)dell’ accelerometro come mostrato nelle rispettive tabelle sotto riportate.

Figura 86

……….

//---

register_name = 0x20; // setup del rgeistro CTRL_REG1 dell' accelerometro

data = 0b10000010; // frequenza 40Hz,attivati assi y

write_register(register_name,data);

Figura 87

……….

//---

register_name = 0x21; // setup del rgeistro CTRL_REG2 dell' accelerometro

data = 0b10000000; //pappresentazione su 12 bit,

Figura 88

………

//---

register_name = 0x22; // setup del rgeistro CTRL_REG3 dell' accelerometro

data = 0b01101011; //seleziono il clock interno

write_register(register_name,data);

//--- ……….

……….. ………

// INIZIO DEL FLUSSO DI TESTING

while(1) {

if(read_adc( )<Fmin) {

register_name =0x2B; // leggo OUTY_H

cbi(PORTB, 4); // pongo CS a 0 quindi attivo l'accelerometro

data_readz= spi_read(register_name); sbi(PORTB, 4); // pongo CS a 1

if(data_ready&2) //ciclo per determinare il segno dell’accelerazione

{ //controlla il terzo bit del registro SPSR (segno) se è

//1(negativo)mette sgn=1

cbi(PORTA,1); //PA1 è connesso al driver dei motori //all’ingresso che permette il controllo del

sgn=1; //senso di rotazione, se l’accelerazione è

}

else //negativa viene posta a livello basso se è

{

sbi(PORTA,1); //positiva viene posta a livello alto

sgn=0; }

register_name =0x2A; //leggo OUTY_L

cbi(PORTB, 4); // pongo CS a 0 quindi attivo l'accelerometro

data_readz= spi_read(register_name);

sbi(PORTB, 4); // pongo CS a 1 if(sgn= =1)

{

data_readz=~(data_readz-1); //complemento a 2 per trovare il modulo

} OCR1A=data_ready; OCR1B=data_ready; function_attiva(); } else { OCR1A= read_adc( ); OCR1B= read_adc( ); } } return(0); }

7. Alimentazione del prototipo.

L’ alimentazione del prototipo è necessariamente affidata ad un pacco batterie, nel valutare quale tipo di batterie fosse meglio impiegare sono stati considerati come parametri principali il basso peso ed ingombro. Ricercando tali caratteristiche nelle batterie presenti in commercio abbiamo scartato a priori il possibile utilizzo di accumulatori al piombo perché hanno un peso notevolmente superiore rispetto ad un equivalente realizzato con celle al l Ni/Mh o Li. Per avere un idea delle differenze di perso che si anno considerando il solito pacco ottenuto con batterie con diversa chimica si pensi che con batterie al piombo il peso del pacco risulta quasi il triplo rispetto a quelle al Ni/MH e il quasi il quintuplo rispetto a quelle al litio. In definitiva la nostra scelta è ricaduta su un pacco batterie costituito da 6 batterie al Li da 4.2V, questa scelta oltre ad ottimizzare le specifiche richieste ci permette di avere una fonte di energia più affidabile rispetto ad un equivalente ottenuto con tecnologia Ni/MH in quanto

quest’ultimo tipo di accumulatori è soggetto al fastidioso effetto memoria che ne limita notevolmente da durata, inoltre ha un impatto ambientale maggiore rispetto alle batterie al Li che risultano più ecocompatibile. In contropartita gli accumulatori al litio hanno attualmente un costo notevolmente maggiore rispetto a quelli al Ni/Mh ma vista l’attuale tendenza che li vede sempre più ampiamente impiegati nei dispositivi

elettronici portatili come cellulari e notebook si può ben ritenere che in breve tempo tale chimica andrà a sostituire totalmente quella al Ni/Mh permettendo così una sensibile riduzione di prezzo. Un aspetto di notevole interesse nella progettazione del sistema elettronico per la gestione del pacco batterie è quello di conferire a tale sistema l’abilità di testare il corretto funzionamento di ogni singola cella componente il pacco; questo permette: 1) in caso di mal funzionamento di escluderla dal pacco segnalando all’utente tramite un apposito display LCD la necessità di sostituirla 2) l’aumento della durata di utilizzo del pacco in quanto è possibile escludere la cella che ha esaurito la carica uniformando così la durata degli elementi. Questo tipo di gestione che potrebbe

sembrare inizialmente solo un costo aggiuntivo in quanto necessita di un’ elettronica di controllo dedicata, si rivela invece vantaggiosa perché consente l’abbattimento dei costi di manutenzione relativi alla sostituzione del pacco batterie in quanto, nel caso di guasto o malfunzionamento di una cella, si dovrebbe procedere con la sostituzione dell’intero pacco e non solo dell’elemento che provoca il malfunzionamento.