Guten Abend Freunde der Elektronik!
An meinem Lebensabend beschäftige ich mich aus Interesse und Spaß mit
den Arm Cortex Controllern, HW und Programmierung. Zu meinem Background:
Als Dipl. Ing. E-Technik (FH) a.D. hatte ich bis etwa 2001 in der
Automobilzulieferbranche Steuergeräte programmiert auf hardwarenaher
Ebene, bevor ich dann ganz in die HW umgestiegen bin für den Rest meiner
Entwicklerlaufbahn. Dabei fiel mir bei den Motorola/Freescale (heute
NXP) Controllern auf, man hat die Treiber damals selber geschrieben,
sprich sich die IO Register selber bitweise vorgenommen, Libraries
hierzu gab es zum Glück nicht, man konnte sich programmiertechnisch
austoben. Heute gibt es gigantische Libraries, Codedschungels, wie CMSIS
oder ASF, je nach Hersteller, in denen tausende Funktionen, Makros und
Defines vereinbart sind, um Treiber damit zu schreiben. Sprich, ich muss
in diesem Codedschungel mir das Passende mühsam zusammensuchen, wobei
ich mir dann auch gelegentlich die Dokumentationen und den Code
anschauen muss, um bei Unsicherheiten zu wissen, was wird da genau
gemacht. Noch krasser ausgedrückt: Ich kann keine Zeile hardwarenahen
Code selbstständig schreiben ohne permanent in CMSIS, ASF und Co.
herumzusuchen. Ich käme mir da hilflos vor, erinnert mich an betreutes
Denken! Ob man diese zahlreichen vorgegebenen Funktionen, Makros und Co.
alle im Kopf behält, darf bezweifelt werden. Im Grunde genommen muss man
doch doppelte, zeitaufwendige Arbeit leisten: Erst das Reference Manual
verstehen, was muss programmiert werden, dann die Suche nach passendem
Code, statt diesen eben mal selber zu designen, was ja einfach ist.
Daher meine Frage: Ist das der heutige hardwarenahe Programmierstil, mit
Hilfe von diesen gigantischen Libraries zu programmieren, was ist der
Sinn, denn Zeitersparnis kann ich mir überhaupt nicht vorstellen, eher
das krasse Gegenteil. Und beim Thema Fehlerfreiheit habe ich auch
erhebliche Zweifel, weil diese Funktionen und Macros einen großen
Funktionsbereich und viele Controller einer Familie abdecken müssen, was
die Komplexität drastisch erhöht und folglich die Fehlerquote, nicht nur
beim Programmierer, auch beim Hersteller.
Mit den Argumenten lesbarer Code, Softwareengeeneering braucht man mir
nicht kommen, solchen Code kann man auch selbst designen mit den
Originalnamen aus den Reference Manuals, dazu braucht man kein betreutes
Denken.
Ich will hier keinen Religionskrieg anzetteln bei den Gurus dieser
Libraries, und hoffe daher auf eine sachliche Diskussion. Gerne lasse
ich mich eines Besseren belehren!
Gruß
Uwe
Uwe M. schrieb:> Ich will hier keinen Religionskrieg anzetteln bei den Gurus dieser> Libraries
Nein, willst Du bestimmt nicht bei Verwendung von Vokabeln wie
"gigantisch"...
CMSIS selbst ist ein eher minimalistisches Teil, von ARM herausgegeben
und gepflegt, damit man sich nicht jeden Kleinkram „an den Hacken
ablaufen“ muss. Da ist halt auch sowas drin wie Gestatten und Verbieten
von Interrupts und dergleichen. Das sollte man durchaus nehmen.
Dinge wie ASF sind dagegen ziemlich aufgebläht, Abstraktionen über viele
Schichten, viel Overhead. Um irgendwo ein Registerbit zu setzen, füllt
man eine Struktur mit allen Details aus, ruft eine Funktion auf, die
dann gleich die Welt retten will …
Wofür wir ASF hin und wieder benutzt haben ist, um ein "vendor
approved"-Beispiel für die Behandlung einzelner Details zu bekommen,
oder um komplette Codebeispiele zu haben, wie man bspw. einen USB-PHY
anspricht. Aber von da erschien es uns dann oft sinnvoller, unseren
eigenen Code zusammenzuhacken.
Uwe M. schrieb:> Daher meine Frage: Ist das der heutige hardwarenahe Programmierstil, mit> Hilfe von diesen gigantischen Libraries zu programmieren, was ist der> Sinn, denn Zeitersparnis kann ich mir überhaupt nicht vorstellen, eher> das krasse Gegenteil.
Da liegst Du aber gänzlich daneben.
Heutzutage wird z.B. von jedem Popelgerät erwartet, dass es
Schnittstellen wie USB, Ethernet, Bluetooth, etc. hat, damit man es in
die Industrie 4.0 integrieren kann oder es der Servicetechniker mit
einem 0815 Tablet konfigurieren kann.
Nun ist aber kaum ein kleiner Hardwareentwickler im Stande, in
angemessener Zeit einen industrietauglichen TCP/IP Stack oder
Bluetoothstack zu entwickeln. Daher bedient man sich halt dann eines
fertigen Stacks und dass dieser die eigene Applikation nicht stört,
nimmt man sich halt gleich noch ein passendes RTOS dazu, mit dem man
alles schön kapseln kann.
Anders gesagt, man hat oft keine andere Wahl als möglichst viele
bestehende Libraries zu nutzen, damit man einestages auch mal fertig
wird mit der Entwicklung und sie an den Kunden ausliefern kann.
Johnny B. schrieb:> Da liegst Du aber gänzlich daneben.
Na ja, Ansichtssache...
Fertige Stacks hat man auch früher gerne genommen, gerade für TCP/IP
oder USB. Darum geht es hier aber denke ich nicht.
CMSIS Core enthält im Grunde genommen die Register definitionen.
Alles was darüber hinaus geht soll das Programmieren erleichtern, wobei
ich das genau so kritisch siehe, wie du Uwe.
Ich hatte mir mal Cube MX und Cube HAL von ST angesehen. Mein ersten
beiden Programm funktionierten nicht, weil der HAL Code fehlerhaft war.
Außerdem ist es mir zu umständlich, neben dem Reference Manual auch noch
zusätzlich das Manual der HAL lesen zu müssen um dann am Ende bei jeder
5. Zeile Code zusätzlich auch noch den Quelltext der HAL lesen zu
müssen, um deren Anwendung zu verstehen.
Bedenke auch, dass diese Libraries offensichtlich auch dem Zweck dienen,
die an den jeweiligen Hersteller zu binden.
So weit ich kann, schreibe ich mir meine Funktionen also lieber selber,
auf Basis der CMSIS Core. Für Ethernet und USB verwende ich mangels
Know-How aber doch fertige Libraries. Ich habe hier Glück, denn für
"meine" STM32 Controller habe ich da gleich zwei Beispiele gefunden, die
ohne HAL funktionieren.
Es ist allerdings schon so, dass die Benutzung von Hersteller-Libraries
zunimmt und bei einigen Chips sogar unvermeidbar ist. Zum Beispiel beim
ESP8266, ESP32, Raspberry Pi. Da kommt sicher noch mehr. Die klassische
Trennung von "x macht die Hardware, ich mache die Software" ist von den
Herstellern nicht mehr gewollt.
Johnny B. schrieb:> Da liegst Du aber gänzlich daneben.
Ok, bei komplexen Funktionen wie USB, Ethernet, ja, da hast du absolut
Recht! Die zu programmieren wären Diplomarbeiten. Da würde ich erwarten,
daß man diese Funktionen als Binaries einbindet ähnlich einer printf()
in stdio.h. Darum geht es aber nicht, denn selbst einfachste Funktionen
wie GPIO Bits setzen, resetten,
Uart, I2C, SPI, ADC, Timer werden auf Registerebene unterstützt. Warum
wird hier nicht fertiger Objectcode wie beim printf() Beispiel
geliefert? Ok, bei Timern müssten viele Funktionen existieren wegen
derer Komplexität, besonders bei Motor control, aber wo ist das Problem?
Irgendwie habe ich den Eindruck, das Rad wird jedesmal neu erfunden...
Stefanus F. schrieb:> Es ist allerdings schon so, dass die Benutzung von Hersteller-Libraries> zunimmt und bei einigen Chips sogar unvermeidbar ist.
Stefanus, ein beängstigender Trend, wenn ich an SIL3 oder 4 Projekte
denke, und man eine black box vor sich hat, wo man erst einmal nicht
genau weiß, was in der Wundertüte drin ist. Sicherlich kann man alles
debuggen, ein Wahnsinnsaufwand, aber im Zusammenspiel mit anderen
Elektroniken, z.B. über Netzwerk und Realtime wird es verdammt
schwierig... Ehrlich gesagt, bei solchen Projekten bete ich Compiler an,
ja keinen Mist zu machen, da auch eine black box.
Naja, es gibt halt nach wie vor beides. Wir haben Device-Treiber für
sicherheitskritischen Code sowohl selbst geschrieben, als auch fertige
Libraries verwendet. Man muss halt wissen wie man mit OTS-Software
umgehen muss.
Wobei CMSIS tatsächlich schon einigermaßen brauchbar ist. Im Gegensatz
zum Schrott, den es teilweise von den MCU-Herstellern gibt.
Uwe M. schrieb:> Als Dipl. Ing. E-Technik (FH)
Und wenn dir ein Informatiker sagen würde deine Hardware ist viel zu
kompliziert und einfacher ist viel besser? Die ganzen Schutzdioden sind
total überflüssig und kosten nur?
Eine eigene Frage?
Dieser Thread ist über 8 Jahre alt.
Stell sie in einem eigenen Thread – dort lesen mehr Leute mit, und sie wird öfter und schneller beantwortet.
