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

Se vuoi essere bravo a lavorare su sistemi embedded, allora sì, devi pensare come un EE per un po 'di tempo. 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 e ADC e DAC. "I fogli dati" per i microcontrollori corrono spesso nelle 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, è solo scrivere 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 di programma. (Questi limiti presuppongono che si stia programmando su micros più piccoli a 8 o 16 bit, se si sta lavorando con Linux embedded su un processore a 32 bit, non si avranno gli stessi limiti di memoria ma si dovrà comunque gestire qualsiasi hardware periferico che la tua distribuzione Linux non fornisce i driver per.)

Ho uno sfondo sia in EE che in CS, quindi mi piacciono entrambi i lati della medaglia. Faccio anche alcune applicazioni di programmazione web (principalmente PHP) e desktop (C # e Delphi), ma mi è sempre piaciuto lavorare su progetti embedded di più.

@ la risposta di tcrosley è eccellente. Non è necessario essere un ingegnere elettrico, ma conoscere le nozioni di base aiuta.

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

• Algoritmi concorrenti - Affrontare interrupt a livello di hardware asincrono presenta tante sfide interessanti rispetto all'utilizzo di un modello di thread del sistema operativo.

• Progettazione delle 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 si può finire con l'ottimizzazione del codice di basso livello simile alla fase di generazione dell'assemblaggio di un compilatore.

Scelgo di lavorare su sistemi embedded per codificare l'interfaccia utente ogni giorno. Non dimenticherai mai la prima volta che guardi una macchina che inizia 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 una serie di software su una scheda di sviluppo o su una versione precedente dell'hardware. Quando arriva la nuova scheda, il mio compito è di mettere il mio software alla lavagna e dimostrare che tutto funziona.

Poiché c'è quasi sempre un problema di qualche tipo, le capacità di debug sono essenziali. Se la periferica esterna non funziona, è un cattivo chip, una cattiva connessione al chip, un codice bug o un uso non corretto della periferica on-chip? L'unico modo per dirlo è con un debug completo. Ciò significa essere a proprio agio con oscilloscopi, analizzatori di rete, analizzatori logici e debugger di destinazione. 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 incorporati, questa abilità è la più critica. Tutto il software ha dei problemi, ma una volta che si inizia ad 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 che si avvicinano allo sviluppo di software di sistema embedded con un cappello "sviluppatore di software" piuttosto che un "ingegnere elettronico". (le 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 migliori l'esperienza; sviluppatore di software più completo.

Ero in una situazione simile circa 8 anni fa. Ho avuto a quel punto 7 anni di sviluppo software in ambienti applicativi e server. La mia unica esperienza con un basso livello di hardware prima era stata scrivere in assembler Z80 da adolescente su uno spettro ZX.

È stata certamente una sfida. Ho trovato molto utile lavorare con i set di chip in assembler e ho sicuramente imparato molto sull'hardware. Una parte sostanziale del mio ruolo consisteva nel testare l'hardware tramite software, in modo da imparare ad affrontare la programmazione e riconoscere che il bug del software è in realtà un bug hardware. In realtà a volte può essere necessario un po 'di lavoro da parte del software e dell'hardware per identificare se un bug è hardware o software.

Un aspetto su cui non sono riuscito a dare seguito è stato il lavoro con i driver dei dispositivi. Non l'ho mai capito veramente, il che è una cosa che io e quel direttore della compagnia non abbiamo mai capito perché. È diventato un fatto accettato.

Avere familiarità con un occiloscopio e uno ione di saldatura sarà essenziale. ricordando che quando un ragazzo dell'hardware dice che il numero 26 ha SEMPRE significa che 0x26 è utile. Rendersi conto che gli ingegneri dell'hardware trovano che gestire i problemi con il software aiuta molto, ma poi un progetto hardware che non coinvolge il software è chiamato cavo.

Ho soggiornato in quel ruolo per 4 anni e me ne sono andato solo perché ero in camicia per un'occasione davvero fantastica.

Come tutto, richiede un approccio equilibrato. Adoro lavorare con i sistemi embedded nel mio lavoro diurno. Mi rendono migliore nell'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 bene, il lato software di te cercherà modi per fare le cose in modo più intelligente e migliore. Il lato hardware di te ti manterrà consapevole delle risorse e super efficiente.

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

Per tutte le cose in cui ho avuto bisogno di giocare con i segnali, leggere i valori dagli input, inviare i dati alle uscite e tutto quel genere di cose, ho trovato concettualmente diverso da quello che faccio ogni giorno come un buon vecchio sviluppatore di software. Scrivere software è davvero quello che è. È quando hai bisogno di andare oltre il software vero e proprio che trovo le cose rischiose perché non ho la consapevolezza di fare confusione con l'hardware. Questo di solito accade quando si tenta di eseguire il debug o testare il codice. Se hai una vera e propria catena di strumenti, potresti avere un ambiente di debug e simulazione integrato per eliminare la maggior parte del dolore, ma anche con tutto questo per aiutarti, a volte devi tornare alle basi e testare il tuo codice contro una specie di analizzatore, e la realtà è che la maggior parte delle piattaforme embedded non ti offre il lusso di più di un semplice compilatore di base e una OEJA-Board di EE per aiutarti.

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

Non ho fatto alcuna programmazione incorporata a livello aziendale, ma la mia laurea triennale riguardava principalmente sistemi embedded, dai quali ho alcuni anni di esperienza reale. Abbiamo usato C su Atmel AVR e ho toccato alcuni chip Texas Instruments con VHDL, e ho avuto alcune cose teoriche su ARM.

In quello che avevamo, era circa il 50-60% di programmazione (C), il 20% di pianificazione / progettazione (UML), e il resto era l'elettronica fisica (saldatura, misurazione, cablaggio, produzione di cavi, ecc.). Sono anche d'accordo che è stato molto interessante e divertente da fare, e in realtà vorrei anche avere una carriera nei sistemi embedded. Purtroppo, con un mercato molto piccolo nei sistemi embedded, ho dovuto ricorrere al semplice vecchio EE Java.

Ma sto divagando; Direi che le percentuali sopra menzionate sono abbastanza vicine ai posti di lavoro nel mondo reale, dal momento che i nostri insegnanti hanno le loro imprese e hanno anche menzionato che cercheranno di renderlo il più realistico possibile. Abbiamo persino avuto turni di 180 gradi nei requisiti di metà progetto, heh heh.

Come per lo stack. Conoscere la programmazione integrata ti darà grandi possibilità di creare prodotti hardware veri e propri che avresti potuto produrre in impianti reali in Asia, quindi assemblarli presso la tua sede (sia a casa che nella tua azienda). È molto interessante! Puoi anche realizzare molti gadget che ti saranno d'aiuto a casa, come i dispositivi di controllo del movimento, il timer per una macchina da caffè per preparare automaticamente il tuo joe mattutino e così via. Cose davvero interessanti!