Arduino und struct gefallen sich nicht !

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

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...

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.

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!

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

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.

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.

1

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

1

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

2

Verwendung: farbe.blue

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

Im Header kann man sich

1

#ifndef EXTENDED_SERIAL_H

2

  #define EXTENDED_SERIAL_H

3

4

#endif

mit

1

#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. :-)

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

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

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/

@der_norbert

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

Gruß Ralph