Welchen Skillsatz sollte ein Low-Level-Programmierer besitzen?

Question

Ich bin ein embedded SW Engineer, mit weniger als 3 Jahren Erfahrung. Ich ziele darauf ab, die Säge kontinuierlich zu "schärfen". Ich habe mich gefragt, ob es etwas Spezifisches für Low-Level-Programmierung gab, mit dem C/C++ - Programmierer umgehen sollten.

Was mir in den Sinn kommt, ist die Vertrautheit mit der Architektur und dem Befehlssatz der Hardware. Zu wissen, wie man mit Bits herumhantiert, ist auch wichtig, Ressourcenmanagement und Leistung waren Teil meiner Arbeit, gibt es noch etwas anderes?

EDIT: Ich arbeite mit einem Inhouse-RTOS, nicht Embedded Linux.

Answer 1

Spezielle Konzepte wie,

1. Endianness (diese Verbindung ist zu einem alten, aber gut Linuxjournal Artikel)
2. Effective use of multithreading architectures (die eingebettete Seite im Allgemeinen gut ist)
3. Debugging embedded und multithreaded Systeme
4. Understand, Learn and Follow good programming techniques (der Link ist sehr alt und der Punkt sehr allgemein und subjektiv, aber darüber nachdenken)
5. Other things (diese IBM Seite auf Embedded Linux fasst die meisten anderen Punkte zusammen, die ich machen möchte)
6. Eine weitere Sache - never underestimate testing! oder, Testfälle planen !!

die Referenz Gäste Ich gebe als Konzepte,
bitte weiter für tiefere Kenntnisse followup.

Answer 2

Ich würde die Elektronik der tatsächlichen Chips studieren. Erfahren Sie, wie sie intern arbeiten (z. B. Architektur), Schnittstelle mit Peripheriegeräten, elektrische und Timing-Eigenschaften, etc.

Lesen Sie das Datenblatt von Anfang bis Ende ein paar Mal und graben Sie in alles, was Sie noch nicht gesehen/verwendet haben .

Übrigens, mit welchen Chips arbeiten Sie?

Answer 3

Mit großer Vertrautheit mit Zeigern, die Kontrollen diese Sprachen nicht viel tun (wie Pufferüberlauf und solche Sachen), digitale Elektronik. Internes Betriebssystem kann ebenfalls hilfreich sein.

Erfahren Sie, wie das Zeug intern dargestellt wird, speziell vorgefertigte Datenstrukturen (vorausgesetzt, Sie werden kein eigenes bauen).

Üben Sie vor allem viel. Doing it bringt viel mehr zu Ihnen als nur darüber zu lesen;)

Answer 4

Wenn Sie noch nicht ich denke, jeder Software Engineer sollte lesen Sie den Pragmatischen Programmierer und Code Complete. Ich weiß, dass diese nicht spezifisch für Low-Level-Programmierung sind, aber in ihnen einen großen Wissensschatz haben, der für alle Teildisziplinen gilt.

Answer 5

ähnlich wie Brian said, lernen, wie man Unit-Tests automatisiert bauen und erstellen.

Diese Fähigkeiten sind gut für alle Ebenen der Software-Ingenieure, um zu beherrschen. Sie werden dazu beitragen, die Qualität Ihres Codes zu verbessern und gleichzeitig die Code-Basis zu refaktorieren und zu verbessern.

Answer 6

• Bit-Operationen
• Prozessorarchitekturen (Caches, etc.)
• WCET Analyse
• Scheduling

Edit: Was ich vergessen zu erwähnen ist modellbasierte Entwicklung. Heute werden die Kontrollalgorithmen oft als eine Art Automat implementiert, aus dem anschließend C-Code generiert wird. Handelsübliche Werkzeuge sind zum Beispiel MATLAB/Simulink, ASCET oder SCADE.

Answer 7

Holen Sie sich eine Kopie des MISRA-C Buches. Es wurde ursprünglich von Mitgliedern der Automobilindustrie geschrieben und versucht, in C geschriebene Software robuster zu machen, indem eine Anzahl (eine ziemlich große Anzahl!) Von Regeln und Richtlinien angewendet wird.

Dann kaufen PC-Lint (oder ein anderes statisches Analyse-Tool), um Ihren Code für MISRA und andere Regeln zu überprüfen.

