Wie wird man Embedded-Software-Entwickler?

Bisher waren alle Antworten gut, aber ich gebe meinen Senf dazu.

Hier ist eine Wiederholung einiger Tipps mit einem Twist und einigen Extras:

• Lernen Sie C: Die grundlegende Sprache der Hardware, die immer noch portabel ist (zu einem gewissen Grad). Lernen Sie es nicht nur, sondern werden Sie ein Experte für all seine Funktionen wie flüchtig und warum es wichtig ist, Gerätetreiber zu schreiben.
• Beginnen Sie mit einem guten Entwicklungskit wie Arduino, aber wie bereits erwähnt, lernen Sie andere Architekturen kennen, sobald Sie ein gutes Gefühl dafür haben. Glücklicherweise gibt es einige Arduino-kompatible Boards, die mit anderen Prozessoren gebaut wurden. Auf diese Weise können Sie dasselbe Design auf einem anderen uC umschreiben, ohne Ihr gesamtes Design durcheinander zu bringen, während Sie ein Gefühl für etwas Neues bekommen.
• In der Lernphase können Sie das Rad bei Gerätetreibern oder anderen Codeteilen neu erfinden. Stecken Sie nicht einfach den Treibercode von jemand anderem hinein. Es lohnt sich, beim Lernen das Rad neu zu erfinden.
• Fordern Sie sich heraus, Ihren Code in Bezug auf Geschwindigkeit und Speichernutzung effizienter neu zu schreiben.
• Vertraut werden mit verschiedenen Arten von Softwarearchitekturen für eingebettete Systeme. Beginnen Sie mit der grundlegenden Interrupt-gesteuerten / Hintergrundschleifenverarbeitung, gehen Sie dann zu Hintergrund-Schedulern und dann zu Echtzeit-Betriebssystemen über.
• Holen Sie sich eine gute Quellcodeverwaltung! Ich selbst bevorzuge Mercurial .
• Melden Sie sich sogar bei einigen kostenlosen Quellcodeverwaltungs-Hosting-Sites wie Sourceforge.net oder Bitbucket.org an, um Ihr Projekt zu hosten, selbst wenn Sie der Einzige sind, der daran arbeitet. Sie sichern Ihren Code, sodass Sie sich keine Sorgen machen müssen, dass ein gelegentlicher Festplattencrash alles zerstört! Die Verwendung eines verteilten VCS ist praktisch, da Sie Änderungen auf Ihrer Festplatte einchecken und dann auf die Host-Site hochladen können, wenn Sie fertig sind.
• Lernen Sie Ihre Werkzeuge für jeden Chip, an dem Sie arbeiten, gut kennen! Es ist wichtig zu wissen, wie der Compiler eine Assembly erstellt. Sie müssen ein Gefühl dafür bekommen, wie effizient der Code ist, da Sie möglicherweise in Assembly umschreiben müssen. Es ist auch wichtig zu wissen, wie man die Linker-Datei verwendet und die Ausgabe der Memory Map interpretiert! Wie sonst wollen Sie wissen, ob diese Routine, die Sie gerade geschrieben haben, dafür verantwortlich ist, dass zu viel ROM/Flash in Anspruch genommen wird!
• Lernen Sie neue Techniken und experimentieren Sie damit in Ihren Designs!
• Gehen Sie beim Debuggen von nichts aus. Überprüfen Sie es!
• Erfahren Sie, wie Sie defensiv programmieren, um Fehler abzufangen und Annahmen zu überprüfen (z. B. mit Assert)
• Bauen Sie Debugging-Informationen in Ihren Code ein, wo Sie z. B. den Speicherverbrauch ausgeben oder Code mit Timern profilieren oder Ersatzpins auf dem uC verwenden können, um die Interrupt-Latenz auf einem O-Scope umzuschalten und zu messen.

Hier sind einige Bücher:

• The Pragmatic Programmer von Andrew Hunt und David Thomas – mehr oder weniger Pflichtlektüre für jede praktische Softwareentwicklung
• Praktisches Arduino
• Programmierung eingebetteter Systeme von Michael Barr
• Bausteine ​​für eingebettete Systeme von Jean Labrosse
• MicroC OS II Real Time Kernel von Jean Labrosse, großartige Einführung in RTOS im Allgemeinen zusammen mit seinem Betriebssystem.
• Embedded Software Primer von David Simon - gute Einführung in Embedded Software

Hier einige Webseiten:

• Eingebettete Gurus
• Ganssle Group Jack Ganssle hat einige wunderbare historische Geschichten zu erzählen. Lesen Sie die Artikel. Bei einigen Dingen wird er jedoch ein wenig predigt.
• Embedded.com Gute Informationen zu den neuesten Techniken und Tipps von Ganssle, Barr und anderen Branchenexperten.

