Mikrocontroller-Programmierung vs. objektorientierte Programmierung

Ich habe einige grundlegende objektorientierte Programmierungen mit C ++ durchgeführt (Erstellen eines B-Baums, Hashing-Algorithmen, doppelt verknüpfte Listen) und ich habe ein kleines Projekt in C durchgeführt (wie das Erstellen eines wissenschaftlichen Taschenrechners usw.)

Wie unterschiedlich ist die Hardware-Programmierung (speziell für Mikrocontroller) von der Software- / objektorientierten Programmierung in Bezug auf die Denkweise und das "Denken", die der Programmierer haben muss?

Wird einer normalerweise als härter angesehen als der andere, meine meisten Leute?

Würde ich mit meinem Hintergrund (wie oben beschrieben) viel Vorbereitung brauchen, um in die Hardware-Programmierung einzusteigen, oder kann ich ohne zu viel Vorbereitung direkt eintauchen?

Beim Umgang mit den meisten Mikrocontrollern müssen Sie das objektorientierte Paradigma vollständig aufgeben.

Mikrocontroller sind im Allgemeinen register- und RAM-begrenzt, mit langsamen Taktraten und ohne Pipelining / Parallelcode-Pfade. Sie können beispielsweise Java auf einem PIC vergessen.

Sie müssen sich in eine Assembler-Denkweise einarbeiten und prozedural schreiben.

Sie müssen Ihren Code relativ flach halten und Rekursionen vermeiden, da RAM-Einschränkungen häufig zu Stapelproblemen führen können.

Sie müssen lernen, wie Sie Interrupt-Serviceroutinen schreiben, die effizient sind (normalerweise in Assemblersprache).

Möglicherweise müssen Sie Teile des Codes manuell in Assemblersprache umgestalten, um Funktionen zu implementieren, die der Compiler nicht (oder nur unzureichend) unterstützt.

Sie müssen mathematischen Code schreiben, der die Wortgröße und den Mangel an FPU-Funktionen der meisten Mikrocontroller berücksichtigt (dh 32-Bit-Multiplikation auf einem 8-Bit-Mikro = böse).

Es ist eine andere Welt. Für mich kann ein Informatik- oder professioneller Programmierhintergrund ebenso hinderlich sein wie überhaupt kein Wissen im Umgang mit Mikrocontrollern.

Sie müssen über verschiedene Dinge nachdenken:

• Sie werden C als Sprache verwenden
• Mit Funktionszeigern können Sie immer noch ein Gefühl der Objektorientierung erzeugen, sodass Sie Funktionen usw. überschreiben können. Ich habe diese Methode in früheren und aktuellen Projekten verwendet und sie funktioniert sehr gut. OO ist also teilweise vorhanden, aber nicht im C ++ - Sinne.

Es gibt andere Einschränkungen, die beim Spielen auftreten werden, wie z. B. begrenzte Geschwindigkeit und Speicher. Als allgemeine Richtlinie vermeide ich:

• Mit Heap mache ich das, wenn es eine Möglichkeit gibt, das Problem ohne Malloc zu lösen. Zum Beispiel ordne ich Puffer vorab zu und verwende sie einfach.
• Ich reduziere absichtlich die Stapelgröße in den Compilereinstellungen, um Probleme mit der Stapelgröße frühzeitig zu lösen. Optimiere dies sorgfältig.
• Ich gehe davon aus, dass jede einzelne Codezeile durch ein Ereignis unterbrochen wird, daher vermeide ich nicht wiedereintretenden Code
• Ich gehe davon aus, dass sogar Interrupts verschachtelt sind, also schreibe ich diesen Code entsprechend
• Ich vermeide die Verwendung von Betriebssystemen, es sei denn, dies ist erforderlich. 70% der eingebetteten Projekte benötigen kein Betriebssystem. Wenn ich ein Betriebssystem verwenden muss, verwende ich nur etwas mit verfügbarem Quellcode. (Freertos usw.)
• Wenn ich ein Betriebssystem verwende, abstrahiere ich fast immer Dinge, damit ich das Betriebssystem in wenigen Stunden ändern kann.
• Für Treiber usw. werde ich nur die vom Anbieter bereitgestellten Bibliotheken verwenden. Ich habe nie direkt an den Bits herumgespielt, es sei denn, ich habe keine andere Wahl. Dies macht den Code lesbar und verbessert das Debuggen.
• Ich schaue mir die Loops und andere Dinge an, besonders in ISR, um sicherzustellen, dass sie schnell genug sind.
• Ich halte immer ein paar GPIOs bereit, um Dinge, Kontextwechsel, ISR-Laufzeit usw. zu messen.

