Flanken erkennung verbessern.vielleicht mit C++?

[struppi (Gast)]

Guten Tag,
ich weiß nicht ob es Euch auch immer wieder so geht das ihr in Euren 
Programmen eine Flanken Erkennung braucht?
Ich benötige das immer wieder.
Im Prinzip ist dies kein Problem. Aber damit nicht jedes mal wieder das 
Rad neu erfunden wird und vor Allem damit die Lesbarkeit gegeben ist 
habe ich mir ein kleines Makro gebastelt.

#define RISING_AGE( DATA, BIT )            \
({                  \
  static uint8_t  mem;\
  uint8_t ret = 0;\
  if ( (DATA & (1<<BIT))&&(mem==0))\
  {\
    mem=1;\
    ret=1;\
  }\
  else\
  {\
    mem=0;\
    ret=0;\
  }\
  ret;/* return value of Macro */  \
})
#define FALLING_AGE( DATA, BIT )            \
({                  \
  static uint8_t  mem;\
  uint8_t ret = 0;\
  if ( (!(DATA & (1<<BIT)))&&(mem==0))\
  {\
    mem=1;\
    ret=1;\
  }\
  else\
  {\
    mem=0;\
    ret=0;\
  }\
  ret;/* return value of Macro */  \
})

Der Aufruf ist dann ganz Simple

if (RISING_AGE(pdo_Power[2],0))
    {
      // mach was.....
    }

Nun zu meiner Frage.
Könnte man so was in c++ besser machen? Wäre es da möglich einfach eine 
Funktion zu instanziieren?
Wäre das Ressourcen schonender?

Oder gibt es eine bessere Möglichkeit um die Lesbarkeit aufrecht zu 
erhalten?
Lg

[nicht"Gast" (Gast)]

Ersetz mal das "Age" durch ein "Edge" :) Dann ist das zawr nicht so 
lustig, aber richtig

[Boäh (Gast)]

> if (RISING_AGE(pdo_Power[2],0))

Lass mal dein Makro expandieren und schau dir den Code dann an. Versuche 
darin zu Debuggen und Fehler zu finden.

Endlich sind die Letzten von ASM runter und jetzt so was?

[struppi (Gast)]

Boäh schrieb:
> Lass mal dein Makro expandieren und schau dir den Code dann an. Versuche
> darin zu Debuggen und Fehler zu finden.
>
> Endlich sind die Letzten von ASM runter und jetzt so was?

Kannst du mir das näher erklären?
Was meinst du mit expandieren?

Lg

[Boäh (Gast)]

Das define wird per preprocessor in den Quelltext an der Aufrufstelle 
direkt eingefügt. Wie sieht die if BEDINGUNG dann wohl aus?

[struppi (Gast)]

Die Frage war ja wie kann man es schöner machen?

[Wilhelm M. (wimalopaan)]

Nur mal so als Idee ...

using PortC     = Port<MCU::PortRegister, C>;
using buttonPin = Pin<PortC, 1>;
using button    = ActiveLow<buttonPin, Input>;
using ledPin    = Pin<PortC, 1>;
using led       = ActiveHigh<ledPin, Output>;
using edgeDetector = EdgeDetector<button>;

int main() {
    edgeDetector::init();
    led::init();

    auto trigger = []{
        led::on();
    };
    auto release = []{
        led::off();
    };
   
    while(true) {
        edgeDetector::sample(trigger, release);
    }
}

P.S.: Auch in C keine Macros schreiben, die wie Funktionen aussehen ...
P.P.S: ... mach eine inline Funktion draus und vertrau dem Compiler 
(ggf. zusammen mit LTO).

[Sheeva P. (sheevaplug)]

struppi schrieb:
> Die Frage war ja wie kann man es schöner machen?

Das war Deine Frage, ja. Mir persönlich wäre es aber viel wichtiger, die 
Sache nicht nur schön, sondern vor allem richtig zu machen. Deine Makros 
haben nämlich leider ein paar Designfehler, und können so nicht in jedem 
Fall korrekt funktionieren.

In C++ könnte man das etwa so machen (ungetestet):

class Edge {
private:
    uint8_t* port;
    uint8_t  bit;
    bool     oldstate;
public:
    Edge(uint8_t* port, uint8_t bit):
        port(port), bit(bit) {
        if( (*port & (1<<bit)) ) {
            oldstate = true;
        } else {
            oldstate = false;      
        }
    }
    bool rising(void) {
        bool newstate = false;
        // bit is set now
        if( (*port & (1<<bit)) ) {
            newstate = true;
        }
        // bit was not set, but is now 
        if( oldstate == false && newstate == true ) {
            oldstate = newstate;
            return true; // rising
        }
        return false; // not rising: falling or kept state
    }
    bool falling(void) {
        bool newstate = true;
        // bit is not set now
        if( (!(*port & (1<<bit))) ) {
            newstate = false;
        }
        // bit was set, but now is not
        if( oldstate == true && newstate == false ) {
            oldstate = newstate;
            return true; // falling
        }
        return false; // not falling: rising or kept state
    }
    bool unchanged(void) {
        bool newstate = false;
        // bit is set now
        if( (*port & (1<<bit)) ) {
            newstate = true;
        }
        if( newstate == oldstate ) {
            return true;
        }
        return false;
    }
};

