Warum sind macnhe Arduino Lib Objekte extern und andere static

Hallo, ich habe eine frage zu den Arduino libs.

Warum sind manche von den zu nutzenden Objekten als extern und manche als static instanziiert?

Z.b. Die SPI und die I2C (also Wire) libs deklarieren die Objekte die genutzt werden können als "extern" und instanziieren diese dann in der cpp Datei.

Also Header:

extern SPIClass SPI;
extern TwoWire Wire;

cpp Datei:

SPIClass SPI;
TwoWire Wire = TwoWire();

Wohingegen die EEPROM lib einfach nur das Objekt als static deklariert:

static EEPROMClass EEPROM;

Liegt dies einfach nur an der Inkonsistenz der Entwickler bei Arduino und evtl fehlender Coding guidelines oder hat dies einen tieferen Sinn?

Bei der Instanziierung des TwoWire Objekts bleibt auch zu hoffen das der Kompiler optimiert...

TwoWire Wire; hätte ja volkommen gereicht....

Vielen Dank :slight_smile:

"Evtl fehlende Coding Guidelines" ist erstens witzig, zweitens die Erklärung.

In der Arduino - Welt gibt es ein paar Sachen, die nur einmal vorkommen EEPROM und die I2C Schnittstelle sind gute Beispiele.
Die fehlenden Coding Guidelines sagen, das Namespace nicht verwendet wird, sondern Klassen. Und wie Singleton Elemente erzeugt werden, ist Geschmackssache.

Wohingegen die EEPROM lib einfach nur das Objekt als static deklariert:

Der EEPROM Klasse tut es nicht weh, wenn jede Übersetzungseinheit seine eigene Instanz bekommt.
Darum ist die static Instanziierung brauchbar.
Auch wird damit der Verzicht auf eine EEPROM.cpp Datei ermöglicht.

Bei I2C und SPI wäre eine Mehrfachinstanziierung tödlich.
Sie würden sich ins Gehege kommen, da sie sich eine Hardware, welche einen inneren Zustand hat, teilen müssen. Darum wird eine Singleton Instanz erzwungen.
Das eingebaute EEPROM hat keinen inneren Status, welchen man daraufhin beachten müsste.

Edit:

Darum wird eine Singleton Instanz erzwungen.

Sie wird nicht erzwungen, sondern wir haben sie als solche zu betrachten.

Das wird dann mit dem ESP32 aber Änderungen geben müssen. Der hat 2 mal I2C.

Gruß Tommy

michael_x:
Und wie Singleton Elemente erzeugt werden, ist Geschmackssache.

Im obigen Kode kommt kein Singleton vor, die benutzten Klassen haben alle einen public Konstruktor
und sind insofern nicht gegen mehrfache Instanziierung geschützt.

siehe Singleton

Ob sie es sind oder nicht sind, ist doch nur blabla.
Wire, Serial und SPI müssen als solche betrachtet werden, sonst knallt es unterm Sofa.
Pro Hardware Modul, eine Instanz, und gut ist.

Bei EEPROM ist das dagegen kein Problem.

combie:
Ob sie es sind oder nicht sind, ist doch nur blabla.

Technische Fachausdrücke sind für dich nur “blabla”?
Die Einstellung solltest du vielleicht noch einmal überdenken.

combie:
Wire, Serial und SPI müssen als solche betrachtet werden, sonst knallt es unterm Sofa.
Pro Hardware Modul, eine Instanz, und gut ist.

Der Link beschreibt genau wann man den Begriff Singleton verwenden kann/darf,
ein freiwilliger Verzicht auf die Instanziierung von Objekten gehört nicht dazu.

Technische Fachausdrücke sind für dich nur "blabla"?

Nochmal, etwas deutlicher, extra für dich, zum mit meißeln:

Ob sie es sind oder nicht sind, ist doch nur blabla.
Etwas ausführlicher:
Ob die genannten Klassen Singletons sind, oder nicht so implementiert worden sind, ist bla bla!
Da kannst du dich gerne drüber aufregen, oder nochmal falsch verstehen wollen.

Wir Arduino User, zumindest ich, müssen uns nach der Decke strecken, und die Dinger so nehmen wie sie sind. Denn sonst können wir die davon abhängigen Libs nicht nutzen.

Darum ist jede Diskussion darüber, ob sie jetzt Singleton sind, oder sein sollten, irrelevant.
Es wird zu keinem Ergebnis kommen, welches in der praktischen Arbeit damit, Wirkung zeigt
Also: Blabla über nichts.

Zugeständnis:
Habe meinen Beitrag #2 geändert.

Es geht mir darum zu verdeutlichen, dass

michael_x:
Und wie Singleton Elemente erzeugt werden, ist Geschmackssache.

überhaupt keine Antwort/Erklärung auf die Frage nach dem Warum von

TwoWire Wire = TwoWire();
...
TwoWire Wire;        // hätte ja volkommen gereicht....

darstellt.

Bei der Beurteilung der Antwort

michael_x:
Und wie Singleton Elemente erzeugt werden, ist Geschmackssache.

ist die Behauptung "TwoWire ist ein Singleton" sehr relevant.

Hätte jemand geschrieben

"Wie Kuchen gemacht werden, ist Geschmackssache."

Wäre jedem direkt aufgefallen, dass TwoWire Objekte keine Kuchen sind...

Whandall:
Es geht mir darum zu verdeutlichen, dass
überhaupt keine Antwort/Erklärung auf die Frage nach dem Warum von

TwoWire Wire = TwoWire();

...
TwoWire Wire;        // hätte ja volkommen gereicht....



darstellt.

Bei der Beurteilung der Antwort
ist die Behauptung "TwoWire ist ein Singleton" sehr relevant.

Da hab ich ja was losgetreten, sorry.

"Geschmackssache" wollte nur sagen: kann man auf verschiedene Weise machen. Man kann es auch so machen, dass es kein Singleton ist und es trotzdem "tödlich" ist, mehrere Instanzen zu erzeugen (Sehr beliebt hier). Klar muss man die Library - Objekte so verwenden, wie es erforderlich/vorgesehen ist.

"Warum" ist selten eine Frage mit klarer Antwort. Ich diskutiere öfter mit meinem Enkel