Wird es in Zukunft möglich sein, Code in C++ für PIC-Mikrocontroller zu schreiben?

Wird es jemals möglich sein, C++ zum Codieren von PICs zu verwenden? Gibt es Hardwarebeschränkungen, die uns daran hindern, C++ zu verwenden? Wie stark erhöhen sich die Größe der generierten .hex-Datei und die Laufzeit des Programms, wenn wir C++ anstelle von C verwenden? Ist es praktisch möglich, C++ für aktuelle PICs zu verwenden? Gibt es diesbezüglich irgendwelche Zukunftspläne oder laufende Entwicklungen?

Ich denke, es ist möglich und wird möglich bleiben, aber AFAIK wird es nicht empfohlen, da es Strukturen und Funktionen auf hoher Ebene implementiert, die für eine stark hardwarebezogene Programmierung nicht geeignet sind
Da die Antwort "Ja, es gibt bereits C++-Compiler" lautet, werde ich diese hier stehen lassen, aber in Zukunft sollten Sie sich darüber im Klaren sein, dass es bei Stack Exchange-Fragen um überprüfbare Fakten gehen sollte, nicht um Vermutungen über die Zukunft.
@clabacchio: Nicht unbedingt wahr. In C++ zahlen Sie nur für das, was Sie nutzen. Siehe meine Antwort unter: electronic.stackexchange.com/questions/3027/…
"PICs" ist eine nutzlose Verallgemeinerung. Auf einigen Low-End-PICs (denken Sie an 10F200) ist C fast unmöglich zu verwenden. Auf einigen High-End-PICs (32MX-Serie) soll derzeit C++ verwendet werden, und es gibt sicherlich keinen technischen Grund, warum dies nicht möglich wäre. Eine bessere Fokussierung könnte also eine brauchbarere Antwort geben, im Moment beantwortet jeder tatsächlich eine andere Frage.

Antworten (5)

Wird es jemals möglich sein, C++ zum Codieren von PICs zu verwenden?

Ja, das ist jetzt möglich. Für dsPIC gibt es den IAR Systems C++ Compiler (obwohl er sehr alt ist und nicht unterstützt wird).

Eine weitere Option ist die Verwendung eines C++-zu-C-Konverters. Konvertieren Sie mit einem vorgefertigten Schritt C++ in C und geben Sie dann das (böse aussehende) C an Ihren normalen C-Compiler weiter. Schauen Sie sich LLVM oder den C++-Compiler von Comeau an, die beide das tun. Comeaus kostet nur 50 US-Dollar, aber es wird wahrscheinlich einige Anstrengungen erfordern, um die gesamte Toolchain und die Bibliotheken ordnungsgemäß zum Laufen zu bringen.

Gibt es Hardwarebeschränkungen, die uns daran hindern, C++ zu verwenden?

Kurze Antwort, nein, es gibt keine Hardwarebeschränkungen. Lange Antwort, C++ fördert sicherlich die Verwendung eines Heaps und / oder Stacks, mit dem kleinere MCUs mit begrenztem RAM zu kämpfen haben.

Warum kämpfen sie mit einem Haufen/Stapel? Aus zwei Gründen: A) Viele MCUs haben begrenzten RAM, sicherlich nicht genug für einen Heap und kaum genug für einen Stack. B) Viele MCUs können Zeiger nicht gut handhaben, sodass die Verwendung von Variablen auf dem Stapel die Leistung wirklich beeinträchtigt.

Wenn Leute nach der Verwendung von C++ auf einer MCU fragen, finde ich es konstruktiv, C++ mit C zu vergleichen. Die genau gleichen Fragen wurden (und werden immer noch) zu C auf einer MCU gestellt. Früher sträubten sich die Leute vor der Idee. Eine Hochsprache, auf 256 Byte RAM MCU ?? Unmöglich. Aber jetzt wissen wir alle, dass es möglich ist. Ich habe C für einen PIC12 geschrieben. Kein Problem. Es ist möglich, weil A) die Softwareentwickler wissen, dass sie ein bisschen vorsichtig sein müssen: Verwenden Sie kein malloc() usw. und B) der Compiler speziell für die MCU geschrieben wurde. Der Compiler wird auch bei der Speicherzuweisung besonders vorsichtig sein, er wird nicht versuchen, einen Heap zu erstellen, und erstellt möglicherweise keinen Stapel. Einige C-Compiler lassen Sie einfach keinen wiedereintrittsfähigen (rekursiven) Code schreiben, der unbedingt einen Stack erfordert.

