Treiberentwicklung für 32-Bit-Mikrocontroller

Die Frage ist ohne weiteren Kontext so sinnlos wie „warum ist es nachts kälter als draußen?“

Oliver

Moin,

So ganz spontan: https://sysprog21.github.io/lkmpg/

Gruss WK

Max schrieb:

Guten Tag,

ich suche Informationen (Bücher, Artikel, Videos, Tutorials, etc.) zu dem Thema Treiberentwicklung für 32-Bit-Mikrocontroller.

Für NuttX: https://nuttx.apache.org/

https://nuttx.apache.org/docs/latest/index.html

Kostet nichts, kannst Du selber ausprobieren.

fchk

Was hat das Thema mit der Registerbreite des µC zu tun?

Das ist eher eine Frage des Schnittstellentyp (Block/Char, Sync/Async), der Anforderungen und des Konzepts.

Das lernt man nicht aus Büchern, sondern aus Erfahrung und ggf. durch "abgucken" bei Leuten die sowas können.

Gibt es eine Treiberentwicklung ausschließlich, wenn man ein RTOS hat?

Beispiele findet man zu STM 32 HAL?

https://www.youtube.com/watch?v=qNLE3yK2k7Q

Gibt es so etwas auch auf Deutsch? (Dieser Ultra FX oder wie der hieß, hatte er nicht damals zu diesem Thema einiges produziert?) Und werden dabei auch alle gängigen Industriestandards berücksichtigt?

Nutzt man in der Industrie auch den ESP32? Oder ist dort nur noch der ARM Cortex R/M relevant? Wird noch ein AVR oder 8051 eingesetzt?

Max schrieb:

Gibt es eine Treiberentwicklung ausschließlich, wenn man ein RTOS hat?

Beispiele findet man zu STM 32 HAL?

https://www.youtube.com/watch?v=qNLE3yK2k7Q

Gibt es so etwas auch auf Deutsch? (Dieser Ultra FX oder wie der hieß, hatte er nicht damals zu diesem Thema einiges produziert?) Und werden dabei auch alle gängigen Industriestandards berücksichtigt?

Nutzt man in der Industrie auch den ESP32? Oder ist dort nur noch der ARM Cortex R/M relevant? Wird noch ein AVR oder 8051 eingesetzt?

Was hat das mit dem Thema zu tun?

Treiber benötigt man unabhängig von der Plattform immer.

Programmieren ist ein wenig wie Kochen. Die wichtigsten Zutaten sind

• Können
• Fantasie
• Kreativität

Das "Können" kann man lernen, aber die anderen 2 Punkte kann man unter dem Begriff "Talent" zusammenfassen - das hat man oder eben nicht.

Sobald eine dieser Zutaten fehlt, mag das Ergebnis satt machen, aber es wird eben wie typischen "Kantine-Frass" schmecken und schlimmstenfalls sogar ungesund sein.

Gibt es eine Treiberentwicklung ausschließlich, wenn man ein RTOS hat?

Braucht dieser Treiber ein RTOS? Läuft dieser Treiber nur auf 32 Bit CPUs?

https://github.com/Makuna/NeoPixelBus

Max schrieb:

Gibt es eine Treiberentwicklung ausschließlich, wenn man ein RTOS hat?

Falsche Frage. --- wenn man ein OS hat ----

Definiere: "Treiberentwicklung"

Max schrieb:

auf Deutsch

Eher nicht... oder nur wenig... Sicherlich über 90% aller Quellen schneidest du dir mit der Anforderung weg.

Suche auf Ebay nach Displays oder irgendwelche Peripherie - Auf jeden Fall sollte ein Datenblatt sowie Registerbeschreibungen dafür auffindbar sein - Und leg einfach los. Naja so würde ich es machen, wenn ich "dieses Bedürfnis*" hätte, Treiber zu schreiben.