int main(void) {
    Edge e(&PORTB, PB1);
    // ...

    if( e.rising() ) {
        do_something(); 
    }
    // ...

    return 0;
}
}

Edit: korrekt formatiert sieht einfach besser aus... ;-)

[struppi (Gast)]

Wilhelm M. schrieb:
> mach eine inline Funktion draus und vertrau dem Compiler
> (ggf. zusammen mit LTO).

Klingt interessant. Wenn innerhalb der Funktion eine Variable static 
deklariert ist, wird dann bei öfteren Verwendung diese Variable öfter 
angelegt?

Sheeva P. schrieb:
> Edit: korrekt formatiert sieht einfach besser aus... ;-)

Danke für deine Mühe.
Was meisnst du mit korrekt formatiert?
Lg

[Sheeva P. (sheevaplug)]

struppi schrieb:
> Sheeva P. schrieb:
>> Edit: korrekt formatiert sieht einfach besser aus... ;-)
>
> Danke für deine Mühe.
> Was meisnst du mit korrekt formatiert?

Daß das Forum mir beim ersten Posten meines Beitrages die Formatierung 
zerschossen hat und ich sie deswegen mit einem Edit korrigieren mußte.

[struppi (Gast)]

Sheeva P. schrieb:
> struppi schrieb:
>> Sheeva P. schrieb:
>>> Edit: korrekt formatiert sieht einfach besser aus... ;-)
>>
>> Danke für deine Mühe.
>> Was meisnst du mit korrekt formatiert?
>
> Daß das Forum mir beim ersten Posten meines Beitrages die Formatierung
> zerschossen hat und ich sie deswegen mit einem Edit korrigieren mußte.

A Ok ich verstehe:)
kennst du dich mit inline aus?

[Sheeva P. (sheevaplug)]

Wilhelm M. schrieb:
> P.P.S: ... mach eine inline Funktion draus und vertrau dem Compiler
> (ggf. zusammen mit LTO).

Inline-Funktionen dürfen IIRC keine nicht-konstanten statischen 
Variablen enthalten, die Variablem "mem" müßten dann also außerhalb der 
Funktionen liegen. Ich glaube, die Makros fallen da auch auf die Nase. 
;-)

[Wilhelm M. (wimalopaan)]

Nein, das Problem an dem Code des TO ist, dass keine Flankenerkennung 
durchgeführt wird. Es wird der statische Zustand ermittelt. Denn es 
handelt sich um anonyme Blöcke, die statics werden also bei jedem Aufruf 
mit 0 initialisiert.

Ein

volatile uint8_t p = 1;

int main() {
    if (RISING_AGE(p, 0)) {
        printf("A\n");        
    }
    if (RISING_AGE(p, 0)) {
        printf("B\n");        
    }
}

sollte "A" und "B" ausgeben.

[Boäh (Gast)]

Wilhelm M. schrieb:
> Denn es
> handelt sich um anonyme Blöcke, die statics werden also bei jedem Aufruf
> mit 0 initialisiert.

Kann man das bitte näher erläutern.

[Neugieriger (Gast)]

Ist hier der Wettbewerb: "Wie mache ich es möglichst umständlich?"?

Sheeva P. schrieb:

> bool rising(void) {
>         bool newstate = false;
>         // bit is set now
>         if( (*port & (1<<bit)) ) {
>             newstate = true;
>         }
>         // bit was not set, but is now
>         if( oldstate == false && newstate == true ) {
>             oldstate = newstate;
>             return true; // rising
>         }
>         return false; // not rising: falling or kept state
>     }

Man, bei so was bekommt man ja Plaque!

Ordentlich formuliert könnte das so aussehen.

bool rising(void) 
{
  bool newstate = *port & (1<<bit);
  bool risen = newstate && !oldstate;
  oldstate = newstate;
  return risen;
}

Die Klasse sollte sich aber nur um Flanken kümmern, und nichts anderes:

   Single Responsibility Principle!

Ein Vorschlag:

class EdgeDetector 
{
public:

  EdgeDetector& update(bool actual)
  {
    previous = present;
    present = actual;
    return *this;
  }

  bool risen() const
  {
    return present && !previous;
  }

  bool fallen() const
  {
    return !present && previous;
  }

  bool changed() const
  {
    return present != previous;
  }

private:
  bool present, previous;
};

