c++ PIN-Klassen-Templates und Vererbung

[Ralf G. (ralg)]

Mahlzeit den Experten.

Diese Idee
Beitrag "Re: IO-Register als Template-Parameter"
würde ich gern mal weiterverfolgen.

Also (nur mal grob, zur Orientierung):

template <typename port_t,typename ddr_t,typename pin_t>
class IOpin_t
{
protected:
  port_t port;
  ddr_t ddr;
  pin_t pin;
  const uint8_t pin_nr;
private:
public:
  IOpin_t( pinInit n ) : pin_nr(n & 0x00FF)
  {
    if (n & pinOutput)
      ddr  |= pin_nr;
    if (n & pinPullUp)
      port |= pin_nr;
  };
};
// --------------------------------------------------------------------------------

dann:

template <typename port_t,typename ddr_t,typename pin_t>
class OutputPins_t : IOpin_t<port_t,ddr_t,pin_t>
{
private:
public:
  OutputPins_t( pinInit n ) : IOpin_t<port_t,ddr_t,pin_t>(pinOutput | n ) {};
  inline void On(uint8_t mask)
  {
    IOpin_t<port_t,ddr_t,pin_t>::port |=  (mask & IOpin_t<port_t,ddr_t,pin_t>::pin_nr);
  };
  inline void Off(uint8_t mask)
  {
    IOpin_t<port_t,ddr_t,pin_t>::port &= ~(mask & IOpin_t<port_t,ddr_t,pin_t>::pin_nr);
  };
  inline void Toggle(uint8_t mask)
  {
    IOpin_t<port_t,ddr_t,pin_t>::port ^=  (mask & IOpin_t<port_t,ddr_t,pin_t>::pin_nr);
  };
  inline uint8_t GetPins()
  {
    return IOpin_t<port_t,ddr_t,pin_t>::pin_nr;
  };
};

so ähnlich noch für 'InputPins_t'...

Jetzt fangen, die im Gegensatz zu 'gewöhnlichen Klassen' viel längeren 
Templates, schon langsam an zu nerven.
Aber es wird noch besser (für eine Tasten-Matrix):

template <typename port_t,typename ddr_t,typename pin_t, uint8_t Z>
class Matrix_t : Object_t
{
private:
  InputPins_t<port_t,ddr_t,pin_t>* Tasten;
  OutputPins_t<port_t,ddr_t,pin_t>* Zeilen;
  Debounce_s deb_var[Z];
  //Debounce_s* deb_var = NULL;
  uint8_t anz_deb_var = 0;
  uint8_t akt_deb_pos = 0;
public:
  Matrix_t( InputPins_t<port_t,ddr_t,pin_t>* t, OutputPins_t<port_t,ddr_t,pin_t>* z, Message_e m );
  void OnMessage(Message_e& m);
  uint16_t get_key_press();
};

Und das ist nur die Deklaration! An der Stelle habe ich aufgegeben. 
Dieses '<port_t,ddr_t,pin_t>' gehört natürlich zum Datentyp dazu.

(*) Lässt sich das aber vielleicht trotzdem irgendwie umgehen?

Gerade sehe ich: Das ist ja noch lange nicht alles! Für 'InputPins_t' 
und 'OutputPins_t' müssen ja unterschiedliche Parameter angegeben 
werden, sind ja zwei verschiedene Ports. Die Template-Liste ist jetzt ja 
fast schon einen Meter lang! [ siehe nochmal (*) ]

[Scelumbro (Gast)]

Mal ein Vorschlag von meiner Seite

#define GPIOB_BASE  0x23
#define GPIOC_BASE  0x26
#define GPIOD_BASE  0x2B
#define GPIOE_BASE  0x2C
#define  GPIOF_BASE  0x2F

typedef struct
{
  uint8_t pin;
  uint8_t ddr;
  uint8_t port;
  
} GPIO_t;

template <uint8_t baseaddr> struct AVRgpioBank
{
  GPIO_t * reg;
  
  AVRgpioBank()
  {
    reg = reinterpret_cast<GPIO_t *>(baseaddr);
    
  }
};

template<uint8_t baseaddr, uint8_t num> struct AVRgpioPin
{
  AVRgpioBank<baseaddr> port;
  
  void setDir(const bool value)
  {
    if(value)
    {
      port.reg ->ddr |= (1<<num);
    }
  }
  bool get() const
  {
    return ((port.reg ->pin) && (1<<num));
  }
  void set(const bool value)
  {
    port.reg ->port |= (1<<num);
  }
  
  bool operator =(const bool &value)
  {
    set(value);
    return value;
  }
  bool operator == (const bool &value)
  {
    return (get() == value);
    
  }
};

int main(void)
{

  AVRgpioPin<GPIOC_BASE, 0> led;
  led.setDir(true);
  led = true;
  while(1)
  {
    //TODO:: Please write your application code
  }
}

Am Ende schnurrt das ganze zu zwei sbi zusammen :)

[Dr. Sommer (Gast)]

Ralf G. schrieb:
> Lässt sich das aber vielleicht trotzdem irgendwie umgehen?
Typ-Aliase sind dein Freund. Schreib am Anfang deiner OutputPins_t

using B = IOpin_t<port_t,ddr_t,pin_t>;

Danach kannst du statt "IOpin_t<port_t,ddr_t,pin_t>" kurz "B" schreiben.

