ARDUINO class oder struct in ISR Fehler

[Joachim B. (jar)]

kann jemand diesen Fehler erklären oder wie ich das anstellen muss das 
es in der ISR läuft?

isr:153: error: passing 'volatile TS_Point' as 'this' argument of 
'TS_Point& TS_Point::operator=(const TS_Point&)' discards qualifiers

im Hauptprogramm

volatile TS_Point p;

in der ISR

extern volatile TS_Point p;

    if(ts.touched())
    {  p = ts.getPoint();   // Retrieve a point  
       p.x = map(p.x, TS_MINX, TS_MAXX, 0, tft.width()); p.y = map(p.y, TS_MINY, TS_MAXY, 0, tft.height());
       ts_data = 1;
    }

IMHO verbirgt sich doch nur ein Struct hinter TS_Point, also sollte die 
Adresse doch reichen aber mit cpp kenne ich mich halt nicht aus.

class TS_Point {
 public:
  TS_Point(void);
  TS_Point(int16_t x, int16_t y, int16_t z);
  
  bool operator==(TS_Point);
  bool operator!=(TS_Point);

  int16_t x, y, z;
};

[Christopher B. (chrimbo)]

Ich kann mich irren, aber:
extern volatile TS_Point p;
sollte nicht innerhalb einer Funktion (ISR) stehen.

Oder ist das erlaubt und welche Eigenschaft hat das dann?

Edit: Ah versuchst du etwa auf eine lokale Variable von main aus einer 
ISR zuzugreifen? Das Funktioniert nicht, du musst sie mindestens 
Modulglobal machen.

[Joachim B. (jar)]

Christopher B. schrieb:
> Edit: Ah versuchst du etwa auf eine lokale Variable von main aus einer
> ISR zuzugreifen?

ne die ist in Main global denke ich zumindest, in der main.ino aber 
ausserhalb der Routine.

Christopher B. schrieb:
> du musst sie mindestens
> Modulglobal machen.

wie muss ich das bitte machen?

[Joachim B. (jar)]

gelöst mit einem Umweg über eine eigen TS_Point in der ISR und Rückgabe 
andere volatile Var.

[Karl H. (kbuchegg)]

Ein

class TS_Point {
 public:
  TS_Point(void) : x(0), y(0), z(0) {}
  TS_Point(int16_t x_, int16_t y_, int16_t z_) : x(x_), y(y_), z(z_) {}
  
  bool operator==(const volatile TS_Point& rhs) const volatile
           { return x == rhs.x && y == rhs.y && z == rhs.z; }
  bool operator!=(const volatile TS_Point& rhs) const volatile
           { return x != rhs.x || y != rhs.y || z != rhs.z; }

  TS_Point& operator=(const volatile TS_Point& rhs)
           { x = rhs.x; y = rhs.y z = rhs.z; return *this; }
  volatile TS_Point& operator=(const volatile TS_Point& rhs) volatile
           { x = rhs.x; y = rhs.y z = rhs.z; return *this; }

  int16_t x, y, z;
};

müsste es eigentlich auch tun.

Der Qualifier, von dem der Compiler spricht, ist das 'volatile', und 
zwar das vom Objekt, für welches der Zuweisungsoperator aufgerufen wird, 
das ansonsten verloren gehen würde, wenn die Operation mit dem 
'normalen' Zuweisungsoperator aufgerufen werden würde (den sich der 
Compiler selbst schreibt, wenn du es nicht tust)


Beachte bitte auch, dass du den Operatoren als Argumente jeweils 
Referenzen zum anderen Objekt geben willst, um die Erzeugung einer 
temporären Kopie zu verhindern. Und zwar allen! Die Übergabe per 
Referenz ist in C++ mit Ausnahme der Basisdatentypen (char, int, double, 
long, ....) der Regelfall! Gegebenenfalls als const-Referenz. Und in 
deinem Fall dann (leider) auch noch mit einem zusätzlichen volatile.

Möglich, dass du die Operatoren in weiterer Folge im Header File als 
inline Funktionen geschrieben hast. Persönlich bevorzuge ich die direkte 
Schreibweise in der Klassendefinition. Ich finde dort sieht man besser, 
dass sie inline sind. Und ja. Du willst sie inline machen, um dem 
Compiler alle Möglichkeiten zur Optimierung zu geben.

[Joachim B. (jar)]

Karl Heinz schrieb:
> Ein
>  public:
> .....
> müsste es eigentlich auch tun.

danke, ich glaube ich verstehe so halb, aber da ich in cpp ganz schön 
absaufe und in Pointer auf Pointer kurz vor dem absaufen bin hebe ich 
mir das durchdenken für freie Zeit auf.

Momentan will ich nur vorwärts kommen, Ziel ist es PeDa bulletprof 
Tastaturentprellung in der ISR zur TouchScreen Entprellung umzubauen.

Ich finde diese Entprellroutine so geil und nie entgeht mir ein 
Tastendruck, das möchte ich gerne auch auf dem Touch haben.

[Karl H. (kbuchegg)]

Joachim B. schrieb:
> Karl Heinz schrieb:
>> Ein
>>  public:
>> .....
>> müsste es eigentlich auch tun.
>
> danke, ich glaube ich verstehe so halb, aber da ich in cpp ganz schön
> absaufe


Im Prinzip ist das, worum es hier geht, sehr simpel.

Du bist von C gewohnt, dass ein

  a = b;

einfach nur eine Umkopieraktion ist.
Dagegen ist auch ncihts zu sagen.

In C++ ist da aber noch ein Schritt dazwischen. Eine derartige Zuweisung 
ist im Sinne der Objektorientierung einfach nur ein AUfruf einer 
Memberfunktion (die lediglich einen etwas spezielleren Namen hat).

  a.operator=( b );

D.h. das Objekt a ist selbst dafür zuständig, was bei einer Zuweisung zu 
passieren hat. Es kapselt dieses Wissen in der Implementierung dieses 
Operators (der nichts anderes als eine speziellere Form einer Member 
Funktion ist).

Wenn du keine derartige Member Funktion selber schreibst, dann schreibt 
der Compiler eine für dich. Die macht - tada - nichts anders als eine 
Zuweisung aller Member des Objektes. Damit sind wir wieder genau da, 
dass ein

  a = b;

für Klassen, die keine Spezialbehandlung benötigen, genau das macht, was 
du erwarten würdest und was du auch gewohnt bist.

In deinem speziellen Fall, kommt dir das volatile von

 volatile MyClass a;

in die Quere.

Denn der standardmässig erzeugte Operator ist dafür nicht ausgelegt. Der 
ist eigentlich nur für nicht volatile Objekte gedacht. Warum das wichtig 
ist, ist einer Eigenschaft geschuldet: Der Operator gibt eine Referenz 
auf sein Objekt zurück. Und da darf dieses volatile nicht verloren 
gehen. D.h. es bleibt nichts anderes übrig, als eine Version des 
Operators zu schreiben, die ausdrückt: kann für volatile Objekte 
aufgerufen werden

  ....

   ........ operator= ( ..... ) volatile;

und liefert dann auch wieder eine Referenz auf ein volatile Objekt

   ....

  volatile MyClass& operator= ( .... ) volatile;