C++-Template-Bibliothek für AVR

[Wilhelm M. (wimalopaan)]

Hallo zusammen,

ich habe beschlossen, sowohl meine HW für Projekte (werde nur noch SMD 
machen) zu ändern, als auch meine eigene AVR-C-Bib zu erneuern. Ich 
werde die alte
C-Bib durch eine C++-Template (header-only) Bib ersetzen. Da ich beim
googlen auf wenig aktuelles / brauchbares gestoßen bin, nun hier die 
Frage, wer mir hier ggf. noch einen Tip geben kann, was man sich evtl 
anschauen sollte.

VG
 Wilhelm

[Oliver S. (oliverso)]

???

Machs einfach. Dazu brauchst du dir gar nichts anzuschauen.
Hier im Forum gibt es den ein paar Beiträge mit solchen Ansätzen, dank 
etwas der rudimentären Suchfunktion sind die allerdings nicht ganz 
einfach zu finden.

Oliver

[Eric B. (beric)]

Wilhelm M. schrieb:
> einen Tip geben kann, was man sich evtl anschauen sollte.

Dieses Buch: http://www.springer.com/us/book/9783642429156
Und hier im Forum disen Thread: 
Beitrag "C++ auf einem MC, wie geht das?"

[D. F. (Firma: EDF) (derdan)]

Gute Idee,

ich habe mal an einem System gearbeitet welches Templates teilweise 
einsetzt. Andere Teile sind als Komponenten ausgelegt, bei denen auch 
darauf geachtet wurde die Abhängigkeiten unter einander durch verbinden 
über Pointer zu realisieren. Wodurch die Module sehr schön zu Testen und 
zu Warten wurden. Allerdings haben Pointer den Nachteil dass sie im RAM 
gespeichert werden. Dies könnte man über eine Template LIB vermeiden.
Im Idealfall kann man eine Art Baukastensystem erstellen, Bei dem man 
gewünschte Teile auf einer höheren Abstraktionsebene zusammensetzt um 
ein System zu erhalten.
Dein Projekt würde ich daher gerne verfolgen.

DerDan

[Eric B. (beric)]

Ich schrieb:

> Beitrag "C++ auf einem MC, wie geht das?"

Und in dem Thread gefunden: https://code.google.com/archive/p/savr/

Ich glaube das ist schon das was du suchst.

[Torsten R. (Firma: Torrox.de) (torstenrobitzki)]

Hallo Wilhelm,

Wilhelm M. schrieb:

> Frage, wer mir hier ggf. noch einen Tip geben kann, was man sich evtl
> anschauen sollte.

Diese Talks von der Meeting C++ könnten ganz inspirierent sein:

https://www.youtube.com/watch?v=k8sRQMx2qUw
https://www.youtube.com/watch?v=AKAYc9ZFBhk
https://www.youtube.com/watch?v=FnGCDLhaxKU

Ich habe eine Bluetooth LE library in C++ geschrieben:

https://github.com/TorstenRobitzki/bluetoe

Der Link hier hat mir bei der Arbeit mit GCC und bare metal jede Menge 
Zeit gespart: 
https://www.gitbook.com/book/arobenko/bare_metal_cpp/details

Ansonsten denke ich, dass man in einer Library, die relativ viel 
Plattform-Unabhängig abstrahiert, bei den Funktionalitäten sehr weit 
oben ansetzen muss. Also keine Pins + Timer, aus denen ich mir dann 
einen PWM zusammen bauen kann, sondern die Abstraktion muss der PWM sein 
und wenn ich auf der Zielplattform kein PWM habe (oder nicht genügend), 
dann kann die Library das immer noch mit einem Timer selbst 
implementieren. Im Ideallfall hat die Zielhardware aber PWM peripherals 
und kann das direkt darauf Mappen.

So etwas lässt sich deutlich einfacher in C++11/14/17 implementieren 
(constexpr, variadic templates etc.). Leider schließt man damit dann die 
in der embedded Welt relativ populären Compiler wie IAR und Keil aus.

mfg Torsten

[Wilhelm M. (wimalopaan)]

Hallo Torsten,

danke für die Hinweise: das Buch kannte ich in der Tat noch nicht!

Er wird (wenn überhaupt) etwas ab C++17 (bzw. C++1z derzeit) aufwärts 
geben. Das mache ich im non-embedded Umfeld auch - alles andere möchte 
ich einfach
nicht mehr!

