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?
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.