AVR und __property

#2931893
Lesenswert?

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
1
__property uint8_t x = {read = readX, write = writeX};
für avr-c++ "nachbasteln"?
#2932188
Lesenswert?

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.
#2933138
Lesenswert?

Johann L. schrieb:
> oder...
1
#include <avr/io.h>
2
#include <inttypes.h>
3

4
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
5
// __property-Nachbildung
6
template <class T> class property
7
{
8
private:
9
 T Value;
10
public:
11
 void Setter();
12
 property()
13
 {
14
  Value=0;
15
 };
16
 property(T i)
17
 {
18
  Value=i;
19
  Setter();
20
 };
21
};
22
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
23

24
class cTest
25
{
26
public:
27
 property<uint8_t> Wert;
28
};
29

30
template<> void property<uint8_t>::Setter()
31
{
32
 PORTD=Value;
33
};
34

35
cTest Test;
36

37

38
int main()
39
{
40

41
 Test.Wert=PORTB | (uint8_t)42;
42

43
 return 0;
44
}

Bis hierher habe ich mal was probiert.
#2939989
Lesenswert?

'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:
1
// Test für z.B. atmega88
2

3
#include <avr/io.h>
4
#include <inttypes.h>
5

6
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
7
// __property-Nachbildung
8
#define PROPERTY(type,identifier)   \
9
class identifier                    \
10
{                                   \
11
private:                            \
12
 type Value;                        \
13
public:                             \
14
 void* Parent;                      \
15
 identifier() { Value=0; };         \
16
/* Getter, Setter */                \
17
 operator type() { return Value; }; \
18
 void operator=(type);              \
19
}                  
20
// __property-Nachbildung
21
//~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
22

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

26
// weitere Klassen/ Strukturen
27
class cTest
28
{
29
public:
30
 uint8_t Testvariable;
31
 uint8_prop Wert;
32
 cTest()
33
 {
34
// für jede 'property'-Variable das Elternelement eintragen
35
  Wert.Parent=this;
36
 };
37
};
38

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

46
cTest Test;
47
volatile uint8_t x;
48

49
int main()
50
{
51
 x=99;
52
 Test.Testvariable=x | PORTC;
53
 Test.Wert=PORTB | 42;
54
 x=Test.Wert;
55

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

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

62
 x=Test.Wert;
63

64
 return 0;
65
}
Gast #2941225
Lesenswert?

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
1
Test.Wert=PORTB | (uint8_t)42;
übrig bleibt? 3 Befehle:
1
    lds r16,PORTB
2
    ori r16,0x2A  ;42
3
    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.
#2941391
Lesenswert?

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.

Antwort schreiben

Bitte melde dich an, um einen Beitrag zu schreiben.

oder

Mit Google-Account einloggen

Die Registrierung ist kostenlos und dauert nur eine Minute.

Jetzt registrieren