Stack UDP/IP per Freescale HCS12

Per consentire ad un microcontrollore di connettersi ad Internet o di sfruttare tutti i vantaggi di una comunicazione su rete LAN, è necessario dotarlo di una pila TCP/IP o UDP/IP. L’implementazione di una pila TCP o UDP richiede tipicamente un sistema operativo (per la gestione della memoria, della rete e delle informazioni da scambiare), oltre ad una ingente quantità di memoria. D’altra parte i dispositivi a 8 o 16 bit non hanno risorse tali da consentire l’uso di un sistema operativo, per cui l’idea di utilizzare una implementazione dedicata permette, intervenendo sul codice, di ottimizzare la memoria in uso e utilizzare soluzioni ottimizzate di run-time. Per ovviare a questo inconveniente si utilizza un’implementazione di una pila in modalità stand-alone. Chiaramente, utilizzare una soluzione stand-alone non implica che la pila non sia comparabile con altre dal punto di vista delle prestazioni o che non sia modulare, ma al contrario, la realizzazione mostrata in questo articolo sarà modulare e portabile, sempre nei limiti imposti da una applicazione embedded. In questo articolo verrà illustrato a livello generale come, utilizzando una pila UDP/IP, sarà possibile utilizzare il device sulla rete.

IL MODELLO A STACK

la particolarità dell’implementazione a stack consiste nell’intercambiabilità di ciascuno strato della pila. È infatti possibile utilizzare una pila UDP/IP su un mezzo di comunicazione fisico come Ethernet o su di una comunicazione seriale senza modificare gli strati ad esso collegati. Le interfacce rimangono costanti anche se il lavoro viene svolto in maniera differente. Questo concetto di pila trova il suo riferimento normativo nel struttura dello standard ISO/OSI (Open Systems Interconnect). La figura 1 riporta il modello a strati ISO/OSI.

Figura 1. La pila ISO/OSI

Dalla figura 1 si nota che per un transfer protocol è possibile utilizzare sia una pila TCP/IP che una UDP/IP. È possibile anche utilizzare, in maniera indipendente, un differente mezzo trasmissivo, quale una seriale, una interfaccia Ethernet o Wireless.

Gli strati

Una pila, TCP/IP, in termini di stratificazione OSI può essere così schematizzata:

Layer 1 - Physical Layer
In questo strato si ritrovano i mezzi trasmessivi utilizzati per spedire/ricevere i pacchetti di dati sulla rete. In questa sezione vengono definite tutte le informazioni elettriche, non viene dato un preciso criterio del dato da trasferire, ma viene individuato un generico flusso (stream) di trasferimento. Vengono date informazioni sui modi operativi come simplex, half duplex, full duplex o, anche, se la trasmissione deve essere sincrona e/o asincrona. Tipicamente in questo livello andranno definite servizi di inizializzazione, di trasporto di bit streams e di controllo della connessione.
Layer 2 - Data Link Layer
Esiste una differenza tra questo livello con quello fisico. Il Data Link Layer interpreta i dati come messaggi strutturati. Tipicamente i servizi di questo strato permettono di fornire il controllo sul flusso d’informazione durante la connessione tra due nodi. Gli errori di questo tipo sono legati al controllo sulla validità del flusso, per esempio un framing error non sul contenuto del flusso stesso.
Layer 3 - Network Layer
In questo livello viene gestito il controllo del flusso dei pacchetti che verranno spediti nella rete. In questo caso occorre definire il percorso della trasmissione ed è qui che entra in gioco l’IP (Internet Protocol). In questo progetto le restrizioni sono diverse: l’IP è conforme alla versione 4 (IPV4), non è prevista la frammentazione dei pacchetti (per preservare le prestazioni e la memoria del sistema), il checksum, che è parte dello standard, in questo contesto è opzionale. L’implementazione della funzionalità di Ping utilizza l’ICMP e, in questa implementazione, l’ICMP consiste di un solo messaggio dato che si intende utilizzare una comunicazione di tipo reply/request. Un messaggio di tipo reply è una risposta alla ricezione di un request: questo è spedito al micro HCS12 utilizzando l’utility ping. Il messaggio di tipo request può essere utilizzato per spedire informazioni diagnostici sul link IP di comunicazione.
Layer 4 - Transport Layer
Il livello di trasporto riceve i dati dal livello superiore e li passa al nework layer segmentando i dati nel corrispondente layer. Per questo livello sono utilizzati due tipi di protocolli:- TCP (Transport Control Protocol)- UDP (User Datagram Protocol)Ognuno è utilizzato per una particolare applicazione, per esempio per SNMP è utilizzato UDP/IP, mentre per FTP la pila TCP/IP.
Layer 5 - Session Layer
In questo modulo si implementano le eventuali primitive di comunicazione: le sockets BSD sono comunemente usate in session/presentation layer. In una pila TCP/IP questo livello può anche non essere presente, infatti il livello sessione viene visto nel livello di networking.
Layer 6 - Presentation Layer
In questo strato i servizi che vengono forniti sono quelli di Data Compression e Data Encrypton. In una pila TCP/IP questo modulo non ha uno specifico ruolo e spesso questo livello è visto come parte del livello di applicazione.
Layer 7 - Application Layer
Questo è lo strato finale dove trovano posto le varie applicazioni utilizzate in una connessione di rete, quali:
TFTP, Trivial File Transfer Protocol
FTP, File Transfer Protocol
SMTP, Simple Mail Transport Protocol
Applicazioni come CORBA sono considerate parte dell’application layer. I pacchetti, in una comunicazione Internet, non arrivano continuamente mediante un flusso di caratteri, ma nella forma di tanti piccoli pacchetti dove ogni pacchetto è costituito da tanti sottopacchetti quanti sono gli strati considerati.

