Kommt die Embedded-Programmierung der Elektrotechnik oder der Softwareentwicklung näher? [geschlossen]

Ich werde mit einem Job zum Schreiben von Embedded C auf Mikrocontrollern angesprochen. Zuerst hätte ich gedacht, dass die Einbettung von Programmierung auf dem Software-Stack für mich zu niedrig ist, aber vielleicht denke ich falsch darüber nach.

Normalerweise hätte ich mir die Möglichkeit genommen, eingebetteten Code zu schreiben, da ich mich nicht als Elektrotechniker betrachte. Ist das eine schlechte Annahme? Kann ich interessante und nützliche Software für eingebettete Systeme schreiben oder mache ich mir selbst einen Kick, weil ich zu wenig auf dem Software-Stack habe?

Ich bin zur Informatikschule gegangen und habe es wirklich genossen, einen Compiler zu schreiben, über parallele Algorithmen nachzudenken, Datenstrukturen zu entwerfen und Frameworks zu entwickeln. Allerdings bin ich derzeit als Webentwickler beschäftigt, was die interessanten Dinge, die ich gerade beschrieben habe, nicht schreit. (Ich beschäftige mich derzeit mit folgenden Problemen: "Dieses Kontrollkästchen muss 4 Pixel links sein" und "Dieses Datum ist falsch formatiert".)

Ich schätze die Beiträge aller. Ich weiß, dass ich die Entscheidung selbst treffen muss, ich möchte nur eine Klarstellung darüber, was es bedeutet, ein eingebetteter Programmierer zu sein, und ob es zu dem passt, was ich interessant finde.

Wenn Sie gut an eingebetteten Systemen arbeiten wollen, dann müssen Sie manchmal wie ein EE denken. Dies ist in der Regel der Fall, wenn Sie Code für die Schnittstelle zu verschiedenen Peripheriegeräten (serielle Busse wie UART, SPI, I2C oder USB), 8- und 16-Bit-Timern, Taktgeneratoren sowie ADCs und DACs schreiben. "Datenblätter" für Mikrocontroller umfassen oft Hunderte von Seiten, da sie jedes Bit jedes Registers beschreiben. Es ist hilfreich, einen Schaltplan lesen zu können, um eine Karte mit einem Oszilloskop oder einem Logikanalysator abzutasten.

In anderen Fällen wird nur Software geschrieben. Aber unter engen Bedingungen: Oft haben Sie kein offizielles Betriebssystem oder ein anderes Framework und möglicherweise nur ein paar KB RAM und vielleicht 64 KB Programmspeicher. (Diese Grenzwerte setzen voraus, dass Sie auf kleineren 8- oder 16-Bit-Mikros programmieren. Wenn Sie mit Embedded Linux auf einem 32-Bit-Prozessor arbeiten, gelten nicht dieselben Speicherbeschränkungen, es müssen jedoch weiterhin benutzerdefinierte Einstellungen vorgenommen werden Peripherie-Hardware, für die Ihre Linux-Distribution keine Treiber bereitstellt.)

