Contollerunabhängige Programmierung

[Klaus S. (skibby)]

Hallo zusammen,

ich habe für einen Sensor der über I2C angesprochen wird ein 
Softwaremodul in C für einen LPC21xx programmiert. Nun möchte ich gerne 
dieses Modul auf einen MSP430 portieren. Das ist im Prinzip kein 
Problem. Nun habe ich mir aber überlegt ob ich das ganze nicht so 
gestalten könnte, dass mein Softwaremodul völlig controllerunabhängig 
programmiert wird und die controllerabhängigen Funktionen ausserhalb 
implementiert werden.
Wie stelle ich das am geschicktesten an ? (Ich dachte mal an 
Funktionszeiger doch leider stehe ich mit Zeigern etwas auf Kriegsfuss 
und vielleicht gibt es ja auch andere Methoden ...)

Danke im voraus,
Klaus Skibowski

[l0wside (Gast)]

Lösungs*skizze*:
- Controllerabhängigen und controllerunabhängigen Code trennen (jeweils 
eigene Quellcode- und Headerdateien). Gibt dann vier Dateien, die z.B. 
i2c.h, i2c.c, transceive.h und transceive_lpc.c heißen könnten.
- In transceive.h werden die controllerabhängigen Funktionen 
deklariert (z.B. i2c_send(), i2c_recv() oder was auch immer)
- In transceive_lpc.c werden die in transceive.h deklarierten Funktionen 
dann für den LPC definiert.
- Für den MSP430 musst Du dann "nur" noch eine transceive_msp.c 
schreiben, die die in transceive.h deklarierten Funktionen dann für den 
MSP430 definiert.
- Projekt bestehend aus i2c.h, i2c.c, transceive.h und transceive_msp.c 
anlegen, compilieren, linken, glücklich sein.

Schwierig dabei ist am ehesten, verschiedene Controllerarchitekturen zu 
verheiraten, in die Abstraktion der in transceive.h deklarierten 
Funktionen muss man ggf. einiges an Hirnschmalz stecken.

Viel Erfolg!

Gruß,

Max

P.S.: #define-Gräber gehen natürlich auch, das macht aber sehr schnell 
gar keinen Spaß mehr.

[cskulkw (Gast)]

In der Automotive-Welt (und sicherlich auch wo anders) nennt das 
Hardware-Abstraction-Layer (HAL)

Ich programmiere schon seit langem so und verbanne hardwareabhängige 
Programmteile in eine Low-Lewel-Treiberdatei und versuche so 
generalisierte Schnittstellen festzulegen. wie Schreibe_spi ; lese_spi ;
setze_Selektion usw.

Gerade externe Controler wie der MCP2515 für CAN benötigen eine 
Reihenfolge von Befehlen. Das ist bei vielen anderen Sensoren und 
Aktoren ähnlich. Diese Reihenfolgen müssen immer von allen 
Implementierungen strikt eingehalten werden. Da ist es doch naheliegend, 
diesen Softwarepart in einem Modul hardwareneutral zu kapseln.


Für die Hardware gilt, dass im Grunde genommen alle nur mit Wasser 
kochen und sich den Schnittstellenstandards unterwerfen müssen. Deshalb 
braucht man nur eine Schublade, wo der Kontroller zugriff - 
Targetabhängig definiert ist.

Über ein übergeordnetes Define wählt man dann die Lowlevel-Treiber für 
Prozessor 1 2 etc. aus. So bleibt die angelegenheit übersichtlich. Man 
hat nur soviel Dateien, wie man Treiber programmiert hat. Außerdem 
erspart man sich die Unübersichtlichkeit der vielen #ifdef ... etc. Bei 
Eclipse geht das ja noch, aber bei anderen Editoren macht das dann 
keinen Spass mehr.

Viel Erfolg und lass mal hören, wie erfolgreich Du warst.

[Mark B. (markbrandis)]

Siehe auch "Adapter Pattern" bzw. Wrapper-Funktionen.

[Klaus S. (skibby)]

Danke für die Antworten, jetzt weiss ich mal wo ich ansetzen kann.
Gibt es irgendein einfaches Referenzprojekt wo man sich die 
Implementierung eines HAL mal anschauen kann ?