Arduino und struct gefallen sich nicht !

[Ralph S. (jjflash)]

Wie im Postingstitel geschrieben werden Arduino und struct in einer .ino 
Datei nicht wirklich Freunde werden.

Zugegeben (und dafür schäme ich mich mal ausnahmsweise nicht), bin ich 
ja nun wirklich ein Arduino-Anfänger (und will das so auch bleiben), 
aber andererseits möchte ich auch, wenn ich schon etwas für Arduino 
mache, das dann auch halbwegs richtig machen und genauso eben auch 
verstehen.

Im Moment erzeugt Arduino bei mir (mal wieder) ein Kopfschütteln:

typedef struct
{
  int x1, y1;
  int x2, y2;
  int upborderattr;
  int dwnborderattr;
  int txfieldattr;
} txbox_t;

txbox_t tbox;

// Arduino braucht diesen Funktionsprototyp, das ist doch bescheuert !
void ansi_txbox(const txbox_t *box);
// und hier die Funktion selbst, direkt darunter
void ansi_txbox(const txbox_t *box)
{
  int x;
  
  x = box->x1;
}

Ehrlich, wie "bescheuert" ist das denn? Und schön aussehen tut's auch 
nicht! Arduino braucht diesen Funktionsprototypen und warum?

Schlicht deshalb, weil Arduino automatisch Funktionsprototypen vor der 
Kompilierung generiert. Bei Funktionen mit Struct-Parametern kennt der 
Compiler den Typ noch nicht und deshalb muss ein Prototyp explizit 
angegeben werden um einen Fehler beim compilieren/linken:

txbox_t does not name a type.

zu vermeiden.

Ich schreibe einen Funktionsprototypen und darunter dann direkt die 
Funktion?
Okay, dann kann man das auch noch anderst lösen, verwenden wir halt 
Zeiger,
aber schön ist das ebensowenig

typedef struct
{
  int x1, y1;
  int x2, y2;
  int upborderattr;
  int dwnborderattr;
  int txfieldattr;
} txbox_t;

// Pointer ist hier ein "Arduino-Hack"
typedef txbox_t* ptxbox_t;

txbox_t tbox;

// Kein Prototyp notwendig und funktioniert direkt in .ino
void ansi_txbox(const ptxbox_t box)
{
  int x;

  x = box->x1;
}

Die sauberste Lösung ist dann wohl am ehesten, den struct in eine eigene 
.h Datei auszulagern, aber: will ein Arduino-User das? Mit mehr als 
einer Datei hantieren.

Eine Frage an die Cracks (und die Nicht-Anfänger wie mich): wie ist das 
korrekte Vorgehen?

[Niklas G. (erlkoenig)]

Ralph S. schrieb:
> typedef struct
>
> {
>
>   int x1, y1;
>
>   int x2, y2;
>
>   int upborderattr;
>
>   int dwnborderattr;
>
>   int txfieldattr;
>
> } txbox_t;

Vielleicht geht's ohne den unnötigen typedef-Tanz?

struct tbox_t
{
  int x1, y1;
  int x2, y2;
  int upborderattr;
  int dwnborderattr;
  int txfieldattr;
};

[Rahul D. (rahul)]

Wie wäre es, wenn du mal compilierbaren Quellcode zu dem "Problem" 
posten würdest (natürlich gerne als Anhanh)?!

Structs funktionieren auch im Arduino-Wrapper.
Du hast eher ein Problem mit dem Ort der Typen-Definition.

[Falk B. (falk)]

Ralph S. schrieb:
> Wie im Postingstitel geschrieben werden Arduino und struct in einer .ino
> Datei nicht wirklich Freunde werden.

Ein lösbares Problem.

> mache, das dann auch halbwegs richtig machen und genauso eben auch
> verstehen.

Gute Einstellung.

> Im Moment erzeugt Arduino bei mir (mal wieder) ein Kopfschütteln:typedef
> struct
> {
>   int x1, y1;
>   int x2, y2;
>   int upborderattr;
>   int dwnborderattr;
>   int txfieldattr;
> } txbox_t;
> txbox_t tbox;

Zeig und VOLLSTÄNDIGEN, compilerbaren Quelltext als Anhang.

> // Arduino braucht diesen Funktionsprototyp, das ist doch bescheuert !

Nein, das ist es nicht. Wer C mal verstanden hat, weiß auch warum.

> Ehrlich, wie "bescheuert" ist das denn? Und schön aussehen tut's auch
> nicht! Arduino braucht diesen Funktionsprototypen und warum?

Laber nicht rum! Das habe sich sehr schlau Leute vor verdammt langer 
Zeit ausgedacht. Es hat seinen Sinn! Wenn man die Funktionen in eine 
Datei packt, braucht man nicht unbedingt Prototypen. Wenn man die 
Funktionen aber in mehrere Dateien aufteilt, braucht man sie, denn 
andere Dateien müssen wissen, wie die Funktionen aufgerufen werden. Also 
natürlich der Compiler, wenn er eine Datei compiliert.

> Schlicht deshalb, weil Arduino automatisch Funktionsprototypen vor der
> Kompilierung generiert. Bei Funktionen mit Struct-Parametern kennt der
> Compiler den Typ noch nicht und deshalb muss ein Prototyp explizit
> angegeben werden um einen Fehler beim compilieren/linken:

Und wo liegt das Problem? Der Rest der Welt hat keins damit.

> txbox_t does not name a type.
>
> zu vermeiden.
>
> Ich schreibe einen Funktionsprototypen und darunter dann direkt die
> Funktion?

Nö. Man schreibt Header files und bindet die per #inlcude ein. Dort 
gehören auch die Typdefinitionen rein.

> Die sauberste Lösung ist dann wohl am ehesten, den struct in eine eigene
> .h Datei auszulagern,

BINGO!

> aber: will ein Arduino-User das? Mit mehr als
> einer Datei hantieren.

Er wird es lernen müssen. Ist wohl nicht zuviel verlangt.

[Nick (b620ys)]

Niklas G. schrieb:
> Vielleicht geht's ohne den unnötigen typedef-Tanz?

Hääää?

Wie gehts denn dann da weiter, ohne typedef? Mit void und casting?

void ansi_txbox(const txbox_t *box)
{
  int x;

  x = box->x1;
}

Ich mach das immer prinzipiell mit typedef, auch wenn ich den typen 
-zunächst vermutlich- nur ein mal brauche.

[Rahul D. (rahul)]

Nick schrieb:
> Wie gehts denn dann da weiter, ohne typedef?

man schleppt "struct" die ganze Zeit mit.

[Niklas G. (erlkoenig)]

Nick schrieb:
> Wie gehts denn dann da weiter, ohne typedef? Mit void und casting?

Nein, einfach nur txbox_t weiter verwenden. Genau wie vorher.

Nick schrieb:
> Ich mach das immer prinzipiell mit typedef, auch wenn ich den typen
> -zunächst vermutlich- nur ein mal brauche.

Wo ist der Nutzen?

struct tbox_t
{
  int x1, y1;
  int x2, y2;
  int upborderattr;
  int dwnborderattr;
  int txfieldattr;
};

und

typedef struct
{
  int x1, y1;
  int x2, y2;
  int upborderattr;
  int dwnborderattr;
  int txfieldattr;
} txbox_t;

sind identisch. Das erste ist aber kürzer, und vielleicht kommt Arduino 
damit besser klar.

Rahul D. schrieb:
> man schleppt "struct" die ganze Zeit mit.

Nicht nötig.

[Nick (b620ys)]

Falk B. schrieb:
> Nö. Man schreibt Header files und bindet die per #inlcude ein.

Aha. Man muss also Sachen die lediglich in einer Datei verwendet werden 
und die Benutzer nichts angehen, veröffentlichen.

> Dort gehören auch die Typdefinitionen rein.

Die gehören da hin, wo sie verwendet werden. Und sonst nirgendwo.

[Falk B. (falk)]

Nick schrieb:
>> Nö. Man schreibt Header files und bindet die per #inlcude ein.
>
> Aha. Man muss also Sachen die lediglich in einer Datei verwendet werden
> und die Benutzer nichts angehen, veröffentlichen.

Bist du so dumm oder tust du nur so?

>> Dort gehören auch die Typdefinitionen rein.
>
> Die gehören da hin, wo sie verwendet werden. Und sonst nirgendwo.

Du mußt es wissen.

[Arduino F. (Firma: Gast) (arduinof)]

Nick schrieb:
> Hääää?
>
> Wie gehts denn dann da weiter, ohne typedef?

Arduino ist C++ nicht C, zumindest in *.ino, *.pde und *.cpp Dateien.

C++ kann zwar noch typedef, aber typedef ist in den allermeisten Fällen 
nicht nötig, oder auch sinnig.
Vor struct ist es flüssiger als Waser.
Sie restlichen typedef lassen sich gerne durch using ersetzen.

[Nick (b620ys)]

Falk B. schrieb:
>> Die gehören da hin, wo sie verwendet werden. Und sonst nirgendwo.
>
> Du mußt es wissen.

Datenkapselung ("encapsulation") ist wohl ein neuer Begriff für dich. 
Ich helf dir kurz:
https://de.wikipedia.org/wiki/Datenkapselung_(Programmierung)

[Falk B. (falk)]

Nick schrieb:
> Datenkapselung ("encapsulation") ist wohl ein neuer Begriff für dich.
> Ich helf dir kurz:
> https://de.wikipedia.org/wiki/Datenkapselung_(Programmierung)

Du trägst gerade Eulen nach Athen.

https://de.wikipedia.org/wiki/Eulen_nach_Athen_tragen

;-)

[Roland F. (rhf)]

Hallo,
Arduino F. schrieb:
> Arduino ist C++ nicht C...

Verwirre ihn nicht noch mehr.

rhf

[Christoph M. (mchris)]

Ralph S. schrieb:
> Wie im Postingstitel geschrieben werden Arduino und struct in einer .ino
> Datei nicht wirklich Freunde werden.

Eine *.ino-Datei ist keine cpp oder c Datei. Die hat ein paar spezielle 
Eigenheiten um den Syntax für die Arduinonutzer zu vereinfachen.

Du kannst aber in jedem Arduinoprojekt eine *.cpp, *.h, *.c Datei 
anlegen per "#include" einbinden (bei *.c "extern C" nicht vergessen). 
Dann verhält sich das Projekt genau wie bei jedem anderen C- oder cpp 
Projekt.

Um alle Arduino-Defines verfügbar zu haben, brauchst du dann noch 
#include "Arduino.h".

[Roland F. (rhf)]

Hallo,
Nick schrieb:
> Ich helf dir kurz:...

Wenn du wirklich Hilfe suchst, würde ich dir dringend empfehlen hier 
etwas weniger überheblich aufzutreten. Glaub mir, die Allermeisten hier 
brauchen deine Hilfe definitiv nicht (und der Angesprochene schon gar 
nicht).

Und im Übrigen sollte jemand, der so selbstbewusst daher kommt wie du, 
zumindest die Grundlagen der verwendeten Programmiersprache beherrschen.

rhf

[Arduino F. (Firma: Gast) (arduinof)]

Christoph M. schrieb:
> Eine *.ino-Datei ist keine cpp oder c Datei.

Der Arduino Builder wandelt die *.ino in eine *.cpp um.
Es ist hinreichend dokumentiert, was der Builder tut.
Kann man ruhig mal lesen.

[Nick (b620ys)]

Roland F. schrieb:
> Wenn du wirklich Hilfe suchst,

Ich such keine Hilfe.

Roland F. schrieb:
> würde ich dir dringend empfehlen hier
> etwas weniger überheblich aufzutreten.

Aha.

Falk B. schrieb:
> Bist du so dumm oder tust du nur so?

Falk B. schrieb:
> Du mußt es wissen.

Falk B. schrieb:
> Du trägst gerade Eulen nach Athen.

Aber gleichzeitig fordern typedefs prinzipiell in header zu schreiben. 
Da scheint mir jede weiteres Diskussion sinnlos.

[Alexander (alecxs)]

Christoph M. schrieb:
> Du kannst aber in jedem Arduinoprojekt eine *.cpp, *.h, *.c Datei
> anlegen per "#include" einbinden

lies bitte noch mal das OP

[Peter (pittyj)]

Arduino F. schrieb:

> Arduino ist C++ nicht C, zumindest in *.ino, *.pde und *.cpp Dateien.
>

Und statt struct nimmt man dann eine class. Die bietet einige Vorteile.

Ich habe hier noch einen K&R von 1983 stehen. Trotzdem bevorzuge ich die 
Klassen. Man muss es ja nicht mit templates und Lambdas übertreiben.

[Arduino F. (Firma: Gast) (arduinof)]

Ralph S. schrieb:
> Die sauberste Lösung ist dann wohl am ehesten, den struct in eine eigene
> .h Datei auszulagern, aber: will ein Arduino-User das? Mit mehr als
> einer Datei hantieren.

Erst den richtigen Weg erkennen, und danach, im gleichen Satz, voll das 
Arduino Bashing.
Also Nein!
Nicht alle Arduino User sind so blöd wie du dir das wünscht!

[Kilo S. (kilo_s)]

Nick schrieb:
> Aha. Man muss also Sachen die lediglich in einer Datei verwendet werden
> und die Benutzer nichts angehen, veröffentlichen.

Boar, gibt selten Leute denen ich empfehle es einfach sein zu lassen.
Aber wer sogar zu doof ist ne lokale Datei anzulegen und zu verwenden 
gehört definitiv dazu.

Leg die .h mit in deinen Sketchorder:

#include "ZuDoofUmPunktHEinzubinden.h"

Und freu dich das die Funktionen in deiner .ino verfügbar sind!

https://docs.arduino.cc/language-reference/en/structure/further-syntax/include/

[Niklas G. (erlkoenig)]

Peter schrieb:
> Und statt struct nimmt man dann eine class. Die bietet einige Vorteile.

Welche? struct und class machen genau das Gleiche, nämlich eine Klasse 
definieren. In C++ gibt's keine structs, nur Klassen. Das 
"struct"-Keyword ist fast ein Alias für das "class" Keyword. Bei struct 
sind die Member per default public, und ich glaub es werden IIRC ein 
paar default Konstruktoren angelegt... Aber im Endeffekt kann man mit 
beiden Keywords exakt das gleiche erzielen.

Man kann "struct" zur Dokumentation nutzen um anzudeuten dass es sich um 
eine simple "Datenklasse" handelt, eben so wie man struct in C 
verwendet.

[Arduino F. (Firma: Gast) (arduinof)]

Nick schrieb:
> Aha. Man muss also Sachen die lediglich in einer Datei verwendet werden
> und die Benutzer nichts angehen, veröffentlichen.

Nein!
Natürlich kannst du struct Definitionen auch in *.cpp Dateien 
verstecken.
Aber sonderlich sinnvoll ist das meist nicht.

[Christoph M. (mchris)]

Alexander schrieb:
> lies bitte noch mal das OP

Was soll das sein? Drück dich bitte präzise aus.

[Nick (b620ys)]

Kilo S. schrieb:
> Nick schrieb:
>> Aha. Man muss also Sachen die lediglich in einer Datei verwendet werden
>> und die Benutzer nichts angehen, veröffentlichen.
>
> Boar, gibt selten Leute denen ich empfehle es einfach sein zu lassen.

Was war jetzt nochmal dein Argument dafür unnötig lokale Informationen 
nach aussen hin sichtbar zu machen?
Dummheit? Datenkapselung? Schlechte Interfaces?

Kilo S. schrieb:
> #include "ZuDoofUmPunktHEinzubinden.h"

oder nur mangelnde persönliche Reife?

[Kilo S. (kilo_s)]

Nick schrieb:
> Was war jetzt nochmal dein Argument dafür unnötig lokale Informationen
> nach aussen hin sichtbar zu machen?

Google mal ob du meine lokalen includes irgendwo in Arduino oder online 
findest! (Tipp: du wirst Jahrhunderte suchen und meine Dateien nicht 
finden! Außer der VapeDisplayDriver.h und fontandcolor.h , die liegen 
hier im Forum im Beitrag zur 25k Vape.)

Dateinamen: py32f030k28_vCustom.h, dbgmcu.h, Interface.h

Alle diese Dateien enthalten unter anderem Code workaround speziell für 
die Macken des PYDuino core.

[Nick (b620ys)]

Arduino F. schrieb:
> Natürlich kannst du struct Definitionen auch in *.cpp Dateien
> verstecken.

