Arduino und struct gefallen sich nicht !

[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

[Ralph S. (jjflash)]

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

smile, nein: dafür, dass ich ein Anfänger bin.

Hm, pragma kann ich machen, aber ich habe noch keine Library in einem 
Zip-File gesehen, wo die *.h und *.cpp in einem Unterverzeichnis sind. 
Die Enums für die Farben werde ich überlegen. Verrückt ist, dass mich 
dieses extendedSerial jetzt schon deutlich mehr Zeit gekostet hat, als 
ich das wollte... Bin ich am gucken, wie ich die anderen Dinge, die V003 
spezifisch sind, da strukturieren werde.

:-) im übrigen läßt man viele Dinge nicht sein, die eigentlich 
"überholt" sind, weil man es eben anderst gelernt und seit Jahrzehnten 
so angewendet hat.

Smile, hast du jetzt schon mal Ansi-Ausgaben mit Arduino versucht? 
Erschließen sich deutlich mehr Möglichkeiten als mit dem Serialmonitor 
in Arduino

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

Ralph S. schrieb:
> Hm, pragma kann ich machen, aber ich habe noch keine Library in einem
> Zip-File gesehen, wo die *.h und *.cpp in einem Unterverzeichnis sind.

Massig!

https://arduino.github.io/arduino-cli/0.20/library-specification/

[Ralph S. (jjflash)]

@der_norbert

Danke für den Tip mit den Technical Character Set des DEC VT100. 
Funktioniert gut, :-) siehe Bild im Anhang.

Gruß
Ralph