Ja, det är nästan säkert ett bra drag att lära sig att använda C så bra som möjligt (C ++ ger dig en bra utgångspunkt, men som leftaroundabout noterar kommer det fortfarande att finnas mycket att hämta , speciellt skillnaderna mellan kodning för små inbäddade system jämfört med att skriva för något som Windows) med tanke på att det är överallt.

De flesta mikrokontroller under en viss storlek (t.ex. PIC, AVR, MSP430, etc) använder C (eller assembler ) eftersom det finns många högkvalitativa (gratis- och $$ -versioner - t.ex. många kommersiella kompilatorer är baserade på den gratis GCC-kompilatorn) C-kompilatorer tillgängliga.
Du får andra språk som den utmärkta JAL för PIC (originalförfattare Wouter Van Ooijen som är medlem här), PICBASIC, Ada-varianter, men på grund av dess popularitet och antalet tillgängliga kompilatorer skulle jag säga att C är det språk som valts för de flesta. Detta betyder visserligen inte att det är det bästa språket, men att använda det mest populära språket kommer med uppenbara fördelar (dokumentation, support, bärbarhet, samarbete osv.)
För de mer komplexa och större 32-bitars mikro som många ARM-varianter, det finns också C ++ och andra kompilatorer tillgängliga.

Jag hoppade direkt in och tog några utvecklingskort och fick kodning. Du kan välja en låg-slut 8-bitars mikro som PIC16F (många startpaket på Microchip Direct)
En mitt i intervallet 16-bitars mikro som PIC24, och också en C / C ++ / inbäddad Linux ARM av något slag - STM32F4 ARM Cortex M4 Discovery är ett mycket billigt dev-kort som det kan vara värt att ta tag i.
På det programmerbara logik- och hårdvarubeskrivningsspråket (HDL - de två stora är Verilog och VHDL) -sidan kan det också vara värt att få tag på av ett FPGA- eller CPLD-dev-kort från Diglent eller liknande.

Om du inte vill vänta på ett dev-kort kan du ladda ner MPLAB eller MPLABX och använda den utmärkta simulatorn för att prova dig på PIC-utveckling. Samma sak gäller för andra verktyg också, till exempel kan du ladda ner Xilinx ISE Webpack gratis och prova HDL och programmerbar logisk design.

Lär dig C, och få ett billigt mikrokontrollerutvecklingskort, som en MSP430 eller ARM Cortex, och skriv åtminstone några C-program.

Jag har en datavetenskaplig examen och en programutvecklingsbakgrund , mestadels C ++ programmering för spel och nu iOS-spel och appar, men mitt sista jobb var en semi-pro EE-spelning som började med att göra en massa firmwareprogrammering för ett ARM Cortex M3-system, och slutade sedan med att jag lärde mig att göra några grundläggande kretskonstruktioner och kortlayout och design av ett par enkla kort. Så jag var i grund och botten tvungen att konfrontera problemet med att använda det bästa programmeringsspråket för att överbrygga hårdvaru- / mjukvarudesignen som någon som var ansvarig för båda ändarna av det.

C är absolut det språk du behöver veta. Det är enkelt för människor som programmerar i C ++ och aldrig behöver begränsa sig till C: s funktionsuppsättning för att säga "det är samma sak" men det är det inte. Speciellt hur C ++ har utvecklats och samlat in funktioner, och hur vanliga C ++ - programmerare använder dessa funktioner, är det verkligen en helt annan sak att arbeta med en ganska stor C-applikation i motsats till en C ++ - applikation. Din firmware SDK kommer att vara en massa C-bibliotek, allt annat som passar på en MCU kommer att vara ett C-bibliotek, alla operativsystem som är meningsfulla på en MCU kommer att skrivas i C, etc. etc.

Med detta sagt, eftersom många av MCU-verktygskedjorna där ute slutar använda GCC som sin kompilator, kommer du nästan säkert att ha en C ++ - kompilator tillgänglig om du använder en anständig MCU-familj. Men du måste vara mycket försiktig med de funktioner du använder, särskilt saker från standardbiblioteket, eftersom det är väldigt enkelt att sluta med en binär som är alldeles för stor för att passa på din enhet. Jag tror att det finns ett bra fall att använda C ++ på inbäddade enheter, C ++ har en hel del fina funktioner som har strö eller ingen storlek eller hastighetsstraff, du måste bara veta vad du gör och skriva kod på det sättet längre fram i C-stiländen av spektrumet än STL-änden av spektrumet när det gäller smart användning av funktioner.