Da man weiß, dass es möglich ist, C für eine MCU zu schreiben, gelten die gleichen Antworten für die Frage, ob C++ auf einer MCU geschrieben werden soll. Solange der Compiler die Einschränkungen des Zielgeräts versteht und der Benutzer auch die Sprache versteht, gibt es wirklich kein Problem. In C++ zahlen Sie nur für das, was Sie nutzen. Es ist durchaus möglich, C++ (mit Objekten und allem) zu schreiben, das genau die asm-Ausgabe erzeugt, die Sie erhalten hätten, wenn Sie C verwendet hätten.

Nun, PIC32s kommen sicherlich mit C++ zurecht. Sie haben bis zu 64kB RAM und basieren auf dem MIPS-Core, also einem ausgewachsenen 32-Bit-Prozessor. Es kann sowohl mit Zeigern und einem Stack als auch mit einem PC umgehen. Tatsächlich gibt es PCs, die auf MIPS basieren (oder zumindest gab es früher).

Leider gibt es so viele Missverständnisse rund um C++. Selbst sehr erfahrene Programmierer scheinen keine Ahnung zu haben, wie die Sprache funktioniert. Siehe meine Antwort , warum C++ für eingebettete CPUs geeignet ist.

Wie stark erhöhen sich die Größe der generierten .hex-Datei und die Laufzeit des Programms, wenn wir C++ anstelle von C verwenden?

Wie gesagt, vielleicht gibt es keinen Unterschied. Bjarne Stroustrup hat eine Reihe von C/C++-Compilern verglichen, um die Zeit- und Platzleistung für eine Reihe von Operationen zu vergleichen. Die Ergebnisse waren sehr unterschiedlich. In einigen Fällen wurde C++ langsamer und größer, in einigen Fällen langsamer und kleiner oder schneller und größer und sogar schneller und kleiner! Die Antwort auf Ihre Frage lautet also, dass es stark vom Compiler abhängt, aber im Allgemeinen muss es überhaupt keinen Unterschied machen. Weitere Einzelheiten finden Sie im Technischen Bericht zur C++-Leistung

Gibt es diesbezüglich irgendwelche Zukunftspläne oder laufende Entwicklungen?

Das weiß ich nicht. Ich weiß, dass der Microchip C32-Compiler Open Source ist und Sie die Quelle herunterladen können. Ich weiß auch, dass jemand, mit dem ich zusammengearbeitet habe, tatsächlich einige Anweisungen online gefunden und es geschafft hat, den Compiler dazu zu bringen, C++-Code zu kompilieren. Aber er verließ das Unternehmen, bevor er mich mit einer richtigen Werkzeugkette ausstatten konnte.


AKTUALISIEREN

Microchip bietet jetzt einen C++-Compiler für seine PIC32-Reihe eingebetteter MCUs an.


