Riassunto della Tesi di Laurea Magistrale: Progettazione e

POLITECNICO DI TORINO
Corso di Laurea Magistrale
in Ingegneria Meccatronica
Tesi di Laurea Magistrale
Progettazione e realizzazione di hardware e software per l'acquisizione ed
elaborazione di dati da rete CAN di veicoli fuoristrada.
Relatore:
Candidato:
Prof. Cosimo Greco
Gianluca Franzini
Correlatore:
Ing. Alessio Facello
Anno Accademico 2014 / 2015
INDICE
1. Introduzione .................................................................................................. 2
2. CAN Bus ........................................................................................................ 5
3. Descrizione del sistema ................................................................................ 7
4. Hardware....................................................................................................... 8
4.1 Microcontroller Unit .................................................................................................... 9
4.1.1 ECAN Module ...................................................................................................... 10
4.1.2 USART Module .................................................................................................... 12
4.2 CAN Transceiver ....................................................................................................... 13
4.3 Bluetooth Module ....................................................................................................... 13
4.4 Alimentazione ............................................................................................................. 14
4.5 Schema Elettrico ........................................................................................................ 15
5. Software ....................................................................................................... 17
5.1 Il firmware .................................................................................................................. 17
5.1.1 Parametri di Bit Timing ...................................................................................... 19
5.1.2 Filtro dei messaggi ............................................................................................... 22
5.1.3 Gestione dei Messaggi .......................................................................................... 25
5.1.4 Parameter Group Number ................................................................................. 26
5.1.5 Esportazione dei dati ........................................................................................... 28
5.2 L’applicazione utente................................................................................................. 29
5.2.1 Vehicle Parameters Request ............................................................................... 30
5.2.2 Serial Port Setting ................................................................................................ 33
5.2.3 Filters setting ........................................................................................................ 33
5.3 Gli strumenti di sviluppo ........................................................................................... 35
5.3.1 L’ambiente di sviluppo MPLAB IDE ................................................................ 35
5.3.2 Il programmatore PICKIT 3 MICROCHIP ..................................................... 36
5.3.3 Il compilatore C CCS........................................................................................... 36
5.3.4 L’ambiente di sviluppo Microsoft Visual Basic 10 Express ............................. 37
5.3.5 Kvaser Database Editor ...................................................................................... 38
5.3.6 L’applicativo KiCad ............................................................................................ 38
6. Conclusioni .................................................................................................. 39
7. Appendici..................................................................................................... 41
7.1 La Demo Board .......................................................................................................... 41
7.3 Codice Firmware ........................................................................................................ 42
7.3.1 Comandi seriali .................................................................................................... 46
8. Riferimenti .................................................................................................. 47
8.1 Bibliografia ................................................................................................................. 47
8.2 Sitografia..................................................................................................................... 47
1. Introduzione
Il settore automobilistico - fin dalla sua nascita - ricopre un ruolo fondamentale per
l’economia mondiale. La sua caratteristica principale è quella di essere un settore in
continua evoluzione, e le grandi case automobilistiche fanno dell’innovazione la loro arma
principale.
L’evoluzione tecnologica è uno dei fattori fondamentali dello sviluppo dell’industria
automobilistica, e da molti anni l’informatica è presente nel mercato automobilistico sotto
forma di applicazioni software e apparecchi hardware di ogni tipo.
I grandi marchi presenti sul mercato hanno standard qualitativi sempre più elevati;
produttività e flessibilità nella produzione sono gli obiettivi principali, raggiungibili solo
tramite computer e software che, interagendo con l’utente, traducano le richieste in azioni
da far compiere agli apparecchi robotizzati.
Le automobili di nuova generazione sono dotate di veri e propri computer in grado di
gestire quasi tutti i componenti.
L’ultima frontiera è la possibilità che anche stando nell’abitacolo di un’autovettura si sia
connessi in rete aumentando sempre di più l’affidabilità e la sicurezza.
L'automobile moderna è monitorata e gestita da decine di unità di controllo elettroniche
(ECU) specifiche per i vari sottosistemi in cui è strutturata. In genere la più importante è
l'unità di controllo del motore (EMS - Engine Management System), mentre le altre sono
utilizzate per la trasmissione, il sistema d'antibloccaggio dei freni (ABS - Antilock Braking
System), gli airbags, il servosterzo elettrico, i sistemi audio, gli alzacristalli elettrici, la
chiusura centralizzata delle porte.
Per poter gestire nel modo più efficiente possibile questa enorme quantità di dati – che
vengono scambiati dalle varie sottoparti del sistema con il compito di supervisionare sia i
componenti elettronici che meccanici – è necessaria la connettività. La rete CAN
(Controller-Area Network) è stata ideata per soddisfare questa esigenza al fine di
centralizzare ed elaborare le informazioni in modo da semplificare ed ottimizzare la
gestione del veicolo e ottenere importanti vantaggi sia nella fase di test che in quella di
utilizzo, non trascurando quella di manutenzione.
Obiettivo di questa tesi è di progettare un sistema che sia in grado di acquisire
autonomamente i parametri operativi di un veicolo fuoristrada che sono inviati sul CAN
Bus dai dispositivi di controllo. Nel caso specifico il fuoristrada in esame è una trattrice
2
agricola dell’Istituto CNR - IMAMOTER di Torino e l’utilizzo dei dati acquisiti è
finalizzato alla visualizzazione e registrazione dei parametri richiesti per una successiva
analisi ed ottimizzazione delle prestazioni del suddetto veicolo anche in termini di
efficienza energetica.
L’idea di base è dare la possibilità che i dati rilevati dalla centralina del veicolo sulla rete
CAN possano essere filtrati, letti ed inviati ad un applicativo software presente su di un
computer (o su un dispositivo dotato di connettività wireless come smartphone o tablet) che
li tratterà opportunamente.
Una volta quindi identificato il modo di interfacciarsi con la rete CAN del veicolo e
sviluppato un firmware adeguato, è fondamentale realizzare fisicamente un dispositivo da
integrare nel sistema esistente. E’ in quest'ottica che s'inserisce il progetto di una scheda
elettronica che si occuperà dell’acquisizione dati secondo lo schema rappresentato in
Fig1.1, dove i dati in arrivo dal veicolo sono visualizzati dall’utente attraverso un apposito
software,
Sistema embedded a bordo fuoristrada
Scheda Acquisizione dati
Fig. 1.1: Schema rappresentativo del progetto
Si è pensato di realizzare la scheda elettronica seguendo la filosofia dei sistemi embedded,
architettura il cui compito è quello di eseguire operazioni molto specifiche, spesso con
vincoli sull'esecuzione in tempo reale: questa scelta permette di ridurre al minimo
l'hardware in termini di spazio, consumo e costo di realizzazione.
3
Questi dispositivi si sono evoluti recentemente virando sulla creazione di architetture
modulari che permettono il riutilizzo delle risorse disponibili. In questo modo si ottengono
comunque dispositivi ottimizzati, ma in grado di mantenere un certo tipo di flessibilità nello
sviluppo delle applicazioni, allargando quindi lo spettro dei possibili impieghi.
Ed è secondo questi principi che nei prossimi capitoli verrà discussa nei particolari la
progettazione della scheda di acquisizione dati evidenziando sia i perché delle scelte che le
caratteristiche dei singoli componenti hardware utilizzati.
Per quanto riguarda la parte software, sarà descritto in dettaglio dando enfasi ad alcuni
aspetti del codice, in particolare la sezione di campionatura dei dati. Infine sarà data enfasi
alla elaborazione dei dati ottenuti e alla loro visualizzazione durante la descrizione
dell’applicazione utente.
4
2. CAN Bus
Il CAN bus è uno standard seriale per bus di campo progettato per collegare diverse unità di
controllo elettronico (ECU). E’ un sistema Multi-Master: ciò significa che qualsiasi nodo
può trasmettere dati e che più nodi possono richiedere il bus contemporaneamente.
Il protocollo Controller Area Network (CAN) definisce il livello di collegamento dati e
parte dal livello fisico del modello OSI, che consiste di sette strati. Questo standard descrive
principalmente lo strato (layer) di scambio dati (data link layer), e da alcuni aspetti dello
strato fisico (physical layer) descritto dal modello ISO/OSI, mentre i protocolli di tutti gli
altri layer sono lasciati alla libera scelta del progettista della rete.
In particolare, il livello fisico definisce la tensione specifica e il tipo di cavo da utilizzare
per i protocolli di trasmissione. Gestisce la trasmissione dei bits da un dispositivo all'altro e
ne regola il flusso. Si occupa della codifica e decodifica dei bit (Non-Return-to-Zero NRZ),
del bit-timing e della sincronizzazione.
Il livello di collegamento dati (data link layer), fornisce i mezzi funzionali e procedurali per
trasferire i dati (frame) tra i dispositivi di rete, per rilevare ed eventualmente correggere
errori che possano verificarsi nello stato fisico.
Fisicamente, il bus CAN è una classica linea bifilare costituita da un doppino twistato per
ridurre fenomeni di diafonia.
L'accesso al bus in CAN è del tipo CSMA/CD (Carrier Sense Multiple Access/Bitwise
Arbitration) ciò significa che i nodi della rete devono monitorare il bus attendendo che
questo si porti in stato di Idle prima di tentare di trasmettere un messaggio (Carrier Sense).
5
Quando il bus è in Idle ogni nodo può tentare di inviare le proprie informazioni
impossessandosi del bus stesso (Multiple Access). Se i due nodi iniziano la trasmissione
nello stesso momento questi rileveranno una collisione e si comporteranno di conseguenza.
La comunicazione tra i vari nodi avviene tramite la trasmissione di frames (o più
semplicemente messaggi). Essi si dividono in quattro tipi:

