Firmware schreiben:Montage oder hohes Niveau?

https://stackoverflow.com/questions/452139

19-08-2019
|

Frage

Bezüglich:

Wenn Sie Code für a schreiben Mikrocontroller Gibt es einen echten Unterschied, ob Sie in Assembler, C oder einer anderen Hochsprache schreiben?Wenn Sie C-Code schreiben würden, wie würden Sie ihn kompilieren?

Danke

Lösung

Einige Kommentare:

1) Absolut nicht Montage es sei denn, die Leistung oder Optimierung Einschränkungen rechtfertigen es. Folgende Messwerte gehen durch das Dach mit Montage:

Zeit, es zu codieren
Zeit zu debuggen es
Zeit zu testen
Zeit zu dokumentieren
Zeit, um herauszufinden (1 Jahr später), was es war dir dabei gedacht, wenn Sie es codiert
Chancen auf einen Fehler

2) Meine Präferenz wäre C ++ statt C für seinen Namensraum Verkapselung und seine Erleichterung von Compiler- objektorientierten Praktiken. C hat zu viele Möglichkeiten für globale Variablen und Namespace-Kollisionen. (Real-Time Java wäre schön, aber von dem, was ich verstehe, seine Anforderungen sind immer noch ziemlich hoch)

oder vielmehr eine Teilmenge von C ++: Ausschließen Ausnahmen, virtuelle Funktionen, Laufzeittypidentifikation, auch dynamische Speicherzuweisung in den meisten Fällen - im Grunde alles, was zum Zeitpunkt der Kompilierung nicht spezifiziert übrig geblieben ist, da es erfordert in der Regel eine Menge von zusätzlichen Ressourcen während der Laufzeit. Das ist das "aufblasen" von C ++.

Ich habe beide TI und IAR-Compiler für C ++, für die TMS320 und MSP430-Mikrocontroller (jeweils) und mit der richtigen Optimierungseinstellungen verwendet, sie machen einen fantastischen Job den Aufwand reduzieren Sie könnten von C ++ erwarten. (Vor allem, wenn Sie ihm helfen, durch vernünftige Nutzung des inline Schlüsselwort)

Ich habe sogar gebrauchte Vorlagen für einige ihrer Kompilierung-Vorteile, die eine gute Code-Wiederverwendung fördern: z eine einzige Quellcodedatei schreibt 8-Bit-zu handhaben, 16-Bit und 32-Bit-CRCs; und Kompilierung-Polymorphismus , damit Sie das übliche Verhalten einer Klasse zu spezifizieren, und dann wiederverwendet werden, dass aber einige seiner Funktionen außer Kraft setzen. Wieder eine extrem niedrige Overhead mit entsprechenden Optimierungseinstellungen hatten die TI-Compiler.

Ich habe für einen C ++ Compiler für den Microchip PICs gesucht; die einzige Firma, die ich gefunden habe, die man produziert, ist IAR. ($$$ war ein Hindernis, aber ich hoffe, eine Kopie irgendwann zu kaufen) Der Microchip C18 / C30-Compiler sind ziemlich gut, aber sie sind C, C ++ nicht.