Var inte uppmärksam på människor som säger att du kan använda Lua eller Python på en MCU med rätt inbäddad tolk bla, bla. Det är sant, jag har gjort det och det är kul, men just nu är det mer för leksaksprojekt och saker som dyker upp på Hack a Day. Jag tror att vi kommer att se mer av den typen av saker, eftersom Moores lag tillämpas obevekligt på även de minsta processorerna, det här är något som hände med spel där det brukade vara mycket montering, sedan höll de ut med C och C ++ längre än alla andra, och nu är allt så snabbt, och utvecklarproduktiviteten är så viktig att mycket utveckling sker med inbäddade språk på högre nivå eller i ett språk på hög nivå direkt. Ändå tar det några år innan du ser företag anställa firmwareprogrammerare med Python- och Lua-bakgrund.

Spenderar inte för mycket tid på montering heller. Det är inte dåligt att vara bekant med begreppen, men det är osannolikt att du kommer att göra mycket, om någon monteringsprogrammering. Det finns som denna konventionella visdom med spel och inbäddade att det är "bra att veta" montering, ofta upprepas av människor som inte arbetar inom dessa områden. Men i verkligheten är det mycket osannolikt att du kommer att skriva någon montering alls, någonsin, och om du gör det kommer det förmodligen bara att vara några rader för optimering eller något med hårdvaran du bara inte har ett API för (men du efter att du har skrivit en som innehåller några rader med montering). Jag har arbetat med flera spel och det här brädet / firmware-designprojektet och det totala antalet monteringslinjer jag har skrivit för kommersiella projekt är förmodligen i de låga tonåren. Det är inte produktivt, det är inte bärbart och det är inte läsbart så det används alltid som det sista möjliga alternativet.

Jag håller med alla andra om att du behöver vara väldigt kompetent i C.

Jag rekommenderar också att du lär dig minst ett monteringsspråk också. Att göra detta kommer att göra dig till en mycket bättre C-programmerare. Du måste veta vad som händer under huven, och detta är mycket mer sant i den inbäddade världen än vad det är i PC-världen.

Att förstå monteraren som din C genererar låter dig skriva mer optimalt C när det gäller hastighet och kompakthet. Snabbare kod betyder:

• du kan använda en långsammare billigare MCU och underskrida en konkurrent.
• Du kan sänka klockfrekvensen för förbättrad EMC-efterlevnad.
• i en applikation med låg effekt kan MCU tillbringa mer tid i sömn, vilket direkt leder till ökad batteritid.

Mer kompakt kod innebär att du kan använda en billigare MCU med mindre minne. Eller ha plats för fler funktioner.

Det andra språket du kan tänka dig att lära dig är Verilog. Det här är ett hårdvarubeskrivningsspråk, och det skiljer sig verkligen helt från C, inte bara i hur det ser ut utan också i dess funktionalitet. Verilog kommer att öppna vägen för att dra nytta av mycket kraftfulla marker som Cypress PSoC3 och 5. Det är en mikrokontroller med analog och digital omprogrammerbar hårdvara, vilket gör att du kan göra några fantastiska saker som är mycket svåra att göra med någon annan MCU. Du kan också göra FPGA -design.

Som en MSEE som har arbetat i försvarsindustrin i åtta år kan jag berätta att förståelse för hur man programmerar bra i LabVIEW (ett grafiskt, strikt typat, dataflödesspråk) innebär att du Det kommer aldrig att sakna arbete.

LabVIEW började som ett programmeringsspråk för hårdvarutekniker, du kan se detta i det faktum att koden ser väldigt ut som ett kretsschema. Under de senaste 25 åren har LabVIEW emellertid utvecklats till ett fullvärdigt, funktionsrikt språk med stöd för Object Orientation och multi-threading. I själva verket skulle jag hävda att det inte finns något annat programmeringsspråk, textbaserat eller på annat sätt, som är lättare att programmera en applikation med flera trådar än LabVIEW; detta beror till stor del på dess dataflödesparadigm. När antalet CPU-kärnor fortsätter att öka kommer LabVIEW att bli mer och mer relevant som ett allmänt språk.

