Come diventare uno sviluppatore di software incorporato?

Vorrei alcuni consigli per coloro che vogliono diventare un buon sviluppatore di software embedded o vogliono migliorare in questo settore.

Cosa devo sapere su hardware, software?

Quali libri sono più consigliati? Blog?

Alla fine, come potrei passare da un hobbista principiante a un professionista eccellente?

Finora tutte le risposte sono state buone, ma aggiungerò i miei due centesimi.

Ecco una ripetizione di alcuni suggerimenti con una svolta e alcuni extra:

• Impara C: il linguaggio fondamentale dell'hardware che è ancora portatile (anche se in qualche modo). Non limitarti a impararlo, ma diventa un esperto di tutte le sue funzionalità come la volatilità e perché è importante per scrivere driver di dispositivo.
• Inizia con un buon kit di sviluppo come Arduino, ma come detto prima impara altre architetture una volta che ne hai avuto la sensazione. Fortunatamente ci sono alcune schede compatibili con Arduino costruite con altri processori, in questo modo puoi riscrivere lo stesso design su un altro uC senza rovinare l'intero design mentre hai un'idea di qualcosa di nuovo.
• Nella fase di apprendimento, sentiti libero di reinventare la ruota sui driver di dispositivo o su altre parti di codice. Non limitarti a inserire il codice del driver di qualcun altro. C'è valore nel reinventare la ruota quando stai imparando.
• Sfida te stesso a riscrivere il tuo codice in modo più efficiente in termini di velocità e utilizzo della memoria.
• Acquisire familiarità con diversi stili di architetture software per sistemi integrati. Inizia con l'elaborazione di base degli interrupt / elaborazione in background, quindi passa agli scheduler in background, quindi ai sistemi operativi in ​​tempo reale.
• Ottieni un buon controllo del codice sorgente! Preferisco Mercurial me stesso.
• Iscriviti anche ad alcuni siti di hosting di controllo del codice sorgente gratuiti come Sourceforge.net o Bitbucket.org per ospitare il tuo progetto anche se sei l'unico a lavorarci. Eseguiranno il backup del codice, quindi non devi preoccuparti di quel crash occasionale del disco rigido che distrugge tutto! L'utilizzo di un VCS distribuito è utile, perché è possibile effettuare il check-in delle modifiche sul disco rigido e caricarlo sul sito host quando è pronto.
• Impara bene i tuoi strumenti per qualunque chip tu stia lavorando! Sapere come il compilatore crea assembly è essenziale. Devi avere un'idea di quanto sia efficiente il codice, perché potresti dover riscrivere in assembly. È anche essenziale sapere come utilizzare il file linker e interpretare l'output della mappa di memoria! In che altro modo saprai se quella routine che hai appena scritto è il colpevole di occupare troppa ROM / Flash!
• Scopri nuove tecniche e sperimentale con loro nei tuoi progetti!
• Non supporre nulla durante il debug. Verificalo!
• Scopri come programmare in modo difensivo per rilevare errori e verificare ipotesi (come usare assert)
• Costruisci informazioni di debug nel tuo codice in cui puoi, ad esempio, emettere il consumo di memoria o il codice di profilazione con timer o utilizzare pin di riserva su uC per attivare e misurare la latenza di interruzione su un O-scope.

Ecco alcuni libri:

• The Pragmatic Programmer di Andrew Hunt e David Thomas - letture più o meno necessarie per qualsiasi sviluppo pratico del software
• Pratico Arduino
• Programmazione di sistemi integrati di Michael Barr
• Embedded Systems Building Blocks di Jean Labrosse
• MicroC OS II Real Time Kernel di Jean Labrosse, grande introduzione a RTOS in generale lì insieme al suo sistema operativo.
• Embedded Software Primer di David Simon - buona introduzione al software incorporato

Ecco alcuni siti Web:

• Guru incorporati
• Il gruppo Ganssle Jack Ganssle ha alcune storie storiche meravigliose da raccontare. Leggi gli articoli Però ha un po 'di predicazione su alcune cose.
• Embedded.com Buone informazioni per le ultime tecniche e suggerimenti di Ganssle, Barr e altri esperti del settore.

• Ricorda, "Non esiste un proiettile d'argento" , non cadere nella trappola di credere che esista uno strumento, una metodologia, un linguaggio o un sistema in grado di risolvere tutti i problemi
• Diventa un esperto in C.
  • Impara a cavartela senza malloc () e POSIX
• Non rimanere impiccato su un'architettura, è facile diventare un fanboy PIC o AVR o ARM per caso
• Crea roba, esegui il debug, fallo funzionare. La pratica rende perfetti
• Impara almeno un sistema di controllo del codice sorgente (SVN / git / etc) e usalo
• Siate sempre pronti a testare i vostri presupposti. Il bug di solito è nella cosa che stai supponendo funzioni
• Non fare troppo affidamento sui debugger, sono diversi su ogni sistema e di varia affidabilità
• Pensa in modo frugale. Quando si risolvono i problemi, considerare l'impronta del codice, l'impronta RAM e il costo dell'hardware

