Hardware Abstraction Layer

Columbo

Andromeda schrieb:

Weniger ist mehr.
C schlägt C++.
Jedenfalls immer dann, wenn Speicherbedarf und Taktfrequenz eine Rolle spielen.

Bist du bescheuert?

Andromeda

Arcoth schrieb:

Andromeda schrieb:

Weniger ist mehr.
C schlägt C++.
Jedenfalls immer dann, wenn Speicherbedarf und Taktfrequenz eine Rolle spielen.

Bist du bescheuert?

Klar doch,

fenrayn

Weniger ist mehr. 
C schlägt C++. 
Jedenfalls immer dann, wenn Speicherbedarf und Taktfrequenz eine Rolle spielen. 
Und das ist bei Embedded Systems fast immer der Fall.

Also die Erfahrung habe ich bisher noch nicht gemacht, eher im Gegenteil

Torsten Robitzki

fenrayn schrieb:

Ist diese Vorgehensweise üblich? Ich finde leider sehr wenig Ressourcen im Netz zu dem Thema

Ich denke, dass wird der Weg sein, den wir gehen sollten. Was bei Deiner Lösung noch fehlt, ist die Berücksichtigung von globalen Initialisierungen (peripheral clocks) und die Berücksichtigung von konkurrierenden Recourcen-Belegungen (z.B. dass ein Pin nicht gleichzeitig als GPIO und als Anschluss für irgend ein Peripheral genutzt werden kann).

Dazu müsste man die gesamte Controller-Nutzung der Library zur Verfügung stellen, dann wüsste die, welche Ports verwendet werden und wie die Initialisierung aussehen muss.

Ich hatte das mal in einem Projekt ausprobiert, dabei ist dann so etwas heraus gekommen:

typedef hammer::gpio::output_pin< device::P0_30 > puls;
typedef hammer::gpio::output_pin< device::P0_15 > ami_enabled;

typedef hammer::gpio::output_pin< device::P0_08, hammer::gpio::inverted, hammer::gpio::toggle > green_led;
typedef hammer::gpio::output_pin< device::P0_09, hammer::gpio::inverted > red_led;

typedef hammer::gpio::output_pin< device::P0_21, hammer::gpio::toggle > debug_pin;

typedef hammer::timer::interval_timer<
    base_timer_interval,
    hammer::callback_member< device_logic, &device_logic::timer_callback, &logic > > main_timer;

typedef hammer::serial::i2c_master<
    hammer::serial::scl_pin_with_pullup< device::P0_01 >,
    hammer::serial::sda_pin_with_pullup< device::P0_02 >,
    hammer::serial::i2c_bus_speed_400k > i2c_master;

typedef radio_receiver radio;

typedef lm75a< i2c_master > temperatur_sensor;

struct hardware : hammer::device< hardware, device > {
    typedef boost::mpl::vector< red_led, green_led, debug_pin > debug_pins;
    typedef boost::mpl::vector< puls, debug_pins > pins;

    typedef boost::mpl::vector<
        pins,
        main_timer,
        i2c_master,
        temperatur_sensor
    > peripherals;
};

Dabei müsste man einen Ansatz wählen, die gewünschte Funktionseinheit sehr konkret und auf höchstem Level zu beschreiben, sodass sich die Library eine passende Implementierung mit den zur Verfügung stehenden pheriperals zusammen suchen kann.

Hier noch ein Talk von der Meeting C++ von 2014 zum Thema: https://www.youtube.com/watch?v=k8sRQMx2qUw

Hier habe ich einen C++ Bluetooth LE stack, der auf einem Cortex-M0 läuft und mit sehr wenig resourcen auskommt, das geht in etwas in die selbe Richtung: https://github.com/TorstenRobitzki/bluetoe

mfg Torsten

Andromeda

fenrayn schrieb:

Weniger ist mehr. 
C schlägt C++. 
Jedenfalls immer dann, wenn Speicherbedarf und Taktfrequenz eine Rolle spielen. 
Und das ist bei Embedded Systems fast immer der Fall.

Also die Erfahrung habe ich bisher noch nicht gemacht, eher im Gegenteil

C ist gewissermaßen sowas wie eine portable Assemblersprache. Für einen HAL gibt es quasi nicht Besseres.

In C++ kanst du zu 99.9% Plain-C programmieren, wenn du willst. Von daher kann man nicht sagen, dass C++ irgendwie weniger geeignet ist.

Problematisch wird es aber immer dann, wenn man die erweiterten Features von C++ einsetzen will. Du siehst ja selbst, auf welche Hindernisse du stößt. Aber vielleicht ist es ja gerade diese intellektuelle Herausforderung, die dich besonders anspornt.

