Hallo Meine Frage kurz zusammengefasst: Wie bereite ich meinen Wechsel von Hardwareentwickler zum Embedded-Softwareentwickler vor? Ich bin Hardwareentwickler mit Schwerpunkt Analog, RFID, EMV, kapazitive Sensorik, PCB-Design. Ich bin 40 Jahre alt und will die zweite Hälfte meines Erwerbslebnes etwas umgestalten. Mein Plan ist, während einem Jahr zuhause KnowHow anzueignen, vieleicht auch eine Weiterbildung besuchen. Und mich dann für Embedded Softwareentwicklung zu bewerben. Wie könnte ich diese private Weiterbildung anpacken? Welches KnowHow soll ich mir aneignen? Wie kann ich mich über das Level eines Studienabgängers anheben? Was ich schon kann: Im Elektrotechnikstudium (Level Fachhochschule Schweiz) hab ich natürlich schon Softwareentwicklung gehabt. Nur ist das nie so richtig vertieft worden. Ich beherrsche: * C: Hab ich dann und wann auf 8 Bit Controllern gebraucht. Da beherrsche ich die meisten Sprachelemente. * C++: Seit dem Studium nie mehr gebraucht. Theorie ist aber noch einigermassen präsent. * C#: Ich besitze ein Buch :-) * html, php, css: Ist zwar fachfremd, hab ich aber immer wieder mal gebraucht * Python: Hab ich schon mal installiert und ein Skript geschrieben. * LabView: Da kann ich einiges. * Software Versionsverwaltung, Branching, usw. : Hab ich keine Ahnung von. * Mikrocontroller: Bis jetzt nur PIC und AVR 8 Bit. Mein Fahrplan, den ich mir ausgedacht habe: 1) Zuerst auf nem 8 Bit uC mit einem kleinen Projekt alle C Elemente repetieren. 2) Eine Hardware und IDE für embedded C++ beschaffen und das objektorientierte programmieren einüben. 3) Software Versionsverwaltung erlernen Was könnte ich sonst noch tun? Was wären gute Thmen, die ich mir aneignen könnte? Welche Ausrüstung (uC Development Board und IDE) ist bei Schritt 2) für einen Anfänger geeignet? Ich will nicht zuviel Energie darauf verschenden, das Ding zum laufen zu bringen, sondern ich will einfach einstecken und drauf los programmieren. Vielen Dank für Tips, Anregungen und Ermutigungen ;-) Knut
:
Bearbeitet durch User
Hol dir ein Launchpad deiner Wahl. Anstecken Software runterladen und loslegen.
Patrick L. schrieb: > Hol dir ein Launchpad deiner Wahl. > Anstecken Software runterladen und loslegen. Danke, das ist mal ein karer Tip für den Anfang. Ich bin aml auf der Seite von TI gewesen. * Das programmiert man ja mit Code Composer Studio. Ist die IDE einigermassen benutzerfreundlich? Also nicht, dass ich zuerst 1000 Einstellungen konfigurieren muss? * Da ist c++ standardmässig möglich, oder? Dazu muss ich nicht eine superteure Extension dazukaufen, bei der ich dann schon bei der Installation scheitere? * Gibt es vieleicht eine Empfehlung, ob ich da mit den MSP430, den ARM oder den C2000 Chips starten soll? Einerseits soll der Chip anspruchsvoll genug sein, dass sich c++ (anstelle von c) lohnt, andererseits will ich keinen Chip, der so komplex ist, dass ich einen Digitalport zuerst über 20 Register konfigurieren muss, bevor ich eine LED ansteuern kann. Sorry, meine Fragen sind vieleicht für erfahrene Entwickler etwas naiv, aber ich habe infach etwas Berührungsängste mit komplexeren Systemen. Aber das hier ist ja das Beufs-Forum, also nicht zu tief ins Detail. Sonst mache ich dann einen Extra Thread woanders auf. Hat vieleicht sonst jemand Ideen, Welche Fachkompetenz ich mir sinnvollerweise zutun könnte? Was ist zum Beispiel ein sinnvolles Tool um erste Erfahrung mit Softwareversionsverwaltung zu machen?
Die GCC von TI ist nicht nur eine IDE sondern eine Comunity und nein nix Parameter, den Richtigen Launchpad anhängen, die GCC findet ihn meist sogar selber und schlägt dir dann Projekte vor. Aber es gibt auch IAR als Umgebung und mittlerweile noch paar andere. Auch Opensource gibt es auf Github zum Download. Du kannst aber auch ein Launchpad (Nicht TI) Kaufen, wobei bei TI kann ich dich zu 100% unterstützen. Zur zeit dümpeln bei mir etwa 300 TI Launchpad rum, da ich für jedes Neue Projekt ein Launchpad hole und dann stepp by stepp das Drumherum aufbaue. Wenn es läuft mache ich dann erst eine Platine, das spart Unmenge an Zeit, da es für fast jede Anwendung ein Launchpad oder Dok dazu gibt.
Meine Empfehlung, ganz klar: Nimm ein STM32F4 ARM von STMicroelectronics und ziehe dir die Udemy Kurse von Fastbitlab rein. MCU: https://de.aliexpress.com/item/1005001456186625.html?gatewayAdapt=glo2deu&spm=a2g0o.9042311.0.0.20b24c4dtb7mBH Kurse: http://fastbitlab.com/ Warte ein paar Tage, bis Udemy eine Aktion hat, dann bekommst du die Kurse für ca 10Eur oder so. Man muss sich ein wenig an den Lehrer und seinen Lehrstil gewöhnen. Kann man sich damit abfinden und anfreunden, sind die Kurse wirklich brauchbar für Anfänger und etwas Fortgeschrittene. Mit dem Wissen kannst du dann deine eigenen kleinen Projekte über Github in deinen Bewerbungen präsentieren. Gruß,
Ob ein Jahr reicht? Viele Programmierer haben, wenn man noch ihr Jugendhobby dazu betrachtet, mit 40 Jahren schon 25 Jahre Programmiererfahrung.
Embedded schrieb: > Ob ein Jahr reicht? Viele Programmierer haben, wenn man noch ihr > Jugendhobby dazu betrachtet, mit 40 Jahren schon 25 Jahre > Programmiererfahrung. Es ist vermutlich einfach nur mal ein Anfang, freilich wird sich der Threadersteller nach einem Jahr Selbststudium nicht mit berufserfahrenen Entwicklern messen können. Mich würde aber noch die Motivation des Threaderstellers interessieren. Wie kommt man im fortgeschrittenen Alter von 40 Jahren plötzlich auf den Trichter, dass einem Hardware-Entwicklung nicht mehr gefällt, und dafür lieber im Software-Bereich bei nahezu Null anzufangen? Warum?
David K. schrieb: > aber ich habe infach etwas Berührungsängste mit komplexeren Systemen. Was erwartest du dann aber von Embedded SW? > Hat vieleicht sonst jemand Ideen, Welche Fachkompetenz ich mir > sinnvollerweise zutun könnte? Handwerk? Lehrer? Gehen haufen Leute in Rente und Nachwuchs sieht nicht so üppig aus. :D > Was ist zum Beispiel ein sinnvolles Tool um erste Erfahrung mit > Softwareversionsverwaltung zu machen? Ich höre in dem Bereich (bin da aber Laie) eigentlich nur noch git, es gab wohl auch mal "Subversion".
Patrick L. schrieb: > Die GCC von TI ist nicht nur eine IDE sondern eine Comunity und nein nix > Parameter, den Richtigen Launchpad anhängen, die GCC findet ihn meist > sogar selber und schlägt dir dann Projekte vor. Klingt gut! Code Composer wird auch in meiner jetzigen Firma verwendet. Da kann ich mir sicher auch mal einen Entwickler schnappen und mir etwas zeigen lassen. Und sonst komme ich auch gerne im Forum wieder daruaf zurück. Aber im Moment will ich mich noch nicht in Details verlieren. Im Moment will ich mir einfach ne Roadmap zurechtlegen. Alex -. schrieb: > Nimm ein STM32F4 ARM von STMicroelectronics und ziehe dir die Udemy > Kurse von Fastbitlab rein. Danke, das kannte ich noch nicht. Ich hab vorhin kurz bie Udemy reingeschaut und das sieht gut aus. Ich werde das noch genauer anscheun. Danke!! Ein wenig kosten darf es ja schon. Embedded schrieb: > Ob ein Jahr reicht? Viele Programmierer haben, wenn man noch ihr > Jugendhobby dazu betrachtet, mit 40 Jahren schon 25 Jahre > Programmiererfahrung. Klar bin ich nach einem Jahr erfahrener Programmierer. Ich will bis dann lediglich besser sein als ein Studienabgänger. Ich hab in meiner Jugend ja auch programmiert und auch später ab und zu gecodet. Und die c++ Theorie vom Studium ist noch zu einem gorssen Teil im (Unter-)Bewusstsein. Timer, ADC, UART, Interrupts, I2C, SPI, Watchdog, Clockkonfiguration, ... hab ich in der Freizeit alles in C immer wieder mal gemacht. Was mir fehlt ist die Praxis im objektorientierten programmieren, Erfahrung mit Grossprojekten, Versionsverwaltung, Softwaretesting, Kollaboration mit anderen Programmierern, Projektplanung, UML, ... Senf D. schrieb: > Mich würde aber noch die Motivation des Threaderstellers interessieren. > Wie kommt man im fortgeschrittenen Alter von 40 Jahren plötzlich auf den > Trichter, dass einem Hardware-Entwicklung nicht mehr gefällt, und dafür > lieber im Software-Bereich bei nahezu Null anzufangen? Warum? Mir hat schon immer beides gefallen. Hardware und Software. Mit meiner ersten Stelle bin ich einfach mehr in die HW abgerutscht als ich wollte und wie es so ist, bleibt man oft bei dem, was man bis anhin gemacht hat. Oft bestimmt ja dein Arbeitgeber, in welchem Ressort du dich spezialisierst. Je länger je mehr stresst mich an der HW, dass es viel zu viel um Zulassung, Compliance, Safety, EMV und Qualität geht. Auch Lieferkette, Produktionsorte und Herstellungskosten haben so hohe Präsenz in der F&E, dass die eigentlich coolen Dinge wie Schaltungsentwicklung, löten, messen, und Kurzschlüsseproduzieren einfach zu kurz kommen. Ich mache fast nur noch Papierarbeit. In der Firmwareentwicklung scheint mir das Problem weniger zu bestehen. Jedenfalls in den Firmen, bei denen ich gearbeitet habe. Klar geht es da auch viel um Qualität, Testing, Planung, usw... Trotzdem hab ich das Gefühl, dass ich in der Firmwareentwicklung meine Nerd-Qualitäten besser ausleben kann. Bisher hab ich Hardware professionell gemacht, SW als Hobby. Jetzt will ich das umkehren.
:
Bearbeitet durch User
Embedded schrieb: > Ob ein Jahr reicht? Viele Programmierer haben, wenn man noch ihr > Jugendhobby dazu betrachtet, mit 40 Jahren schon 25 Jahre > Programmiererfahrung. Reicht locker.
David K. schrieb: > In der Firmwareentwicklung scheint mir das Problem weniger zu bestehen Nein. Das hast du da genau so. Aus meiner Sicht: entweder in ne kleinere Bude gehen, vielleicht sogar direkt HW und SW machen.. Da ist für viel Papierkram schlicht zu wenig manpower..
David K. schrieb: > Mein Plan ist, während einem Jahr zuhause KnowHow anzueignen Das ist der falsche Weg. Du musst Industrieluft schnuppern, z.B durch Praktika oder schlecht bezahlte Absolventenjobs.
David K. schrieb: > Mein Plan ist, während einem > Jahr zuhause KnowHow anzueignen, vieleicht auch eine Weiterbildung > besuchen. Und mich dann für Embedded Softwareentwicklung zu bewerben. > Wie könnte ich diese private Weiterbildung anpacken? Ich gehe mal davon aus, dass du einen Hochschulabschluss hast. Dann frage ich mich, in welchem Land ist dein Arbeitsmarkt? Andere Länder, andere Sitten. In der Schweiz kann es anders sein als in Deutschland. Allgemein wird es nicht einfach werden. Neben den Fachwechsel kommt vllt. noch ein Branchenwechsel dazu, dass wird ganz allg. im deutschen Arbeitsmarkt als Problem gesehen. Warum nutzt du deine Erfahrung nicht und baust die weiter aus, also Schwerpunkte setzen und dann z. B. Lead-Engineer werden? Vllt. hilft es ja mal abzuchecken, was deine Kollegen in anderen Firmen so tun, wie sie sich im Fachgebiet entwickelt haben und wohin, also ein wenig Orientierung suchen. Ich würde mir es ganz allgemein verkneifen, meine aufgebaute Erfahrung in die Tonne zu werfen und nochmal was anderes neu anfangen. Und dann kommt evtl. noch die Frage dazu, warum ein Jahr Pause? (interessiert mich nicht, aber künftige Arbeitgeber schon) Ich würde bei deinen Plan versuchen das bei deinem Arbeitgeber zu machen, also die Abteilung wechseln und dann Einarbeitung in das neue Gebiet. Ich denke, das wird am wenigsten Reibungsverluste verursachen. Es muss nur der Arbeitgeber überzeugt werden. David K. schrieb: > Wie könnte ich diese private Weiterbildung anpacken? Wichtig finde ich, dass da was hinter steht, also beispielsweise ein mehr oder weniger anspruchsvolles Projekt, dass du selber löst, dass du dich selbst in die Materie einfuchst. Dann lässt man auch gleichzeitig sehen, dass Motivation und Durchhaltevermögen dabei ist. > Welches KnowHow soll ich mir aneignen? Dass ist nicht so ganz wichtig. Wichtig ist, dass du es gemacht und geschafft hast und bei diesem Prozess kommen von ganz alleine die Dinge nach vorne, die wichtig sind. Vllt. wird irgendwann der Quellcode zu komplex, dass du dir denkst, mit C++ anstatt C komme ich weiter und schreibst einiges um oder dass du auf einmal feststellst, dass deine Programmierweise zu viel Speicher frisst oder dass das Gerät, was auf Batterie laufen soll, zu viel Batterien frisst. Und irgendwo ist noch ein Bug, wie komme ich dahinter, was da wo schief läuft bzw. wo das Programm falsch abbiegt. > Wie kann ich mich über das Level eines Studienabgängers anheben? Üben, Erfahrung sammeln, Projekt durchziehen und zeigen inkl. Know-How. Kurzum, motivationsbedingt einen raushauen. Ich denke, damit kannst du mehr Leute (Arbeitgeber) beeindrucken als dass du sagst, ich kann C++ mit Smartpointer, etwas Python (ohne GUI) und mixed Code öööhmmm, ja/nee ... Zudem kommt dann noch die Frage, warum jetzt der Wechsel? Hast du dich die letzten 15 Jahre gelangweilt oder was gemacht, wo keine echte Motivation bei war? (Wiederholungstäter?) > Was ich schon kann: > Im Elektrotechnikstudium (Level Fachhochschule Schweiz) hab ich > natürlich schon Softwareentwicklung gehabt. Nur ist das nie so richtig > vertieft worden. Was meine Studium-Kollegen damals an SW beigebracht haben bekommen, war im Grunde nicht viel, man könnte auch sagen, fast nix. Deswegen könnte man erst recht von dir erwarten, dass deine Motiovation, wenn du über dem Studentenlevel Abschluss nach einem Jahr stehen willst, zeigen kannst. Deswegen "ballern" und nicht "rumspielen". > Ich beherrsche: > * C: Hab ich dann und wann auf 8 Bit Controllern gebraucht. Da > beherrsche ich die meisten Sprachelemente. Das ist nicht so ganz wichtig. Wichtig ist bei 8-bittern, dass man bei wenig Speicher ressourcenschonend damit umgehen kann. Ich habe auf einen ATmega48 vor diversen Jahren eine paramtrisierbare Bussimulation für LKW's programmiert (konform nach SAE-1... als State Machine, zeit- und ereignisgesteuert) und das Ding lief 1A+. Ich bin darauf richtig stolz zumal der ATmega48 nur 1 kB RAM hat. Dafür habe ich mit allem drum und dran ca. 160-180 Stunden gebraucht. > * C++: Seit dem Studium nie mehr gebraucht. Theorie ist aber noch > einigermassen präsent. Das schöne an C++ ist, dass man dazu keine HW braucht um es zu lernen. Ich sehe es mal so, für Controller, egal ob 32-bit oder 8-bit, ist alles fundamentale, was mit der HW des Controllers zu tun hat, in C geschrieben. Wenn du den Controller also kennen lernen willst, hast du es mit C und einem Dev- bzw. Eval-Kit zu tun, dazu einen Debugger und womöglich mit Multimeter, Logic-Analyzer und Scope. Wenn du C++ lernen willst und dann vllt. noch mit GUI, dann reicht ein Laptop und irgendwo eine vernünftige Arbeitsumgebung. Und vllt. ein gutes Tutorial. In der Tube gibt es eine Serie, die ich ganz geil finde. Sie heißt "C++ von { bis }" = C++ von Anfang bis Ende. > * C#: Ich besitze ein Buch :-) C# auf Contoller? Ich kenne ein Firma, die sucht Leute, die Java auf Controllern können. > * html, php, css: Ist zwar fachfremd, hab ich aber immer wieder mal > gebraucht Das ist noch higher-level als C++. Habe ich noch nie gebraucht. > * Python: Hab ich schon mal installiert und ein Skript geschrieben. Python war bei mit immer interessant, wenn es um Automatisierung von Tests ging o. ä. Die Kommunikation mit dem Dev-Kit ging über USB bzw. seriell. > * LabView: Da kann ich einiges. Ich kann LabWindows/CVI, Labview im Embedded Bereich wird es sicher geben aber ist das notwendig oder nur ein nice to have? > * Software Versionsverwaltung, Branching, usw. : Hab ich keine Ahnung > von. Das wird wichtig, wenn mehrere Leute an einem Projekt arbeiten. Also wird dein Projekt, womit die deine Motivation zeigst, auch GIT-mäßig darunter verwaltet. Einfach um zu zeigen, dass du dich damit befasst hast und vllt. auch kannst. > * Mikrocontroller: Bis jetzt nur PIC und AVR 8 Bit. 8-bit Controller und C++ wird nicht so einfach werden, weil die 8-bitter nicht viel RAM haben. Wie schon geschrieben, da ist der sparsame bzw. sinnvolle Umgang mit den Ressourcen (RAM, Timer (soft/hard), IO-Ports, Stromverbrauch, Fließkommarechnen ...) wichtig. Bei 32-bittern gibt es mehr RAM und IO-Ports und oft mangelt es nicht an den Ressouren, schon eher, wie bei mir gerade, an der nicht vorhanden Fließkomma Fähigkeit = die FPU fehlt (oder ich muss mir Workarounds ausdenken und das Komma später in den String dängeln, Prozessorwechsel ist richtig blöd). Dafür haben aber 32-bitter Dinge drin, die sind schon anspruchsvoller, wie z. B. Verschlüsselung, DMA, ... und vllt. noch ein Real-Time Betriebssystem. > Mein Fahrplan, den ich mir ausgedacht habe: > 1) Zuerst auf nem 8 Bit uC mit einem kleinen Projekt alle C Elemente > repetieren. Zum Einstieg, Auffrischungskurs. > 2) Eine Hardware und IDE für embedded C++ beschaffen und das > objektorientierte programmieren einüben. Ich würde erstmal alles selber konfigurieren, initialisieren und gebrauchen und das passiert in C. Auf einem 8-bitter bei Auffrischungskurs und dann bei einem 32-bitter. Wichtig dabei finde ich, ist gute Dokumentation. Frustrierend ist es, wenn man ein Problem hat und in Doku A steht was anderes als in Doku B und C schreibt wieder was anderes und nach Tagen ohne weiter zu kommen, steht die Lösung im Forum irgendwo beim Hersteller, wo es dann heißt, alle Lösungen sind unvollständig bzw. unrichtig. Und ein Mitarbeiter der Fa. schreibt dann ausführlich, wie es geht und warum es so muss und nicht anders. Die User fragen sich dann, warum das nicht irgendwo im Datenbladl steht oder sonstwo. (Das ist meine TI-Erfahrung, s. u.) > 3) Software Versionsverwaltung erlernen Learning by doing. Neben GIT gibt es noch SVN. Aber das ist, denke ich, nicht sooo wichtig. Wichtig ist, dass man die "Mechanik" dahinter verstanden hat und damit umgehen kann. Wenn dann mal was schief läuft, dann gibt es sicher jemanden, der das irgendwie wieder gerade ziehen kann. > Was könnte ich sonst noch tun? > Was wären gute Thmen, die ich mir aneignen könnte? Elementäre Busprotokolle erlernen wie SPI, I2C und andere inkl. Initialisierung. Und dann gleichzeitig beide benutzen ohne dass es hakt und klemmt... Real-Time OS mit den Themen wie Tasks erstellen mit Prioritäten, Mutexe und Semaphoren, wie man was macht, was es dazu noch alles gibt und generell solche Dinge wie State-Machine, was das ist und was es macht usw. Und ganz wichtig: Motivation und Durchhaltevermögen zeigen. Ich denke, das ist die größte Herausforderung. Und auch ein halb fertiges Dingen zeigen können. Ob man das alles in einem Jahr schafft? Ich habe da meine Zweifel. > Welche Ausrüstung (uC Development Board und IDE) ist bei Schritt 2) für > einen Anfänger geeignet? Ich will nicht zuviel Energie darauf > verschenden, das Ding zum laufen zu bringen, sondern ich will einfach > einstecken und drauf los programmieren. Das finde ich eine suboptimale Einstellung. Sicher gibt es solche Dinge aber die Hintergründe sollte man sich schon aneignen auch deswegen, wenn was schief läuft, dass man weiß warum, welche Auswirkungen das hat und wie man damit umgeht. Was schon von Haus aus was kann, sind z. B. STM32F... Dev-Kits bzw. Eval-Boards. Zudem gibt es zu dem STM32-Zeug (und sicher auch zu dem STM8-Zeug sowie Atmel) gute und eindeutige Doku, von TI (wurde oben schon mal empfohlen) kann ich das leider nicht sagen, da hatte ich vor 3 Jahren das Problem, was ich oben schon beschrieb, mit halbgarer Doku, im Forum (e2e.ti.com, (enginer to engineer)) dann nach Tagen die Antwort finden usw. Auch toll, die TI's schrieben zu einem anderen Problem mit I2C Kommunikation kein Wort, wie das Verhalten des Controllers ist, wenn der I2C Eingangsbuffer beschrieben wird während eine I2C Kommunikation läuft. Ich habe bei der Doku bzgl. TI's C2000 und CC3240 oder so Controllern einen ziemlich schlechten Eindruck. Noch was zu dem STM32 Zeug: auf den Seiten von ST gibt es zu den einzelnen Dev-Kits/ Eval-Board reichlich Demo-Programme, die sich mit einem Thema beschäftigen, z. B. STM32F030 und mehrere Timer, läuft direkt auf dem Board mit LED's und Tasten. Dazu gibt es dann auch eine Doku, die alles erklärt. Und es gibt eine große Community, da kann man auch Infos bekommen.
David K. schrieb: > Meine Frage kurz zusammengefasst: Wie bereite ich meinen Wechsel von > Hardwareentwickler zum Embedded-Softwareentwickler vor? Kurze Antwort: einfach machen. :-) Sieh zu, dich möglichst aktiv und kreativ zu betätigen. Mein Einstieg war übrigens eine malloc()-Implementierung für die avr-libc. ;-) (Die war nicht ohne Bugs, aber sie lebt heute noch.) Beteiligung an Opensource-Projekten in dem Bereich ist immer ein gutes Betätigungsfeld, wenn du nicht gerade genügend eigene Projekte hast, die du angehen kannst. Mach dir den Einstieg nicht zu schwer; auch mit einem AVR kann man das Thema nach wie vor angehen. Hat den Vorteil, dass du schneller und auch "bare metal" loslegen kannst. Während ich mir eine Cortex-M-Umgebung noch einrichte, läuft das erste AVR-Projekt schon lange, denn dort genügt schon der Klassiker
1 | avr-gcc -Os -mmcu=atmega328 -o helloworld.elf helloworld.c |
um ein lauffähiges Binary zu erzeugen. Startup-Code, Linkerscript etc. bringt die Toolchain passend mit. Arbeite grundsätzlich mit eingeschalteter Optimierung beim Compiler. Alles andere ist Kokolorus, du debuggst dann was ganz anderes als das eigentliche Problem. OK, deine C-Kenntnisse müssen natürlich sattelfest genug sein, dass du nicht nur Anfängerfehler debuggen musst: Zeiger und Indizes verwechselt und solche Dinge. Die kann man ohne Optimierung vielleicht wirklich einfacher debuggen, aber das lernt man viel schneller gleich auf dem PC. Alle ernsthaften Probleme treten eh erst mit eingeschalteter Optimierung auf, das fängt beim berüchtigten vergessenen "volatile" an für eine Variable, die aus verschiedenen Kontexten gesetzt und abgefragt wird. Da beginnt die eigentliche Arbeit des Embedded-Entwicklers: man muss kreativ werden, wie man das Problem gefasst bekommt. Debugger mit Singlestep geht so gut wie nie wirklich brauchbar. Für jedes "richtige" Embedded-Problem ist beim Erreichen des ersten Breakpoints sowieso alles zu spät, weil das Timing im Eimer ist. Man kann dann nur noch post-mortem debugging machen, also fast so, als hätte man einen Coredump vor sich. Man muss sich da rantasten. Mal ein Array mit Log-Daten irgendwo hinlegen um so zu tracen, wo die Firmware schon lang gekommen ist. (Das Entwicklungssystem sollte immer genügend Speicherreserven haben, sowohl RAM als auch Flash.) An bestimmten Stellen mit GPIOs wackeln und das mit einem Logic Analyzer tracen. (Falls du noch keinen hast: das wäre deine ersten Anschaffung.) > * C: Hab ich dann und wann auf 8 Bit Controllern gebraucht. Da > beherrsche ich die meisten Sprachelemente. Musst du fließend sprechen können. > * C++: Seit dem Studium nie mehr gebraucht. Theorie ist aber noch > einigermassen präsent. Nach wie vor eher selten. Wenn man es benutzen kann (und der Kunde das vor allem auch will), kann es ganz praktisch sein. Man sollte stets im Hinterkopf behalten, welches Feature wie viele Ressourcen kostet. Eine Zeile C++ kann viel schneller den erzeugten Assemblercode explodieren lassen als eine Zeile C. Wenn man es wirklich sinnvoll benutzen kann, kann man aber manche Sachen sehr schön und gut dokumentierend abstrahieren. > * C#: Ich besitze ein Buch :-) Braucht kein Mensch in diesem Bereich. > * html, php, css: Ist zwar fachfremd, hab ich aber immer wieder mal > gebraucht Brauchst du höchstens, falls deine Plattform sowas ausgeben will. Aber dann wirst du stattdessen besser jemanden fragen, der sich damit gut auskennt. > * Python: Hab ich schon mal installiert und ein Skript geschrieben. Braucht man laufend. Nicht so sehr auf dem embedded target (wenngleich es hübsch ist, wenn man eins hat, wo sowas läuft, aber das sind die etwas größeren), aber auf dem PC. Auswerten von Logdaten, PC-Gegenstelle zur Schnittstelle auf dem Controller, allgemeine Automatisierungsaufgaben. In meinem aktuellen Job habe ich vielleicht 80 % Python auf dem PC und 20 % C auf der MCU aktuell. > * LabView: Da kann ich einiges. Kenne ich nicht. ;-) Messgeräte kann man prima auch mit Python ansteuern. SCPI zu kennen, ist dafür dann wiederum sehr hilfreich. > * Software Versionsverwaltung, Branching, usw. : Hab ich keine Ahnung > von. Essenziell. Eigentlich auch für Hardwareentwicklung, wenngleich ich zugeben muss, dass ich bei Dingen wie privaten PCB-Entwürfen da manchmal schlampig bin. Da sollte ich noch viel öfter auch Zwischenschritte aufzeichnen. Aktuell macht praktisch jeder Git. Ich finde dort zwar viele Dinge nicht so toll gelöst, aber es gibt halt ganz viel Tooling drumrum (Gitlab und solche Dinge), weshalb daran nunmehr kein Weg vorbei führt. Was bei dir in der Liste noch fehlt: grundlegende Assemblerkenntnisse für die verwendete(n) Plattform(en). Damit sollst du nicht programmieren (dauert viel zu lange), aber du musst das lesen und analysieren können, was der Compiler ausspuckt. Spätestes im Disassembler-Listing des Debuggers solltest du in der Lage sein nachzuvollziehen, was der Compiler da zusammen gestöpselt hat.
Der Standard Einstieg ist darauf zu arbeiten. Das Schwierige an Embedded Software ist uebrigens nicht die Sprache, sondern das Drum-Herum. Die Software muss fehlerfrei sein, denn ein Update ist nicht immer moeglich, auch falls man das denn wollte. Ein Rueckruf geht extrem ins Geld. Und eigentlich ist die Software sehr oft sicherheitsrelevant. Bedeutet man muss auch ueber die Normen Bescheid wissen. Und man muss die Hardware sehr genau kennen. Man sollte auch mit dem Einkauf zu tun haben. Sonst kauft ein smarter Einkaeufer ein Schnaeppchen, mit einer einzigen Ziffer anders in der Bezeichnung eines Bauteils und schon hat man unerklaerbare Ausfaelle. Wo liegt der Fehler ? Hardware - Software ? Debuggen hat einen viel hoeheren Stellenwert, denn die Software soll fehlerfrei sein. Mich wundert eigentlich nur wie man Hardware machen kann, ohne die Embedded Software dazu ...? Ich mache schon seit immer beides zusammen. Ah, ja, Embedded hat meist auch eine PC Anbindung. Die sollte man auch gleich machen. Sonst wird das nie was.
:
Bearbeitet durch User
Also für mich ist die Hauptkompetenz eines Embedded Entwicklers das effiziente Einsetzen des Speichers und Rechenzeit. Im Vergleich dazu gibt es auf dem PC unendliche Ressourcen. Dementsprechend muss auch ein Embedded-Entwickler sich auch um das Memory Mangement bis zur genauen Speicheraddresse kümmern und wissen, dass auch z.B. wenn man nicht das Attribut "packed" benutzt, dass es dann zum Padding auf die Wordbreite des Systems kommt. Das andere gravierende Problem bei Embedded ist die Synchronisation des Programmablaufs. Wie teile ich Ressourcen, z.B. Peripherals, einzelnen Tasks zu. Tasks müssen pausieren, wenn Daten und Ressourcen noch nicht zur Verfügung stehen. Tasks müssen sich gegenseitig mit Mutex ausschließen, wenn sie auf eine einzelne Ressource, wie gemeinsame globale Daten oder ein Peripheral zugreifen wollen. Bei mehrere Peripherals kann man Semaphores benutzen, wobei man dann die Peripherals als Tokens verpacken muss. Datenaustausch über globale Variablen ist unglücklich, daher sollte bei Embedded immer ein Realtime-OS zum Einsatz kommen, damit Daten über sichere Messageboxes ausgetauscht werden. Wie bei der Thread-Programmierung üblich, sollten auch Signals und Events benutzt werden. So sieht der Stand der Technik aus, wobei ich nicht ausschließe, dass man für Lowlevel-IO-Aufgaben auch mal einen einfachen 8051 oder AVR8 programmieren muss, was dann wieder eine Wissenschaft für sich ist im Verlgeich zum eher komfortablen ARM-Cortex Architektur. Daher ist es wichtig, eine ganze Bandbreite von Controllern zu kennen, dazu gehören auch PIC und ARM-Cortex Controller von verschiedenen Herstellern wie TI, STM, Microchip (ATMEL), NXP usw. Als Embedded-Entwickler hat man es auch gelegentlich mit programmierbaren Prozessoren bzw. SoMs mit SoCs auf Embedded-Linux-Basis oder FPGAs. Manchmal gibt es das sogar kombiniert, einen MPSoC, FPGA mit SoC. Das nur mal nebenbei.
In diesem ganz nicht ernst gemeinten Thread sind auch einige Hürden zum Embedded-Entwickler gut beschrieben: Beitrag "Bootcamp embedded systems"
Embedded schrieb: > Also für mich ist die Hauptkompetenz eines Embedded Entwicklers das > effiziente Einsetzen des Speichers und Rechenzeit. Die Hauptkompetenz für mich ist, dass es sicher und stabil läuft, was produziert wird. Ressourceneffizienz kann eine Rolle spielen, aber oft nicht die größte. Das heißt nicht, dass man damit verschwenderisch umgehen sollte, aber Stabilität ist wichtiger. So'n Kram wie "packed" spielt im realen Leben oft genug eine völlig untergeordnete Rolle. Für nicht genutzte Ressourcen bekommt man vom Controller-Hersteller eh kein Geld zurück. > Daher ist es wichtig, eine ganze Bandbreite von Controllern zu kennen "It depends." Lieber mit einem effizient arbeiten können als 20 verschiedene nur halbherzig kennen. Oft genug hat der Kunde eh seine ganz eigene Idee.
Vielen Dank für all eure Antworten, Ermutigen, Entmutigungen, Tips und Hiweise. Ich weiss das alles sehr zu schätzen. Mittlerweile hab ich meine 8-Bit Developmentbords ausgepackt und die UART tauscht fleissig Daten mit dem PC-Terminal aus. Natürlich interruptgesteuert ;-) Erste Materialbestellungen für weitere Hardware ist getätigt. Will heissen: Ich hab mich auf den Weg gemacht und bin gespannt, wie schnell ich wie weit komme. Übrigens mache ich das ganze berufsbegleitend. Wenn am Abend die Kinder im Bett sind, investiere ich einige Stunden in meine Weiterbildung. Hoffentlich halte ich es durch, mehrere Male pro Woche intensiv dran zu sein. Um auf einige eurer Anregungen etwas einzugehen: Da ich in einer Firma Arbeite, die grpssere Geräte herstellt, ist die HW und SW Entwicklung strickte getrennt. Am liebsten würde ich auch beides machen. Aber in grösseren Firmen, die auch gut bezahlen ist die Entwicklung oft aufgeteilt. Ich fände es aber am coolsten, einen Job zu haben, wo ich Hardware und Firmware gleichzeitig machen kann. Da ich Firmwareentwickler in meiner Abteilung habe, kann ich sicher viel auf die zugehen und fragen. Trotzdem will ich da nicht zu aufdringlich sein, weil ich meinem Chef meinen angepeilten Wechsel noch nicht offenbaren will. Am meisten zu lernen hab ich vermutlich (wie ienige angedeutet haben) bei Real Time, Threading und Sicherheit. Da habe ich noch keine Ahnung, wie ich das anpacke. Ein Projekt, das ich machen will habe ich schon länger im Kopf: Einen 6- oder 8- beinigen Roboter (Modellbauservos und 3D Drucker) der sich mit einem neuronalen Netzwerk selber das laufen beibringt. Und wenn das laufen etwas anspruchsvoll ist, soll er doch wenigstens selber lernen, das Gleichgewicht zu halten. Mit Github hab ich angefangen, mich zu befassen. Werde da in den nächsten Tagen einen Account einrichten und beginnen, selber geschriebenen Code hochzuladen. Für die Messgeräteansteureung mit Python hab ich auch schon einen Plan. Bei uns in der Firma steht im EMV Keller ein HF-Signalgenerator, der danach schreit, endlich automatisiert angesteuert zu werden. Kann sicher nicht schaden, wenn ich bei der Stellensuche vorweisen kann, dass ich sowas schon mal gemacht haben. Speziellen Dank an K. H. (hegy) für die lange Anbtwort. Da konnte ich viel nützliches draus ziehen. Wie ich mich an Opensource Themen beteiligen soll, weiss ich noch nicht. Bin auch nicht sicher, ob ich die richtige Vorstellung habe, wie gut man dazu sien muss, wie viel Energie man reinstecken sollte. Jedenfalls könnte es sicher nicht schaden, einige opensource projekte zu studerien um zu schauen, wie andere Leute ihren Code schreiben. Und ja, grundlegende Assemblerkenntnisse, könnten sicher auch nicht schaden. Zumindest so, dass ich lesen kann, was der compiler produzeirt hat. Das wird für mich eine grössere Hürde werden. Nochmals herzlichen Dank für alle Antworten!!! Gruss, David
David K. schrieb: > Mit Github hab ich angefangen, mich zu befassen. "git" heißt nicht (notwendig) "Github". Du kannst ein git-Repository auch ganz simpel lokal einrichten, ganz nicht-verteilt. Dann brauchst du Dinge wie "clone", "fetch", "push" und "pull" nicht, aber den Workflow hinsichtlich "add", "commit", "checkout" auf jeden Fall, und irgendwann sicher auch "branch" und "merge".
David K. schrieb: > Speziellen Dank an K. H. (hegy) für die lange Anbtwort. Vielen Bitte. Die Kostennote an welche Adresse? > Da konnte ich viel nützliches draus ziehen. Und danach ist mir noch das eine oder andere dazu eingefallen. Jörg W. schrieb: > "git" heißt nicht (notwendig) "Github". Github ist von Microsoft übernommen worden. Damit sind viele Leute von Github abgehauen und u. a. nach Gitlab gewechselt. Vllt. gibt es mit Microsoft dann künftig ein anderes Git, eins das mehr kann und mehr kaputt machen kann und zudem nicht besonders benutzerfreundlich ist oder logisch. Es könnte dann ein MS-Git mit anderen Kommandos geben, statt "push", "pull", "commit" usw. gibt es dann "up", "down", "transfer", "take", "give", "buy¨, "sell" usw. und ganz neu "repair", wobei das noch mehr Chaos verursacht. Neben Git gibt es auch noch SVN. Wo die Unterschiede genau liegen weiß ich nicht. Und solltest du z. B. eine Eclipse IDE benutzen, da gibt es für GIT und SVN entsprechende Plugins/Add-Ons mit grafischer Ausgabe, das macht das ganze etwas einfacher.
K. H. schrieb: > Vllt. gibt es mit Microsoft dann künftig ein anderes Git, eins das mehr > kann und mehr kaputt machen kann und zudem nicht besonders > benutzerfreundlich ist oder logisch. Man kann an Microsoft viel kritisieren, aber Benutzerfreundlichkeit gehört nicht dazu, da sind sie immer weit vorne mit dabei; ganz im Gegensatz zur Unix/Linux-Welt. Sicherlich ein ganz wichtiger Faktor für den kommerziellen Erfolg von Microsoft Produkten. Und nein, dieser Beitrag enthält keine Ironie.
Was ist der unterschied von C auf 8bit und C auf 64bit? Richtig, keiner. Also besorg die ein einfaches und günstiges experimentiersystem. Etwas was dich nicht gerade mit komplexität erschlägt, sonst gibst du nämlich auf. Kauf dir arduino clones. Dann fängst du mit "blink" auf dem 328p an. Dann PWM mit registern, interrupts etc. Wenn du den 328p beherrschst machst du einen webserver mit dem esp8266, immer noch mit arduino IDE. Hände weg von proprietären systemen. Das sind sackgassen. C# ist was für tiefenunfähige, C++ muss man verstehen aber nicht benutzen. Warum denn 1 jahr warten?
K. H. schrieb: > Es könnte dann ein MS-Git mit anderen Kommandos geben Halt, Moment, ob MS wohl schon damals bei "git" Pate stand? ;-) Bei git ist alles (OK, vieles) anders als bei allen anderen … K. H. schrieb: > Wo die Unterschiede genau liegen weiß ich nicht. Das wusste offenbar Linus Torvalds auch nicht, als er sich an git geschafft hat, auch CVS scheint er nicht gekannt zu haben. Sonst hätte er manche Fehler, die beim Übergang von CVS auf SVN repariert worden sind, nicht wieder eingebaut. Aber OK, das geht jetzt hier zu weit …
Angehängte Dateien:
Senf D. schrieb: > Man kann an Microsoft viel kritisieren, aber Benutzerfreundlichkeit > gehört nicht dazu, da sind sie immer weit vorne mit dabei Das glaube ich jetzt nicht. Was ist z. B. aus dem Ur-Skype geworden, das von Skype bzw. der Firma dahinter stammt? Das war ganz einfach zu bedienen, ein paar Steuer-Icons unten mittig im Bild und man wusste intuitiv Bescheid. Dann hat MS das übernommen und alles umgeworfen und das gratis Skype ist alles andere als bedienerfreundlich. Ebenso meinten sie mit Ribbons den großen Wurf gemacht zu haben aber scheinbar hat sich dieser große Wurf nicht durchgesetzt, sonst hätten andere SW-Hersteller, freie wie kommerzielle, das Konzept übernommen. Auch sehr fragwürdig finde ich Yammer, eine Austauschplattform von MS. Anmelden ist kein Problem, aber wo zum Himmel kann ich mich ausloggen? Nachdem ich mich eingeloggt habe steht oben rechts ein "Profilbild" (sofern vorhanden, ansonsten ein rundes Teil mit irgendwas drin) und links daneben mein Name. Wenn ich auf das "Profilbild" klicke, lande ich auf einer Art Startseite, wo oben drüber wieder ein Kreis ist mit meinen Initialien. Auf der Seite kann ich mich nicht ausloggen. Vllt., wenn ich auf das runde Teil mit meinen Initialien klicke? Auch nicht. Wo denn dann? Na da: <siehe Bild oben> ein Haus, ein Briefumschlag und eine Glocke in dunkelgrau, mit etwas Abstand ein Zahnrad in grau auf grauem Hintergrund. Und hier kann ich mich irgendwo ausloggen. Nur wo? Die Lösung steht weiter unten. :) Pepe T. schrieb: > Was ist der unterschied von C auf 8bit und C auf 64bit? > Richtig, keiner. Es gibt welche. Wenn du mal auf einen 8-Bit Controller ein printf() laufen lässt, wirst du feststellen, dass dann i. A. Feierabend mit dem Programm ist bzw. schon vorher, weil printf() relativ viel Stack braucht. Vllt. funktioniert es mit den Nano-Libs, aber zu viel Gebrauch machen würde ich davon nicht. Generell ist Stringverarbeitung und C ein ziemlich heftiges Dingen. Der Hintergrund ist übrigens, dass 8-Bit Geräte rel. wenig SRAM haben ggü. 32-bit oder mehr. Das macht C auf einen 8-Bit Gerät was anspruchsvoller, auch was Programmaufbau angeht bzw. das benutzen von irgendwelchen Konstrukten, Stichwort MISRA. Lesense dazu auch dies: https://de.wikipedia.org/wiki/MISRA-C Noch ein Ding sind Variablen. Bei wenig SRAM und dann vllt. float/double Variablen benutzen oder Arrays, die vllt. noch in der Schleife... Da kommt dann MISRA ins Spiel. Jörg W. schrieb: > Halt, Moment, ob MS wohl schon damals bei "git" Pate stand? ;-) Ich kenn mich in der Historie von GIT nicht aus. Aber MS schafft es auch, einen quasi-Standard über den Haufen zu werfen und mit was neuem zu kommen, weil das doch viel vorteilhafter ist, z. B. kann Outlook versandte Emails an einem Outlook Kontakt wieder zurückholen. Und wer braucht noch das alte Zeug aus den <eben mal nachkucken...> Anfang 2000er Jahren? Und beim Nachsehen file mir auf, dass GIT 2005 entstand ohne Microsoft aber seit 2017 das Repository vom Linux-Kernel auf einen Microsoft-GIT Server liegt. Aber was interessiert mich das Betriebssystem, auf dem GIT läuft? (Quellchen: https://de.wikipedia.org/wiki/Git) *** Unter dem Zeichen, das allgemein bekannt ist für Einstellungen, dem Zahnrad, kann ich mich beim Yammer abmelden. Wer hätte das gedacht? Sehnse hier im Bildchen unter dem Link, der letzte Punkt in der Auswahl, nur da kann man sich abmelden. Wirklich genial! Die wollen wohl nicht, dass man sich abmeldet, die wollen die Leute wohl tracken oder so. https://abload.de/img/screenshot_20220202_2ppj0q.jpg
K. H. schrieb: >> Was ist der unterschied von C auf 8bit und C auf 64bit? >> Richtig, keiner. > > Es gibt welche. Wenn du mal auf einen 8-Bit Controller ein printf() > laufen lässt, wirst du feststellen, dass dann i. A. Feierabend mit dem > Programm ist bzw. schon vorher, weil printf() relativ viel Stack > braucht. Es gibt größere 8-Bitter als einen ATtiny13. :-) Ich mache seit vielen Jahren printf auf AVRs, das geht völlig problemlos. Der Stack-Verbrauch ist in der Gleitkommaversion bissel größer als in der Standardversion, aber das ist auch alles. (Aktuell schaue ich mir gerade an, was man für 64-bit double in printf machen müsste, das wird dann wohl wirklich etwas größer werden. Aber 64-bit-double-Argumente werden halt ohnehin über den Stack übergeben, 32-bit double passte noch in 4 Register.) > Wer hätte das gedacht? "Drücken sie 'Start', wenn sie anhalten möchten." ;-)
Thread beobachten
Seitenaufteilung abschalten
Bitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.