Per vari motivi mi sto interessando al mondo dello sviluppo embedded, ma non so se tenerlo come hobby o se farlo diventare un possibile sbocco lavorativo (perché mi sono veramente scartavetrato i maroni di quello che sto facendo).
C’è qualcuno che lavora nel campo e può raccontare che aria tira?
No idea, io sto imparando Rust di recente che ho visto può essere applicato negli ambiti embedded dove penso generalmente regna C/C++.
Il linguaggio è figo mi sta piacendo scriverlo, se trovi ambienti che lo usano secondo me può essere un esperienza positiva e qualcosa di nuovo che fa sempre bene per uscire dalla monotonia
Io non lavoro nel campo ma ho un caro amico che ci è dentro ed è CTO di una PMI qua in zona. Da quanto mi dice lui c’è poca gente veramente brava, per intenderci gli sviluppatori un po’ anziani non hanno la minima idea di terminati pattern o best pratice tipo unit testing, i giovani invece son abituati a vari framework che danno una mano su tutto e si trovano spaesati
Rosica molto perché appunto non riesce a trovare figure interessanti e, i loro senior, viaggiano dai 55k di RAL in su
Io circa.
Scappa.
Non entrare mai in quella grande azienda che ha il nome sia di un noto artista italiano del rinascimento sia di una tartaruga ninja. MAI. hai capito?
Al momento non ci faccio niente tbh, anni fa avevo preso un kit arduino uno ma mi aveva scocciato il tono paternalistico della documentazione, che è perfetto per il target ma a me sta sul cazzo, ho sempre rigettato anche python per lo stesso motivo, è un problema mio
All’embedded ci sono arrivato per esclusione, perché mi piacerebbe tornare a un ruolo più tecnico di quello che ho ora, dove sono a metà a navitare nel guano corporate di un reparto IT allo sbando e l’altra metà a fare insegnante di sostegno, ma vorrei evitare come la peste:
tutto ciò che è sviluppo web
tutto ciò che è devops / infrastruttura cloud
tutto ciò che è data science
tutto ciò che è sviluppo app mobile
tutti i linguaggi dove ci sono evangelist e seghe varie (questo include rust, anche se lo tengo sempre d’occhio con interesse)
Quindi sono rimasto con i sistemi embedded in C
Sono abbastanza certo che dovrei affrontare un paycut, dovrò vedere se ne vale la pena.
Un dubbio che ho è se ci siano opportunità full remote nel campo embedded, immagino di no perché alla fine immagino si debba lavorare a stretto contatto con l’hardware che giocoforza sarà nei lab dell’azienda, però boh ne so una mazza di come funzioni in realtà.
Riguardo a quello che scriveva Kaldais:
io mi troverei nel mezzo, nel senso che saprei arrangiarmi senza framework ma conosco l’importanza di pattern e unit test (ho appena dato una scorsa veloce a questo libro che è esattamente su questi temi e mi sembra fatto molto bene, però serve già una conoscenza di base che al momento mi manca Making Embedded Systems [Book]).
Il mio problema è che non saprei come dimostrarlo, perché non ho mai fatto il programmtore tout-court di mestiere.
Seguirò il corso e proverò a fare un progettino casalingo giusto per capire cosa sono in grado di fare, nel mentre terrò d’occhio le opportunità sul mercato.
Io ho lavorato in varie tipologie di “sviluppo a basso livello”, diciamo, tipo GPU/graphics programming e anche contesti embedded, al momento lo faccio poco dove sono ma interfaccio abbastanza con chi lo fa, quindi forse posso dirti due cose. Fai conto pero’ che in Italia ho lavorato praticamente zero, ho solo fatto qualche progetto da freelance verso la fine dell’uni.
Partiamo da questo messaggio che ovviamente non voglio criticare e capisco. Pero’, si parla ad esempio di applicare pattern ad un contesto embedded, ok, ma in un setup embedded spesso si ha a disposizione un compilatore C-only, quindi non si ha a disposizione:
classi con inheritance, scopes/visibilita’
veri funtori, lambdas ecc
ovviamente niente templates quindi nessun modo di esprimere generics nel linguaggio
Ora, capisci che la possibilita’ di usare pattern di design classici e’ parecchio azzoppata… Certo, si possono trovare vie a volte, per dire se hai un pre-processore completo puoi fare un sacco di cose tra macros e xmacros, ma, ha senso? e’ una roba stabile/leggibile dalla prossima persona che arriva?
Scrivo tutto questo perche’ secondo me da’ una idea di cosa puo’ essere il settore, dove magari la best practice non e’ avere sempre il pattern giusto ma piu’ che altro creare un setup dove clang static analyzer viene eseguito sul codice periodicamente, con i parametri giusti e connnesso altri tool quando trova errori, o altro. Btw svariati ambienti non sono nemmeno POSIX quindi non si ha:
multi-threadig, o se lo si ha, quasi nessuna operazione che lo sarebbe normalmente e’ thread safe
capacita’ di aprire piu’ files allo stesso tempo! Se apri file1 e hai un handle, se poi apri file2 il primo handle ti va a nullptr
Insomma, ci siamo capiti… Ok, siccome ho divagato un po’ certo di darti qualche mano piu’ pragmatica.
I corsi che hai listato, guardando quello che toccano, dovrebbero andare bene per imparare molte cose… Anche troppe… Io fossi in te starei attento anche a capire bene “la teoria”, o comunque imparare tante cose su computer architecture in generale, per dire il primo tocca “access level e operation modes del processore”, ma tu sai quali sono le operation modes di un processore moderno in genere e perche’ esistono? E quindi poi: sai leggere un ISA? Hai presente come un sisema memory-mapped funzioni, come funzioni davvero paging, e robe cosi’? Perche’ se non hai questi fondamenti, potresti non sare veramente capendo il codice che scrivi, che magari sembra semplice ma fa varie assunzioni… a volte in quel mondo la differenza per creare un flow di esecuzione totalmente diverso e quindi risolvere un problema grosso e’ aggiungere la flag giusta - magari poco documentata - alla system call giusta…
Il problema e’ che non ho buone fonti per imparare quelle cose in un buon modo io di base ti consiglierei questo Algorithms for Modern Hardware - Algorithmica che e’ un corso strano che pero’ introduce con logica a molti aspetti di programmazione low level e computer architecture. Se invece vuoi seguire un corso vero di computer architecture, online ce n’e’ uno ottimo che e’ questo https://www.coursera.org/learn/comparch/ ma e’ anche molto completo, forse puoi selezionarti solo delle parti?
Insisto sulle basi di comparch perche’ alla fine, i lavori migliori? nel campo si basano su: “ok abbiamo questa nuova piattaforma con un core ARM tipo cortex VX ma con queste differenze, e con un driver che fa solo queste cose ecc, ora devi scrivere un tool/driver/programma che…”, ovvero devi lavorare su una architettura e stack “nuova” e quindi devi sapere come leggere le specs e cosa intendono, altrimenti e’ molto dura…
Riguardo i linguaggi: devi imparare C, che significa saper usare puntatori ecc, saper conteggiare quanti bytes una struct ti occupera’ [piu’ difficile di quel che sembra], e poi conoscere tutti i pitfall del linguaggio :D Ad una certa potresti anche guardare C++. Non diffidare dei linguaggi con evengelist eh, solo dei linguaggi con piu’ evangelist che contributors! Quindi Rust o Julia o Zig o anche altri rimangono interessanti. Ad un certo punto, prova a leggere dell’assembly [algorithmica sopra te lo introduce], sopratutto ARM, non e’ cosi’ ostico eh!
Riguardo opportunita’ remote: si’, quello che dici e’ vero. Pero’ io so che all’estero ce ne sono e anche parecchie, post-covid molte piu’ aziende hanno creato un setup per permettere alla gente di lavorare in remoto collegati ai device, o in alcuni casi ti mandano anche i device a casa eh, e’ una cosa che si fa. Fai conto che spesso ci sono dei simulatori che piattaforme e tu scrivi il SW usando quelli e poi quando fai push viene eseguito sul device da un’altra parte del mondo. Pero’ come sia in Italia non lo so.
In conclusione, non conoscendo il tuo background ti consiglierei di stare lontano dal settore :D Se devi impararti molte cose da zero puo’ essere un po’ deprimente, e sebbene capisca molto bene il voler stare “di piu’ con il codice”, ti posso assicurare che quando il SW che hai scritto freeza il device in modo riproducibile, e ovviamente il tuo e’ SW critico senza cui non si puo’ fare nulla, e sei li’ da solo che cerchi di capire dove sta il problema - che potrebbe stare in altri driver, o compilatore, e anche nell’HW stesso - stare da solo con il codice non sembrera’ piu’ tanto una benedizione ma una condanna, e penserai con nostalgia ai giorni in cui magari eri manager di altri… Ma vedi tu!
Ha assolutamente senso, infatti ho scritto determinati pattern e best pratice. Facevo riferimento a cose base base, per evitare di scrivere cagate: mi pare abbia assolutamente senso, in un contesto del genere, creare una state machine interna che rappresenta proprio lo stato del dispositivo su cui sta girando, ad esempio.
Comunque quando fai cenno alla pipeline con l’analisi statica è proprio quello a cui mi riferivo. I “vecchi” appena cominci ad accennare CI tirano su gli occhi
Ho sempre guardato questo argomento con molta fascinazione, mi ripromettevo di capirci qualcosa da anni, poi sono diventato vecchio.
Ai miei occhi ha qualcosa di molto poetico e profondo che parte da lontanissimo ma non lo so dire meglio.
Secondo me ci sono nella storia dei lavori che sono delle vere opere d’arte.
Per dire il Voyager I che ancora funziona è ai miei occhi un sistema embedded fenomenale.
Certe volte penso agli strati di complessità che mi appaiono come pezze inutili rispetto al genio di un livello di astrazione matematica del mondo fisico già complesso il giusto che di suo ha tutto quello che serve per stagliarsi maestoso.
Bel post Hans, sono d’accordo anche io… abbiamo fatto cose in passato allucinanti se consideriamo il fatto che avevamo a disposizione 1/1000 della memoria e della capacita’ di calcolo che abbiamo ora ma abbiamo mandato gente sulla luna…