L’embedded ha vincoli con cui non si discute. C’è una quantità fissa di RAM, un budget di energia fisso, e un dispositivo che deve continuare a funzionare in un posto dove nessuno andrà.
Scrivo firmware per quell’ambiente, incluso il caso sempre più comune di metterci sopra una rete neurale.
Cosa comporta
- Firmware a basso livello. Periferiche, interrupt, DMA, bring-up di schede nuove, e il lavoro poco glamour di far sopravvivere un dispositivo a una caduta di tensione a metà scrittura.
- ML su microcontrollore. Dimensionare l’arena dei tensori prima di scegliere il modello, quantizzare con dati di calibrazione veri, e verificare che la pipeline di feature sul dispositivo sia quella usata in addestramento.
- Budget di memoria. Flash per i pesi, RAM per le attivazioni, e il layer di picco che decide in silenzio se tutto ci sta.
- Attenzione ai consumi. Duty cycling e stati di sleep, perché l’autonomia nel foglio di calcolo assomigli a quella sul campo.
- Connettività. Portare i dati fuori dal dispositivo in modo affidabile, anche quando la rete non c’è.
Quando serve chiamarmi
- Un modello che gira sul portatile e non entra nel target.
- Accuratezza che crolla dopo la quantizzazione.
- Comportamento sul campo diverso da quello al banco.
- Autonomia pari a una frazione della stima.
Come procede il lavoro
Sull’hardware vero fin dall’inizio. I benchmark su host ingannano in entrambe le direzioni, e i guasti interessanti si vedono solo quando l’inferenza compete con un campionatore a interrupt per gli stessi cicli.
Parliamone
Portami il problema spinoso. Se non è un lavoro adatto a me te lo dico, e ti indico chi può aiutarti.