Per i libri, consiglierei di scavare nella storia. La maggior parte delle tecniche software integrate odierne proviene dal limite del passato.

Come qualsiasi cosa, esercitati ogni giorno.

Le altre risposte sono ottime, ma la più grande differenza tra un hobbista e un professionista dovrebbe essere una mentalità sulla qualità. Quindi fai andare il tuo progetto fino in fondo, non fermarti quando hai finito l'80% con un progetto. Prendilo fino in fondo, dimostra che funziona e documentalo correttamente.

Assicurati che il tuo codice sia leggibile e gestibile.

E non dimenticare di divertirti pure :)

A parte l'ovvio, come l'apprendimento del C e iniziare con alcune schede sviluppatore, vorrai imparare a leggere i fogli dati del microcontrollore .
I produttori aggiungono sempre più funzionalità ai microcontrollori, che diventano quindi sempre più complessi. Il foglio dati non fornisce solo caratteristiche elettriche (che sono più interessanti per l'ingegnere elettronico che per lo sviluppatore di software), ma anche una descrizione dettagliata di registri, mappe di memoria, ecc.
Alla prima lettura un foglio dati può sembrare scoraggiante, ma non capirle può causare un forte mal di testa nella fase di debug.

'Incorporato' è un po 'un termine caricato ..

Per alcuni aspetti, qualsiasi sistema dedicato all'esecuzione di una singola applicazione potrebbe essere chiamato un sistema incorporato, purché ci sia dell'hardware da controllare. Probabilmente è possibile chiamare un PPC604 a 400 MHz con 2 GB di RAM che esegue un'applicazione Java sopra Linux un sistema incorporato, se succede che sta controllando un processo attraverso moduli I / O locali. D'altra parte, un arduino che esegue solo una sorta di applicazione di rete minima non sarebbe molto simile a un sistema incorporato. Ma probabilmente "incorporato" fa pensare alla maggior parte dei controller basati su flash con solo poche centinaia di byte di RAM, nessun sistema operativo di cui parlare e una pletora di periferiche su chip.

Detto questo, probabilmente i due maggiori ostacoli ai programmatori non embedded di solito affrontano l'apprendimento dei sistemi embedded: i registri I / O e gli interrupt.

Gli interrupt possono in realtà essere il più semplice dei due concetti da gestire per i programmatori non incorporati, poiché i problemi principali con questi, la concorrenza e la programmazione guidata dagli eventi, sono spesso riscontrati nelle applicazioni tradizionali. Ciò che rende gli interrupt una sofferenza è rendersi conto dell'estrema sensibilità di un sistema alla qualità della sua gestione degli interrupt, e la complessità di trattare con l'hardware per cancellare la condizione di interrupt e impostare per il successivo. Con una GUI, un deadlock uccide solo l'applicazione. Con un gestore di interrupt, un deadlock provoca il blocco dell'intero sistema.

I dispositivi I / O sembrano essere l'area che causa la maggior difficoltà. Per chi non lo sapesse, può essere una sorpresa scoprire che leggere questo registro qui ha un effetto su quel registro lì . Scrivere 1 per cancellare i bit. Bit di stato che si cancellano quando si legge un registro dati, ecc. Esistono così tante possibilità con l'hardware I / O che non esiste una regola generale per gestirlo, tranne che per imparare a trovare e interpretare le schede tecniche dei dispositivi. Scrivere un driver di dispositivo per una porta seriale ti insegnerà molto sulla programmazione I / O di basso livello.

Non c'è davvero alcun sostituto per imparare queste cose se non di rimboccarsi le maniche e programmare un linguaggio C e / o di assemblaggio diretto sul metallo nudo. Anche il summenzionato sistema embedded basato su Java alla fine ha bisogno di un driver di dispositivo per l'I / O, e questo significa in definitiva avere a che fare con alcuni C. L'esperienza è il miglior insegnante. Scegli un microcontrollore, che si tratti di MSP430, TMS320, AVR, ARM, PIC, 68HC11, qualunque cosa, trova un kit di valutazione e costruisci alcuni sistemi.

$$50 to $$ma devi saldare per il pro mini. Non sono un fan della famiglia PIC, ma potresti voler ricevere qualcosa come lezione di storia, lo stesso vale per l'8051, entrambe le famiglie sono ancora popolari e in uso, ma non molto efficienti e sono state passate da altre architetture. Impara assolutamente ARM e pollice, forse MIPS (che è un pic-32, da non confondere con la vecchia architettura PIC originale). ARMmite Pro è una buona scheda ARM entry level, anche se lo Stellaris può esserlo.

Quello che vuoi imparare qui è assemblatore per varie piattaforme. Interazione C. e assemblatore. Diversi strumenti GCC e non GCC. Come leggere un riferimento di scheda tecnica / programmatori (e rendersi conto che hanno tutti degli errori o possono essere fuorvianti, non fidarsi mai di loro, l'hardware vince sui documenti) e come leggere o utilizzare uno schema. Questi non sono schemi complicati normalmente. Un certo numero di schede sono utili per l'interfacciamento nei progetti, il che significa che non hanno immondizia sulla scheda, solo l'accesso diretto ai pin I / O. Ma questo non è il migliore per l'apprendimento. Qualcosa come uno Stellarisla scheda che è dolorosa per i progetti ha molte cose divertenti a bordo per l'apprendimento incorporato e l'apprendimento di prendere in prestito / utilizzare i driver o scrivere il proprio dai fogli di dati. La farfalla Atmel AVR è una buona scheda anche se ancora disponibile, potrebbe essere necessario saldare sulla propria porta seriale per programmarla o semplicemente inceppare alcuni fili nei fori. Ciò che ti dà sono alcune periferiche che puoi imparare a programmare.

Anche se finisci per fare un lavoro integrato che prevede la scrittura di applicazioni utilizzando SDK o chiamate API su Linux o RTOS (senza mai toccare l'hardware o leggere i fogli dati), le conoscenze di cui sopra ti porteranno ancora avanti rispetto al resto.

Questo articolo (tradotto automaticamente dal portoghese in inglese) offre una buona panoramica dello sviluppo di una carriera come sviluppatore di software incorporato. Nota: l'originale è qui .

Inizia delineando le sfere di conoscenza che devi sviluppare:

1. Conoscenza: è necessario conoscere la teoria coinvolta nei sistemi integrati. Ciò significa hardware e software. È impossibile essere uno sviluppatore competente di software incorporato senza conoscere l'architettura hardware che sta funzionando.

2. Abilità: è necessario acquisire esperienza nell'area. Ha bisogno di pratica. Puoi decorare tutti i mnemonici dell'assemblatore PIC, ma è inutile se non puoi guidare un LED con questa conoscenza.

3. Atteggiamento: soprattutto, devi avere atteggiamenti che ti faranno crescere in questo settore. È molto dinamico con frequenti cambiamenti e sviluppi. Devi essere sempre motivato (a) essere autodidatta, divertirti imparando, "modificare" e capire come funzionano le cose. Senza tali atteggiamenti ti daranno presto. Perché quest'area devi essere molto, molto persistente.

Fornisce quindi i seguenti suggerimenti per padroneggiare queste aree (e le sviluppa con ulteriore testo, questi sono solo i titoli):

1. Cosa ti serve per imparare l'hardware (almeno)
2. Cosa ti serve per imparare il software (almeno)
3. Inoltre, studia i sistemi operativi
4. Hai bisogno di un allenamento
5. Non fermarti, continua a imparare e sviluppare il tuo networking!

Pensaci due volte prima di diventare un ingegnere del software incorporato. Ho avuto fasi della mia carriera. Ho sviluppato software nei primi 5 anni, poi sono passato a vendite / marketing, fatto che per 15 anni, ho gestito un business di oltre 100 milioni di dollari e ora sono tornato al software.

Quando torno al software dopo 15 anni, ricordo innanzitutto perché sono partito. È difficile. Ha bisogno di concentrazione, diverse centinaia di righe di codice si toccano e tutti voi dovete tenerlo in memoria. Incorporato è particolarmente difficile.

Devi anche capire te stesso. Se sei generalmente un ragazzo intelligente, meticoloso e paziente, diventeresti un grande ingegnere. Se ti manca qualcuno di questi sarai nella media al massimo. Pensaci. Se sei ultra intelligente e non paziente, non vale molto perché non importa quanto tu sia intelligente, una buona ingegneria richiede pazienza e attenzione ai dettagli.

Devi anche sentirti a tuo agio a guardare le ore di programmazione alla volta senza parlare. Osservo che le persone con buone capacità sociali lo trovano insopportabile.

Se tutto questo verifica, che leggere tutti quei grandi libri, fai gli esercizi e diventerai un grande ingegnere .. Buona fortuna

Tutti gli altri dicono grandi cose. Quindi ti darò un consiglio generale: leggi leggi leggi leggi leggi leggi leggi leggi!

Leggi tutti gli articoli su http://embeddedgurus.com Se non capisci qualcosa, cercalo. Se nella spiegazione di queste cose trovi qualcosa che non capisci, leggi di più. Sto per entrare in una posizione di software incorporato e la mia esperienza è stata una manciata di progetti professionali negli ultimi anni e molta lettura. L'esperienza ti consente di provare le cose, ma la lettura ti consente di sapere se le cose che hai provato sono state fatte in precedenza, forse meglio di quanto potresti. Ti introduce a concetti con cui puoi lavorare in qualsiasi circostanza.

Appena letto!

Diventa un esperto in C Comprendi timer e comunicazioni seriali. Dovresti sporcarti le mani. Comprendi i protocolli RF, modificali in base alle tue esigenze. Non solo provare ciecamente combinazioni di codice durante il debug. Il codice fa esattamente quello che gli dici di fare. Leggi il manuale dell'utente e la scheda tecnica, quindi apporta una modifica se qualcosa non funziona. Detto questo, l'unico vero modo per diventare un esperto è esercitarsi. Continua a creare applicazioni. Presto diventerà una seconda natura.