Is het mogelijk om in de toekomst code te schrijven in C ++ voor PIC-microcontrollers?

Is het ooit mogelijk om C ++ te gebruiken voor het coderen van PIC's? Zijn er hardwarebeperkingen die ons verhinderen om C ++ te gebruiken? Hoeveel de grootte van het gegenereerde .hex-bestand en de bedrijfstijd van het programma nemen toe als we C ++ gebruiken in plaats van C? Is het praktisch mogelijk om C ++ te gebruiken voor huidige PIC's? Zijn hier toekomstplannen of doorlopende ontwikkelingen over?

9
@clabacchio: Niet noodzakelijkerwijs waar. In C ++ betaalt u alleen voor wat u gebruikt. Zie mijn antwoord op: electronics.stackexchange.com/questions/3027/…
toegevoegd de auteur Armandas, de bron
toegevoegd de auteur Gangnus, de bron
Omdat het antwoord "Ja, er zijn C ++ -compilers bestaan", laat ik deze staan, maar in de toekomst moet je je ervan bewust zijn dat Stack Exchange-vragen over verifieerbare feiten zouden moeten gaan, geen veronderstellingen over de toekomst.
toegevoegd de auteur Orangecrush, de bron
"PIC's" is een nutteloze generalisatie. Op sommige low-end PIC's (denk aan 10F200) is C bijna onmogelijk te gebruiken. Op sommige high-end PIC's (32MX-serie) wordt gezegd dat C ++ nu wordt gebruikt en er is zeker geen technische reden waarom dit niet het geval was. Dus sommige betere focussering zou een bruikbaarder antwoord kunnen geven, op dit moment is iedereen in feite bezig met het beantwoorden van een andere vraag.
toegevoegd de auteur tomzx, de bron
Ik denk dat het mogelijk is en mogelijk zal blijven, maar AFAIK wordt niet aanbevolen omdat het hoogwaardige structuren en functies implementeert die niet geschikt zijn voor sterk hardware-gerelateerde programmering
toegevoegd de auteur clabacchio, de bron

5 antwoord

Is het ooit mogelijk om C ++ te gebruiken voor het coderen van PIC's?

Ja, het is nu mogelijk. Voor dsPIC is er de IAR Systems C ++ Compiler (hoewel het erg oud is en niet wordt ondersteund).

Een andere optie is om een ​​C ++ naar C-converter te gebruiken. Gebruik een pre-buildstap, converteer de C ++ naar C en geef de (vervelende) C aan je normale C-compiler. Neem een ​​kijkje op LLVM of Comeau's C ++ -compiler die beide dat doen. Comeau is slechts $ 50, maar het kost waarschijnlijk enige moeite om de hele toolchain en bibliotheken naar behoren te laten werken.

Zijn er hardwarebeperkingen die ons verhinderen om C ++ te gebruiken?

Kort antwoord, nee, er zijn geen hardwarebeperkingen. Langdurig antwoord, C ++ moedigt zeker het gebruik van een heap en/of stack aan, waar kleinere MCU's met beperkte RAM moeite mee hebben.

Waarom worstelen ze met een hoop/stack? Om twee redenen: A) Veel MCU's hebben een beperkte hoeveelheid RAM, zeker niet genoeg voor een hoop, en nauwelijks genoeg voor een stapel. B) Veel MCU's kunnen pointers niet goed verwerken, dus het gebruik van variabelen op de stapel doodt de prestaties echt.

Wanneer mensen vragen over het gebruik van C ++ op een MCU, vind ik het constructief om C ++ te vergelijken met C. Dezelfde vragen werden (en worden nog steeds gesteld) over C op een MCU. Vroeger hadden mensen geen idee van het idee. Een taal op hoog niveau, op 256 bytes RAM MCU ?? Onmogelijk. Maar nu weten we allemaal dat het mogelijk is. Ik heb C geschreven voor een PIC12. Geen probleem. Het is mogelijk omdat A) de softwareontwikkelaars weten dat ze een beetje voorzichtig moeten zijn: gebruik geen malloc() enz. En B) de compiler is speciaal geschreven voor de MCU. De compiler zal ook extra voorzichtig zijn met geheugentoewijzing, hij zal niet proberen een hoop te creëren en maakt mogelijk geen stapel. Sommige C-compilers laten je simpelweg geen recurrente (recursieve) code schrijven die absoluut een stack vereist.