Wenn du für so ein "Allerwelts-Gerät" z.B. HD4470 oder BMP280 eine Ansteuerung schreibst, und nicht weiter kommst, kannst du jederzeit Hilfe in anderen Referenzen finden. Will sagen: Fang besser mit etwas "kleinerem und normalen" an, was auch ein anderer versteht oder schon gemacht hat - um dein Ergebnis zu vergleichen!

Außerdem gibt es ja kaum "direkte" 32-Bit Peripherie, außer du willst z.B. einen PCI-Bus bauen. Dein Host Mikrocontroller sollte seine "Treiber / SDK" für seine Internals in der Regel schon selber mitbringen!

Mein "erster eigener Treiber" war für ein Noritake Grafik-VFD mit 8 Bit Bus - Das Pinout und Beschreibung sowie Register Infos waren über mehrere verschiedene Datenblätter anderer VFDs verteilt, und einiges musste ich selber Zusammenreimen und ergänzen, weil es einfach kein Datenblatt oder Fertig-Treiber dafür gab.

Wie immer: Übung macht den Meister. Und Registerbreite ist tatsächlich total egal! Viel Spaß.

Tut mir leid, leider kann ich mit den Antworten nicht viel anfangen, aber besten Dank für die Mühe und Zeit.

Evtl. kommen ja nächste Woche noch mehr Tipps.

Einen schönen Sonntag noch.

Es gibt kein vorgegebenes Kochrezept für "Treiber".

Überlege Dir, welche Funktionalitäten Du mit Deinen "Treibern" abstrahieren willst, definiere die entsprechende API (Sprich Funktionen, Strukturen / Datentypen - wenn wir mal von C ausgehen) und fülle diese danach mit Inhalt für den ersten Controllertyp.

Dann hast Du Deinen ersten Treiber fertig.

Je nachdem wie gut Du am Anfang Deine API definiert hast, wirst Du später, wenn Du den gleichen Treiber für andere Controller programmierst, evtl. Änderungen oder Erweiterungen vornehmen wollen/müssen.

Grundsätzlich sollte man in so einem Treiber jegliche direkten Hardwareabhängigkeiten abstrahieren.

Allenfalls waere noch interessant worum's geht. Ein Treiber ist eine Abstraktion. Da wird mit kurzem Code in einem Interrupt etwas rumgeschaufelt, und dann gibt's ein Signal an das Main, resp an den weiter bearbeitenden Task. Dazu kommt noch eine Konfiguration, eine Initialisierung, ein Statuswechsel, ..

Und das ist eben schon verschieden von Kontext zu Kontext. Muss ein ADC 500 Punkte sammeln, oder ein grafischer Display upgedated werden ?

Markus M. schrieb:

Es gibt kein vorgegebenes Kochrezept für "Treiber".

Das ist erstmal NICHT richtig. Fast immer gibt die Umgebung (also das OS) das Kochrezept vor.

Nur dann, wenn kein OS involviert ist, dann kann man das Kochrezept selber festlegen.

Grundsätzlich sollte man in so einem Treiber jegliche direkten Hardwareabhängigkeiten abstrahieren.

Das ist MIST. Dieser Ansatz führt nämlich oft dazu, dass Features der Hardware "wegabstrahiert" werden. Das ist zumindest der worst case.

Viel öfter aber führt es dazu, dass Hardware-Features einfach nur mit neuen Namen versehen werden. Der Code bleibt dabei natürlich so hardwareabhängig, wie er ist, aber es kostet richtig Aufwand, herauszufinden, dass er es ist und warum er es ist, weil das Datenblatt wegen eben dieser Namensverwirrung nicht mehr als Referenz dienen kann.

Das ist das, was bei schwachsinnigen Abstraktionen wie etwa der ST-HAL oder auch dem QTouch-Scheiß von Atmel rauskommt. Sowas dient einzig dem Vendor-LockIn.

C-hater schrieb:

Das ist MIST. Dieser Ansatz führt nämlich oft dazu, dass Features der Hardware "wegabstrahiert" werden. Das ist zumindest der worst case.

Nein, das ist durchaus vernünftig.

