Grundsatzfragen

[Klebwax]

Zwar gibt es das Credo bei C:
"alles ist ein file!"

Das ist so nicht richtig. Das gilt für Unix, oder vergleichbare Systeme. Und die Sprache ist dabei nebensächlich. Richtig heißt es "Für Unix ist alles ein File"

das ist bei MCUs aber nicht so einfach, weil du bei Arduino aus einer "Stream class"-enherited "File class" liest (oder schreibst), jedoch gibt es per Arduino GCC oder avrgcc ja überhaupt kein file System, weder für SD cards noch für sonst irgendwas!

Und auch das hat mit C oder dem benutzten Compiler nichts zu tun. Es fehlt dem Arduino-System ein Betriebssystem, ein Kernel, der ein Filesystem zur Verfügung stellt. Die libc stellt nur ein C-kompatibles Interface für die Systemcalls in den Kernel zur Verfügung.

C bietet für FILE* aber auch nur Dinge wie fread() für byte-Blöcke oder (f)scanf() für formatierte Daten,

C bietet genau das an, für was jemand eine Funktion geschrieben hat. C selbst kann nichts, außer vorhandene Funktionen aufrufen. Wenn die Arduino-Erfinder Files hätten haben wollen, hätten sie nur die passenden Funktionen schreiben müssen. Am besten (aber nicht notwendigerweise) kompatibel zur Standardlibrary von C.

MfG Klebwax

[HaWe]

Das ist so nicht richtig. Das gilt für Unix, oder vergleichbare Systeme. Und die Sprache ist dabei nebensächlich. Richtig heißt es "Für Unix ist alles ein File"

Und auch das hat mit C oder dem benutzten Compiler nichts zu tun. Es fehlt dem Arduino-System ein Betriebssystem, ein Kernel, der ein Filesystem zur Verfügung stellt. Die libc stellt nur ein C-kompatibles Interface für die Systemcalls in den Kernel zur Verfügung.

C bietet genau das an, für was jemand eine Funktion geschrieben hat. C selbst kann nichts, außer vorhandene Funktionen aufrufen. Wenn die Arduino-Erfinder Files hätten haben wollen, hätten sie nur die passenden Funktionen schreiben müssen. Am besten (aber nicht notwendigerweise) kompatibel zur Standardlibrary von C.

MfG Klebwax

Mit Unix vs. "nacktem" C hast du Recht, stimmt (und C wurde ja zum programmieren von Unix überhaupt erst entwickelt), aber für C gibt es die stdio.h, die genau die file- (FILE*) Funktionen zur Verfügung stellt (egal ob Unix oder x86), die es bei Arduino nicht gibt, obwohl sie auch "File" heißen.
Moppi bemängelte ja, dass es bei x86 asm so viel "logischer" wäre, aber auch hier bezog er sich auf x86, im Gegensatz zu C(++).

mich quält mal wieder C++
...
das war das schöne an x86 Assembler

In C aber gibt es ja gewisse Funktionen, die logisch wären, wie z.B. die printf/scanf-Familie, für stdin/out und files, und hier ist tatsächlich quasi "alles" ein File
Worauf ich hinaus wollte:
obwohl es das grundsätzlich für C gibt und dort auch logisch und im gewissen Rahmen verfügbar ist:
das gibt es eben nicht für Arduino, aber das ist keine Schuld von C++, womit moppi haderte, sondern es liegt am fehlenden File system mit den entsprechenden Libs.
Und hier sind wir uns ja auch einig.

[Moppi]

Ich habe eine sehr interessante Lösungsstrategie gefunden.

https://www.arduinoforum.de/arduino-...byte-Variablen

Mit dieser UNION-Geschichte sollte es möglich sein, eine Kette an Bytes zu laden, um dann mit verschiedenen Datentypen, an verschiedenen Stellen in dieser Byte-Kette, zugreifen zu können.

Da tun sich viele Möglichkeiten auf, was man mit UNION und Datentypen anstellen kann.




MfG

[HaWe]

ja, mit union mache ich es teilw. auch, wenn ich einen array of bytes habe, der verschiedene Datentypen enthält, allerdings mit eigenen Funktionen, die weniger kompliziert aussehen

[Moppi]

Muss man mal wissen, dass es so etwas gibt.
Damit kann man char-Arrays an Methoden als string übergeben usw.
Mehrere Datentypen für einen Speicherbereich.

[HaWe]

Damit kann man char-Arrays an Methoden als string übergeben usw.

ja, aber gerade bei cstring musst du beachten, dass sie immer aus
char
und nicht aus uint8_t bestehen:

char str1[20];
char* str2;

und dass char in cstrings bei AVR kein byte und auch kein uint8_t (0..255) sondern ein signed char ist (-128..+127).
Bei ARM/ESP hingegen ist die cstring-char unsigned, also quasi "wie ein byte".
Aber auch wenn char hier unsigned sind, kann man dennoch nicht byte oder uint8_t arrays dafür einsetzen bzw. verwenden.

Genau darauf wollte ich oben in meinen Posts #5 und #7 hinaus.

[Moppi]

Muss man drauf achten, was man tut.


Habs jetzt mal so gemacht:

union xyzS{
               uint8_t  byt[6];                //XYZ-Array: 3 Werte mit 16 Bit   
               uint16_t val[3];
}; 
xyzS xyzSet;

Zugriff:

f.read(xyzSet.byt,6);
uint16_t ACX = xyzSet.val[0];
uint16_t ACY = xyzSet.val[1];
uint16_t ACZ = xyzSet.val[2];