Quando non mi occupo di sviluppo di applicazioni .NET per le piattaforme desktop o web passo parte del mio tempo in laboratorio a sperimentare soluzioni basate su microprocessori dei più svariati tipi. L'aspetto della programmazione contestualizzato all'elettronica digitale mi ha sempre affascinato fin dai primi tempi in cui, con un caro amico, poco più che quindicenni realizzavamo piccole interfacce per il mitico Commodore VIC20 prima e C64 poi (chi non ha mai pilotato una bella fila di relais con il VIC20?). Fino ad oggi, però, approcciare il mondo della programmazione di dispositivi elettronici significava adottare strumenti di sviluppo specifici nonché produrre codice raramente riutilizzabile.

Verso Settembre 2007 Microsoft ha rilasciato una nuova piattaforma di sviluppo denominata .NET Micro Framework 2.0 (di seguito uF) nata dall'evoluzione di SPOT (Microsoft's Smart Personal Objects Technology) il cui principale scopo è proprio quello di colmare tale lacuna fornendo una serie di strumenti familiari a chi frequenta il mondo .NET e fosse interessato alla programmazione di sistemi embedded. Tali strumenti includono un SDK gratuito ed integrato in Visual Studio 2005 con relativo emulatore di dispositivo e possibilità di eseguire il debug delle applicazioni sia attraverso l'emulatore che direttamente sull'hardware.

Questo strumento è collocato in una fascia d'utilizzo relativamente bassa , quasi hobbistica: si parla per lo più di reti di sensori, piccoli robot o elettrodomestici, piccoli strumenti di laboratorio, lettori MP3, dispositivi connessi in rete ma anche applicazioni in ambito sanità e automazione industriale. Tale premessa è in realtà riduttiva e il reale campo di applicazione di questa tecnologia è ben più ampio.

Micro Framework si colloca quindi nella fascia di prodotti dedicati al mondo embedded insieme a Microsoft Windows XP e Windows CE (con le relative versioni di .NET e .NET Compact Framework) coprendo proprio la fascia di dispositivi a ridottissime dimensioni, equipaggiati per lo più con un set relativamente ridotto di risorse, basati su processori a 32 bit a basso costo e basso consumo anche non dotati di MMU (Memory Management Unit). Si pensi che per far girare uF in un processore non servono più di 300 KB.

Architettura di .NET Micro Framework

Con riferimento alla precedente figura non vi sarà mancato di osservare come uF sia collocato indifferentemente nella stessa fascia coperta in parte dai sistemi operativi embedded e in parte dai cugini .NET Framework e .NET Compact Framewok. Questo perché il runtime di uF non richiede obbligatoriamente la presenza di un sistema operativo e può pertanto funzionare direttamente ?sul chip? come deducibile guardando la prossima figura che illustra proprio l'architettura dei componenti che costituisco questa piattaforma.

Questo significa che uF è in grado di fornire tutta una serie di servizi che normalmente sono implementati nel sistema operativo (SO) quali l'inizializzazione dell'ambiente, la gestione degli interrupt, la gestione dei processi e delle thread, la gestione della heap ed altri. Tale lavoro è suddiviso e svolto da due componenti fondamentali: l'hardware abstraction layer (HAL che occupa indicativamente 20-30 Kb) e il common language runtime (CLR).

L'HAL è l'unica parte di uF fortemente accoppiata all'hardware e si occupa, tramite l'uso di drivers specifici implementati dai produttori hardware, di fornire i servizi di accesso a tutte le periferiche del dispositivo attraverso una coda di I/O schermando il driver stesso dai dettagli di gestione delle ISR e del locking delle code (ruolo che di norma viene svolto proprio dal kernel del S.O.). In presenza di un S.O. vero e proprio l'HAL funziona da tramite dirottando le chiamate verso il S.O. stesso (questo è il modo in cui funziona, ad esempio, anche l'emulatore integrato). Sempre l'HAL si occupa anche della fase di avvio (booting) nonché di tutta una serie di ottimizzazioni finalizzate ad ottenere un bassissimo consumo di energia (tipicamente riduzione dell'uso della CPU, utilizzo delle deferred service routines ? DSR, gestione della velocità del clock).

In un certo senso possiamo pensare all'HAL come ad un mini kernel che da un lato dialoga con l'hardware e dall'altro, attraverso il componente PAL, espone i servizi al CLR. A conferma di ciò il nucleo dell'HAL supporta due modalità di esecuzione del codice: thread singolo e ISR (interrupt service routine). Non esiste quindi uno schedulatore di processi vero e proprio come avviene nei normali S.O. in quanto, a questo livello, c'è una sola singola thread rappresentata proprio dal CLR.

E' quindi il CLR ad eseguire tutte le altre applicazioni utente (sempre in senso esteso) e a fornire le funzionalità di multi threading implementando, inevitabilmente, un meccanismo di multitasking cooperativo (anche se ottimizzato).

HAL e CLR sono accoppiati da un componente intermedio denominato Platform Abstraction Layer (PAL) il cui ruolo primario è quello di provvedere alla totale astrazione della piattaforma hardware esponendo verso il CLR strutture complesse quali i timers, i blocchi di memoria, le comunicazioni asincrone, gli I/O e quant'altro.