OK. Man kann und soll sogar.

> Aber sonderlich sinnvoll ist das meist nicht.

Wenn man sich keine Gedanken zu seinen Interfaces macht, dann kann man 
das so sehen.

Wenn ich nochmal auf Datenkapselung hinweisen darf?
Das Konzept wird ja noch weitergeführt in OOP. Nach aussen hin so wenig 
wie möglich und nur so viel wie nötig preisgeben. Andere Sprachen 
ermöglichen sogar lokale Funktionen/Prozeduren. Das erhöht die 
Lesbarkeit und Wartbarkeit. Manchen mag das egal sein, Hauptsache es 
läuft.

Oder verwendest du nur globale Variablen, statt lokaler (ggf. sogar nur 
innerhalb eines Blocks)?
Ich nehme mal an, dass nicht. Aber dann gilt das gleiche Argument auch 
für die header.

[Harry L. (mysth)]

Nick schrieb:
> Arduino F. schrieb:
>> Natürlich kannst du struct Definitionen auch in *.cpp Dateien
>> verstecken.
>
> OK. Man kann und soll sogar.
>
>> Aber sonderlich sinnvoll ist das meist nicht.
>
> Wenn man sich keine Gedanken zu seinen Interfaces macht, dann kann man
> das so sehen.
>
> Wenn ich nochmal auf Datenkapselung hinweisen darf?
> Das Konzept wird ja noch weitergeführt in OOP. Nach aussen hin so wenig
> wie möglich und nur so viel wie nötig preisgeben. Andere Sprachen
> ermöglichen sogar lokale Funktionen/Prozeduren. Das erhöht die
> Lesbarkeit und Wartbarkeit. Manchen mag das egal sein, Hauptsache es
> läuft.
>
> Oder verwendest du nur globale Variablen, statt lokaler (ggf. sogar nur
> innerhalb eines Blocks)?
> Ich nehme mal an, dass nicht. Aber dann gilt das gleiche Argument auch
> für die header.

Lern erstmal, den Unterschied zwischen "Definition" und "Deklaration" zu 
verstehen, bevor du dich hier so weit aus dem Fenster lehnst, und so 
einen Bullshit verzapfst!

Das ist einfach nur noch peinlich!

[Arduino F. (Firma: Gast) (arduinof)]

Nick schrieb:
> Man kann und soll sogar.

Die "Regeln" sind sowohl logisch, als auch sinnvoll!

Wird die Struktur in nur einer *.c oder *.cpp Datei benötigt, dann 
bringt man sie da unter.

Wird die Struktur in in mehreren *.c oder *.cpp Dateien benötigt, dann 
sollte man sie in einer *.h unterbringen.

[Alexander (alecxs)]

Kilo S. schrieb:
> Google mal ob du meine lokalen includes irgendwo in Arduino oder online
> findest! (Tipp: du wirst Jahrhunderte suchen und meine Dateien nicht
> finden!

ChatGPT hat mir die Dateien gegeben und dazu erzählt es hätte diese erst 
kürzlich erstellt.

[Arduino F. (Firma: Gast) (arduinof)]

Christoph M. schrieb:
> Du kannst aber in jedem Arduinoprojekt eine *.cpp, *.h, *.c Datei
> anlegen per "#include" einbinden

*.c oder *.cpp Dateien per include einbinden führt ganz schnell zu 
vielen Linker Errors. Bitte nachlesen, was der Bilder tut.

[Kilo S. (kilo_s)]

Alexander schrieb:
> ChatGPT hat mir die Dateien gegeben und dazu erzählt es hätte diese erst
> kürzlich erstellt.

Zeig mal den Inhalt.

[Nick (b620ys)]

Arduino F. schrieb:
> Wird die Struktur in nur einer *.c oder *.cpp Datei benötigt, dann
> bringt man sie da unter.

Dann sind wir uns ja einig.
Und damit ist die "Lösung" den typedef in einen header zu schreiben 
(beim Beispiel des TO) eben nur eine unsaubere Lösung.

Harry L. schrieb:
> Lern erstmal, den Unterschied zwischen "Definition" und "Deklaration" zu
> verstehen, bevor du dich hier so weit aus dem Fenster lehnst, und so
> einen Bullshit verzapfst!

Bist du jetzt schon argumentativ im Endschalter?
Nirgendwo hab ich in meiner Antwort Definition oder Deklaration 
verwendet.

Harry L. schrieb:
> Das ist einfach nur noch peinlich!

Also du bist am Anschlag. Danke, aber das hab ich schon gemerkt.

[Arduino F. (Firma: Gast) (arduinof)]

Nick schrieb:
> Dann sind wir uns ja einig.
> Und damit ist die "Lösung" den typedef in einen header zu schreiben
> (beim Beispiel des TO) eben nur eine unsaubere Lösung.

Nein!
Die Fehler Meldungen im Eingangsposting sagen ganz klar, dass da der 
Bock geschossen wird.
Dummer weise, hat es der TO vermieden ein testbares Beispiel zu liefern.
Außer jammern und Prosa ist da nix.

[Alexander (alecxs)]

Kilo S. schrieb:
> Zeig mal den Inhalt.

[Nick (b620ys)]

Arduino F. schrieb:
> Nick schrieb:
>> Dann sind wir uns ja einig.
>> Und damit ist die "Lösung" den typedef in einen header zu schreiben
>> (beim Beispiel des TO) eben nur eine unsaubere Lösung.
>
> Nein!

Arduino F. schrieb:
> Wird die Struktur in nur einer *.c oder *.cpp Datei benötigt, dann
> bringt man sie da unter.

Na gut.

[Kilo S. (kilo_s)]

;-) hihi, nette Idee.

ChatGPT kann dir die nicht geben, das erstellt höchstens gleichnamige 
Dateien mit viel falschem STM Registerzeug, wenn du dem nicht Quasi 
einprügelst das es Air001 verwendet, baut es nur scheiße zusammen.

[Kilo S. (kilo_s)]

Ist eher mein geschmack:

unsigned char kilo[] = {
  0x68, 0x74, 0x74, 0x70, 0x73, 0x3A, 0x2F, 0x2F,
  0x74, 0x69, 0x6E, 0x79, 0x75, 0x72, 0x6C, 0x2E,
  0x63, 0x6F, 0x6D, 0x2F, 0x34, 0x68, 0x34, 0x6D,
  0x76, 0x64, 0x72, 0x65, 0x0D, 0x0A
};

[Georg M. (g_m)]

Es stehen folgende Unterforen zur Auswahl:

Forum: Mikrocontroller und Digitale Elektronik
Für alle Fragen rund um Mikrocontroller und sonstige digitale 
Elektronik.

Forum: Compiler & IDEs
Fragen zu Compilern und Entwicklungsumgebungen für Mikrocontroller, z.B. 
GCC.

Forum: PC-Programmierung
Programmierung auf PCs, Algorithmen, allgemeine Programmierfragen ohne 
direkten Mikrocontroller-Bezug.

[Alexander (alecxs)]

Kilo S. schrieb:
> Ist eher mein geschmack

Rickrolling passt dann aber nicht mehr, dann musst Du Dir ein eigenes 
Meme ausdenken

https://www.mikrocontroller.net/topic/goto_post/7935049

[Norbert (der_norbert)]

Kilo S. schrieb:
> Ist eher mein geschmack:unsigned char kilo[] = {
>   0x68, 0x74, 0x74, 0x70, 0x73, 0x3A, 0x2F, 0x2F,
>   0x74, 0x69, 0x6E, 0x79, 0x75, 0x72, 0x6C, 0x2E,
>   0x63, 0x6F, 0x6D, 0x2F, 0x34, 0x68, 0x34, 0x6D,
>   0x76, 0x64, 0x72, 0x65, 0x0D, 0x0A
> };

unsigned? ;-)

[Kilo S. (kilo_s)]

Norbert schrieb:
> unsigned? ;-)

Hab nur eben die Bytes getauscht, Rest ungelesene übernommen. ;-D

Funktioniert ja trotzdem auch wenn const char richtig wäre.
Wenn ich das auf dem PY32 MCU machen würde, wäre es sogar

static const char kilo[] = ...

RAM sparen. ;-)

[Arduino F. (Firma: Gast) (arduinof)]

Kilo S. schrieb:
> Ist eher mein geschmack:

Naja...
Wenn Arduino/C++ dann doch eher:

constexpr unsigned char kilo[] 
{
  0x68, 0x74, 0x74, 0x70, 0x73, 0x3A, 0x2F, 0x2F,
  0x74, 0x69, 0x6E, 0x79, 0x75, 0x72, 0x6C, 0x2E,
  0x63, 0x6F, 0x6D, 0x2F, 0x34, 0x68, 0x34, 0x6D,
  0x76, 0x64, 0x72, 0x65, 0x0D, 0x0A,
};

oder?

[Nick (b620ys)]

Kilo S. schrieb:
> Funktioniert ja trotzdem auch wenn const char richtig wäre.

Wenn man uint8_t noch nicht kennt...

[Arduino F. (Firma: Gast) (arduinof)]

Nick schrieb:
> Wenn man uint8_t noch nicht kennt...
Und dann, wenn man Glück hat, muss man feststellen, dass es das nicht 
überall gibt.

[Ralph S. (jjflash)]

Arduino F. schrieb:
> Erst den richtigen Weg erkennen, und danach, im gleichen Satz, voll das
> Arduino Bashing.
> Also Nein!
> Nicht alle Arduino User sind so blöd wie du dir das wünscht!

Sorry, wenn das so rüber gekommen ist, das soll mit Bashing nichts zu 
tun haben. Ich habe hier etwas angefangen (eben in Arduino) und möchte 
das eben so auch machen, auch wenn das nicht für mich ist.

Und ich möchte das so gut ich das kann machen und ich möchte das so 
angenehm für einen Arduino User machen wie es geht. Hier stellt sich mir 
die Frage schlicht, wie fängt ein Arduino User an. Er fängt erst einmal 
mit nichts an und weiß auch wenig und er weiß auch noch nicht wirklich 
was eine Inlcude-Datei ist und was da hinein gehört und was nicht. Er 
wird nur die eine .ino Datei bearbeiten.

Erst im Laufe der Zeit wird er sich vllt. Gedanken darüber machen, wie 
Libraries aufgebaut sind, was ein Objekt, eine Objektinstanz ein 
Konstruktor etc. ist. Er wird erst später verstehen, dass er in seinem 
Ordner seines Projekts nicht nur die .ino Datei liegen haben kann.

Ich habe schon ausgefeilte Algorithmen und Codes in Arduino gesehen, bei 
denen ich gedacht habe: wow.... aber ich habe auch gestaunt über die Art 
und Weise, wie der Code aufgebaut war.

Von daher: nein, das soll hier kein Bashing sein und schon gar nicht 
halte ich die Arduino-User für blöd. Je mehr ich mich damit momentan 
beschäftige, umso mehr kann ich auch verstehen, dass da manche 
begeistert sind, auch wenn es genügend Einschränkungen gibt.

Wenn man ein Bashing vornehmen möchte (und eigentlich auch kann), dann 
in der Richtung, dass es immer häufiger moderne Chips gibt, die auf ein 
Board geklatscht werden und dann gibt es einen unausgegorenen Core der 
oft (ogt != selten) nicht das tut was er soll.

Arduino F. schrieb:
> Die Fehler Meldungen im Eingangsposting sagen ganz klar, dass da der
> Bock geschossen wird.
> Dummer weise, hat es der TO vermieden ein testbares Beispiel zu liefern.
> Außer jammern und Prosa ist da nix.

:-) nein, der TO war mit seiner Frau einkaufen ... :-)) zudem hat er 
sich entschlossen, dass in seinen Tests erst einmal mit 
Funktionsprototypen zu machen, weil die Dinge die er testet, erst einmal 
in den Structs belässt und dann später sowieso Bestandteil einer Klasse 
werden. Und, ich muß jetzt irgendwie über mich selbst lachen: ich habe 
jetzt das ganze ohne Zeiger gemacht und das funktioniert dann erst 
einmal (von daher ist mein "Problem" gelöst), Die Diskussion hier find 
ich gar nicht mal so schlecht, nur der Ton ist gewohnt 
superklasseroberaffentittengeil-gut ... oder auch nicht !

Ach so, ja, bevor gemeckert wird, ein (leider) funktionsfährig und 
compilierbares Testprogramm:

typedef struct

{
  int x1, y1;
  int x2, y2;
  int upborderattr;
  int dwnborderattr;
  int txfieldattr;
} txbox_t;

txbox_t tbox;

void ansi_txbox(txbox_t box)
{
  int x;
  
  x= box.x1;
  Serial.println("\n\r Nur eine Testausgabe \n\r");
}

void setup() 
{
  Serial.begin(115200);

  tbox.x1= 0; tbox.y1= 0;
  tbox.x2= 40; tbox.y2= 10;
  tbox.txfieldattr= 0x70;
  tbox.upborderattr= 0xae;
  tbox.dwnborderattr= 0x2e;  
  
  ansi_txbox(tbox);
}

void loop() 
{
}

[Hans W. (hanswieland)]

>> Wenn man uint8_t noch nicht kennt...
Arduino F. schrieb:

> Und dann, wenn man Glück hat, muss man feststellen, dass es das nicht
> überall gibt.

Nenne mal ein nachvollziehbares Beispiel aus diesem Jahrtausend.

[Falk B. (falk)]

Ralph S. schrieb:

> Und ich möchte das so gut ich das kann machen und ich möchte das so
> angenehm für einen Arduino User machen wie es geht.

Ja, aber.

> Hier stellt sich mir
> die Frage schlicht, wie fängt ein Arduino User an. Er fängt erst einmal
> mit nichts an und weiß auch wenig und er weiß auch noch nicht wirklich
> was eine Inlcude-Datei ist und was da hinein gehört und was nicht. Er
> wird nur die eine .ino Datei bearbeiten.

Und wo liegt das Problem?

> werden. Und, ich muß jetzt irgendwie über mich selbst lachen: ich habe
> jetzt das ganze ohne Zeiger gemacht und das funktioniert dann erst
> einmal (von daher ist mein "Problem" gelöst),

Das ist ein Irrtum. Denn du sollest mal über das Thema "call by value" 
und "call by reference" nachdenken. Dein Testprogramm schreibt in der 
Funktion
ansi_txbox() auf eine KOPIE der globalen Variable/Struct tbox. Das ist 
mit Sicherheit nicht gewünscht. Ein Lesezugriff wäre OK. Structs KANN 
man als Wert (call by value, KOPIE!) oder als Zeiger auf das Objekt 
(call by reference) als Parameter übergeben. Meistens ist die Referenz 
(Zeiger) besser und vor allem das, was man wirklich will.

> Ach so, ja, bevor gemeckert wird, ein (leider) funktionsfährig und
> compilierbares Testprogramm:typedef struct

Wieso leider? Welche komischen, ästhetischen Ansprüche hast du als 
ANFÄNGER?

> {
>   int x1, y1;
>   int x2, y2;
>   int upborderattr;
>   int dwnborderattr;
>   int txfieldattr;
> } txbox_t;

> txbox_t tbox;

globale Variable

