ARM az ARM, tök mindegy, hogy hová megy. Egy gyártónak van egy procicsaládja és abból lehet válogatni, vagy akár gyártatni is, ha éppen olyan az igény. Régebben az utóbbiak voltak a gyakoriak, ma meg már az előbbi, mivel eszméletlenül tud skálázódni szinte mindegyik architektúra, nem ritka hogy adott projektre együtt van az M-line és az A-line (ha már szóba hoztad az ST-t ) a legkisebbtől a legnagyobbig. Mert pl. ugyanaz a vezérlő megy az A3-as full fapad és az A8-as full extra kivitelébe, de az elsőnél elég a legkisebb uC is, mert alig van kezelendő funkció.
C és C++ - ahogy dabadab is írja - teljesen más világ. Sajnos a hazai színvonalat mutatja, hogy így kerülnek ki a fejlesztői állásajánlatok. Ami a kettőben hasonlít, az a szintaktika, de a mögöttes gondolkodás nagyon más. C++-osként szinte azonos szinten indulsz java-val vagy C#-pal (szo-szo), csak a szintaktikát kell megváltoztatni, még hc c coderként c++-ban tudsz majd írni egy for ciklust, de oop gondolkodás az pl. teljesen kimarad, anélkül meg minek c++.
VC az csak szerkesztőként is használható, én pl. abban fejlesztek uC-re. De rengetegen nyomják Eclipse-ben vagy Netbeans-ben is. Igazából ami a uC felé kell az az interface ami lekezeli a jtag/nexus portot. Eclipse-hez szinte minden gyártó ad pl. plug-int a kis hw-éhez. VS-nél általában nincs add-in, ellenben talán a legprofibb fejlesztőeszköz. Pl. egy VS Visual Assist-tal kiegészítve és Matlabbal megtámogatva olyan rapid sw prototype és automatikus tesztkörnyezetet, illetve "big data" alapú algoritmus fejlesztést tudsz csinálni, aminek közelében nincs semmi, főleg nem a kb. 2000$-os áron amibe ez kerül.
Objektum orientáltság ott jön elő már uC-n is, amikor komponens alapon kéne fejleszteni. Na most ez C-ben egész addig viszonylag kezelhető, amíg csak egy cég van és láthatod a teljes forráskódot és ért is hozzá az összes kóder (ha harmada már igen, akkor az nagy szó!). Egyéb esetben vagy van egy autosar alapú megközelítés végtelen szívással vagy simán vannak jól ledokumentált moduljaid és annak adod akinek akarod. Ráadásul egy - nem túl bonyolult - komplexitás felett az objektum orientált megközelítés sokkal gyorsabb kódolást tesz lehetővé. Triviális példa uC kapcsán amikor mondjuk van 5-6 kimeneted, amiket használhatsz mondjuk led, hangszóró, lcd fényerő, stb. meghajtására. Na most c alapon ekkor írsz 5-6 külön drivert vagy annyit ahány csoportod van. Objektum orientált alapon meg van egy ős driver osztályod és azt leszármaztatod mondjuk annyi felé ahány csportod van és majd azokat példányosítod. Utóbbi megközelítés kb. harmad annyi idő és sokkal gyorsabban javítható/módosíthat ha a requirement változik.
Alchemist. Értem mit akarsz mondani a fogyasztással, de ezek gyakorlatilag kimerülnek távirányítóknál ma már. Egyébként egy olyan helyet sem tudok ahol c-t amiatt használnának, mert azzal kevesebbet fogyaszt egy uC, főleg hogy a hűtőlap is ritkán látott vendég a mai beágyazott prociknál 100MHz-nél is akár, amivel már azért világot váltasz meg ilyen szinten. Ahol meg számít a fogyasztás (telefon, tablet) ott meg ugye mostanában a virtuális gép a divat és nem a c.
''A file-cserélés öli meg a filmipart? Inkább a filmipar öli meg a file-cserélést. 2 hónapja nincsen semmi értelmes film, amit érdemes lenne letölteni...''