Stringverknüpfung C/C++

Mikro 7. schrieb:
> Serial.println(std::string("Boa") + "Constructor");

1

'string' is not a member of 'std'

Sven B. schrieb:
> Mikro 7. schrieb:
>> (std::string("Boa") + "Constructor").c_str()
>
> Fraglicher Pattern, das funktioniert genau wenn es direkt als Argument
> einer Funktion benutzt wird (die es sich zudem nicht merken darf) und
> ansonsten nicht.

was?

> Serial.println("Boa" + "Constructor");
>
> Auch mit "&" geht es nicht. Für einen Tipp danke ich.

Serial.println("Boa" "Constructor");

HTH

1

Serial.println("Boa"  "Constructor");

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

1

Serial.println(String("Boa")+String("Constructor"));

-----------

1

Serial.println(String("Boa")+"Constructor");

---------

1

char a[] = "Boa";

2

char b[] = "Constructor";

3

4

void setup() 

5

{

6

  char temp[strlen(a)+strlen(b)+1] = "";

7

  strcpy(temp,a);

8

  strcat(temp,b);

9

10

  Serial.begin(9600);

11

  Serial.println(temp);

12

}

13

14

void loop() {

15

}

g457 schrieb:
> Serial.println("Boa" "Constructor");

geht.




Mikro 7. schrieb:
> Boa Constructor schrieb:
>> Mikro 7. schrieb:
>>> Serial.println(std::string("Boa") + "Constructor");
>>
>>

1

'string' is not a member of 'std'

>
> #include <string>

Ändert nichts. In allen Varianten nicht, auch nicht mit string.h

Boa Constructor schrieb:
> Ändert nichts. In allen Varianten nicht, auch nicht mit string.h

Was verwendest Du denn. C oder C++?

Dirk B. schrieb:
>

1

Serial.println("Boa");

2

> Serial.println("Constructor");

Dies habe ich bis jetzt getan. Nur mit mehr Strings. Gab irgendwann 
Performanceprobleme, daher will ich davon weg.

Das einzige, was bis jetzt geht, ist das hier.

1

Serial.println("Boa" "Constructor");

Bei der anderen Variante kriege ich leider immer

1

'string' is not a member of 'std'

Danke bisher

Brummbär schrieb:
> Boa Constructor schrieb:
>> Ändert nichts. In allen Varianten nicht, auch nicht mit string.h
>
> Was verwendest Du denn. C oder C++?

k. Ahn., die Arduino IDE.  ich denke  C++ ist drin

Mikro 7. schrieb:
> Boa Constructor schrieb:
>> g457 schrieb:
>>> Serial.println("Boa" "Constructor");
>>
>> geht.
>
> Das funktioniert, solange du Literals benutzt. Mit Variablen gehts es
> aber nicht.
>
>>> #include <string>
>>
>> Ändert nichts. In allen Varianten nicht, auch nicht mit string.h
>
>

1

> #include <string>

2

> #include <stdio.h> // printf

3

> 

4

> int main()

5

> {

6

>   printf("%s\n",(std::string("Boa") + "Constructor").c_str()) ;

7

>   return 0 ;

8

> }

9

>

Das funzt leider auch nicht. Oder bin ich zu blöd dazu, kann das sein?

1

#include <string>

2

3

                  ^

4

5

compilation terminated.

6

7

exit status 1

8

Fehler beim Kompilieren für das Board Arduino/Genuino Mega or Mega 2560.

Boa Constructor schrieb:
> Dies habe ich bis jetzt getan. Nur mit mehr Strings. Gab irgendwann
> Performanceprobleme, daher will ich davon weg.

Performanceprobleme?
Glaube ich nicht!

Hier noch eine Variante:

1

#include <Streaming.h> // suche nach "Arduino Streaming.h"

2

3

void setup() 

4

{

5

  Serial.begin(9600);

6

  Serial << "Boa" << "Constructor" << endl;

7

}

8

9

void loop() {}

Boa Constructor schrieb:
> Das funzt leider auch nicht. Oder bin ich zu blöd dazu, kann das sein?
> #include <string>
Bei der AVR ToolChain ist die STL nicht dabei.

mhh.

Niemand hat eine Idee? Dann brauche ich meine 2. Frage gar nicht zu 
stellen, wie ich Zahlenwerte in den Ausgabestring hinein bekomme.