[Sheeva P. (sheevaplug)]

Neugieriger schrieb:
> Die Klasse sollte sich aber nur um Flanken kümmern, und nichts anderes:
>
>   *Single Responsibility Principle!*

Schick! Trotzdem halte ich es für eine gute Idee, den Status fest an die 
Port- und Registerkombination zu binden, um damit Fehler wie diesen hier

ed.update( (PORTA & (1<<PA0)) );
ed.update( (PORTB & (1<<PB1)) );

zu vermeiden. Das ändert aber nichts daran, daß Dein Code viel hübscher 
ist als meiner. Ich sollte wieder mehr C++ coden. ;-)

[struppi (Gast)]

Wilhelm M. schrieb:
> Nein, das Problem an dem Code des TO ist, dass keine Flankenerkennung
> durchgeführt wird. Es wird der statische Zustand ermittelt. Denn es
> handelt sich um anonyme Blöcke, die statics werden also bei jedem Aufruf
> mit 0 initialisiert.

Warum funktioniert es dann?
Warum Funktioniert den dann dieser CODE?? 
https://www.mikrocontroller.net/attachment/67964/debounce.c

Ich bin ein Anfänger bitte um nähere Erklärungen was das Static und 
staic in Inline Funktionen betrifft.

Danke für Eure Bemühungen!

Lg

[Wilhelm M. (wimalopaan)]

struppi schrieb:
> Wilhelm M. schrieb:
>> Nein, das Problem an dem Code des TO ist, dass keine Flankenerkennung
>> durchgeführt wird. Es wird der statische Zustand ermittelt. Denn es
>> handelt sich um anonyme Blöcke, die statics werden also bei jedem Aufruf
>> mit 0 initialisiert.
>
> Warum funktioniert es dann?

Ich habe das Macro bewusst falsch verwendet: ein Macro ist eben keine 
Funktion und sollte auch so nicht verwendet werden.

> Warum Funktioniert den dann dieser CODE??
> https://www.mikrocontroller.net/attachment/67964/debounce.c

Steht ja eigentlich in dem Kommentar des Codes drin ...

Jede neue(!) Verwendung des Macros führt zu einem neuen(!) unbenannten 
Block/Scope (hier als GCC-Erweiterung als 
Compound-Statement-Expression). Und der hat seine eigenen lokalen 
Objekte.
(Das kann Vorteile haben ... s.a. Dein zitiertes Beispiel, das für jeden 
Pin
sinnvollerweise eine eigene static-Variable angelegt wird. In meinem 
extra konstruierten Fall wird es aber falsch).

Wird das Ganze also in einer Schleife verwendet und pro Pin nur 
einmal(!) das Macro benutzt, ist es richtig.

> Ich bin ein Anfänger bitte um nähere Erklärungen was das Static und
> staic in Inline Funktionen betrifft.

Da empfehle ich ein C-Buch oder

http://en.cppreference.com/w/c/language

[struppi (Gast)]

Wilhelm M. schrieb:
> Wird das Ganze also in einer Schleife verwendet und pro Pin nur
> einmal(!) das Macro benutzt, ist es richtig.

Also bei richtiger verwendung ginge es?
Wie würde sich das verhalten wenn ich anstelle von diesem Macro den Code 
in eine Inline Funktion packen würde?
 Würde dann bei jeden Aufruf die staic deklarierte Variable "mem" neu 
verwendet?

Danke Lg

[Wilhelm M. (wimalopaan)]

struppi schrieb:
> Wilhelm M. schrieb:
>> Wird das Ganze also in einer Schleife verwendet und pro Pin nur
>> einmal(!) das Macro benutzt, ist es richtig.
>
> Also bei richtiger verwendung ginge es?

Ja ;-)

> Wie würde sich das verhalten wenn ich anstelle von diesem Macro den Code
> in eine Inline Funktion packen würde?

Wie wäre es mit ausprobieren?
Wobei es in der o.g. Form nur als Funktion geschrieben wieder eine 
andere Fehlerquelle beinhaltet (s.a. Post von sheevaplug).

>  Würde dann bei jeden Aufruf die staic deklarierte Variable "mem" neu
> verwendet?

Schlage mal die Bedeutung von static nach.

[struppi (Gast)]

Wilhelm M. schrieb:
> Schlage mal die Bedeutung von static nach.

Ich weiß das static deklarierte Variablen nach der ausfürung der 
Funktion erhalten bleiben.
Was ich aber in meinem C Buch nicht finde wie das verhalten in einer 
Inline Funktion ist!
Lg
Danke Für die Geduld.

Wilhelm M. schrieb:
> Wie wäre es mit ausprobieren?

Funktioniert aber ich weiß nicht wie es sich verhaltet wenn sonderfälle 
auftreten ;)