Wetende dat het mogelijk is om C te schrijven voor een MCU, zijn dezelfde antwoorden van toepassing op de vraag van het schrijven van C ++ op een MCU. Zolang de compiler de beperkingen van het doelapparaat begrijpt en de gebruiker de taal begrijpt, is er echt geen probleem. In C ++ betaalt u alleen voor wat u gebruikt. Het is perfect mogelijk om C ++ (met objecten en alles) te schrijven die de exacte asm-uitvoer produceert die je zou hebben als je C. had gebruikt

Nu kunnen PIC32's zeker omgaan met C ++. Ze hebben maximaal 64 kB RAM en zijn gebaseerd op de MIPS-kern, wat een goed ontwikkelde 32-bits processor is. Het kan omgaan met wijzers en een stapel en een pc. Er zijn inderdaad pc's op basis van de MIPS (of althans, vroeger).

Helaas is er zoveel misverstand rondom C ++. Zelfs zeer ervaren programmeurs lijken geen idee te hebben hoe de taal werkt. Zie mijn antwoord over waarom C ++ geschikt is voor ingesloten CPU's.

Hoeveel de grootte van het gegenereerde .hex-bestand en de bedrijfstijd van het programma nemen toe als we C ++ gebruiken in plaats van C?

As I said, there may be no difference. Bjarne Stroustrup did a comparison of a bunch of C/C++ compilers to compare time and space performance for a number of operations. The results varied widely. In some cases, the C++ came out slower and larger, some cases slower and smaller, or faster and larger, and even faster and smaller! So, the answer to your question is that it depends heavily on the compiler, but in general, it need make no difference at all. For more detail, see the Technical Report on C++ Performance

Zijn er toekomstplannen of lopende ontwikkelingen hierop?

Dat weet ik niet. Ik weet dat de Microchip C32-compiler open source is en dat je de bron kunt downloaden. Ik weet ook dat iemand met wie ik heb gewerkt een aantal instructies online heeft gevonden en erin geslaagd is om de compiler C ++ -code te laten compileren. Maar hij verliet het bedrijf voordat hij in staat was mij op te leiden met een goede gereedschapsketting.


UPDATE

Microchip heeft nu een C ++ compiler beschikbaar voor zijn PIC32-reeks ingesloten MCU's.