3) Eine spezifische Einschränkung über Compiler-Optimierung: es kann / wird sehr schwierig machen Debugging; ist es oft unmöglich, einstufiges durch optimierte C / C ++ Code und Ihre Uhr Fenster Variablen zeigen können, die keine Korrelation mit dem, was denken Sie, sie mit nicht optimierten Code enthalten sollte. (Ein guter Debugger würden Sie warnen, dass eine bestimmte Variable hat eher aus der Existenz oder in ein Register optimiert als einen Speicherplatz. Viele Debugger nicht.> :(

Auch ein guter Compiler würde Sie auf der Funktionsebene durch #pragmas Pick / wählen Optimierung. Die, die ich verwendet habe, nur lassen Sie die Optimierung auf Dateiebene angeben.

4) Interfacing C-Code zu assembly: Dies ist in der Regel schwierig. Der einfachste Weg ist, um eine Stub-Funktion vornehmen, die Signatur, die Sie zum Beispiel mögen, hat uint16_t foo(uint16_t a, uint32_t b) {return 0; }, wo uint16_t = unsigned short, wir in der Regel die Anzahl der Bits explizit machen. Dann kompilieren und bearbeiten Sie die Montage es produziert (nur sicherstellen, dass die beginnen / Ausfahrt Teile des Codes verlassen) und vorsichtig sein, keine Register verprügeln, ohne sie wieder herstellt, nachdem Sie fertig sind.

Inline-Montage in der Regel kann Probleme haben, wenn Sie etwas tun sehr einfach wie die Aktivierung / Deaktivierung von Interrupts.

Der Ansatz, den ich am besten gefällt, ist Compiler intrinsics / "erweitert ASM" Syntax. Microchip C-Compiler auf dem GNU C Compiler basiert und es hat „ erweitert ASM “, die Sie Bits von Inline-Assembler-Code können aber Sie es viele Hinweise geben kann, es zu sagen, welche Register / Variablen, die Sie verweisen, und es wird alles das Speichern / Wiederherstellen von Registern Griff um sicherzustellen, dass die Assembly Code zu machen‚spielt schön‘with C. TI Compiler für die TMS320 DSP ist diese nicht unterstützen; es hat eine begrenzte Anzahl an intrinsics haben, die eine gewisse Verwendung haben.

Ich habe Baugruppe verwendet, um einigen Regelkreis Code zu optimieren, die häufig ausgeführt wurden, oder Sünde zu berechnen (), cos () und arctan (). Aber ansonsten würde ich bleiben weg von der Montage und halte mit einer Hochsprache.

Andere Tipps

Die meisten Mikrocontroller-Hersteller bieten irgendeine Art von Cross-Compiler, wo Sie den Code auf dem PC zusammenstellen können und es dann an den Mikrocontroller übertragen über.

Warum C?
Ein Vorteil von C ist, dass der Code leichter zu portieren zu anderen Mikrocontrollern in der Zukunft sein wird. Die Geschichte der Informatik ist, dass Code typischerweise überdauert Hardware-Implementierungen gezeigt.
Ein zweiter Vorteil ist, Steuerstrukturen (wenn zur, während), der Code lesbaren und wartbar zu machen.

Warum Assembly Language?
Sie können Handwerk Optimierungen Hand.

Fazit
Wie es oft der Fall mit dieser Art von Frage, sind die Kompromisse sehr abhängig von der spezifischen Anwendung.
Seien Sie sich bewusst, dass es oft möglich ist, die beiden zu mischen, indem Montage Anrufe innerhalb des C-Code, so dass Sie ein Gleichgewicht finden, die für Ihr Projekt richtig ist.

Spezifisch für die PIC-Hardware
Es scheint , dass Sie nicht die Möglichkeit, GCC mit den meisten PIC-Hardware haben. Auf der anderen Seite, wie ein Kommentator erwähnt, ist die Microchip C30 Compiler für die 16-Bit PIC24 und dsPIC33 ist gcc.
PIC ist auch noch nicht unterstützt von SDCC .
Neue Info:. Nach einem Kommentar, SDCC hat tragfähige Unterstützung für PIC
Es gibt einige andere Open-Source- Optionen , aber ich habe keine Erfahrung mit ihnen.

Die beste Option ist wahrscheinlich in C zu kodieren, und dann für die wenigen Fälle, in denen Sie brauchen könnten zu optimieren und können einen besseren Job als der Compiler tun, sollten Sie die Baugruppe in Ihre c-Dateien kodieren.

Montage Codierung ist eine Sache der Vergangenheit für PCs, ist aber sehr relevant in eingebettet ist.

Schreibanordnung eingebettet ist anders als auf PC Montag zu schreiben. PC-Compiler sind „besser als Menschen“ zu optimierten Anweisungen zu erzeugen. Eingebettete Systeme haben oft seltsame Architekturen und deren optimierende Compiler sind nicht annähernd so ausgereift wie ein PC optimierenden Compiler.

Eine Frage, die ich für einen Mikrocontroller mit dem Schreiben von Montage lief in der Notwendigkeit, sehr vorsichtig, wie Ihr Code wurde angelegt. eine Sprungtabelle Querspeichergrenzen zu haben, und was Ihr Code wirklich seltsam Orte zu springen ist eher störend. Codierung in C, der Compiler umfasst, dass die Basis für Sie.

Ich würde auf jeden Fall mit C geht Es ist schneller und es schafft zuverlässige Software. Versammlung hat sehr wenig und in knappen Gelegenheiten zu bieten. Haben Sie daran, dass in C:

Sie würden die Lage sein leicht Port-Code von bestehenden Plattformen, auch von PCs.
Sie können ohne Kompromisse bei der Ausführungsgeschwindigkeit oder die Codegröße in einer Hochsprache entwickeln. zur Verfügung gestellt, dass ein Qualitäts Compiler ist (es gibt viele Möglichkeiten für PIC18), werden diese höchstwahrscheinlich besser als handgearbeitete Montage mit C wäre sein.
Es ist viel einfacher zu debuggen, zu testen und den Code zu halten. C erzeugt zuverlässigen Code.

Eine andere Sache, die spezifisch mit PIC18 zu tun hat. Sie werden nicht mit der nicht-intuitiven PIC Architektur und Dingen wie Speicherbanken zu tun haben.

Ich habe gute Erfahrungen gemacht mit IAR C-Compiler für 8051 sind in der Vergangenheit.

Meine bisherige Vorgehensweise hat dies immer: -

Schreiben Sie es in C mit einem guten optimierenden Compiler, und nur dann, wenn es ein Problem mit der Größe oder der Geschwindigkeit ist, sollten bestimmte Teile in Assembler neu zu schreiben.

Da jedoch diesen Ansatz ich nie haben erforderlich eine einzige Zeile Assembler schreiben ...

Gehen Sie

für c!

Ich habe für einen großen CE-Hersteller gearbeitet. Das letzte Mal, als ich sah, war Montag dort für RC5 und RC6-Decodierung und TV-Tuning-Algorithmen in einigen kleinen Interrupt-Routinen Dienste um 1996 war. Danach immer verwendet c und C ++ (nur verwendete Klassen, keine stl, Ausnahmen oder RTTI). Ich habe gute Erfahrungen mit den alten KEIL-Compiler für 8051 und mit green Compiler (MIPS) und dem VxWorks-Toolset (PowerPC-basierten).

Wie Roddy sagt, erster Schreib in C, und später in der Montage optimieren (falls erforderlich).

Die Montage kann in vielen Fällen schneller; wenn Sie auf einem Desktop sind, neigen die Compiler auf den Punkt optimiert werden, dass Handmontage selten eine Notwendigkeit ist, sondern in der uC Welt, ist es oft ist. Auch, wenn Sie benötigen wie die Interrupt-Behandlungsroutinen und Dinge zu schreiben, kann man oft nicht tut es in C.

Wie für die Kompilierung, Google um für einen C-Compiler für Ihr Ziel.

Auf jeden Fall C, außer wenn

Programmspeicher ist äußerst begrenzt. Sagen Sie nach sorgfältigem Hand-Optimierung Ihres Assembler Code, den Sie verwalten Ihr Programm in diesem 1024 Bytes von Flash, mit 0 Byte links zu passen. In diesem Fall werden keine C-Compiler gut sein.
Sie absolute Zeitsteuerung haben. Wenn jede Menge Interrupt-Latenzzeit zu lang ist, müssen Sie auf Assembler verlassen.

Das Problem besteht heutzutage darin, dass Embedded alles sein kann, von einem ATTiny mit 6 Pins und ein paar Bytes RAM bis hin zu einem Multi-Core-SBC mit einem eingebetteten Betriebssystem, das die Desktop-Computer mancher Leute in den Schatten stellen würde.

Daher muss bei der Wahl der Sprache/Entwicklungsumgebung berücksichtigt werden, wie effizient Sie sein müssen und wie komplex das System ist.

Zunächst einmal: C funktioniert überall und lässt sich ziemlich gut skalieren. Je höher Sie gehen, desto mehr werden Sie am Ende externe Bibliotheken usw. aufrufen.um mit der Komplexität umzugehen.

Für sehr kleine Mikros (Flash/RAM in Bytes) verwenden Sie am besten ASM. Wenn Sie den KB-Bereich erreichen, können Sie C oder eine der anderen herkömmlichen Sprachen verwenden, da Sie nicht jedes Byte zählen müssen.Sobald Sie über Megabytes verfügen, mit denen Sie spielen können, haben Sie sowohl die Möglichkeit als auch immer wahrscheinlicher die Anforderung, ein RTOS zu verwenden, um alles zu erledigen und die Entwicklungszeit zu verkürzen.Wenn Sie über Hardware verfügen, auf der Sie ein vollwertiges Betriebssystem ausführen könnten, können Sie sich wahrscheinlich von der Hardware abstrahieren und einfach alles in eine gepolsterte Zelle wie Java oder so schreiben, ohne sich allzu viele Gedanken darüber machen zu müssen, wie furchtbar verschwenderisch das alles ist und wie es Ihnen geht kein richtiger Programmierer mehr...;)