IL NOSTRO MODELLO

Nella presente trattazione verrà utilizzata una pila UDP/IP. Rispetto ad una TCP/IP, la pila UDP ha degli indubbi vantaggi: non richiede una dispendiosa attività di trattamento dei dati dato che no prevede processi di acknowledgement come il TCP/IP, risulta, poi, facile da implementare e richiede una quantità ridotta di memoria, oltre ad introdurre un overhead di sistema decisamente trascurabile. La pila UDP utilizzata si basa sul lavoro svolto da Trenado e Torres ed è disponibile in forma open source sul sito web di NXP/Freescale. L’applicazione che verrà realizzata si basa sui protocolli TCP, UDP, IP, ICMP (è utilizzato per controllare la presenza di un collegamento sfruttando l’utility ping che si basa appunto su questo protocollo) e costituisce il livello di transport e di network. Come mostrato schematicamente in figura 2, tale livello ha due interfacce: una rivolta verso il livello applicazione (A) e l’altra verso il data link (B).

Figura 2. Le due interfacce del Transport/Network layer

L’interfaccia A definisce le connessioni, con i relativi dati scambiati, fra transport e session layer. A questo livello d’interfaccia esiste, de facto, uno standard già largamente utilizzato: i sockets. Per una questione di portabilità, si preferisce utilizzare un insieme di API le più possibili vicine ai sockets di berkeley (BSD). L’interfaccia B definisce invece le connessioni, con i relativi dati scambiati, fra il data link e il network layer. Il ruolo di questa parte è quello di gestire i pacchetti IP. Si preferisce costruire questa interfaccia in modo tale da non essere vincolata alle scelte progettuali hardware.

Modifiche per UDP/IP su HCS12

Le differenze con la soluzione originale di Torres e Trenado si basano sulle seguenti modifiche e considerazioni:

La pila UDP/IP è modulare;
È possibile aggiungere altri network (per esempio Ethernet) alla soluzione base;
La struttura del progetto originale è stata modificata per permettere l’implementazione della stratificazione OSI;
Sono state introdotte un insieme di interfacce (API) per consentire al software la comunicazione tra i diversi livelli;
Si è cercato, per quanto possibile, di isolare le parti dipendenti dall’hardware per facilitare la portabilità della pila.

La figura 3 evidenzia le relazioni tra i vari strati con le dipendenze dai vari moduli software.

Figura 3. La reazione tra i layer della pila ISO/OSI e i moduli software

La pila è composta dai seguenti moduli software:

main.c - application Layer
In questo caso l’applicazione implementata prevede il controllo dei pins d’ingresso di una porta digitale. A questi pins viene collegato un sensore. Quando lo stato della porta cambia viene inviata una trama UDP verso una porta di comunicazione.
UDPIP.c - UDP/IP
In questo modulo software sono implementati i protocolli UDP, IP e ICMP. La funzionalità di ICMP è utilizzata per fare l’echo replies. In questo modo è possibile controllare l’attività della linea. Il protocollo IP è, invece, responsabile dell’instradamento dei pacchetti.
PPP.c - PPP
Questo modulo si occupa di svolgere la funzione di datagram encapsulation e di gestione del link con un fornitore di servizi Internet (un Internet Service provider).
Physical.c - PHYSICAL
Questa parte gestisce il componente fisico. Si cura lo strato di basso del livello del protocollo utilizzato per differenti configurazioni hardware combinati con il modulo PPP (Ethernet, linea seriale o altro).
Drv_modem.c - MODEM
Questo modulo è responsabile della corretta comunicazione tra lo stack UDP/IP e il modem. Dal lato modem, i comandi sono spediti come parametri/comandi in un formato testuale come da specifica del componente. Le risposte, rice- vute dal modem, sono gestite in un ISR: in questo modo le attività del modem non bloccano la normale esecuzione del microcontrollore.
Drv_sci.c - SCI
Questo modulo software contiene il driver per pilotare correttamente la ricezione/spedizione sul dispositivo SCI, interno al microcontrollore.
Timeout.c - TIMER
Questa parte si occupa di gestire il timeout. Sono state implementate anche routine che si preoccupano di disabilitarlo quando si è in modalità di debug.
Debug.c - DEBUGGING
Questo modulo ha il compito di presentare le informazioni sullo stato del protocollo su una seconda linea seriale. In questo caso occorre collegare un programma come HyperTerminal per visualizzare le informazioni. La figura 4 mostra un esempio.

Figura 4. La visualizzazione dello stato del protocollo su Hyperterminal

La pila UDP/IP implementata svolge azioni su eventi. Infatti, la cosa importante è che ogni livello comunica con gli altri attraverso delle funzioni predefinite utilizzando il meccanismo della callback. Quando un pacchetto viene ricevuto, l’informazione transita da un livello all’altro attraverso delle funzioni d’interfaccia senza utilizzare eventi asincroni. In questo caso, quando non ci sono comunicazioni, questo meccanismo riduce l’attività di CPU. L’ambiente di cross compilazione utilizzato è CodeWarrior. La figura 5 mostra una possibile applicazione in cui la pila UDP/IP costituisce un elemento fondamentale.