Serial.print() Funktion - Versionsgeschichte

Chris T. Ludwig: /* 2.Fall */

2021-03-05T19:15:53Z

2.Fall

← Nächstältere Version		Version vom 5. März 2021, 21:15 Uhr
Zeile 26:		Zeile 26:

	==2.Fall==		==2.Fall==
	Das Gepointere geht fast immer die Hose. Obwohl die Logik (Speicherbereich zugewiesen, Inhalt vorhanden, String korrekt mit \0 abgeschlossen, ...) stimmt, erhält man nicht das gewünschte Ergebnis.		Das Gepointere geht fast immer in die Hose. Obwohl die Logik (Speicherbereich zugewiesen, Inhalt vorhanden, String korrekt mit \0 abgeschlossen, ...) stimmt, erhält man nicht das gewünschte Ergebnis.
	Hier habe ich mehrfach ~~eine~~ Versuche, die über seriellen Output oder ~~StatusLEDs~~ den Programmzustand nach "außen" melden, abgebrochen.		Hier habe ich mehrfach Versuche, die über seriellen Output, StatusLEDs oder angeschlossenes Display den Programmzustand nach "außen" melden, abgebrochen.

	==Lösung(en)==		==Lösung(en)==

Chris T. Ludwig: /* 1. Fall */

2021-03-05T13:04:49Z

1. Fall

← Nächstältere Version		Version vom 5. März 2021, 15:04 Uhr
Zeile 24:		Zeile 24:
	Unabhängig von der Scope-Problematik, sehe ich als Ursache fehlerhaft programmierte Libraries als Ursache. Dies tritt gerade dann zu Tage wenn mehrere Libraries in einem Programm benutzt werden, die sich		Unabhängig von der Scope-Problematik, sehe ich als Ursache fehlerhaft programmierte Libraries als Ursache. Dies tritt gerade dann zu Tage wenn mehrere Libraries in einem Programm benutzt werden, die sich
	dann sehr oft gegenseitig beeinflussen. Die Problem wird dann auch noch durch den Umstand verstärkt wenn die (RAM-)Ressourcen ausgereizt werden, oder der Zugriff auf Kommunikationsschnittstellen aufgeteilt wird.		dann sehr oft gegenseitig beeinflussen. Die Problem wird dann auch noch durch den Umstand verstärkt wenn die (RAM-)Ressourcen ausgereizt werden, oder der Zugriff auf Kommunikationsschnittstellen aufgeteilt wird.

			==2.Fall==
			Das Gepointere geht fast immer die Hose. Obwohl die Logik (Speicherbereich zugewiesen, Inhalt vorhanden, String korrekt mit \0 abgeschlossen, ...) stimmt, erhält man nicht das gewünschte Ergebnis.
			Hier habe ich mehrfach eine Versuche, die über seriellen Output oder StatusLEDs den Programmzustand nach "außen" melden, abgebrochen.

			==Lösung(en)==
			Mein einziger Ansatz, der Lösungen verspricht, ist das Emulieren oder noch besser Step-Debugging wie ich es noch aus der Assemblerzeit mit dem MC86HC05/11 her kenne. Zu diesem Zweck habe ich mir jetzt mal
			den Atmel-ICE ([https://de.wikipedia.org/wiki/In-Circuit-Emulator In-Circuit-Emulator]) zugelegt und werde die oben genanten Fälle mal "low Level" untersuchen.

			to be continued ...

			==Request for Comments==

			<comments />

Chris T. Ludwig: Die Seite wurde neu angelegt: „oder serial.println() Nach dem ich schon in mehreren Programmen Probleme mit "zerschossenen" Variablen hatte trage ich hier mal alle meine Infos zusammen.…“

2021-03-05T12:52:24Z

Die Seite wurde neu angelegt: „oder serial.println() Nach dem ich schon in mehreren Programmen Probleme mit "zerschossenen" Variablen hatte trage ich hier mal alle meine Infos zusammen.…“

Neue Seite

oder serial.println()

Nach dem ich schon in mehreren Programmen Probleme mit "zerschossenen" Variablen hatte trage ich hier mal alle meine Infos zusammen.

Ähnlich gelagerte Probleme haben andere Nutzer bereits in Foren formuliert.

https://www.arduinoforum.de/arduino-Thread-Problem-mit-char-array

https://forum.arduino.cc/index.php?topic=368430.0

Mit den Antworten war ich allerdings weniger zufrieden. Ich finde in Foren einfach zu oft die Reaktion:

#Warum machst Du das so?
#Das geht so viel besser!
#Dein Ansatz ist falsch.

Das heißt eigentlich wird gar zu selten auf das eigentliche Problem eingegangen, sondern es wird einfach ein Workaround geschildert oder gar eine komplett andere Evtl-Lösung empfohlen.
Ein Kommentator spricht mir aus der Seele:

Ich verstehe deinen Lösungsvorschlag schon, aber mich würde mehr interessieren, warum meine Lösung nicht funktioniert.

==1. Fall==
Variablen haben nach einem Funktionsaufruf einen anderen (undefinierten) Wert, obwohl sie in der Funktion gar nicht benutzt wurden.
Unabhängig von der Scope-Problematik, sehe ich als Ursache fehlerhaft programmierte Libraries als Ursache. Dies tritt gerade dann zu Tage wenn mehrere Libraries in einem Programm benutzt werden, die sich
dann sehr oft gegenseitig beeinflussen. Die Problem wird dann auch noch durch den Umstand verstärkt wenn die (RAM-)Ressourcen ausgereizt werden, oder der Zugriff auf Kommunikationsschnittstellen aufgeteilt wird.