> void ansi_txbox(txbox_t box)
> {
>   int x;
>
>   x= box.x1;

Zugriff auf lokale Kopie in der Funktion. Die verschwindet beim 
Verlassen der Funktion!

>   Serial.println("\n\r Nur eine Testausgabe \n\r");
> }
> void setup()
> {
>   Serial.begin(115200);
>   tbox.x1= 0; tbox.y1= 0;
>   tbox.x2= 40; tbox.y2= 10;
>   tbox.txfieldattr= 0x70;
>   tbox.upborderattr= 0xae;
>   tbox.dwnborderattr= 0x2e;
>
>   ansi_txbox(tbox);

Aufruf mit lokaler Kopie von tbox.

[Nick (b620ys)]

Arduino F. schrieb:
> Und dann, wenn man Glück hat, muss man feststellen, dass es das nicht
> überall gibt.

stdint.h gibts nicht? Aber auf dem Arduino schon.
stdint.h gibts seit C99, also seit 1999. In C++ seit 2005.

Also Pech gehabt.

[Norbert (der_norbert)]

Nick schrieb:
> Wenn man uint8_t noch nicht kennt...

Knapp daneben ist auch vorbei!

[Arduino F. (Firma: Gast) (arduinof)]

Ralph S. schrieb:
> void ansi_txbox(txbox_t box)
Hier würde ich den Copy Construktor vermeiden wollen!

[Nick (b620ys)]

Norbert schrieb:
> Knapp daneben ist auch vorbei!

Wenn du schon weißt, dass Kilo S. uint8_t kennt, dann kannst Du 
sicherlich auch ein gutes Argument bringen, warum man uint8_t nicht 
verwenden sollte.

[Arduino F. (Firma: Gast) (arduinof)]

Nick schrieb:
> stdint.h gibts seit C99, also seit 1999. In C++ seit 2005.

uint8_t ist ein optionaler Datentype.
Steht nicht auf allen Plattformen zur Verfügung.

[Nick (b620ys)]

Arduino F. schrieb:
> Steht nicht auf allen Plattformen zur Verfügung.

Arduino scheidet aber schon mal aus, da gibts ihn.

[Arduino F. (Firma: Gast) (arduinof)]

Nick schrieb:
> Arduino scheidet aber schon mal aus, da gibts ihn.
Da sind so viele µC im Spiel, dass ich da nicht die Hand für ins Feuer 
legen würde.

Was heute noch richtig zu sein scheint, kann morgen schon anders 
aussehen.

[Christoph M. (mchris)]

Ralph S. schrieb:
> Und ich möchte das so gut ich das kann machen und ich möchte das so
> angenehm für einen Arduino User machen wie es geht. Hier stellt sich mir
> die Frage schlicht, wie fängt ein Arduino User an. Er fängt erst einmal
> mit nichts an

Doch, doch: Er nimmt den Mauszeiger und bewegt ihn auf das 
Drop-Down-Menu, bei dem "examples" steht, denn es gilt: Ein Beispiel 
sagt mehr als 1000 Worte.

Ralph S. schrieb:
> Und, ich muß jetzt irgendwie über mich selbst lachen: ich habe
> jetzt das ganze ohne Zeiger gemacht und das funktioniert dann erst
> einmal (von daher ist mein "Problem" gelöst)

Zeiger sollte man in der Arduinowelt möglichst vermeiden (und das geht 
auch meistens).

[Nick (b620ys)]

Arduino F. schrieb:
> Da sind so viele µC im Spiel, dass ich da nicht die Hand für ins Feuer
> legen würde.

Dann probier's aus und meld dich dann wieder.

Übrigens:
Wenns keinen unit8_t gibt ist die Verwendung von unsigned char auch 
sinnlos. Wobei ich das Gewurstle von "unsigned char" und "long long" 
etc. schon immer sinnlos fand.
Aber zumindest weiß man es dann nicht. Das hilft ja Einigen schon 
weiter.

[Maxim B. (max182)]

Christoph M. schrieb:
> Zeiger sollte man in der Arduinowelt möglichst vermeiden

Nachdem ich HAL für STM32 etwas genauer angekuckt habe, sehe ich, daß 
Zeiger auf Structur viele Aufgaben erleichtern könnten und auch manche 
Fehler vermeiden helfen.
Da Arduino GIGA mit STM32H747 bestückt wird, liegt auf der Hand, daß 
HAL-Vorgehensweise auch für Arduino nicht uninteressant wird.

[Ralph S. (jjflash)]

Falk B. schrieb:
> ansi_txbox() auf eine KOPIE der globalen Variable/Struct tbox. Das ist
> mit Sicherheit nicht gewünscht. Ein Lesezugriff wäre OK. Structs KANN
> man als Wert (call by value, KOPIE!) oder als Zeiger auf das Objekt
> (call by reference) als Parameter übergeben. Meistens ist die Referenz
> (Zeiger) besser und vor allem das, was man wirklich will.

ich weiß, und das ist am Schluß auch nicht gewünscht und wird dann in 
einer Klasse garantiert einen Zeiger haben. Es ging darum, einen 
compilierbaren Code zu haben.

Arduino F. schrieb:
> Ralph S. schrieb:
>> void ansi_txbox(txbox_t box)
> Hier würde ich den Copy Construktor vermeiden wollen!

Wie oben schon für Falk geschrieben wird es das auch werden...

Christoph M. schrieb:
> Zeiger sollte man in der Arduinowelt möglichst vermeiden (und das geht
> auch meistens).

Das ist mir aber nun wirklich neu, dass man keine Zeiger verwenden soll 
!

by the way, damit (hoffentlich) Friede herrscht, mittels Zeiger (an 
chris: ohne Zeiger werde ich sicherlich nichts machen):

typedef struct

{
  int x1, y1;
  int x2, y2;
  int upborderattr;
  int dwnborderattr;
  int txfieldattr;
} txbox_t;

txbox_t tbox;

void ansi_txbox(const txbox_t *box)
{
  int x;
  
  x= box->x1;
  Serial.println("\n\r Nur eine Testausgabe \n\r");
  Serial.print(x);
  Serial.println(" : end of program");
}


void setup() 
{
  Serial.begin(115200);

  tbox.x1= 12; tbox.y1= 0;
  tbox.x2= 40; tbox.y2= 10;
  tbox.txfieldattr= 0x70;
  tbox.upborderattr= 0xae;
  tbox.dwnborderattr= 0x2e;  
  
  ansi_txbox(&tbox);
}


void loop() 
{
}

[Arduino F. (Firma: Gast) (arduinof)]

struct TxBox
{
  int x1, y1; //class/struct Point
  int x2, y2; //class/struct Point
  int upBorderAttr;
  int dwnBorderAttr;
  int txFieldAttr;
};

TxBox tbox 
{
  x1:  0,
  y1:  0,
  x2: 40,
  y2: 10,
  upBorderAttr:  0x70,
  dwnBorderAttr: 0xae,
  txFieldAttr:   0x2e
};

void ansiTxBox(const TxBox &box)
{
  int x; 
  
  x= box.x1;
  Serial.println("\n\r Nur eine Testausgabe \n\r");
}

void setup() 
{
  Serial.begin(115200);
  ansiTxBox(tbox);
}

void loop() 
{
}

[Klaus H. (klummel69)]

Zu stdint.h:

Ich kenne keinen einzigen C Compiler der diese Header Datei nicht hat. 
Selbst uralte Dinger haben das.

Ist ja keine Änderung am Compiler sondern eine einfache Header Datei die 
halt an den Compiler/Architektur angepasst wird.

[Rolf (rolf22)]

> Das ist mir aber nun wirklich neu, dass man keine Zeiger
> verwenden soll !

Du hast anscheinend noch kein Lehrbuch über C++ gelesen. Sonst wüsstest 
du, dass man in C++ die von C geerbten "rohen" Zeiger nur in bestimmten 
Fällen nutzt. Ansonsten nimmt man die sogenannten Smart Pointer.

Und du wüsstest dann auch, dass man deinen Beispielcode ganz einfach 
ohne Zeiger schreiben kann, ohne ihn länger oder unübersichtlicher zu 
machen. Der Zeiger dort ist völlig überflüssig: Es geht auch mit einer 
Referenz.
Hier zeigt dir das ein Profi:
Beitrag "Re: Arduino und struct gefallen sich nicht !"

[Arduino F. (Firma: Gast) (arduinof)]

Klaus H. schrieb:
> Ich kenne keinen einzigen C Compiler der diese Header Datei nicht hat.
Es dreht sich doch gar nicht um die Datei selber, sondern eher darum was 
da drin steht!

CHAR_BIT aus limits.h sagt dir wieviel Bit ein char hat.
Wenn ungleich 8, dann gibts auch kein uint8_t.
Früher recht üblich, dass es sowas gab.
Und ist für die Zukunft nicht ausgeschlossen.
Weder C noch C++ legen sich da fest.

[Kilo S. (kilo_s)]

Nick schrieb:
> Wenn man uint8_t noch nicht kennt...

Ist kein FW blob, keine Rohdaten, keine Register Map.

Warum sollte ich zur Ausgabe per UART konvertieren wollen?

Kein strlen möglich!

Arduino F. schrieb:
> Naja...
> Wenn Arduino/C++ dann doch eher:

Weil const auch mit älteren Cores funktioniert. ;-)

[Arduino F. (Firma: Gast) (arduinof)]

Ralph S. schrieb:
> Das ist mir aber nun wirklich neu, dass man keine Zeiger verwenden soll

Die C Zeigerwirtschaft ist ein steter Quell von üblen Effekten.
Memory leaks
Bereichsüberschreitungen
Endlose Debugsitzungen
usw.

Wenn man Zeiger vermeiden kann, dann sollt man das auch tun.
C++ bietet da deutlich bessere Möglichkeiten, als C.
Das erleichtert das Leben ungemein.

[Nick (b620ys)]

Kilo S. schrieb:
> Kein strlen möglich!

Steht ja auch kein x00 in deinem Beispiel mit lauter hex-zahlen.

Kilo S. schrieb:
> Ist kein FW blob, keine Rohdaten, keine Register Map.

Aber integers in deinem Beispiel.
Eventuell könntest du ja auch "https://tinyurl.c*m/4h4mvdre"; schreiben. 
Könnte leserlicher sein. Die \n \r schenk ich dir zu dem kostenlosen Tip 
noch mit dazu.

Kilo S. schrieb:
> Warum sollte ich zur Ausgabe per UART konvertieren wollen?

Da gibts nix zu konvertieren. Nochdazu gibst du deine Daten in Bytes an 
um Platz zu sparen. Um das sicherzustellen, dass tatsächlich Platz 
gespart wird, verwendet man uint8_t. Die Größe von char ist 
implementationsabhängig, uint8_t ist garantiert ein Byte groß.

Genial ist dein Schachzug zuerst einen String in hex zu wandeln und dann 
zu merken, dass strlen nicht funktioniert, stattdessen sizeof verwenden 
zu müssen und dann Zeichen für Zeichen in die UART zu schubsen.

[Hans W. (hanswieland)]

Arduino F. schrieb:
> uint8_t ist ein optionaler Datentype.
> Steht nicht auf allen Plattformen zur Verfügung.

Ich hake nochmal nach: Nenne bitte ein nachvollziehbares Beispiel aus 
diesem Jahrtausend.

[Alexander (alecxs)]

Nick schrieb:
> Aber integers in deinem Beispiel.
> Eventuell könntest du ja auch "https://tinyurl​.com/4h4mvdre"; schreiben.
> Könnte leserlicher sein.

Du hast nicht verstanden worum es ging. Das ist auch gar nicht das 
original.

[Arduino F. (Firma: Gast) (arduinof)]

Nick schrieb:
> stattdessen sizeof verwenden
> zu müssen und dann Zeichen für Zeichen in die UART zu schubsen.

sizeof ist auch oft ein Ort für vertippsler.

Seit C++11 kann man den "range based for loop" verwenden.

Oder per constexpr Template Funktion die Array Größe ermitteln.

[Hans W. (hanswieland)]

Rolf schrieb:
> Und du wüsstest dann auch, dass man deinen Beispielcode ganz einfach
> ohne Zeiger schreiben kann, ohne ihn länger oder unübersichtlicher zu
> machen. Der Zeiger dort ist völlig überflüssig

Letztendlich sind Referenzen nur eine Variante von Zeigern, und im 
Maschinencode sogar exakt das Gleiche, egal wie sehr fragwürdige 
Lehrbücher das zu leugnen versuchen. Man hat aus einigen Ideen eine 
krampfhafte Lehre gemacht. Zum Glück muss sich niemand daran halten. Und 
nein, Arduino ist keine Gotteslästerei.

Lest mal Bücher von Bjarne Stroustrup nach dem Jahr 2000. Er geht mit 
seiner eigenen Arbeit nachträglich viel entspannter um, als so mancher 
seiner Jünger.

[Arduino F. (Firma: Gast) (arduinof)]

Hans W. schrieb:
> Letztendlich sind Referenzen nur eine Variante von Zeigern,

Nun ja...
Mit Zeigern kann man deutlich eher dumme Fehler einbauen.

Zudem kann man bei Übergabe per Referenz die Arraygröße im Datentype 
übergeben.
Dieses geht bei der Übergabe per Zeiger verloren.

[Nick (b620ys)]

Alexander schrieb:
> Das ist auch gar nicht das original.

Er hat es als seinen code gepostet.

Arduino F. schrieb:
> sizeof ist auch oft ein Ort für vertippsler.

Was man nicht alles flasch schreiben kann, wenn man muss.

[Arduino F. (Firma: Gast) (arduinof)]

Nick schrieb:
> flasch

Ein einfacher Buchstabendreher kann einen ganzen Sinnzusammenhang 
urinieren.

[Kilo S. (kilo_s)]

Nick schrieb:
> Könnte leserlicher sein.

Das war kurz da hin gerotzt um bei dem Witz zu bleiben.

Hab Gerade gedanklich noch dem RDP1 vom PY32F002A im Hinterkopf und 
finde es erfrischend nebenher immer mal wieder an der Feelin Vape weiter 
zu machen. Dump war ja einfach, nach dem ich endlich den blöden Reset am 
China JLink gefunden habe.

Alexander schrieb:
> Du hast nicht verstanden worum es ging.

Ich kenn ihn auch nur halb, hab trotzdem genug Humor um mal mit zu 
blödeln.

[Ralph S. (jjflash)]

Arduino F. schrieb:
> TxBox tbox
> {
>   x1:  0,
>   y1:  0,
>   x2: 40,
>   y2: 10,
>   upBorderAttr:  0x70,
>   dwnBorderAttr: 0xae,
>   txFieldAttr:   0x2e
> };

nach dieser Methode kann ich aber die Members der Struct im Programm 
nicht mehr ändern

[Arduino F. (Firma: Gast) (arduinof)]

Ralph S. schrieb:
> nach dieser Methode kann ich aber die Members der Struct im Programm
> nicht mehr ändern

Natürlich geht das!

C++ generiert für dich eine Handvoll Konstruktoren und Operatoren.
Automatisch, für jede Struktur und Klasse, wenn du das nicht 
unterbindest, kannst du diese nutzen.

[Johann L. (gjlayde)]

Und was ist jetzt das Problem?

[Arduino F. (Firma: Gast) (arduinof)]

Ihm kann die Members der Struct im Programm nicht mehr ändern!

Sagt/Zeigt aber nicht was er versucht oder erreichen will.

[Bruno V. (bruno_v)]

Kein Problem, nur der Übergang von „IDE macht alles“ oder „alles in ein 
file inkludiert“ zu selbst verwalteten c/cpp und h files.

[Ralph S. (jjflash)]

Johann L. schrieb:
> Und was ist jetzt das Problem?

:-) gute Frage, ich habe keines mehr... hier geht es glaube ich 
grundsätzlich um Mißverständnisse... so irgendwie ...

[Arduino F. (Firma: Gast) (arduinof)]

Ralph S. schrieb:
> hier geht es glaube ich
> grundsätzlich um Mißverständnisse... so irgendwie ...

Verstehe ich nicht!
Ich dachte es geht um Strukturen im Arduino Umfeld.

Aber wenn du meinst.

Nachtrag:
Wenn du Missverständnisse siehst, dann möchte ich dich bitten diese 
aufzulösen, wenn möglich.
Oder wenigstens klar benennen.

[Nick (b620ys)]

Kilo S. schrieb:
> Das war kurz da hin gerotzt um bei dem Witz zu bleiben.

Kilo S. schrieb:
> spi_write_byte(CMD,  0xB0);
>     spi_write_byte(DATA, 0xC0);  // Interface mode
>     spi_write_byte(CMD,  0xB2);  // FRMCTR2 - Frame rate normal mode
>     spi_write_byte(DATA, 0x24);
>     spi_write_byte(CMD,  0xB3);  // FRMCTR3 - Frame rate partial mode
>     spi_write_byte(DATA, 0x03);
>     spi_write_byte(CMD,  0xB7);  // ETMOD - Entry mode
>     spi_write_byte(DATA, 0x01);
>     spi_write_byte(CMD,  0xB6);  // DISSET5 - Display function control
>     spi_write_byte(DATA, 0x19);
>     spi_write_byte(CMD,  0xAC);
>     spi_write_byte(DATA, 0xDB);
undsoweiter ...

Ist das dann auch Rotz oder ist es ein Witz?
Ich hab den Eindruck, dass du beim schreiben nur wenig nachdenkst.

[Harald K. (kirnbichler)]

Ralph S. schrieb:
> nach dieser Methode kann ich aber die Members der Struct im Programm
> nicht mehr ändern

Was soll das heißen?

Weißt Du nicht, wie's geht, oder gibt der Compiler Fehlermeldungen aus?