Ich habe einen Hintergrund in EE und CS, also genieße ich beide Seiten der Medaille. Ich mache auch einige Web-Programme (hauptsächlich PHP) und Desktop-Apps (C # und Delphi), aber es hat mir immer am meisten Spaß gemacht, an eingebetteten Projekten zu arbeiten.

@ Tcrosley Antwort ist ausgezeichnet. Sie müssen kein Elektrotechniker sein, aber die Grundlagen zu kennen, hilft.

Ich glaube nicht, dass Sie befürchten müssen, "zu niedrig auf dem Software-Stack zu sein". Ich musste als Embedded Engineer viele sehr interessante Probleme lösen. Sie erwähnen eine Liste von Aufgaben, die Ihnen gefallen haben:

• Gleichzeitige Algorithmen - Der Umgang mit Interrupts auf asynchroner Hardwareebene ist mit so vielen interessanten Herausforderungen verbunden wie die Verwendung eines Betriebssystem-Thread-Modells.

• Datenstrukturen entwerfen - prüfen. Design für Kompaktheit und effizienten Zugang.

• Frameworks entwickeln - prüfen. Auf Bare-Bones-Systemen können Sie am Ende ein Mini-OS entwerfen.

• Schreiben eines Compilers - möglicherweise nicht, aber Sie können am Ende eine Codeoptimierung auf niedriger Ebene durchführen, die dem Schritt der Assembly-Generierung eines Compilers ähnelt.

Ich würde es mir aussuchen, an eingebetteten Systemen zu arbeiten, anstatt die Benutzeroberflächen zu codieren. Sie werden nie vergessen, wie sich eine Maschine zum ersten Mal so bewegt, wie Sie es programmiert haben. Es ist viel befriedigender, als Pixel zu schieben.

Als Embedded-Programmierer ist es meine Aufgabe, benutzerdefinierte Hardware zum Laufen zu bringen. Normalerweise habe ich eine Reihe von Software auf einem Entwicklungsboard oder eine frühere Version von Hardware entwickelt. Wenn das neue Board kommt, ist es meine Aufgabe, meine Software auf das Board zu stellen und zu demonstrieren, dass alles funktioniert.

Da es fast immer ein Problem gibt, sind Fähigkeiten zum Debuggen unerlässlich. Wenn das externe Peripheriegerät nicht funktioniert, handelt es sich um einen schlechten Chip, eine schlechte Verbindung zum Chip, einen fehlerhaften Code oder eine falsche Verwendung des On-Chip-Peripheriegeräts? Die einzige Möglichkeit, dies festzustellen, ist ein umfangreiches Debugging. Dies bedeutet, dass Sie mit Oszilloskopen, Netzwerkanalysatoren, Logikanalysatoren und Zieldebuggern vertraut sind. Der Debugging-Prozess wird fast wissenschaftlich. Ich entwickle eine Hypothese, entwerfe ein Experiment, um Beweise für oder gegen meine Hypothese zu liefern, und teste.

Bei der Bewertung von Praktikanten oder neuen Embedded-Ingenieuren ist diese Fähigkeit am wichtigsten. Jede Software hat Probleme, aber sobald Sie anfangen, mit den physikalischen Welten in Kontakt zu treten, nimmt die Vielfalt dieser Probleme exponentiell zu. Die Essenz meiner Arbeit ist es, die lange Reihe von Problemen zwischen Konzept und Realität zu lösen.

Nach meiner Erfahrung erzielt man mit einem "Softwareentwickler" -Hut bessere Ergebnisse bei der Entwicklung eingebetteter Systeme als mit einem "Elektronikingenieur" -Hut. (Praktiken wie TDD und CI sind im Hardware-Engineering weniger verbreitet.)

Andererseits denke ich, dass die Erfahrung, für ein eingebettetes System zu entwickeln, es besser macht; abgerundeter Softwareentwickler.

Ich war vor ungefähr 8 Jahren in einer ähnlichen Situation. Zu diesem Zeitpunkt hatte ich 7 Jahre Erfahrung in der Softwareentwicklung in Anwendungs- und Serverumgebungen. Meine einzige Erfahrung im Umgang mit Hardware war das Schreiben in Z80 Assembler als Teenager in einem ZX-Spektrum.

Es war sicherlich eine Herausforderung. Ich fand den Umgang mit den Chipsätzen im Assembler sehr unterhaltsam und habe sicher viel über Hardware gelernt. Ein wesentlicher Teil meiner Rolle bestand darin, die Hardware mithilfe von Software zu testen. Ich habe also gelernt, mit der Programmierung umzugehen und zu erkennen, dass es sich bei Ihrem Softwarefehler tatsächlich um einen Hardwarefehler handelt. Tatsächlich kann es von Software- und Hardware-Mitarbeitern manchmal eine Menge Arbeit erfordern, um festzustellen, ob es sich bei einem Fehler um Hardware oder Software handelt.

Ein Aspekt, den ich nicht erreichen konnte, war die Arbeit mit Gerätetreibern. Ich habe das nie wirklich begriffen, was eine Sache ist, die ich und der Geschäftsführer des Unternehmens nie verstanden haben, warum. Es wurde einfach eine akzeptierte Tatsache.

Es ist unerlässlich, sich mit einem Okziloskop und einem Lötion vertraut zu machen. sich daran zu erinnern, dass, wenn ein Hardware-Typ die Nummer 26 sagt, er IMMER 0x26 bedeutet, ist nützlich. Die Erkenntnis, dass Hardware-Ingenieure den Umgang mit Software als sehr frustrierend empfinden, hilft, aber ein Hardware-Projekt, das keine Software umfasst, wird als Kabel bezeichnet.

Ich blieb 4 Jahre in dieser Rolle und ging nur, weil ich für eine wirklich fantastische Gelegenheit geworben wurde.

Wie alles erfordert es einen ausgewogenen Ansatz. Ich liebe es, bei meinem täglichen Job mit eingebetteten Systemen zu arbeiten. Sie machen mich besser in der Elektrotechnik. Physische Datenverarbeitung und Automatisierung sind sehr aufregend. Auf der anderen Seite ist es fantastisch, Web-Apps zu erstellen und mit Cloud Computing zu basteln.

Wenn Sie es richtig machen, wird die Softwareseite nach Wegen suchen, die Dinge intelligenter und besser zu machen. Die Hardware-Seite von Ihnen wird Sie ressourcenschonend und supereffizient machen.

Ich bin kein Elektroingenieur, habe aber eine kleine Menge eingebetteter Software entwickelt. Das größte Problem, das ich festgestellt habe, ist, dass ich einen wesentlich grundlegenderen Hintergrund in Mathematik habe und daher nicht weiß, wie ich eine komplexe Reihe fortschrittlicher mathematischer Algorithmen ohne viel Hilfe einfach in Code zerlegen kann.

Für all die Dinge, bei denen ich mit Signalisierung spielen, Werte von Eingängen lesen, Daten an Ausgänge senden und all diese Dinge habe ich festgestellt, dass sie konzeptionell ein wenig anders sind als das, was ich täglich als Gut mache altmodischer Software-Entwickler. Das Schreiben von Software ist wirklich das, was es ist. Es ist, wenn Sie über die eigentliche Software hinausgehen müssen, dass ich Dinge finde, die wackelig werden, weil ich nicht das Wissen habe, direkt mit der Hardware zu spielen. Dies geschieht normalerweise beim Versuch, Code zu debuggen oder zu testen. Wenn Sie eine wirklich großartige Toolkette haben, haben Sie möglicherweise eine integrierte Debugging- und Simulationsumgebung, um den größten Teil der Schmerzen zu beseitigen. Trotz alledem müssen Sie manchmal zu den Grundlagen zurückkehren und Ihren Code testen eine Art Analysator, und die Realität ist, dass die meisten Embedded-Plattformen nicht

Aus dieser Perspektive denke ich nicht, dass es für die Embedded-Programmierung unerlässlich ist, Elektrotechniker zu sein, wenn die Aufgaben einfach sind und die tatsächlichen hardwarespezifischen Anforderungen minimal sind. Darüber hinaus denke ich, dass ein EE das Leben in einer eingebetteten Umgebung erheblich erleichtert, insbesondere wenn echte Wissenschaft erforderlich ist, um herauszufinden, wo die Probleme liegen.

Ich habe noch keine Embedded-Programmierung auf Unternehmensebene durchgeführt, aber in meinem Bachelor habe ich mich hauptsächlich mit Embedded-Systemen befasst, aus denen ich einige Jahre echte Erfahrung habe. Wir haben C für Atmel AVR verwendet und einige Texas Instruments-Chips mit VHDL angerührt und hatten einige theoretische Fragen zu ARM.

Bei dem, was wir hatten, waren es ungefähr 50-60 Prozent Programmieren (C), 20 Prozent Planen / Entwerfen (UML) und der Rest war physikalische Elektronik (Löten, Messen, Verdrahten, Kabelherstellung usw.). Ich stimme auch zu, dass es sehr interessant und unterhaltsam war und ich wünschte, ich würde auch eine Karriere in eingebetteten Systemen machen. Leider musste ich mit einem sehr kleinen Markt für eingebettete Systeme auf einfaches, altes Java EE zurückgreifen.

Aber ich schweife ab; Ich würde sagen, dass die oben genannten Prozentsätze den realen Arbeitsplätzen sehr nahe kommen, da unsere Lehrer ihre eigenen Unternehmen haben, und auch erwähnen, dass sie versuchen werden, dies so realistisch wie möglich zu gestalten. Wir hatten sogar zufällige 180-Grad-Drehungen bei den Anforderungen während des Projekts, heh heh.

Wie für den Stapel. Wenn Sie die eingebettete Programmierung kennen, haben Sie enorme Chancen, Ihre eigenen und sehr realen Hardwareprodukte zu erstellen, die Sie in realen Werken in Asien hergestellt haben könnten, und diese dann bei Ihnen vor Ort zu montieren (sei es zu Hause oder in Ihrem eigenen Unternehmen). Es ist sehr interessant! Sie können auch viele Geräte herstellen, die zu Hause hilfreich sind, z. B. bewegungsgesteuerte Wohnraumbeleuchtung, Timer für eine Kaffeemaschine, um Ihren Morgenjoe automatisch zuzubereiten, und so weiter. Aufregendes Zeug!