avr-libc alternativen

Falk Schilling schrieb:
> Vielleicht könntest du einfach objektorientiert mit C programmieren?
Das will man doch nur wenns gar nicht anders geht, in C++ ist das doch 
viel eleganter und sicherer...

Christoph Wiesmeier schrieb:
> Ist für micht nicht wirklich vergleichbar, da ich weniger die
> Objektorientierung von C++ verwende, sondern in erster linie operator
> overloading, namespaces, und besonderen Templates.

All das funktioniert doch. Dafür braucht es ja keine Standard-lib, das 
macht alles der Compiler.

Oliver

Selbst dynamischer Speicher ist ja nicht wirklich ein Problem. Man muß 
halt eine eigene new- und delete-Implementierung beistellen, dann klappt 
das auch. Da gibts hier im Forum und auch ausserhalb in den schon 
mehrfach geführten Diskussionen zum C++ auf dem AVR Vorschläge.

Oliver

Wasle schrieb:
> einem größeren projekt bei dem ich vorhabe einen
> ATxmega controller

Tu es nicht. Nimm einen anderen Controller mit den gleichen Specs.

Wasle schrieb:
> Der letzte versuch mit c++ typte_traits zu arbeiten hat mich dazu
> gebracht boost ein zu binden,

Ich muss das jetzt ganz ernsthaft fragen: Weißt du eigentlich, was du 
tust? Also, hast du echte Erfahrung mit Mikrocontrollern der Größe des 
Xmegas in einer Freestanding-Umgebung?

Weil, dass klingt alles so wie Großer Hacker will es einem kleinen 
Microcontroller mal so richtig zeigen und die große Welt erklären. Wenn 
du type_traits bei einem Microcontroller wie dem XMega brauchst, dann 
hast du entweder den Überblick über deinen Code verloren (ganz schlecht 
beim Embedded-Programmieren), oder du willst eine Show abziehen um zu 
zeigen was für cleveren Code du schreiben kannst (der dann zwar schlecht 
wartbar ist, aber Hauptsache clever und trickreich geschrieben ...).

Oben drauf dann noch Boost? Weil? Ja, warum eigentlich? Weil man zuviel 
Platz in einem uC hat? Weil da ganz tolle, clevere Funktionen drin sind, 
die man nie-nicht selber, in einfacher, verständlicher, wartbarer, 
nachvollziehbarer Weise programmieren kann? So wie 
Template-Metaprogramming (hust, hust)? Weil semi-nichtdeterministische 
dynamische Speicherverwaltung in einem uC so viel Spaß macht?

Franz schrieb:
> Wasle schrieb:
>> einem größeren projekt bei dem ich vorhabe einen
>> ATxmega controller
>
> Tu es nicht. Nimm einen anderen Controller mit den gleichen Specs.

Tu es nicht. Nimm einen anderen Controller mit deutlich erweiterten 
Specs ;)

Full-Size C++ in der Variante 11 mit allem, was die Sprache hergibt, 
wird auf Mikro-Mikros nichts. Nimm dir einen ausgewachsenen ARM, und 
alles wird gut.

Oliver

Oliver schrieb:
> Full-Size C++ in der Variante 11 mit allem, was die Sprache hergibt,
> wird auf Mikro-Mikros nichts. Nimm dir einen ausgewachsenen ARM, und
> alles wird gut.
C geht aber auch nicht auf AVR's, denn malloc,free,fopen,system gehen 
auf denen auch nicht so gut.

Malte schrieb:
> Wenn
> du type_traits bei einem Microcontroller wie dem XMega brauchst
Was haben type_traits mit der Zielplattform zu tun? Wenn man 
generischen, wiederverwendbaren Code schreiben möchte sind diese sehr 
hilfreich. Da sie ja onehin nur zur Compiletime agieren, sind sie nicht 
vom Speicher des Targets abhängig. Warum sollte zB so eine Hilfsfunktion 
auf XMega grunsätzlich schlecht sein?

1

template <typename T>

2

stm32_always_inline T mask (const uint8_t count) {

3

  return (T { 1 } << count) - 1;

4

}

5

6

template <typename T>

7

using Plain = typename std::remove_reference<typename std::remove_volatile<T>::type>::type;

8

9

template <typename T>

10

inline void setBits (T& reg, const uint8_t bit, const uint8_t size, const Plain<T> val) {

11

  const Plain<T> bmask = mask<Plain<T>> (size);

12

  const Plain<T> base = reg & ~(bmask << (size * bit));

13

  reg = base | (val << (size * bit));

14

}