[Kilo S. (kilo_s)]

Nick schrieb:
> undsoweiter

Dich zu ignorieren wird jedenfalls helfen das ich weniger Mordgelüste 
hab! Mann die Menscheit ist so derbe am Arsch wenn nur noch so Leute wie 
du rumlaufen!

Reiß das nicht aus dem Zusammenhang, deine Möchtegern Konstruktion die 
du hier starten willst kannste dir als Zäpfchen verabreichen!

WAS STEHT OBEN ÜBER DEM CODE?!

Dissasembly lesen und vernünftig rekonstruieren ist nicht meine größte 
Stärke, vor allem weil ich nur sporadisch weiter mache wie ich gerade 
Zeit habe. Der erste Versuch (Grundlagen) war noch mit Forenhilfe, schon 
ne Weile her, dafür hab ich mich allerdings ganz gut erinnern können was 
ich versuchen kann und muss.

Und wenn überhaupt, kaper hier nicht mit dem Code der Nevoks Feeling 
Vape den Thread!

Und wenn du dort schreibst, Konstruktive Sachen, mach einen auf 
Oberlehrer und du kannst gleich weg bleiben!

[Ralph S. (jjflash)]

Harald K. schrieb:
> Ralph S. schrieb:
>> nach dieser Methode kann ich aber die Members der Struct im Programm
>> nicht mehr ändern
>
> Was soll das heißen?
> Weißt Du nicht, wie's geht, oder gibt der Compiler Fehlermeldungen aus?

Arduino F. schrieb:
> Verstehe ich nicht!
> Ich dachte es geht um Strukturen im Arduino Umfeld.
> Aber wenn du meinst.
> Nachtrag:
> Wenn du Missverständnisse siehst, dann möchte ich dich bitten diese
> aufzulösen, wenn möglich.
> Oder wenigstens klar benennen.

doch, ich weiß wie es geht (Schreibfehler bitte entschuldigen, sitze im 
Auto auf dem Handy). Der letzte Programmpost von Arduino F. ist genau 
das, wie ich das zuvor auch gemacht hatte und es aufgrund von dämlichen 
Syntaxfehler von mir Compilerfehler gab. Dann gings hier ab wie Schmidts 
Katze und es waren zu viele Posts auf einmal, während ich noch am 
programmieren war... nicht an der Struktur, sondern an den Funktionen 
selbst. Hm, heute abend vllt. so ein Zwischenpost von dem, an dem ich 
gerade bin... Schmunzeln muß, das ganze nur deshalb, weil in einem 
anderen Tread es um Steuerzeichen cr und lf ging... und welches 
Terminal... hrmpf.. Aber: Arduino F. und Kirnbichler waren sind schon / 
zielführend (oft) und im Fall hier jetzt war Arduino F. der Experte

[Rahul D. (rahul)]

Ralph S. schrieb:
> (Schreibfehler bitte entschuldigen, sitze im Auto auf dem Handy)
LOL *SCNR* interessante "Tippmethode"...

[Arduino F. (Firma: Gast) (arduinof)]

Ralph S. schrieb:
> und im Fall hier jetzt war Arduino F. der Experte

Danke für die Blumen.

Aber in Wirklichkeit ist das nur fundiertes Halbwissen in Sachen C++ und 
Arduino.
Ich helfe gerne bei solchen Themen!

Andere Dinge ignoriere ich meistens noch nicht einmal.

[Veit D. (devil-elec)]

Hallo,

jetzt untertreibt er. Arduino F. weiß schon was er macht.  :-)

[Arduino F. (Firma: Gast) (arduinof)]

Veit D. schrieb:
> Arduino F. weiß schon was er macht.
Meistens!
Habe aber auch meine Grenzen in Wissen und Können.
Bin seit 2014 im C++ und Arduino Umfeld.
Versuche alle Dokumentation aufzusaugen.
Alle C++ Features/Fähigkeiten so lange auszuprobieren/üben, bis sie 
sitzen.

[Ralph S. (jjflash)]

na ja.
:-) C mach ich seit 1985... C++ irgendwann mitte 90er... Das Schlimme 
ist das permanente wechseln der Sprache, weil dazwischen auch immer 
wieder mal Delphi rutscht... und im moment auch noch Javascript. Viele 
Köche verderben den Brei. Für Arduino bin ich ein Anfänger, wie bei 
vielen Frameworks eine Flut von Dateien... Aaaaber so n kleines bischen 
versteh ich die Philosophie dahinter. Hmmm, ich bin mal gespannt, was 
ihr zu meinem Zwischenprojekt, wenn man das so sagen kann, sagen werdet. 
Und alles nur, um mit Arduino Ausgaben auf einem Terminal zu machen.

[Arduino F. (Firma: Gast) (arduinof)]

Ralph S. schrieb:
> C mach ich seit 1985

Kommt bei mir auch so in etwa hin
Bin mit "SCO Xenix 286" in die C/Unix Welt gestolpert.
Später dann "DG/UX"

Ralph S. schrieb:
> Für Arduino bin ich ein Anfänger


Zu Arduino bin ich eher durch Zufall gekommen.
Ein Freund brauchte eine kleine Ablaufsteuerung.
Wusste dass ich viel mit SPS gemacht habe, genauer "PS4 201 MM1".
Hatte noch eine liegen und habe ihm den Preis genannt.
Er ist auf den Rücken gefallen.
Dann in den Keller gerannt, mit den Worten "Ich habe da noch was!"
Ein misslungenes Geburtstagsgeschenk für/von seinem Ableger.
Der ist damit nicht warm geworden.

Ein Arduino UNO Starter Kit.
Mit Taster Kabel Relais und Hundert weiterem Rödel.

Nach ca 1 Stunde liefen die ersten Beispiele.
Nach ca 2 weiteren Stunden, war seine Ablaufsteuerung, noch rudimentär, 
aber funktionsfähig.
Und ich, entgegen meiner anfänglichen Vorbehalte: Begeistert!

[Rahul D. (rahul)]

Ralph S. schrieb:
> :-) C mach ich seit 1985... C++ irgendwann mitte 90er... Das Schlimme
> ist das permanente wechseln der Sprache, weil dazwischen auch immer
> wieder mal Delphi rutscht... und im moment auch noch Javascript.

Dann solltest du dir zur weiteren Verwirrung noch python antun. ;)

[Ralph S. (jjflash)]

Rahul D. schrieb:
> Dann solltest du dir zur weiteren Verwirrung noch python antun. ;)

mag ich schon aufgrund der Einrückungen per Whitespaces nicht... und von 
daher glaube ich, dass ich mit Computersprachen gut bedient bin. 
Allerdings: wenn es irgendwann notwendig sein sollte, dann werde ich 
mich wohl auch noch mit Python beschäftigen.... aber vorerst einmal 
nicht!

[Cyblord -. (cyblord)]

Darf ich die Überschrift mal korrigieren: "Arduino-Nutzer und das Wissen 
um Structs gefallen sich nicht".

[Norbert (der_norbert)]

Ralph S. schrieb:
> mag ich schon aufgrund der Einrückungen per Whitespaces nicht...

In jeder halbwegs akzeptablen Programmiersprache rückt man ein, um sein 
strukturiertes Ansinnen zu verdeutlichen. Python forciert dieses an sich 
sinnvolle Verhalten.

Aber ich gebe es gerne zu, auch ich habe die ersten zwei** Minuten der 
darauf folgenden vielen Tausenden von Stunden gemeckert und mir Gründe 
aus den Fingern gezogen warum ausgerechnet dies nun schlecht sein soll. 
;-)

** Könnten auch zwanzig Minuten gewesen sein.

[Rahul D. (rahul)]

Norbert schrieb:
> In jeder halbwegs akzeptablen Programmiersprache rückt man ein, um sein
> strukturiertes Ansinnen zu verdeutlichen.

Das gilt als guter Stil, den manche gar nicht mögen.

Norbert schrieb:
> Python forciert dieses an sich sinnvolle Verhalten.
Klingt nicht sehr überzeugt.

> Aber ich gebe es gerne zu, auch ich habe die ersten zwei** Minuten der
> darauf folgenden vielen Tausenden von Stunden gemeckert und mir Gründe
> aus den Fingern gezogen warum ausgerechnet dies nun schlecht sein soll.
> ;-)

Wenn man aus der C/C++/C#-Ecke oder von einer anderen Programmiersprache 
mit Semikolon am Ende kommt, ist es etwas gewöhnungsbedürftig.

[Cyblord -. (cyblord)]

Rahul D. schrieb:
>> Python forciert dieses an sich sinnvolle Verhalten.
> Klingt nicht sehr überzeugt.

Egal ob man Einrückungen für sinnvoll hält oder nicht, sie als 
Syntaxelemente der Sprache selbst zu verwenden ist gräßlich.

[Norbert (der_norbert)]

Rahul D. schrieb:
> Wenn man aus der C/C++/C#-Ecke oder von einer anderen Programmiersprache
> mit Semikolon am Ende kommt, ist es etwas gewöhnungsbedürftig.

Kam' ich. Plus Assembler. Plus, plus,… Mindestens zwanzig Jahre lang.

Isses nicht wirklich. Man lässt es einfach weg.

Oder man lässt es da und outet sich als ›Ehemaliger‹. Geht trotzdem.

[Rolf (rolf22)]

Arduino F. schrieb:
> Ein einfacher Buchstabendreher kann einen ganzen Sinnzusammenhang
> urinieren.

Wenn wir schon mal bei dem Thema sind:
Ein Testwort für die Silbentrenn-Funktion von 
Textverarbeitungsprogrammen: Urinstinkt.

[Yalu X. (yalu) (Moderator)]

Norbert schrieb:
> Rahul D. schrieb:
>> Wenn man aus der C/C++/C#-Ecke oder von einer anderen Programmiersprache
>> mit Semikolon am Ende kommt, ist es etwas gewöhnungsbedürftig.
>
> Kam' ich. Plus Assembler. Plus, plus,… Mindestens zwanzig Jahre lang.
>
> Isses nicht wirklich. Man lässt es einfach weg.

Oder man lässt es dran. Python ist diesbezüglich gegenüber Umsteigern
sehr tolerant ;-)

[Rahul D. (rahul)]

Norbert schrieb:
> Kam' ich. Plus Assembler. Plus, plus,… Mindestens zwanzig Jahre lang.

Ja, und dann definiert man eine Funktion in einer Klasse und wundert 
sich, dass deren Aufruf einen Fehler wirft:
Bei jeder klammerorientierten Programmiersprache wäre die Einrücktiefe 
egal.
Hier war die Funktion Teil einer anderen Funktion.
Also alles einen Tab zurücksetzen, damit sie eine Methode innerhalb der 
Klasse und nicht einer anderen Methode ist.
Wer's mag... (oder frei nach Else Kling: "Wenn's schee macht!?")

[Norbert (der_norbert)]

Yalu X. schrieb:
> Oder man lässt es dran. Python ist diesbezüglich gegenüber Umsteigern
> sehr tolerant ;-)

Wenn du nur eine Zeile mehr zitiert hättest… ;-)

[Norbert (der_norbert)]

Rahul D. schrieb:
> Also alles einen Tab zurücksetzen, damit sie eine Methode innerhalb der
> Klasse und nicht einer anderen Methode ist.

Ja, einfach richtig machen und schon geht's.

[Rahul D. (rahul)]

Norbert schrieb:
> Ja, einfach richtig machen und schon geht's.

ja, indem man Klammern verwendet, die die IDE auch passend markiert.

[Norbert (der_norbert)]

Rahul D. schrieb:
> ja, indem man Klammern verwendet, die die IDE auch passend markiert.

Die einen machen's selbst, die anderen verlassen sich auf ihre IDE.

[Rahul D. (rahul)]

Norbert schrieb:
> Die einen machen's selbst, die anderen verlassen sich auf ihre IDE.
Oder der Compiler wirft einen Error, dass die öffnende Klammer nicht 
geschlossen wurde.

Da kann man dann auch gleich Assembler mit Schaltern programmieren und 
das EPROM regelmäßig ins Löschgerät packen. Been there, done it, diddn't 
like it.


Auch, wenn ich mit python so langsam zurecht komme, bis ich die mag, 
wird es noch dauern.
Wenn Niederländer eine Programmiersprache entwickeln... ich habe die 
Vermutung, dass das in einem Coffee-Shop passierte.

[Rolf (rolf22)]

Falk B. schrieb:
> Structs KANN
> man als Wert (call by value, KOPIE!) oder als Zeiger auf das Objekt
> (call by reference) als Parameter übergeben.

Das Wort "Zeiger" kann sehr leicht zu Missverständnissen führen, weil es 
eine Übersetzung von "pointer" ist. Referenzen und Pointer sind aber 
zwei Paar Schuhe:

#include <iostream>

struct myStruct { int a; int b; };

void foo1(myStruct  eins) { std::cout << "value     " << eins.a  << '\n'; }

void foo2(myStruct& zwei) { std::cout << "reference " << zwei.a  << '\n'; }

void foo3(myStruct* drei) { std::cout << "pointer   " << drei->a << '\n'; }


int main()
{  myStruct s = { 33, 44 };

   myStruct* ptr_s = &s;    

   foo1(s);
   foo2(s);
   foo3(ptr_s);
   foo3(&s);
   //foo3(s&); // Fehler
   //foo3(*s); // Fehler
   //foo3(s*); // Fehler
   
    return 0; 
}

// Ergebnis:
//value     33
//reference 33
//pointer   33
//pointer   33

[Yalu X. (yalu) (Moderator)]

Norbert schrieb:
> Yalu X. schrieb:
>> Oder man lässt es dran. Python ist diesbezüglich gegenüber Umsteigern
>> sehr tolerant ;-)
>
> Wenn du nur eine Zeile mehr zitiert hättest… ;-)

Sorry, hatte ich übersehen :)

[Norbert (der_norbert)]

Rahul D. schrieb:
> Oder der Compiler wirft einen Error, dass die öffnende Klammer nicht
> geschlossen wurde.

Oder der Compiler wirft keinen Error, weil die öffnende Klammer 
irrtümlich an der falschen eingerückten Position geschlossen wurde. ;-)
Obwohl's gut aussah…

[Rahul D. (rahul)]

Norbert schrieb:
> Oder der Compiler wirft keinen Error, weil die öffnende Klammer
> irrtümlich an der falschen eingerückten Position geschlossen wurde. ;-)

Man kann sich alles schönreden. Man sollte halt bei der Formatierung 
konsequent sein. Das ist doch das, was so "toll" an python ist.

[Arduino F. (Firma: Gast) (arduinof)]

Rahul D. schrieb:
> Das ist doch das, was so "toll" an python ist.

Mir schmeckt die Sprache nicht.
Mittlerweile habe ich etwas Übung, werde aber nicht warm.
Kein flüssiges Arbeiten.

C++ mit seiner OO und auch Templates, liegt mir da deutlich besser.

[Alexander (alecxs)]

Rolf schrieb:
> Referenzen und Pointer sind aber zwei Paar Schuhe

https://www.mikrocontroller.net/topic/goto_post/8022612

[Arduino F. (Firma: Gast) (arduinof)]

Alexander schrieb:
> Rolf schrieb:
>> Referenzen und Pointer sind aber zwei Paar Schuhe
>
> https://www.mikrocontroller.net/topic/goto_post/8022612

Ich bestätige:
Referenzen und Pointer sind zwei Paar Schuhe.

Wenn du das nicht begreifen willst selber Schuld.

[Norbert (der_norbert)]

Rahul D. schrieb:
> Man kann sich alles schönreden. Man sollte halt bei der Formatierung
> konsequent sein.

Das gilt umgekehrt aber genauso.
Klar, ist nach einer copy'n'paste Aktion noch nie jemandem passiert…
Semikolon am Ende einer ›for‹ Schleife und danach schön eingerückt? 
Klar, ist noch nie jemandem passiert…

Man kann sich in jeder Sprache ins Bein schießen und es nicht sehen. 
Oder erst wenn es blutet. Nennt sich expectation bias.

[Rahul D. (rahul)]

Norbert schrieb:
> Man kann sich in jeder Sprache ins Bein schießen und es nicht sehen.
> Oder erst wenn es blutet. Nennt sich expectation bias.

Was bei klammerorientierten Sprach noch ganz angenehm ist:
Man kann Klammer dazu benutzen, Blöcke zu defininieren, auch wenn das 
gar nicht notwendig ist.
Aber die "Diskussion" hat zu viel philosophisches. Ich mag sie nicht, 
und wie Arduion Fanboy, werde ich mit ihr nicht wirklich warm.
Jeder wie er mag.

