Hallo Nibbels!

Danke vielmals für die sehr gute Erklärung .

Eine Anmerkung hätte ich aber noch:

Die Aktion ist tatsächlich ohne tatsächlichen Nutzen

Doch, für Entwickler ist dies essentiell (zum. für mich). Der Compiler zeigt mit den Warnings an, daß evtl. sehr essentielle Probleme, Mißverständnisse, Denkfehler oder Laufzeitprobleme auftreten können, welche die Entwickler nicht bedacht haben könnten. Der compilierte Code funktioniert aber oft nicht so, wie es sich der Entwickler vorgestellt hat.

Die redefinierten String-Konstanten für die Oberfläche sind dabei ein vernachlässigbares Übel. Richtig böse können Overflows oder Unitialized Memory Warnings werden, da hier plötzlich ganz andere als die erwarteten / angegebenen Werte verwendet werden. Uninitialisierte Pointer gehören ebenfalls dazu. Uninitialisierte Variablen sind deshalb so böse, da hier der Programmierer meistens vom Wert 0 ausgeht oder kein Initialisierungszweig durchlaufen wurde und der Wert deshalb vom letzten Zustand des Speichers / Stacks abhängt. Bsp.: Es wird die Variable für einen Z-Offset gelesen. Erwarten würde der Entwickler den Wert 0 (mm) da die Variable nicht explizit initialisiert war. Vorher stand an der Speicheradresse zuletzt aber 42 drin. Da die Variable nicht initialisiert wurde, wird jetzt mit 42 (mm) gearbeitet anstatt 0. Und das Ganze tritt dann auch noch zur Laufzeit völlig willkürlich und nicht reproduzierbar auf. NICHT GUT.
Und man sollte sich nicht darauf verlassen, daß der Stack / der Speicher immer schön sauber mit 0x0 initialisiert ist.

Deshalb halte ich es für so wichtig, die Warnings mit den uninitialisierten Variablen wegzubekommen --> sie können dann nicht mehr die Ursache für das unterschiedliche Verhalten derselben Firmware auf unterschiedlichen Druckern sein.

' (increment<0) ': Hier ist 'increment' eine 'unsigned' variable (ohne Vorzeichen). Der Wert kann nie < 0 werden. Bei unsigned char ist der '0 -1' nicht '-1' sondern 255. --> Hier wird immer nur der else Zweig durchlaufen ...

Ist '\x0' hier besser als eine normale 0?

Nö. Ich hatte nur den Typ char gesehen, und dann daraus '\x0' gemacht, das es das 0-Byte char ist. 0 ist absolut gleichwertig (ebenso 0x0).

Hilft das weiter?

Viele Grüße und sorry für's zutexten ...

Wenn mich was dermaßen interessiert werde ich gerne zugetextet ^^.
Nur mehr als 1,5h am Stück bin ich nicht gewohnt
Ich hatte Informatik im Abi und diese Boolsche Algebra, digitale Datenstrukturen, Zähler, Schieberegister etc. kenne ich.

"Overflows"
Das ist mir logisch absolut klar. Auch dass C einfach nichts prüft und stupide im Speicher rumschreibt - wenn man es lässt. Nur wieviel intelligenz die Compiler inzwischen besitzen weiß ich nicht. Ich glaube aber die denken da überhaupt nicht mit.
in der ui.cpp gibts 3x Stellen, wie:
uint8_t nr = pgm_read_word_near(&(men->numEntries));
Für mich war ein word immer 2 Bytes, das uint8 ein byte - egal was drinsteht.

Der Code den du oben zitierst:

rf_42 hat geschrieben:

Code: Alles auswählen

sketch\ui.cpp:2542:149: warning: comparison of unsigned expression < 0 is always false [-Wtype-limits]
 #define INCREMENT_MIN_MAX(a,steps,_min,_max) if ( (increment<0) && (_min>=0) && (a<_min-increment*steps) ) {a=_min;} else { a+=increment*steps; if(a<_min) a=_min; else if(a>_max) a=_max;};
 

' (increment<0) ': Hier ist 'increment' eine 'unsigned' variable (ohne Vorzeichen). Der Wert kann nie < 0 werden. Bei unsigned char ist der '0 -1' nicht '-1' sondern 255. --> Hier wird immer nur der else Zweig durchlaufen ...

An diesen zwei Fällen knabbere ich noch immer. Die Variable die da "verglichen wird" ist ein Zeitstempel vom Typ millis_t, was uint32_t entspricht. Die will ich auch nicht umbauen und in ihrer maximalen Höhe limitieren.
Ich hab diese zwei Warnungen noch drin. Wenn die weg wäre, wäre die Firmware schön sauber.
Würdest du hierfür ein neues zweites INCREMENT_MAX einführen? Oder einfach so lassen?