von der IAR-Webseite: „Legacy-Produkt: IAR Embedded Workbench für dsPIC ist ein Legacy-Produkt. IAR Systems aktualisiert es nicht und es ist nicht möglich, eine Support- und Update-Vereinbarung dafür zu erwerben.“
Ich weiß, dass IAR-Produkte großartig sind, aber leider sehr teuer und es scheint "alt" zu sein. Ich weiß, dass C++ auf jeder Plattform machbar ist, solange Sie nicht alle Funktionen nutzen. Es fügt jedoch die Möglichkeit für eine zusätzliche Abstraktionsebene mit Klassen hinzu. Ich verwende Vorlagen nicht oft und verwende überhaupt keine dynamischen Speicherzuweisungen. Kennt jemand zufällig einen anderen Konkurrenten für C++ auf PIC24/PIC32?
Ja, tut mir leid, es war nicht wirklich ein toller Fund. Lassen Sie mich meiner Antwort noch einige Dinge hinzufügen.
Ich würde C als Konkurrenten für C++ auf einem Mikrocontroller betrachten. Mir fällt nichts ein, was ich in C++ tun möchte, was ich in C nicht tun kann, und es gibt weniger unsichtbare Funktionsaufrufe (Konstruktoren, Destruktoren usw.). Macht den Code deterministischer und einfacher. Welche Funktionen von C++ sind ein Muss, das sich mit C nicht durcheinanderbringen lässt?
Man könnte fragen: "Welche Funktionen von C sind ein Muss, die in ASM nicht durcheinandergebracht werden können?" Antwort: „Nichts“. Die Vorteile liegen in einer verbesserten Möglichkeit für den Designer, das Design zu spezifizieren, und in der Möglichkeit, dass der Compiler überprüft, ob die Implementierung korrekt ist. Siehe meine Antwort electronic.stackexchange.com/questions/3027/… für eine Liste der wirklichen und unmittelbaren Vorteile von C++ in dieser Hinsicht.
Schade, dass ich keine Binärdateien für LLVM finden kann. Das Comeau's scheint ein seltsames Programm zu sein, das Worte wie "atemberaubend, erstaunlich und fabelhaft" verwendet (dh was KANN es tun? - Ich habe keine Ahnung, ich habe keine 50 $ dafür bezahlt!). Ich müsste LLVM in einer VMware testen, aber das klingt für den täglichen Gebrauch sehr schmerzhaft.
Ja, es ist sehr traurig, dass es keine großartigen Lösungen gibt.
Sie können den Comeau-Compiler online ausprobieren: comeaucomputing.com/tryitout
Ich habe Ihnen das Kopfgeld als einzige nützliche Antwort auf die Kopfgeldperiode zuerkannt. Ich habe zufällig das chipKIT32 entdeckt, das Arduino-kompatibel ist und somit C++ verwendet! Ich habe sogar pic32-g++.exe gesehen, also ist das irgendwie vielversprechend. Ich werde hier posten, wenn ich etwas daraus machen kann. Die Dokumentation der neuen zukünftigen Compiler von Microchip hat den C++-Status von „nicht unterstützt“ auf „noch nicht unterstützt“ geändert.
Danke Hans. Gute Nachrichten über das chipKIT32 und sehr gute Nachrichten, dass Microchip eines Tages einen PIC32 C++ Compiler haben könnte!
Es ist wichtig zu beachten, dass es bei Prozessoren wie "klassischen" PICs oder dem 8x51 nicht möglich ist, guten Code zu generieren, ohne einen schleifenfreien Aufrufgraphen zu generieren. Compiler für solche Maschinen sind im Allgemeinen pessimistisch in ihrer Call-Graph-Generierung, aber für Code, der in C geschrieben ist, ist das normalerweise kein Problem. Ich habe nicht versucht, C++ auf solchen Plattformen zu programmieren, würde aber erwarten, dass es in vielen Fällen schwieriger sein kann zu beweisen, dass eine Routine nicht rekursiv aufgerufen werden kann.
@supercat - Das ist eigentlich ein sehr interessanter Punkt.
Welche C-Compiler erlauben keinen rekursiven Code?
Der IAR C++-Compiler-Link ist jetzt tot.
@Dean - Ich denke, es gibt mindestens einen C-Compiler für den PIC, der dies nicht tut, vielleicht den CSS -Compiler . Außerdem erlaubt der PSoC-Compiler im Allgemeinen keinen reentranten Code .

Wie stark erhöhen sich die Größe der generierten .hex-Datei und die Laufzeit des Programms, wenn wir C++ anstelle von C verwenden?