Mikro 7. schrieb:
> Arduino Fanboy D. schrieb:
>> Bei der AVR ToolChain ist die STL nicht dabei.
>
> Habe ich auch gerade gesehen. Also kein vollst. C++ Support.
>
> @Boa: Dann ignoriere mein Postings.

keine Ursache. Danke trotzdem.

Arduino hat eine eigene String Klasse, die ist hier dokumentiert: 
https://www.arduino.cc/reference/en/language/variables/data-types/string/

Die einzig sinnvolle Antwort hat hier jedoch Dirk gegeben: Man soll die 
Strings nicht zusammenfügen, wenn es vermeidbar ist.

Und zwar schlicht und ergreifend deswegen, weil man dann zumindest 
zeitweise doppelt so viel RAM belegt. Die beiden Quell-Strings belegen 
bereits Speicher und das Ergebnis der Zusammenfügung belegt nochmal 
Speicher.

Dazu kommt, dass man durch String-Manipulation Ratz-Fatz einen 
fragmentierten Heap produziert, der zu einem Heap/Stack Überlauf führt.

https://hackingmajenkoblog.wordpress.com/2016/02/04/the-evils-of-arduino-strings/

> wie ich Zahlenwerte in den Ausgabestring hinein bekomme.

Wenn keine besondere Formatierung notwendig ist, dann fülle einen Puffer 
(char[]) mit atoi() oder atol(). Siehe 
https://www.nongnu.org/avr-libc/user-manual/group__avr__stdlib.html

Wenn du Formatieroptionen brauchst, dann nimm printf(). Siehe 
https://www.nongnu.org/avr-libc/user-manual/group__avr__stdio.html

Die Serial Klasse von Arduino hat auch Funktionen für formatierte 
Ausgabe: 
https://www.arduino.cc/reference/en/language/functions/communication/serial/print/

Stefanus F. schrieb:
> Arduino hat eine eigene String Klasse, die ist hier dokumentiert:
> https://www.arduino.cc/reference/en/language/variables/data-types/string/
>
> Die einzig sinnvolle Antwort hat hier jedoch Dirk gegeben: Man soll die
> Strings nicht zusammenfügen, wenn es vermeidbar ist.
>
> Und zwar schlicht und ergreifend deswegen, weil man dann zumindest
> zeitweise doppelt so viel RAM belegt. Die beiden Quell-Strings belegen
> bereits Speicher und das Ergebnis der Zusammenfügung belegt nochmal
> Speicher.
>
> Dazu kommt, dass man durch String-Manipulation Ratz-Fatz einen
> fragmentierten Heap produziert, der zu einem Heap/Stack Überlauf führt.
>
> 
https://hackingmajenkoblog.wordpress.com/2016/02/04/the-evils-of-arduino-strings/

Ist schon klar. Ob der uC Garbage Collection kann (?) ist ja auch egal, 
lags will ich nicht provozieren. Momentan habe ich aber zuweilen eine 
Rekursion im ISR, wenn dort zu viele Serial.print ausgegeben werden. Was 
soll ich machen ohne Debugger. Es ist wie bei armen Leuten

Boa Constructor schrieb:
> Ob der uC Garbage Collection kann (?)

Dafür bräuchtest du ein Betriebssystem, welches das steuert, und eine 
Memory Mapping Unit. AVR sind davon sehr weit entfernt.

Stefanus F. schrieb:
> Arduino hat eine eigene String Klasse, die ist hier dokumentiert:
> https://www.arduino.cc/reference/en/language/variables/data-types/string/

ja das geht, danke schonmal.

Kann ich auch Zahlen in den String integrieren?  Keine Literale, sondern 
Variablen. also wer VB kennt, ist beeindruckt von dem Aufwand in c. Soll 
aber keine Wertung sein, aber Stringverarbeitung ist (m.E.,) ein Kreuz

Stefanus F. schrieb:
> Boa Constructor schrieb:
>> Ob der uC Garbage Collection kann (?)
>
> Dafür bräuchtest du ein Betriebssystem, welches das steuert, und eine
> Memory Mapping Unit. AVR sind davon sehr weit entfernt.

Habe ich vermutet. Die Andeutung war auch eher theoretisch.

Boa Constructor schrieb:
> Kann ich auch Zahlen in den String integrieren?

Du hast die Seite nicht wirklich gelesen. Ich zitiere:

" For more details on the String object, which gives you more 
functionality at the cost of more memory, see the String object page."

Da hättest du nur drauf klicken brauchen.