[Oliver S. (oliverso)]

Arduino F. schrieb:
> Referenzen und Pointer sind zwei Paar Schuhe.

Eigentlich sinds der rechte und linke Schuh des selben Paars, und noch 
eigentlicher sinds Schuhe, die an beide Füße passen.

Oliver

[Arduino F. (Firma: Gast) (arduinof)]

Oliver S. schrieb:
> Arduino F. schrieb:
>> Referenzen und Pointer sind zwei Paar Schuhe.
>
> Eigentlich sinds der rechte und linke Schuh des selben Paars, und noch
> eigentlicher sinds Schuhe, die an beide Füße passen.

Was soll der Unsinn?
Referenzen können nicht Null werden. Damit fängts schon an.

[Oliver S. (oliverso)]

Arduino F. schrieb:
> Was soll der Unsinn?
> Referenzen können nicht Null werden. Damit fängts schon an.

Ja, aber das ist auch der einzige Unterschied. Der Rest ist syntactical 
sugar.

Oliver

[Johann L. (gjlayde)]

Oliver S. schrieb:
> Arduino F. schrieb:
>> Referenzen können nicht Null werden. Damit fängts schon an.
>
> Ja, aber das ist auch der einzige Unterschied.

Gibt schon noch mehr.  Beispielsweise kann man ein Array von Pointern 
haben aber kein Array von Referenzen.

Einem Zeiger kann man einen neuen Wert zuweisen, einer Referenz nicht 
etc.

[Arduino F. (Firma: Gast) (arduinof)]

Oliver S. schrieb:
> Ja, aber das ist auch der einzige Unterschied.
Bei Übergabe per Pointer geht die Arraygröße verloren. Muss man 
händische als 2ten Parameter nachreichen. Eine üble Fehlerquelle.
Bei Referenzen steckt die Arraygröße im Datentype.

[Veit D. (devil-elec)]

Oliver S. schrieb:
> Arduino F. schrieb:
>> Was soll der Unsinn?
>> Referenzen können nicht Null werden. Damit fängts schon an.
>
> Ja, aber das ist auch der einzige Unterschied. Der Rest ist syntactical
> sugar.
>
> Oliver

Hallo Oliver und auch Hans W.,

nein. Mit syntaktischen Zucker, was man deutsch schreiben darf, sollte 
man das nicht so lässig abtun. Bsp. kann man den Adresswert in der 
Zeigervariable defaultmäßig ändern. Das referenzierte Objekt o.ä. einer 
Referenzvariable dagegen nicht. Da es mit C++ primär um Datenkapselung 
und Sicherheit geht, sollte eine Referenz Vorrang haben. Das Gehampel 
mit dem expliziten Dereferenzierungsoperator fällt auch weg. Der gesamte 
Umgang ist mit Referenzen einfacher und damit weniger bis kaum 
Fehleranfällig. Allein schon deswegen ...

[Rolf (rolf22)]

Oliver S. schrieb:

>> Referenzen können nicht Null werden. Damit fängts schon an.

> Ja, aber das ist auch der einzige Unterschied.

Pointer sind Variablen mit Typ und Speicherplatz, den man im 
Maschinencode sieht. Referenzen haben keinen Speicherplatz und treten im 
Maschinencode gar nicht auf.

> Der Rest ist syntactical sugar.

Logik? Rest? Sobald es mindestens einen Unterschied gibt, den man im 
Maschinencode sehen kann, ist das Ganze kein syntactical sugar.

Klar, der Optimierer kann in manchen(!) Fällen den Unterschied 
wegoptimieren. Das ist hier aber nicht das Thema.

[Oliver S. (oliverso)]

Johann L. schrieb:
> Gibt schon noch mehr.  Beispielsweise kann man ein Array von Pointern
> haben aber kein Array von Referenzen.

Das ist eine direkte Folge dessen, dass es das Null-Element nicht gibt 
(bzw. eine Referenz nicht default-constructible ist).

Johann L. schrieb:
> Einem Zeiger kann man einen neuen Wert zuweisen, einer Referenz nicht
> etc.

Aber sicher geht das.

Arduino F. schrieb:
> Bei Übergabe per Pointer geht die Arraygröße verloren. Muss man
> händische als 2ten Parameter nachreichen. Eine üble Fehlerquelle.
> Bei Referenzen steckt die Arraygröße im Datentype.

#include <iostream>
#include <type_traits>

void foo(auto ar)
{
    std::cout << std::is_same<decltype(ar), int(*)[3]>::value << std::endl;
    std::cout << sizeof(*ar) << std::endl;
}


int main()
{
    int arr[3];
    foo(&arr);
}

;)

Rolf schrieb:
> Pointer sind Variablen mit Typ und Speicherplatz, den man im
> Maschinencode sieht. Referenzen haben keinen Speicherplatz und treten im
> Maschinencode gar nicht auf.

#include <iostream>

int main()
{
    int x = 3;
    int& r = x;

    std::cout << sizeof(r) << std::endl;
}

Oliver

[Oliver S. (oliverso)]

Rolf schrieb:
> Logik? Rest? Sobald es mindestens einen Unterschied gibt, den man im
> Maschinencode sehen kann, ist das Ganze kein syntactical sugar.

https://godbolt.org/z/YefnEerdd

Dann such mal den Unterschied...

Veit D. schrieb:
> Mit syntaktischen Zucker, was man deutsch schreiben darf, sollte
> man das nicht so lässig abtun. Bsp. kann man den Adresswert in der
> Zeigervariable defaultmäßig ändern. Das referenzierte Objekt o.ä. einer
> Referenzvariable dagegen nicht.

Das ändern des Wertes einer Zeigervariablen und das ändern des 
referenzierten Objekts sind aber zwei völlig verschiedene Dinge. Den 
"Wert" einer Referenz kann man durch zuweisen eines anderen 
referenzierten Objekts auch ändern.

Da es mit C++ primär um Datenkapselung
> und Sicherheit geht, sollte eine Referenz Vorrang haben. Das Gehampel
> mit dem expliziten Dereferenzierungsoperator fällt auch weg. Der gesamte
> Umgang ist mit Referenzen einfacher und damit weniger bis kaum
> Fehleranfällig. Allein schon deswegen ...

Da bin ich voll bei dir. Raw pointer kann und sollte man vermeiden. Das 
entkräftet dann auch das Argumemnt, daß ein pointer die 
Größeninformation eines Array nicht enthält. Auch Array sind letzendlich 
raw pointer. Dafür nimmt man besser std::vector.

Oliver

[Rolf (rolf22)]

Oliver S. schrieb:
>

> #include <iostream>
> 
> int main()
> {
>     int x = 3;
>     int& r = x;
> 
>     std::cout << sizeof(r) << std::endl;
> }
>

Ausgegeben wird 4, sieht aus wie die Größe eines Pointers? Machen wir 
vorsichtshalber mal eine andere Probe:

#include <iostream>
int main()
{
    char x = 'A';
    char& r = x;
    
    std::cout  << sizeof(r);
}

Da erscheint 1 als Ergebnis, also steht r nicht für einen Speicherplatz, 
in dem ein Pointer PLatz hätte.

[Hans W. (hanswieland)]

Rolf schrieb:
> also steht r nicht für einen Speicherplatz,
> in dem ein Pointer PLatz hätte.

Wer lesen kann, denn sollte das nicht überraschen. Denn in der Doku 
steht:

> When applied to a reference type, the result is the size of the referenced type.
https://en.cppreference.com/w/cpp/language/sizeof.html

[Oliver S. (oliverso)]

Nee, da wird die Größe der referenzierten Variable ausgegeben, das 
ändert aber nichts daran, daß Referenzen „under the hood“ nichts anders 
als Pointer sind.

Oliver S. schrieb:
> Johann L. schrieb:
>> Einem Zeiger kann man einen neuen Wert zuweisen, einer Referenz nicht
>> etc.
>
> Aber sicher geht das.

Um das noch etwas zu präzisieren: „natürlich“ war natürlich etwas 
überspitzt. Seit C++20 ist das möglich, von hinten durch die Brust ins 
Auge, mit placement new. Ist aber irgendwie ein unschöner Hack, auch 
wenns kein UB ist.

Näheres hier:
https://stackoverflow.com/questions/7181372/why-can-i-assign-a-new-value-to-a-reference-and-how-can-i-make-a-reference-refe

Ob mans im realen Leben braucht? Wohl eher nicht.

Oliver

[Rolf (rolf22)]

Oliver S. schrieb:
> Nee, da wird die Größe der referenzierten Variable ausgegeben
Eben, und deshalb hat dein Beispiel nicht das bewiesen, was du beweisen 
wolltest.

> das ändert aber nichts daran, daß Referenzen „under the hood“ nichts
> anders als Pointer sind.

"Unter der Haube" kann vieles bedeuten. Die Frage ist, wer wann was tut.

Bei Zeigervariablen wird die Verbindung zum referenzierten Objekt im 
Normalfall erst zur Laufzeit hergestellt, also dynamisch zum Zeitpunkt 
des Zugriffs. Zur Übersetzungszeit ist der Inhalt einer Zeigervariable 
im Allgemeinen unbekannt.
Bei Referenzen stellt der Compiler die Verbindung schon zur 
Übersetzungszeit her. Anders gesagt, die Adresse des Zielobjekts ist dem 
Compiler bekannt, sie muss nicht erst zur Laufzeit durch Auslesen einer 
Zeigervariablen beschafft werden.

Zwar kann man das Ziel einer Referenz umdefinieren, aber das passiert 
dann genau dort, wo es im Quelltext steht. Deswegen braucht man dafür 
keinen speziellen Speicherplatz für einen Zeiger, wie man ihn für eine 
Zeigervariable braucht.

[Veit D. (devil-elec)]

Oliver S. schrieb:
> Das ändern des Wertes einer Zeigervariablen und das ändern des
> referenzierten Objekts sind aber zwei völlig verschiedene Dinge. Den
> "Wert" einer Referenz kann man durch zuweisen eines anderen
> referenzierten Objekts auch ändern.

Hallo Oliver,

ich denke wir reden etwas aneinander vorbei.

#include <iostream>
using namespace std;

int var1 {16};
int var2 {32};

int main()
{
  // --- mit Referenz --- //
  cout << "--- mit Referenz ---" << endl;
  int &refVar {var1};
  cout << "var1   " << var1 << endl;
  cout << "refVar " << refVar << endl;
  refVar = var2;
  cout << "refVar " << refVar << endl;
  //refVar = &var2;   // Error

  // Ausgangszustand herstellen //
  var1 = 16;
  var2 = 32;

  // --- mit Zeiger --- //
  cout << "--- mit Zeiger ---" << endl;
  cout << "addr von var1 " << &var1 << endl; 
  cout << "addr von var2 " << &var2 << endl; 

  int *pRef {&var1};
  cout << "addr in pRef  " << pRef << "   Wert " << *pRef  <<  endl;
  pRef = &var2;
  cout << "addr in pRef  " << pRef << "   Wert " << *pRef  <<  endl;

  return 0;
}

Auch wenn der Unterschied in der Betrachtung banal erscheinen mag, er 
ist da.
Eine Referenzvariable kann ich mit etwas (gleichem Datentyps) 
initialisieren und dann ist die Referenzvariable wegen ihrem Aliasnamen 
gleich der initialisierten Variablen oder Objekt o.ä. Zeile 11.
Die Instanz, die Adresse, in Zeile 16 zu ändern geht.

Man kann der Referenzvariablen nur durch kopieren/übergeben von Werten 
andere Werte zuweisen. Aber die Referenzvariable bleibt in dem Bsp. var1 
und wird nicht var2. Man arbeitet weiterhin mittels Referenzvariablen 
refVar immer noch im Namen von var1.

Bei Zeigern weise ich in Zeile 29 pRef die Adresse von var2 zu und ab 
dem Zeitpunkt arbeitet man sinnbildlich mittels pRef mit var2 und nicht 
mehr mit var1. Man ändert nicht nur irgendwelche Werte in var1, sondern 
man arbeiten mit einem anderen Objekt var2.

Das ist der Unterschied in der Betrachtung oder gar Bedeutung, aber der 
ist wichtig zu verstehen. Ansonsten ackert man mit der falschen 
Variablen weiter und will das gar nicht.

Edit:
Natürlich kann man den gleichen Schutz mit Zeiger durch const

int* const pRef {&var1};

an der richtigen Stelle auch erreichen, nur ist das nicht "Default". :-) 
Und eben das Gehampel mit Dereferenzieren usw. bleibt bestehen. Bis ich 
das damals verstanden hatte, da verging viel Zeit. Arduino F. wird sich 
vielleicht erinnern.  :-)

[Oliver S. (oliverso)]

Rolf schrieb:
> "Unter der Haube" kann vieles bedeuten. Die Frage ist, wer wann was tut.

Schau dir doch einfach das oben verlinkte godbolt-Beispiel an. Da siehst 
du den erzeugten Assembler-Code.

Der C++-Standard schreibt „ It is unspecified whether or not a reference 
requires storage“

Spätestens, wenn die Reference ein Funktionsparameter ist, oder 
dynamischer Polymorphismus genutzt wird, gehts nicht ohne.

Oliver

[Ein T. (ein_typ)]

Norbert schrieb:
> Ralph S. schrieb:
>> mag ich schon aufgrund der Einrückungen per Whitespaces nicht...
>
> In jeder halbwegs akzeptablen Programmiersprache rückt man ein, um sein
> strukturiertes Ansinnen zu verdeutlichen. Python forciert dieses an sich
> sinnvolle Verhalten.

Exkurs: nicht nur das, die Kombination von Klammern {} und Einrückung 
ist vor allem redundant und insofern überflüssig. Trotzdem erlaubt 
Python auch eine Formatierung mit Semikola wie beispielsweise

import sys; sys.exit()

> Aber ich gebe es gerne zu, auch ich habe die ersten zwei** Minuten der
> darauf folgenden vielen Tausenden von Stunden gemeckert und mir Gründe
> aus den Fingern gezogen warum ausgerechnet dies nun schlecht sein soll.
> ;-)
>
> ** Könnten auch zwanzig Minuten gewesen sein.

Man gewöhnt sich jedenfalls sehr schnell dran, insbesondere wenn der 
genutzte Editor das ordentlich unterstützt.

[Ein T. (ein_typ)]

Rahul D. schrieb:
> Man kann sich alles schönreden. Man sollte halt bei der Formatierung
> konsequent sein. Das ist doch das, was so "toll" an python ist.

Man kann sich auch künstlich doof stellen. Oder künstlich aufregen. Oder 
beides. Such Dir einfach was aus.

[Tim T. (tim_taylor)]

Also ich habe ehrlich gesagt keine Ahnung was das Problem des OP ist. 
Das Beispiel im Anhang kompiliert auch ohne explizite 
Forward-Deklaration.

Und ja, ich weiß...

[N. M. (mani)]

Tim T. schrieb:
> Also ich habe ehrlich gesagt keine Ahnung was das Problem des OP ist

Das gleiche frage ich mich schon seit 50 Beiträgen.

[Rahul D. (rahul)]

Ein T. schrieb:
> Oder beides. Such Dir einfach was aus.
Dich stört, dass jemand was gegen dein heiß geliebtes Python hat - 
dessen Meinung ist für dich demnach irrelevant, was du dadurch 
ausdrücken könntest, dass du solche Beiträge / Kommentare einfach 
ignorierst.

Ein T. schrieb:
> Oder künstlich aufregen.
Was du ja offensichtlich gerne tust.

Wie schon mehrfach angegeben: "Diskussionen" mit dir sind überflüssig.
Hast du schon mal irgendwas sachbezogenes beigetragen?
Ein Problem hier gelöst?

[Alexander (alecxs)]

Tim T. schrieb:
> Also ich habe ehrlich gesagt keine Ahnung was das Problem des OP ist.

war.. Arduino Temp Dateien. Hatte ich auch schon `uint8_t does not name 
a type`

[Christoph M. (mchris)]

Alexander schrieb:
> Hatte ich auch schon `uint8_t does not name
> a type`

stdint.h is a header file in the C standard library introduced in the C99 standard library section 7.18 to allow programmers to write more portable code by providing a set of typedefs that specify exact-width integer types, together with the defined minimum and maximum allowable values for each type, using macros

