Ich habe noch diesen GY 61
Das braucht man nicht zu prüfen, das sehe ich aus 300km Entfernung, dass da der Teufel drin steckt.
Das ist das Skript was direkt bei dem Chip als Beispiel dabei ist… siehe den Link bei Post #82
LG
Kann schon sein...
Eine tödliche Falle ist eine tödliche Falle!
Auch wenn sie irgendwo publiziert wird.
Überraschend tödlich wird sie dadurch, wenn das Gehirn nicht eingeschaltet wird.
Tipp:
Du musst mir nicht glauben.
(selber nachdenken macht selber schlau)
Dann hat der dortige Programmierer keine Ahnung.
result wird als lokales Array auf dem Stack angelegt und der wird am Ende der Funktion frei gegeben. Es kann zufällig funktionieren, dass das, worauf der Zeiger zeigt noch nicht überschrieben ist, aber ich würde mich nicht darauf verlassen. (Die Erklärung ist etwas vereinfacht).
Gruß Tommy
Ich will das nochmal etwas präzisieren.
Es könnte ja der Einwand kommen, beim z.B. Returntype int wird ja auch das int ordentlich zurück gegeben (oder jeder andere direkte Wert).
Ja das stimmt und das passiert auch bei char * (und anderen Arrays, die in der Funktion angelegt wurden).
Dort wird der Zeiger auf das Array zurück gegeben. Das ist ok.
Aber der Speicherbereich mit dem Inhalt des Arrays ist freigegeben und höchstwahrscheinlich überschrieben.
Gruß Tommy
Um das Testen an dieser Stelle nicht zu gefährden, ein Vorschlag von mir, der das Problem umschiffen sollte. Es ist vermutlich nicht besonders sauber, aber sollte das potentielle Problem beheben. Bessere Vorschläge oder Korrekturen meines Schnellschusses bitte vor ...
char result[7]; // am Anfang
// Rest des codes hier einfügen
char* toStr(int16_t value)
{
sprintf(result, "%6d", value);
return result;
}
Also weiter mit 
Und wie ich hier erkennen muss ignoriest Du ja immer noch die Fragen auch Bilder wie es im Model verkabelt ist fehlen. Da kann Dir keiner Helfen.
Und deine Frage kennst Du dich überhaupt mt Modellbau aus. WOW Du zerfließt in Selbstüberschätzung @HotSystems hat vielleicht kein Modellbau zuhause Dafür könnte ich aber reichlich beitragen. Da sollten meine 40 Jahre Modellerfahrung schon ausreichen 
Ich bin sicher, dass viele großartige, umfassende technische Erfahrungen einzubringen haben. Deswegen lese ich ja auch gern in diesem Forum mit.
Der Ton ist aber schon manchmal ein bisschen ... sagen wir mal provokant und dann führt das schon mal zu menschlichen Reaktionen. Ich wundere mich häufig, wie ätzend der Ton hier wird.
Ja, manchmal wird eine Frage nicht richtig verstanden oder aus Irritation heraus ignoriert. Manchmal, weil die Frage teils vermuten lässt, dass der Fragesteller bereits gegebene Information ignoriert, selbst aber besondere Sorgfalt einfordert.
Ich schätze alle technische Kompetenz hier sehr!
Ansonsten gilt aber auch, wie man in den Wald hineinruft ....
Das ist sehr gelinde ausgedrückt.
Wenn ein Fragesteller so kommt, ist das schon ziemlich arrogant und ich ziehe mich einfach zurück. Da dürfen andere dann ran.
1 Like
Statt einer globalen Variablen namens result hätte ein lokales
static char result[7];
innerhalb der Funktion den gleichen Effekt.
Noch einfacher könnte man direkt die Methode print(int) verwenden.
Wenn es denn bei einem Test, ob dies die "Abstürze" beeinflusst, auf Schönheit (genau 6 Ziffern) ankommt, ist auch ein Tabulator-Zeichen '\t' eine Alternative
1 Like
Ja!
- unnötiger statischer Speicherverbrauch
- eingeschränkte Wiederverwendung (z.B. non reentrant)
Einziger Vorteil: Es müllt den globalen Geltungsbereich nicht voll. Aber das ist ja auch schon was.
Hier mal eine Erweiterung.
So bleibt der Buffer lokal, allerdings im Geltungsbereich der aufrufenden Funktion.
Es wird ein versehentliches Überschreiten der char Array Grenzen verhindert.
Reentrance bleibt erhalten
Schafft Platz für das Vorzeichen
#include <Streaming.h> // die Lib findest du selber ;-)
Print &cout = Serial; // cout Emulation für "Arme"
template<size_t N> char* toStr(char (&buffer)[N], const int16_t value)
{
static_assert(N>7,"Buffer zu klein");
snprintf(buffer, N, "%6d", value);
buffer[N-1] = '\0'; // das u.U. rettende Stringende
return buffer;
}
void setup()
{
Serial.begin(9600);
cout << F("Start: ") << F(__FILE__) << endl;
char temp[12]; // lieber etwas zu groß als zu klein
int16_t test = 4711;
cout << F("test: ") << toStr(temp,test) << endl;
test = 42;
cout << F("test: ") << toStr(temp,test) << endl;
}
void loop()
{
}
Jo da muss ich mich entschuldigen hab das Skript nicht gründlich gelesen und mal darauf vertraut das es stimmt Huch danke für die Korrektur! LG
Ja, nee..
Musst du nicht.
Es reicht vollkommen einen Fehler/Irrtum einzusehen und zu vermeiden.
Das habe ich für mich aufgegeben.
Mittlerweile gehe ich davon aus, dass rund 90% der Angaben im großen weiten Internet fahrlässig bis gefährlich sind.
(das gilt übrigens auch für meine Ansagen, selbst wenn ich anderer Ansicht bin)
Nachtrag, zu meiner obigen Funktion. Da ich die Streaming Lib verwende, geht das alles viel einfacher!
#include <Streaming.h> // die Lib findest du selber ;-)
Print &cout = Serial; // cout Emulation für "Arme"
void setup()
{
Serial.begin(9600);
int16_t test = 4711;
cout << F("test: ") << _WIDTH(test,7) << " Eier" << endl;
test = 42;
cout << F("test: ") << _WIDTH(test,7) << " Eier" << endl;
}
void loop()
{
}
Ausgabe:
test: 4711 Eier
test: 42 Eier
Nun.... Was ist provokant wenn man 60 Post abwartet um dann noch immer kein brauchbares Bild der Leitungsführung sieht?
Post#60 (Bild) lässt ja schon mal erahnen wo es dran liegt. Jetzt sind wir hier bei Post #106 und immer noch nicht weiter.
Grund: Die schnellschüsse ins Blaue. .
Nein hast Du nicht Du hast am Anfang einen 3S an BMC erwähnt.
1 Like
This topic was automatically closed 180 days after the last reply. New replies are no longer allowed.