Diese sind besonders relevant für Low-Level und Embedded C, da sie sich mit den Ursachen für viele Bugs in einer solchen Software beschäftigen, wie z. B. Pointer, Speicherlecks, Integerpromotion (es gibt ein ganzes Kapitel) dazu im MISRA-Buch), Endianness und undefiniertes Verhalten.

Answer 8

Ich sehe eine Menge von High-Level-Betriebssystem Antworten hier, aber Sie sagte speziell Low-Level.

Einige zerstreuten Gedanken:

• Design for Test. Während Sie ein Problem bearbeiten, ändern Sie nur eine Sache pro Test.
• Sie müssen Busse und Schnittstellen, spi, i2c, USB, Ethernet, etc. zu verstehen. Nummer eins Schnittstelle, heute, gestern und morgen, die UART, serielle.
• Die Schritte zur Programmierung eines Flash.
• Tricks zur Vermeidung von Brickability.
• Bootloader im Allgemeinen.
• Bit-Banging oben genannten Schnittstellen auf verschiedenen Familien von Teilen (verschiedene Chip Anbieter haben unterschiedliche Ideen über IO-Pins, Klimmzüge, Richtung Kontrollen, etc.).
• Board und Chip bringen, wollen Sie sicherlich nie booten viele Zehntausende von Zeilen Code-Programm auf der ersten Power-up (glaube, führte, führte aus).
• Wie ein Produkt zu debuggen, ohne zu viel Testausrüstung (logische Analysatoren und Bereiche), zur gleichen Zeit müssen Sie lernen, einen Bereich für das Debuggen zu verwenden, Sie sind weit wertvoller, wenn Sie nicht haben müssen ein Techniker oder Ingenieur im Labor mit Ihnen.
• Wie würden Sie das Gerät im Feld neu programmieren? Was würde Sie tun, um menschliche Fehler zu minimieren, wenn es dem Benutzer erlaubt, Feld das Gerät zu aktualisieren? Denken Sie auch an Feldherabstufungen.
• Was würden Sie tun, um Hacking zu verhindern (Binärdateien, etc).
• Effiziente Nutzung des Flash/ROM (nicht eine Bank oder Abschnitt abtragen, die Abnutzung herum verteilen, oder sehen, ob der Blitz es für Sie tut).
• Wie und wann einen Watchdog-Timer verwenden.
• State Machines, sehr nützlich mit Bytestreams (seriell und Ethernet), entwerfen Paketstrukturen, die gut streamen und auf eine Zustandsmaschine zugeschnitten sind und einen Header und eine Prüfsumme oder andere Struktur haben, die sicherstellt, dass Sie keine Teilpakete oder interpretieren Zufallsdaten als ein gutes Paket.

Answer 9

Gute Frage. Einige, die nicht erwähnt wurden ...

Lernen Sie Ihre verschiedenen Möglichkeiten zum Erreichen von Low-Level-Multitasking. Von einfachen Round-Robin-Schedulern (nicht-präventiv) mit Timing-Ticks von einem Hardware-Timer bis hin zu einem preemptiven RTOS. Erfahren Sie, warum Sie möglicherweise ein RTOS benötigen und warum nicht. Wenn Sie ein RTOS verwenden, lernen Sie, dass Anfänger mit einem PC-Hintergrund wahrscheinlich dazu neigen, zu viele Aufgaben zu erstellen.

Der Einblick in die Interna zum Debugging kann eine Herausforderung sein. In der Regel gibt es keinen Bildschirm, so dass Sie keine "printf" -Rufe eingeben können, wo immer Sie möchten. Ein Emulator oder eine JTAG-Schnittstelle ist ideal - Sie können Haltepunkte setzen und durch Ihr Programm gehen (solange das Anhalten des Mikros die Hardware nicht verrückt macht, wie etwa einen Roboterarm mit voller Geschwindigkeit herumzuschleppen!). Wenn Emulator/JTAG nicht verfügbar ist, lernen Sie, wie Sie einen Ersatz-Serial-Port (oder vielleicht sogar einen Bit-Bash-Pin für einen seriellen Port) für einen Debug-Kanal mit einigen einfachen Speicher-Peek/Poke-Befehlen verwenden.