C++ mit WinAvr

[Johngo (Gast)]

Hi,
wie kann ich mit WinAvr C++ Programme für AVRs schreiben? Müssen dazu
z.B. irgendwelche Optionen im Makefile eingestellt werden?
danke,
Johngo

[Josef Zimmermann (Gast)]

Hi

warum C++ auf einem AVR? Irgendwie fehlt mir da etwas das Verständnis.
Welche Vorteile versprichst Du Dir davon?

Die ganzen Anregungen zu C++ auf kleinen uCs stammen nach meiner
Erfahrung bisher lediglich aus den Marketing- oder Personalabteilungen,
aber nicht von den Entwicklern.

[A.K. (Gast)]

Das sehe ich anders und verwende C++ auf AVR.

Nur kann ich nicht mit einem passenden Makefile dienen, weil ich das
vorhandene nach gewissen schlechten Erfahrungen durch eine
selbstgestrickte dmake-Version ersetzt hab (kenne ich besser).

Das normale Makefile neigt dazu, bei C++ den Quellcode aus dem Weg zu
räumen. Also Vorsicht!

[Josef Zimmermann (Gast)]

@A.K.
Das Du das anders siehst ist gut und schön. Aber kannst Du auch die
Gründe dafür nennen. Es würde mir wirklich interessieren, weil mir
bisher die Vorteile nicht klar sind.

Warum sollte make den Quellcode löschen?

C++:
Unter Linux würde ich einfach den Compiler mit g++ aufrufen. Allerdings
habe ich gerade kein Windows laufen und weiß daher nicht wie das unter
WinAVR aussieht.

[Johngo (Gast)]

@J.Z.:
C++, um die Vorteile einer objektorientierten Sprache zu nutzen, z.B.
bessere Strukturierung des Programmcodes, bessere Datenkapselung,
Vererbung,... . Und in vernünftigen Maßen und an den richtigen Stellen
eingesetzt, sollten eigentlich durch C++ auch nicht sehr viel
zusätzliche Rechenpower und Speicher nötig sein.

[A.K. (Gast)]

"Warum sollte make den Quellcode löschen?"

Weil da eine Regel drin ist, die bei "make cleanup" oder so aehnlich
praktisch alles ausser dem Quelltext löscht. Unter der Annahme dass der
Quelltext ".c" heisst. Heisst er aber nicht.

Einfachster Weg also: Als .c bezeichnen und per GCC-Option trotzdem als
C++ übersetzen.

[Dirk M. (avr-nix)]

Zeige doch ein Sourcecode. Also es würde bei Menues was bringen(?) wie
es bei Windows, aber sonst...?

[A.K. (Gast)]

Stark eingedampftes Beispiel. Kein Zusatzaufwand gegenüber C, kommt hier
auch ohne vtbl aus (weil in meinem Fall nicht nötig, kann aber anderswo
für start/read sinnvoll sein):

class Temp {
    bool  valid () volatile const;
    temp_t  value () volatile const;
};

class DS18x20 : public Onewire, public Temp {
    error_t  start ();
    error_t  read ();
};

class LMx35 : public Temp {
    error_t  start ();
    error_t  read ();
};

Kann man alles auch in C machen. Aber ich finde es so eleganter.

[A.K. (Gast)]

Zweites Beispiel. Datenstrukturen im ROM. Etwas AVR/GCC-spezifisch, weil
dort ja Datenzugriff auf Flash arg hässlich ist.

class PDescr {
    id_t  id () const PURE;
    void *  data () const PURE;
};

id_t
PDescr::id() const
{
    return pgm_read_byte(&d.id);
}

void *
PDescr::data() const
{
    return (void *) pgm_read_word(&d.ptr);
}

[Josef Zimmermann (Gast)]

@A.K.:
- bessere Strukturierung des Programmcodes,
Das ist mehr eine Frage der Selbstdisziplin der Programmierer.

- bessere Datenkapselung,
.dito, manchmal machen Programmierrichtlinien das unmöglich, aber
grundsätzlich klappt das auch in C. (Stichwort Modulare
Programmierung)

- Vererbung,... .
Ja. Das wäre ein Vorteil wenn man es den wirklich benötigt. Da fallen
mir spontan aber nur sehr wenige Anwendungen aus einem Bereich ein.

- zusätzliche Rechenpower und Speicher nötig.
Ja. Häufig das K.O. Kriterium. Bei vielen Projekten ist noch nicht
einmal möglich die stdio Funktionen aus der CLIB einzubinden, weil der
Speicher knapp ist.

Im Prinzip kann C++ alles was C auch kann. Also warum auch nicht.

[Johngo (Gast)]

Natürlich kann man die meiste Funktionalität von C++ auch mit C
irgendwie selberstricken, aber wozu, wenn es einen C++ Compiler gibt,
der das viel schneller, besser und schöner kann.

[Johngo (Gast)]

@A.K.
Welche Compileroptionen verwendest du für C++? Und kannst du mir auch
dein Makefile zukommen lassen?

[mthomas (Gast)]

>Weil da eine Regel drin ist, die bei "make cleanup" oder so aehnlich
>praktisch alles ausser dem Quelltext löscht. Unter der Annahme dass
>der Quelltext ".c" heisst...

Ursache dafuer ist wahrscheinlich die Option "adhlns" im
WinAVR/mfile-makefile. Thread zum Anlass genommen, einen
Aenderungsvorschlag auf Grundlage meiner "WinARM-Vorlage" an den
WinAVR-Macher zu senden. Falls Ursache richtig vermutet, wird der
Vorschlag hoffentlich in die naechste WinAVR-Makefile-Vorlage
uebernommen. Allerdings "beissen" sich einige CFLAGS zumindest mit
dem arm-elf-g++ (hauptsaechlich Warning-Einstellungen), duerfte beim
avr-g++ auch so sein, kann man einfach deaktivieren oder evtl. auch
einen zweiten Satz Optionen einfuehren (einen fuer C und einen fuer
C++). In der WinARM-Vorlage werden C und C++ getrennt abgearbeitet,
ohne die "automatische Umschaltung auf g++" durch das/den
Compiler-Frontend zu nutzen.

[Jörg W. (dl8dtl) (Moderator)]

Das ist glaub' ich nur eine Stelle, es gibt noch eine gleichartige bei
»make clean«.

Die Lösung wäre, dass man nicht mehr so schöne einfache Muster
benutzt, um die .o-(und anderen) -Dateien von den Quelldateinamen
abzuleiten.  Ich muss da auch mal Mfile überarbeiten.