https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Die "Garbage Collection" von C++ nennt sich Smart Pointer. Natürlich ist 
das keine Garbage Collection im eigentlichen Sinne sondern nur die 
automatisierte Freigabe von Resourcen gebunden i.d.R. an die Destruktion 
des Smart Pointers (ein Objekt das eine Referenz auf die Resource 
besitzt).

Eine Garbage Collection im klassischen Sinn muss die Sprache selbst 
unterstützen. Das ist bei C und C++ nicht der Fall (und auch nicht 
wünschenswert). Eine Memory Management Unit + OS sind hilfreich aber 
eigentlich keine Voraussetzung. Die Garbage Collection ist bei 
(teil)interpretierten Sprachen eng mit der VM gekoppelt.

Stefanus F. schrieb:
> Boa Constructor schrieb:
>> Kann ich auch Zahlen in den String integrieren?
>
> Du hast die Seite nicht wirklich gelesen. Ich zitiere:
>
Ehrlich gesagt noch gar nicht. English quält mich immer so, da muss ich 
Zeit+Ruhe haben. Bin gerade i.d. Küche am kochen :)

Programmieren ohne Englisch ist wie Kochen ohne Feuer. Weit kommt man 
ohne Englisch nicht, da musst du durch.

Die Zeiten, wo man sich dicke Bücher auf deutsch kaufen konnte, sind 
vorbei.

Boa Constructor schrieb:
> Momentan habe ich aber zuweilen eine
> Rekursion im ISR, wenn dort zu viele Serial.print ausgegeben werden.

Niemals in einer ISR Strings ausgeben. Das macht man nicht.
Eine ISR hat immer, bis auf ganz wenige Ausnahmen, so kurz wie möglich 
zu sein. Keine Ausgaben, keine (großen) Berechnungen, keine Delays.

Brummbär schrieb:
> Boa Constructor schrieb:
>> Momentan habe ich aber zuweilen eine
>> Rekursion im ISR, wenn dort zu viele Serial.print ausgegeben werden.
>
> Niemals in einer ISR Strings ausgeben. Das macht man nicht.
> Eine ISR hat immer, bis auf ganz wenige Ausnahmen, so kurz wie möglich
> zu sein. Keine Ausgaben, keine (großen) Berechnungen, keine Delays.

Ja Brummbär, entspann dich wieder :)

Boa Constructor schrieb:
> Was soll ich machen ohne Debugger. Es ist wie bei armen Leuten

Peter D. schrieb:
> Ich hab da schon die dollsten Sache erlebt, wenn alle Ausgaben einzeln
> definiert werden, z.B.:

Aber kein "Errör"?

Konkretisiert schlägt der Wachhund an, wenn ich (testweise) 2 Meßreihen 
a' 5 Werte ausgebe. Das sind 2x 5 Werte mit 2x4 Tabs ("\t") dazwischen, 
also insg. 18 Serial.print. Das ist zuviel Last, weiß ich. Der ISR 
taktet mit 160 Hz.

Peter D. schrieb:
> Boa Constructor schrieb:
>> Dies habe ich bis jetzt getan. Nur mit mehr Strings. Gab irgendwann
>> Performanceprobleme, daher will ich davon weg.
>
> Bei Strings sollte man sich erstmal ein einheitliches Format überlegen,
> denn meistens sind Ausgaben recht ähnlich aufgebaut. Das erleichert es
> auch, die Ausgaben konsistent und ohne Schreibfehler zu halten.
> Obenrdrein spart es auch massig Speicher.
> Ich hab da schon die dollsten Sache erlebt, wenn alle Ausgaben einzeln
> definiert werden, z.B.:
> "Error xxx\n"
> "error xxx\n"
> "Eror xxx\n"
> "Error: xxx\n"
> "Error xxx!\n"
> "Erorr: xxx !\n"
>
> Beim AVR muß man etwas tricksen, damit Stringkonstanten nicht im RAM
> dupliziert werden.
>
>

1

> #include <avr/pgmspace.h>

2

> #include <stdint.h>

3

> 

4

> const char header_1[] PROGMEM = "header1";

5

> const char footer_1[] PROGMEM = "footer1";

6

> 

7

> void display_item( char* buffer, char* header, uint16_t val, char* 

8

> footer)

9

> {

10

>   sprintf_P(buffer, PSTR("%S %d %S\n"), header, val, footer);

11

> }

12

> 

13

> void test(char* buffer)

14