Liste geht weiter, ich bin wahrscheinlich unterdurchschnittlich in Bezug auf Softwareprogrammierung, ich bin sicher, dass es bessere Praktiken gibt.

Ich mache beides, also hier ist meine Ansicht.

Ich denke, die mit Abstand wichtigste Fähigkeit in Embedded ist Ihre Debugging-Fähigkeit. Die erforderliche Denkweise ist insofern sehr unterschiedlich, als so viel mehr schief gehen kann, und Sie müssen sehr offen dafür sein, all die verschiedenen Möglichkeiten zu berücksichtigen, mit denen das, was Sie versuchen, schief gehen kann.

Dies ist das größte Problem für neue Embedded-Entwickler. PC-Leute neigen dazu, es rauer zu haben, da sie es gewohnt sind, nur für sie zu arbeiten. Sie werden viel Zeit damit verschwenden, nach Werkzeugen zu suchen, um stattdessen Dinge für sie zu tun (Hinweis: Es gibt nicht viele). Es werden immer wieder viele Köpfe gegen Wände geschlagen, ohne zu wissen, was man sonst tun soll. Wenn Sie das Gefühl haben, stecken zu bleiben, treten Sie zurück und finden Sie heraus, ob Sie feststellen können, was alles schief gehen könnte. Gehen Sie systematisch die Liste der potenziellen Probleme ein, bis Sie es herausgefunden haben. Aus diesem Prozess folgt direkt, dass Sie den Umfang der Probleme einschränken sollten, indem Sie nicht zu viel auf einmal ändern.

Erfahrene Embedded-Leute halten das Debuggen für selbstverständlich ... die meisten Leute, die es nicht gut können, halten nicht lange durch (oder arbeiten in großen Unternehmen, die einfach akzeptieren, dass "Firmware ist schwer" als Antwort auf die Gründe für eine bestimmte Funktion ist Jahre zu spät)

Sie arbeiten an Code, der auf einem externen System für Ihr Entwicklungssystem ausgeführt wird und von Plattform zu Plattform unterschiedliche Einblicke in Ihr Ziel bietet. Wenn Sie unter Ihrer Kontrolle stehen, suchen Sie nach Entwicklungshilfen, um diese Sichtbarkeit Ihres Zielsystems zu verbessern. Verwenden Sie serielle Debug-Ports, Bit-Banging-Debug-Ausgabe, das berühmte blinkende Licht usw. Lernen Sie mindestens die Verwendung eines Oszilloskops und verwenden Sie Pin-E / A mit dem Bereich, um zu sehen, wann bestimmte Funktionen ein- / ausgehen, ISRs ausgelöst werden usw. Ich habe beobachtet, wie Menschen buchstäblich Jahre länger als nötig gekämpft haben, nur weil sie sich nie die Mühe gemacht haben, einen richtigen JTAG-Debugger-Link einzurichten / zu lernen.

Es ist viel wichtiger, genau zu wissen, über welche Ressourcen Sie im Vergleich zu einem PC verfügen. Lesen Sie die Datenblätter sorgfältig durch. Berücksichtigen Sie die Ressourcenkosten für alles, was Sie versuchen zu tun. Lernen Sie ressourcenorientierte Debugging-Tricks wie das Füllen des Stapelspeichers mit einem magischen Wert, um die Stapelverwendung zu verfolgen.

Während sowohl für PC als auch für eingebettete Software ein gewisses Maß an Debugging-Kenntnissen erforderlich ist, ist dies bei Embedded viel wichtiger.

Ich gehe davon aus, dass Ihre C ++ - Erfahrung PC-basiert ist.

Ein häufig gemachter Fehler von Programmierern, die vom PC zum Mikrocontroller wechseln, ist, dass sie nicht erkennen, wie begrenzt Ressourcen sein können. Auf einem PC wird Sie niemand aufhalten, wenn Sie eine Tabelle mit 100 000 Einträgen erstellen oder ein Programm schreiben, das mit 1 MB Maschinencode kompiliert wird.
Es gibt Mikrocontroller mit einer Fülle von Speicherressourcen, insbesondere im High-End-Bereich, aber es ist noch weit entfernt von dem, was Sie gewohnt sind. Bei einem Hobbyprojekt können Sie wahrscheinlich immer das Maximum erreichen, aber bei einem professionellen Projekt müssen Sie häufig mit dem kleineren Gerät arbeiten, weil es billiger ist .
Bei einem Projekt habe ich mit einem TI MSP430F1101 gearbeitet. 1 KB Programmspeicher, 128 Byte Konfigurations-Flash, 128 Byte RAM. Das Programm passte nicht in die 1K, daher musste ich eine 23-Byte-Funktion in den Konfigurations-Flash schreiben. Mit diesen kleinen Controllern berechnen Sie byteweise . Bei einer anderen Gelegenheit war der Programmspeicher 4 Bytes zu klein. Boss ließ mich den Controller nicht mit mehr Speicher verwenden, sondern musste stattdessen einen bereits optimierten Maschinencode (der bereits im Assembler geschrieben wurde) optimieren, um die zusätzlichen 4 Bytes aufzunehmen. Sie erhalten das Bild.

