C++ Frage zur Combie Bibliothek

International Deutsch
1

ich versuche mich etwas mit der Combie-Lib auseinander zu setzen und mein C++ Wissen zu erweitern. Dazu habe ich mit CombiePin angefangen. Nun drängt sich mir eine Frage auf. Dadurch, dass ein Pin Objekt aus einem Template erzeugt wird, kann ich kein Array aus Pins erstellen.

// Spielbeispiel versimplifiziert....
template <byte pin> class Pin {
protected:
  void initInput() { pinMode(pin, INPUT); }
  void initPullup() { pinMode(pin, INPUT_PULLUP); }
  void initOutput() { pinMode(pin, OUTPUT); }
  bool isHigh() const { return digitalRead(pin); }
  void setHigh() { digitalWrite(pin, HIGH); }
  void setLow() { digitalWrite(pin, LOW); }
  void toggle() { digitalWrite(pin, !digitalRead(pin)); }
};

template <byte arduinoPin> class InputPin : protected Pin<arduinoPin> {
public:
  using Pin<arduinoPin>::initPullup;
  using Pin<arduinoPin>::isHigh;

  operator bool() const { return Pin<arduinoPin>::isHigh(); }

  bool operator()() const { return Pin<arduinoPin>::isHigh(); }

  void init() { Pin<arduinoPin>::initInput(); }
};

InputPin<4> iPin1;
InputPin<5> iPin2;
InputPin<6> iPin3;
InputPin<7> iPin4;

void setup() {
  iPin1.initPullup();
  iPin2.initPullup();
  iPin3.initPullup();
  iPin4.initPullup();
}

void loop() {

}

Ich bin also (mit meinem momentanen Wissensstand) gezwungen, einzelne Objekte anzulegen, die ich nicht in einer Schleife abarbeiten kann. Wie kann man das möglich machen?

Eine Erweiterung der Frage:

In anderen Zusammenhängen hast Du (@combie) mit einer abstrakten Basisklasse Arrays aus Zeigern auf die Basisklasse erzeugt. Wenn man das macht, kann nur auf die Methoden zugegriffen werden, die auch in der Basisklasse deklariert wurden. Ein Zugriff auf (nicht virtuelle) Methoden, die nur in der von der Basisklasse abgeleiteten Klasse vorkommen, ist dann ja nicht möglich. Oder Doch?

2

Das ins Array stopfen geht nur über eine Interface Klasse.
Die Pins kommen selten alleine vor, sondern in einem umhüllenden Kontext.

Du hast Richtig.
Darum nenne ich auch eine solche Basisklasse "Interface Klasse"

Beispiel:

#include <CombiePin.h>
using namespace Combie::Pin;

class Task //  Interface Klasse
{
  public:
    virtual void init() {}
    virtual void run() = 0;
};

template<typename Taster, typename Druck, typename Pumpe>
class PumpemAbhandlung : public Task
{
  public:
    virtual void init() override
    {
      Taster{}.initPullup();
      Pumpe{} .init();
      Druck{} .init();
    }

    virtual void run() override
    {
      Pumpe{} = Druck{} && Taster{};  // wenn Druckanforderung und Taster dann pumpen
    }
};

Task *tasks[] //typename Taster, typename Druck typename Pumpe
{
  new PumpemAbhandlung<InvInputPin<2>, InputPin<5>, OutputPin<11>>{},
  new PumpemAbhandlung<InvInputPin<3>, InputPin<6>, OutputPin<12>>{},
  new PumpemAbhandlung<InvInputPin<4>, InputPin<7>, OutputPin<13>>{},
};

void setup()
{
  for(Task *t : tasks) t->init();
}

void loop()
{
  for(Task *t : tasks) t->run();
}
3

Danke für das Beispiel. Das ist ein ausgefuchstes Baukastensystem. Da muss ich erst mal weiter mit probieren. Es ist aber schon mal gut bestätigt zu bekommen, dass Arrays tatsächlich nur über Interface-Klassen zu „bauen“ sind und es nicht doch noch irgend einen anderen Mechanismus gibt.

4

Der springende Punkt ist halt, dass in einem Array alle Daten vom gleichen Type sein müssen. Bei mir das ein Zeiger auf Task.

Ist kein vollständiger Datentype.
Er braucht auch noch seine Template Parameter

Jetzt ist es ein Datentype. Jetzt kann man auch eine Instanz davon erzeugen.

Im Grunde ist es das Arduino Pin Durchnummerieren, welches die andere Wege unterbindet.
Und eben der Wunsch, die eigentliche Pin Operation so schlank wie möglich zu machen.
Ein paar wenige Takte gehen für jede Pin Operation drauf. Irgendwas um 1 bis 3 pro Zugriff.
Ein digitalWrite() braucht da eher an die 100 Takte.

Da werden 3 Instanzen erzeugt (könnte man meinen).
Das ist allerdings völlig kostenlos.
Kein Takt und kein Speicher(RAM/Stack) wird dafür genutzt, nur wenige ASM Statements landen im Flash

5

Genial. Hast Du einen Link oder Beschreibung für mich wo man dieses Nachlesen kann?

Was wird mit dieser Zeile gemacht?

6

Ja.

Aber da die Tasks verschiedene Template-Parameter haben, sind sie doch eigentlich auch verschiedene Typen?
Und Zeiger auf verschiedene Typen kann man doch eigentlich auch nicht mischen?

[Edit]
Äh, in deinem Beispiel fehlen die Definitionen von Taster, Pumpe, Druck
[/Edit]

7

Nein!
Task ist keine Template Klasse,

Wird ja auch nicht gemischt.
Alle Zeiger werden dort nach *Task konvertiert.

Ähhh..
Nöö.
Alles da und funktioniert.
Taster ist ein Datentype, ein Alias für z.B. Combie::Pin::InvInputPin<2>

1 Like
8

Im generierten Quellcode: Drehzahlregelung Verbrennungsmotor - #39 by combie
Oder auch in wiring_digital.c

Es werden 3 Instanzen von Combie::Pin erzeugt. (und wegoptimiert)
Druck und Taster werden nach ihrem aktuellen Zustand gefragt, die Zustände logisch &&(AND) verknüpft und das Ergebnis in die Pumpe geschickt.

1 Like
9

Dass das was in init() mit Pumpe{}.init(); gemacht wurde, auch für die neue Instanz
Pumpe{} in run() gilt, liegt daran, dass es sich nur auf den darin versteckten Pin auswirkt.

Wenn man wollte, könnte man in PumpemAbhandlung auch (private) Membervariable vom Typ Pumpe, Druck, Taster oder Sonstwas definieren, die dann in run() zur Verfügung stünden, da statt Task::run() tatsächlich PumpemAbhandlung::run() läuft.
(z.B. wenn man sich da einen alten Hysterese-Zustand oder gleitenden Mittelwert oder so merken will)

Andere combie-Elemente reagieren empfindlicher auf Neuerzeugen und Wegoptimieren.

10

So ist es!

Sobald es Instanz Variablen/Eigenschaften gibt, ist es vorbei mit der schönen/radikalen Optimierung.

Andererseits steht das virtual auch vielen Optimierungen im Wege rum.
Naja, einen Tod muss man halt sterben.

Immerhin findet sich in dem Beispiel Code kein einziges if und das ist ja auch schon etwas.

11

This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.