#include <stdint.h>

https://en.wikibooks.org/wiki/C_Programming/stdint.h

[Rahul D. (rahul)]

Tim T. schrieb:
> Also ich habe ehrlich gesagt keine Ahnung was das Problem des OP ist.

Klar wird das Problem nicht.
Ich vermute die Typdefinition in setup() und deren Verwendung in loop().

[Rahul D. (rahul)]

Christoph M. schrieb:
> https://en.wikibooks.org/wiki/C_Programming/stdint.h

Man kann Fehlermeldungen natürlich auch einfach mal googlen.
Vielleicht / bestimmt hatte ja jemand anderes schon das selbe Problem...

[Oliver S. (oliverso)]

Da Arduino aber nun C++ ist, ist der passende Header <cstdint>.

Und das Problem dahinter ist, daß der halt manchmal eh schon irgendwo in 
irgendwelchen Library-headern includiert ist, manchem halt nicht, und 
daß sich das mit verschiedenen toolchain schonmal ändert.

Mit dem Problem des TO hat das alles aber nun überhaupt nichts zu tun.

Oliver

[N. M. (mani)]

Ralph S. schrieb:
> Johann L. schrieb:
>> Und was ist jetzt das Problem?
>
> :-) gute Frage, ich habe keines mehr... hier geht es glaube ich
> grundsätzlich um Mißverständnisse... so irgendwie ...

Sein Problem ist auch seit 40 Beiträgen gelöst...

[Alexander (alecxs)]

Christoph M. schrieb:
> #include <stdint.h>

war natürlich drin. korrekt zitieren, hatte den Grund benannt.

Alexander schrieb:
> Arduino Temp Dateien

[Arduino F. (Firma: Gast) (arduinof)]

Alexander schrieb:
> hatte den Grund benannt.
>
> Alexander schrieb:
>> Arduino Temp Dateien

Unsinnig!

[Georg M. (g_m)]

Falls sich jemand für Arduino interessiert:

http://forum.arduino.cc/
https://www.arduinoforum.de


Falls sich jemand für C++ interessiert:

https://www.c-plusplus.net/forum/
(und viele weitere Internet-Foren)
https://www.w3schools.com/cpp/default.asp

[Alexander (alecxs)]

Arduino F. schrieb:
> Unsinnig!

Es wird nur das Sketch überwacht (und das Board) aber nicht das 
Framework.

[Arduino F. (Firma: Gast) (arduinof)]

Alexander schrieb:
> Arduino F. schrieb:
>> Unsinnig!
>
> Es wird nur das Sketch überwacht (und das Board) aber nicht das
> Framework.

Leere Worte, ohne Sinn und Zusammenhang.

[Alexander (alecxs)]

Och is mir doch egal. Ich hab keine Lust. Lass es Dir halt von einer KI 
erklären wenn Du den Zusammenhang nicht verstehst.

https://copilot.microsoft.com/shares/71sUzGB5nox9eLW7tNDjp

Der Unterschied, ich hab eine Erklärung für nichtreproduzierbare 
Fehler gegeben. Du schiebst nur den TE vor.

[Arduino F. (Firma: Gast) (arduinof)]

Alexander schrieb:
> Och is mir doch egal.

Ja, das (anfangs) Problem des TO ist dir egal.
Du baust stattdessen lieber ein neues dahin.
Ohne jeden Zusammenhang oder Sinn.

Ja, mach du mal weiter mit deiner Gehirnprothese...
Das macht dich nicht glaubwürdiger.

[Alexander (alecxs)]

Die Gehirnprotese ist in dem Falle für Dich. Ich weiß ja was ich mit 
Arduino Temp Dateien gemeint habe.

[Rahul D. (rahul)]

Alexander schrieb:
> Ich weiß ja was ich mit Arduino Temp Dateien gemeint habe.
ja, aber niemand anders. Scheint also nicht relevant zu sein.
Eine Erklärung lieferst du lieber nicht? Ist dir das peinlich?

[Alexander (alecxs)]

Was soll ich denn erklären, ist irgendwas unklar?

[Arduino F. (Firma: Gast) (arduinof)]

Alexander schrieb:
> ...

Erinnere dich:

Du bist bei mir unten durch, seit du mir verkaufen wolltest, dass mein 
OOP Code kein C++ ist.

Und jetzt bist du für mich nur noch ein Troll und Thead Kidnapper

[Ein T. (ein_typ)]

Rahul D. schrieb:
> Ein T. schrieb:
>> Oder beides. Such Dir einfach was aus.
> Dich stört, dass jemand was gegen dein heiß geliebtes Python hat -

Nö. Mich stört, daß der Betreffende jedes Mal das Maul aufreißen muß, 
wenn das böse P-Wort erwähnt wird. Mich stört, daß der Betreffende sich 
dabei jedes Mal auf einen der unwichtigsten Aspekte der Sache 
kapriziert. Und mich stört, daß sich jemand ernsthaft für einen guten 
Entwickler mit einer ernstzunehmenden Meinung hält, der sich an solchen 
Lächerlichkeiten hochziehen kann, und das ständig, jedes Mal, und immer 
und immer und immer wieder.

> Wie schon mehrfach angegeben: "Diskussionen" mit dir sind überflüssig.

Ja, für Dich ist das sicher richtig. Ich habe ja immer Recht. Andere 
können sehr konstruktiv mit mir diskutieren, aber bei einem, der sich 
ständig und immer wieder an der Sache mit dem Whitespace hochzieht... 
mit Kleingeistern zu diskutieren, ist intellektuell anspruchslos und 
daher Zeitverschwendung.

> Hast du schon mal irgendwas sachbezogenes beigetragen?
> Ein Problem hier gelöst?

Im Gegensatz zu Dir mache ich das sogar recht oft. Und jetzt zurück zum 
Thema, Du hast schon genug Threads mit Deiner Pythonophobie 
zuge^Wgeflutet.

[Alexander (alecxs)]

Arduino F. schrieb:
> du mir verkaufen wolltest, dass mein OOP Code kein C++ ist.

Schwachsinn. Wie dumm ist das bitte? Wir reden von einer C++ Lib. Ich 
sage ich versteh das Abstraktionsniveau nicht mehr. Als Antwort kommt 
ich könnte doch C++ lernen.

Warum sind hier im Forum eigentlich immer die Leute die Experten die 
nicht sinnerfassend Zusammenhänge lesen können?

Ich schrieb doch ganz klar, Arduino Temp Dateien sind eine mögliche 
Ursache für nichtreproduzierbare Fehler. Nicht mehr und nicht weniger, 
nicht ob das hier zutrifft.

Offensichtlich können Tim T. (tim_taylor) und einige andere den Fehler 
nicht reproduzieren.

Ralph S. schrieb:
> typedef struct
>
> {
>
>   int x1, y1;
>
>   int x2, y2;
>
>   int upborderattr;
>
>   int dwnborderattr;
>
>   int txfieldattr;
>
> } txbox_t;
>
> txbox_t tbox;
>

Ralph S. schrieb:
> txbox_t does not name a type.

Ralph S. schrieb:
> Ach so, ja, bevor gemeckert wird, ein (leider) funktionsfährig und
> compilierbares Testprogramm:
>
> typedef struct
>
> {
>
>   int x1, y1;
>
>   int x2, y2;
>
>   int upborderattr;
>
>   int dwnborderattr;
>
>   int txfieldattr;
>
> } txbox_t;
>
> txbox_t tbox;

Ist der Fehler nun reproduzierbar oder nicht?

[Arduino F. (Firma: Gast) (arduinof)]

Alexander schrieb:
> Ist der Fehler nun reproduzierbar oder nicht?

Der TO hat keinen testfähigen Code gepostet.
Damit ist jeder Versuch den Fehler zu reproduzieren von Anfang an 
unmöglich.

Zudem lag der Code in einer *.ino Datei und unterliegt damit deiner heiß 
geliebten Überwachung.
Deine temp Geschichte ist damit eine Nebelkerze. Ein dummer Versuch den 
Thread zu hijacken.
Eine Blamage.

[Alexander (alecxs)]

Arduino F. schrieb:
> Zudem lag der Code in einer *.ino Datei und unterliegt damit deiner heiß
> geliebten Überwachung.

Das zeigt mir nur dass Du es nicht verstanden hast. Gerade darum geht es 
bei nichtreproduzierbaren Fehlern: am Code ändert sich nichts.

[Rahul D. (rahul)]

Ein T. schrieb:
> Nö. Mich stört, daß der Betreffende jedes Mal das Maul aufreißen muß,
> wenn das böse P-Wort erwähnt wird.
Das ich erwähnt habe.

> Und mich stört, daß sich jemand ernsthaft für einen guten
> Entwickler mit einer ernstzunehmenden Meinung hält, der sich an solchen
> Lächerlichkeiten hochziehen kann, und das ständig, jedes Mal, und immer
> und immer und immer wieder.
Habe ich irgendwann mal behauptet, dass ich mich "ernsthaft für einen 
guten Entwickler" halte? Tue ich nicht. Meine Einstellung ist, dass es 
jemandanders gibt, der es besser kann als ich (z.b. die Kollegen im Büro 
nebenan).

Du springt doch sofort darauf an, wenn ich mal wieder über python 
herziehe bzw. es als mittelprächtiges Beispiel einer Programmiersprache 
verwende.
Es gibt bessere. Das solltest du als "programmiertechnisches Super-GAU" 
ja bestens wissen (der Begriff stammt von einem Uni-Prof)-

Ein T. schrieb:
> Im Gegensatz zu Dir mache ich das sogar recht oft. Und jetzt zurück zum
> Thema, Du hast schon genug Threads mit Deiner Pythonophobie
> zuge^Wgeflutet.
1. Das Problem / Thema des Threads ist schon lange geklärt.
2. Wenn ich meine "Pythonophobie" auslebe, stört das eher wenige - die 
lesen das kurz und scrollen dann weiter.
3. der einzige, der sich dadurch getriggert fühlt und seine 
Übergriffigkeit loswerden muss, bist du.

Wenn dich meine Kommentare stören: Melde sie einfach!

[Norbert (der_norbert)]

Rahul D. schrieb:
> Wenn ich meine "Pythonophobie" auslebe, stört das eher wenige - die
> lesen das kurz und scrollen dann weiter.

Du könntest das auch einfach sein lassen und mal still schweigen, dann 
störte es gar niemanden.

[Rahul D. (rahul)]

Norbert schrieb:
> Du könntest das auch einfach sein lassen und mal still schweigen, dann
> störte es gar niemanden.
Ich habe Ralph nur vorgeschlagen, sich auch mit python zu beschäftigen.
Dass das nicht so ganz ernst gemeint war, hat er zumindest verstanden 
(siehe Smilie)

Du bist doch auf Ralphs Aussage eingegangen:
Norbert schrieb:
> Aber ich gebe es gerne zu, auch ich habe die ersten zwei** Minuten der
> darauf folgenden vielen Tausenden von Stunden gemeckert und mir Gründe
> aus den Fingern gezogen, warum ausgerechnet dies nun schlecht sein soll.
Wo habe ich (in diesem Thread) geschrieben, dass ich die Sprache 
grundsätzlich schlecht finde?
Ich finde sie gewöhnungsbedürftig, weil sie Sachen für notwendig 
erachtet, die bei anderen Sprachen nicht so relevant sind.

Ja, man kann sich an vieles gewöhnen:
Rahul D. schrieb:
> Auch, wenn ich mit python so langsam zurecht komme, bis ich die mag,
> wird es noch dauern.

[Ein T. (ein_typ)]

Rahul D. schrieb:
> Habe ich irgendwann mal behauptet, dass ich mich "ernsthaft für einen
> guten Entwickler" halte? Tue ich nicht.

Und trotzdem bekommst Du Deine Missionierungsobsession nicht in den 
Griff.

> Du springt doch sofort darauf an, wenn ich mal wieder über python
> herziehe bzw. es als mittelprächtiges Beispiel einer Programmiersprache
> verwende.

Du darfst Python gerne und jederzeit fundiert kritisieren. Was nervt, 
sind diese ständigen Wiederholungen des immer gleichen Mülls.

> Es gibt bessere.

Nur für bestimmmte Anwendungsfälle, allgemein jedoch nicht.

[Rahul D. (rahul)]

Ein T. schrieb:
> Und trotzdem bekommst Du Deine Missionierungsobsession nicht in den
> Griff.
> Nur für bestimmmte Anwendungsfälle, allgemein jedoch nicht.

Wer missioniert hier?

[Rahul D. (rahul)]

Ein T. schrieb:
> Du darfst Python gerne und jederzeit fundiert kritisieren.
Du bist ja sooo gnädig! Wer bist du denn, dass du dich hier so wichtig 
aufführst?

> Was nervt, sind diese ständigen Wiederholungen des immer gleichen Mülls.
Und nun? Halte es einfach wie Peter Lustig: „... Ihr könnt also 
abschalten.“

[Alexander (alecxs)]

Warum wollt ihr Äpfel mit Birnen vergleichen; Python ist eine 
Scriptsprache und keine klassische Programmiersprache. Der Vorteil liegt 
ja gerade darin dass nichts für eine Zielplattform kompiliert werden 
muss. Bevor man anfängt Shellskripte und Batchdateien parallel zu 
pflegen dann lieber ein Python.py

[Rahul D. (rahul)]

Alexander schrieb:
> Zielplattform kompiliert werden muss.
Den Interpreter namens "python" braucht man aber.
Der ist zwar häufig vorinstalliert, aber das muss nicht immer der Fall 
sein.
Und dann ist der Kunde aufgeschmissen, wenn er die Software selber 
installieren soll  will  muss.

[Alexander (alecxs)]

In der Tat unter Windows eine Fehlerquelle. Microsoft hat sich 
erdreistet eine dummy Python.exe in den Path mit aufzunehmen. Diese soll 
dann den Appstore öffnen. Funktioniert aber nicht wenn man den Appstore 
deinstalliert hat. Scripte laufen dann mit Returncode 0 ins Leere.

[Veit D. (devil-elec)]

Rahul D. schrieb:
> Alexander schrieb:
>> Zielplattform kompiliert werden muss.
> Den Interpreter namens "python" braucht man aber.
> Der ist zwar häufig vorinstalliert, aber das muss nicht immer der Fall
> sein.
> Und dann ist der Kunde aufgeschmissen, wenn er die Software selber
> installieren soll  will  muss.

Deine Aussage ist doch ein glatter Strohmann. Nichts ist einfacher wie 
eine Pythoninstallation. Das ist einfacher wie Office zu installieren.

[Rahul D. (rahul)]

Veit D. schrieb:
> Deine Aussage ist doch ein glatter Strohmann. Nichts ist einfacher wie
> eine Pythoninstallation. Das ist einfacher wie Office zu installieren.

oder den Unterschied bei der Anwendung von "als" und "wie" zu kennen?
Was ist wohl einfacher: Erst einen Interpreter zu installieren, oder 
gleich eine .exe (bezogen auf MS Windows) zu starten?

[Alexander (alecxs)]

erzähl das FreeCAD

[Rahul D. (rahul)]

Alexander schrieb:
> erzähl das FreeCAD

Welche Funktionen werden dort denn mit python realisiert?
Es gibt auch andere Programme (z.B. Inkscape), die sich mit python 
automatisieren lassen - ist halt eine betriebssystemübergreifende 
Scriptsprache.

[Alexander (alecxs)]

Rahul D. schrieb:
> Welche Funktionen werden dort denn mit python realisiert?

Vermutlich so ziemlich alle. Ohne Python unbenutzbar. Da bin ich beim 
ersten Mal genau in die Windows Falle getappt.

[N. M. (mani)]

Rahul D. schrieb:
> Den Interpreter namens "python" braucht man aber.
> Der ist zwar häufig vorinstalliert, aber das muss nicht immer der Fall
> sein.
> Und dann ist der Kunde aufgeschmissen

Für den Fall kannst du ihm über PyInstaller dann eine Exe machen 😁
Dann ist die alleine lauffähig.

Aber was hat das alles noch mit dem Thema dieses Threads zu tun?

[Rahul D. (rahul)]

N. M. schrieb:
> Für den Fall kannst du ihm über PyInstaller dann eine Exe machen 😁
> Dann ist die alleine lauffähig.
Ich weiß. Dann kann ich aber auch gleich eine lauffähige Datei in einer 
anderen Programmiersprache erzeugen.