• Denken Sie daran: „Es gibt keine Wunderwaffe“ , tappen Sie nicht in die Falle zu glauben, dass es ein Werkzeug, eine Methodik, eine Sprache oder ein System gibt, das alle Probleme lösen kann
• Werden Sie C-Experte
  • Lernen Sie, ohne malloc() und POSIX auszukommen
• Bleiben Sie nicht an einer Architektur hängen, es ist leicht, aus Versehen ein PIC-, AVR- oder ARM-Fan zu werden
• Erstellen Sie Dinge, debuggen Sie sie, bringen Sie sie zum Laufen. Übung macht den Meister
• Lernen Sie mindestens ein Versionsverwaltungssystem (SVN/git/etc) kennen und verwenden Sie es
• Seien Sie immer bereit, Ihre Annahmen zu testen. Der Fehler liegt normalerweise in dem, von dem Sie annehmen, dass es funktioniert
• Verlassen Sie sich nicht zu sehr auf Debugger, sie sind auf jedem System anders und von unterschiedlicher Zuverlässigkeit
• Denken Sie sparsam. Denken Sie bei der Problemlösung an Code-Footprint, RAM-Footprint und Hardwarekosten

Für Bücher würde ich empfehlen, in der Geschichte zu graben. Die meisten der heutigen eingebetteten Softwaretechniken stammen von der Schneide vergangener Zeiten.

Wie alles, üben Sie täglich.

Die anderen Antworten sind großartig, aber der größte Unterschied zwischen einem Bastler und einem Profi sollte die Einstellung zur Qualität sein. Also lassen Sie Ihr Projekt den ganzen Weg gehen, hören Sie nicht auf, wenn Sie mit einem Projekt zu 80% fertig sind. Gehen Sie alles durch, beweisen Sie, dass es funktioniert, und dokumentieren Sie es korrekt.

Stellen Sie sicher, dass Ihr Code lesbar und wartbar ist.

Und vergiss nicht, auch etwas Spaß zu haben :)

Abgesehen von dem Offensichtlichen, wie dem Erlernen von C und dem Start mit einem Entwicklerboard, sollten Sie lernen, Mikrocontroller-Datenblätter zu lesen .
Hersteller fügen Mikrocontrollern immer mehr Funktionen hinzu, die dadurch immer komplexer werden. Das Datenblatt enthält nicht nur elektrische Eigenschaften (was für den Elektroniker interessanter ist als für den Softwareentwickler), sondern auch eine detaillierte Beschreibung von Registern, Speicherabbildern usw.
Beim ersten Lesen eines Datenblatts mag es abschreckend wirken, aber nicht verständlich sein kann in der Debugging-Phase stärkere Kopfschmerzen verursachen.

'Embedded' ist ein etwas belasteter Begriff..

In gewisser Hinsicht könnte jedes System, das für die Ausführung einer einzelnen Anwendung bestimmt ist, als eingebettetes System bezeichnet werden, solange es Hardware gibt, die gesteuert werden muss. Sie können einen 400-MHz-PPC604 mit 2 GB RAM, auf dem eine Java-Anwendung auf Linux ausgeführt wird, wohl als eingebettetes System bezeichnen, wenn er zufällig einen Prozess über lokale E / A-Module steuert. Andererseits wäre ein Arduino, der nur eine Art minimale Netzwerkanwendung ausführt, kein großes eingebettetes System. Aber wahrscheinlich denken die meisten Leute bei „eingebettet“ an Flash-basierte Controller mit nur ein paar hundert Byte RAM, ohne nennenswertes Betriebssystem und einer Fülle von On-Chip-Peripheriegeräten.

Abgesehen davon sind die wahrscheinlich zwei größten Hürden, denen sich nicht-eingebettete Programmierer gegenübersehen, wenn sie eingebettete Systeme lernen, E/A-Register und Interrupts.

Interrupts sind möglicherweise das einfachere der beiden Konzepte für nicht eingebettete Programmierer, da die Hauptprobleme bei diesen, Nebenläufigkeit und ereignisgesteuerte Programmierung, häufig in Mainstream-Anwendungen auftreten. Was Interrupts zu einem Schmerz macht, ist die Erkenntnis, wie extrem empfindlich ein System auf die Qualität seiner Interrupt-Behandlung reagiert und wie kompliziert es ist, mit Hardware umzugehen, um den Interrupt-Zustand zu löschen und für den nächsten vorzubereiten. Bei einer GUI beendet ein Deadlock nur die Anwendung. Bei einem Interrupt-Handler führt ein Deadlock dazu, dass Ihr gesamtes System gesperrt wird.

