La programmazione integrata è più vicina all'ingegneria elettrica o allo sviluppo del software? [chiuso]

Mi viene richiesto un lavoro per scrivere C incorporato su microcontroller. All'inizio avrei pensato che l'incorporamento della programmazione fosse troppo basso nello stack del software per me, ma forse ci sto pensando in modo sbagliato.

Normalmente avrei scrollato di dosso l'opportunità di scrivere codice incorporato, poiché non mi considero un ingegnere elettrico. È una cattiva ipotesi? Sono in grado di scrivere software interessante e utile per i sistemi incorporati o mi prenderò a calci per essere caduto troppo in basso nello stack del software?

Sono andato a scuola per l'informatica e mi è piaciuto molto scrivere un compilatore, pensare a algoritmi simultanei, progettare strutture di dati e sviluppare framework. Tuttavia, attualmente sono impiegato come sviluppatore web, il che non grida le cose interessanti che ho appena descritto. (Attualmente mi occupo di problemi come: "questa casella di controllo deve essere 4 pixel a sinistra" e "questa data è formattata in modo errato".)

Apprezzo il contributo di tutti. So che devo prendere la decisione da solo, vorrei solo qualche chiarimento su cosa significhi essere un programmatore incorporato e se si adatta a ciò che trovo interessante.

Se vuoi essere bravo a lavorare su sistemi embedded, allora sì, devi pensare come un EE qualche volta. Ciò accade generalmente quando si scrive codice per interfacciarsi con le varie periferiche (bus seriali come UART, SPI, I2C o USB), timer a 8 e 16 bit, generatori di clock, ADC e DAC. I "fogli dati" per i microcontrollori spesso scorrono in centinaia di pagine mentre descrivono ogni bit di ogni registro. Aiuta a essere in grado di leggere uno schema in modo da poter sondare una scheda con un oscilloscopio o un analizzatore logico.

Altre volte, sta solo scrivendo un software. Ma sotto vincoli stretti: spesso non avrai un sistema operativo formale o un altro framework e potresti avere solo pochi KB di RAM e forse 64 KB di memoria del programma. (Questi limiti presuppongono che si stia programmando su micro 8 o 16 bit più piccoli; se si lavora con Linux incorporato su un processore a 32 bit, non si avranno gli stessi vincoli di memoria ma si dovrà comunque gestire qualsiasi personalizzato hardware periferico per il quale la tua distribuzione Linux non fornisce driver.)

Ho un background sia in EE che in CS, quindi mi piacciono entrambi i lati della medaglia. Faccio anche un po 'di programmazione web (principalmente PHP) e app desktop (C # e Delphi), ma mi è sempre piaciuto lavorare di più sui progetti embedded.

La risposta di @ tcrosley è eccellente. Non è necessario essere un ingegnere elettrico, ma conoscere le basi aiuta.

Non penso che tu debba temere di essere "troppo basso nello stack del software". Ho dovuto risolvere molti problemi molto interessanti come ingegnere embedded. Citi un elenco di attività che ti sono piaciute:

• Algoritmi simultanei: gestire gli interrupt di livello hardware asincroni presenta molte sfide interessanti quanto l'uso di un modello di thread del sistema operativo.

• Progettazione di strutture dati - Verifica. Design per compattezza e accesso efficiente.

• Sviluppo di framework - Verifica. Sui sistemi bare bones, puoi finire per progettare un mini-OS.

• Scrivere un compilatore - forse no, ma puoi finire per fare l'ottimizzazione del codice di basso livello simile alla fase di generazione dell'assembly di un compilatore.

Sceglierei di lavorare su sistemi embedded piuttosto che codificare l'interfaccia utente ogni giorno. Non dimenticherai mai la prima volta che guardi una macchina iniziare a muoversi nel modo in cui l'hai programmata. È molto più soddisfacente che spingere i pixel.

Come programmatore incorporato, il mio compito è far funzionare l'hardware personalizzato. In genere, ho sviluppato un sacco di software su una scheda di sviluppo o una versione precedente di hardware. Quando arriva la nuova scheda, il mio compito è quello di mettere il mio software sulla scheda e dimostrare che tutto funziona.

Poiché esiste quasi sempre un problema di qualche tipo, le abilità di debug sono essenziali. Se la periferica esterna non funziona, si tratta di un chip difettoso, di una cattiva connessione al chip, di un codice errato o di un uso errato della periferica su chip? L'unico modo per dirlo è con un ampio debug. Ciò significa sentirsi a proprio agio con oscilloscopi, analizzatori di rete, analizzatori logici e debugger target. Il processo di debug diventa quasi scientifico. Sviluppo un'ipotesi, progetto un esperimento per fornire prove a favore o contro la mia ipotesi e test.

Quando si valutano stagisti o nuovi ingegneri embedded, questa abilità è la più critica. Tutti i software hanno problemi, ma una volta che inizi a interfacciarsi con i mondi fisici, la varietà di questi problemi aumenta esponenzialmente. L'essenza del mio lavoro è risolvere la lunga serie di problemi tra concetto e realtà.

Nella mia esperienza, si ottengono risultati migliori avvicinandosi allo sviluppo del software di sistema integrato con un cappello "sviluppatore software" piuttosto che un cappello "ingegnere elettronico". (pratiche come TDD e CI sono meno comuni nell'ingegneria dell'hardware)