Wilhelm M. schrieb:
> Einvolatile uint8_t p = 1;
>
> int main() {
>     if (RISING_AGE(p, 0)) {
>         printf("A\n");
>     }
>     if (RISING_AGE(p, 0)) {
>         printf("B\n");
>     }
> }

So wie du mir oben gezeigt hats
Danke
Lg

[Marc (Gast)]

Sheeva P. schrieb:
> Schick! Trotzdem halte ich es für eine gute Idee, den Status fest an die
> Port- und Registerkombination zu binden, um damit Fehler wie diesen hier
> ed.update( (PORTA & (1<<PA0)) );
> ed.update( (PORTB & (1<<PB1)) );
>
> zu vermeiden.

Im Prinzip hast du recht. Aber eine andere Sache ist gefährlicher:
Häufig soll der Zustand eines anderen Signals bei einer Flanke 
verarbeitet werden. Wird das Auslesen eines Portpins in die Klasse 
gezogen wird das ganze asynchron. Jede Interruptunterbrechung macht das 
ganze inkonsistent.

Daher sollte die Klasse auch mit Daten aus einem gespiegelten Speicher 
klarkommen und nicht nur mit direkten IO Ports.

[Wilhelm M. (wimalopaan)]

struppi schrieb:
> Wilhelm M. schrieb:
>> Schlage mal die Bedeutung von static nach.
>
> Ich weiß das static deklarierte Variablen nach der ausfürung der
> Funktion erhalten bleiben.
> Was ich aber in meinem C Buch nicht finde wie das verhalten in einer
> Inline Funktion ist!

Wie gesagt: hier entsteht das nä. Problem.

Du hast ja eingangs gefragt, obs mit OOP (C++) ggf. besser ginge. Also: 
wir bewegen uns durch Selbsterkenntnis dahin ;-))

Zeige mal Deinen Code soweit ... dann schauen wir.

[struppi (Gast)]

Wilhelm M. schrieb:
> Zeige mal Deinen Code soweit ... dann schauen wir.

Welchen? den meiner Inline Funktion?

Lg

[Wilhelm M. (wimalopaan)]

struppi schrieb:
> Wilhelm M. schrieb:
>> Zeige mal Deinen Code soweit ... dann schauen wir.
>
> Welchen? den meiner Inline Funktion?

Ja, alles was dazu relevant ist.

[struppi (Gast)]

C-Code
/* PROTOTYPS */

 static inline uint8_t steigende( uint8_t DATA,uint8_t BIT );





int main(void)
{
while (1)
    {
        if (steigende(pdo_PowerCtrlA[2],0))
    {
      emcyData[0]=0x13;
      emcyData[1]=0x30;
      emcyData[2]=0x33;
      emcyData[3]=0x40;

      EmcyWriteReq(0x2301,&emcyData[0]);
    }
    }
}


 static inline uint8_t steigende( uint8_t DATA,uint8_t BIT )            
{                  
  static uint8_t  mem;
  uint8_t ret = 0;
  if ( (DATA & (1<<BIT))&&(mem==0))
  {
    mem=1;
    ret=1;
  }
  if ( (! (DATA & (1<<BIT))&&(mem==1)) )
  {
    mem=0;
    ret=0;
  }
  return  ret;
}

so in etwa;)

[Carl D. (jcw2)]

struppi schrieb:
> Wilhelm M. schrieb:
>> Schlage mal die Bedeutung von static nach.
>
> Ich weiß das static deklarierte Variablen nach der ausfürung der
> Funktion erhalten bleiben.
> Was ich aber in meinem C Buch nicht finde wie das verhalten in einer
> Inline Funktion ist!

Inline bei Funktion bedeutet nur, daß der Compiler sich den Call sparen 
soll und den Code bei jedem Aufruf direkt einfügt. Er kann das auch ohne 
inline machen, wenn er meint der Call wäre zu aufwendig. Dadurch ändern 
sich aber die anderen Eigenschaften der Funktion nicht. Die Variablen im 
"Funktions-Scope" bleiben weiterhin außerhalb unsichtbar und static legt 
genau eine Instanz einer Variablen an, die genau einmal, beim 
Programmstart initialisiert wird.
Nicht durch die (inzwischen vielen) anderen Verwendungen von inline 
verwirren lassen.

[Wilhelm M. (wimalopaan)]

struppi schrieb:

>

>  static inline uint8_t steigende( uint8_t DATA,uint8_t BIT )
> {
>   static uint8_t  mem;
>   uint8_t ret = 0;
>   if ( (DATA & (1<<BIT))&&(mem==0))
>   {
>     mem=1;
>     ret=1;
>   }
>   if ( (! (DATA & (1<<BIT))&&(mem==1)) )
>   {
>     mem=0;
>     ret=0;
>   }
>   return  ret;
> }
>

>
>
> so in etwa;)

