Hallo zusammen, ich habe mir das Projekt von https://github.com/w1ne/u8g2-ssd1306-CubeMX als Grundlage genommen um mir etwas auf einem OLED (SSD1306) mit der u8g2 Lib etwas auszugeben. Zur Programmierung nutze ich Stm32CubeIDE und für die Konfiguration eben STm32CubeMX. Es funktioniert eigentlich alles, wenn das kleine Brettchen mit 8MHz und als Clock Source HSI gewählt ist. Stelle ich HCLK um auf 72MHz und somit auf HSE PLLCLK, dann spielt sich die Ausgabe auf dem Display ca im ersten 5tel ab und der Rest ist entweder Schwarz oder Bildrauschen. I2C Clock ist weiterhin auf 400KHz, es wurde nichts anderes geändert. Ich war dann irgendwann hierauf gestossen: https://electronics.stackexchange.com/questions/467043/increasing-system-clock-frequency-on-stm32f303-drops-i2c-clock-proportionately Ich bin mir nicht sicher, ob es exakt das gleiche Problem ist, aber wenn ich bei HCLK die 8MHz einstelle und I2C von 400KHZ abwärts reduziere bekomme ich das gleiche Fehlerbild, wie wenn ich HCLK von 8MHz auf 72MHz erhöhe. Kann mir jemand erklären wie das zusammenhängt? Nebenbei habe ich im Clock Tree von CubeMX nach Sysclk keine Abzweigung für I2C. Liegt das am verwendeten Chip und dessen Konfigurationsmöglichkeit? Edit: ich glaube ich habe nicht das gleiche Problem wie der Kollege auf Stackexchange. Ich habe kein Osziloskop um die Externe Quelle zu prüfen, aber ich habe wie auf SE beschrieben eine NOP Schleife erstellt und eine LED blinken lassen. Bei 72MHz blinkt sie deutlich schneller als bei 8MHz, also dürfte es kein Problem mit dem externen Taktgeber geben.
:
Bearbeitet durch User
Tuck I. schrieb: > Ich bin mir nicht sicher, ob es exakt das gleiche Problem ist, aber wenn > ich bei HCLK die 8MHz einstelle und I2C von 400KHZ abwärts reduziere > bekomme ich das gleiche Fehlerbild, wie wenn ich HCLK von 8MHz auf 72MHz > erhöhe. Wie sieht denn das Fehlerbild aus? Wie sehen die I²C Signale aus? Was genau heißt "von 400KHZ abwärts reduziere"? Wie sieht dein Schaltplan aus (Stromversorgung, Pull-Ups, was hängt sonst noch so dran)? Die Informationen zur Taktverteilung sind im Reference Manual des Mikrocontrollers. Mit CubeMX und HAL sollte man sich erst befassen, nachdem man sich mit dem Mikrocontroller vertraut gemacht hat. Denn die Doku von CubeMX und HAL erklären nicht, wie der Mikrocontroller funktioniert. Die I²C Schnittstelle des STM32F103 hat ein paar eklige Bugs. Es würde mich nicht wundern, wenn die bei der HAL vergessen habe, diese bugs zu berücksichtigen. Beim HAL Code für den STM32F103 bin ich schon mehrfach auf Fehler gestoßen, die früher mal funktioniert hatten.
Angehängte Dateien:
-
nok.JPG
51 KB -
ok.JPG
120 KB -
clktree_8mhz.JPG
73 KB -
clktree_72mhz.JPG
73 KB -
clktree_8mhz.JPG
72 KB
Stefan ⛄ F. schrieb: > Wie sieht denn das Fehlerbild aus? Fotos angehängt >Wie sehen die I²C Signale aus? Habe das Hello World mit Saleae Logic aufgezeichnet und exportiert. Bei hi2c1.Init.ClockSpeed = 400000; habe ich mit HCLK 72MHz ein SCL mit genau 400KHz. Ändere ich HCLK auf 8MHz zeigt mir der Logic Analyser SCL mit 333KHZ. > Was genau heißt "von 400KHZ abwärts reduziere"? Das war etwas mißverständlich ausgdrückt. Wenn ich HCLK auf 8MHz belasse und den I2C ClockSpeed auf sagen wir auf 200KHZ reduziere, dann sieht die Ausgabe genauso aus, wie wenn ich HCLK auf 72MHz setze und I2C Clockspeed auf 400KHz bleibt. > Wie sieht dein Schaltplan aus (Stromversorgung, Pull-Ups, was hängt sonst noch so dran)? Auf dem Steckbrett: Blue Pill Board direkt mit dem SSD1306 verbunden, sonst nur noch der STLink von einem Nucleo Board. Stromversorgung über STLink oder Steckbrettadapter (3,3V). Kein Unterschied im Fehlerbild, wenn ich die Stromquelle wechsle. Das Display hat interne 10K Pull-Ups an SCL und SDA. > Die Informationen zur Taktverteilung sind im Reference Manual des > Mikrocontrollers. Mit CubeMX und HAL sollte man sich erst befassen, > nachdem man sich mit dem Mikrocontroller vertraut gemacht hat. Denn > die Doku von CubeMX und HAL erklären nicht, wie der Mikrocontroller > funktioniert. Das stimmt, ich wollte blauäugig mit dem Kopf durch die Wand. > Die I²C Schnittstelle des STM32F103 hat ein paar eklige Bugs. Es würde > mich nicht wundern, wenn die bei der HAL vergessen habe, diese bugs zu > berücksichtigen. Beim HAL Code für den STM32F103 bin ich schon mehrfach > auf Fehler gestoßen, die früher mal funktioniert hatten. Früher ging wohl auch das Timing Register mit hi2c1.Init.Timing setzen, was in meinem Fall in der aktuellen HAL Bibliothek nicht existiert, die ich hier verwende. Evtl sollte ich das mal ohne HAL machen und die Timings setzen wie sie der Timing Calculator von ST vorgibt. Edit: ich kann die Bilder nicht editieren... das erste Bild für den Clock tree mit 8MHz ist falsch, das zweite ist das richtig Bild (HSI statt PLLCLK).
:
Bearbeitet durch User
Tuck I. schrieb: > Das Display hat interne 10K Pull-Ups an SCL und SDA. Zu hochohmig, ich schalte 2,2 kΩ parallel dazu, dann funktionieren sie. > Früher ging wohl auch das Timing Register mit hi2c1.Init.Timing setzen Nicht beim STM32F103. Du meinst vielleicht den STM32F303, da gibt es ein Timing Register. Dessen I²C Peripherie ist eine völlig andere. > Evtl sollte ich das mal ohne HAL machen und die Timings setzen wie sie > der Timing Calculator von ST vorgibt. Fall du kein DMA brauchst kannst du von meinem Beispiel abgucken http://stefanfrings.de/stm32/stm32f1.html#i2c
Kleine Korrektur: die Pull-Ups haben 4,7K, also keine 10K. Die 10K habe ich vom falschen Display. Ich kann die Werte ohne Lupe nicht erkennen. Das vermeindlich Baugleiche von Sunfounder hat 10K, meins ist von SKU(?) https://wiki.52pi.com/index.php/0.96_Inch_OLED_Module_SKU:_S-0005 Handy mit Lupenfunktion hat dann geholfen... Das Timerregister war von meinem Nucleo mit STM32F446RE. Alles so verwirrend diese Woche.
Vielleicht versuchst du das erstmal manuell statt dich mit diesen Case Tools herum zu schlagen. Also per Hand. Das Display ist echt einfach, man shreibt einfach die gfx Arduiono Adafruit Library etwas um auf STM. Hier ist meine I2C Lib für M3 Ach ja, diese Displays kannste nach einem halben Jahr in die Tonne hauen, wenn sie immer an sind. Sie verdunkeln sich immer weiter und das Bild wird irgendwann ziemlich dunkel und scheckig.
Hallo Zusammen Laut Datenblatt sollte der SSD1306 zwar 400KHz hinbekommen, aber ein paar Hindernisse gibt es schon: - Die Flexleitung hat meist einen Widerstand von mehreren 100 Ohm - Auf der PCB des OLEDs sind oft auch Widerstände um beispielsweise 5V TTL zu ermöglichen - Steckboards sind natürlich auch nicht besonders zuverlässig. Aus meiner Sicht ist es gut denkbar, dass das OLED mit 333 kHz läuft aber mit exakt 400 kHz ans Limit kommt. Die meisten Probleme hatte ich übrigens mit dem Reset solcher Display-Module. Bevor man anfängt Daten zum OLED zu senden (u8g2 send buffer oder next page), sollte man am besten 1000 ms vor und nach dem Init des Displays warten. Wenn man den HAL für u8g2 richtig umgesetzt hat, sollte das zwar kein Problem sein, aber vielleicht hat hier der Sprung von 8 auf 72 MHz einen negativen Einfluss. Grüße, Oliver
Thread beobachten
Seitenaufteilung abschaltenBitte melde dich an um einen Beitrag zu schreiben. Anmeldung ist kostenlos und dauert nur eine Minute.
Bestehender Account
Schon ein Account bei Google/GoogleMail? Keine Anmeldung erforderlich!
Mit Google-Account einloggen
Mit Google-Account einloggen
Noch kein Account? Hier anmelden.