Guten Tag,
bei Stellenausschreibungen werden manchmal Leute gesucht, die
Erfahrungen mit der Programmierung von STM32 haben.
Dabei gibt es mehrere Libraries (LL, HAL, SPL) für den STM32.
Alle dieser Libraries haben doch aber Probleme. SPL wird nicht mehr
aktualisiert, HAL scheint aufgebläht zu sein und hat ein paar Bugs (wie
ich es hier nachgelesen habe) und bei LL muss man doch praktisch alles
von Vorne entwickeln.
Wie aber machen es die Profis? Was erwarten die Leute, die solch eine
Stelle ausschreiben?
Hier werden sich gleich mindestens 50 Fachleute mit 75 Meinungen
melden.
Hinzu kommt dass die Fragestellung Freitags-Troll-Verdächtig ist.
(bei dieser allgemein gehaltenen Fragestellung die in den Raum
geworfen wurde)
Nö, eigentlich ist die Antwort einfach: Such Dir eine Variante aus, die
Dir am besten liegt. Schreib in den Lebenslauf nur die Plattform, nicht
die Abstraktions-Library. Die gehört da eh nicht hin. Und sollte man im
Vorstellungsgespräch wirklich gefragt werden, nennt man seine Variante
und erwähnt, wie gering doch der Umgewöhnungsaufwand sei.
mcuStudi schrieb:> Wie aber machen es die Profis? Was erwarten die Leute, die solch eine> Stelle ausschreiben?
In größeren Unternehmen erfolgt die Stellenausschreibung ausschließlich
durch die Personalabteilung. Aus der Fachabteilung kommt eine Liste mit
ein paar "Buzzwords", die zum einen in der Stellenanzeige auftauchen
werden. Zum anderen werden sie dafür verwendet, die eingegangenen
Bewerbungen vorzusortieren. Wenn also ein Bewerber schreibt: "drölfzig
Jahre Erfahrung mit verschiedenen Microcontroller-Familien von SGS-Ates
bis ST Microelectronics, unter Verwendung von LL-, HAL- und
SPL-Bibliotheken und CubeMX", dann fliegt er bei der ersten Sichtung
raus, denn dort steht nirgendwo STM32. Der entsprechende
Abteilungsleiter in der Entwicklung wird die Unterlagen niemals zu
Gesicht bekommen, um festzustellen, dass der Bewerber die Anforderung
genau erfüllt.
in der "professionellen" freien Wildbahn habe ich in den Endprodukten
alle 3 Varianten gesehen und noch mehr.
Ja sogar in einem neuentwickelten neuen Produkt wurde noch die SPL
eingesetzt.
Geht zwar ein bisschen an deiner Frage vorbei, könnte aber tortzdem
interessant sein.
Ich persönlich denke, dass sich generierte HALs durchsetzen werden
(damit meine ich nicht sowas wie CubeMX). Also sowas wie svd2rust (für
die Sprache Rust) oder für C++ finde ich das Projekt modm
(https://modm.io/) sehr spannend.
Bei diesen Projekten werden die modernen Sprachfeatures besser
ausgenutzt, so dass die HAL kompakter ist und einiges an fehlerhafter
Konfiguration kann bereits zur Compilezeit abgefangen werden, statt
aufwändig zur Laufzeut zu debuggen. Eine weiterere Zeit- und somit
Kostenersparnis
Roland D. schrieb:> Also sowas wie svd2rust (für> die Sprache Rust) oder für C++ finde ich das Projekt modm> (https://modm.io/) sehr spannend.> Bei diesen Projekten werden die modernen Sprachfeatures besser> ausgenutzt, so dass die HAL kompakter ist und einiges an fehlerhafter> Konfiguration kann bereits zur Compilezeit abgefangen werden, statt> aufwändig zur Laufzeut zu debuggen. Eine weiterere Zeit- und somit> Kostenersparnis
So so! Kennst du mir das bitte genauer erklären? Ich programmiere
beruflich die uC's seit 13 Jahren in C und habe nicht verstanden, was du
da schreibst.
Danke im Voraus!
A. F. schrieb:> So so! Kennst du mir das bitte genauer erklären? Ich programmiere> beruflich die uC's seit 13 Jahren in C und habe nicht verstanden, was du> da schreibst.
Und in den 13 Jahren in C sind Dir nie die gravierenden Schwachstellen
von C aufgefallen? Rust weist da doch einige sehr deutliche
Verbesserungen auf, aber bisher scheitert der Einsatz häufig daran, dass
man eben generierten (auch) auf generiertem C-Code aufsetzen muss.
A. F. schrieb:> So so! Kennst du mir das bitte genauer erklären? Ich programmiere> beruflich die uC's seit 13 Jahren in C und habe nicht verstanden, was du> da schreibst.
ein fiktives und stark vereinfachtes Beispiel:
angenommen wir haben einen UART1 der eine Baudrate bis 3MBaud
unterstützt und einen UART2 der intern an einem anderen Bus hängt und
deshalb nur maximal 1MBaud unterstützt.
Bisher hindert dich niemand daran zu versuchen auch den UART2 mit 3MBaud
zu konfigurieren und es knallt dann eben zur Laufzeit. Wie schön wäre es
denn, wenn dein Programm da nicht kompilieren würde und der Compiler
auch noch sagen würde, 3MBaud ist für UART2 kein gültiger Wert?
Und es kommt noch besser, dies ist eine sogenannte "zero cost
abstraction" d.h. es kostet dich absolut kein runtime overhead.
Solche Informationen sind in den SVD Dateien der Hersteller enthalten,
warum diese nicht auch verwenden?
Und es lässt sich auf vieles erweitern, z.B: welches peripheral hängt an
welchem DMA channel?
Welche GPIOs können als Timer1 PWM output verwendet werden?
usw.
(etwas Schleichwerbung: ich darf über ähnliche Themen demnächst in
Frankfurt einen Vortrag halten, falls es jemanden interessiert:
https://www.meetup.com/de-DE/IoT-Hessen/events/264495652/)
Roland D. schrieb:> Und es kommt noch besser, dies ist eine sogenannte "zero cost> abstraction" d.h. es kostet dich absolut kein runtime overhead.
Und das ist der wesentliche Punkt an der ganzen Angelegenheit!
Es ist eigentlich überhaupt kein Problem, eine sehr weitreichende
Kapselung von Zugriffen auf bestimmte Ressourcen auch in
Programmiersprachen wie C vorzunehmen, was aber bedeutet, dass zur
Laufzeit viele Überprüfungen stattfinden müssen. Und dann kann man viele
dieser Überprüfungen auch lieber gleich sein lassen, denn dadurch
verschiebt man das grundlegende Problem nur. Statt also darauf zu
achten, dass sich verschiedene Kontexte nicht beim Zugriff auf z.B. ein
Hardwareregister ins Gehege kommen, muss man Unmengen an Aufwand
betreiben, Fehlermeldungen und Rückgabewerte auszuwerten.
Bei der Konstruktion von Rust wurde jedoch schon sehr darauf geachtet,
viele dieser Überprüfungen zur Kompilierzeit durchzuführen und den
Overhead zur Laufzeit zu minimieren. Ein sehr schöner Artikel ist hier
zu finden:
https://blog.japaric.io/brave-new-io/
Natürlich muss man seine ganzen Treiber usw. auch so programmieren, dass
der Rust-Compiler seine Stärken ausspielen kann.
Ich selbst habe zwar auch noch kein Projekt mit Rust realisiert, aber
zumindest ein kleines Testprojekt werde ich zeitnah angehen.
Roland D. schrieb:> Bisher hindert dich niemand daran zu versuchen auch den UART2 mit 3MBaud> zu konfigurieren und es knallt dann eben zur Laufzeit.Roland D. schrieb:> angenommen wir haben einen UART1 der eine Baudrate bis 3MBaud> unterstützt und einen UART2 der intern an einem anderen Bus hängt und> deshalb nur maximal 1MBaud unterstützt.>> Bisher hindert dich niemand daran zu versuchen auch den UART2 mit 3MBaud> zu konfigurieren und es knallt dann eben zur Laufzeit.
Doch, mich hindern meistens die Angaben im Datenblatt sowas zu tun.
A. F. schrieb:> Doch, mich hindern meistens die Angaben im Datenblatt sowas zu tun.
Und auf welche Art und Weise dringen die Datenblattangaben bis in die
Buildumgebung (Compiler, usw.) für die Firmware vor? Gar nicht.
Roland D. schrieb:> Also sowas wie svd2rust
Das generiert doch nur die nackten Register-Header (bzw. was unter Rust
das Äquivalent zu den altbekannten CMSIS-Headern mit den ganzen typedefs
und defines ist, die werden ja auch automatisiert aus dem svd erzeugt),
aber das ist noch lange keine Abstraktionslibrary.
mcuStudi schrieb:> Wie aber machen es die Profis?
Die Profis sind imstande, alte Projekte zu pflegen, neue Libraries
auszuprobieren und die Library zu benutzen, die ihm vorgegeben wird.
Wenn in einer Stellenausschreibung bestimmte Libraries genannt werden,
dann sind das wohl genau die, die bereits verwendet werden oder
verwendet werden sollen. Wer sich auf so eine Stelle bewirbt, sollte
wenigstens mit den meisten davon vertraut sein.
Falls du die Hoffnung hegst, dass die Firma keinen passenden Entwickler
findet und die daher auch ohne passende Kenntnisse eine Chance hast,
bleibe wenigstens ehrlich. Ich finde nichts ärgerlicher, als Zeit mit
Schaumschlägern zu vergeuden, die angeblich alles können aber nichts
davon richtig.
Andreas S. schrieb:> dann fliegt er bei der ersten Sichtung> raus, denn dort steht nirgendwo STM32
Leider fürchte ich, dass du Recht hast. Nicht immer, aber immer öfter.
Stefanus F. schrieb:> Andreas S. schrieb:>> dann fliegt er bei der ersten Sichtung>> raus, denn dort steht nirgendwo STM32>> Leider fürchte ich, dass du Recht hast. Nicht immer, aber immer öfter.
Bei einem ehemaligen Arbeitgeber bewarb sich ein ASIC-Entwickler als
FPGA-Entwickler. Der Entwicklungschef und der Abteilungsleiter waren
begeistert, und auch der Personalchef hatte der Einstellung schon
zugestimmt. Aber dann trat der neue Mitarbeiter die Stelle nicht zum
vereinbarten Termin an. Wie sich herausstellte, stellte der
Sachbearbeiter(!) in der Personalabteilung beim Anlegen der Personalakte
fest, dass in den Bewerbungsunterlagen kein einziges Mal der Ausdruck
FPGA auftauchte und verschickte daraufhin einfach aus formalen Gründen
nicht die finale Version des Arbeitsvertrages.
Und da der Bewerber nichts mehr von dem Unternehmen hörte, nahm er
zwischenzeitlich eine andere Stelle an. Der eigentlich sehr
diplomatische Entwicklungschef äußerte daraufhin ein paar sehr deutliche
Unmutsbekundungen über die Arbeit der Personalabteilung.
Bernd K. schrieb:> Das generiert doch nur die nackten Register-Header (bzw. was unter Rust> das Äquivalent zu den altbekannten CMSIS-Headern mit den ganzen typedefs> und defines ist, die werden ja auch automatisiert aus dem svd erzeugt),> aber das ist noch lange keine Abstraktionslibrary.
Stimmt
allerdings hilft da schon die Rust eigene "sicherheit" relativ viel.
Durch das Owner-Borrow-Prinzip wird garantiert, dass immer nur an einer
Stelle auf ein Peripheral zugegriffen wird.
Oder z.B. hat der Systick Timer normalerweise 24Bit, Wenn man versucht
da 32Bit zu schreiben, warnt der Compiler einen auch.
A. F. schrieb:> Doch, mich hindern meistens die Angaben im Datenblatt sowas zu tun.
Genau das.
Und ausserdem helfen die Angaben im Datenblatt aus dem Chip mehr raus zu
holen, als die Mickymaus-Sprachen und aufgeblähten Libraries
ermöglichen.
Wer auf einem Microcontroller, der ja eine definierte Aufgabe zu
erledigen hat, eine objektorientierte Sprache einsetzt, hat
wahrscheinlich auch sonst die Kontrolle über sein Leben verloren.
