Introduzione al Kit ARCHIMEDE

Il .NET Micro Framework

Nell’anno 2002 Microsoft ha rilasciato la prima versione del framework .net, un ambiente operativo per la creazione, la distribuzione e l’esecuzione di tutti gli applicativi che supportano questa tecnologia siano essi Servizi Web o altre applicazioni.

Il Framework .NET rappresenta l’interpretazione di Microsoft alla tendenza già consolidatasi negli anni precedenti al 2002 con Java in merito alla “virtualizzazione” del microprocessore. L’obiettivo principale del progetto è infatti costituito dalla realizzazione di una “virtual machine” (così chiamata nel gergo Java), denominata “CLR” (Common Language Runtime), in grado di compilare o interpretare (a seconda delle implementazioni) codice scritto in un linguaggio indipendente dall’hardware , denominato IL (Intermediate Language), traducendolo “just-in-time” in istruzioni native per lo specifico microprocessore su cui si sta eseguendo l’applicazione.

Nel 2004 viene rilasciato il .net Compact Framwork 1.1, una versione leggermente più limitata e con meno librerie rispetto alla versione standard, fatta per dispositivi mobili con risorse limitate (Palmari, telefoni, set top boxes…).

Infine, nel Novembre 2009 in seguito al rilascio dei codici sorgenti del loro framework, Microsoft inizia a coordinare lo sviluppo del .net Micro Framework, un’iniziativa open source orientata a sviluppare un’infrastruttura software che permetta l’esecuzione di codice IL su microcontrollori a 32 bit e quindi l’utilizzo dei normali strumenti di sviluppo diponibili per gli altri progetti basati sul framework .net.

I principali vantaggi riscontrabili utilizzando questa tecnologia sono:

  • bassissima occupazione di spazio: 300Kb di memoria FLASH
  • possibilità di realizzare applicazioni che possono girare senza sistema operativo
  • ricca API (Application Programming Interface) indipendente dall’hardware
  • efficiente controllo sulle periferiche del microcontrollore
  • libreria runtime che gestisce tutti gli aspetti che vanno dal bootstrap al debug del firmware
  • supporto nativo per i tipi di periferiche e interconnessione (EEPROM, GPIO, I²C, SPI, porte seriali…)
  • Non richiede una MMU (Memory Management Unit)
  • Portabile su altre piattaforme grazie alla HAL (Hardware Abstraction Layer)
  • Vincoli di esecuzione del codice che permettono la gestione dei crash di sistema
  • Ambiente di sviluppo professionale: Visual Studio
  • debug real-time del codice direttamente sulla scheda tramite porta USB
  • ri-utilizzabilità del codice tra ambiente desktop e micro controller
  • programmazione ad oggetti evoluta

Si capisce che i vantaggi della virtualizzazione sono numerosi ed evidenti, primi tra tutti quelli dell’indipendenza dall’hardware e della maggior possibilità di controllo su quanto viene eseguito, a fronte di un calo delle prestazioni assolutamente trascurabile (dipende dall’applicazione che si vuole andare a realizzare).

Nel mondo dei microcontrollori, in cui le architetture dominanti sono ben più numerose di quanto presente nel mondo del personal computer (in cui sostanzialmente troviamo x86, x64 e Itanium), i vantaggi derivanti dall’adozione di un framework basato su una runtime che virtualizzi l’hardware sono ancora più evidenti. Grazie al .NET Micro Framework possiamo infatti realizzare applicazioni che possono essere eseguite indistintamente su processori Atmel, NXP, Freescale, Analog Devices, ecc. senza apportare alcuna modifica.

Per meglio comprendere come si incastrino tutti i tasselli di hardware, funzionalità del framework e applicazioni managed, diamo un’occhiata all’architettura del Micro Framework.

 

Il cuore del sistema: la HAL e la PAL

In un sistema embedded di piccole dimensioni non troviamo quasi mai un sistema operativo, soprattutto in considerazione dell’impatto che questo potrebbe avere sulle risorse. Per questo motivo il Micro Framework ne fa tipicamente a meno e, al contrario dei suoi fratelli maggiori (Compact Framework e Framework.NET), è in grado di prendere direttamente il controllo dell’hardware.

Il componente al livello più basso è detto HAL (Hardware Abstraction Layer) e si occupa di gestire le operazioni più a stretto contatto con il microprocessore, come la gestione dell’I/O, gli interrupt e i timer, nonché l’intero processo di bootstrap.

I componenti dell’HAL collaborano con i driver nativi che permettono di astrarre le funzionalità delle periferiche hardware. A seconda del produttore hardware il .NET Micro Framework porta con se’ una serie di driver, come ad esempio quello per la gestione della seriale asincrona, delle comunicazioni sincrone (SPI e I²C), per pilotare i display LCD, per il monitoraggio dell’alimentazione, per la gestione delle porte I/O, per la gestione del modulo per la generazione PWM, per l’utilizzo di memorie Flash ed Eeprom e molto altro ancora. I driver nativi vengono tipicamente scritti dagli OEM (Original equipment manufacturer) che forniscono il “porting” del .NET Micro Framework specifico per la loro architettura.

Sopra la HAL risiede un altro componente fondamentale denominato PAL (Platform Abstraction Layer) che utilizza le funzionalità dello strato HAL per implementare nel modo più efficiente possibile caratteristiche tipiche del Micro Framework quali il multi-threading ed il garbage-collector  (il servizio in grado di liberare automaticamente blocchi di memoria non più utilizzati da parte del firmware).