Die Ausnahme von oben ist, wenn Sie die gesamte Leistung benötigen, die Sie aus der Hardware herausholen können. Zu diesem Zeitpunkt müssen Sie möglicherweise ein oder zwei Stufen herunterstufen, um die Effizienz zu gewährleisten.

Das ist die untere Zeile, wenn Sie C verwenden Sie später optimieren Hand kann, ich würde nicht etwas anderes als C oder Assembler (ohne C ++, etc.) verwenden.

Der Schlüssel ist der Mikrocontroller Befehlssatz, wenn Sie einen PIC oder sogar eine 8051 verwenden ich Assembler nur verwenden würde. Wenn es ein Compiler freundlich isa wie Arm oder avr oder msp430 dann C verwenden, um einige Tipparbeit zu sparen, aber Sie werden wahrscheinlich einige Routinen in Assembler aus verschiedenen Gründen haben. Ebenso haben Sie wahrscheinlich eine C-Bibliothek vermeiden wollen, auch newlib kann einfach zu sperrig sein, leiht Code oder Ideen von ihnen aber derzeit Link nur eine in. Oh, zurück zu der Frage, schauen, was C-Compiler sind für das Ziel vorhanden, wieder Arm und avr Sie Probleme gewohnt haben. Wahrscheinlich msp ist auch in Ordnung. Nur weil Keil oder Iar erhalten Sie einen Compiler SELL bedeuten muß nicht, sollten Sie es kaufen oder verwenden, die Ausgabe des Entgelts für sowie freie Compiler können schrecklich sein. Sie müssen auch in der asm sowieso und untersuchen Sie die Ausgabe versiert werden (Sie müssen wahrscheinlich einen Disassembler schreiben, dies zu tun).