Hieran sieht man, dass es (meistens) ungut ist, Funktionen mit internen 
Zuständen (also keine Funktionen mehr im engeren Sinn) zu schreiben. 
Denn wendest Du Deine Funktionen erneut an auf einen anderen Pin / 
Objekt

if (steigende(pdo_PowerCtrlA[2],7)) {
...
}

wirds wieder falsch. Denn Du / der Programmierer muss sich nun merken, 
dass der interne Zustand der Funktion für Bit 0 in pcd_PowerCtrl[2] gilt 
und sonst für nichts anderes.

Folglich wäre es besser:

struct Flag {
    uint8_t value;
};

typedef struct Flag flag_t;

inline bool rising_edge(volatile uint8_t* data, uint8_t bit, flag_t* mem) {
    uint8_t ret = 0;
    if ( (*data & (1<<bit))&&(mem->value == 0)) {
        mem->value = 1;
        ret=1;
    }
    else {
        mem->value = 0;
        ret=0;
    }
    return ret;
}

was nichts anderes bedeutet, als dass wir den internen Zustand 
externalisiert haben. Damit haben wir eine Funktion, die auf ein Objekt 
vom Type flag_t angewendet wird. Das kann man objektbasierte 
Programmierung nennen.

Nun ist muss der Programmierer explizit sagen, welche Flags benutzt 
werden sollen, und macht hoffentlich keinen Fehler (aber optimal ist das 
ja noch nicht!).

Jetzt kannst Du es leicht nach OOP (C++) umbauen.

Die nächste Stufe wäre nun, dass man die Flags ausschließlich einem 
bestimmten Pin zur Flankenüberwachung zuordnen kann (das kann man jetzt 
noch falsch machen). Das könnte man mit dem Ansatz ganz oben von mir 
sicherstellen ...

[Wilhelm M. (wimalopaan)]

Carl D. schrieb:
> struppi schrieb:
>> Wilhelm M. schrieb:
>>> Schlage mal die Bedeutung von static nach.
>>
>> Ich weiß das static deklarierte Variablen nach der ausfürung der
>> Funktion erhalten bleiben.
>> Was ich aber in meinem C Buch nicht finde wie das verhalten in einer
>> Inline Funktion ist!
>
> Inline bei Funktion bedeutet nur, daß der Compiler sich den Call sparen
> soll und den Code bei jedem Aufruf direkt einfügt.

Jaein, "soll" ist hier aber kein "muss". Das darf er aber auch sonst 
nach der as-if-rule.

inline ist hauptsächlich dazu da, die ODR nicht zu verletzten.

[struppi (Gast)]

Wilhelm M. schrieb:
> was nichts anderes bedeutet, als dass wir den internen Zustand
> externalisiert haben. Damit haben wir eine Funktion, die auf ein Objekt
> vom Type flag_t angewendet wird. Das kann man objektbasierte
> Programmierung nennen.
>
> Nun ist muss der Programmierer explizit sagen, welche Flags benutzt
> werden sollen, und macht hoffentlich keinen Fehler (aber optimal ist das
> ja noch nicht!).
>
> Jetzt kannst Du es leicht nach OOP (C++) umbauen.
>
> Die nächste Stufe wäre nun, dass man die Flags ausschließlich einem
> bestimmten Pin zur Flankenüberwachung zuordnen kann (das kann man jetzt
> noch falsch machen). Das könnte man mit dem Ansatz ganz oben von mir
> sicherstellen ...

Ok ich verstehe! Also gibt es keine Möglichkeit in c eine Instanz einer 
Funktion zu deklarieren?!

Macht C++ also OOP auf einem 8 Bit Maschine Sinn? Ich habe hier einen 
At90Can128 im Einsatz.

Im Prinzip ist die Macro Methode wenn nur einmal mit selber Variable 
verwendet am leichtesten anzuwenden, Oder?

Lg
Ps Danke für die Fachliche Kompetenz!

[Wilhelm M. (wimalopaan)]

struppi schrieb:
> Wilhelm M. schrieb:
>> was nichts anderes bedeutet, als dass wir den internen Zustand
>> externalisiert haben. Damit haben wir eine Funktion, die auf ein Objekt
>> vom Type flag_t angewendet wird. Das kann man objektbasierte
>> Programmierung nennen.
>>
>> Nun ist muss der Programmierer explizit sagen, welche Flags benutzt
>> werden sollen, und macht hoffentlich keinen Fehler (aber optimal ist das
>> ja noch nicht!).
>>
>> Jetzt kannst Du es leicht nach OOP (C++) umbauen.
>>
>> Die nächste Stufe wäre nun, dass man die Flags ausschließlich einem
>> bestimmten Pin zur Flankenüberwachung zuordnen kann (das kann man jetzt
>> noch falsch machen). Das könnte man mit dem Ansatz ganz oben von mir
>> sicherstellen ...
>
> Ok ich verstehe! Also gibt es keine Möglichkeit in c eine Instanz einer
> Funktion zu deklarieren?!