Ralf G. schrieb:
> template <typename port_t,typename ddr_t,typename pin_t>
> class IOpin_t
> {
> protected:
>   port_t port;
>   ddr_t ddr;
>   pin_t pin;
Was soll das denn? Du übergibst einen (vermutlich integer-) Typ und 
legst Variablen an, initialisierst sie nicht, schreibst hinein, 
transferierst die Werte aber nie in die Peripherie Register?

Und was ist das für ein komischer Namensstil, Klassen -Namen auf _t 
enden zu lassen?!

[Ralf G. (ralg)]

Scelumbro schrieb:
> Mal ein Vorschlag von meiner Seite
Versuch' ich mal zu verstehen.

Dr. Sommer schrieb:
> Danach kannst du statt "IOpin_t<port_t,ddr_t,pin_t>" kurz "B" schreiben.
Stimmt, hätte ich auch selber drauf kommen können. Das ist was, was ich 
noch überschauen kann.

Dr. Sommer schrieb:
> Und was ist das für ein komischer Namensstil
Cool, was ;-)
(Ist rein privat, einfach nicht hinsehen!)

Scelumbro schrieb:
> Am Ende schnurrt das ganze zu zwei sbi zusammen :)
Leider immer nur bei solchen Minimal-Beispielen :(

Ach ja, noch was:
Dr. Sommer schrieb:
> Was soll das denn?
siehe:
http://www.mikrocontroller.net/topic/goto_post/1733891

[Scelumbro (Gast)]

Ralf G. schrieb:
> Scelumbro schrieb:
>> Mal ein Vorschlag von meiner Seite
> Versuch' ich mal zu verstehen.

Das ganze ist noch sehr roh (set, setDir sind unvollständig), aber 
kompiliert.

Und warum sollte das ganze nicht auch für komplexere Projekte 
funktionieren? Solange alles zur Compile-Zeit bekannt ist kann sich der 
Compiler schön austoben.

[Ralf G. (ralg)]

Ralf G. schrieb:
> (*) Lässt sich das aber vielleicht trotzdem irgendwie umgehen?

Kommando zurück! Der Aufwand lohnt nicht.
In den Fällen, wo der Compiler das komplette Programm sieht, ist 
zwischen der oben zitierten Variante ('frisieren' der io.h), der 
Übergabe von PORT/DDR/PIN als Pointer ('const' oder ganz normal) oder 
als Referenz (mit Compiler-Warnung) kein Unterschied im Ergebnis!

Dazu reicht es schon bei größeren Projekten die 'weniger erwünschte 
Variante' ;-) zu nehmen: Statt sauber alles in Modulen zu halten und dem 
Linker das Zusammenfügen zu überlassen, einfach die "*.cpp's" statt der 
Header vor der 'main()' includieren.

[Dr. Sommer (Gast)]

Ralf G. schrieb:
> In den Fällen, wo der Compiler das komplette Programm sieht, ist
> zwischen der oben zitierten Variante ('frisieren' der io.h), der
> Übergabe von PORT/DDR/PIN als Pointer ('const' oder ganz normal) oder
> als Referenz (mit Compiler-Warnung) kein Unterschied im Ergebnis!
Was für eine Warnung?
Aber in der Tat werden Pointer und Referenzen quasi gleich behandelt.

Ralf G. schrieb:
> Statt sauber alles in Modulen zu halten und dem
> Linker das Zusammenfügen zu überlassen, einfach die "*.cpp's" statt der
> Header vor der 'main()' includieren.
Was soll das bringen? Warum nicht LTO verwenden?

[Ralf G. (ralg)]

Dr. Sommer schrieb:
> Was für eine Warnung?

../Test.cpp:7:20: warning: ignoring packed attribute because of unpacked non-POD field 'volatile uint8_t& IOpin_t::port' [enabled by default]
../Test.cpp:8:20: warning: ignoring packed attribute because of unpacked non-POD field 'volatile uint8_t& IOpin_t::ddr' [enabled by default]
../Test.cpp:9:20: warning: ignoring packed attribute because of unpacked non-POD field 'volatile uint8_t& IOpin_t::pin' [enabled by default]

Dr. Sommer schrieb:
> Warum nicht LTO verwenden?
Hab' ich bis jetzt nur was davon gehört und weiß so ungefähr was es 
bewirken soll. Weiter bin ich noch nicht.

[TriHexagon (Gast)]

Ralf G. schrieb:
> Dr. Sommer schrieb:
>> Und was ist das für ein komischer Namensstil
> Cool, was ;-)
> (Ist rein privat, einfach nicht hinsehen!)

Ist der Suffix "_t" nicht eigentlich für die C stdlib vorbehalten? Kann 
das wer bestätigen?

[Klaus W. (mfgkw)]

TriHexagon schrieb:
> Ist der Suffix "_t" nicht eigentlich für die C stdlib vorbehalten? Kann
> das wer bestätigen?

Nein, warum?
In C ist es häufig usus, alle Typen mit _t zu garnieren.
Warum sollte das für die stdlib reserviert sein?

[TriHexagon (Gast)]

Klaus Wachtler schrieb:
> TriHexagon schrieb:
>> Ist der Suffix "_t" nicht eigentlich für die C stdlib vorbehalten? Kann
>> das wer bestätigen?
>
> Nein, warum?
> In C ist es häufig usus, alle Typen mit _t zu garnieren.
> Warum sollte das für die stdlib reserviert sein?

Hab ich irgendwo aufgeschnappt. War mir deshalb nicht sicher. Aber danke 
für die Berichtigung.