Unterm Strich (eine andere untere Zeile), gibt es keine globale Antwort ist (gut vermeiden anyhthing höher als C eine globale Antwort ist) es kommt immer darauf an, was die Plattform ist, was Ihre Ressourcen sind, was Ihre Aufgabe, was die Leistung Anforderungen sind, was die Portabilität Anforderungen sind (wenn es wirklich auf einem Mikrocontroller viel davon eingebettet ist, ist per Definition nicht tragbar), welche Compiler, Debugger, jtag, etc. sind availble, sogar so weit, was Host-Betriebssystem sind ein großer Faktor sein, das Sie entwickeln auf können .

Es gibt eine andere Zeit, als in der Montage Schreiben notwendig sein kann: wenn Sie einig Low-Level-RAM-Test oder ähnliches tun müssen, die über die absolute Kontrolle erfordert, wo Daten gespeichert werden

Zum Beispiel Software, die auf SIL -2 (Safety Integrity Level) und oben kann es erforderlich, um kontinuierliche Überprüfungen auf RAM, eine mögliche Beschädigung von Daten zu erkennen. Der Bereich des RAM sind die Überprüfung Sie lässt sich nicht ändern, während es aktiviert ist wird, und das Schreiben so den Test in Assembler ermöglicht es Ihnen, um sicherzustellen, dass dies wahr ist, zum Beispiel durch alle lokalen Variablen in bestimmten Register zu speichern oder in einem anderen Bereich des RAM . Dies wäre schwierig, wenn nicht unmöglich, in C.

Startup-Code, der die RAM-Nullen und initialisiert nicht Null statische Variablen auch in Assembler für denselben geschrieben werden können geschrieben werden, obwohl diese Art von Code normalerweise vorgesehen ist.

Wenn Sie Code schreiben, die auf gerätespezifische Peripheriegeräten in hohem Maße abhängig ist, und die Werkzeugkette Sie verwenden liefern nicht die notwendigen Spezifika sie effizient zu nutzen (wie die beschissene Freescale DSP563CC Compiler), dann Assembly verwenden .

Außerdem denke ich, dass die ungeschriebenen Regeln der Verwendung Montage im Vergleich zu einer High-Level-Sprache sind mehr oder weniger die gleiche wie die für Desktop-Software-Entwicklung: Halten Sie den Code sauber und leicht zu verwaltende und optimieren Hot Code mit Maschinensprache.

-Code in Assemblersprache ist sehr schnell mit geringen Platzbedarf, aber Code in Assemblersprache geschrieben ist nicht wiederverwendbar Code. Diese reusibility Funktion zur Code ist wichtigste Merkmal für Software-Design. Zum Beispiel, wenn Sie Assembler Projektcode für x86-Prozessor haben, kann es nur für x86-Prozessor, nicht für ARM-Prozessor sein. Aber wenn Sie Projekt C / C ++ Code für x86-Prozessor haben, können Sie diesen Code für ARM-Prozessor verwenden. Also, es ist besser zu vermeiden Assembler für die Software-Entwicklung.

Es ist schade, niemand Forth oder Scheme bisher erwähnt hat. Beide können für kleine Umgebungen geeignet und kann beeindruckende Produktivitätsgewinne geben.

Plain C oder Pascal, Modula2. Aber aufgrund der Compiler Verfügbarkeit das bedeutet C.

Die Extrakosten von C ++ und similars sind nur aus der Mode Gründen interessant, da die dynamische Zuordnung und Programmgröße in der Regel sehr begrenzt ist.

Auch eine kompliziertere Laufzeit kann ein Schmerz, wenn Ihre Anwendungen eng wird.

Assembler kann nützlich sein, aber nur, wenn Sie wirklich gigantische Mengen zu verkaufen, und eine kleinere Firmware bedeutet einen kleineren, billigerer Chip (weniger Blitz) und die Größe des Programms ist überschaubar (sprich: es gibt eine gewisse Chance, dass Sie es bekommen bugfree in der Zeit)

Lizenziert unter: CC-BY-SA mit Zuschreibung

Nicht verbunden mit StackOverflow