Konfiguration STMH755

[ndsdeveloper]

Hallo Rudolph,

vielen Dank erstmal für die tolle Library, die mir jedoch sehr geholfen hat EVE von NHD zum Laufen zu bekommen.
Ich benötige jedoch Unterstützung bei der Nutzung von Nucleo H755. Auf einem F469 läuft die Lib super und ich habe es sogar geschafft TouchGFX einzubinden. Leider ist der 469 doch etwas zu lahm. Aktuell ist die Idee auf H755 umzusteigen, aber ich scheitere bei der Konfig von dem Controller, denn der FTDI 813 will einfach nicht mit dem Nucleo kommunizieren. Ich habe nun hundert tausend Einstellungen ausprobiert, von kleinen Frequenzen, bis hin zum Maximum. Nur fehlt mir irgendwie bestimmt nur eine Kleinigkeit. Vielleicht kannst Du mir da weiter helfen. Aktuelle Einstellungen (vermutlich nicht ideal):

Die Initialisierung klappt nicht, HAL Funktionen lieferen ebenfalls 0 zurück und auch while (!LL_SPI_IsActiveFlag_RXWNE(EVE_SPI)) {} bleibt im Nirvana.

Ich freue mich auf den Support.

Vielen Dank im Voraus.

Mit den besten Grüßen
Alex

[RudolphRiedel]

Hallo,
mir ist gerade aufgefallen, dass mir Github eine Notification anzeigt und bin auf diesen Thread hier gestoßen.
Keine Ahnung, warum mir das durchgerutscht ist, normalerweise bekomme ich von Github eine EMail für neue Threads.

Zu STM32 kann ich nicht wirklich viel sagen da ich die Controller nicht aktiv verwende, es gibt praktisch keine die ich in einem Projekt wirklich einsetzen könnte.

Aber, dem Board hier habe ich nebenbei eine SPI Schnittstelle verpasst:
https://github.com/RudolphRiedel/USB_CAN-FD/tree/master/D5035-05_STM32G0B1/D5035-05-02
Um neben der eigentlichen Verwendung ein Display anschließen zu können, die Software dafür zu machen war dann auch Teil der Inbetriebnahme des Boards.
Das Projekt habe ich mit PlatformIO aufgesetzt, konfiguriert habe ich das aber in der STM32CubeIDE und habe mir auch den Source dafür generieren lassen.

Und in dem Zuge hatte ich den Fehler, dass ich zwar eine MX_GPIO_Init() und eine MX_SPI1_Init() erhalten habe,
aus dem SPI kam dann aber nichts raus.
Die Pins für den SPI wurden durch den erzeugten Code nämlich nicht konfiguriert.

Nach einigem Suchen habe ich dann das hier in die MX_SPI1_Init() eingebaut:
__HAL_RCC_SPI1_CLK_ENABLE();
__HAL_RCC_GPIOA_CLK_ENABLE();

GPIO_InitTypeDef GPIO_InitStruct = {0};

/* SPI1 GPIO Configuration: PA5 -> SPI1_SCK, PA6 -> SPI1_MISO, PA7 -> SPI1_MOSI */
GPIO_InitStruct.Pin = GPIO_PIN_5|GPIO_PIN_6|GPIO_PIN_7;
GPIO_InitStruct.Mode = GPIO_MODE_AF_PP;
GPIO_InitStruct.Pull = GPIO_NOPULL;
GPIO_InitStruct.Speed = GPIO_SPEED_FREQ_HIGH;
GPIO_InitStruct.Alternate = GPIO_AF0_SPI1;
HAL_GPIO_Init(GPIOA, &GPIO_InitStruct);

Es würde mich jetzt nicht wundern, wenn das auf dem H755 auch nicht richtig funktioniert.

[ndsdeveloper]

Hallo @RudolphRiedel ,

ich habe es inzwischen tatsächlich auch auf dem H755 zum Laufen bekommen, auch übers QUAD Spi. Das Problem war damals bei mir, dass ich SPI1 verwendet hatte. Habe es dann zufällig auf SPI6 (gleiche Pins) umgeschaltet und es fing an zu laufen. Jedenfalls aber mit QUAD Spi war die Performance bei einem 800x400 Display auch katastrophal. Laut dem OSZI dauert ein Frame 100-150ms (was schon verdammt lange ist) mit QSPI Modus und über 4 Lines. Gefühlt war es aber deutlich länger, da z. B. ein Page Wechsel ein extrem unschönes von oben nach unten Aufbau des Bildes erzeugt. Evtl. hab ja auch ich irgendwas falsch gemacht. Aber mit EVE 2/4 - direkt Flash STM32 (400Mhz) - SPI/QSPI ist eine gute Performance meinerseits nicht erreichbar gewesen. DMA über HAL, LL leider nicht getestet, hat eher eine viel schlechtere Performance gezeigt. Laut den Foren soll angeblich LL mit DMA viel schneller sein, aber nach wochenlangen rumtesten hatte ich irgendwann keine Lust mehr.

[RudolphRiedel]

Hat TouchGFX keinen Kachel-Modus oder so?
Man könnte den Bildschirm ja z.B. in 80x80 Pixel Bilder zerlegen und immer nur aktualisieren was sich auch ändert.
768000 Bytes zu übertragen dauert etwas, 12800 Bytes geht deutlich schneller.

Wobei es ja auch eine Adaptierung für LVGL gibt, macht auch wenig Sinn, also EVE als Framebuffer zu misbrauchen und alle Vorteile weg zu werfen, anstatt ein anderes Display zu werwenden.
Aber das soll unter LVGL schon benutzbar gewesen sein.