mikrocontroller.net

Forum: Mikrocontroller und Digitale Elektronik STM32 - wie programmieren


Announcement: there is an English version of this forum on EmbDev.net. Posts you create there will be displayed on Mikrocontroller.net and EmbDev.net.
Autor: mcuStudi (Gast)
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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?

Autor: OMG (Gast)
Datum:

Bewertung
-3 lesenswert
nicht lesenswert
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)

Autor: Walter T. (nicolas)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: MaWin (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
mcuStudi schrieb:
> Wie aber machen es die Profis?

Die programmieren ihn mit der Arduino-Umgebung.
Duckundweg.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Roland D. (roland_d829)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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

Autor: A. F. (artur-f) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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!

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Roland D. (roland_d829)
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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
Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: A. F. (artur-f) Benutzerseite
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
-1 lesenswert
nicht lesenswert
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.

Autor: Bernd K. (prof7bit)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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
Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
1 lesenswert
nicht lesenswert
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.

Autor: Stefanus F. (Firma: Äppel) (stefanus)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: Andreas S. (Firma: Schweigstill IT) (schweigstill) Benutzerseite
Datum:

Bewertung
2 lesenswert
nicht lesenswert
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.

Autor: Roland D. (roland_d829)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Autor: TheBug (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
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.

Antwort schreiben

Die Angabe einer E-Mail-Adresse ist freiwillig. Wenn Sie automatisch per E-Mail über Antworten auf Ihren Beitrag informiert werden möchten, melden Sie sich bitte an.

Wichtige Regeln - erst lesen, dann posten!

  • Groß- und Kleinschreibung verwenden
  • Längeren Sourcecode nicht im Text einfügen, sondern als Dateianhang

Formatierung (mehr Informationen...)

  • [c]C-Code[/c]
  • [avrasm]AVR-Assembler-Code[/avrasm]
  • [code]Code in anderen Sprachen, ASCII-Zeichnungen[/code]
  • [math]Formel in LaTeX-Syntax[/math]
  • [[Titel]] - Link zu Artikel
  • Verweis auf anderen Beitrag einfügen: Rechtsklick auf Beitragstitel,
    "Adresse kopieren", und in den Text einfügen




Bild automatisch verkleinern, falls nötig
Bitte das JPG-Format nur für Fotos und Scans verwenden!
Zeichnungen und Screenshots im PNG- oder
GIF-Format hochladen. Siehe Bildformate.

Mit dem Abschicken bestätigst du, die Nutzungsbedingungen anzuerkennen.