15

16

int main () {

17

  // Setze Bits 7-9 vom Register auf 5.

18

  setBits (someHardwareRegister, 7, 3, 5);

19

}

So kann man im User-Code recht praktisch einzelne Bits von Registern 
setzen, unabhängig von der Registergröße. Dank inline und 
Compiler-Optimierungen wird das auch schön kurz und effizient.
Dabei werden C++11 Features und type_traits verwendet.
Warum habe ich jetzt den Überblick über meinen Code verloren?

Malte schrieb:
> Oben drauf dann noch Boost? Weil? Ja, warum eigentlich? Weil man zuviel
> Platz in einem uC hat? Weil da ganz tolle, clevere Funktionen drin sind,
> die man nie-nicht selber, in einfacher, verständlicher, wartbarer,
> nachvollziehbarer Weise programmieren kann? So wie
> Template-Metaprogramming (hust, hust)? Weil semi-nichtdeterministische
> dynamische Speicherverwaltung in einem uC so viel Spaß macht?
Hier gilt das selbe wie für type_traits; die Boost MPL z.B. verbraucht 0 
bytes Flash und 0 Bytes RAM, keine dynamische Speicherverwaltung, und 
kann einem beim Aufbau von Funktionen wie oben oder anderer 
Metaprogrammierung sehr helfen. Natürlich kann man das auch selber 
programmieren, aber wozu, wenn man auch die fertige Implementation der 
boost verwenden kann? Warum soll die etablierte boost Library nicht 
wartbar oder wiederverwendbar sein?

Malte schrieb:
> So wie
> Template-Metaprogramming (hust, hust)? Weil semi-nichtdeterministische
> dynamische Speicherverwaltung in einem uC so viel Spaß macht?
Wieso braucht mein obiges template Metaprogrammierungs-Beispiel 
semi-nichtdeterministische Speicherverwaltung?

Jörg Wunsch schrieb:
> system ist sowieso nicht portabel.
system ist laut C-Standard vorhanden.
> Ansonsten: malloc und free, ausprobiert (welche Bugs sind dir übern
> Weg gelaufen?), oder plapperst du nur nach?
Pingelalarm? Klar funktionieren tun die, nur ob das bei 2 KB RAM 
wirklich sinnvoll sind ist... kontrovers.

Dr. Sommer schrieb:
> Was haben type_traits mit der Zielplattform zu tun? Wenn man
> generischen, wiederverwendbaren Code schreiben möchte

Die Mär vom wiederverwendbaren Code ...
Die Realität sieht anders aus. Selber macht man das dann doch nicht, 
weil der Code woanders dann nicht ganz passt oder - sehr beliebt - weil 
man den eigenen cleveren Code später selber nicht mehr versteht.

Andere nehmen den Code auch nicht, weil der nicht richtig dokumentiert, 
getestet und verständlich ist.

Und so ist all der schöne Aufwand, den man in die Wiederverwendbarkeit 
gesteckt hat für die Katz.

> sind diese sehr
> hilfreich. Da sie ja onehin nur zur Compiletime agieren, sind sie nicht
> vom Speicher des Targets abhängig. Warum sollte zB so eine Hilfsfunktion
> auf XMega grunsätzlich schlecht sein?template <typename T>
> stm32_always_inline T mask (const uint8_t count) {
>   return (T { 1 } << count) - 1;
> }
>
> template <typename T>
> using Plain = typename std::remove_reference<typename
> std::remove_volatile<T>::type>::type;
>
> template <typename T>
> inline void setBits (T& reg, const uint8_t bit, const uint8_t size,
> const Plain<T> val) {
>   const Plain<T> bmask = mask<Plain<T>> (size);
>   const Plain<T> base = reg & ~(bmask << (size * bit));
>   reg = base | (val << (size * bit));
> }
>
> int main () {
>   // Setze Bits 7-9 vom Register auf 5.
>   setBits (someHardwareRegister, 7, 3, 5);
> }So kann man im User-Code recht praktisch einzelne Bits von Registern
> setzen, unabhängig von der Registergröße. Dank inline und
> Compiler-Optimierungen wird das auch schön kurz und effizient.
> Dabei werden C++11 Features und type_traits verwendet.
> Warum habe ich jetzt den Überblick über meinen Code verloren?