Abhängig von der Plattform, an der Sie arbeiten, müssen Sie mit E / A auf sehr niedriger Ebene umgehen . Einige Entwicklungsumgebungen verfügen über Funktionen zum Schreiben auf ein LCD, andere sind jedoch selbstständig und müssen das Datenblatt des LCD von Anfang bis Ende lesen , um zu wissen, wie es gesteuert wird.
Möglicherweise müssen Sie ein Relais steuern, das ist einfacher als ein LCD, aber Sie müssen zur Registerebene des Mikrocontrollers wechseln. Wieder ein Datenblatt oder eine Bedienungsanleitung. Sie müssen die Struktur des Mikrocontrollers kennenlernen, die Sie in einem Blockdiagramm wieder im Datenblatt finden. In den Tagen des Mikroprozessors sprachen wir über ein ProgrammiermodellDies war im Grunde eine Aufstellung der Register des Prozessors. Die heutigen Mikrocontroller sind so komplex, dass eine Beschreibung aller Register den größten Teil eines 100-seitigen Datenblattes ausmachen kann. IIRC nur die Beschreibung des Uhrmoduls für den MSP430 war 25 Seiten lang.

$\mu$

Mikrocontroller werden häufig in C programmiert . C ++ ist ziemlich ressourcenhungrig, das ist also normalerweise nicht der Fall. (Die meisten C ++ - Implementierungen für Mikrocontroller bieten eine begrenzte Teilmenge von C ++.) Wie ich bereits sagte, steht Ihnen je nach Plattform möglicherweise eine umfangreiche Funktionsbibliothek zur Verfügung, mit der Sie einige Entwicklungszeit sparen können. Es lohnt sich, sich etwas Zeit zu nehmen, um es zu studieren. Es kann Ihnen später viel Zeit sparen, wenn Sie wissen, was verfügbar ist.

"Hardware-Programmierung" kann viele Dinge bedeuten. Das Programmieren eines sehr kleinen Chips (denken Sie an 10F200, 512 Anweisungen, einige Bytes RAM) kann fast wie das Entwerfen einer elektronischen Schaltung sein. Auf der anderen Seite kann die Programmierung eines großen Cortex-Mikrocontrollers (1 MB FLASH, 64 kB RAM) der PC / GUI-Programmierung mit einem großen GUI-Toolkit sehr ähnlich sein. Meiner Meinung nach benötigt ein guter Embedded- / Echtzeit-Programmierer Kenntnisse sowohl von der Seite des Software-Engineerings als auch von der Seite des Schaltungsdesigns. Für die größeren uC ist C ++ eine gute Sprachwahl, für die sehr kleinen könnte C die einzige Wahl sein. Assemby-Wissen kann nützlich sein, aber ich würde nicht empfehlen, ernsthafte Projekte ausschließlich in der Montage durchzuführen.

Ich habe ernsthafte eingebettete Arbeit mit Menschen von beiden Seiten (SWI und EE) geleistet. Ich bevorzuge im Allgemeinen die SWI-Leute, vorausgesetzt, sie haben Erfahrung mit Multu-Threading-Programmierung.

Ihre Frage klingt so, als ob Sie in die eingebettete Programmierung eintauchen möchten. Tun Sie dies auf jeden Fall. Für die Low-Level-Aspekte (Anbindung der Peripheriegeräte in Ihrem Chip und der Hardware um ihn herum) müssen Sie einige neue Fähigkeiten erlernen, aber es ist nur eine Menge Arbeit ohne viele neue Konzepte. Für die höheren Ebenen Ihrer Projekte können Sie auf Ihr vorhandenes Wissen zurückgreifen.

