Sviluppare applicazioni per target embedded non è sempre una tra le esperienze informatiche migliori. Gli ambienti che la fanno da padrona sono spesso in un estremo tra eccessivamente chiusi e proprietari, troppo difficili da impostare per iniziare un nuovo progetto, o troppo pieni di boilerplate.
Disclaimer: ho principalmente a che fare con target STM ARM-Cortex ed ATMega AVR; i contenuti di questo articolo riflettono questa realtà, ed esprimono dei punti di vista completamente soggettivi e basati su mie opinioni ed esperienze.
Lo stato degli IDE e delle toolchain nel mondo embedded
Ci sono quattro elementi che valuto come importanti in una toolchain + IDE:
- Facilità di setup, o quanto tempo ci vuole a creare un primo stub funzionante per un progetto.
- Comodità e semplicità di utilizzo: quante feature vengono fornite e con quale accessibilità.
- Tipo di licenza: open source, freeware, pagamento.
- Esperienza di debugging.
Altri punti che considero importanti sono la possibilità di utilizzare un sistema su più piattaforme, e quello di potere invocare comandi di compilazione/testing da terminale facilmente. Quest’ultimo, in particolare, è perennemente sottovalutato, ed aiuta davvero molto ad automatizzare task di test, packaging e release.
Per quanto riguarda gli ambienti proprietari ed a pagamento, il mio punto di vista è che se non ce n’è un particolare bisogno, a causa di motivi iper-specifici come livelli particolari di ottimizzazione, preferisco non utilizzarli.
Infine, penso che sia essenziale potere utilizzare un ambiente moderno, che renda semplici e scontate alcune caratteristiche ormai basilari come effettuare ricerche globali nella codebase, avere un minimo di color highlighting e personalizzazione estetica.
Keil μVision
μVision è un IDE proprietario che utilizza un compilatore ARM closed-source e basato su licenza a pagamento.
L’ambiente è supportato solo su Windows, e permette di specificare dei task da eseguire prima e dopo alcune azioni (compilazione, linking, ecc.), ma il processo di compilazione è legato all’istanza grafica dell’IDE ed è difficile da separare da quest’ultima.
C’è un aspetto ricorrente in quasi tutti gli IDE del settore che si ritrova anche in questo ambiente. I file di configurazione contengono allo stesso tempo dati da versionare (include path, flag di compilazione) e dati da non versionare (impostazioni specifiche dell’IDE). Questo rende caotico il lavorare in gruppo con sistemi come git.
Detto ciò, μVision offre un’esperienza di debugging davvero approfondita, semplice ed intuitiva, che a mio parere costituisce un po’ la sua “killer feature”. Non è strano quindi il fatto che in rete si trovino progetti come questo, che effettuano il syncing da un ambiente ad μVision anche solo per poter sfruttare il suo debugger.
STM32Cube (MX + IDE)
C’è poco da fare, STM32Cube è il migliore ambiente “tutto in uno” che ti permette di configurare e avere un progetto funzionante senza troppi pensieri. CubeMX è la vera killer app della piattaforma STM: un configuratore e generatore di codice davvero completo e facile da utilizzare, che penso non abbia rivali.
Ci sono dei però: non amo Eclipse, anzi cerco attivamente di evitarlo. La lentezza, la non ergonomicità e l’incapsulamento di alcuni meccanismi interni sono i principali motivi per cui cerco di non usare IDE eclipse-like. Come μVision, anche CubeIDE utilizza file non-standard per la configurazione del compilatore, che vanno a mischiare impostazioni varie.
L’IDE usa però gcc come compilatore, e genera dei Makefile per la fase di build, il che rende un po’ più semplice l’automazione di alcuni processi.
Un aspetto molto particolare di questo ambiente è la code generation: le HAL (Hardware Abstraction Layer, una sorta di wrapper sulle funzionalità hardware) generate da STMCubeMX sono comodissime da utilizzare. Allo stesso tempo, sono piene di codice boilerplate. La mia idea è che in ogni progetto si hanno delle priorità, e se si ha poco tempo e poco bisogno di andare ad ottimizzare ogni pelo di un applicativo, le HAL ST fanno il loro sporco lavoro.
CLion
Piccola premessa, adoro gli IDE della JetBrains. Sì sono un po’ cari, ma valgono il loro costo.
CLion è a mani basse il miglior IDE che io abbia mai utilizzato in questo campo. L’interfaccia di editing è spettacolare, gli hint dell’IDE sono utilissimi e danno un boost di produttività non indifferente, rendendolo di sicuro la scelta più ergonomica che ho provato.
Ma c’è sempre almeno un però: bisogna perdere un po’ di tempo a configurare un nuovo progetto, in quanto CLion utilizza CMake come piattaforma di build automation. Di recente CLion si è adeguato al mondo dei configuratori, almeno per MCU della STM, e supporta la possibilità di generare stub di progetto partendo da un file ioc prodoto da STM32CubeMX.
Per quanto riguarda il debugger, se si dispone di un’installazione di openocd, il configuratore di progetti STM renderà automatico anche il processo di debug. L’unica pecca di questo ambiente è che non copre la totalità degli MCU STM, specialmente gli ultimi arrivati.
Editor + CMake
Ho lavorato per molto tempo su progetti personali utilizzando i Makefile, e qualche tempo fa ho deciso di applicarmi ed imparare ad utilizzare CMake, spinto anche dall’esperienza vissuta con CLion.
Da quando ci ho preso la mano, utilizzare un editor con CMake come strumento di build è diventata la mia scelta preferita. Certo, c’è un gradino in più a livello di setup di progetto, ma la libertà che si guadagna è incredibile, soprattutto una volta che si riesce a scavalcare il gradino della curva d’apprendimento.
La mia scelta prediletta è VSCodium + un’installazione locale di CMake, che è il setup base che utilizzo quando sviluppo progetti con MCU AVR. L’unica pecca di questo approccio sta nella mancanza di un semplice modo di andare in debug, ma ci sono soluzioni anche a questo, come utilizzare Bloom. Non ho ancora sperimentato nulla per quanto riguarda micro ARM, e generalmente mi baso sull’utilizzare il debugger integrato in CubeIDE stando attento ad utilizzare lo stesso compilatore, ma so che PlatformIO offre un ottima alternativa.
Per un esempio di questo approccio, questo piccolo progetto a cui lavoro nel tempo libero è completamente basato su toolchain gcc-avr +cmake su Ubuntu.
Conclusioni
In un mondo che va avanti alla velocità della luce come quello dell’embedded, gli ambienti di sviluppo vanno un po’ a rilento, ma le opzioni ci sono per chi sa guardarsi intorno. Spero che in un futuro prossimo ci si muova un po’ più verso la modernità cercando di imparare le lezioni sulla facilità di setup ed integrandole con quelle sulla riproducibilità ed automazione.
Per questo articolo è tutto, per eventuali approfondimenti o chiarimenti vi invito come al solito a commentare nella sezione qui sotto!