Bei der Portierung von STM8 (Compiler = SDCC) nach AVR hat mich
folgendes (eigentlich einfaches) schier Verzweifeln lassen (und ich
hätte früher ins Assemblerlisting gucken sollen), Code ist in einer ISR:
SDCC:
1
uint32_charlie_buf;
2
uint32_t nr;
3
4
...
5
if (charlie_buf & (1 << nr))
6
{
7
}
8
...
Ein Blick in meine Notizen zum originalen Programm hat mir auch gezeigt,
warum nr 32-Bit lang war.
AVR-GCC:
macht erst mal irgendwie Müll wenn nr 32-Bit groß ist. Okay, gibt es das
halt in:
1
uint32_charlie_buf;
2
uint32_t nr;
3
4
...
5
if (charlie_buf & (1 << nr))
6
{
7
}
8
...
funktioniert nicht... auch ein cast:
1
if (charlie_buf & ((uint32_t)(1 << nr)))
funktioniert nicht... und warum nicht (das war das was ich im
Assemblerlisting hätte sehen können):
die "1" bei (1 << nr) ist 16 Bit lang und es funktioniert erst richtig
bei:
1
(1ul << nr)
Bei SDCC wirds gleich richtig ausgeführt und bei arm-none-eabi-gcc gibts
das Problem nicht!
Für mich, MERKE: Bei 32-Bit shifting die 1 als ul kennzeichnen.
---------------------------------------------------------
Welche "kuriosen" Fehler gabs bei Euch zuletzt ?
Ralph S. schrieb:> auch ein cast:> if (charlie_buf & ((uint32_t)(1 << nr)))> funktioniert nicht.
Da wird ja auch das Ergebnis des Shifts gecastet. Trotzdem ist 1 per
Definition 16 Bit breit. Du hättest also die 1 auf long casten müssen
(was letztendlich mit dem ul auch passiert ist)...
ich sag ja: dummer Fehler, ich hatte nicht mehr im Kopf, dass die 1
16-Bit breit ist.
Witzigerweise hatte der SDCC das "richtig" gemacht gehabt wenn die bei
1 << nr
nr 32-Bit groß ist. Sollte ich noch einmal in die Verlegenheit kommen,
32 Bit shiften zu müssen, bekommt die 1 immer auch ul mit, egal auf
welchem Compiler.
> Welche "kuriosen" Fehler gabs bei Euch zuletzt ?
Callback von espconn_gethostbyname in ESP8266_NONOS_SDK liefert einen
Nullpointer als IP-Adresse zurück, wenn kein Internetzugriff vorhanden
ist. Der Fehler (Exception mit Reboot) trat bei mir nur 1x am Tag bzw.
eben 1x nachts auf, weil dann mein DSL-Modem neu connectete... Ein
Nullpointer kopiert sich relativ schlecht mit memcpy...
if (ipaddr != NULL) ... Steht zwar im Beispielcode im Manual, aber
kommentarlos und ohne Warnungen oder Erklärungen.
Bis ich die genauen Umstände und Zusammenhänge begriffen hatte, dauerte
es etwas...
Viele.
Manche soviel Zeit, dass sie bis heute nicht gelöst sind.
Mal habe ich mich am AVR halbtot programmiert.
Bis ich gemerkt habe, dass ich den Speicherbereich begrenzt hatte.
Obwohl der eigentlich doppelt so groß ist.
Ralph S. schrieb:> ich sag ja: dummer Fehler, ich hatte nicht mehr im Kopf, dass die 1> 16-Bit breit ist.>> Witzigerweise hatte der SDCC das "richtig" gemacht gehabt wenn die bei>> 1 << nr>> nr 32-Bit groß ist.
1 ist vom Typ int. Dessen Größe liegt bei mindestens 16 Bit, darf aber
je nach Compiler auch beliebig größer sein.
> Sollte ich noch einmal in die Verlegenheit kommen, 32 Bit shiften zu> müssen, bekommt die 1 immer auch ul mit, egal auf welchem Compiler.
Damit machst du es zu einem unsigned long. Der ist mindesten 32 Bit
breit, darf aber auch beliebig größer sein. Auf einem 64-Bit-Linux ist
er z.B. 64 Bit breit. Es stört aber in der Regel nicht, wenn es größer
als nötig ist.
Gestern ist mir der Maischetank übergelaufen (Höllen Sauerei), dann das
Rad vom Tresterwagen raus geflogen, dann der Riegel von der Keltertür
weggeflogen, dann die Kelter auf Störung gegangen wegen defektem
Druckschalter, dann das Getriebe von der Maischeaustragung aus dem
Maischetank verreckt.
Es gibt Tage, da läufts einfach ...
Gerade letztens: nur mal schnell was zusammen hacken am Uni PC, misst
nur die Arduino IDE. Dachte: Naja dafür wird gehen.
Habe dann irgendwo ein if(xxx=5) statt if(xxx==t) drin gehabt.
Erst habe ich das gar nicht gemerkt weil es im Standardfall auch so
funktioniert hat.
Es gab keine Warnung obwohl in den Einstellungen alles auf ausführlicher
Output stand...
Da hab eich ewig dran gesucht.
Nie wieder diese IDE...
LG
Scyte
Scyte R. schrieb:> dann irgendwo ein if(xxx=5) statt if(xxx==t)
Standardfehler (passiert mir immer dann, wenn ich zwischen den Sprachen
switche... bspw. von Delphi nach C++).
Scyte R. schrieb:> Nie wieder diese IDE...
Ich mag die Arduino-IDE auch nicht, aber ausnahmsweiße war sie da mal
nicht dran schuld
Ralph S. schrieb:> Ich mag die Arduino-IDE auch nicht, aber ausnahmsweiße war sie da mal> nicht dran schuld
Doch, denn vernünftige IDEs zeigen hier die Compiler-Warnung an.
Und "ausnahmsweiße"? Sprichst du das auch so aus? Also so wie "Eine
weiße Wand", "ausnahmsweiße"? Nicht wie bei "Die Art und Weise",
"ausnahmsweise"?
Ralph S. schrieb:> Wein gut P. ( wein bauer) schrieb: ...> soll das heißen, jetzt gibts kein Bier mehr ?
Bier ist da wohl das einzige, was es jetzt noch gibt. Prosit! ;-)
Dr. Sommer schrieb:> Doch, denn vernünftige IDEs zeigen hier die Compiler-Warnung an.
Immerhin kann man die Arduino IDE dazu auch überreden, in den
Einstellungen Compiler Warnungen auf 'alle' einstellen. Das ist
dummerweiße nicht die Voreinstellung :)
Exakt dieses Prinzip hat sich über viele Jahrhunderte bewährt. Heute
sogar noch am Telefon weiter ausgebaut; sage da einmal "Ja", und du hast
ein teures Abo! Angeblich. Zumindest wollen sie nur dein Bestes, sprich
dein Geld.
Meine OLED-Library hat mich letztens locker zwei-drei Stunden Zeit
gekostet...weil ich statt eines SSD1306-Displays ein SH1106-Display
angeschlossen hatte. Das war so ein dummer Fehler, da werde ich mich
noch Monate drüber ärgern.
Ralph S. schrieb:> Weingut P. schrieb:>> dann das Getriebe von der Maischeaustragung aus dem>> Maischetank verreckt.>> soll das heißen, jetzt gibts kein Bier mehr ?
Siehe: Anmeldename != Braumeister
Anmeldename == Weingut
Produkt Weingut != Bier
Produkt Weingut == Wein
;) Kulturbanause
Zum "if (x=5)", warum sollte da der Compiler warnen? Die Abfrage lautet
doch letztlich "wenn zuweisung x=5 möglich dann weise zu und führe den
Zweig aus und ist nach meinem Kenntnisstand regulär. In PHP nutze ich
sowas öfters.
Driton schrieb:> Ich habe vor einigen jahren wohl zur falschen zeit ja gesagt. Nun> kostet> sie mich jeden tag viel zeit...
Warts nur ab wenn die Childprozesse starten, dann geht die CPU-Last auf
unbestimmte Zeit auf Anschlag
Weingut P. schrieb:> Zum "if (x=5)", warum sollte da der Compiler warnen?
Weil die Compiler-Bauer solche Standard-Fehler(tm) kennen und dafür
Warnungen eingebaut haben. Bei
1
intmain(){
2
inta;
3
if(a=42){
4
}
5
}
gibt der GCC (mit -Wall) aus:
1
test.cc: In function ‘int main()’:
2
test.cc:3:12: warning: suggest parentheses around assignment used as truth value [-Wparentheses]
3
if (a = 42) {
Zugegebenermaßen nicht die am Besten formulierte Meldung, aber wenn
denkt auf jeden Fall mal über diese Zeile nach.
Weingut P. schrieb:> Driton schrieb:>> Ich habe vor einigen jahren wohl zur falschen zeit ja gesagt. Nun>> kostet>> sie mich jeden tag viel zeit...>> Warts nur ab wenn die Childprozesse starten, dann geht die CPU-Last auf> unbestimmte Zeit auf Anschlag
Man muss vor allem dann vorsichtig sein, dass die Brown-Out Detection
nicht zu früh anspringt, wenn der Schlaf-Supply gefährlich einbricht.
Weingut P. schrieb:> Zum "if (x=5)", warum sollte da der Compiler warnen?
der gcc ist da mittlerweile sehr vorrausschauend und das ist gut so. Bei
der Zuweisung im if meckert er:
1
warning: suggest parentheses around assignment used as truth value [-Wparentheses]
2
if (i=0)
wenn man soetwas machen möchte geht es also wenn man den Ausdruck
klammert:
1
if( (i=0) )
geht dann ohne Warnung durch. Mit einer Konstanten macht das natürlich
wenig
Sinn, eher mit einer Funktion: if ( i=func(xy) ). Aber das würde ich
defensiver in zwei Zeilen schreiben.
Früher beim Umstieg von Pascal bin ich da oft drauf reingefallen.
Ich habe es mir angewöhnt*, bei Vergleichen in C den Non-L-Value nach
links zu schreiben, soll heißen:
1
if(42==answer)...
dann knallt es, sobald ich versehentlich = statt korrekt == schreibe.
* zu Zeiten von KR-C, da haben Compiler alles geschluckt, gemäß der
Annahme: wenn das so da steht, dann hat sich wer wohl was dabei gedacht
:(
Der Sensor (hatte meherere verschiedene gekauft, erste Tests damit
gemacht) wird aber heiss, wieso lässt der sich nicht ansprechen, stimmt
doch alles. Tja dann war halt doch + und - vertauscht.
Keine gescheite Lampe vorhanden, im Halbdunkel schnell was verkabelt.
ESP deepsleep geht mal wieder nicht. Warum nur, weil man beim verbinden
von RESET und D0 eben einen Pin daneben gesteckt hat, schlecht lesbar
weil zu dunkel + Parallaxe. Oder statt VCC erwischt man nen unbelegten
Pin daneben und nix tut sich. "Wasn jetzt los?"
Zwei Versionen einer lib im Suchpfad, wird nat. die falsche eingebunden.
ODer man hatte ne alte erste Mockupversion included nach Wochen mal
wieder dran weitergearbeitet inzwischen aber längst ne final fertig und
man fragt sich warum plötzlich die alten Fehler wieder auftauchen.
Oder lib für Architektur X eingebunden, statt für Architektur Y.
Das kompiliert im schlimmsten Fall auch noch nur im Betrieb tut es was
anderes.
...
So bekloppte Fehler macht man immer wieder mal inzw. weiss man aber
schnell was falsch läuft.
Thread beobachten
Seitenaufteilung abschalten