Data frame: frame contenente i dati che il nodo trasmette. La cui composizione in
bits è raffigurata in Figura 2.1

Remote frame: frame che richiede la trasmissione di un determinato identificatore.

Error frame: frame trasmesso da un qualsiasi nodo che ha rilevato un errore.

Overload frame: frame che introduce un ritardo fra data frame e/o remote frame
Figura 2.1
Di norma in una rete i diversi nodi sono individuati tramite un indirizzo, presente in ogni
pacchetto che viene affidato alla rete. I pacchetti CAN non hanno indirizzi. In alternativa
essi contengono un campo noto come identificatore del contenuto del messaggio, unico in
tutta la rete, che svolge il ruolo dell'indirizzo.
La strategia utilizzata permette di lavorare in multicast: tutti i nodi ricevono il messaggio.
Molti, se interessati all'informazione, possono acquisirla contemporaneamente e questo si
traduce, a livello di rete, in effettivo aumento di efficienza.
Un altro vantaggio è legato alla strategia: nodi che sono solo ricevitori, possono essere
aggiunti o tolti senza particolari problemi dalla rete, che risulta quindi flessibile e modulare.
6
3. Descrizione del sistema
Il sistema di acquisizione dati è essenzialmente costituito da un microcontroller PIC
("Peripheral Interface Controller"). Nella progettazione del sistema si è scelto un PIC che
avesse integrato il modulo di interfaccia e gestione del protocollo CAN (ECAN) e il modulo
di gestione della porta seriale (USART): due moduli necessari per semplificare il lavoro di
progetto.
Per la programmazione del microcontroller si è optato per un linguaggio ad alto livello
come il linguaggio C, in quanto sono disponibili delle librerie specifiche sia per la gestione
dell’interfaccia alla Rete CAN sia per quella seriale. Questa scelta solleva il progettista da
una più complessa programmazione in assembler e anche dalla necessità di un’approfondita
conoscenza dei registri interni al PIC, permettendo così uno sviluppo più rapido e sicuro.
Mentre la parte di elaborazione dati è costituita da un’applicazione windows, sviluppata in
Visual Basic, in grado di richiedere i dati attraverso la porta seriale virtuale del PC per
visualizzarli sullo schermo.
7
4. Hardware
L’hardware è costituito da un Microcontroller PIC 18F26K80, da un Can Tranceiver
MCP2551, dal modulo di interfaccia seriale wireless HC-05 Bluetooth e dalla circuiteria di
base. La scelta del PIC 18F26K80 è dovuta al fatto che è integrato al suo interno il modulo
ECAN che permette di gestire i messaggi CAN in entrambe le versioni di identificatore
(standard ed esteso). Si è utilizzato l’MCP2551 per il rispetto delle specifiche richieste dalla
comunicazione CAN. Mentre la scelta del collegamento bluetooth è dovuta sia alla
semplicità del collegamento, nello specifico del modulo HC-05 Bluetooth il cui costo è
risibile, sia al fatto di non avere la necessità di connessioni a lunghe distanze.
PC
Bluetooth
Microcontroller
PIC 18F26k80
CAN
Transceiver
CAN BUS
VCC
Alimentazione Scheda
Fig. 4.1: Schema a blocchi hardware
8
4.1 Microcontroller Unit
Il Microcontroller è il cuore della scheda di interfaccia tra la rete CAN e la porta seriale del
PC. Esso è rappresentato con la sua circuiteria esterna in Figura 4.1
Figura 4.1 PIC 18F26K80
Si tratta di un Risc PIC 18F26K80 con 48K di memoria programma, 3K di memoria dati e
1K di memoria dati EEPROM. Trattandosi di un RISC con struttura Hardward l'area di
memoria è divisa in due parti: la Memoria Programma (Program Memory), in tecnologia
Flash e la Memoria Data (Data Memory), in tecnologia RAM CMOS
I PIC della famiglia 18F utilizzano la struttura Harvard, dove i due tipi di memoria sopra
elencati sono dipendenti da due bus diversi. La Memoria Programma è l'area dove
vengono posti i codici operativi (opcodes) e i vari elementi del programma. Si tratta di
memoria del tipo FLASH, non volatile, ovvero che conserva il dato contenuto anche se
viene a mancare la tensione di alimentazione. Inoltre è scrivibile e cancellabile
elettricamente, con la possibilità di operare sull'area dall'interno del programma stesso, con
un evidente ampliamento delle possibili gestioni automatiche del firmware (update, auto
9
apprendimento, bootloader, etc). Mentre la Memoria Dati tipicamente è una RAM statica,
volatile, ovvero che perde i dati contenuti al mancare della tensione di alimentazione.
Questa RAM contiene una serie di registri di uso generico, detti GPR - General Purpose
Registers, cioè locazioni ampie un byte (8 bit) il cui contenuto può essere scritto e letto
attraverso le istruzioni del programma e dedicate a contenere le variabili utilizzate. Inoltre
nell' area RAM si trovano i registri di controllo delle funzioni del processore e dell'I/O
integrato, detti SFR - Special Function Registers.
La programmazione del PIC avviene attraverso un connettore ICSP acronimo
di In Circuit Serial Programming che evita la sua rimozione del PIC dal circuito nella fase
di debug, in Figura 4.1 sono interessati i pin connessi 1, 27 e 28. L’acquisizione dati
avviene sui pin 23 e 24 che si occupano della trasmissione e ricezione verso e dal CAN Bus,
mentre i pin 6 e 7 sono interessati per comunicare sulla seriale.
Nel PIC 18F26K80 è stato implementato un raffinato sistema di generazione del clock
senza utilizzare componenti esterni. L’oscillatore impiega una circuiteria interna e solo
alcuni valori sono programmabili con un rapporto fisso (16, 8, 4, 1MHz, 500, 250, 125 e
31kHz) ed ha il vantaggio di non richiedere alcun componente esterno con una buona
precisione del clock generato compresa tra ± 1%.
La frequenza base del clock interno (INTOSC) è di 16MHz e l'aggiunta del postscaler
permette di ottenere gli altri 7 valori inferiori. Va notato che il valore di default a cui parte il
microcontrollore dopo un RESET è 8MHz: sarà possibile poi da software scegliere
eventualmente un'altra frequenza tra quelle disponibili.
4.1.1 ECAN Module
Il PIC18F26K80 integra un modulo CAN denominato ECAN (Enhanced Controller Area
Network) compatibile con le specifiche CAN 2.0A e CAN 2.0B e supporta sia la modalità
standard che estesa. Il modulo ECAN può essere impostato su tre modalità di
funzionamento:

mode 0: Legacy mode (compatibile con la serie PIC18Cxx8)

mode 1: modalità enhanced

mode 2: modalità FIFO con supporto DeviceNet
A seconda della modalità è in grado di gestire più buffer di ricezione e di trasmissione,
nonché un diverso numero di maschere e filtri.
10
Ogni modalità di funzionamento possiede sei modi di operare:

Configuration mode: ogni volta che bisogna inizializzare il modulo ECAN,
............scrivere una maschera od un filtro è necessario prima impostare questa modalità.

Disable mode: tale modalità disabilita sia il modulo di ricezione che di trasmissione