D'altra parte, penso che l'esperienza di sviluppo per un sistema embedded ne faccia uno migliore; sviluppatore software più completo.

Ero in una situazione simile circa 8 anni fa. A quel punto ho avuto 7 anni di sviluppo software in ambienti applicativi e server. La mia unica esperienza nel campo dell'hardware a basso livello era stata quella di scrivere sull'assemblatore Z80 da adolescente su uno spettro ZX.

È stata sicuramente una sfida. Ho trovato molto divertente gestire i set di chip nell'assemblatore e ho sicuramente imparato molto sull'hardware. Una parte sostanziale del mio ruolo è stata quella di testare l'hardware utilizzando il software, quindi imparare a gestire la programmazione e riconoscere che il tuo bug del software è in realtà un bug hardware. In realtà a volte può essere necessario un po 'di lavoro da parte di persone software e hardware per identificare se un bug è hardware o software.

Un aspetto che non sono riuscito a fornire è il lavoro del driver di dispositivo. Non l'ho mai capito, che è una cosa che io e quel direttore della compagnia non abbiamo mai capito perché. È appena diventato un fatto accettato.

Acquisire familiarità con un occiloscopio e uno ione per saldatura sarà essenziale. ricordando che quando un ragazzo hardware dice il numero 26 SEMPRE significa che 0x26 è utile. Capire che gli ingegneri hardware trovano molto frustrante la gestione del software, ma poi un progetto hardware che non prevede software viene chiamato cavo.

Sono rimasto in quel ruolo per 4 anni e me ne sono andato solo perché ero stato messo in camicia per un'opportunità davvero fantastica.

Come tutto, richiede un approccio equilibrato. Adoro lavorare con i sistemi embedded nel mio lavoro quotidiano. Mi rendono migliore in ingegneria elettrica. L'elaborazione fisica e l'automazione sono molto eccitanti. D'altra parte, creare app Web e armeggiare con il cloud computing è fantastico.

Se lo fai nel modo giusto, il lato software cercherà modi per fare le cose in modo più intelligente e migliore. Il lato hardware di te ti terrà consapevole delle risorse e super efficiente.

Non sono un ingegnere elettrico, eppure ho fatto una piccola parte dello sviluppo di software embedded. Il problema più grande che ho riscontrato è che ho un background molto più elementare in matematica, e quindi non so come scomporre facilmente una serie complessa di algoritmi matematici avanzati in codice senza molto aiuto.

Per tutte le cose in cui ho avuto bisogno di giocare con la segnalazione, leggere i valori dagli input, inviare i dati agli output e tutto quel genere di cose, l'ho trovato un po 'diverso concettualmente a quello che faccio ogni giorno come un buono Sviluppatore di software vecchio stile. Scrivere software è davvero quello che è. È quando devi uscire oltre il software vero e proprio che trovo che le cose diventino rischiose perché non ho le conoscenze per pasticciare direttamente con l'hardware. Questo di solito accade quando si tenta di eseguire il debug o il test del codice. Se hai una catena di strumenti davvero eccezionale, potresti avere un ambiente di debug e simulazione integrato per eliminare la maggior parte del dolore, ma anche con tutto ciò per aiutarti, a volte devi tornare alle basi e testare il tuo codice contro una sorta di analizzatore e la realtà è che la maggior parte delle piattaforme embedded non

Da questo punto di vista, non penso che essere un ingegnere elettrico sia essenziale per la programmazione integrata se i compiti sono semplici e gli effettivi requisiti specifici dell'hardware sono minimi. Oltre a ciò, penso che essere un EE renderebbe la vita molto più semplice quando si lavora in un ambiente incorporato, in particolare quando è necessaria la vera scienza per capire dove sono i problemi.

Non ho fatto alcuna programmazione integrata a livello aziendale, ma il mio Bachelor riguardava principalmente i sistemi embedded, da cui ho alcuni anni di esperienza reale. Abbiamo usato C su Atmel AVR e toccato alcuni chip Texas Instruments con VHDL, e avevamo alcune cose teoriche su ARM.

In quello che avevamo, era circa il 50-60 percento di programmazione (C), il 20 percento di pianificazione / progettazione (UML), e il resto era l'elettronica fisica (saldatura, misurazione, cablaggio, fabbricazione di cavi, ecc.). Concordo anche sul fatto che sia stato molto interessante e divertente da fare, e vorrei davvero avere una carriera nei sistemi embedded. Purtroppo, con un mercato molto piccolo di sistemi embedded, ho dovuto ricorrere al semplice vecchio Java EE.

Ma sto divagando; Direi che le percentuali sopra menzionate sono abbastanza vicine ai lavori nel mondo reale, dal momento che i nostri insegnanti hanno le loro imprese e hanno anche detto che cercheranno di renderlo il più realistico possibile. Abbiamo anche avuto curve casuali di 180 gradi nei requisiti a metà progetto, eh eh.

Per quanto riguarda lo stack. Conoscere la programmazione integrata ti offrirà ampie possibilità di creare i tuoi prodotti hardware molto reali che potresti aver fabbricato in impianti reali in Asia, quindi assemblarli presso la tua sede (sia a casa che presso la tua azienda). È molto interessante! Puoi anche creare molti gadget che ti saranno utili a casa, come luci della casa a movimento controllato, timer per una macchina da caffè per preparare automaticamente la tua mattinata mattutina e così via. Roba eccitante davvero!