> {

15

>   display_item(buffer, header_1, 1234, footer_1);

16

> }

17

>

>
> header, footer können auch als Array mit fester Stringlänge im PROGMEM
> definiert werden.

ich mache das bis jetzt so:

1

#define SP(zahl)     Serial.print(zahl)       // Zahl seriell ausgeben

2

#define SPLN(zahl)   Serial.println(zahl)     // Zahl seriell ausgeben mit Zeilenumbruch

3

#define SPT(text)    Serial.print(F(text))    // Text seriell ausgeben

4

#define SPTLN(text)  Serial.println(F(text))  // Text seriell ausgeben mit Zeilenumbruch

5

#define SPTAB        Serial.print("\t")       // Tab ausgeben

aber das ist natürlich nicht performant, nur ein Workarround. Ich muss 
das jetzt verfeinern.

Ansonsten ist das auch nicht kritisch, wenn der Ticker den lfd. Prozess 
einholt, nur unschön.

Peter D. schrieb:
> Boa Constructor schrieb:
>> Konkretisiert schlägt der Wachhund an
>
> Der Watchdog hat in der Entwicklungsphase inaktiv zu sein. Man will ja
> alle Fehler sehen und sie nicht verstecken.

Ist doch kein Watchdog. Nur mein persönlicher "Wachhund" :-) Am 
ISR-Eingang wird, solange dort drin Code ausgeführt wird, abgefragt, ob 
der Event erneut aufgerufen wird. sei() ist natürlich immer aktiv, sonst 
geht das nicht. Ein rekursiver (oder wie sagt man hier..?) Aufruf wird 
mit "return" abgeblockt, so dass der Ticker nicht blockiert wird, 
solange im ISR code läuft.

Stefanus F. schrieb:
> Programmieren ohne Englisch ist wie Kochen ohne Feuer. Weit kommt man
> ohne Englisch nicht, da musst du durch.

Ich kanns ja, es quält mich nur.
Und glaube mir, kochen ohne Feuer geht. Ich bin doch gerade in der 
Küche, am Kochen :)

Peter D. schrieb:
> Boa Constructor schrieb:
>> ich mache das bis jetzt so:
>
> Define ist kein Funktionsaufruf, d.h. der Code wird bei jeder Verwendung
> dupliziert. Mach ne Funktion draus, nur dann spart man auch.

Lohn nicht. Prints gibts nur i.d. entwicklung, als Debugger für arme.

So, habe ein wenig i.d. reference gestöbert u. 1 Lösung gefunden. Es 
scheint auch zu funktionieren, auch wenn es einfach aussieht

https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

1

void setup() 

2

{

3

byte i1 = 1;

4

byte i2 = 2;

5

byte i3 = 3;

6

byte i4 = 4;

7

byte i5 = 5;

8

9

  Serial.begin(9600);

10

  Serial.println(String(i1) 

11

             + String("\t")

12

             + String(i2) 

13

             + String("\t")

14

             + String(i3) 

15

             + String("\t")

16

             + String(i4) 

17

             + String("\t")

18

             + String(i5));

19

}

20

21

void loop() {}

Ob das jetzt performanter ist, weiß ich nicht. Heute werde ich das nicht 
mehr testen. Habs nur geschrieben, falls jemand dasselbe Problem hat, 
kann er/sie hier fündig werden.

Danke an alle.

Noch eine Info für die Nachwelt:

Habe mich noch mal eingelesen.  String (mit großem 'S') ist als 
Speicher-Fragmentierer verpönt. Das sollte man dann wissen. Mir macht's 
nichts, weil es nur zur Entwicklungszeit verwendet wird. Au jeden Fall 
will ich den tipp nicht gegeben haben, ohne darauf zu verweisen.

Diese String Objekt Verwirrung will keiner.

Nutze das Streaming!

Arduino Fanboy D. schrieb:
> Diese String Objekt Verwirrung will keiner.

häh, Altersheimer? diese Verwirrung hast du doch selber eingestreut ^^ 
..

Arduino Fanboy D. schrieb:
>

1

> Serial.println(String("Boa")+String("Constructor"));

2

>

>
> -----------

>

1

> Serial.println(String("Boa")+"Constructor");

2

>

>
> ---------

usw

Boa Constructor schrieb:
> usw

Ist klar!

Arduino Fanboy D. schrieb:
> Ist klar!

Ja du lässt die Leut' ins offene Messer laufen. Ein toller Ratgeber, 
muss ich schon sagen, Respekt.