> Aber was hat das alles noch mit dem Thema dieses Threads zu tun?
Nichts. Das eigentliche Thema ist schon lange abgeschlossen.
Beitrag "Re: Arduino und struct gefallen sich nicht !"

[Arduino F. (Firma: Gast) (arduinof)]

Rahul D. schrieb:
> Das eigentliche Thema ist schon lange abgeschlossen.
Für mich irgendwie noch nicht!
Denn ich habe das ursprüngliche Problem nicht erkannt/gesehen/erfasst.

[Rahul D. (rahul)]

Arduino F. schrieb:
> Denn ich habe das ursprüngliche Problem nicht erkannt/gesehen/erfasst.

So gesehen, ist das richtig.
Manche beenden Gespräche, indem sie nur sagen, dass Sie den Fehler 
gefunden und behoben haben; aber nicht woran es lag (häufig sitzt das 
Problem ja zwischen Stuhllehne und Monitor...)

[Roland F. (rhf)]

Arduino F. schrieb:
> Denn ich habe das ursprüngliche Problem nicht erkannt/gesehen/erfasst.

Vielleicht weil es eigentlich keins gab.

rhf

[Alexander (alecxs)]

Das Problem steht im OP, und wie es umschifft wurde auch.

[Arduino F. (Firma: Gast) (arduinof)]

Alexander schrieb:
> Das Problem steht im OP, und wie es umschifft wurde auch.

Alles klar, keine Fragen mehr...

https://www.youtube.com/watch?v=DrG2c0_EyDE

[Rahul D. (rahul)]

Alexander schrieb:
> Das Problem steht im OP, und wie es umschifft wurde auch.

What?
Einfach mal den Hinweis beachten.

[Alexander (alecxs)]

Arduino F. schrieb:
> Alles klar, keine Fragen mehr...

Passt gur zu Dir...

[Arduino F. (Firma: Gast) (arduinof)]

Rahul D. schrieb:
> What?

Bei dem brauchste gar nicht nachfragen, da kommt nur Müll.

[Alexander (alecxs)]

also noch mal auf deutsch für Christoph und Rahul (früher hat man sowas 
gegoogelt)

- OP - Opening Post
- EP - Eröffnungspost

- TE - Threadersteller
- TO - Thread Opener / Thread Owner
- TS - Thread Starter
- OP - Original Poster

[Rahul D. (rahul)]

Alexander schrieb:
> also noch mal auf deutsch für Christoph und Rahul (früher hat man sowas
> gegoogelt)
>
> - OP - Opening Post
> - EP - Eröffnungspost
>
> - TE - Threadersteller
> - TO - Thread Opener / Thread Owner
> - TS - Thread Starter
> - OP - Original Poster

Das war nicht die Frage, sondern, was du mit

Alexander schrieb:
> Das Problem steht im OP, und wie es umschifft wurde auch.

meintestest.
Das war auch gar keine Lösung, sondern Präsentation von gefährlichen 
Nichtwissen, die schon dicht an Arduino-Bashinng war.

[Alexander (alecxs)]

Also erstens bin ich ich nicht der TE, zweitens das Problem und die 
'Lösung' (Workaround; deutsch 'umschifft') stehen sehr wohl im OP. Es 
steht sogar haarklein die Begründung im Text.

Ich wette ich kann es sogar reproduzieren. Damit habe ich Nichtwisser 
euch zwei Experten schon mal was voraus.

[Rahul D. (rahul)]

Alexander schrieb:
> Ich wette ich kann es sogar reproduzieren. Damit habe ich Nichtwisser
> euch zwei Experten schon mal was voraus.
Nachdem die eine KI befragt hast?

[Alexander (alecxs)]

Das muss ich gar nicht, da ich schon vor (meinen) KI-Zeiten ein 
ähnliches Problem hatte und mir die Begründung des TE bzgl. Eigenheiten 
der Arduino IDE sehr wohl vertraut ist.

Aber gute Idee, ich wette selbst eine KI kann das nachvollziehen, befrag 
sie doch direkt mal!

Ralph S. schrieb:
> Schlicht deshalb, weil Arduino automatisch Funktionsprototypen vor der
> Kompilierung generiert. Bei Funktionen mit Struct-Parametern kennt der
> Compiler den Typ noch nicht und deshalb muss ein Prototyp explizit
> angegeben werden

Dann lass Dir gleich noch im Arduino Quelltext zeigen wie die 
Reihenfolge genau ist. Dann ist hier ein für alle mal Ruhe.

[Ralph S. (jjflash)]

Alexander schrieb:
> Aber gute Idee, ich wette selbst eine KI kann das nachvollziehen, befrag
> sie doch direkt mal!
>
> Ralph S. schrieb:
>> Schlicht deshalb, weil Arduino automatisch Funktionsprototypen vor der
>> Kompilierung generiert. Bei Funktionen mit Struct-Parametern kennt der
>> Compiler den Typ noch nicht und deshalb muss ein Prototyp explizit
>> angegeben werden
>
> Dann lass Dir gleich noch im Arduino Quelltext zeigen wie die
> Reihenfolge genau ist. Dann ist hier ein für alle mal Ruhe.

Nur mal so: es ist hier schon elendig lange "Ruhe" und das Thema hatte 
sich auch schon erledigt, gehabt, aber garantiert nicht wegen Dir, 
sondern schon eher von Arduino F. wegen.

Es ist unglaublich, wie sich hier immer und immer und immer wieder 
manche auf Kosten anderer profilieren wollen (oder glauben dieses tun zu 
müssen).

Warum auch immer habe ich mich in der letzten Zeit etwas mehr mit 
Arduino beschäftigt, als mir das lieb war und das alles nur, weil ich 
beschreiben will, wie mein Hardwareboard (mit CH32V003 und seriellem 
Bootloader) mit Arduino zusammenarbeiten kann (aber nicht muß)... und 
wie man mit bestimmten Gegebenheiten umgehen muß.

Wie gesagt, der Titel dieses Threads hier ist schon lange obsolet und, 
obwohl ich nicht so wirklich viel mit Arduino gemacht habe, glaube ich 
dennoch, dass ich darüber schon deutlich mehr weiß, als der 
Standardanwender.

Also, alle, die sich angesprochen fühlen: klopft euch mal selbst auf die 
Schulter und redet euch ein, wie toll und wie klasse ihr seid (jemand 
anderes wird das nicht tun). Die, die wirklich klasse und gut sind, 
werden sicherlich oft genug gelobt!

--------------------------------------------------------

So, zum eigentlichen Thema will ich nicht wirklich zurück, aber das was 
ich hier jetzt präsentieren möchte ist genau wegen dieses Threads hier 
entstanden.

Mittlweile habe ich mich auch durch einen Teil des Dateien-Geflechts von 
Arduino gekämpft und weiß, wo ich bei bestimmten Dingen ansetzen müßte, 
wenn ich das denn umsetzen wollte.

Warum bspw. bei einem CH32V003 in :

~/.arduino15/packages/WCH/hardware/ch32v/1.0.4/variants/CH32V00x/CH32V00 
3F4/variant_CH32V003F4.h

das hier steht:

/* ENABLE Peripherals */
// #define                         ADC_MODULE_ENABLED
#define                         UART_MODULE_ENABLED
// #define                         SPI_MODULE_ENABLED
#define                         I2C_MODULE_ENABLED

erschließt sich mir nicht. "unkommentiert" man den ADC, funktioniert 
auch analogRead in Arduino (zuvor eben nicht).

Ich wüßte mittlerweile auch, wo ich ansetzen müßte um HardwareSerial die 
Read-Funktionen zu implementieren, laß das aber, weil ich hier dann 
lieber ein eigenes Serial als Library habe (und einem Anfänger nicht 
zumuten möchte, den Core zu patchen).

---------

Wie dem auch sei, waren die Diskussionen hier sehr hilfreich, wie ein 
Arduino-User bestimmte Dinge vorfinden mag (bspw. einen geerbten 
Stream), oder eben auch, wie hier gerne die funktion loop gesehen wird. 
Einiges respektriere ich so und übernehme das auch so, bei anderen 
Dingen bin ich dann halt manchmal anderer Meinung.

Und weil in einem anderen Thread sogar moniert wurde, dass ein \n\r 
nicht richtig sei (obwohl das von mir sogar ganz bewußt so eingesetzt 
wird.... mit allen Mikrocontrollern die ich verwende), nur weil die User 
scheinbar noch nie eine Terminalemulation wie PuTTY, minicom oder 
TeraTerm verwendet haben.

Weil ich gerne bestimmte Dinge (und nein, ich kann auch mit OpenOCD 
umgehen) dann einfach nur auf die Schnelle auf einem Terminal ausgeben 
mag um korrekte Funktionsweise zu überprüfen, ist es mitunter 
hochangenehm, wenn man im Terminal Farben verwenden und den Textcursor 
positionieren kann.

Hierfür ist dann der "serielle Monitor" von Arduino (man möge es mir 
verzeihen, das soll kein Bashing sein) dann wirklich allerübelster 
Schrott und es hätte der Arduino-IDE gut zu Gesicht gestanden, hier ein 
halbwegs vernünftiges Terminal zu integrieren.

Hier ist also mal das Ergebnis (und smile, ich schreibe das von meinem 
Urlaub aus in einem südlichen Land) für solche Ausgaben, die mit 
unterschiedlichen Controllern, namentliche Arduino-nano, STM32F411 
Nucleo und Eigenbau CH32V003 getestet sind und doch tatsächlich auf 
allen gleich funktionieren.

Es dreht sich hier um eine Ausgabemöglichkeit mittels ESC-Sequenzen auf 
einem Terminal (meistens eine Terminalemulation), die weit weniger 
aufwändig (aber auch weniger leistungsfähig) ist als ein mcurses von 
Frank M.(ukw) https://www.mikrocontroller.net/articles/MCURSES und zudem 
auch eben noch aus Arduino heraus funktioniert.

Es würde mich sehr freuen, wenn ihr konstruktive Kritik an meinen 
Dateien üben würdet, insbesondere von Arduino F.  Veit  Kirnbichler 
würds mich sehr freuen. Allerdings kann ich natürlich nicht erwarten, 
dass ihr euch diese Menge auch ansehen werdet.

Für alle anderen: es kann durch aus richtig Spaß machen, mit den 
Ansi-Sequenzen auf Arduino zu spielen.

Viele Grüße,
Ralph

[Alexander (alecxs)]

Hast Du Dich im Thread vertan? Der ist hier

Beitrag "Re: CH32V003 und Arduino"

[Ralph S. (jjflash)]

Alexander schrieb:
> Hast Du Dich im Thread vertan? Der ist hier
>
> Beitrag "Re: CH32V003 und Arduino"

nein, habe ich nicht. Dort hätte es zwar auch gepasst, aber die Library 
hier jetzt funktioniert mit jedem Controller für den es einen 
Arduino-Core und ein HardwareSerial gibt (und ist von daher genau eines 
nicht: CH32V003 spezifisch!).

Hier hätte ich jetzt eher eine Aussage erwartet wie: Warum hast du die 
msgbox und die txtbox nicht als eigenständige Klassen gemacht und die 
entsprechenden Methoden vererbt: Einzig, weil es dann irgendwann 
"unübersichtlich" wird und es einen Overhead produziert, der für kleine 
bis sehr kleine Controller garantiert kontraproduktiv ist.

----------------------------------------

Ähem Alexander, hast du in irgendeinem Thread auch irgendetwas 
konstruktives beizutragen ?

[Alexander (alecxs)]

War das nicht konstruktiv genug\n\r

[Arduino F. (Firma: Gast) (arduinof)]

Ralph S. schrieb:
> Es würde mich sehr freuen, wenn ihr konstruktive Kritik an meinen
> Dateien üben würdet,
Gefühlte 100 Vorschläge könnte ich machen.

Ralph S. schrieb:
> Einiges respektriere ich so und übernehme das auch so, bei anderen
> Dingen bin ich dann halt manchmal anderer Meinung.
Ja, so sind sie... alle...

[Ralph S. (jjflash)]

Alexander schrieb:
> War das nicht konstruktiv genug\n\r

Das war eine Anmerkung von dir, die MIR zeigt, dass es manche Leute hier 
gibt, die xzy (zensiert) und dann abc (genauso zensiert) ... und 
überhaupt zensiert ist.

Kurz: du hast schlicht überhaupt keine Ahnung und weißt nicht, dass es 
außerhalb des Tellerrandes weitergeht, denn es gibt noch etwas anderes 
als schlicht nur den seriellen Monitor von Arduino ... und du hast auch 
mit keiner Faser verstanden, für was das ist und warum bspw. PuTTY 
standardmäßig es trennt, dieses LF und CR (oder eben auch \n \r) ... und 
es überhaupt keine Rolle spielt, ob es zuerst eine neue Zeile gibt und 
dann an den Anfang der Zeile gesprungen wird, oder ob zuerst an den 
Anfang einer Zeile gesprungen wird und dann eine neue Zeile.

Dort hatte ich auch dargelegt, dass es absolut ABSICHT ist ... also ist 
dein Minieinwand, dass etwas von dir konstruktiv ist absolut daneben. 
Erst nix verstehen, dann sich selbst als Experten darstellen und 
überhaupt noch nichts gezeigt haben. Ich bitte dich: verschone mich mit 
deinen Expertenaussagen.

---------------------------------------

@Arduino F. ich muß etwas schmunzeln, weil ich angenommen habe, dass du 
gefühlt 100 Vorschläge machen könntest. Wäre nett, wenn du mal den 
größten nennen würdest.

Beim Schreiben habe ich mir vieles überlegt, wie man etwas machen 
könnte. Wie gesagt könnte man bspw. aus den Elementen aus AnsiOut eigene 
Klassen herstellen. Das hätte dann den Vorteil, dass es kein struct 
benötigen würde, weil das dann schlichtweg Variable der Klasse wären.

Außerdem ist es etwas "gefährlich", die Farbnamen so zu beschreiben wie 
ich das gemacht hab (obwohl du dann schon zugeben mußt, dass ich 
wenigstens constexpr gemacht habe).

Und ich gebe zu, dass es wohl doch ein "arger" Mix aus C und C++ ist 
(und ich bin immer noch kein Freund von C++ auf kleinen 
Mikrocontrollern).

Im Übrigen funktioniert dein Vorschlag im Verlauf dieses Threads zum 
Belegen der Instanz einer struct nur mit einem Compiler, der C++20 
unterstützt. Der AVR-GCC Compiler Version 7.3 der der Arduino-IDE 1.8 
hinterlegt ist, kann das nicht. Der benutzte RISC-V Compiler für 
CH32V003 kann es.

Im Demo hätte man anstelle einen 12-Bit ADC auf 10 zu reduzieren, eine 
10-Bit Auflösung pseudomäßig mittes wert << 2 auf einen 12-Bit Wert 
skalieren können, so dass bei einem 12-Bit ADC keine Auflösung 
verschenkt wird.

Man kann die Instanzen von progbar_t und tbox_t bereits im Konstruktor 
mit Werten belegen.

Ich habe mir viele Sachen überlegt wie man ein printf und ein AnsiOut 
realisieren kann, so dass es für Arduino-User "okay" ist.

Aber ohne Käse, mach einfach mal ein paar Vorschläge... und dann auch 
mal eine Einschätzung darüber wie sinnvoll diese Library ist....

Uuuuuund: ist es legitim, wenn ich "Treiber" für bspw. DHT11 / 22 oder 
DS18B20 , BM280 mache, dass die Beispiele für diese "Treiber" dieses 
extendedSerial verwenden dürfen oder ist es hier besser doch nur 
HardwareSerial von Arduino zu verwenden.

Und: für ein vollwertiges Serial für einen CH32V003 lieber den Core 
patchen oder eine eigenständige Library für Serial.

--------------------------------

Es geht mir nicht darum, dass man mir zeigt wie man etwas programmiert, 
sondern es geht mir daraum, was denn für den geneigten Anwender das 
pragmatischtes und durchschaubarste ist?

[Alexander (alecxs)]

Also bleib ruhig in deinem Film, aber um den seriellen Monitor ging es 
nie. Genau dort ist es nämlich irrelevant. Auch ich hab schon 
Progressbars und per ANSI-Escapesequenzen steuerbare ASCII Menüs 
gebastelt.

[Kilo S. (kilo_s)]

Am sinnvollsten Düfte Core patchen sein, die Frage welches serial für 
die Treiber erübrigt sich dadurch, die Nutzer kennen das 
Benennungsschema, kommen so in "gewohnter Umgebung" besser zurecht

