Hallo,
habe gerade CubeMX auf Version 5.0.1 geupdatet, um etl. mein CAN Bus
Problem zu beheben. Dafür habe ich ein anderes Problem.
Am Mikrocontroller hängen 2 identische Displays an I²C und die sollen
gelöscht werden. Hat mit CubeMX 4.21.0 super funktioniert. Jetzt zeigt
er mir bei der
"b" for Schleife ein "containing loop"
und bei
"SSD1306Command[1] = SSD1306Zeile[b]; //Y" sagt er "iteration 8u invokes
undefined behavior [-Waggressive-loop-optimization]"
Ich verstehe überhauptnicht warum das plötzlich kommt, weil es rein gar
nichts mit CubeMX zu tun hat. Eclipse 4.6.3 und GCC habe ich nicht
upgedatet.
Außerdem warum geht es mit "a" und "i", aber nicht mit "b". Wenn ich bei
der betroffenen Zeile die Variable b gegen eine Zahl tausche geht es.
Komisch vorher hats mit "<8" immer nur 7 Zeilen angezeigt. Jetzt läuft
es so wie es eigentlich soll. Fragt mich trotzdem was das mit dem CubeMX
Update zu tun haben soll.
Was aber auch nicht passt ist, dass ich in der While Schleife vom
mainloop eine der beiden Zeilen drin stehen haben muss, sonst macht der
Controller nichts oder die Anzeige macht nur nichts:
1
HAL_Delay(1);
2
HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13);
Kommentiere ich beide Zeilen aus funktioniert es nicht mehr.
An dem Port hängt lediglich eine LED.
Wie ich schon einmal schrieb, hatte ich auch Probleme mit der
HAL_I2C_Master_Transmit Funktion.
Seit dem habe ich mir angewöhnt die Typen mit zu übergeben.
Also:
HAL_I2C_Master_Transmit(&hi2c1,SSD1306Adresse[i],SSD1306Command,2,100);
wird zu:
HAL_I2C_Master_Transmit(&hi2c1,(uint16_t)SSD1306Adresse[i],(uint8_t*)SSD
1306Command,2,100);
Seit dem gab es in keiner Situation mehr Probleme.
Sonst sehe ich da nur ein Timing Problem, das durch die zusätzlichen
Zeilen entschärft wird.
Vereinfacht habe ich meine SSD1306 Ansteuerung, in dem ich alles im RAM
bearbeite und dann in einem Rutsch per DMA zum SSD1306 sende.
Bei 400kHz gelingt das auch ohne Bildstörungen.
Mit Timing hat es nichts zu tun. Steht noch einiges mehr in der
mainloop.
Wenn ich eine Abfrage einrichte, dass die LED nach 5 Tagen eingeschalten
wird reicht das aus. Hauptsache es steht irgendwo in der mainloop, sonst
bleibt das Display schwarz.
Wenn ich die Zeilen wo das Display gelöscht wird auskommentiere, dann
bleibt der Display Inhalt von vorher. Demzufolge funktioniert die
Initialisierung des µC, aber irgendwo danach bleibt er hängen wenn der
GPIO Port nicht geschalten wird.
Das heißt der µC erwartet:
HAL_GPIO_TogglePin(GPIOC, GPIO_PIN_13);
oder
HAL_Delay(1);
irgendwo in der mainloop
Dabei ist es egal ob der Fall eintreten kann. Wenn ich den Timer vor
Ablauf der 5 Tage zurücksetze, kann der Fall nie eintreten, dass der
GPIO Port geschalten wird.
Auch egal ist welcher Port. Selbst nicht initialisierte Ports sind egal.
Off Topic:
Der Code ist aus der Initialisierung. Ich verwende dort kein DMA damit
ich keine Abfrage einbauen muss ob der DMA COntroller fertig ist,
sondern die Initialisierung schön der Reihe nach abläuft. Danach alles
mit DMA.
Bimbo. schrieb:> Ohne HAL wäre das nicht passiert.
Das ist leicht dahin gesagt, kann man kaum überprüfen.
Ich habe allerdings schon das Gefühlt, dass es ohne HAL zumindest nicht
schwieriger ist.
Meine I²C implementierung auf Basis des Referenzahndbuches und des
Errata funktionierte auf Anhieb tadellos. Gleiches gilt auch für fast
alle anderen Funktionen, die ich bisher nutzte.
Jedenfalls habe ich keine Lust, mich mit zusätzlichen 2000 Seiten Doku
herum zu schlagen und bei jeder neuen Version neue Bugs kennen zu
lernen. Da freunde ich mich lieber mit den Registern an.