Hängt davon ab, welche Funktionen Sie verwenden. Wenn Sie die objektorientierten Kernfunktionen (Klassen + Methoden) verwenden, hat dies wahrscheinlich nur sehr geringe Auswirkungen (verstümmelte Variablen- / Funktionsnamen länger, sodass die Symboltabelle wahrscheinlich etwas zunimmt). Vorlagen sollten bei einem guten Compiler auch nicht viel beitragen.

Wenn Sie völlig verrückt werden und Dinge wie die Standard-Vorlagenbibliothek verwenden und dynamische Speicherzuweisung und Ausnahmen verwenden, werden Sie wahrscheinlich auf Code-Bloat stoßen.

Nur eine Warnung für das OP: Seien Sie bei der Speicherzuweisung auf kleinen Speicherarchitekturen und eingebetteten, immer laufenden Systemen sehr vorsichtig.
könnte der "-1"er bitte kommentieren, warum er/sie nicht zustimmt?
Ich bin nicht der -1er, aber Templates sind eine Funktion, die mit großer Sorgfalt verwendet werden muss, um Code-Bloat zu vermeiden. Sie können leicht viele Kopien eines Algorithmus haben, wenn einer ausreichen würde.
Dazu müssten Sie die Vorlage tatsächlich mit mehreren verschiedenen Datentypen verwenden, und eine Kopie WÜRDE NICHT ausreichen, es sei denn, Sie verwenden polymorphen Code, der eine gemeinsame Basisklasse hat. (In diesem Fall entstehen Laufzeitkosten.) Vorlagen bewirken nicht auf magische Weise, dass Ihr Code aufgebläht wird, sie verursachen nur aufgeblähten Code, wenn Sie sie mit mehreren Datentypen verwenden, ohne sich der Konsequenzen bewusst zu sein.

Es gibt bereits C++-Compiler für pic, zum Beispiel http://www.sourceboost.com/Products/BoostCpp/Overview.html

Ich habe das nicht benutzt und weiß nichts darüber, außer dass es existiert ...

Um Ihre Frage etwas zu verallgemeinern, gibt es ARM-Prozessoren, die für den Embedded-Markt gebaut wurden und eine MMU (Memory Management Unit) enthalten. Speichergröße und -zuweisung machten Sprachen wie Java und C++ zu schlechten eingebetteten Entscheidungen. Da eingebettete Prozessoren immer schneller und leistungsstärker werden und Speicher immer dichter und billiger werden, ändert sich die Sprachauswahl, die Embedded-Ingenieuren zur Verfügung steht, dramatisch. Ein 32-Bit-600-MHz-ARM-Prozessor mit MMU und einer 64-G-Flash-Karte ist ein großartiger Kandidat für C++-Anwendungen. Ob es zur Definition des klassischen Embedded-Prozessors passt, ist eine andere Frage.

Wahrscheinlich ja ... aber Sie sollten es sowieso nicht ... C ist die eingebettete Sprache und es gibt keine Vorteile bei der Verwendung von C++. Oder besser gesagt, die Vorteile von C überwiegen bei weitem die Vorteile von C++ für Embedded. Verschwenden Sie nicht Ihre Zeit.

  • Wenn Sie wissen, wie man Funktionszeiger usw. verwendet, können Sie wie C++ codieren, dort gibt es kein Problem.