Al di fuori di questi componenti (HAL, PAL e driver a basso livello) il resto del Micro Framework è indipendente dall’hardware. Il porting del Micro Framework su un hardware differente si riduce perciò all’implementazione di entrambi i componenti o della sola PAL.

Un altro compito importante della HAL è quello di provvedere alla modalità di esecuzione del codice che avviene su singolo thread o tramite ISR (Interrupt Service Routine). In sostanza Micro Framework rinuncia allo Scheduler dei thread in luogo di un multitasking di tipo cooperativo, in cui ciascun thread riceve una finestra temporale massima di 20 ms, che rappresenta quindi la “risoluzione” temporale minima per la realizzazione di applicazioni che abbiano necessità di garantire un ritardo massimo nell’esecuzione di determinate operazioni di controllo.

 

L’hardware del kit Archimede

Dopo aver parlato dell’architettura software utilizzata dalla scheda approfondiamo l’architettura hardware della scheda.

Archimede è una piattaforma Open-source (e Open-hardware) basata sul firmware della scheda Cerberus della GHI Electronics. L’obiettivo che ci siamo prefissati con questa scheda è riuscire a soddisfare la richiesta di un hardware facilmente programmabile, da qui la scelta del .net micro framework, ma nel contempo avere un hardware che possa essere utilizzato in ambiente domestico in modo semplice per realizzare progetti domotici e/o di building automation o anche per semplici progetti hobbistici.

Si parla di kit perchè in quanto la scheda è configurabile e componibile per soddisfare ogni esigenza.

L’architettura è piuttosto semplice: c’è una base-board che può ospitare una scheda CPU e fino a 12 schede di espansione o 12 relè e/o 24 ingressi digitali opto-isolati. Questa architettura è stata scelta per rendere la scheda adattabile a ogni esigenza sia economica che di utilizzo.

Esiste già un notevole numero di schede di I/O utilizzabili insieme al kit e continuiamo a svilupparne di nuove, inoltre essendo il tutto completamente aperto lascia spazio agli utente per realizzare le loro proprie schede di I/O

Solo per citare alcune delle schede già disponibili:

– Doppio Ingresso A/D
– Doppia Uscita DAC
– PWM di potenza
– Ethernet
– RS232
– RS485
– CAN Bus
– I2C
– I2C isolato
– Dual 1-Wire
– Dual 1-Wire isolata
– Dual Relè ritardati
– Dual Relè a priorità
– …

Il tutto viene fornito in una comoda scatola (6 moduli DIN) da quadro elettrico con morsetti passo 5, documentazione in Italiano, Inglese e moltissimi esempi di utilizzo, per essere subito pronti a provare ed utilizzare questo prodotto.

 

Specifiche Tecniche

Dimensione del prodotto

Box DIN Archimede

Box DIN Archimede

 Contenuto della confezione

 

n° 1 CD di documentazione ed esempi
n° 1 scheda base predisposta per alloggiare 12 moduli di interfaccia (la scheda viene fornita con 1 relè e 2 ingressi opto-isolati già montati)
n° 1 scheda CPU
n° 1 modulo di interfaccia seriale RS232
n° 1 modulo di interfaccia con 2 ingressi analogici
n° 1 modulo di interfaccia (1-Wire)
n° 1 cavetto di alimentazione
n° 6 morsetti a 3 vie femmina
n° 1 contenitore modulare 102×88 mm per montaggio su barra DIN

 

Requisiti di sistema

  • Windows XP, Vista, 7 or 8 (32 o 64bit), Raccomandato: Windows 7 or 8
  • Processore a 1.6Ghz o superiore
  • 1 Gb di RAM
  • Almeno 3Gb di spazio su harddisk per l’installazione dell’ambiente di sviluppo e dei vari SDK
  • RoHS compliant
  • 0 – 70 °C (32 – 158 °F)
  • CPU: 32-bit ARM Cortex-M4 microcontroller
  • Velocità: 168MHz
  • Dimensione FLASH: 384 KB
  • Ram: 112 KB

Specifiche ambientali

  • RoHS compliant
  • 0 – 70 °C (32 – 158 °F)

Processore e memoria

  • CPU: 32-bit ARM Cortex-M4 microcontroller
  • Velocità: 168MHz
  • Dimensione FLASH: 384 KB
  • Ram: 112 KB

Led e pulsanti

Led e pulsanti

Led e pulsanti

 

Posizionamento dei led

Posizionamento dei led

 

Connettori e pulsanti

Connettori e pulsanti

 

* Solo per utenti esperti: chiudere il ponticello e resettare la scheda per mettere la CPU in modalità DFU (vedi documentazione della ST)

** Lasciare il ponticello sempre inserito soprattutto durante la programmazione e/o il debug. Toglierlo solo se si è sicuri di ciò che si fa. Il ponticello inserito blocca il circuito del watchdog hardware (default). Togliendo il ponticello si abilita il circuito di watchdog che resetterà la scheda periodicamente a meno che si scriva un’applicazione che gestisca correttamente questo circuito.

 

Inputs e Outputs

Vengono qui di seguito elencate tutte le periferiche potenzialmente utilizzabili sul sistema (dipende dal tipo e la quantità di schede di I/O che vengono montate).

  • 24 I/O generici
  • 11 Canali analogici a 12 bit
  • 2 DAC a 12 bit
  • 24 canali 1-wire
  • 2 USART (fino a 3Mbit)
  • 1 canale SPI 4 fili
  • 1 RTC con batteria a tampone
  • 2 PWM hardware fino a 1MHz
  • 1 slot per micro-SDCard

Specifiche elettriche

Input: 12V

Assorbimento massimo della scheda: 300mA