Das ist genau die Art von Angeber-Code den ich meine. Ja, kann man 
machen. Bringt einem aber nicht weiter gegenüber einfachem C, nur dass 
man der Welt mal gezeigt hat, dass man in der Lage ist die 
weltkomplizierteste setBits()-Funktion zu schreiben. Gratulation.

Malte schrieb:
> Und so ist all der schöne Aufwand, den man in die Wiederverwendbarkeit
> gesteckt hat für die Katz.
Wenn du es nicht hinbekommst, vielleicht. Ich kann meinen Code wunderbar 
dokumentieren, verstehen und wiederverwenden.

> Das ist genau die Art von Angeber-Code den ich meine. Ja, kann man
> machen. Bringt einem aber nicht weiter gegenüber einfachem C, nur dass
> man der Welt mal gezeigt hat, dass man in der Lage ist die
> weltkomplizierteste setBits()-Funktion zu schreiben. Gratulation.
Nur weil du sie nicht verstehst? Wie würdest du das denn in einfachem C 
machen? Mit einem langen hässlichen Makro in einer Zeile, mit all den 
ekligen bekannten Nebenwirkungen?

Jörg Wunsch schrieb:
> Es gibt auch inline-Funktionen, wenn dir Makros zu hässlich sind.
Aber die haben in C feste Parametertypen (C kann keine Templates und 
kein Overloading).
> Ansonsten ist das Bitgewurschtel sowieso immer auf der untersten
> Abstraktionsebene, und das ist genau die, die man beim Wechsel der
> Plattform austauschen muss.
Kommt drauf an, dieser Code ist ziemlich generisch.
> Da kann man dann (was dein Code nicht
> kann) auch gleich noch berücksichtigen, ob die Zielplattform zum
> Setzen eines Bits vielleicht ein eigenständiges "bit-set"-IO-Register
> hat (ARM, Xmega).
Das würde ich auf noch einer Ebene drunter machen, auf der 
Hardware-Zugriffs-Ebene, und nicht auf der Bitverarbeitungsebene. Aber 
auch wenn nicht, dieser Code ist doch dann ein hübsches Interface, unter 
dem man die Implementierung abändern kann (Wiederverwendbarkeit des 
darauf aufsetzenden Codes).
> Was willst du hier eigentlich?
Dem "Malte" erläutern, dass C++(11) und type_traits nicht grundsätzlich 
schlecht auf Mikrocontrollern ist, auch nicht auf kleinen AVR's.
>  Zuerst willst du uns erzählen, dass man
> C auf einem Controller nicht benutzen kann, weil es dort kein system()
> gibt, und dann tust du so, als könnte man sowas nur programmieren,
> indem man mit den neuesten C++11-Features nur so um sich wirft.
Das mit C war natürlich ein Vergleich, weil ja behauptet wurde, dass man 
C++ grundsätzlich nicht verwenden kann, weil einige der Features nicht 
"Mikrocontroller-geeignet" sind; mit der gleichen Logik wäre C dann aber 
auch ungeeignet.
Man kann natürlich auch alles in Assembler oder Brainf*ck programmieren, 
aber Features von höheren Sprachen wie C und C++ (C++11 erst recht) 
helfen dabei.

Jörg Wunsch schrieb:
> Wie willst du das eine Ebene drunter machen, wenn es um Dinge wie ein
> Register zum Setzen von Bits geht (also sowas wie PORTA->OUTSET)?
Es wäre zB. denkbar, sich eine Wrapper-Klasse für Register zu 
definieren, die die Operatoren |, &, ^, = überlädt, und sich somit 
(fast) wie eine Register-Variable verhält, aber bei den Operationen 
entsprechende Bitmasken konstruiert und diese beim zuweisen verwendet, 
um die Register atomar per Bit-Banding o.ä. zu setzen. Dann würde man 
Instanzen dieser Klasse anstelle der Register-Definitionen verwenden. 
Die Berechnungen würde man mit constexpr und inline zur Compile-Zeit 
durchführen. Die innere Implementation wäre dann Plattform-Spezifisch 
(bit-banding bei ARM, sbi/cbi bei AVR etc.). Code, der diese Klasse 
nutzt könnte dann plattformunabhängig effizient atomare Register 
verwenden mit (fast?) "nativer" Syntax. O.g. setBits-Funktion könnte man 
vermutlich unverändert auch auf Instanzen davon anwenden ("statische 
Polymorphie" / "Concept").