Rolf M. schrieb:
> Boa Constructor schrieb:
>> Noch eine Info für die Nachwelt:
>>
>> Habe mich noch mal eingelesen.  String (mit großem 'S') ist als
>> Speicher-Fragmentierer verpönt.
>
> Das gilt ganz besonders, wenn man es so benutzt wie in deinem Beispiel

Was konkret ? Nur zum lernen, Speicher ist noch genug frei

Boa Constructor schrieb:
> Ja du lässt die Leut' ins offene Messer laufen. Ein toller Ratgeber,
> muss ich schon sagen, Respekt.

Du irrst!
(etwas plemplem heute?)

Dirk B. schrieb:
> Boa Constructor schrieb:
>> 18 Serial.print. Das ist zuviel Last, weiß ich. Der ISR
>> taktet mit 160 Hz
>
> Das ist kein Problem der 18 Funktionsaufrufe (von Serial.print)
> Es sind zuviel Daten für deine 160 Hz.
>
> bei 9600 Baud / 10 (Bits pro Zeichen) / 160 Hz komme ich auf 6 Zeichen
> die vernünftig rüber kommen.
> Und da wird nichts anderes mehr ausgeführt.

Ja kann sein. Vermutlich hast du recht. Die Baudrate lässt sich 
vielleicht hochsetzen.

Rolf M. schrieb:
> Jedesmal, wenn du den Operator + verwendest, wird für das Ergebnis ein
> neuer Speicherblock allokiert, der natürlich auch jedesmal etwas größer
> ist, als der davor. Da werden dann die beiden Strings reinkopiert. Erst
> ganz am Schluss wird alles wieder freigegeben.

OK, danke. Ja das leuchtet mir ein,

.....
also dann Strings via Array vor-verketten und den (char)Pointer an 
Serial.print übergeben? Nur mal so dahingedacht, bin kein c Profi

Boa Constructor schrieb:
> .....
> also dann Strings via Array vor-verketten und den (char)Pointer an
> Serial.print übergeben? Nur mal so dahingedacht, bin kein c Profi

Wie gesagt ist der beste Weg, die Strings gar nicht zu verketten. Besser 
jeden Teilstring einzeln ausgeben. Durch die serielle Schnittstelle 
kommt das hinten als ein Datenstrom heraus, egal wie viele 
"Serial.print" Aufrufe dazu nötig waren.

OK. Also bleibt es so, wie gehabt

Boa Constructor schrieb:
> ich mache das bis jetzt so:
>

1

> #define SP(zahl)     Serial.print(zahl)       // Zahl seriell ausgeben

2

> #define SPLN(zahl)   Serial.println(zahl)     // Zahl seriell ausgeben 

3

> mit Zeilenumbruch

4

> #define SPT(text)    Serial.print(F(text))    // Text seriell ausgeben

5

> #define SPTLN(text)  Serial.println(F(text))  // Text seriell ausgeben 

6

> mit Zeilenumbruch

7

> #define SPTAB        Serial.print("\t")       // Tab ausgeben

8

>

Ich ging bisher davon aus, die vielen print wären das Problem. Aber wenn 
man nachrechnet, die Baudrate, dann ergibt sich der Rest.

Rolf M. schrieb:
> Auf die Schnelle hab ich dazu auch die folgende ausführlichere Erklärung
> gefunden:
> 
https://hackingmajenkoblog.wordpress.com/2016/02/04/the-evils-of-arduino-strings/

@ Rolf M. gute Seite, sehr aufschlußreich. danke

Boa Constructor schrieb:
> 
https://hackingmajenkoblog.wordpress.com/2016/02/04/the-evils-of-arduino-strings/
> @ Rolf M. gute Seite, sehr aufschlußreich. danke

Ich war derjenige, der den Artikel vorgeschlagen hat.

Dirk B. schrieb:
> Wie schnell ist dein Controller? ca. 10 MHz?

16MHz

Stefanus F. schrieb:
> Ich war derjenige, der den Artikel vorgeschlagen hat.

wos? brauche ich Brille?

nö, es steht 2x oben.

Dann danke an euch beide :))

Boa Constructor schrieb:
> Dann danke an euch beide :))

Jetzt bin ich zufrieden :-)

Den Speicherverbrauch kann man während er Laufzeit sichtbar machen:

https://playground.arduino.cc/Code/AvailableMemory