Ralph S. schrieb:
> Für alle anderen: es kann durch aus richtig Spaß machen, mit den
> Ansi-Sequenzen auf Arduino zu spielen.

Ich werde demnächst mal einen PY32F002 dafur verwenden und das 
ausprobieren. :-)

[Norbert (der_norbert)]

Ralph S. schrieb:
> s dreht sich hier um eine Ausgabemöglichkeit mittels ESC-Sequenzen auf
> einem Terminal (meistens eine Terminalemulation),

Ralph, wenn du magst, dann schau dir auch mal das DEC TCS an. Macht die 
Ausgaben noch etwas hübscher.

#!/usr/bin/python3
# vim: fileencoding=utf-8: ts=4: sw=4: expandtab:
#┌────────────────────────────────────────────────────────────────────────────┒
#│      DEC VT100                                                             ┃
#│      Technical Character Set                                               ┃
#┕━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━━┛
TCS_ON = '\x1b(0'
TCS_OFF = '\x1b(B'

def showtable():
    for i in range(0x20,0x7f):
        if i%16==0 and i>0x20:
            print()
        print(chr(i),end=' ')
    print('\n')

showtable()
print(TCS_ON,end='')
showtable()
print(TCS_OFF,end='')

  ! " # $ % & ' ( ) * + , - . / 
0 1 2 3 4 5 6 7 8 9 : ; < = > ? 
@ A B C D E F G H I J K L M N O 
P Q R S T U V W X Y Z [ \ ] ^ _ 
` a b c d e f g h i j k l m n o 
p q r s t u v w x y z { | } ~ 

  ! " # $ % & ' ( ) * + , - . / 
0 1 2 3 4 5 6 7 8 9 : ; < = > ? 
@ A B C D E F G H I J K L M N O 
P Q R S T U V W X Y Z [ \ ] ^   
◆ ▒ ␉ ␌ ␍ ␊ ° ± ␤ ␋ ┘ ┐ ┌ └ ┼ ⎺ 
⎻ ─ ⎼ ⎽ ├ ┤ ┴ ┬ │ ≤ ≥ π ≠ £ ·

[Ralph S. (jjflash)]

Norbert schrieb:
> Ralph, wenn du magst, dann schau dir auch mal das DEC TCS an. Macht die
> Ausgaben noch etwas hübscher.

Grüß dich Norbert,

:-) na ja, gibt die Ascii-Tabelle mittels Programm in Python auf der 
Linux-Konsole aus. Mir ging es ja hier eigentlich um Arduino und 
Mikrocontroller.

Natürlich kann man das auch mit MicroPython auf einem Controller machen 
(sagen wir ab sSTM32F411), aber das war nicht das Ziel hier.

Zudem :-) nichts für ungut, dein Pythonprogramm ist so schön "unfarbig". 
Vllt. bis du auch nur der Meinung, ich sollte die Ascii-Tabelle mit 
Arduino machen ?

[Alexander (alecxs)]

╔═════════════════════════╗
║    er findet das schöner     ║
║                              ║
║    Arduino mit AnsiOut       ║
║    230400 bd 8N1             ║
║                              ║
║   15.03.2026 by R. Seelig    ║
║                              ║
╚═════════════════════════╝

[Arduino F. (Firma: Gast) (arduinof)]

Ralph S. schrieb:
> @Arduino F. ich muß etwas schmunzeln, weil ich angenommen habe, dass du
> gefühlt 100 Vorschläge machen könntest. Wäre nett, wenn du mal den
> größten nennen würdest.

Naja...
Hauptsächlich kleinere.
Stil Dinge.

Wie immer: "Das Prinzip der geringsten Verwunderung"
Eine Programm- bzw. Libsammlung ist verständlicher, wenn überall der 
gleiche Stil verwendet wird. Und da hat sich ein quasi Standard 
herausgebildet.

Das fängt an bei den selbstgewählten Bezeichnern für alle möglichen 
Dinge.
1. Keine Unterstriche in Bezeichnern. (also kein xyz_t)
2. Datentypen beginnen mit einem Großbuchstaben (also kein xyz_t)
3. Andere, mit Kleinbuchstaben ( DatenType variable = 23;)
4. KamelHöckerSchreiweise
5. Kein typedef für Strukturen, eigentlich gar kein typedef mehr. 
"typedef" ist eine Sammlung unnützer Buchstaben.

C Stil:
typedef uint16_t meintype_t;


Ab C++11/Arduino Stil:
using MeinType = uint16_t;

using kann sogar etwas mehr, als typedef, Templates!


Natürlich ist der alte C Stil in Arduino nutzbar, aber eher ungewohnt 
für geübte Arduin User.




---------------

Die Aufteilung in *.h und *.cpp vermeiden.
Warum?

Methoden in *.h only sind per default inline.

Man hat nur eine Datei zu pflegen und nicht zwei.

Die Verlängerung der Kompilezeit spielt meist keine Rolle. Bei großen 
Desktop Anwendungen schon eher.

Da zwecks Portabilität sowieso der Quellcode mit in der Lib sein muss, 
macht das Ausliefern von proprietären *.a Dateien wenig Sinn. Das 
geheimhalten/verbergen von Quellcode ist eher nicht Ziel in der Arduino 
Welt.

-----------------

Das sind alles nur persönliche Ansichten.
Keine Religion, kein Muss.

[Norbert (der_norbert)]

Ralph S. schrieb:
> Natürlich kann man das auch mit MicroPython auf einem Controller machen
> (sagen wir ab sSTM32F411), aber das war nicht das Ziel hier.
>
> Zudem :-) nichts für ungut, dein Pythonprogramm ist so schön "unfarbig".

Ach um die Programmiersprache geht's doch gar nicht. Auch nicht um die 
Farbe. ;-) Py war nur gerade zur Hand, bequem und schnell.

Es geht um die zusätzliche TCS Funktionalität mit ESC(0 und ESC(B (für 
Grafikzeichen), welche alle VT100 oder besser haben. Eben auch die 
richtigen Hardware-Dinger, falls man da mal dran möchte. Die können 
nämlich mit UTF-8 nicht wirklich etwas anfangen und der Bildschirm sieht 
dann aus wie ausgekotze Buchstabensuppe.

Für eine (ausschließliche) Emulation braucht man das natürlich nicht. 
Die halten sich sowieso kaum an Standards.

[Norbert (der_norbert)]

Alexander schrieb:

> ╔═════════════════════════╗
> ║    er findet das schöner     ║
> ║                              ║
> ║    Arduino mit AnsiOut       ║
> ║    230400 bd 8N1             ║
> ║                              ║
> ║   15.03.2026 by R. Seelig    ║
> ║                              ║
> ╚═════════════════════════╝

Das üben wir aber noch einmal!

[Ralph S. (jjflash)]

Norbert schrieb:
> Es geht um die zusätzliche TCS Funktionalität mit ESC(0 und ESC(B (für
> Grafikzeichen), welche alle VT100 oder besser haben. Eben auch die
> richtigen Hardware-Dinger, falls man da mal dran möchte. Die können
> nämlich mit UTF-8 nicht wirklich etwas anfangen und der Bildschirm sieht
> dann aus wie ausgekotze Buchstabensuppe.

okay, das schaue ich mir einmal genauer an (weil ich das so nicht auf 
dem Schirm hatte) und danke für den Hinweis.

Arduino F. schrieb:
> Das fängt an bei den selbstgewählten Bezeichnern für alle möglichen
> Dinge.
> 1. Keine Unterstriche in Bezeichnern. (also kein xyz_t)
> 2. Datentypen beginnen mit einem Großbuchstaben (also kein xyz_t)
> 3. Andere, mit Kleinbuchstaben ( DatenType variable = 23;)
> 4. KamelHöckerSchreiweise
> 5. Kein typedef für Strukturen, eigentlich gar kein typedef mehr.
> "typedef" ist eine Sammlung unnützer Buchstaben.

puuuuh, das ist für mich natürlich "harter Tobak", weil das seit 40 
Jahren meine Sache so ist. Werde ich mir mal gucken ob ich mich 
"überwinden" kann, weil es genau diese Schreibweise ist, die ich 
"eigentlich" nicht sonderlich mag.

Aaaaber: das kann man ja ändern.

Arduino F. schrieb:
> Die Aufteilung in *.h und *.cpp vermeiden.
> Warum?
>
> Methoden in *.h only sind per default inline.
>
> Man hat nur eine Datei zu pflegen und nicht zwei.

Für so etwas wurde mir vor Jahren "der xyz" vesohlt, weil ich nur eine 
Datei hatte und habe mir das nun nach *.h / *.c ... oder *.h / *.cpp 
angewöhnt.
Eigentlich unfassbar, dass Konventionen nicht mehr gültig sind, wenn sie 
in die Jahre kommen.

Hmmmm. ich war gerade dabei, das HardwareSerial (CH32V003) zu patchen 
und muß das an mehreren Dateien gleichzeitig machen, besonders der 
Ringbuffer beim Lesen, interruptgesteuert ist etwas "eklig" zu 
realisieren und ich glaube ich lass das dann doch lieber, weil ich 
niemandem erklären kann oder will, wie ich das dann gemacht habe.

Hier gehe ich dann glaube ich doch eher den Weg, dass es eine zweite 
Library geben wird, die dieselben Klassen und Objekte wie extendedSerial 
hat, aber in einer Library namens v003extendedSerial vorhanden ist.

Einziger Unterschied wird dann sein, dass das #include anderst heißt und 
die Objektinstanziierung.... Rest wird gleich bleiben.

Vielen Dank, dass du dir das angesehen hast

[Ralph S. (jjflash)]

Norbert schrieb:
> Ach um die Programmiersprache geht's doch gar nicht. Auch nicht um die
> Farbe. ;-) Py war nur gerade zur Hand, bequem und schnell.
>
> Es geht um die zusätzliche TCS Funktionalität mit ESC(0 und ESC(B (für
> Grafikzeichen), welche alle VT100 oder besser haben. Eben auch die
> richtigen Hardware-Dinger, falls man da mal dran möchte. Die können
> nämlich mit UTF-8 nicht wirklich etwas anfangen und der Bildschirm sieht
> dann aus wie ausgekotze Buchstabensuppe.
>
> Für eine (ausschließliche) Emulation braucht man das natürlich nicht.
> Die halten sich sowieso kaum an Standards.

jetzt hast du mich echt "angetriggert" mit deiner "Idee" und den alten 
7-Bit DEC Standard hatte ich nicht mehr auf dem Schirm... weil ich jetzt 
meinen letzten Urlaubstag hier auf Gran Canaria habe... aber das Wetter 
eine Woche schlecht war (und heute auch), werde ich mich doch 
tatsächlich diesem mal widmen und sehen, wie sich das bei mir 
präsentiert, wenn ich TCS noch in die AnsiOut-Klasse implementiere....

Hrmpf, man hat ja in einem südlichen Land mit Barbetrieb, Pool und 
Strand ja nix anderes zu tun, als Elektronik zu machen...

[Arduino F. (Firma: Gast) (arduinof)]

Ralph S. schrieb:
> Für so etwas wurde mir vor Jahren "der xyz" vesohlt, weil ich nur eine
> Datei hatte und habe mir das nun nach *.h / *.c ... oder *.h / *.cpp
> angewöhnt.
> Eigentlich unfassbar, dass Konventionen nicht mehr gültig sind, wenn sie
> in die Jahre kommen.

Ja.
Das wird sich auch wieder ändern!
z.B. mit den modules von C++23 braucht es keine *.h mehr.
Also dann nur *.cpp
Funktioniert bei mir schon, auch für AVR.
Aber der Arduino Builder spielt da noch so richtig mit.
Tuts, aber hakelt.

[Ralph S. (jjflash)]

Arduino F. schrieb:
> Ja.
> Das wird sich auch wieder ändern!
> z.B. mit den modules von C++23 braucht es keine *.h mehr.
> Also dann nur *.cpp
> Funktioniert bei mir schon, auch für AVR.
> Aber der Arduino Builder spielt da noch so richtig mit.
> Tuts, aber hakelt.

:-) ich glaube ich sollte anfangen, das was ich habe (eben für V003) mal 
alles zusammenfassen und so lassen wie es ist, denn es ist eine Menge 
schon an Code und dann nur "punktuell" ändern: Wie du vor längeren Posts 
gesagt hast: die Arduino-User sind nicht dumm und diejenigen, die dann 
wirklich den Billigst 32-Bit Chip nutzen wollen (unter Arduino) werden 
dann auch mit dem zurechtkommen, wie es ist. Soooooo viel anderst ist es 
dann auch nicht!

[Oliver S. (oliverso)]

Ralph S. schrieb:
> puuuuh, das ist für mich natürlich "harter Tobak", weil das seit 40
> Jahren meine Sache so ist. Werde ich mir mal gucken ob ich mich
> "überwinden" kann, weil es genau diese Schreibweise ist, die ich
> "eigentlich" nicht sonderlich mag.

Erste Grundregel zu Styles in Programmiersprachen: es gibt nur genau 
einen einzigen richtigen: den, den man selber benutzt. Alle anderen sind 
grundlegend und komplett falsch…
>
> Aaaaber: das kann man ja ändern.

Muß man aber nicht, erst recht nicht bei Code, den außer einem selber 
niemand jemals zu Gesicht bekommt. Du musst den verstehen, sonst 
niemand.

> Arduino F. schrieb:
>> Die Aufteilung in *.h und *.cpp vermeiden.

Wenn die Modules in C++ irgendwann mal sinnvoll bzw. überhaupt 
funktionieren, kann man da eventuell drüber nachdenken. Das wird aber 
noch eine ganze Weile dauern, bis das soweit ist. Bis dahin wird es in 
C/C++ selbstverständlich weiterhin Header- und sourcedateien geben. Es 
geht gar nicht ohne.

Oliver

[Arduino F. (Firma: Gast) (arduinof)]

Oliver S. schrieb:
> Bis dahin wird es in
> C/C++ selbstverständlich weiterhin Header- und sourcedateien geben. Es
> geht gar nicht ohne.

In der Arduino Welt ist "*.h only" weit verbreitet!
Die Notwenigkeit *.cpp Dateien anzulegen ist eher gering, bis nicht 
vorhanden. Gerade nicht, in Libraries.

[Veit D. (devil-elec)]

Hallo Ralph,

eigentlich wollte ich mich raushalten. Vieles wurde schon gesagt. Von 
mir sind das auch nur Kleinigkeiten.
In Kurzform.

Keine #define mehr. Alle Konstanten mit const oder besser constexpr. 
Mehrfach gleiche defines bekommt man unter Umständen nicht und dann 
finde den Fehler.

typdef struct

 wurde schon gesagt.

Die Farbenaufzählung und Durchnummerierung im Header würde ich mit enums 
machen. Um die versteckte Durchnummerierung, quasi "Index", soll sich 
gefälligst der Compiler kümmern.

C++11

struct Farbe {enum {black, blue, green, ANZAHL}; } constexpr farbe;
Verwendung: farbe.blue

Damit kann man auch dem Farbdefinition Konfliktpotential entgegen 
steuern. ;-)
Notfalls noch in einem Namespace.

Im Header kann man sich

#ifndef EXTENDED_SERIAL_H
  #define EXTENDED_SERIAL_H

#endif

mit

#pragma

 ersparen. Unterstützt laut meines Wissens jede Toolchain.

und wegen Terminal - EOL

https://www.loginradius.com/blog/engineering/eol-end-of-line-or-newline-characters
https://mojoauth.com/blog/end-of-line-characters#the-history-of-eol-characters
https://www.rfc-editor.org/old/EOLstory.txt

Wird interessant wenn man Daten in einer Textdatei speichert und 
zwischen Windows und Linux austauscht.

.h und .cpp noch in einen Unterordner 'src' und alles ist Arduino 
konform.

Ich denke das reicht. Ist jammern auf hohen Niveau, dafür das du 
eigentlich C programmierst.  :-)

[Alexander (alecxs)]

Veit D. schrieb:
> und wegen Terminal - EOL

möchte er aber nicht, er ist was besonderes

Ralph S. schrieb:
> Dort hatte ich auch dargelegt, dass es absolut ABSICHT ist ...

zumindest kann man seinen Code gut damit auf GitHub finden

Veit D. schrieb:
> alles ist Arduino konform

bis auf die deutsche Sprache im Quellcode, damit wird das nichts mit 
offiziell im Framework