Torsten Robitzki

fenrayn schrieb:

Weniger ist mehr. 
C schlägt C++. 
Jedenfalls immer dann, wenn Speicherbedarf und Taktfrequenz eine Rolle spielen. 
Und das ist bei Embedded Systems fast immer der Fall.

Also die Erfahrung habe ich bisher noch nicht gemacht, eher im Gegenteil

Das Problem ist eher, dass im Embedded Bereich wenige ausgebildete SW-Entwickler arbeiten. Die meisten sind E-Techniker, die da mehr oder weniger rein geworfen wurden. Mit wachsenden Projektgrößen wird die Notwendigkeit von Abstraktionen bestimmt noch weiter steigen und da hat C wenig zu bieten (vor allem, wenn es keine Recourcen kosten darf).

Torsten Robitzki

Andromeda schrieb:

Problematisch wird es aber immer dann, wenn man die erweiterten Features von C++ einsetzen will.

Naja, es gibt sehr viele features in C++, die überhaupt keine Ressourcen kosten (bzw. nur welche kosten, wenn man das feature auch verwendet) und C++ genau deshalb zur besseren Wahl für embedded systems machen:

- namespaces
- templates
- strenger Typenprüfung
- gezieltere casts
- class enums
- Verhinderungen von narrowing conversions ({})
- constexpr
- const
- constructors
usw.

mfg Torsten

fenrayn

Problematisch wird es aber immer dann, wenn man die erweiterten Features von C++ einsetzen will. Du siehst ja selbst, auf welche Hindernisse du stößt. Aber vielleicht ist es ja gerade diese intellektuelle Herausforderung, die dich besonders anspornt.

Ja natürlich, wenn ich OO programmiere, ist dies mit gewissen Overhead verbunden, aber ich kann ja auch in C OO programmieren ... das ist also keine Frage der Programmiersprache, sonders des Konzepts. Verwendet man Sachen wie RTTI oder Exceptions, dann kann es schon mal dazu führen das der C Code schneller ist als der äquivalente C++ Code. Aber da ich diese Features beim Compiler eh komplett deaktiviert habe, mach ich mir da keine Sorgen.

Großes Potential besonders für den Embedded Bereich sehe ich für C++ in Templates/Metaprogrammierung, constexpr und Lambdas. Inline-Funktionen und Const sind ja auch schon eine weile im C-Standard.

Auch wenn ich für den PC programmiert habe stand ich immer dem Dilemma: Performance oder Flexibilität. Meine Hoffnung ist, dass ich dieses Dilemma mit den oben genannten C++ Features nicht mehr habe.

Das Problem ist eher, dass im Embedded Bereich wenige ausgebildete SW-Entwickler arbeiten. Die meisten sind E-Techniker, die da mehr oder weniger rein geworfen wurden.

Da ich gerade am Ende meines E-Technik Studiums bin, kenne ich dieses Phänomen Was wir an der Hochschule an Programmiertechniken gelernt haben war nen Witz. Kein C++, nur "einfaches" C, und je nach Vertiefungsrichtung durfte man noch ein wenig Java für Webanwendungen (LOL) lernen^^

Andromeda

Torsten Robitzki schrieb:

Das Problem ist eher, dass im Embedded Bereich wenige ausgebildete SW-Entwickler arbeiten. Die meisten sind E-Techniker, die da mehr oder weniger rein geworfen wurden.

Ja, das sehe ich auch so.

Wobei in den letzen 5-10 Jahren durchaus eine Tendenz spürbar ist, für die Softwareentwicklung eher Informatiker und ähnliche Code-Monkeys anzuheuern.

Das hängt wohl auch mit dem erweiterten Leistungsspektrum moderner MCUs zusammen. Daher lässt sich inzwischen auch bei Embedded Devices zwischen hardwarenaher Programmierung und "Userland" trennen.

fenrayn

@Torsten:
Alle Pins in einem Enum anzugeben finde ich interessant. Vllt. werde ich das auch so übernehmen.

Was bei Deiner Lösung noch fehlt, ist die Berücksichtigung von globalen Initialisierungen (peripheral clocks) und die Berücksichtigung von konkurrierenden Recourcen-Belegungen (z.B. dass ein Pin nicht gleichzeitig als GPIO und als Anschluss für irgend ein Peripheral genutzt werden kann)

Das ein Pin zur selben Zeit von zwei unterschiedlichen Modulen verwendet wird sollte auf jeden Fall vermieden werden, aber es soll schon die Möglichkeit geben einen Pin zu muxen.

