AVR und __property

[Ralf G. (ralg)]

Nach der Lektüre vieler Beiträge hier im Forum über den (Un)Sinn von C++ 
auf AVRs, versuche ich trotzdem mal positiv an diese Sache heranzugehen: 
Kann man eigentlich sowas wie

__property uint8_t x = {read = readX, write = writeX};

für avr-c++ "nachbasteln"?

[Johann L. (gjlayde)]

Ja, GCC ist Freie Software.  Du kannst dir die Quellen nehmen, nach 
belieben verrenken und erweitern und dir dann deinen Compiler daraus 
erzeugen. Voilà.

[Oliver (Gast)]

Das ist weniger ein AVR-Problem, eher ein Problem mit 
Spracherweiterungen außerhalb des C++ Standards.. Google findet einige 
Hinweise zu dem Thema.

Oliver

[Ralf G. (ralg)]

Johann L. schrieb:
> Ja, GCC ist Freie Software.  Du kannst dir die Quellen nehmen, nach
> belieben verrenken und erweitern und dir dann deinen Compiler daraus
> erzeugen. Voilà.
Na, dann werde ich das mal so machen, Viola

Mit "nachbasteln" meinte ich eher einen mehr oder weniger guten 
Würgeraund.
Sonst hätte ich "reinbasteln" für "integrieren" geschrieben.

Oliver schrieb:
> Das ist weniger ein AVR-Problem, eher ein Problem mit
> Spracherweiterungen außerhalb des C++ Standards.
Hm, dacht' ich mir schon.

War halt nur so 'ne Idee von mir.

[Johann L. (gjlayde)]

Ralf G. schrieb:

> Mit "nachbasteln" meinte ich eher einen mehr oder weniger guten
> Würgeraund.

Durch einen Text-Prozessor?  m4 oder was hausbackenes aus perl oder 
python oder awk oder...

[Ralf G. (ralg)]

Johann L. schrieb:
> oder...

#include <avr/io.h>
#include <inttypes.h>

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// __property-Nachbildung
template <class T> class property
{
private:
 T Value;
public:
 void Setter();
 property()
 {
  Value=0;
 };
 property(T i)
 {
  Value=i;
  Setter();
 };
};
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

class cTest
{
public:
 property<uint8_t> Wert;
};

template<> void property<uint8_t>::Setter()
{
 PORTD=Value;
};

cTest Test;


int main()
{

 Test.Wert=PORTB | (uint8_t)42;

 return 0;
}

Bis hierher habe ich mal was probiert.

[Ralf G. (ralg)]

'template' war eine Sackgasse.

Angeregt duch diesen Thread:
Beitrag "C++ für Embedded: ab welchen Prozessormerkmalen?"
und nicht verschreckt durch Yalu X. ;-)
Beitrag "Re: C++ für Embedded: ab welchen Prozessormerkmalen?"
möchte ich mal das hier zur Diskussion stellen:

// Test für z.B. atmega88

#include <avr/io.h>
#include <inttypes.h>

//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
// __property-Nachbildung
#define PROPERTY(type,identifier)   \
class identifier                    \
{                                   \
private:                            \
 type Value;                        \
public:                             \
 void* Parent;                      \
 identifier() { Value=0; };         \
/* Getter, Setter */                \
 operator type() { return Value; }; \
 void operator=(type);              \
}                  
// __property-Nachbildung
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

// Typ(en) für 'property' erzeugen
PROPERTY(uint8_t,uint8_prop);

// weitere Klassen/ Strukturen
class cTest
{
public:
 uint8_t Testvariable;
 uint8_prop Wert;
 cTest()
 {
// für jede 'property'-Variable das Elternelement eintragen
  Wert.Parent=this;
 };
};

// Zuweisungsoperator(en) für 'property'-Typ(en) definieren
void uint8_prop::operator=(uint8_t val)
{
 PORTD=val;
 Value=val+((cTest*)Parent)->Testvariable;
};

cTest Test;
volatile uint8_t x;

int main()
{
 x=99;
 Test.Testvariable=x | PORTC;
 Test.Wert=PORTB | 42;
 x=Test.Wert;

// Test.Wert++;         // sowas geht (noch) nicht! -> '++' implementieren

 Test.Wert=Test.Wert+1; // ist hier natürlich 'gewöhnungsbedürftig',
                        // da im Beispiel 'Wert' ausnahmsweise noch von
                        // 'Testvariable' beeinflusst wird (Demo)

 x=Test.Wert;

 return 0;
}

[cplusplus (Gast)]

Warum ist das weniger Sackgasse als ein Template?
Weil man es "kunstvoll" per Macro nachbaut?

Ich finde das ja immer ganz toll:
"wenn ich die nicht für kleinen Speicher geeigneten Features von C++ 
verwende, dann geht's nicht. Also kann ich C++ nicht verwende!"
Nein, falscher Schluß! Dann muß man das weglassen, was nicht geht!

Was glaubt ihr denn, was von

Test.Wert=PORTB | (uint8_t)42;

übrig bleibt? 3 Befehle:

    lds r16,PORTB
    ori r16,0x2A  ;42
    sts PORTB,r16

Obwohl da Templates, Overloading und ... benutzt werden.

Die "property"'s von MSC ermöglichen es quasi Variablezugriffe zu 
überladen. Statt der Variablen prop, werden jeh nachdem ob 
lesender/schreibender Zugriff deren Setter/Getter-Methoden gerufen, die 
z.B. auch direkt die AVR Flash-/EEPROM-Zugriffsroutinen sein könnten.

[Ralf G. (ralg)]

cplusplus schrieb:
> Warum ist das weniger Sackgasse als ein Template?
> Weil man es "kunstvoll" per Macro nachbaut?
Kann schon sein...

Nur:
Ich kann die Operatoren in Templates für den entsprechenden Datentyp 
überladen. Variablen des selben Datentypes würden dann die gleichen 
Funtionen aufrufen.
Deshalb von mir die Definition eines neuen Datentypes speziell für 
eine Variable. Ob das jetzt besser geht oder man es lassen sollte ... 
ich wollte einfach mal was probieren.

> Was glaubt ihr denn, was von
>    Test.Wert=PORTB | (uint8_t)42;
> übrig bleibt? 3 Befehle:
>    lds r16,PORTB
>    ori r16,0x2A  ;42
>    sts PORTB,r16

Eben nicht! Die Änderungsmethode soll ja noch mehr machen, als nur den 
Wert zuweisen.