Wenn ich ein bißchen was zusammen habe, gibts hier den Link auf das Repo 
...

VG
 Wilhelm

[MCUCPP (Gast)]

C++-Template Bib
****************
https://github.com/KonstantinChizhov/Mcucpp

C++14 AtmelStudio
*****************
Beitrag "Re: ASF und C++ im Atmel Studio 7"
Beitrag "Re: DCF77 Uhr in C mit ATtiny26"

[MCUCPP (Gast)]

C++14 AtmelStudio
*****************
Beitrag "Re: (dauerhaft) aktuelle Toolchain"

[Jack (Gast)]

Gute Sache - zur maximalen Verwirrung des Programmierers.

Halt, eigentlich gibt es für eine C++ Template-Bibliothek zwei Klassen 
von Programmierern:

1. Der Entwickler der Bibliothek, der zeigen will was für ein toller 
Hecht er ist.

2. Opfer, die die Bibliothek aus irgendeinem Grund benutzen müssen oder 
wollen. Die sich dann mit den wunderbaren Fehlermeldungen bei 
Template-Problemen herumschlagen müssen. Die höllisch aufpassen müssen, 
dass dem C++-Compiler die Codegenerierung halbwegs gelingt und nicht 
irgendein interessantes Feature von C++ dazwischenfunkt. Die den 
besonderen Spass genießen mit einem Debugger Template-Code in 
Einzelschritten abzuarbeiten.

Jau, und das alles um ein paar Bits in ein paar lächerlich einfachen 
AVR-Registern so kompliziert wie möglich zu setzen. Auf der nächsten 
Maker-Party ist man damit sicher der Held.

[Oliver S. (oliverso)]

Na ja, einer der wesentlichen Vorteile des AVR in diesem Zusammenhang 
ist, daß da eh kaum einer drauf debugt. Der Nachteil ist also achonmal 
keiner ;)

Oliver

[Wilhelm M. (wimalopaan)]

Ich möchte weder zeigen, dass ich ein toller Held bin, noch möchte ich 
andere zu Opfern machen! Also bitte, lasst wenigstens diesen Thread frei 
von Polemik.

Ich kann verstehen, dass C++ nicht jedermanns Sache ist. Wer Konstrukte 
wie die folgenden nicht mag, der sollte sich hier zurückhalten:

#include "mcu.h"
#include "timer.h"
#include "usart.h"
#include "event.h"
#include "ports.h"

int main()
{
    EventManager<Timer8Bit<0>>::start();

    PortB::Set(0);

//    Usart<0>::init();
    Usart<0, 64, ATMega8>::init();

//    uint8_t byte;
//    auto ok = Usart<0>::getc(byte);

    if (auto ok = Usart<0>::getc()) {
        uint8_t b = *ok;
    }

    get<ATMega8::Port, C>()->ddr = 0xff;
    get<ATMega8::Port, C>()->out = 0;
    get<ATMega8::Port, B>();

    EventManager<Timer8Bit<0>>::run();
}

VG
 Wilhelm

[D. F. (Firma: EDF) (derdan)]

Deinen Code

EventManager<Timer8Bit<0>>::start();

Könntest du über Typedef lesbarer schreiben:

typedef EventManager<Timer8Bit<0>> CyclicTimer;

CyclicTimer::Init();
CyclicTimer::Start();
CyclicTimer::Run();

[Oliver S. (oliverso)]

Wilhelm M. schrieb:
> get<ATMega8::Port, C>()->ddr = 0xff;

Solchen Code mag ich tatsächlich nicht. Bezüglich Wiederverwendbarkeit 
ist das ja wirklich nicht schön. Zumindest der Zielprozessor sollte 
schon, wenn überhaupt erforderlich, nur an einer einzigen Stelle des 
Programms definiert wenn müssen. Noch schöner wäre es, wenn das 
automatisch irgendwo in einem Systemheader passieren würde.

Aber da lässt sich mit ein paar weiteren typedefs noch was retten.

Oliver

[Wilhelm M. (wimalopaan)]

Es freut mich, wenn jemand tatsächlich den Code liest und sich Gedanken 
macht.

Mittlerweile geht es so:

using PortB = Port<DefaultMcuType::PortRegister, B>;

Das get<>() Funktionstemplate ist im öffentlichen API überflüssig 
geworden... (das Ganze ist auch erst 1 Tag alt)

VG