17
toegevoegd
@Dean - Ik denk dat er ten minste één C-compiler voor de PIC is die dat niet doet, misschien de CSS één . Ook de PSoC-compiler staat algemene code niet toe .
toegevoegd de auteur Armandas, de bron
@supercat - Dat is eigenlijk een heel interessant punt.
toegevoegd de auteur Armandas, de bron
Bedankt Hans. Goed nieuws over de chipKIT32, en heel goed nieuws dat Microchip ooit een PIC32 C ++ -compiler zou kunnen hebben!
toegevoegd de auteur Armandas, de bron
U kunt de Comeau-compiler online proberen: comeaucomputing.com/tryitout
toegevoegd de auteur Armandas, de bron
Ja, het is heel triest dat er geen geweldige oplossingen in de buurt zijn.
toegevoegd de auteur Armandas, de bron
Ja, sorry, het was niet echt een geweldige vondst. Laat me wat meer dingen toevoegen aan mijn antwoord.
toegevoegd de auteur Armandas, de bron
Je zou je kunnen afvragen: "Welke kenmerken van C zijn een must-have die niet doormodderen kan worden in ASM?" Antwoord: "Niets". De voordelen zijn een groter vermogen voor de ontwerper om het ontwerp te specificeren en de compiler te laten controleren of de implementatie correct is. Zie mijn antwoord elektronica .stackexchange.com/questions/3027/& hellip; voor een lijst van de echte en onmiddellijke voordelen van C ++ in dit verband.
toegevoegd de auteur Armandas, de bron
Het is belangrijk op te merken dat processors zoals "klassieke" PIC's of de 8x51, het niet mogelijk is om goede code te genereren zonder een loop-vrije call-grafiek te genereren. Compilers voor dergelijke machines zijn over het algemeen pessimistisch in het genereren van call-grafieken, maar voor code geschreven in C is dat meestal geen probleem. Ik heb C ++ niet op dergelijke platforms geprobeerd te coderen, maar zou verwachten dat het in veel gevallen moeilijker is om te bewijzen dat een routine niet recursief kan worden genoemd.
toegevoegd de auteur firedfly, de bron
van de IAR-webpagina: "Legacy-product: IAR Embedded Workbench voor dsPIC is een verouderd product, IAR Systems werkt het niet bij en het is niet mogelijk om er een ondersteunings- en update-overeenkomst voor te kopen."
toegevoegd de auteur Travis Christian, de bron
Ik beschouw C als een concurrent voor C ++ op een microcontroller. Ik kan niets bedenken wat ik zou willen doen in C ++ dat ik niet kan doen in C en er zijn minder onzichtbare functieaanroepen (constructors, destructors, enz.). Maakt de code meer deterministisch en duidelijk. Welke functies van C ++ zijn een must-have die niet met C verward kan worden?
toegevoegd de auteur splattered bits, de bron
Welke C-compilers staan ​​geen recursieve code toe?
toegevoegd de auteur Dean, de bron
De IAR C ++ - compilerlink is nu dood.
toegevoegd de auteur Dean, de bron
Ik heb je de boutny als het enige bruikbare antwoord op de premieperiode toegekend. Ik ontdekte toevallig de chipKIT32, die compatibel is met Arduino en dus C ++ gebruikt! Ik heb zelfs pic32-g ++. Exe's gezien, dus dat is best veelbelovend. Ik zal hier posten als ik hier iets van kan krijgen. De documentatie van Microchip's nieuwe toekomstige compilers heeft de C ++ status veranderd van 'niet ondersteund' naar 'nog niet ondersteund' ..
toegevoegd de auteur Vader, de bron
Jammer dat ik geen binaries voor LLVM kan vinden. De Comeau lijkt een raar programma, met woorden als 'adembenemend, geweldig en fantastisch' (d.w.z. wat kan het doen?), Ik had geen idee, ik moest er geen 50 $ voor betalen!). Ik zou LLVM in een VMware moeten testen, maar klinkt erg pijnlijk voor dagelijks gebruik.
toegevoegd de auteur Vader, de bron
Ik weet dat IAR-producten geweldig zijn, maar helaas erg duur en het lijkt 'oud'. Ik weet dat C ++ mogelijk is op elk platform, zolang je niet alle functies gebruikt. Het voegt echter de mogelijkheid toe voor een extra laag abstractie met klassen. Ik gebruik vaak geen sjablonen en ik gebruik helemaal geen dynamische geheugenallocaties. Kent iemand een andere concurrent voor C ++ op PIC24/PIC32?
toegevoegd de auteur Vader, de bron

Hoeveel de grootte van het gegenereerde .hex-bestand en de bedrijfstijd van het programma nemen toe als we C ++ gebruiken in plaats van C?

Afhankelijk van welke functies u gebruikt. Als u de belangrijkste objectgeoriënteerde functies (klasse + methoden) gebruikt, heeft dit waarschijnlijk weinig effect (verminkte variabelen/functienamen langer, waardoor de symbolentabel waarschijnlijk enigszins zal toenemen). Sjablonen zouden ook niet veel moeten toevoegen met een goede compiler.

