Ist die Programmierung von Low-Level-/Embedded-Systemen für Softwareentwickler schwierig?

Question

Da ich ein Generalist bin, kann ich viele Bereiche abdecken, von analoger Elektronik bis hin zum Schreiben einfacher Anwendungen, die eine Schnittstelle zu einem RDBMS-Backend haben.

Ich arbeite derzeit in einem Unternehmen, das Hardware zur Lösung branchenspezifischer Probleme entwickelt. Wir haben einen erfahrenen Programmierer, der schon Geschäftsanwendungen, Videospiele und eine ganze Reihe anderer Dinge für PCs geschrieben hat. Als ich ihn auf Low-Level-Programmierung anspreche, äußert er gleichzeitig Interesse, aber auch Zweifel und Ungewissheit, ob er sich dem Projekt anschließen soll.

Selbst wenn er über PCs spricht, scheint er sich auf der Sprachebene wohler zu fühlen als auf der unteren Ebene (Befehlssätze, ISRs). Trotzdem ist er ein schlauer Kerl, und ich denke, dass ihm die Arbeit Spaß machen würde, sobald er die anfängliche Lernschwierigkeit überwunden hat. Aber vielleicht ist das meine eigene Begeisterung für Low-Level-Sachen, die da spricht... Wenn er wirklich interessiert wäre, hätte er vielleicht schon angefangen, etwas in dieser Richtung zu lernen?

Haben Sie Erfahrung mit dem Übergang von Software zu Hardware (oder Low-Level-Software)? Oder, besser noch, haben Sie Erfahrung damit, einen reinen Softwareentwickler auf die Low-Level-Software umzustellen?

編集する。

P.S. Ich würde gerne von den Antwortenden hören, was ihr eigener Hintergrund ist - EE, CS, beides?

Answer 1

Letzten Endes ist alles eine API.

Sie müssen Code für eine SPI-Peripherie in einem Mikrocontroller schreiben? Holen Sie sich das Datenblatt oder das Hardware-Handbuch und sehen Sie sich das SPI-Peripheriegerät an. Es ist eine große, komplexe API.

Das Problem ist, dass man die Hardware und einige grundlegende EE-Grundlagen verstehen muss, um zu verstehen, was die API bedeutet. Das Datenblatt wurde nicht von und für SW-Entwickler geschrieben, sondern für Hardware-Ingenieure und vielleicht auch für Software-Ingenieure.

Es ist also alles aus der Perspektive der Hardware (seien wir ehrlich - die Mikrocontroller-Firma ist eine Hardware-Firma, die mit Hardware/Asic-Ingenieuren besetzt ist).

Das bedeutet, dass der Übergang keineswegs einfach und geradlinig ist.

Aber es ist nicht schwierig - es ist nur ein etwas anderer Bereich. Wenn Sie ein Studienprogramm durchführen können, beginnen Sie mit Kaninchen-Halbleiter Bausätze. Es gibt genug Software, so dass ein SW-Typ wirklich mit wenig Aufwand einsteigen kann, und die HW ist einfach zu handhaben, weil alles in netten kleinen Bibliotheken verpackt ist. Wenn sie etwas Komplexes machen wollen, können sie den direkten Hardware-Zugriff nutzen und auf der unteren Ebene herumspielen, aber gleichzeitig können sie einige ziemlich coole Sachen machen, wie zum Beispiel kleine Webserver o Schwenk-/Neige-Netzwerk-Kameras . Es gibt andere Unternehmen mit ähnlichen Angeboten, aber Rabbit konzentriert sich wirklich darauf, Hardware für Software-Ingenieure einfach zu machen.

Alternativ können Sie sie auch auf die Android-Plattform bringen. Es sieht für sie wie ein Unix-System aus, bis sie etwas Interessantes tun wollen, und dann werden sie den Wunsch haben, dieses kleine Problem anzugehen, und sie werden etwas über die Hardware lernen.

Wenn Sie wirklich ins kalte Wasser springen wollen, sollten Sie sich für eine Arduino-Bausatz - billige, kostenlose Compiler und Bibliotheken, ziemlich einfach für den Anfang, aber man muss Drähte anschließen, um etwas Interessantes zu tun, was für einen zögerlichen Software-Ingenieur eine zu große Hürde sein könnte. Aber ein wenig Hilfe und ein paar Stöße in die richtige Richtung und sie werden absolut begeistert sein, eine kleine LED-Anzeige zu haben, die wackelt* wie die Nightrider-Lichter...

-Adam

*Ja, das ist ein technischer Fachbegriff aus dem Ingenieurwesen.

Answer 2

Die besten Embedded-Programmierer, mit denen ich zusammengearbeitet habe, sind EE-geschult und haben SW on the job gelernt. Die schlechtesten Embedded-Entwickler sind frischgebackene CS-Absolventen, die glauben, dass SW die einzige Möglichkeit ist, ein Problem zu lösen. Ich betrachte die Embedded-Programmierung gerne als das unterste Glied der SW-Pyramide. Es ist eine stabile Abstraktionsschicht/Grundlage, die den Anwendungsentwicklern das Leben leicht macht.