E/A-Geräte scheinen der Bereich zu sein, der die meisten Schwierigkeiten verursacht. Für den Uneingeweihten kann es ziemlich überraschend sein zu entdecken, dass das Lesen dieses Registers hier eine Auswirkung auf das Register dort hat . Schreiben von Einsen zum Löschen von Bits. Statusbits, die sich selbst löschen, wenn Sie ein Datenregister lesen usw. Es gibt so viele Möglichkeiten mit E/A-Hardware, dass es keine allgemeine Regel für den Umgang damit gibt, außer zu lernen, wie man Gerätedatenblätter findet und interpretiert. Das Schreiben eines Gerätetreibers für eine serielle Schnittstelle wird Ihnen viel über die Low-Level-E/A-Programmierung beibringen.

Es gibt wirklich keinen Ersatz dafür, diese Dinge zu lernen, als die Ärmel hochzukrempeln und ein wenig reines C und/oder Assemblersprache auf dem Bare Metal zu programmieren. Sogar das oben erwähnte Java-basierte eingebettete System benötigt irgendwann einen Gerätetreiber für die E/A, und das bedeutet letztendlich, sich mit etwas C auseinanderzusetzen. Erfahrung ist der beste Lehrmeister. Wählen Sie einen Mikrocontroller, sei es MSP430, TMS320, AVR, ARM, PIC, 68HC11, was auch immer, finden Sie ein Evaluierungskit und bauen Sie einige Systeme.

Sparkfun hat eine Reihe guter Entwicklungsplatinen für unter $\$$50. Gehen Sie auch zu TI für die Stellaris-Familie im $$$50 to $$$ 100, auch das Hawkboard , das ich vorerst vor dem Beagleboard empfehlen würde, für das, was Sie vielleicht lernen möchten / müssen, auch TI hat die MSP430-Familie und ich würde ein EZ430 und ein Dreierpack der Add-In-Boards für $\$ bekommen $10. Holen Sie sich bei Sparkfun ein Lillypad mit dem FTDI USB Serial/Power Board, das Lillypad ist so ziemlich das gleiche wie das Arduino Pro Miniaber Sie müssen für den Pro Mini löten. Ich bin kein Fan der PIC-Familie, aber vielleicht möchten Sie dort etwas als Geschichtsstunde bekommen, das gleiche gilt für den 8051, beide Familien sind immer noch beliebt und in Gebrauch, nur nicht sehr effizient und wurden von anderen Architekturen übergangen. Lernen Sie unbedingt ARM und Daumen, vielleicht MIPS (was ein pic-32 ist, nicht zu verwechseln mit der älteren ursprünglichen PIC-Architektur). Das ARMmite Pro ist ein gutes Einstiegs-ARM-Board, obwohl das Stellaris es auch sein könnte.

Was Sie hier lernen möchten, ist Assembler für verschiedene Plattformen. C. Interaktion zwischen C und Assembler. Verschiedene Tools GCC und Nicht-GCC. Wie man eine Datenblatt-/Programmierreferenz liest (und erkennt, dass sie alle einige Fehler haben oder irreführend sein können, vertraue ihnen niemals, die Hardware gewinnt über Dokumente) und wie man einen Schaltplan liest oder verwendet. Dies sind normalerweise keine komplizierten Schaltpläne. Einige der Boards eignen sich gut für Schnittstellen in Projekten, was bedeutet, dass sie keinen Müll auf dem Board haben, sondern nur direkten Zugriff auf die I/O-Pins. Aber das ist nicht das Beste zum Lernen. So etwas wie ein StellarisBoard, das für Projekte schmerzhaft ist, hat viele lustige Sachen an Bord, um Embedded zu lernen und zu lernen, Treiber zu leihen/zu verwenden oder eigene aus Datenblättern zu schreiben. Der Atmel AVR-Schmetterling ist auch ein gutes Board, wenn er noch verfügbar ist. Möglicherweise müssen Sie an Ihrem eigenen seriellen Anschluss löten, um ihn zu programmieren, oder einfach einige Drähte in die Löcher klemmen. Was es Ihnen gibt, sind ein paar Peripheriegeräte, die Sie programmieren lernen können.

Selbst wenn Sie am Ende Embedded-Arbeiten erledigen, bei denen Sie Anwendungen mit SDK- oder API-Aufrufen unter Linux oder einem RTOS schreiben (ohne Hardware zu berühren oder Datenblätter zu lesen), werden Sie mit den oben genannten Kenntnissen immer noch einen Schritt voraus sein.

Dieser Artikel (automatisch aus dem Portugiesischen ins Englische übersetzt) ​​bietet einen guten Überblick über die Entwicklung einer Karriere als Entwickler von eingebetteter Software. Hinweis: Das Original ist hier .

Es beginnt mit der Skizzierung der Wissensbereiche, die Sie entwickeln müssen:

1. Wissen: Sie müssen die Theorie von eingebetteten Systemen kennen. Gemeint sind Hard- und Software. Es ist unmöglich, ein kompetenter Entwickler von eingebetteter Software zu sein, ohne die funktionierende Hardwarearchitektur zu kennen.

2. Skill: Sie müssen Erfahrung in dem Bereich sammeln. Braucht Übung. Sie können alle PIC-Assembler-Mnemoniken dekorieren, aber es nützt nichts, wenn Sie mit diesem Wissen keine LED ansteuern können.

3. Einstellung: Sie brauchen vor allem eine Einstellung, die Sie in diesem Bereich wachsen lässt. Es ist eine sehr dynamische mit häufigen Änderungen und Entwicklungen. Sie müssen immer motiviert sein (a) Autodidakt sein, Spaß am Lernen haben, „optimieren“ und verstehen, wie die Dinge funktionieren. Ohne solche Einstellungen wirst du bald aufgeben. Denn in diesem Bereich muss man sehr, sehr hartnäckig sein.

Es gibt dann die folgenden Tipps zur Bewältigung dieser Bereiche (und entwickelt sie mit weiterem Text, dies sind nur die Überschriften):

1. Was Sie brauchen, um Hardware zu lernen (mindestens)
2. Was Sie zum Erlernen der Software benötigen (mindestens)
3. Studieren Sie außerdem Betriebssysteme
4. Sie brauchen eine Ausbildung
5. Hören Sie nicht auf, lernen Sie weiter und entwickeln Sie Ihr Netzwerk weiter!

Denken Sie zweimal darüber nach, bevor Sie Embedded Software Engineer werden. Ich hatte Phasen in meiner Karriere. Ich habe in den ersten 5 Jahren Software entwickelt, bin dann in den Vertrieb/Marketing gewechselt, habe das 15 Jahre lang gemacht, ein 100+M$-Geschäft geleitet und bin jetzt zurück zur Software.

Wenn ich nach 15 Jahren zur Software zurückkehre, erinnere ich mich, warum ich überhaupt gegangen bin. Es ist schwer. Es erfordert Konzentration, mehrere hundert Codezeilen, die sich berühren, und Sie alle müssen es im Gedächtnis behalten. Eingebettet ist besonders hart.

Du musst dich auch selbst verstehen. Wenn Sie im Allgemeinen ein kluger Kerl, akribisch und geduldig sind, würden Sie einen großartigen Ingenieur abgeben. Wenn Sie eines davon vermissen, werden Sie bestenfalls durchschnittlich sein. Denk darüber nach. Wenn Sie ultraschlau und nicht geduldig sind, ist das nicht viel wert, denn egal wie schlau Sie sind, gute Technik erfordert Geduld und Liebe zum Detail.

Sie müssen sich auch wohl fühlen, wenn Sie Codestunden gleichzeitig ansehen, ohne zu sprechen. Ich beobachte, dass Menschen mit guter sozialer Kompetenz das unerträglich finden.

Wenn all dies zutrifft, dann lesen Sie all diese großartigen Bücher, machen Sie die Übungen und Sie werden ein großartiger Ingenieur sein. Viel Glück

Alle anderen sagen tolle Dinge. Deshalb gebe ich Ihnen einen allgemeinen Rat: Lesen, Lesen, Lesen, Lesen, Lesen, Lesen, Lesen!

Lesen Sie jeden Artikel auf http://embeddedgurus.com Wenn Sie etwas nicht verstehen, recherchieren Sie es. Wenn Sie in der Erklärung dieser Dinge etwas finden, das Sie nicht verstehen, lesen Sie weiter. Ich stehe kurz vor dem Einstieg in eine Embedded-Software-Position und meine Erfahrung besteht aus einer Handvoll professioneller Projekte in den letzten Jahren und einer Menge Lesestoff. Erfahrung lässt Sie Dinge ausprobieren, aber Lesen lässt Sie wissen, ob die Dinge, die Sie versucht haben, schon einmal gemacht wurden, vielleicht besser als Sie es könnten. Es führt Sie in Konzepte ein, mit denen Sie unter allen Umständen arbeiten können.

Gerade gelesen!

Werden Sie Experte für C. Verstehen Sie Timer und serielle Kommunikation. Damit solltest du dir die Hände schmutzig machen. Verstehen Sie HF-Protokolle und passen Sie sie an Ihre Anforderungen an. Probieren Sie Codekombinationen beim Debuggen nicht einfach blind aus. Code tut genau das, was Sie ihm sagen. Lesen Sie die Bedienungsanleitung und das Datenblatt und nehmen Sie dann eine Änderung vor, wenn etwas nicht funktioniert. Alles in allem ist der einzige wirkliche Weg, ein Experte zu werden, das Üben. Erstellen Sie weiterhin Anwendungen. Bald wird es zur zweiten Natur werden.