Als je helemaal gek wordt en dingen als de standaard sjabloonbibliotheek aantrekt en dynamische geheugentoewijzing en uitzonderingen gebruikt, kom je waarschijnlijk code-bloat tegen.

5
toegevoegd
Om dat te doen, zou je de sjabloon met verschillende gegevenstypen moeten gebruiken, en een kopie ZOU NIET volstaan, tenzij je polymorfische code gebruikt die een gemeenschappelijke basisklasse heeft. (In dat geval zijn er runtime-kosten.) Sjablonen veroorzaken op magische wijze niet dat uw code opzwelt, ze veroorzaken alleen maar opgeblazen code wanneer u ze met meerdere gegevenstypen gebruikt wanneer u zich niet bewust bent van de gevolgen.
toegevoegd de auteur Travis Christian, de bron
Kan de "-1" er alstublieft commentaar geven op waarom hij/zij het er niet mee eens is?
toegevoegd de auteur Travis Christian, de bron
Stel een waarschuwing voor het OP op, wees heel voorzichtig met geheugentoewijzing op kleine geheugenarchitecturen en embedded always running-systemen.
toegevoegd de auteur kenny, de bron
Ik ben niet de -1er, maar sjablonen zijn een functie die met de grootste zorg moet worden gebruikt om codezwelling te voorkomen. Je kunt gemakkelijk eindigen met veel kopieën van een algoritme als dat zou volstaan.
toegevoegd de auteur Peter Green, de bron

There are C++ compilers for pic already, for example http://www.sourceboost.com/Products/BoostCpp/Overview.html

Ik heb dit niet gebruikt en weet er niets van behalve dat het bestaat ...

4
toegevoegd

Waarschijnlijk wel ... maar je moet toch niet ... C is de taal van ingebed en er zijn geen voordelen verbonden aan het gebruik van C ++. Of beter gezegd: de voordelen van C wegen veel zwaarder dan de voordelen van C ++ voor embedded. Verspil geen tijd.

  • als je weet hoe je functie-aanwijzers moet gebruiken enz. Je kunt coderen als C ++, daar is geen probleem.