Answer 3

"Schwer" ist ein äußerst relativer Begriff. Wenn Sie es gewohnt sind, in der engen, manchmal verworrenen Art und Weise zu denken, die Sie für kleinen eingebetteten Code benötigen (z. B. wenn Sie ein Treiberentwickler sind), dann ist es sicherlich nicht "schwer".

Ich will die Shell-Skripteure nicht "bashen" (kein Wortspiel beabsichtigt), aber wenn Sie den ganzen Tag Perl- und Shell-Skripte schreiben, dann könnte es sehr wohl "hart" sein.

Dasselbe gilt, wenn Sie ein UI-Typ für Windows sind. Das ist eine andere Art des Denkens.

Answer 4

Warum eingebettete Entwicklung "schwierig" ist:

1) Der Kontext kann zwischen den einzelnen Maschinenbefehlen auf einen Interrupt umschalten. Da Hochsprachenkonstrukte auf mehrere Assemblerbefehle abgebildet werden können, kann dies sogar innerhalb einer Codezeile geschehen, z. B. long var = 0xAAAA5555. Wenn in einer Interrupt-Service-Routine darauf zugegriffen wird, ist var in einem 16-Bit-Prozessor möglicherweise nur halb gesetzt.

2) Die Sichtbarkeit des Systems ist begrenzt. Sie haben möglicherweise nicht einmal eine Ausgabe für Hyperterm, es sei denn, Sie schreiben sie selbst. Emulatoren funktionieren nicht immer so gut oder konsistent (obwohl sie heute viel besser sind als früher). Sie müssen wissen, wie man Oszilloskope und Logikanalysatoren benutzt.

3) Operationen brauchen Zeit. Nehmen wir an, Ihr serieller Sender verwendet einen Interrupt, um zu signalisieren, wann es Zeit ist, ein weiteres Byte zu senden. Sie könnten 16 Bytes in einen Sendepuffer schreiben, dann die Interrupts löschen und sich wundern, warum Ihre Nachricht nie gesendet wird. Timing im Allgemeinen ist ein schwieriger Teil der Embedded-Programmierung.

4) Sie sind subtilen Race Conditions ausgesetzt, die nur selten auftreten und sehr schwer zu debuggen sind.

5) Sie müssen das Handbuch lesen. Sehr viel. Man kann es nicht durch Herumalbern zum Laufen bringen. Manchmal muss man 20 Dinge

6) Die Hardware funktioniert nicht immer oder ist leicht zu beschädigen, und es dauert eine Weile, bis man merkt, dass sie kaputt ist.

7) Software-Reparaturen in eingebetteten Systemen sind in der Regel sehr teuer. Sie können nicht einfach eine Webseite aktualisieren. Ein Rückruf kann jeden Gewinn, den Sie mit dem Gerät gemacht haben, zunichte machen.

Wahrscheinlich gibt es noch mehr, aber ich muss diese Rennbedingung lösen...

Answer 5

Das ist wohl sehr subjektiv, seine Gründe könnten vielfältig sein. Aber wenn er so ist wie ich, weiß ich, woher er kommt. Lassen Sie mich das erklären.

In meiner beruflichen Laufbahn habe ich 6 Jahre lang in der Telekommunikationsbranche gearbeitet und viel mit der Einbettung von SDK-Middleware in Low-End-Mobiltelefone usw. zu tun gehabt.

Die meisten eingebetteten Umgebungen, die ich erlebt habe, sind für einen Programmierer wie raues Wetter, man muss ständig mit begrenzten Ressourcen usw. zurechtkommen. Einige mögen dies als Herausforderung empfinden und genießen es wegen der Herausforderung selbst, andere fühlen sich der "echten Sache" - der Hardware - näher, wieder andere fühlen sich in ihrer Kreativität eingeschränkt.

Ich habe das Gefühl, dass dies meine Kreativität einschränkt.

Ich genieße es, wieder in der Windows-Desktop-Umgebung zu sein und mich mit ausgeklügelten Klassendesigns auszutoben, mir die Beine ein paar Takte mehr zu vertreten, unnötig viel Speicher für Diagnosen zu verwenden usw.

Auf bestimmten eingebetteten Einheiten hatte ich in der Vergangenheit kaum Unterstützung für fseek() (eine ANSI C-Standard-Dateifunktion). Wenn man Glück hatte, konnte ein "Watchdog" Hinweise darauf geben, wo etwas abgestürzt war. Ganz zu schweigen von der mühsamen Kommunikation mit dem Benutzer in präemptiven Single-Thread-Sümpfen.

Nun, Sie wissen, worauf ich hinaus will. Meiner Meinung nach ist es nicht unbedingt schwer, aber es ist ein ziemlicher Sprung, bei dem Sie möglicherweise wenig von Ihrer bisherigen Erfahrung wiederverwenden können.

Mit freundlichen Grüßen

Robert