mikrocontroller.net

Forum: Compiler & IDEs Code-Portabilität


Autor: Tommy M. (muello)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Hallo,

ich programmiere im Freizeit- und Hobbybereich mit µC (ATmega und 
LPX1768) meist mit Schnittstelle UART, SPI und I2C.

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.

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

Vielen Dank

T. Müller

Autor: Oliver (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Was willst du denn erreichen?

Oliver

Autor: Karl Heinz (kbuchegg) (Moderator)
Datum:

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

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

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

Autor: ... ... ... (Gast)
Datum:

Bewertung
0 lesenswert
nicht lesenswert
Frank M. schrieb:
> Ich würde mich da an dem Design von Unix-Device-Treibern orientieren.
> Dort wird alles über die Systemaufrufe
Damit wird es ja mehr oder weniger OOP.

Autor: Frank M. (ukw) (Moderator) Benutzerseite
Datum:

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

Autor: Tommy M. (muello)
Datum:

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

Danke

Thomas

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.
Hinweis: der ursprüngliche Beitrag ist mehr als 6 Monate alt.
Bitte hier nur auf die ursprüngliche Frage antworten,
für neue Fragen einen neuen Beitrag erstellen.

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