Das würde ich mal tun, um die verschiedenen Theorien hier bezüglich der 
Stringfunktionen zu überprüfen.

Diese Funktion ermittelt (auf den ersten Blick) die Summer aller freier 
Speicherblöcke. Fragmentierung bemerkt man damit nicht.

Die folgende Funktion testet mit einer in 10er Schritten aus, wie viel 
Speicher man an einem Stück belegen kann.

1

unsigned short function_freememory(char* buffer) {

2

    //

3

    void *p = 0;

4

    size_t size;

5

    for (size = RAMEND; size > 1; size -= 10) {

6

        p = malloc(size);

7

        if (p != 0) {

8

            break;

9

        }

10

    }

11

    if (p != 0) {

12

        free(p);

13

    }

14

    else {

15

        size=0;

16

    }

17

    return sprintf_P(buffer,PSTR("%5u"),size);

18

}

Peter D. schrieb:
> und mit strcat Strings
> aneinander kopieren.
Habe ich dem Roth gezeigt!

Aber dazu sagte er:

Boa Constructor schrieb:
> du lässt die Leut' ins offene Messer laufen.

Stefanus F. schrieb:
> Die folgende Funktion testet mit einer in 10er Schritten aus, wie viel
> Speicher man an einem Stück belegen kann.
> unsigned short function_freememory(char* buffer) {

Die Funktion ist krank oder sehr unsauber.
Gibt offensichtlich einen Zeiger zurück, ist aber als unsigned short 
deklariert.
Das passt nicht.

Es wäre voll ausreichend, wenn sie nur ein size_t zurückgeben würde.
Die Stringgenerierung kann man doch anderen Zuständigkeiten überlassen.

Die korrekte Funktion der Funktion habe ich (noch) nicht getestet.

PeDa
>Man kann auch einfach plain C verwenden und mit strcat Strings
>aneinander kopieren. Dann wird kein unnützer Speicher alloziert.

Das ist schon wahr, aber die Arduino-String-Funktionen sind so 
unglaublich bequem:
https://www.arduino.cc/reference/en/language/variables/data-types/stringobject/

Wirklich, bis man das alles mit C zusammen hat, ist man eine Weile 
unterwegs.

Ich vermute, Arduino-String ist ein Versuch, sich der Java-API zu 
nähern:
https://www.dpunkt.de/java/Referenz/Das_Paket_java.lang/68.html

Arduino Fanboy D. schrieb:
> Die Funktion ist krank oder sehr unsauber.
> Gibt offensichtlich einen Zeiger zurück, ist aber als unsigned short
> deklariert.

Sie gibt die Anzahl der Zeichen zurück, die in den Buffer geschrieben 
wurden.

Ich bin ein bisschen erstaunt, dass du nicht mit der Funktion 
sprintf_P() vertraut bist.

> Es wäre voll ausreichend, wenn sie nur ein size_t zurückgeben würde.
> Die Stringgenerierung kann man doch anderen Zuständigkeiten überlassen.

Ja kann man. Ich habe das aus einem Programm heraus kopiert, wo es so 
gebraucht wurde. Ich erlaube Dir hiermit ausdrücklich, den kopierten 
Code nach deinen Bedürfnissen anzupassen. Zufrieden?

Cornelius schrieb:
> Ich vermute, Arduino-String ist ein Versuch, sich der Java-API zu
> nähern:
Das vermute ich auch.
Denn die ursprüngliche Basis/Vorbild soll wohl Processing sein.

Cornelius schrieb:
> Das ist schon wahr, aber die Arduino-String-Funktionen sind so
> unglaublich bequem:

Noch bequemer ist wohl das Streaming.
Zumindest bei den einfachen Ausgaben die in diesem Thread zu sehen sind.
Siehe: Beitrag "Re: Stringverknüpfung C/C++"

Stefanus F. schrieb:
> Sie gibt die Anzahl der Zeichen zurück, die in den Buffer geschrieben
> wurden.
>
> Ich bin ein bisschen erstaunt, dass du nicht mit der Funktion
> sprintf_P() vertraut bist.

Sorry.
Den Punkt nehme ich zurück....
Es ist kein Zeiger, sondern die Anzahl Zeichen.

Allerdings wäre  hier int der richtige Datentype.
> On failure, a negative number is returned.
Da ist unsigned sicherlich gänzlich falsch.

Arduino Fanboy D. schrieb:
> Da ist unsigned sicherlich gänzlich falsch.

Na also. Klappt doch.
Weiter so.