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