esegue bytecode espresso in linguaggio «CIL» Integrazione binaria tra moduli software La CLR si occupa di threading, gestione della memoria, interazione con procedure «native»,ecc. La CLR «consuma» delle unità eseguibili dette «assembly» Un assembly è costituito da: metadati (un db interno che descrive i «prototipi» di tutti i tipi e membri definiti nell’assembly) bytecode CIL (la sequenza di istruzioni che costituisce il «corpo» di ciascun metodo (funzione) manifest (esprime le dipendenze da altri assembly) Principali intenti di .NET
(C#/VB.NET) 2. Il compilatore genera uno o più assembly 3. Il bytecode degli assembly così generati viene scritto sulla memoria Flash del dispositivo mediante l’IDE o con un apposito tool (MFDeploy) 4. Il device al reset esegue il «TinyBooter» che a sua volta carica la «TinyCLR» 5. La TinyCLR carica gli assembly ed esegue il metodo «entry-point» utente Sviluppare firmware per .NET MF
il test, il debug e il rilascio di un semplice firmware Diamo uno sguardo al compilato “IL” Esploriamo più nel dettaglio il modello di threading e l’interazione con il flusso di esecuzione del firmware nativo del microcontrollore (gestione interrupt)
costituiscono la toolchain più produttiva disponibile nel mercato embedded Affidabilità Runtime «managed», controllo completo su ogni «layer» dell’applicazione Portabilità Virtualmente portabile su tutti qualsiasi core, attualmente copre tutti i core ARM™ 32 bit Supporto Completamente «open», molte librerie di base, molte risorse community Punti di forza del .NET MF
globalizzazione, crittografia, manipolazione testo, diagnostica, sicurezza Funzionalità di sistema Networking, file-system, user interface, threading Gestione periferiche USB (device/host), GPIO (con interrupt), I2C, SPI, UART, ADC, PWM, Watchdog, power Componenti di terze parti CAN, DAC, RTC, Glide (UI+Touch), SQLLite, ecc. Base Class Libraries
12-bit con interfaccia SPI (Microchip MCP3201) Sviluppo di un semplice driver “managed” Aggiunta di nuove funzionalità tramite ereditarietà Astrazione del modello di interazione con la periferica Implementazione di un nuovo driver con lo stesso modello Integrazione dei due componenti in un’applicazione completa
range) ZigBee (mesh) Integrazione con sistemi informativi di terze parti (AS/400, Windows, Unix) Controllo barriere mezzi Logging remoto attività sistema Monitoraggio continuo parametri ambientali delle centraline Applicazioni «Real-World» #1
CEI Acquisizione continua di Encoder velocità motori Pressioni (in diversi punti del tubo Venturi) Temperatura/umidità ambientali Potenza DC e AC Gestione motori induzione 220V/50Hz, 110V/ 60Hz, DC brushless con e senza controller integrato Interfacciamento con software gestione prove «kiosk» (Windows 7+WPF+touch) Applicazioni «Real-World» #2
piano computazionale Controllo del timing Non adatto ad applicazioni real-time Non è un OS Non esiste un supporto «di base» per processi, file-system, comunicazione, sicurezza, ecc. Pochi porting GHI Electronics (4), Secret Labs (2), Mountaineer Group (2), Sytech Designs, Love Electronics Punti deboli …
del timing Utilizzo di schede multi-processore (come la Triumvirato: USBizi+MSP430+CPLD !!!) Non è un OS Molti servizi sono stati sviluppati nel tempo dai vendor come estensioni del framework Pochi «porting» Molti sono open (Netduino, Mountaineer Boards, GHI OSH) e lo stesso Porting Kit è completamente open (netmf.codeplex.com) …ma risolvibili !