Ich bin anderer Ansicht. Sie können viele Funktionen von C++ (Klassen, Templates, Operatorüberladung, Referenzen) mit geringen bis keinen Laufzeitkosten verwenden. Ja, Sie können all diese Dinge in einfachem C mit hackigen Konstrukten tun, aber es ist eine Belastung für Ihr Gehirn, und ich würde viel lieber C++ verwenden. (Natürlich würde ich viel lieber eine bessere Sprache verwenden, aber ich würde sofort einen C++-Compiler gegenüber einfachem C auswählen.)
Klassen = Strukturen (ohne eingebaute Methoden, aber wenn Sie möchten, können Sie einen Funktionszeiger in der Struktur speichern und diese aufrufen). Templates = verwendest du die??? Operatorüberladung = ja das möchte ich auch. Referenzen = Zeiger, nicht wahr? Zumindest mit C können Sie nur die 'Features' von C++ verwenden, die Sie möchten, ohne sich Gedanken über die Generierung von übermäßigem Code machen zu müssen oder eine zufällig große Bibliothek einbinden zu müssen, nur um etwas zum Kompilieren zu erhalten.
Ich bin auch anderer Meinung.
Ja, Vorlagen sind eine äußerst leistungsfähige Möglichkeit, zuverlässigen und leistungsstarken Code zu generieren. Referenzen sind ein zuverlässigerer Zeiger. Auch bei C++ zahlen Sie nur für die Features, die Sie nutzen. Ich denke, Sie müssen C++ wirklich besser verstehen.
Leute, es tut mir leid.. C ist die eingebettete Sprache. Ja, Sie können C++ machen, aber die Vorteile werden immer marginal sein. Ein gut geschriebener C-Code übertrifft an jedem Tag der Woche jeden C++-Code. Das zumindest meine Erfahrung. Ich habe irgendwo gelesen, dass es schwieriger ist, sich mit C++ zu erschießen, aber wenn Sie es einmal tun, nimmt es das ganze Bein mit. Ich stimme vollkommen zu. Wenn Sie dem Metal nahe sind, wollen Sie keine endlosen Abstraktionen, Overloader usw. Der beste Weg ist, sich an die Grundlagen zu halten.
Ich weiß nicht, was Sie mit "C ist die eingebettete Sprache" meinen. Sicher, es ist sehr beliebt. Wollen Sie damit sagen, dass es die bestmögliche Sprache ist? Sicher nicht.
@Rocketmagnet 90 % des eingebetteten Codes da draußen ist C. Ist es das Beste? Ich weiß es nicht, aber es ist das gebräuchlichste und am einfachsten zu wartende. Dies ist eine Frage des Geschmacks, ich finde C++ geschmacklos für Embedded. Noch geschmackloser finde ich es für die Anwendungsprogrammierung, es gibt bessere Sprachen, Lua, Java usw. sind einige Beispiele. Ich kann gut programmieren, bin aber kein Programmierer, also belasse ich es dabei.
@Rocketmagnet: Das Aufrufen einer C++-Methode, die möglicherweise Ausnahmen auslöst, führt zu einem erheblichen Mehraufwand, unabhängig davon, ob die Methode tatsächlich welche auslöst oder nicht. Wenn man Ausnahmen nicht global deaktiviert, gibt es meines Erachtens keine bequeme Möglichkeit, sie nur dort zu bezahlen, wo sie verwendet werden.
@Ktc: Überladungen können sehr hilfreich sein, wenn Sie versuchen, effizienten Code zu schreiben. Wenn einer Funktion normalerweise ein 8-Bit-Wert übergeben wird, aber manchmal ein 16-Bit-Wert, werden durch separate Methoden für die 8-Bit- und 16-Bit-Fälle (auch wenn erstere einfach mit letzteren verkettet werden) zwei Anweisungen pro eingespart Website aufrufen. Bei manchen Projekten kann sich das sehr schnell summieren. Überladungen können die Verwendung separater Methoden erleichtern. Ich wünschte, das C-Standards-Komitee würde Überladungen für statische und Inline- Methoden zulassen; Der traditionelle Einwand gegen das Überladen war in der Vergangenheit, dass es eine Namensverstümmelung erfordert, aber ...
...das wäre nur ein Problem für Namen, die über einen externen Code zugänglich wären. Das Überladen auf statische und Inline-Funktionen zu beschränken, würde deren Nützlichkeit in keiner Weise beeinträchtigen, da eine Header-Datei leicht sagen inline int foo(unsigned char x) { return foo_byte(x); }und jeden Aufruf, foo()der an übergibt , unsigned charin einen Aufruf von umwandeln könnte foo_byte().
@Ktc: Wenigstens haben Leute wie ich dank Leuten wie dir einen Job. Übrigens finde ich es ziemlich seltsam, dass Sie Assembler nicht über C stellen, weil es näher am Metal liegt. Entschuldigung, aber Ihre Antworten und Kommentare sind reine BS.