En annan fördel med att känna till LabVIEW är att du bara är ett stenkast bort från att programmera FPGA med hjälp av LabVIEW FPGA-modul som tar din LabVIEW-kod och konverterar den till VHDL bakom kulisserna innan den skickas till Xilinx-kompilatorn. Du kan också använda dina LabVIEW-färdigheter för att övergå till programmering av realtidskod via LabVIEW Real-Time Module som använder antingen VxWorks eller Phar Lap.

Obs! Jag är en Certifierad LabVIEW-utvecklare.

Om du vill göra programmering av mikrokontroller på låg nivå bör du känna dig bekväm med programmeringssamlingsprogram (ju fler olika arkitekturer desto bättre), och ja, du kommer att använda C mycket mer än du använder C ++.

För allmänt ingenjörsarbete kommer matteorienterade språk som Matlab (även Scilab och GNU Octave) ofta att användas för modellering och prototyper.

Dessutom är många IDE för programvara och hårdvara skriptbart, vanligtvis med TCL eller LUA, så en viss bekantskap med skriptspråk i allmänhet (även Perl, Python, PHP, Javascript, etc.) skulle vara användbart.

För hårdvarudesign kommer du att behöva Verilog- och / eller VHDL-färdigheter.

Är C ++ tillräckligt? Kanske.

Kom ihåg att C används i ungefär 90-99% av alla MCU: er där ute, så C är ett måste i ditt CV.

Men eftersom du är en kille på hög nivå som du kan börja spela med Arduino: er eftersom de är programmerade med en nedskalad C ++, och det skulle ge en grov uppfattning om vad C ++ kan göra i MCU-världen just nu.

För mikrokontroller (och jag kommer bara att ta upp mikrokontroller) tycker jag att C är ett mycket bättre inmatningsspråk än C ++. Montering skulle vara nästa steg, fantastiskt för att hjälpa dig att förstå hur din C-kompilator skruvar upp dig, skapar buggar, stjäl klockor osv. Och pressar ut mest prestanda ur din plattform. Allt förutsätter att du pratar om en mikrokontroller - inte en arduino, BASIC Stamp eller någon annan plattform som involverar en inpackad mikrokontroller.

Svårt att säga vad som är användbart för "ditt fält" - och föreslå att du som student kanske inte riktigt vet vad ditt område är ännu !! - men jag tycker att din språkuppsättning verkar ganska rimlig och att du kommer att använda den om och om igen. Att ha ett bra grepp om ett strukturerat språk gör åtminstone nästa så mycket lättare, men jag tror att du alltid kommer att hitta dina Windows-programmeringskunskaper trevliga att ha i fickan.

Du kan lära dig C och vilken typ av samlarkod som genereras av C-satser om du arbetar med processorer, men du bör också lära dig själv hur man använder ett Unix-kommandoradsskal som bash och de verktyg som följer med det. som sed, ed, awk, vim / vi, find, tjära, gzip, ... samt Python som du kan använda på många plattformar och är ett bra sätt att "få saker gjort".

Du måste lära dig C om du vill vara en seriös inbäddad utvecklare. Du borde också känna monteraren även om du förmodligen mycket sällan kommer att använda den.

Jag definierar först elektronikingenjören som en person som är involverad i hårdvarudesign från firmware till kortdesign och till chipdesign. I vissa fall kommer du att göra firmware, som anges ovan behöver du "C". Djupare mjukvara blir helt enkelt ett verktyg, att förstå vissa comp sci-koncept på kompletterande språk från C / C ++ till Lisp som språk kommer att vara viktigare än detaljer. Du kommer att behöva programvara för att stödja ditt designarbete men det har inte företräde för att förstå de grundläggande gränserna för vad som kan göras i en fysisk implementering. Digital design är INTE Verilog / VHDL även om designen uttrycks på dessa språk. I full anpassad och in-silico design ser du Lisp-liknande språk och C-funktionella språk. Saker trender mer mot Python för skript, men det finns många Perl / Skill / C / System C / Verilog-A / VHDL testbänkar och kontrollprogram / skript.