Beispiel, ein eingebauter serieller Peripheriebaustein, welcher wahlweise I2C, UART, SPI usw. kann. Da macht es durchaus Sinn die jeweils unnützen Features "weg zu abstrahieren" (wie du es nennst). Den worst Case würde hier eine "Gottklasse" darstellen, mit viel zu vielen Haaren dran.

Vergleichbares gilt für Timer, mit ihren Modi.

Selbst für Pins. Einem OpenDrain Pin z.B. beim AVR8(welcher das gar nicht von Hause aus kann) die Möglichkeit zu nehmen, den Pin auf Output+High setzen zu können.

Max schrieb:

Treiberentwicklung für 32-Bit-Mikrocontroller.

Das könnten mehrere Aspekte sein, die meisten gelten für "normale" Entwicklung ebenso:

• Codierkonzepte (Benennung, Architektur, Kopplung/Kapselung)
• Plattformunabhängigkeit (endianess, HAL, 2/4 Byte int (und nein, int-typen mit bitbreite lösen das nicht))
• Sprachen (welche Version C++)
• Effizienz (Optimierung auf Takte, ram, rom, worst Case, ... )
• genutzte Standards (Posix, rtos, boost, ...)
• Konkrete HW (Displays, I2C Sensoren, ...)
• Rein SW (Fifos, Speicher, tastenentprellung, TCP/IP Stack)
• Konfig/Tayloring
• ...

Vielleicht ist es andersrum besser: was für Treiber kennst Du oder hast Du schon entwickelt?

Markus M. schrieb:

Grundsätzlich sollte man in so einem Treiber jegliche direkten Hardwareabhängigkeiten abstrahieren.

Es gibt daher auch immer Hardwaretreiber und Softwaretreiber. Der HW-Treiber liefert z.B. Putpixel und der SW-Treiber zeichnet damit Kreise, Buchstaben usw. Oder der HW-Treiber liefert CAN-tx, CAN-rx und der SW-Treiber baut daraus CANopen usw.

C-hater schrieb:

Grundsätzlich sollte man in so einem Treiber jegliche direkten Hardwareabhängigkeiten abstrahieren.

Das ist MIST. Dieser Ansatz führt nämlich oft dazu, dass Features der Hardware "wegabstrahiert" werden. Das ist zumindest der worst case.

Es kommt darauf an. Wenn das Ziel Portabilität ist, wird es vermutlich dazu kommen, dass man nur die wichtig(st)en Features implementiert, die für die Anwendung notwendig sind.

Aber die Frage vom TO ist ja so ungenau erstellt, da kann man viel schreiben.

Das ist das, was bei schwachsinnigen Abstraktionen wie etwa der ST-HAL oder auch dem QTouch-Scheiß von Atmel rauskommt. Sowas dient einzig dem Vendor-LockIn.

ACK. Diese "HALs" sind weder Fisch noch Fleisch.

Schau Dir mal als Beispiel für eine Art "Treiber" das FatFs von Chan an: http://elm-chan.org/fsw/ff/00index_e.html Das ist ein modular aufgebautes FAT Dateisystem für eine breite Palette von Controllerarchitekturen (8-32 bit) und Speichermedien. Dateisystem und hardwarenahe I/O sind klar voneinander getrennt. Ich finde das Paket gut strukturiert und dokumentiert.

Ich habe das vor langer Zeit für AVR Controller und SD/MMC karten verwendet, funktioniert tadellos. Selbst Siemens nutzt(e?) diese Bibliothek für die LOGO Kleinsteuerungen.

Max schrieb:

Tut mir leid, leider kann ich mit den Antworten nicht viel anfangen

Treiber schreibt man, um ein Gerät für ein Betriebssystem verfügbar zu machen. Dafür benutzt man eine geregelte, für das Betriebssystem festgelegte Schnittstelle.

Für Mikrocontroller gibt es in der Regel kein Betriebssystem bzw. Du hast auch keines genannt. Von daher ist Deine Frage nicht sinnvoll.

Wenn Deine Frage schon nicht sinnvoll ist, was erwartest Du dann von den Antworten?