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.
:
Bearbeitet durch User
mcuStudi schrieb: > Wie aber machen es die Profis? Die programmieren ihn mit der Arduino-Umgebung. Duckundweg.
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/)
:
Bearbeitet durch User
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.
:
Bearbeitet durch User
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.
Thread beobachten
Seitenaufteilung abschaltenBitte 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.