LG

Hallo Nibbels!

Auch dass C einfach nichts prüft und stupide im Speicher rumschreibt

C / C++ führt soviele Prüfungen wie möglich zur Compilationszeit durch. Viele Sachen sind allerdings Warnings, die man sich anzeigen lassen sollte (Warnings Compilerschalter), weil der Compiler zwar ausführbaren Code erzeugt, der aber mit einiger Wahrscheinlichkeit das Ergebnis nicht ganz das sein könnte, was sich der Entwickler gedacht hat.
Außerdem: C und bis zu einem gewissen Grade C++ sind für Echtzeit-Kriterien geeignet. D.h. C / C++ darf nichts implzit zusätzlich ausführen wie z.B. eine implizite Speicherinitialisierung mit 0, ... wie es Java und C# machen. Wenn man aber eine negative Integer, long, ... Zahl mit einer Zahl vergleicht, welche per Definitionem nie negativ werden kann, existiert ein Überraschungseffekt, auf welchen der Compiler hinweisen will. Mit dem unerwarteten Ergebnis muß der Anwender leben

Würdest du hierfür ein neues zweites INCREMENT_MAX einführen? Oder einfach so lassen?

Ich persönlich würde ein neues zweites INCREMENT_MAX einführen, diese neue Funktion modifizieren und nur dort verwenden, wo die Warning aufgetreten ist. Das basiert auf dem Open-Closed-Prinzip in der Software-Entwicklung und auf ERfahrungen, daß Du nie mit 100 prozentiger Sicherheit sagen kannst, ob nicht irgendwo im Sourcecode irgendeine Funktion auf gen die Logik angewiesen ist, welche Du zu modifizieren gedenkst.
(siehe https://de.wikipedia.org/wiki/Prinzipie ... Prinzipien)

Viele Grüße

Danke!!

Mir fällt gerade noch etwas ein, was vielleicht hier hinein passt.

Mein RF1000 ist schon immer vom X und Y Motor extrem laut.
Sodass man eigentlich meist Kopfschmerzen bekommt, wenn man sich im selben Raum aufhält.
Da das alles relativ hohe Frequenzen sind lässt sich das gut mir Oropax überleben. Das ist aber auch nicht so die Patentlösung.

Ich habe jetzt das ein oder andere mal gelesen, dass das auch von Firmware zu Firmware unterschiedlich wäre.
(Oder es liegt eben nur an meinem Gerät)

Hat sich da denn in der neuen Firmware etwas getan?
Dann würde ich nämlich auch mal über ein Update nachdenken.

Grüße

Gegenfrage: welche FW läuft bei deinem Drucker?
Hintergrund: ich meine, dass sich tatsächlich beim Motorgeräuschpegel etwas geändert hat über die FW-Versionen hinweg. Kann mich nicht mehr erinnern bei welchem Wechsel die Motoransteuerung geändert wurde, aber es wäre (eventuell für andere die es noch wissen) hilfreich, zu wissen welche Version bei dir läuft


Edit: Hinweis in diesem Thread: http://www.rf1000.de/viewtopic.php?p=15131#p15131

stilotto hat geschrieben:Hallo!

Ich habe heute die 1.33 geflasht weil mir bei 1.10 die Motoren zulaut waren.
und nun ist wieder alle in Ordnung!
Danke

lg Otto

Verzeihung, das habe ich doch glatt vergessen zu erwähnen.
Ich habe die Firmware 0.91.48 drauf.

Grüße

OK... mir ist sie bisher nicht als sonderlich laut aufgefallen.

@ diejenigen die von 0.91.48 auf RF.01.33 oder 35 geupgradet haben, hat sich beim Geräuschpegel was geändert? Würde mich auch interessieren... Danke!

0.91.48 sollte auf jeden Fall lauter sein. Ich hab damals auf eine andere Version vor 01.33 gepudatet.
Da hat sich Sound mäßig einiges getan. Irgendwas mit den Mikroschritten wurde da gemacht.
War ein Segen von der Lautstärke her .

Oo

Oo, R3D3,

Die Anzahl der Mikroschritte wurde schon in der Version 0.91.48 von dem Standardwert 8 auf den neuen Wert 32 geändert (laut Changelog).Damit werden es nicht die Mikroschritte sein, die zur Geräuschminderung geführt haben.

Es gab einmal eine Stromreduzierung, bei einer früheren Version, ich glaube aber auch nicht, dass es das war.

Wer Lust hat, kann alle Changelogs durchackern.

mjh11