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 Hardwareeinschränkungen, die uns daran hindern, C ++ zu verwenden? Um wie viel 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 zukünftige Pläne oder Weiterentwicklungen?

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 andere Option ist die Verwendung eines C ++ zu C-Konverters. Konvertieren Sie C ++ mithilfe eines Pre-Build-Schritts in C und geben Sie das (böse aussehende) C Ihrem normalen C-Compiler. Schauen Sie sich LLVM oder Comeaus C ++ - Compiler an, die beide das tun. Comeaus kostet nur 50 US-Dollar, aber es wird wahrscheinlich einige Mühe kosten, bis die gesamte Toolchain und die Bibliotheken ordnungsgemäß funktionieren.

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

Kurze Antwort, nein, es gibt keine Hardwareeinschränkungen. Lange Antwort, C ++ empfiehlt 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, nicht genug für einen Heap und kaum genug für einen Stack. B) Viele MCUs verarbeiten Zeiger nicht gut, 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. Genau die gleichen Fragen wurden (und werden) über C auf einer MCU gestellt. Die Leute hielten sich immer an die 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. Dies ist möglich, weil A) die Softwareentwickler wissen, dass sie etwas vorsichtig sein müssen: Verwenden Sie nicht malloc () usw. und B) der Compiler wurde speziell für die MCU geschrieben. Der Compiler ist auch bei der Speicherzuweisung besonders vorsichtig. Er versucht nicht, einen Heap zu erstellen, und erstellt möglicherweise keinen Stapel. Bei einigen C-Compilern können Sie einfach keinen rekursiven (rekursiven) Code schreiben, für den unbedingt ein Stapel erforderlich ist.

In dem Wissen, dass es möglich ist, C für eine MCU zu schreiben, gelten die gleichen Antworten für die Frage, C ++ auf einer MCU zu schreiben. 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 verwenden. 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.

Jetzt können PIC32s sicherlich mit C ++ umgehen. Sie haben bis zu 64 KB RAM und basieren auf dem MIPS-Kern, einem richtig erwachsenen 32-Bit-Prozessor. Es kann sowohl mit Zeigern und einem Stapel als auch mit einem PC umgehen. In der Tat gibt es PCs, die auf dem MIPS basieren (oder zumindest früher).

Leider gibt es so viele Missverständnisse in Bezug auf 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.

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

Wie gesagt, es kann keinen Unterschied geben. Bjarne Stroustrup hat eine Reihe von C / C ++ - Compilern verglichen, um die Zeit- und Raumleistung für eine Reihe von Operationen zu vergleichen. Die Ergebnisse waren sehr unterschiedlich. In einigen Fällen kam das C ++ langsamer und größer heraus, 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 sie stark vom Compiler abhängt, aber im Allgemeinen muss es überhaupt keinen Unterschied machen. Weitere Informationen finden Sie im Technischen Bericht zur C ++ - Leistung

Gibt es diesbezüglich zukünftige Pläne oder Weiterentwicklungen?

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ß die Firma, bevor er mich mit einer richtigen Werkzeugkette ausstatten konnte.

AKTUALISIEREN

Microchip verfügt jetzt über einen C ++ - Compiler für seine PIC32-Reihe eingebetteter MCUs.

Um wie viel 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 (Klasse + Methoden) verwenden, hat dies wahrscheinlich nur sehr geringe Auswirkungen (verstümmelte Variablen- / Funktionsnamen sind länger, sodass die Symboltabelle wahrscheinlich etwas zunimmt). Mit einem guten Compiler sollten Vorlagen auch nicht viel hinzufügen.

Wenn Sie total verrückt werden und Dinge wie die Standardvorlagenbibliothek aufrufen und dynamische Speicherzuweisungen und Ausnahmen verwenden, werden Sie wahrscheinlich auf aufgeblähten Code stoßen.

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 eingebetteten Markt entwickelt wurden und eine MMU (Memory Management Unit) enthalten. Die Speichergröße und -zuordnung führten dazu, dass Sprachen wie Java und C ++ schlecht eingebettet waren. Da eingebettete Prozessoren immer schneller und leistungsfähiger werden und der Speicher dichter und billiger wird, ändern sich die Sprachoptionen für eingebettete Ingenieure dramatisch. Ein 32-Bit-600-MHz-ARM-Prozessor mit MMU und einer 64G-Flash-Karte ist ein hervorragender Kandidat für C ++ - Anwendungen. Ob es zur Definition des klassischen Embedded-Prozessors passt, ist ein weiteres Problem.

Wahrscheinlich ja ... aber Sie sollten es sowieso nicht ... C ist die Sprache von Embedded und es gibt keine Vorteile 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. Sie können wie C ++ codieren, da gibt es kein Problem.