Für jede von Ihnen aufgerufene Arduino-Bibliotheksmethode gibt es eine Fülle von C / C ++ - Code, der dies ermöglicht. Sie ist einfach gut verpackt, damit Sie sie als API verwenden können. Werfen Sie einen Blick auf den Arduino-Quellcode unter dem Verzeichnis hardware / arduino / * und Sie werden alle für Sie geschriebenen C / C ++ sehen, die direkt mit den Registern des AVR-Mikrocontrollers interagieren. Wenn Sie lernen möchten, wie man solche Dinge schreibt (direkt für die Hardware), gibt es viel zu besprechen. Wenn Ihr Ziel darin besteht, mithilfe der Bibliotheken etwas zum Laufen zu bringen, gibt es möglicherweise nicht viel zu besprechen, da der größte Teil der harten Arbeit für Sie erledigt wird und die Bibliotheken und die Entwicklungsumgebung sehr einfach zu verwenden sind.

Einige Faustregeln bei der Arbeit mit Geräten mit eingeschränkten Ressourcen, die entweder für die Arduino-Umgebung oder für andere gelten können:

Beachten Sie, wie viel Speicher Sie verwenden. Sowohl die Codegröße (die in den Flash-Speicher geht) als auch die statische RAM-Nutzung (Konstanten in Ihrem Code, die immer im RAM vorhanden sind). Ich würde argumentieren, dass die statische RAM-Nutzung zu Beginn etwas wichtiger ist, da sie leicht zu übersehen ist. Es ist nicht ungewöhnlich, dass Sie nur 1000 Bytes für Ihren Stack, Heap und Ihre Konstanten haben. Seien Sie weise, wie Sie es ausgeben, also vermeiden Sie Dinge wie lange Arrays von ganzen Zahlen (jeweils 4 Bytes), wenn Bytes oder vorzeichenlose Zeichen (jeweils 1 Byte) ausreichen. Eine andere Antwort hier behandelt einige andere wichtige Punkte sehr gut, daher werde ich hier aufhören. Ich wollte vor allem darauf hinweisen, dass es viel zu besprechen gibt , wenn Sie nicht die Arduino-Bibliothek verwenden und Ihre eigenen C-Bibliotheken schreiben .

In Bezug auf Mikrocontroller und OOP-Programmierung sind sie keine Gegensätze. Es stimmt, dass sich alle Herstellerbibliotheken in einfachem C befinden, aber alle Plattformen unterstützen auch C ++ OOP. Entwickler können darüber hinaus C ++ - Bibliotheken und Gerätefirmware auf hoher Ebene erstellen und erstellen. Das gute Beispiel sind offizielle und vom Benutzer erstellte Arduino-Bibliotheken - hauptsächlich C ++ - Klassen. Möglicherweise können nicht alle OOP-Vorteile in einer eingebetteten Umgebung vollständig genutzt werden, aber auch hier gelten bekannte C ++ - und C-Vorteile.

In Bezug auf die Denkweise und das Denken sind Mikrocontroller, wie in anderen Antworten erwähnt, sehr ressourcenbeschränkte Plattformen (insbesondere im RAM, weniger schnell) - Dinge wie dynamische Speicherzuweisung, C ++ - Ausnahmen sind normalerweise ausgeschlossen. Wenn die richtige Hardware ausgewählt wird, ist es einfach, diese Einschränkungen zu übernehmen und andere Techniken zu verwenden (die auch auf anderen Plattformen weit verbreitet sind).

Meiner Ansicht nach könnte die schwierigere Herausforderung eine weitere Dimension der eingebetteten Programmierung sein - das Timing. Dies liegt daran, dass eingebettete Software in der Regel viel mit Echtzeitereignissen, streng zeitgesteuerten Protokollen zur Steuerung der Peripheriehardware und allgemeinen Aufgaben selbst zu tun hat (dies sind auch einige Parallelen zu anderen "High-Level" -Plattformen wie Multithread-Anwendungen).

Seien Sie darauf vorbereitet, viele Datenblätter zu lesen, wenn Sie sich mit neuer Hardware befassen - ich denke, dies könnte mit dem Fragenteil "Denkweise" zusammenhängen :) Sicherlich wären einige EE- und Hardware-Kenntnisse erforderlich.

Außerdem möchte ich darauf hinweisen, dass die Entwicklung eingebetteter Software heutzutage keine Assemblersprache erfordert. Tatsächlich ist Java (übrigens standardmäßig OOP) bereits vorhanden und wird immer stärker (zumindest für einige Klassen eingebetteter Geräte, z. B. IoT-Geräte, könnte es eine sehr gute Zukunft haben).