Torsten Robitzki

fenrayn schrieb:

Das ein Pin zur selben Zeit von zwei unterschiedlichen Modulen verwendet wird sollte auf jeden Fall vermieden werden, aber es soll schon die Möglichkeit geben einen Pin zu muxen.

Das war auch nur ein Beispiel, warum ich der Meinung bin, dass das ganze am besten funktionieren wird, wenn man so einer Library die gesamte "Wahrheit" mitteilt. Wenn die die Möglichkeit hätte, konkurrierende Ressourcenverwendung anzuzeigen, dann sollte es auch möglich sein, Ihr mitzuteilen, dass das an der Stelle so gewollt ist.

Columbo

Andromeda schrieb:

C ist gewissermaßen sowas wie eine portable Assemblersprache. Für einen HAL gibt es quasi nicht Besseres.

Das reicht nicht. Damit C die bessere Wahl ist, muss die Größe der ausführbaren Datei eine große Rolle spielen - das ist das einzige Kriterium, was mir auf die Schnelle einfällt, um überhaupt irgendeinen Einsatz von C per se zu rechtfertigen. Und selbst dort kann ein C++ Compiler optimieren ( -Os , -s & UPX). Es gibt auch einen Grund für die Definition von "freestanding implementation".

In C++ kanst du zu 99.9% Plain-C programmieren, wenn du willst.

Oder man kann sich der Vielfalt an Abstraktionen bedienen, die Programmieren um einiges Erleichtern. Mein Vorposter hat ja schon einiges erwähnt. Wenn dir das nicht relevant scheint, bist du eben bescheuert, daher die Frage.

Problematisch wird es aber immer dann, wenn man die erweiterten Features von C++ einsetzen will. Du siehst ja selbst, auf welche Hindernisse du stößt. Aber vielleicht ist es ja gerade diese intellektuelle Herausforderung, die dich besonders anspornt.

Nix ist "problematisch". Wenn sowohl die Variable als auch die entsprechenden Funktionen als constexpr deklariert werden, wird der Compiler all die Funktionsaufrufe mit Sicherheit weg optimieren. Und bei der Template-Lösung gab es überhaupt keine Probleme. Du scheinst überdies außer Acht zu lassen, dass jedes unproblematische Feature von C++ (was praktisch fast alle sind) einen weiteren, womöglich großen Nutzen für den Programmierer darstellt. Keine Last.

Im Übrigen hat dein C Fundamentalismus in diesem Jahrzehnt wenig verloren.

Arcoth schrieb:

Im Übrigen hat dein C Fundamentalismus in diesem Jahrzehnt wenig verloren.

http://www.tiobe.com/tiobe_index

fenrayn

Die Statistik ist ja jetzt sehr allgemein gehalten. Mich würde mehr Interessieren, wie es im Embedded Bereich aussieht!

http://spectrum.ieee.org/static/interactive-the-top-programming-languages-2015

Besser?

Torsten Robitzki

ieee schrieb:

http://spectrum.ieee.org/static/interactive-the-top-programming-languages-2015

Du würdest Dich bei der Wahl eines Werkzeuges eher an Statistiken, als an Argumenten orientieren? Warum?

Und wann habe ich das gesagt? Genau, gar nicht. Hör also auf, hier Unsinn zu schreiben.

Torsten Robitzki

ieee schrieb:

Und wann habe ich das gesagt? Genau, gar nicht. Hör also auf, hier Unsinn zu schreiben.

Genau, weil ich Deine Einwerfen dieser Statistiken nicht verstanden habe, habe ich gefragt, warum Du diese Statistiken hier in die Diskussion wirfst.

Wo habe ich da gesagt, dass Du etwas gesagt hast? Ich habe Dich etwas gefragt. Vielleicht solltest Du dich mal nicht so schnell, persönlich auf den Schlips getreten fühlen?

mfg Torsten

fenrayn

Mich interessiert einfach der Trend. Für die Auswahl spielt das erstmal keine Rolle, aber vllt. lohnt es sich mal genauer nachzuschauen warum eine bestimmte Sprache einen hohen Trend aufweißt.

Ich bin mal gespannt wie lange es dauert, bis sich eine Sprache mit besserer Meta-Programmierung durchsetzt. Die C++ Metaprogrammierung war ja eher ein glücklicher Zufall. Ich denk da an sowas wie VHDL und "generate". Wobei sich die Frage stellt, ob es überhaupt "besser" umgesetzt werden kann, als in C++ ...

fenrayn

Das D mit fast 50% vertreten ist finde ich jetzt schon etwas überraschend