Atmega 8 mit c++ programmieren

[fumir]

die gewünschte kapselung kann man in c mit struct erreichen:

struct meinestruktur
  {
  unsigned int bit1 : 1;
  unsigned int bit2 : 1;
  unsigned int bit3 : 1;
  unsigned int bit4 : 1;
  unsigned int bit5 : 1;
  };

int main() {
...
struct meinestruktur daten;

daten.bit1=1;
daten.bit2=0;

}

die sache hat allerdings nen haken: es kommt auf den compiler bzw. dessen einstellungen an, ob die bits dann wirklich als bits in einem datenbyte gespeichert werden.
prinzipiell darf der compiler auch jedes bit in ein eigenes byte, oder int oder sonstwas speichern. daran ändert aber auch c++ nichts.

du kannst dir natürlich so ne struktur definieren und dazu ne passende funktion, um die daten dann wirklich in die richtige position eines byte zu schreiben. wenns um hardware geht, muss man letztlich immer auf etwas umständliche methoden zzurückgreifen, wenn man in ner hochsprache programmiert (zumindest wenn der code portabel bleiben soll)

der gnu compiler avr-gcc unterstützt einige c++ möglichkeiten (siehe doku). damit kann man sicher das ein oder andere eleganter formulieren als in reinem c. aber an der tatsache, dass du dir bei hardwarezugriff genau anschauen musst, welchen maschinencode dein hochsprachencompiler letztlich erzeugt, kommst du nicht drum rum.
(das kann natürlich schon jemand in irgend ner bibliothek für dich erledigt haben, aber genau hinschauen sollte man trotzdem mal, bevor man so ne bibliothek verwendet)

[fumir]

Wenn das der Fall ist, weißt Du sicher auch, daß Punkt . in C für ganz andere Zwecke gedacht ist, als das was Du möchtest.

wieso?
der punkt ist genau dazu da: auf teile eines größeren datenobjektes zuzugreifen.
in c betrifft das z.b. struct und union.
in c++ wirds dann auch noch für klassen verwendet.

wozu sonst sollte der punkt in c sein?

[ogni42]

Um mal mit ein paar Mythen aufzuräumen:

* Eine vollständige C++ Implementierung verlangt die Standard Bibliothek (nicht die STL). Der avr-gcc hat aber weder das eine noch das andere.
* Klassen benötigen nicht mehr RAM/Flash als structs und Methoden, die darauf zugreifen. Wenn man mit virtuellen Methoden arbeitet, kommt ein Zeiger pro Methode für die vtable hinzu
* Es wird erst dann (RAM)speicherfressend, wenn exceptions verwendet werden sollen (wg. callstack-Verwaltung). Die gibt es mit dem avr-gcc nicht. Beispiel: http://www.mikrocontroller.net/topic/90380#772976

Fazit: Man kann es durchaus mit den avr's verwenden. Es gibt aber gegenüber einer vollständigen C++ Implementierung Einschränkungen (habe ich an anderer Stelle hier im Forum schon mal geschrieben)

[izaseba]

Hallo Fumir,

Ja Du hast recht, an Bitfelder hab ich da nicht gedacht, eher an größere Sachen *schäm*
Du hast auch recht, daß der Kompiler die Felder nach Lust und Laune organisieren kann.

ABER mir fällt da noch was ein!

Code Vision !
Ich glaube in CodeVision ist die Möglichkeit gegeben genauso auf die Bits zuzugreifen.

Vielleicht sollte Ceos sich das mal angucken, es gibt auch eine kostenlose Version die auf 4 oder 2 kB beschränkt ist.

Die Vollversion ist auch bezahlbar.



Gruß Sebastian

P.S. was die Sache mit C++ angeht, gibt es hier einen User 'ehenkes' oder so heißt er, der hat was in diese Richtung gemacht...
Einfach nach "nibo" Suchen, da hat der was gepostet, in meinen Augen sehr Speicherfressend mit malloc usw. , vielleicht ist das eine Anregung...

[fumir]

* Eine vollständige C++ Implementierung verlangt die Standard Bibliothek (nicht die STL). Der avr-gcc hat aber weder das eine noch das andere.

kannst du das mal noch etwas näher erläutern.
ich dachte zu c++ gehören zwingend die üblichen header und damit die STL (die heißt wohl inzwischen anders, oder?) funktionalität.
wo kann man das nachlesen?

[ogni42]

Die STL enthält z.B. keine iostream Bibliothek, die Standard-Bibliothek aber schon.

Näheres z.B. hier:
http://de.wikipedia.org/wiki/C%2B%2B-Standardbibliothek

[fumir]

in wikipedia fand ich folgenden schönen satz:

Unter C++-Programmierern ist der Begriff "STL" trotzdem üblicher Jargon für den aus der ursprünglichen STL abgeleiteten und um Elemente wie Zeichenketten erweiterten Template-basierten Teil der Standardbibliothek.

der meine verwendung des begriiffs STL verdeutlicht. insofern meinten wir das gleiche, wobei ich mich nicht so ganz präzise ausgedrückt habe

gehört nicht ganz hierher, aber ich fand neulich ein beispiel bei dem c++ gerade wegen den klassen und templates kürzeren und effizienteren code erzeugt:
sortieren unter c mit qsort erfordert die übergabe einer vergleichsfunktion mittels zeiger.
in c++ kann man stattdessen ein funktionsobjekt übergeben. dieses kann dann vom c++ compiler inline in den template generierten qsort-code eingefügt werden. dadurch spart man sich zum einen den funktionsaufruf bei jedem vergleich und zum anderen kann der compiler den code weiter optimieren, da nun kein sprung mehr im qsort-code steht.

trotzdem glaube ich nicht das man unbedingt c++ braucht um z.b. nen atmege8 zu programmieren. bei den größeren µC würd ich mich allerdings auch über die c++ funktionalität freuen.