Was meinst Du damit? Ein Funktionsobjekt? Ein Closure?

> Macht C++ also OOP auf einem 8 Bit Maschine Sinn? Ich habe hier einen
> At90Can128 im Einsatz.

Nach meiner Meinung: absolut! Allerdings muss sollte man sich im 
wesentlichen auf statische Polymorphie beschränken, TMP benutzen und 
auch Exceptions aussen vor lassen (gehen eh nicht beim avr-g++).

Generell kann man das gleiche machen wie in C und noch sehr, sehr viel 
mehr. Was m.E. zu besserem (in vielerlei Hinsicht) Code führt (teilweise 
sogar schneller).

Aber es werden jetzt gleich ganz viele Stimmen kommen, dass C++ Quatsch 
ist ;-))

> Im Prinzip ist die Macro Methode wenn nur einmal mit selber Variable
> verwendet am leichtesten anzuwenden, Oder?

Wie gesagt: wenn man keinen Fehler macht, ist so ziemlich alles ok.

M.E: geht es aber immer um ein ganz wesentliches Grundprinzip: Eine 
Schnittstelle sollte einfach richtig und schwer falsch zu benutzen sein. 
Und das erfüllt die Macro Methode (auch noch aus anderen Gründen) nicht.

[Frank M. (ukw) (Moderator)]

Wilhelm M. schrieb:
> Denn wendest Du Deine Funktionen erneut an auf einen anderen Pin /
> Objekt
> ...
> wirds wieder falsch.

Man kann es auch anders herum sehen:

Wenn man mit dem Makro für jeden abzufragenden Pin jeweils genau eine 
Stelle im Source wählt, dann funktioniert alles wie gewünscht, denn dann 
gibt es für jeden abzufragenden Pin gibt es genau einen "Speicher" mem.

Die Externalisierung ist dann nicht notwendig. Und so wird das Makro 
zumindest einfacher anzuwenden als jede (inline-)Funktion.

struppi schrieb:
> Im Prinzip ist die Macro Methode wenn nur einmal mit selber Variable
> verwendet am leichtesten anzuwenden,

Ja.

Ja, ich weiß: Makro-Hassern dreht sich da der Magen um. Aber jeder 
Versuch, das Makro durch Alternativlösungen zu schlagen, wird auf jeden 
Fall komplizierter - auch wenn der Compiler es schaffen sollte, trotz 
"Externalisierung" denselben Code wie beim Makro zu erzeugen. Der 
Binärcode wird auf jeden Fall nicht besser oder performanter.

[struppi (Gast)]

Wilhelm M. schrieb:
> Was meinst Du damit? Ein Funktionsobjekt? Ein Closure?

Ich meine einfach eine Art um die Funktion zwei drei ....X mal zu 
verwenden und das die variablen die stisch sein müssen einfach neu 
angelegt werden im Hintergrund ohne das ich einen Fehler machen kann.

Wilhelm M. schrieb:
> TMP benutzen

Was ist das?

Gibt es ein Beispiel wie das Atmel Studio7 eingestellt werden muß damit 
ich c++ verwenden kann?


Danke für deine guten Erklärungen!!!!

[Wilhelm M. (wimalopaan)]

Frank M. schrieb:

> Wenn man mit dem Makro für jeden abzufragenden Pin jeweils genau eine
> Stelle im Source wählt, dann funktioniert alles wie gewünscht, denn dann
> gibt es für jeden abzufragenden Pin gibt es genau einen "Speicher" mem.

Wie gesagt: wenn man es richtig macht, ist ja alles ok. (Oben hatte ich 
zur Erläuterung ein Beispiel gebracht, wie es leicht falsch wird).

> Die Externalisierung ist dann nicht notwendig. Und so wird das Makro
> zumindest einfacher anzuwenden als jede (inline-)Funktion.

Mehr ist bei reinem C m.E. nicht möglich.

> struppi schrieb:
>> Im Prinzip ist die Macro Methode wenn nur einmal mit selber Variable
>> verwendet am leichtesten anzuwenden,
>
> Ja.
>
> Ja, ich weiß: Makro-Hassern dreht sich da der Magen um. Aber jeder
> Versuch, das Makro durch Alternativlösungen zu schlagen, wird auf jeden
> Fall komplizierter - auch wenn der Compiler es schaffen sollte, trotz
> "Externalisierung" denselben Code wie beim Makro zu erzeugen.

Das sollte er schaffen ;-)

> Der
> Binärcode wird auf jeden Fall nicht besser oder performanter.

Ich denke, er ist identisch.

