Mondo Embedded. Per gioco e per lavoro.

Tempo fa ero rimasto impressionato dalla STM32F4 Discovery, una scheda che, per la pazzesca cifra di circa 20 euro iva e spedizione inclusi, permetteva di fare esperimenti con il .NET Micro Framework. L’installazione del Net MF è un minimo “macchinosa”, ma una volta scaricato, si può cominciare.

Di contro, la scheda ha una serie di “limiti”. Essendo una “doppia faccia” (GLOM!) sono parecchio dubbioso sulle masse e sui disaccoppiamenti, manca un PHY per la rete, uno zoccolo per la SD ed il Codec Audio lo trovo piuttosto “limitato” rispetto alle applicazioni che si potrebbero effettuare con i dispositivi di cui sopra, ma per 20 euro non sono troppo autorizzato a rompere.

Fatti gli esperimenti e giocato un minimo mi sono riservato di preparare una scheda un minimo più funzionale, con le alimentazioni ed i disaccoppiamenti fatti un minimo più decentemente, con la periferia che mi serve, in formato SODIMM, che vedrà il mercato da fine settembre (trattandosi di prodotto commerciale, che oltretutto deve ancora uscire, mi è impossibile postare immagini e, ancora di più, schemi)

Ho quindi iniziato a fare il porting del firmware dell’apparecchiatura definitiva sul NetMF… salvo scoprire a metà del lavoro… che avevo due problemi.

Il primo era di velocità, il secondo era di spazio. La cosa, devo ammettere, mi ha lasciato basito visto che, trattandosi di PORTING ho già una apparecchiatura funzionante su un microcontrollore di classe decisamente inferiore (NXP LPC2368 a 57.6MHz). Tutto questo “merito” (scusate la sottile ironia) dell’ overhead del NetMF. Ok, ammetto di essere un minimo “carogna” perché come progetto di partenza ho usato un sistema hard real time con 42 task contemporanei (che nella nuova scheda aumenteranno di una decina per ovvi motivi), ma il micro in quanto tale ha sicuramente la capacità di effettuare tutte queste operazioni.

Con L’hardware definito ho voluto provare a valutare Kernel Real Time aventi caratteristiche di overhead di spazio e di tempo decisamente diversi. Uno lo conosco e lo uso da tempo, l’altro che non conoscevo e sono rispettivamente il FreeRTOS ed il ChibiOS/RT. Non è che ci siano differenze allucinanti tra il primo ed il secondo, se si conoscono i principi non ci sono grosse differenze di “usabilità” tra i due sistemi operativi. Secondo quella che è una opinione puramente personale, ho trovato il secondo decisamente più completo a livello di porting, mentre il primo è decisamente più “snello”. Ciò è anche dovuto al fatto che il ChibiOS/RT ha un porting veramente completo (grazie all’ottimo lavoro di Giovanni Di Sirio, deus ex machina di ChibiOS e dei suoi collaboratori), mentre il porting di FreeRTOS è abbastanza minimale e soprattutto non esistente per molti IDE.

Visto che adoro complicarmi la vita, per non lasciarmi mancare niente, per il FreeRTOS ho voluto usare l’IDE di CooCox, chiamato CoIDE, che è free ed usabile anche da un principiante. Il drawback è che rispetto agli altri IDE basati su Eclipse, alcune impostazioni della compilazione sono un po’ “nascoste”, o meglio, non sono dove sei abituato che siano. Il plus non indifferente è che in 10 minuti puoi partire a sviluppare sul silicio. Un altro plus altrettanto interessante è il numero enorme di “JTAG” supportati nativamente. Purtroppo CooCox supporta il PROPRIO sistema operativo (CoOS), che però non ha un porting ufficiale per il Cortex M4 e altrettanto non supporta il FreeRTOS (nel senso che esistono un paio di sample che però non sono riuscito a far funzionare). Data la mia elasticità mentale degna di un muro di granito, ho preso e fatto il porting praticamente “from scatch” partendo dai sorgenti e, alla fine, ho chiuso “la pratica” in un pomeriggio, facendo il porting sia per la STM32F4 Discovery che per la STM32-E407 di Olimex, una scheda decisamente più completa avente caratteristiche simili alla NetDuino Plus (il phy è decisamente migliore, due USB invece di uno, uno sfracello di I/O) ma di costo minore (così appare dal sito RobotItaly). Ovviamente mancano il porting del LWIP, della FatFS e dello stack USB. L’unico che mi da una qualche preoccupazione è comunque l’ultimo.

Rimane quindi da fare una piccolissima valutazione dell’overhead introdotto dal kernel in termini di spazio.

Dovendo far lampeggiare il classico led, lavorando sul “freddo silicio” si può scrivere un programma di qualche decina di byte in assembler, di qualche centinaio in C. Il FreeRTOS compilato in O0, comprensivo di codice per creare un thread ed il codice necessario per far lampeggiare un led “costa”, in termini di flash, circa 5650 bytes (configurazione minima) che fanno impallidire i quasi 640 del NetMF. In realtà il paragone è fuorviante visto che in questo momento il porting è minimale e praticamente senza periferia. Prometto di essere più preciso alla fine del porting, pari periferiche.

Compilazione

Qualora ci sia qualcuno altrettanto malato che voglia fare prove simili o voglia il mio porting del FreeRTOS su STM32F4 per CooCox, mi contatti pure.

A Presto

posted @ venerdì 19 luglio 2013 22:59

Print

Comments on this entry:

No comments posted yet.

Your comment:



 (will not be displayed)


 
 
 
Please add 4 and 3 and type the answer here:
 

Live Comment Preview: