Code-Portabilität

Thomas Müller schrieb:

> Beim Durchstöbern von Büchern, u.a. "C und C++ für Embedded Systems" bin
> auf die Problematik "Treiberprogrammierung" im Zusammenhang mit
> Code-Portabilität gestoßen. Leider war das Beispiel, wo ein UART-Aufruf
> in Treiber- und Applikationslayer zerlegt wurde, im Buch nicht sehr
> ausführlich beschrieben.

Was hat dir denn gefehlt?

> Gibt es eurer Meinung nach für mein "Problem" sinnvolle Literatur oder
> Links, wie man sich am Besten in diese Problematik einarbeiten kann.

Hmm.
Diese Bücher sind grundsätzlich nicht schlecht. Man bekommt Ideen und 
Anregungen. Sie zeigen wie man Dinge sinnvoll machen kann.

Aber dann sind sie irgendwo aber auch wie Bücher übers Radfahren: Du 
kannst noch so viele Bücher darüber lesen und dir Tips holen - radfahren 
lernst du nur, wenn du dich auf den Drahtesel setzt und losfährst. Und 
leider manchmal auch hinfällst. Auch das gehört dazu.

Thomas Müller schrieb:

> Beim Durchstöbern von Büchern, u.a. "C und C++ für Embedded Systems" bin
> auf die Problematik "Treiberprogrammierung" im Zusammenhang mit
> Code-Portabilität gestoßen. Leider war das Beispiel, wo ein UART-Aufruf
> in Treiber- und Applikationslayer zerlegt wurde, im Buch nicht sehr
> ausführlich beschrieben.

Ich würde mich da an dem Design von Unix-Device-Treibern orientieren. 
Dort wird alles über die Systemaufrufe

open(), read(), write(), ioctl() und close() gelöst. Bei 
blockorientierten Geräten kommt dann noch lseek() hinzu, um zu 
positionieren. Sämtliche Geräte werden wie Dateien gehandhabt. Das hat 
den Vorteil, dass der I/O sehr einfach von Gerät zu Gerät oder auch 
auf/von Dateien umgelenkt wird.

Bei Character-Devices - wie bei einem UART - ist eine Implementierung 
für µCs dann ziemlich simpel:

    open()  entspricht der Initialisierung des UARTs
    read()  liest Zeichen
    write() schreibt Zeichen
    ioctl() macht Einstellungen, wie z.B. Baudrate, Bits per character,
            blockierendes/nicht-blockierendes/halb-blockierendes Lesen
    close() macht hier nicht unbedingt Sinn.

Das wären dann die µC-spezifischen Funktionen, die für jeden 
verschiedenen µC extra geschrieben werden müssten. Sollen sie nicht 
abstrakt auf irgendeinem beliebigen Gerät funktionieren, sondern nur auf 
einem UART, würde ich ein Prefix benutzen, wie z.B. uart_open().

Die eigentliche Applikation ruft dann einfach diese Funktionen auf. Da 
könnte man dann auch wieder eigene Library-Funktionen (siehe z.B. stdio) 
drüberlegen, um sich das Leben zu vereinfachen.

Dokumentationen zu obigen Systemfunktionen findest Du im Internet 
zuhauf, z.B. indem Du bei Google einfach das Schlüsselwort "man" vor die 
Systemfunktion schreibst, also z.B.

    man read

Viel Spaß,

Frank

... ... ... schrieb:
> Damit wird es ja mehr oder weniger OOP.

Wenn Du mit OOP objektorientierte Programmierung meinst, wüsste ich 
nicht, warum. UNIX-/Linux-Device-Treiber haben mit OOP nichts zu tun.

Vielen Dank für die Infos - ich werde mich auf die "man-Suche" begeben.

Danke

Thomas