Allerdings: wenn es die Anwendung zulässt, dass man die Flags als lokale 
Variable (etwa in main) repräsentiert, wird der Ansatz mit 
Externalisierung effizienter.

[Peter D. (peda)]

Ich mache die Flankenerkennung immer zusammen mit der Entprellung und 
parallel für einen kompletten IO-Port. Das bischen Code wird in einen 
Timerinterrupt mit eingefügt. Das Main muß dann nur noch das Ereignis 
abholen.

[Wilhelm M. (wimalopaan)]

struppi schrieb:
> Wilhelm M. schrieb:
>> Was meinst Du damit? Ein Funktionsobjekt? Ein Closure?
>
> Ich meine einfach eine Art um die Funktion zwei drei ....X mal zu
> verwenden und das die variablen die stisch sein müssen einfach neu
> angelegt werden im Hintergrund ohne das ich einen Fehler machen kann.

Dann wären wir in C++ bei einem Funktor angelangt.

> Wilhelm M. schrieb:
>> TMP benutzen
>
> Was ist das?

Template-Meta-Programmierung.

> Gibt es ein Beispiel wie das Atmel Studio7 eingestellt werden muß damit
> ich c++ verwenden kann?

Da kann ich leider nicht weiterhelfen, das benutze ich nicht.

[struppi (Gast)]

Peter D. schrieb:
> Ich mache die Flankenerkennung immer zusammen mit der Entprellung und
> parallel für einen kompletten IO-Port. Das bischen Code wird in einen
> Timerinterrupt mit eingefügt. Das Main muß dann nur noch das Ereignis
> abholen.

Ich kenne deine ausgezeichnete Entprellung.
Ich benötige aber oft eine Flankenerkennung bei Variablen die über zB 
Can rein kommen.
Deine Variante erkennt die fallende Flanke ich benötige aber beide.
Außerdem müsste ich deine Entprellung ausbohren und und mittels 
Hilfsvariable zB 16 bit zusammen bauen.

Deshalb finde ich so eine Funktion oder Makro besser und wartbarer.

Wilhelm M. schrieb:
> Da kann ich leider nicht weiterhelfen, das benutze ich nicht.

Kein Problem hast mir ja sonst viel bei gebracht;)

Lg

[Carl D. (jcw2)]

struppi schrieb:
> Peter D. schrieb:
>> Ich mache die Flankenerkennung immer zusammen mit der Entprellung und
>> parallel für einen kompletten IO-Port. Das bischen Code wird in einen
>> Timerinterrupt mit eingefügt. Das Main muß dann nur noch das Ereignis
>> abholen.
>
> Ich kenne deine ausgezeichnete Entprellung.
> Ich benötige aber oft eine Flankenerkennung bei Variablen die über zB
> Can rein kommen.
> Deine Variante erkennt die fallende Flanke ich benötige aber beide.
> Außerdem müsste ich deine Entprellung ausbohren und und mittels
> Hilfsvariable zB 16 bit zusammen bauen.

Peters Flankenerkennung merkt sich diese auch bis sie jemand abfragt, 
wärend oben eine C++-Version zu sehen war, die die erkannten Flanken 
schon beim nächsten Takt wieder vergessen hat. Nur "alt XOR neu" ist 
eher ein Hochpassfilter.

[Sheeva P. (sheevaplug)]

Marc schrieb:
> Sheeva P. schrieb:
>> Schick! Trotzdem halte ich es für eine gute Idee, den Status fest an die
>> Port- und Registerkombination zu binden, um damit Fehler wie diesen hier
>> ed.update( (PORTA & (1<<PA0)) );
>> ed.update( (PORTB & (1<<PB1)) );
>> zu vermeiden.
>
> Im Prinzip hast du recht. Aber eine andere Sache ist gefährlicher:
> Häufig soll der Zustand eines anderen Signals bei einer Flanke
> verarbeitet werden. Wird das Auslesen eines Portpins in die Klasse
> gezogen wird das ganze asynchron. Jede Interruptunterbrechung macht das
> ganze inkonsistent.
>
> Daher sollte die Klasse auch mit Daten aus einem gespiegelten Speicher
> klarkommen und nicht nur mit direkten IO Ports.

#include <functional>

typedef std::function<bool(void)> PinReader;
class EdgeDetector {
public:
    EdgeDetector(PinReader updater_): updater(updater_) {
        oldstate = updater();
    }
    
    bool hasRisen(void) { return rise; }
    
    bool hasFallen(void) { return fall; }

    bool hasChanged(void) { return rise or fall; }
    
    EdgeDetector& update(void) {
        bool newstate = updater();
        rise = newstate and !oldstate;
        fall = !newstate and oldstate;
        oldstate = newstate;
        return *this;
    }
    // nifty
    EdgeDetector& operator()(void) { return update(); }
protected:
    PinReader updater;
private:
    bool oldstate;
    bool rise;
    bool fall;
};