1
toegevoegd
Ja, sjablonen zijn een extreem krachtige manier om betrouwbare en krachtige code te genereren. Referenties zijn een betrouwbaardere aanwijzer. Met C ++ betaalt u ook alleen voor de functies die u gebruikt. Ik denk dat je C ++ echt beter moet begrijpen.
toegevoegd de auteur Armandas, de bron
Ik smeek ook om te verschillen.
toegevoegd de auteur Armandas, de bron
Ik weet niet wat je bedoelt met "C is de taal van embedded". Natuurlijk, het is erg populair. Zeg je dat het de best mogelijke taal is? Natuurlijk niet.
toegevoegd de auteur Armandas, de bron
@Rocketmagnet 90% van de ingesloten code die er is, is C. Is dit het beste? Ik weet het niet, maar het is de meest voorkomende en gemakkelijkst te onderhouden. Dit is een smaakprobleem, ik vind C ++ onsmakelijk voor ingebed. Ik vind het zelfs nog meer onsmakelijk voor het programmeren van applicaties, er zijn betere talen, lua, java enz. Zijn enkele voorbeelden. Ik kan goed coderen, maar ik ben geen programmeur, dus daar laat ik het bij.
toegevoegd de auteur Tim Ring, de bron
Jongens, het spijt me .. C is de taal van ingebed. Ja, je kunt C ++ doen, maar de voordelen zullen altijd marginaal zijn. Een goed geschreven C-code staat bovenaan elke C ++-code elke dag van de week. Dat tenminste mijn ervaring. Ik heb ergens gelezen, het is moeilijker om jezelf met C ++ neer te schieten, maar als je het eenmaal doet, kost het je hele been. Ik ben het er helemaal mee eens. Wanneer je dicht bij het metaal bent, wil je geen eindeloze abstracties, overloaders enz. De beste manier is om je aan de basis te houden.
toegevoegd de auteur Tim Ring, de bron
@Rocketmagnet: het aanroepen van een C ++ -methode die uitzonderingen zou kunnen opleveren, zal een aanzienlijke overhead met zich meebrengen, ongeacht of de methode deze daadwerkelijk gooit. Tenzij iemand globaal uitzonderingen uitschakelt, denk ik niet dat er een handige manier is om alleen te betalen waar ze worden gebruikt.
toegevoegd de auteur firedfly, de bron
@Ktc: overbelasting kan erg handig zijn bij het schrijven van efficiënte code. Als een functie meestal een 8-bitswaarde wordt doorgegeven, maar soms een 16-bitswaarde doorgeeft, hebben afzonderlijke methoden voor de 8-bits en 16-bits cases (zelfs als de eerste eenvoudig een ketting vormt voor de laatste) twee instructies per bel site. Bij sommige projecten kan dat snel oplopen. Overbelasting kan het gebruik van afzonderlijke methoden eenvoudiger maken. Ik zou willen dat het C-normencomité overbelastingen zou toestaan ​​voor statische en inline methoden; het traditionele bezwaar tegen historische overbelasting was dat het vernoeming van de naam vereist, maar ...
toegevoegd de auteur firedfly, de bron
... dat zou alleen een probleem zijn voor namen die via externe code toegankelijk waren. Het beperken van overbelasting tot statische en inlinefuncties zou op geen enkele manier het nut ervan schaden, omdat een headerbestand gemakkelijk inline int foo (unsigned char x) {return foo_byte (x); } en verander elke aanroep naar foo() die een unsigned char doorgeeft aan een aanroep naar foo_byte() .
toegevoegd de auteur firedfly, de bron
Ik ben het er niet mee eens. U kunt vele functies van C ++ gebruiken (klassen, sjablonen, operator-overloading, referenties) met weinig of geen looptijdskosten. Ja, je kunt al deze dingen in gewone C doen met hackish constructs, maar het is een belemmering voor je hersenen, en ik zou veel liever C ++ gebruiken. (natuurlijk zou ik liever een betere taal gebruiken, maar ik zou een C ++ -compiler in een oogwenk over gewone C kiezen.)
toegevoegd de auteur Travis Christian, de bron
Classes = structs (zonder ingebouwde methoden, maar als je wilt, kun je een functiewijzer opslaan in de struct en dat noemen). Templates = gebruik je die ??? Operator overbelasting = ja dat zou ik ook leuk vinden. References = pointers, niet? Met C kun je in ieder geval alleen de 'functies' van C ++ gebruiken die je wilt, zonder je zorgen te maken over het genereren van overtollige code of een willekeurige grote bibliotheek moeten opnemen om iets te kunnen compileren.
toegevoegd de auteur splattered bits, de bron
@Ktc: dankzij mensen zoals jij hebben mensen zoals ik op zijn minst een baan. En trouwens, ik vind het nogal vreemd dat je assembler niet boven C promoot, want het is dichter bij het metaal. Sorry, maar je antwoord en opmerkingen zijn pure BS.
toegevoegd de auteur Tibo, de bron

Als u uw vraag enigszins generaliseert, zijn er ARM-processors die zijn gebouwd voor de ingesloten markt die een MMU (memory management unit) bevatten. Geheugengrootte en toewijzing maakten talen zoals java en c ++ slechte ingesloten keuzes. Omdat ingesloten processors steeds sneller en krachtiger worden en het geheugen dichter en goedkoper wordt, veranderen de taalkeuzes die beschikbaar zijn voor ingesloten engineers drastisch. Een 32-bits 600 MHz ARM-processor met MMU en een 64 G-flashkaart is een geweldige kandidaat voor c ++ -toepassingen. Of het in de definitie van de klassieke embedded processor past, is een ander probleem.

1
toegevoegd