Normal operation mode: viene normalmente utilizzata nelle normali fasi di
............trasmissione e ricezione dei messaggi

Listen Only mode: rappresenta una modalità “silenziosa”, ovvero il modulo ECAN
............è impostato solo in ricezione e non trasmetterà nulla sul bus.

Loopback mode: permette di collegare la linea di trasmissione del PIC con la linea
............di ricezione, questa modalità può risultare utile per ragioni didattiche o di diagnosi.

Error Recognition mode: per mezzo di questa modalità il modulo ECAN viene
............impostato in maniera tale da ricevere tutti i messaggi ignorando ogni errore. Questa
............modalità può risultare particolarmente utile in fase di diagnosi.
Figura 4.2 Modulo ECAN
Come descritto nella Figura 4.2 il modulo ECAN implementa tre buffer dedicati alla
trasmissione TXB0, TXB1 e TXB2. I messaggi da inviare sono in una coda di priorità che
al momento dell’invio, il Message Queue Control discrimina quale buffer verrà messo in
trasmissione. Per la ricezione dei messaggi vengono utilizzati due buffer, RXB0 e RXB1
11
ognuno con associato più filtri di accettazione messaggio. Tutti i messaggi ricevuti sono
assemblati nel Message Assembly Buffer (MAB) e qualora soddisfino i filtri di accettazione
predisposti saranno spostati nei buffers di ricezione.
4.1.2 USART Module
Il modulo USART (Universal Synchronous Asynchronous Receiver Transmitter) è
l’hardware dedicato all’interfaccia per la comunicazione seriale. Il fatto che sia integrato nel
PIC18F26K80, permette al microcontroller stesso di eseguire altre operazioni mentre i dati
sono inviati all’USART e di poter gestire i dati in ricezione su interrupt. Nella Figura 4.3 è
rappresentato lo schema a blocchi della ricezione dati da cui si comprende che per settare il
baud rate è necessario inizializzare i registri SPBRGHx e SPBRGx. Così facendo si potrà
ottenere il baud rate desiderato ed abilitare RcxIE qualora si desiderasse ottenere un
interrupt alla ricezione del dato.
Fig. 4.3 USART Module
Sono disponibili funzioni delle librerie C per selezionare da programma il baud rate e il
formato dei dati, nonché i comandi di scrittura e lettura sul canale seriale e di gestione
dell’interrupt. Queste librerie verranno riportate nella descrizione del software di progetto
nella sezione riguardante il compilatore del linguaggio C: CCS-C
12
4.2 CAN Transceiver
Il transceiver è un convertitore di livello, converte il segnale generato dal CAN Controller
in un segnale adatto alla trasmissione sul cavo del CAN Bus. A questo scopo é stato
utilizzato per il progetto il CAN Transceiver MCP2551 che implementa il ‘physical layer’
del CAN Bus ed ha caratteristiche adatte per convertire segnali CMOS/TTL in formato
CAN.
In figura 4.4 sono da evidenziare il segnale TXD in uscita dal PIC e il segnale RXD in input
verso il PIC, e le doppie linee dedicate per la comunicazione del CAN bus: CANH e
CANL.
Figura 4.4
4.3 Bluetooth Module
Bluetooth è uno standard di comunicazione radio a corto raggio tramite il quale si possono
connettere dispositivi elettronici in modalità wireless (senza fili). Il modulo bluetooth
utilizzato per il progetto è un HC-05 Wireless Bluetooth Transceiver Module Slave 4Pin
Serial riportato in Figura 4.5, scelto per il costo irrisorio e per le basse distanze di copertura.
I pins di trasmissione TX e ricezione RX vanno direttamente collegati invertiti ai pins TX e
RX del PIC18F26K80
Figura 4.5
13
4.4 Alimentazione
Il circuito in progetto necessita per i suoi componenti elettronici una tensione di
alimentazione di 5 Volt; prevedendo una sorgente di alimentazione esterna di 12 Volt a
bordo del veicolo, si è reso necessario l’utilizzo di un regolatore di tensione: si è adottato il
circuito integrato LM7805. Il circuito integrato LM7805, è dotato di tre terminali con una
tensione di uscita fissa a 5V ed è contenuto nei classici contenitori TO220, adatti per essere
connessi ad un dissipatore di calore. Questo tipo di stabilizzatore è molto versatile in quanto
utilizza una corrente interna di limitazione. Presenta caratteristiche di shut down termico ed
una efficace protezione dell'area operativa, che li rende praticamente indistruttibili.
Il collegamento da effettuare è di facile realizzazione come evidenziato dallo schema
utilizzato per il progetto riportato in Figura 4.6. La presenza di condensatori serve per
evitare che delle auto-oscillazioni sorgano nel circuito danneggiando i componenti. Mentre
il diodo in ingresso ha la funzione di protezione da tensioni di Breakdown nel caso di
accidentali tensioni inverse in ingresso. In questa maniera otterremo un circuito con una
uscita nominale pari a 5 volt.
Figura 4.6 Schema elettrico alimentazione scheda
14
4.5 Schema Elettrico
Lo schema elettrico riportato in Figura 4.7 e la relativa Printed Circuit Board (PCB) in
Figura 4.8 sono stati progettati con l'ausilio di KiCad, un software free per la realizzazione
di circuiti elettronici.
Nel disegno dello schema elettrico, oltre ai collegamenti elettrici con i componenti già
descritti, sono state progettate delle piedinature aggiuntive per futuri sviluppi. Queste
piedinature consentono di disporre di interfacce sia analogiche che digitali connesse con il
microcontroller, ma anche l’utilizzo di led di segnalazione dell’operatività del sistema.
Figura 4.7 Schema Elettrico
Il progetto del circuito stampato (PCB) in fig.4.8 presenta dimensioni rispettivamente di
66x57mm. E’ stato progettato in modo tale che il posizionamento dei componenti e le loro
relative piste di connessione stiano su una sola faccia dello stampato. A tal fine si è
15
introdotto un jumper per poter permettere il collegamento a massa di tutto il piano
interessato.
Come si può notare dallo schema, si è introdotta la possibilità di inserire tre diodi led: il
primo con lo scopo di verificare la presenza dell’alimentazione nel circuito, il secondo con
lo scopo di diagnosticare la presenza di messaggi di ricezione sulla rete CAN, mentre il
terzo dà la possibilità di sviluppi futuri. Il connettore di interfaccia P3 permette di inserire
dal lato destro il bluetooth mentre dal lato sinistro la seriale.
Figura 4.8 Circuito Stampato
16
5. Software
La parte software del progetto è costituita da un firmware che verrà caricato sul
Microcontroller per l’acquisizione dei dati dalla rete CAN e da un’applicazione su PC che
richiederà i dati al Microcontroller. I dati acquisiti verranno interpretati utilizzando un
Database con la descrizione dei singoli parametri e visualizzati su schermo.
5.1 Il firmware
Il firmware che viene caricato nella memoria del microcontroller PIC18F26K80 è stato
progettato per eseguire compiti essenziali quali: ricezione dei messaggi CAN ed
acquisizione degli stessi in memoria, sempre aggiornati agli ultimi ricevuti, al fine poi di
fornirli, su richiesta, all’utilizzatore finale. Per fare questo l’applicativo dispone di un buffer
opportunamente dimensionato in cui sono tenuti i dati campionati a disposizione per le
richieste utente; ed inoltre il firmware fornisce la possibilità di settare i filtri dei messaggi, a
run time, su comando utente.
L’applicazione opera esclusivamente su interrupts. Un tipo di interrupt viene attivato della
presenza di un messaggio CAN da acquisire nel buffer di ricezione. Mentre un altro tipo di
interrupt viene attivato per soddisfare una richiesta utente proveniente dal collegamento
seriale.
L’applicativo può essere visto come composto da due parti distinte in base alla loro
operatività: un Blocco Interfaccia Modulo ECAN e da un Blocco Interfaccia Utente.
Entrambi i blocchi si appoggiano ad un buffer di lavoro (Buffer Dati Campionati), come
riportato in Figura 5.1.
Blocco Interfaccia Utente
Buffer Dati
Campionati
Blocco Interfaccia
Modulo ECAN
Figura 5.1 Schema acquisizione dati
Il blocco Interfaccia Modulo ECAN gestisce il CAN Bus settando i parametri operativi e
elabora i messaggi ricevuti dalla rete registrandoli opportunamente nel buffer di lavoro.
17
Mentre il blocco Interfaccia Utente viene utilizzato per esportare i dati presenti nel buffer di
lavoro quando richiesti dall’utente.
Nella fase di start-up dell’applicazione, il Blocco Interfaccia Modulo ECAN riportato in
Figura 5.2, inizializza il modulo ECAN del microcontroller abilitando gli specifici
interrupts che saranno attivati nel momento in cui un messaggio valido sia presente nei suoi
due buffers di ricezione.
Si occupa anche di azzerare i filtri per l’accettazione dei messaggi in rete in modo di
permettere la ricezione di qualunque messaggio. Sarà dato all’utente la facoltà di
discriminare su quali messaggi eseguire la campionatura.
Altra fase importante dell’inizializzazione è quella di settare il corretto baud rate con cui
operare sul Can Bus, pena la non ricezione di alcun messaggio.
In fase di run time, il blocco si occupa di recuperare i messaggi ricevuti dalla rete ed
eseguire la loro corretta registrazione nel Buffer Dati Campionati: si tratta di un array di
strutture in cui ordinatamente vengono registrati i messaggi con il loro ID ed i dati
contenuti. I messaggi con il medesimo ID non saranno duplicati, ma riscritti in modo da
avere sempre l’ultimo ricevuto.
Gestore
Registrazione
Messaggi
CAN BUS
MODULO
ECAN
Buffer Dati
Campionati
Inizializzazione
Modulo ECAN
Figura 5.2 Schema Blocchi Acquisizione Dati
Il Blocco Interfaccia Utente ECAN, riportato in Figura 5.3, si occupa di gestire i comandi
provenienti dall’ applicazione utente che sono di due tipi: comando di richiesta di dati di
uno specifico messaggio CAN presente nel Buffer Dati Campionati ed il comando diretto al
Modulo ECAN di settaggio dei filtri dei messaggi CAN
18
MODULO
ECAN
Buffer Dati
Campionati
COMANDO
Gestore
Comandi
Utente
CAN BUS
Gestione Filtri
Figura 5.3 Schema Blocchi Interfaccia Utente
5.1.1 Parametri di Bit Timing
La corretta impostazione del parametro di Bit Timing è fondamentale affinché il nostro
sistema possa integrarsi nella rete CAN del veicolo con cui intendiamo connetterci. Tutti i
devices sul CAN Bus devono usare lo stesso bit rate, anche se ogni device ha una propria
frequenza di clock. I parametri richiesti dal modulo ECAN per interfacciarsi al CAN Bus
con il corretto Bit Rate devono essere memorizzati nei suoi registri: BRGCON1,
BRGCON2, BRGCON3.
Il flusso dei dati sul CAN Bus è determinata dal Nominal Bit Rate (NBR), definito come il
numero di bit trasmessi al secondo in una trasmissione ideale. Il suo inverso è il Nominal
Bit Timing e rappresenta il tempo occupato da un singolo bit, cioè il reciproco del NBR:
NBT = 1/NBR
L’ NBT consiste di 4 intervalli temporali di durata regolabile, espressa come multiplo di un
quanto di tempo (Time Quantum).
Qui è riportata la suddivisione del Bit Time:

Synchronization Segment (Sync_Seg): è la prima parte del bit time, che viene
............utilizzata per sincronizzare i vari nodi.

Propagation Time Segment (Prop_Seg): viene introdotto per compensare i ritardi
............nella trasmissione e nella ricezione dei bit.
19

Phase Segment 1 e 2 (Phase_Seg1 e Phase_Seg2): sono i due segmenti terminali del
............bit-time e vengono regolati in modo che la transizione fra di essi, sulla quale i nodi
............leggono il livello del Bus (Punto Di Campionamento), rispetti le esigenze di tutto
............l’hardware connesso al bus.
Ogni segmento è diviso in unità conosciute come Time Quantum il cui valore è fisso e
derivato dal periodo dell’oscillatore. I Time Quantum di ogni segmento possono variare da
1 a 8.La lunghezza in Time Quantum dei segmenti sono:

_ Sync_Seg è di 1 time quantum

_ Prop_Seg è programmabile da 1 a 8

_ Phase_Seg1 è programmabile da 1 a 8

_ Phase_Seg2 è programmabile da 2 a 8
Quindi il Nominal Bit Time è programmabile da un minimo di 8 ad un massimo di 25 time
quanta.
Conoscendo la velocità della rete CAN da interfacciare in Bit Rate e la frequenza del nostro
oscillatore è possibile campionare correttamente il Nominal Bit Time. Questo valore è
calcolabile manualmente utilizzando le formule, ma più rapidamente utilizzando un
applicativo MBTime che implementa le stesse formule. Questo strumento è conosciuto
come: Microchip CAN Bit Timing Calculator.
Utilizzando questo calcolatore e fornendogli in input il baud rate di 250 kbps del CAN Bus
al quale connettere il nostro sistema e associandogli la frequenza dell’oscillatore utilizzato
dal sistema stesso che è di 16 MHz, ci vengono forniti i parametri di Bit Timing e, derivati
da questi, i valori da memorizzare nei registri del PIC perché sia rispettato il corretto Bit
Timing. I valori ricavati sono riportati in Figura 5.4
20
Figura 5.4 Calcolo Bit Timing
21
5.1.2 Filtro dei messaggi
I messaggi che transitano su una rete CAN possono in alcuni casi risultare di poco interesse
per i nostri campionamenti. Essere in grado di filtrare solo le informazioni utili significa
ridurre il tempo macchina da dedicare alla loro gestione, nonché di ottimizzare le
dimensioni del Buffer Dati Campionati.
La soluzione è quella di fornire il processore di un filtro hardware, un CAN Bus controller
hardware che filtra i dati e coinvolge il Microcontroller solo con dati che sono di suo
interesse. Questo compito viene svolto all’interno del modulo ECAN del PIC 18F2680K
Il modulo ECAN usa dei filtri e delle maschere (mask) per determinare se un messaggio
ricevuto nella MAB (Message Assemby Buffer) debba essere caricato nel buffer di
ricezione. Ogniqualvolta un messaggio valido è ricevuto dalla MAB, il campo
identificazione del messaggio (ID message) è comparato col valore dei filtri e della
associata maschera, se corrisponde, il messaggio è caricato nell’appropriato buffer di
ricezione. Il ruolo delle maschere è quello di determinare quali bits dell’identificativo del
messaggio debbano essere comparati col filtro. La maschera deve essere pensata come una
collezione di bits che abilitano o disabilitano gli omologhi bits del filtro, se un bit della
maschera è settato a 0, quel bit nell’ID message corrispondente è automaticamente accettato
indipendentemente dal valore del bit del filtro. Segue un esempio esplicativo.
Progettiamo un filtro con valore: 00000000001 e una maschera con valore: 11111111111
Se nella MAB arrivassero i seguenti messaggi:
ID1 = 00000000001
ID2 = 00000000010
ID3 = 00000000011
ID4 = 00000000100
Con questo filtro, solo il messaggio ID1 verrebbe caricato nel buffer di ricezione.
Qualora, invece, usassimo una maschera coi seguenti valori: 11111111100, nel buffer di
ricezione sarebbero caricati ID1, ID2, ID3 perché come detto in precedenza i bit dell’ID
corrispondenti al bit di valore 0 della maschera sono automaticamente accettati
indipendentemente dal valore del filtro.
I filtri possono essere definiti nella fase di inizializzazione del modulo ECAN, ma possono
pure essere aggiornati in modo run time. Il codice di progetto eseguito nel Microprocessore
è in grado di gestire un comando utente con i parametri specifici per la configurazione dei
filtri. Per operare la nuova configurazione è necessario passare alla modalità Configuration
22
Mode ed utilizzare alcune funzionalità di libreria offerte dal compilatore C CCS che
andranno ad impostare gli specifici registri del modulo ECAN. Un esempio di codice è il
seguente in cui sono configurati i filtri in modo di accettare qualsiasi messaggio.
void SetFilters() {
can_set_mode (CAN_OP_CONFIG);
can_set_id (RX0MASK, CAN_MASK_ACCEPT_ALL, CAN_USE_EXTENDED_ID); //set mask 0
can_set_id (RX0FILTER0, 0, CAN_USE_EXTENDED_ID); //set filter 0 of mask 0
can_set_id (RX0FILTER1, 0, CAN_USE_EXTENDED_ID); //set filter 1 of mask 0
can_set_id (RX1MASK, CAN_MASK_ACCEPT_ALL, CAN_USE_EXTENDED_ID); //set mask 1
can_set_id (RX1FILTER2, 0, CAN_USE_EXTENDED_ID); //set filter 0 of mask 1
can_set_id (RX1FILTER3, 0, CAN_USE_EXTENDED_ID); //set filter 1 of mask 1
can_set_id (RX1FILTER4, 0, CAN_USE_EXTENDED_ID); //set filter 2 of mask 1
can_set_id (RX1FILTER5, 0, CAN_USE_EXTENDED_ID); //set filter 3 of mask 1
can_set_mode (CAN_OP_NORMAL);
}
Il processo di ricezione è schematizzato in Figura 5.5. Il microcontroller PIC 18F6K80
comprende due buffer di ricezione RXB0 e RXB1, con più filtri di accettazione per ognuno
dei due buffer. Una volta che un messaggio viene ricevuto, indipendentemente dal tipo di
ID e il numero di byte di dati, l'intero messaggio viene copiato nella MAB.
I messaggi ricevuti possono avere diverse priorità. RXB0 è il buffer con priorità più alta, e
ha due filtri programmabili di accettazione dei messaggi, RXF0 e RXF1, mentre il buffer
RXB1 con priorità inferiore ha quattro filtri programmabili di accettazione: RXF2, RXF3,
RXF4, e RXF5. Sono inoltre disponibili due maschere programmabili di accettazione,
RXM0 e RXM1, una per ogni buffer di ricezione.
23
Figure 5.5: Receive buffer block diagram
24
5.1.3 Gestione dei Messaggi
La presenza di un messaggio nel buffer di ricezione genera uno specifico interrupt software
che attiva la funzione associata che si occupa di gestire il messaggio. Due sono i buffer di
ricezione RXB0 e RXB1, e due sono gli interrupt da gestire, ma la funzione di gestione è la
stessa come si evince dal codice sotto riportato.
#INT_CANRX0
#INT_CANRX1
void canrx0_int() {
void canrx1_int() {
getCanMessage();
getCanMessage();
}
}
Questa funzione non entra nel merito del messaggio, ma si limita ad estrarlo dal buffer di
ricezione, ad identificarlo ed a ricopiarlo, memorizzandolo in una prestabilita posizione nel
Buffer Dati Campionati. Per far questo la funzione getCanMessage() utilizza la routine
getPos() a cui passa l’ID del messaggio. La funzione getPos(), a sua volta, gli ritorna un
indice, il quale indica la posizione nel Buffer Dati Campionati dove registrare il messaggio.
/* Function that extracts the message from CAN's buffer and put it in an array */
void getCanMessage(){
int32 rx_id;
int index;
int rx_len;
struct rx_stat rxstat;
char in_data[8];
int32 mask =0x00ffff00;
if ( can_kbhit() ) {
//if data is waiting in buffer...
if(can_getd(rx_id, &in_data[0], rx_len, rxstat)) {
rx_id =(rx_id&mask)>>8;
index = getPos(rx_id);
can_rx_buffer[index].ID = rx_id;
memcpy(can_rx_buffer[index].Data,&in_data[0],rx_len);
}
}
}
25
5.1.4 Parameter Group Number
L’identificazione dei singoli messaggi avviene attraverso la lettura del Parameter Group
Number (PGN) che è una parte dei 29 bit dell’identificativo del messaggio CAN, come
evidenziato in Figura 5.6
Figura 5.6 Struttura Frame CAN
Come da figura si nota che il PDU Format (PF) ed il PDU Specific (PS) sono entrambi
lunghi 8 bit, ma il valore del campo PS dipende dal valore del campo PF. Se quest’ultimo
ha un valore fra 0 e 239(EF hex), il campo PS contiene l’indirizzo di chi è il destinatario del
messaggio.
Nel caso invece che il campo PF è tra 240 e 255 si parla di Global PGN ed il campo PS
diventa un’estensione: una Group Extension (GE). Questi messaggi sono di tipo broadcast
con il campo GE che caratterizza il messaggio che viene inviato a tutti i nodi della rete.
Il PGN è un numero definito nello standard SAE J1939, identifica il gruppo a cui appartiene
il messaggio trasmesso e ne caratterizza i parametri, i cui valori sono presenti negli 8 byte
del data field del messaggio.
Le tabelle sotto riportate sono esplicative di quanto detto, descrivono il PGN 65262
(0xFEEE) ricavato dai documenti SAE.
26
Tabella 5.7
Se il PGN identifica il messaggio e la sua struttura dati, l’SPN sarà un numero sempre
definito dallo standard SAE J1939 è riportato in una tabella con la descrizione del singolo
parametro. Nella tabella sottostante è riportata, ad esempio, la descrizione di un parametro
SPN.
27
5.1.5 Esportazione dei dati
Lo scambio dati fra l’applicativo utente e il sistema di acquisizione dati avviene mediante
interfaccia seriale. L’applicativo utente invia un comando, all’arrivo di dati sul canale
seriale il sistema viene attivato da un interrupt a cui è associata la funzione che gestisce il
comando.
#INT_RDA
void isr_rs232(){
getCommand();
}
Al momento i comandi gestiti dalla funzione getCommand() sono di due tipi:
configurazione dei filtri per l’acquisizione dei messaggi o richiesta parametri del veicolo.
L’applicativo utente è progettato per richiedere i dati di un singolo messaggio alla volta. La
richiesta è caratterizzata dal PGN del messaggio di cui si intende ricevere i parametri. Il
sistema utilizza il PGN per la ricerca del messaggio richiesto nel suo buffer interno di
registrazione messaggi, se questo è presente ritornerà al richiedente gli 8 byte associati, in
caso contrario ritornerà la segnalazione di messaggio non campionato. La struttura del
Buffer Dati Campionati è la seguente:
.
#define CAN_RX_BUFFERS 50
struct Can_Buffer {
int32 ID;
BYTE Data[8];
};
28
5.2 L’applicazione utente
L’applicazione utente, alla quale è stato dato il nome CanDataRequestor, è progettata per
interfacciarsi al sistema di acquisizione dati e richiedere una serie ben definita di parametri
dal CAN Bus.
Si presenta con un’interfaccia grafica costituita, nella pagina principale, da una paginazione
tabulare dal titolo Vehicle Parameters Request, dove sono elencati i comandi di richiesta
parametri come da Figura 5.8. Mentre nella seconda pagina dal titolo: Filters setting vi è
implementato il comando di filtro dei messaggi rappresentato nella Figura 5.11. In fine
nella terza pagina si ha il comando per la connessione alla porta seriale come da Figura
5.10.
Figura 5.8 Vehicle Parameters Request
29
5.2.1 Vehicle Parameters Request
I parametri campionati dal sistema dei quali richiedere il valore sono visualizzati
dall’applicativo Visual Basic in una griglia e sono raggruppati per messaggio CAN che li
contiene. Ogni riga della pagina Vehicle Parameters Request è un comando verso il sistema
e selezionandola, viene confezionato il messaggio che sarà inviato sulla porta seriale. Il
comando è costituito dal valore numerico corrispondente al PGN del messaggio CAN di cui
si richiede i parametri. E’ pure possibile eseguire la richiesta in automatico ed in modo
ciclico sull’intera lista visualizzata attivando il bottone Start Inquiry che attiva un timer, il
quale ad intervalli regolari procede ad attivare il comando di richiesta parametri secondo la
sequenza presente a video.
I parametri campionati dal sistema per i quali è possibile richiederne il valore, sono indicati
nella specifica TextBox e solo quelli descritti in un file .dbc dal Database Kvaser Editor
come dall’esempio riportato in Figura 5.9
Figura 5.9 Kvaser Database Editor
30
Il valore dei parametri ritornato dal sistema connesso alla rete CAN richiede una
elaborazione prima di essere visualizzato, in quanto i valori acquisiti dal CAN Bus sono
stati registrati grezzi, come pervenuti da messaggio CAN, per ridurre i tempi di
acquisizione. In base allo standard SAE J1939-71 questi dati espressi in numero di bit
devono essere singolarmente estratti dagli 8 bytes di dati del messaggio CAN e convertiti in
parametri fisici secondo una precisa risoluzione riportata nel documento stesso e che è
specifica per ogni parametro. Questa operazione viene eseguita a livello utente,
dall’applicativo CanDataRequestor prima che il valore reale venga visualizzato utilizzando i
dati del Database, il quale per ogni parametro ne descrive la posizione e le dimensioni in
termini di bit, nonché la risoluzione e l’offset.
Supponiamo, come esempio esplicativo, che venga effettuata la richiesta dei parametri del
messaggio Electronic Engine Controller 1 - EEC1, caratterizzato da un PGN dal valore
0xF004.
Il parametro: Engine Speed, come registrato nel Kvaser Database e visualizzato pure dal
Kvaser Database Editor nella Figura 5.9, è descritto a partire dallo start bit 24 per una
lunghezza di 16 bit: quindi il suo valore è contenuto nel quarto e quinto byte dei dati del
messaggio in esame. Supponendo che il valore grezzo del parametro ritornato sia di
0x1ADF (6879 in decimale), ci basiamo per il calcolo del suo valore reale sulla tabella
SPN190 sotto riportata. , La tabella , i cui valori sono registrati nel Kvaser DB, ci dice che il
valore contenuto nel messaggio è interpretabile in 0,125 rpm per bit e l'offset è 0; per cui il
valore effettivo di questo parametro sarà: (6879 x 0,125) + 0 , quindi poco meno di 859,875
rpm, e questo sarà il valore del parametro Engine Speed a video.
spn190 - Engine Speed Data Length: 2 bytes
Resolution: 0.125 rpm/bit , 0 offset
Data Range: 0 to 8,031.875 rpm
Type: Measured
Suspect Parameter Number: 190
Parameter Group Number: [61444]
31
Di seguito è riportato il codice che estrae dalla stringa dei dati ricevuti i singoli parametri:
decimal = Convert.ToInt64(DataReceived16)
iPos = Index + 1
While (DataGridView1(cSignalName, iPos).Value() IsNot Nothing)
startBit = DataGridView1(cStartBit, iPos).Value()
length = DataGridView1(cLength, iPos).Value()
factor = DataGridView1(cFactor, iPos).Value()
offset = DataGridView1(cOffset, iPos).Value()
value = decimale
tmpValue = decimale
posX = max - startBit
posY = max - (startBit + length)
If startBit <> 0 Then
tmpValue = tmpValue >> posX
tmpValue = tmpValue << posX
value = value - tmpValue
End If
value = value >> posY
value = value * factor
value = value + offset
DataGridView1(cValue, iPos).Value() = CStr(value)
iPos = iPos + 1
End While
32
5.2.2 Serial Port Setting
L’interfaccia fisica fra l’applicativo utente ed il sistema di campionamento avviene via
RS232 in emulazione bluetooth. Il componente Visual Basic per comunicare con la seriale è
il SerialPort. Di seguito è ripotata la form per la richiesta di connessione il codice che la
gestisce.
Figura 5.10 Serial Port Setting
Private Sub btnConnect_Click(ByVal sender As System.Object, ByVal e As
System.EventArgs) Handles btnConnect.Click
SerialPort1.PortName = cmbPort.Text
'Set SerialPort1
SerialPort1.BaudRate = cmbBaud.Text
'Set Baud rate
'Other Serial Port Property
SerialPort1.Parity = IO.Ports.Parity.None
SerialPort1.StopBits = IO.Ports.StopBits.One
SerialPort1.DataBits = 8
'Open our serial port
SerialPort1.Open()
btnConnect.Enabled = False
'Disable Connect button
btnDisconnect.Enabled = True
'and Enable Disconnect button
End Sub
5.2.3 Filters setting
Si è ritenuto di utilità implementare un commando utente che permetta, a run-time, di
variare i filtri di accettazione dei messaggi: questo consente al sistema un alleggerimento di
carico di lavoro e di focalizzare l’attività di monitoraggio solo su alcuni parametri specifici
del veicolo. Il comando di filtraggio permette di inserire per i due buffer di ricezione RXB0
33
e RXB1 le rispettive maschere e i filtri. Qualora i campi maschera fossero settati a zero
sarebbero accettati tutti i messaggi in arrivo dalla rete CAN. Di seguito è riportata la form
con la richiesta del valore dei filtri e il codice che la gestisce.
Figura 5.11 Filters Setting
Private Sub setfilterButton_Click(ByVal sender As System.Object, ByVal e
AsSystem.EventArgs) Handles setfilterButton.Click)
Dim FilterCommand As String
FilterCommand = "," + TextBox31.Text + "," + TextBox32.Text + "," +
TextBox33.Text + "," + TextBox34.Text + "," + TextBox35.Text +"," +
TextBox36.Text + "," + TextBox37.Text + "," +TextBox38.Text + ","
SerialPort1.Write(FilterCommand & vbCr)
End Sub
34
5.3 Gli strumenti di sviluppo
Per quanto riguarda la realizzazione del firmware si è utilizzato l’ambiente di sviluppo
MPBLAB IDE ed il Compilatore e le Librerie CCS-C per PICmicro con l’ausilio del
programmatore PICKIT 3 per il caricamento e il debug del firmware nel microcontroller.
Mentre per lo sviluppo dell’applicazione utente è stato utilizzato l’ambiente di sviluppo
Microsoft Visual Basic 10 Express integrato con le librerie CANlib fornite da Kvaser per
accedere al Kvaser Database
5.3.1 L’ambiente di sviluppo MPLAB IDE
Per lo sviluppo del firmware per i PIC, Microchip mette a disposizione l’ambiente di
sviluppo MPLAB IDE (Integrated Development Environment), software per PC che
consente di gestire completamente il progetto del firmware di qualunque sistema basato su
microcontrollori della famiglia PIC.
MPLAB IDE è un ambiente di sviluppo di proprietà Microchip, gratuitamente fruibile dal
sito www.microchip.com, esso integra tutte le funzionalità di un ambiente classico. Si
differenzia per la possibilità di essere collegata tramite programmatore, ad esempio il
PICKIT al prototipo con montato il PIC, in questo modo si ottengono due vantaggi, non
presenta la necessità di dover staccare il PIC e collocarlo nel programmatore ed offre la
possibilità di debuggare il software in real-time posizionando i break point all'interno del
codice, osservando cosa accade nella memoria del PIC. MPLAB-IDE supporta in modalità
nativa l’Assembler di tutte le famiglie di PIC, questi assemblatori possono essere utilizzati
gratuitamente. Se invece si sceglie di adoperare i compilatori per il linguaggio C, bisogna
acquistare la licenza.
Come tutti i moderni sistemi di sviluppo, è basato sul concetto di Progetto: come
raccoglitore di tutti i file legati al progetto, in modo da dare ordine e organicità al lavoro.
Esso integra tutte le funzionalità di un ambiente classico come l’editor di testo, riconosce il
linguaggio adoperato evidenziando le keyword, presenta dei tool di sussidio molto utili.
Dispone di un compilatore che può essere invocato direttamente cliccando sull'icona Build e
offre anche la possibilità di debuggare il codice usando i breakpoint per proseguire step by
step nell'analisi del codice, osservando cosa accade nella memoria del PIC. L’editor di testo
è di tipo “intelligente” ovvero una volta determinato il tipo di file da editare, il programma
distingue le istruzioni programma dalle costanti, dalle variabili e dai commenti ed utilizza
diversi colori rendendo molto più leggibile il codice. MPLAB IDE si differenzia da un
35
classico ambiente di sviluppo per la possibilità di essere collegato tramite programmatore al
"target", la scheda sulla quale è inserito il PIC. In questo modo si può usare lo stesso
ambiente software sia per la scrittura del codice che per la programmazione e il testing.
5.3.2 Il programmatore PICKIT 3 MICROCHIP
Il programmatore utilizzato è il PICKIT 3, un programmatore/debugger real-time per PIC
che, utilizzando le funzioni di In-Circuit Debug (ICD), permette appunto di caricare i
programmi sul microcontrollore, eseguirli in tempo reale ed esaminarli in dettaglio con le
funzioni di debug di MPLAB IDE. Ovviamente, prima di procedere con la
programmazione, bisogna collegare PICKIT 3 tra il PC e il circuito sul quale è inserito il
PIC da programmare come da Figura 5.12. Esso agisce come una interfaccia/traduttore tra i
due, permettendo di eseguire il debug dell’applicazione caricata nel microcontrollore.
Figura 5.12
5.3.3 Il compilatore C CCS
CCS-C è un compilatore C per PICmicro, ottimizzato per l'utilizzo esclusivo con questi
dispositivi. Si pone come strumento di sviluppo potente ed economico; i files generati sono
selezionabili e compatibili con gli emulatori e programmatori per PIC più diffusi,
compreso MPLAB IDE della Microchip usato per questo progetto. Le caratteristiche
principali per cui è stato scelto sono la dotazione di librerie per l’I/O seriale RS232 e per la
gestione del Can Bus, nonché per la semplicità di integrazione con MPLAB IDE e altri
emulatori/simulatori per un debug a livello sorgente. Di seguito sono elencate le funzioni
utilizzate per il progetto divise per aree di operatività.
RS232 I/O:

#use rs232, questa direttiva dice al compilatore il baud rate e i pins usati per l’I/O della
......seriale.
36

gets(),questa funzione acquisisce una stringa dal pin di ricezione.

printf(),manda in output una stringa formattata sul pin di trasmissione.

#INT_RDA, una direttiva per il compilatore per la gestione della seriale: è l’interrupt
......che se abilitato attiva la routine di ricezione dati.
CAN Bus:

can_init(void), inizializza il modulo ECAN e di default azzera tutti i filtri e le
......maschere.

can_set_mode(), definisce in quale modalità il modulo ECAN deve operare, le modalità
......utilizzate dall’applicativo sono in base alle circostanze: Configuration mode, Normal
......operation mode e Loopback mode in alcune fasi di debug.

can_getd(), recupera un messaggio ricevuto da uno dei buffer CAN e salva il contenuto
......in area dati

can_set_id(), utilizzato per inizializzare i filtri e le maschere

#int_canrx0, una direttiva per il compilatore per la gestione dell’interrupt quando un
......messaggio è ricevuto nel buffer RXB0

#int_canrx1, una direttiva per il compilatore per la gestione dell’interrupt quando un
......messaggio è ricevuto nel buffer RXB1
5.3.4 L’ambiente di sviluppo Microsoft Visual Basic 10 Express
La scelta è caduta su questo IDE per la possibilità di utilizzare un prodotto libero da royalty
e costi di licenza, che permette di creare un’applicazione facilmente e velocemente.
Utilizzando Microsoft Visual Basic è possibile creare le cosiddette applicazioni Windows
Form, una superficie visiva sulla quale è possibile visualizzare informazioni per l'utente. Per
creare applicazioni di questo tipo, in genere si aggiungono i controlli nei forms e si
definiscono le risposte alle azioni degli utenti, ad esempio i clic con il mouse o le pressioni
dei tasti. Un controllo è un elemento separato dell'interfaccia utente che visualizza dati o
accetta input di dati ed è facilmente inseribile durante la progettazione. Utilizzando la
funzione di trascinamento è sufficiente selezionare i controlli con il cursore e aggiungerli
nel punto desiderato del form. Quando un utente esegue un'azione nel modulo o in uno dei
controlli, viene generato un evento. L'applicazione risponde a questi eventi utilizzando il
codice ed elabora gli eventi quando si verificano. Windows Form contiene diversi controlli
che possono essere inseriti nei forms, ad esempio i controlli che visualizzano caselle di
testo, pulsanti, caselle di riepilogo a discesa e pulsanti di opzione.
37
5.3.5 Kvaser Database Editor
Il Kvaser Database Editor permette di visualizzare, inserire o modificare nel Database le
definizioni dei messaggi CAN e la descrizione dei segnali associati. Ciascun segnale ha un
bit di inizio e fine, che vengono utilizzati per selezionare i bit corretti negli 8 byte di dati.
Kvaser mette a disposizione le librerie: CANlib, per accedere da programma alle
informazioni contenute nel DB.
5.3.6 L’applicativo KiCad
KiCad è un programma utilizzato per il progetto di circuiti stampati, è un software Open
Source che gira su più piattaforme compresa la piattaforma Windows. Esso permette la
gestione di tutte le fasi di lavoro con la stessa interfaccia: disegno circuitale e sbroglio PCB.
La procedura per lo sviluppo di una scheda con KiCad è la seguente: si verifica che i
componenti utilizzati nel progetto siano presenti nella libreria; nel caso non ci siano, si
procede con la loro creazione. Successivamente si procede a disegnare lo schema elettrico,
una volta terminato, occorre numerare e identificare ogni componente associandolo al
proprio simbolo reale nella netlist di KiCad in modo tale da impostare in maniera corretta
collegamenti e dimensioni dei componenti per circuito stampato.
Infine si procede con la creazione del circuito stampato, posizionando i componenti nel
modo più consono per ottenere tutti i collegamenti delle piste. Le piste possono essere
ottenute utilizzando una funzione di autoroute o operando manualmente. Come ultima
operazione si crea un piano di massa che collega tutti i GND dei componenti.
38
6. Conclusioni
Il progetto sviluppato si appoggia su strutture consolidate nel tempo quali i sistemi
embedded e la rete CAN, per cui la potenzialità e peculiarità di questo lavoro è stata quella
di agglomerare in un tutt’uno le conoscenze di elettronica ed informatica già acquisite od
indagate allo scopo, al fine specifico di acquisire dati dalla rete CAN.
La conoscenza della suddetta rete ha permesso di selezionare i componenti hardware più
performanti per le necessità progettuali, quale il Microcontroller PIC 18F26K80, dotato del
modulo interno ECAN di gestione del Can Bus. Infatti questo modulo solleva il progettista
dal doversi occupare di gestire il livello fisico della rete, cioè sia le caratteristiche fisiche ed
elettriche del bus sia quelle dell'hardware. Il modulo ECAN si occupa di convertire i
caratteri di un messaggio di trasmissione in segnali elettrici mentre per i messaggi in
ricezione converte i segnali elettrici in caratteri.
La scelta della tecnologia Bluetooth per lo scambio dati con l’utente finale è stata pensata
per avere un oggetto di facile posizionamento e di facile connessione evitando l’uso di cavi
di collegamento per la parte seriale del progetto, per esempio l’uso di uno smartphone.
La conoscenza del linguaggio C ha reso facile la scrittura del firmware, essendo questo il
linguaggio più utilizzato nei sistemi embedded oltre al linguaggio assembler. Il linguaggio
assembler è preferibile nei casi particolari in cui sia decisiva la velocità di elaborazione o si
utilizzi un microcontroller con poca memoria, e questo non era il nostro caso.
Di aiuto nella stesura del codice è stata la possibilità di utilizzare delle librerie C che
implementino funzioni di interfaccia CAN, nonché la possibilità di utilizzare i vari IDE in
commercio in versione free.
Nonostante le conoscenze e la vasta letteratura nel campo delle Reti CAN e del loro uso nel
campo Automotive, la progettazione del sistema di acquisizione dati non è stato un percorso
in discesa; inizialmente è stato realizzato un prototipo hardware e software che ha richiesto
tempo per essere funzionante. Nella prima fase si è proceduto per tentativi. Uno dei
rallentamenti è stato quello di riuscire a settare correttamente il Baud Rate nella
comunicazione con la rete CAN esistente, in quanto l’errato settaggio faceva sì che i
messaggi inviati non venissero rilevati dal sistema. Questa mancanza di segnale ha reso
difficile la
corretta
realizzazione
dell’intero
schema
elettrico
progettato; quando
l’hardware ha iniziato a eseguire il lavoro per cui era stato progettato, sono subentrati i
problemi software. Nello specifico la necessità di dover discriminare, nel blocco di 8 byte di
dati del messaggio ricevuto dalla rete, i valori dei singoli parametri ivi descritti. A questo
39
punto si è resa necessaria l’adozione di un database con la descrizione dei singoli messaggi
e dei dati da loro forniti, quali il posizionamento e la loro lunghezza in bit, e quindi la
progettazione di un software in grado di interrogarlo per produrre il risultato finale. Infine durante lo spacchettamento del blocco dati - si è evidenziata la non idoneità del linguaggio
Visual Basic, che per quanto riguardava lo sviluppo dell’interfaccia grafica era stato di
grande supporto.
Comunque per raggiungere l’obiettivo proposto, quello di avere un sistema per
l’acquisizione ed elaborazione di dati dalla rete CAN, si erano prospettate più strade sia
nella scelta della piattaforma hardware che software, e ne è stata percorsa una delle tante
praticabili.
L’innovazione di prodotto, aspetto molto importante nell’industria, richiede di essere critici
e propositivi verso il prodotto in gestione, ed ora che il progetto è arrivato a conclusione, si
può già pensare ad applicare allo stesso delle migliorie o già immaginare una sua
evoluzione. Pur non prevedendo un hardware diverso, è pensabile che il firmware possa
essere reso più performante utilizzando al meglio le potenzialità del microprocessore in uso.
Per quanto riguarda l’applicazione utente, si ritiene che questa possa essere migliorata come
grafica o riscritta anche in altri linguaggi più adatti alla complessità del trattamento e
dell’elaborazione dei dati ottenuti: uno dei quali potrebbe essere Matlab o Viewlab.
40
7. Appendici
7.1 La Demo Board
La Demo Board (Figura 7.1) è una semplice scheda su cui è stato sviluppato e testato il
circuito di progetto. In seguito è stato assemblato un prototipo (Figura 7.2) per eseguire i
test prima della messa in produzione.
Figura 7.1
Figura 7.2
41
7.3 Codice Firmware
#include <18F26K80.h>
#fuses INTRC,NOWDT, NOPROTECT, PUT, BROWNOUT
#use delay(internal=8000000)
#use rs232(baud=9600, xmit=PIN_C6, rcv=PIN_C7)
#include <can-18xxx8.c>
#include <stdio.h>
#include <stdlib.h>
#include <math.h>
#include "defines.h"
#define CAN_RX_BUFFERS 50
struct Can_Buffer {
int32 ID;
BYTE Data[8];
};
struct Can_Buffer can_rx_buffer[CAN_RX_BUFFERS];
char recvData[100];
void main() {
memset(can_rx_buffer,0x00,sizeof(struct Can_Buffer)*CAN_RX_BUFFERS);
can_init();
enable_interrupts(INT_CANRX0);
enable_interrupts(INT_CANRX1);
enable_interrupts(INT_RDA);
enable_interrupts(GLOBAL); //enable all interrupts
while(TRUE){
}
}
/* Function to convert hexadecimal to decimal. */
int32 hexToInt(char hex[])
{
int i, length;
int32 hexdigit;
int32 sum=0;
for(length=0; hex[length]!='\r'; ++length);
42
for(i=0; hex[i]!='\r'; ++i, --length)
{
if(hex[i]>='0' && hex[i]<='9')
hexdigit = hex[i] - '0';
if(hex[i]>='A' && hex[i]<='F')
hexdigit = hex[i] - 'A' + 10;
if(hex[i]>='a' && hex[i]<='f')
hexdigit = hex[i] - 'a' + 10;
sum = 16 * sum + hexdigit;
}
return sum;
}
/* Function to set filters, extract data from User Command */
void SetFilters(char recvData[]) {
int32 filters[10];
int32 digit ;
int x =0;
int pos =1;
//first char is ','
while (recvData[pos] != '\r' ) { //last char is Carriage Return
for (int i=pos; recvData[i] != ','; i++);
recvData[i++] = '\r';
digit = hexToInt(&recvData[pos]);
filters[x++] = digit;
pos = i;
}
can_set_mode(CAN_OP_CONFIG);
can_set_id(RX0MASK, filters[0], CAN_USE_EXTENDED_ID); //set mask 0
can_set_id(RX0FILTER0, filters[1], 1); //set filter 0 of mask 0
can_set_id(RX0FILTER1, filters[2], 1); //set filter 1 of mask 0
can_set_id(RX1MASK, filters[3], CAN_USE_EXTENDED_ID); //set mask 1
can_set_id(RX1FILTER2, filters[4], 1); //set filter 0 of mask 1
can_set_id(RX1FILTER3, filters[5], 1); //set filter 1 of mask 1
can_set_id(RX1FILTER4, filters[6], 1); //set filter 2 of mask 1
can_set_id(RX1FILTER5, filters[7], 1); //set filter 3 of mask 1
memset(can_rx_buffer,0x00,sizeof(struct Can_Buffer)*CAN_RX_BUFFERS);
can_set_mode(CAN_OP_NORMAL);
}
/* Function to return position message in buffer */
int getIndex(int32 rx_id){
43
int indexPos = 0;
while (indexPos < CAN_RX_BUFFERS)
{
if (rx_id == can_rx_buffer[indexPos].ID )
return indexPos;
else
indexPos++;
}
return indexPos;
}
/* Function to manage User Command */
void getCommand(){
char temp[17]= "0";
unsigned char tmpBuffer[10];
int index;
int32 digit;
gets(recvData);
if(recvData[0] == '2') //set filters command
SetFilters(recvData);
else if(recvData[0] == '1') {
digit = hexToInt(&recvData[2]); //request data command
index= getIndex(digit);
if (index < CAN_RX_BUFFERS ){
memcpy(tmpBuffer, &can_rx_buffer[index].Data[0], 8);
tmpBuffer[8] = 0x00;
sprintf(temp,"%X%X%X%X%X%X%X%X", tmpBuffer[0], tmpBuffer[1], tmpBuffer[2],
tmpBuffer[3],tmpBuffer[4], tmpBuffer[5], tmpBuffer[6], tmpBuffer[7]);
printf("%s",temp);
}
else
printf("%s","*"); //Value not available
}
else
printf("%s","!"); // Invalid Command
}
/* Function to get position where to register message in buffer */
int getPos(int32 rx_id){
int indexPos = 0;
while (indexPos < CAN_RX_BUFFERS)
{
44
if ((can_rx_buffer[indexPos].ID == 0x00) || (rx_id == can_rx_buffer[indexPos].ID) )
return indexPos;
indexPos++;
}
return --indexPos;
}
/* Function that extracts the message from CAN's buffer and put it in buffer */
void getCanMessage(){
int32 rx_id;
int index;
int rx_len;
struct rx_stat rxstat;
char in_data[8];
int32 mask =0x00ffff00;
if ( can_kbhit() ) //if data is waiting in buffer...
{
if(can_getd(rx_id, &in_data[0], rx_len, rxstat))
{
rx_id =(rx_id&mask)>>8;
index = getPos(rx_id);
can_rx_buffer[index].ID = rx_id;
memcpy(can_rx_buffer[index].Data,&in_data[0],rx_len);
}
}
}
/* Interrupts management */
#INT_CANRX0
//Buffer 0 receive data available
void canrx0_int() {
getCanMessage();
}
#INT_CANRX1
//Buffer 1 receive data available
void canrx1_int() {
getCanMessage();
}
#INT_RDA
//RS232 receive data available
void isr_rs232(){
getCommand();
}
45
7.3.1 Comandi seriali
Comando Richiesta Parametri :
Sintassi :
1:PGN
Parametri:
PGN : PGN in Hex del messaggio CAN
Funzione:
Ritorna una stringa in Hex con i dati del messaggio CAN richiesto.
Esempio comando:
1:FE56\r
Comando Configurazione filtri:
Sintassi :
2:ID {lista}
Parametri:
ID : lista identificatori in Hex separati da virgola
Funzione:
Setta i filtri basandosi sulla seguente lista ordinata :
RX0MASK,RX0FILTER0, RX0FILTER1, RX1MASK,RX1FILTER2,
RX1FILTER3, RX1FILTER4, RX1FILTER5
Esempio comando:
2:07FFFF0FF,18FEA400,0,07FFFF0FF,18FEE100,0,0,18FEEE11,\r
46
8. Riferimenti
8.1 Bibliografia
[B1] Barnett, O'Cull, Cox - Embedded C Programming and the Microchip PIC
[B2]
Han-Way Huang - PIC Microcontroller: An Introduction to Software & Hardware
Interfacing
[B3] Dogan Ibrahim - Advanced PICMicrocontroller Projects in C
[B4]
Uwe Kiencke, Lars Nielsen - Automotive Control Systems: For Engine, Driveline
and Vehicle
8.2 Sitografia
[S1] CAN Bus Tutorial:
http://www.datajob.com/corso/can/Default.aspx
[S2] Understanding SAE J1939:
http://www.simmasoftware.com/j1939-presentation.pdf
[S3] SAE J1939:
http://centurion2.com/SAEJ1939/Can110/J1939_v2007-10.pdf
[S4] PIC18F26K80 Datasheet:
http://www.microchip.com/
[S5] MCP2551
Datasheet :
http://www.microchip.com/
[S6] CCS C Compiler Manual :
http://www.ccsinfo.com/downloads/ccs_c_manual.pdf
[S7] MPLAB® X IDE User’s Guide
http://ww1.microchip.com/downloads/en/DeviceDoc/50002027C.pdf
[S8] PICkit™ 3 User’s Guide :
http://ww1.microchip.com/downloads/en/DeviceDoc/52116A.pdf
[S9] Visual Basic 2010 Tutorial:
http://www.vbtutor.net/index.php/visual-basic-2010-tutorial/
[S10] Kvaser Database Editor User’s Guide:
http://www.kvaser.com/software/7330130980334/V2/UG_98033_kvaser_database_editor_
userguide.pdf
47