// usage:

EdgeDetector kasper{
    [](void)->bool{
        return (PORTA & (1<<PA0));
    }
};

// ...

    ATOMIC_BLOCK( ATOMIC_FORCEON ) {
        kasper.update();
        if( kasper.hasRisen() ) {
            do_something();
        }
    }


// ... oder ... 

    ATOMIC_BLOCK( ATOMIC_FORCEON ) {
        if( kasper().hasRisen() ) {
            do_something();
        }
    }

Wer kein std::functional hat, kann natürlich auch Funktionszeiger 
benutzen.

[tictactoe (Gast)]

Sheeva P. schrieb:
> Wer kein std::functional hat, kann natürlich auch Funktionszeiger
> benutzen.

Lieber nicht. Auf einem Microcontroller hat man ja nicht unvorhersehbar 
viele Edge-Inputs, sondern nur genau so viele wie die angeschlossene 
Hardware hergibt. Deshalb ist es viel besser, die Klasse gleich als 
Template zu gestalten, wobei der updater ein Template-Parameter ist. Ich 
wette, dass in typischen Anwendungsfällen der Code am Ende kleiner ist, 
selbst wenn man, sagen wir, 5 EdgeDetectoren instanziieren muss.

BTW, ich würde außerdem versuchen, die 3 bool Variablen in ein Byte zu 
packen:

    bool oldstate : 1;
    bool rise : 1;
    bool fall : 1;

Wobei ich zugebe, dass ich in meinem Leben noch nie bools in ein 
Bitfield gequetscht habe.

[Wilhelm M. (wimalopaan)]

Sheeva P. schrieb:

> Wer kein std::functional hat, kann natürlich auch Funktionszeiger
> benutzen.

Evtl. ist die Einschränkung auf Callables (void) -> bool etwas zu 
einschränkend. In solchen fällen kann man sehr gut class template 
argument deduction (ggf. mit einem deduction guide) verwenden:

template<typename Updater>
class EdgeDetector {
public:
    EdgeDetector(Updater f) : mF{f}{}
    template<typename A = void>
    void update(const A& arg) {
        mF(arg);
    }
    void update() {
        mF();
    }
private:    
    Updater mF;
};

Man sollte in meinem Code oben noch die Überladung durch SFINAE 
ersetzen...

[Wilhelm M. (wimalopaan)]

tictactoe schrieb:

> BTW, ich würde außerdem versuchen, die 3 bool Variablen in ein Byte zu
> packen:
>

>     bool oldstate : 1;
>     bool rise : 1;
>     bool fall : 1;
>

> Wobei ich zugebe, dass ich in meinem Leben noch nie bools in ein
> Bitfield gequetscht habe.

Kann man aber gut machen. Gibt halt mehr Flash (Assembler Code), weniger 
RAM.

Mittlerweile habe ich mir angewöhnt, so etwas auch generisch zu lösen. 
Dann kann ich wählen per TemplateParameter, ob einzelne bools, ein 
BitField, oder ggf. auch ein GPIOR (bspw. bei AVR sehr effizient wenn 
sbi/cbi fähig) benutzt wird.

[Sheeva P. (sheevaplug)]

tictactoe schrieb:
> Auf einem Microcontroller hat man ja nicht unvorhersehbar
> viele Edge-Inputs, sondern nur genau so viele wie die angeschlossene
> Hardware hergibt. Deshalb ist es viel besser, die Klasse gleich als
> Template zu gestalten, wobei der updater ein Template-Parameter ist. Ich
> wette, dass in typischen Anwendungsfällen der Code am Ende kleiner ist,
> selbst wenn man, sagen wir, 5 EdgeDetectoren instanziieren muss.

Das käme auf einen Versuch an.

> BTW, ich würde außerdem versuchen, die 3 bool Variablen in ein Byte zu
> packen:

Da hatte ich auch schon 'dran gedacht und wollte es in meinem Posting 
eigentlich auch erwähnt haben, aber...

[Sheeva P. (sheevaplug)]

Wilhelm M. schrieb:
> Evtl. ist die Einschränkung auf Callables (void) -> bool etwas zu
> einschränkend.

Ich hatte darüber nachgedacht, es dann aber ganz absichtlich so gemacht. 
Der Status kann in diesem Fall ja eh nur ein Bool sein, und deswegen ist 
es IMHO korrekt, den Rückgabewert fest darauf zu beschränken. Und weil 
ich das Ganze festnageln und gerade nicht von externen Parametern 
abhängig machen, sondern im Gegenteil unbeabsichtigte Fehler verhindern 
will, soll diese Funktion gar keine Parameter annehmen können. Wer das 
trotzdem unbedingt haben will, kann das ja wahlweise als Template oder 
über Vererbung realisieren.