Mam zainstalowane STM32CubeIDE. Głównie programuję w assemblerze i z tego całego CubeIDE korzystam rzadko, właściwie tylko aby mieć łatwy podgląd do ustawień rejestrów i czasami aby mieć podgląd, czy jakimś ustawieniem częstotliwości nie przekraczam zaleceń.
W każdym razie dziś postanowiłem powalczyć z ustawieniami sterownika LCD-TFT w układzie STM32H750VBT6 opartego o LTDC.
Zawsze korzystałem w tym celu z załączonego pliku data i w zasadzie nigdy mnie nie zawiódł. Aż do dzisiaj, a właściwie zastanawiam się, co jest nie tak.
Otóż wybrałem sobie w STM32CubeIDE mój układ, czyli STM32H750VBT6, i o dziwo w ustawieniach LTDC mam dostępne tylko 2 tryby wyświetlania, tj. RGB666 i RGB565,
podczas gdy we wszystkich dokumentacjach, jakie udało mi się znaleźć na stronie ST, jest tych trybów 8.
Od razu przyznam, że nigdzie nie udało mi się znaleźć żadnego dokumentu dotyczącego bezpośrednio układu STM32H750VBT6, jedyne, co znalazłem na ich stronie, to ogólne dokumenty opisu STM32H750 Value line czy STM32H750VB.
Zastanawiam się, czy problem dotyczy środowiska IDE i ono w jakiś sposób ogranicza możliwości tego układu, czy po prostu nie umiem znaleźć na ich stronie właściwego dokumentu.
W każdym razie zamierzam sprawdzić w asemblerze, czy dodatkowe tryby da się uruchomić na danym układzie.
Załączniki:
rm0433-stm32h742-stm32h743753-and-stm32h750-value-line-advanced-arm-based-32-bit-mcus-stmicroelectronics-en.pdf(38.83 MB)
Musisz być zalogowany, aby pobrać ten załącznik.
an5312-migration-from-revy-to-revv-for-stm32h743753-and-stm32h750-value-line-microcontrollers-stmicroelectronics.pdf(334.43 KB)
Musisz być zalogowany, aby pobrać ten załącznik.
an4861-introduction-to-lcdtft-display-controller-ltdc-on-stm32-mcus-stmicroelectronics.pdf(4.02 MB)
Musisz być zalogowany, aby pobrać ten załącznik.
Otóż wybrałem sobie w STM32CubeIDE mój układ, czyli STM32H750VBT6, i o dziwo w ustawieniach LTDC mam dostępne tylko 2 tryby wyświetlania, tj. RGB666 i RGB565,
No bo te 8 to nie jest jak wyświetlacz jest podłaczony (a raczej jak odbiera dane na tej magistrali równoległej) tylko jak dane są przechowywane w buforze Widziełeś kiedyś wyświeltacze "L8 (8-bit luminance or CLUT)"
W buforze przechowujesz dane w różnych warstwach w tych właśnie 8 formatach a to peryferium je potrafi łaczyć, przkształcać etc i na koniec wypluć do wyświtlacza w tych właśnie 2 formatach fizycznych.
Oczywiście, aby skorzystać z tych dobrodziejstw, musisz mieć odpowiednio dużo pamięci (co w praktyce oznacza, że musisz mieć pamięć zewnętrzną).
Są oczywiście takie MCU ST, które mają taką pamięć wbudowaną - np seria U5 albo N6(4.2MB)
Dodano po 1 [godziny] 1 [minuty]:
gregor124 napisał:
Od razu przyznam, że nigdzie nie udało mi się znaleźć żadnego dokumentu dotyczącego bezpośrednio układu STM32H750VBT6
Nie jest potrzebny, bo wszystko jest RM, a róznice są zaznaczone.
gregor124 napisał:
Zastanawiam się, czy problem dotyczy środowiska IDE i ono w jakiś sposób ogranicza możliwości tego układu, czy po prostu nie umiem znaleźć na ich stronie właściwego dokumentu.
Raczej nie umiesz czytać ze zrozumieniem albo raczej całkowicie nie rozumiesz, o co w tym wszystkim chodzi.
gregor124 napisał:
W każdym razie zamierzam sprawdzić w asemblerze, czy dodatkowe tryby da się uruchomić na danym układzie.
Oh wiara we wszechmocny asembler ROTFL, Najpierw zrozum jak działa układ, a potem dopiero programuj w asemblerze (co samo w sobie jest nonsensem).
Dobra, chyba się rozjaśniło.
Wygląda, że "display Type" dotyczy fizycznego interfejsu, specjalnie ograniczonego w tym IDE, co wyjaśnię później.
Te tryby, o które pytałem, to tak naprawdę różne sposoby reprezentacji danych w pamięci RAM, które w układzie są tłumaczone na interfejs 4x8 bitów.
Przy rozdzielczości 320x200 właściwie każdy tryb bez problemu zmieści się w pamięci dostępnej w układzie.
A teraz trochę cytatów z załączonej dokumentacji:
"The LTDC can output data according to the following parallel formats: RGB565, RGB666, and RGB888.
So, 16-bit RGB565, 18-bit RGB666 or 24-bit RGB888 display can be connected."
Z kolei data sheet STW32h750VB.
"The LCD-TFT display controller provides a 24-bit parallel digital RGB (Red, Green, Blue)
and delivers all signals to interface directly to a broad range of LCD and TFT panels up to
XGA (1024x768) resolution with the following features"
W każdym razie chyba znalazłem to, czego potrzebuję.
Wygląda, że w każdym układzie z tej serii fizyczny interfejs zewnętrzny składa się z 24 bitów po 8 dla każdego z 3 kolorów. RGB.
Ale ze względu na ograniczenia w ilości wyprowadzeń nie wszystkie bity są wyprowadzone.
Okazuje się jednak, że w przypadku mniejszej ilości wyprowadzeń przynajmniej teoretycznie mogę w assemblerze do jednego wyprowadzenia podłączyć jeden z kilku bitów koloru.
Co ciekawe, wygląda, że można używać mniej bitów niż jest w interfejsie, a nieużywane mogą być zastosowane w innym celu.
A jeszcze ciekawiej, że wygląda, że mogę przynajmniej w kodzie maszynowym wyprowadzić więcej bitów dla danego koloru.
Np. w trybie RGB666 normalnie dostępne są bity R7..R1, G7..G2, B7..B2.
Ale okazuje się, że bity G1 są dostępne na pinie 34 w obudowie LQFP100, G0 (35), B1 (69). B0 i R0 nie są widocznie dostępne w tej obudowie.
Trzeba będzie się z tym pobawić w wolnej chwili..
Czyli wygląda, że wprowadzono ograniczenia z powodu niedostępności wszystkich bitów w danej obudowie, choć wygląda, że i tak jest możliwość uzyskania większej liczby kolorów, choć to wymaga stworzenia swojego formatu.
W niektórych obudowach na pinie PG10 są dostępne zamiennie bity kolorów B2 i G3, czyli teoretycznie można by ukryć jakiś obrazek na tych bitach i odpowiednio maskując wyprowadzenia móc podejrzeć taki ukryty obraz w obrazie .
A jeszcze ciekawiej, że wygląda, że mogę przynajmniej w kodzie maszynowym wyprowadzić więcej bitów dla danego koloru.
Np. w trybie RGB666 normalnie dostępne są bity R7..R1, G7..G2, B7..B2.
To wyraźnie błąd w logice tej paczki dla CubeMX. Po prostu sobie ustaw te bity jako alternate z odpowiednim numerkiem, aby to działało. Ważne jest to, co mówi dokumentacja. Tak że spoko możesz używać tych 2 bitów. Jedyne, co musisz zrobić, to je ustawić na odpowiedni alternate. Nie jest to szczególna właściwość asemblera.
Podejrzewam, że ci, co to pisali, zasugerowali się tymi standardowymi nazwami, raczej istotnymi tylko przy komunikacji szeregowej z wyświetlaczem.
Sam LTDC nie ma żadnych ustawień RGB565 ani RGB666 - to tylko dla Cube'a do ustawienia pinów. On sam zawsze generuje 888, tylko parę pinów zabrakło w tej obudowie, a piszący zasugerował się tymi nazwami.
Z racjonalnego punktu widzenia - może by to miało jakiekolwiek znaczenie, jakbyś miał jakiś super wyświetlacz. Chińskie i tak tyle kolorów nie wyświetlą i 565 jest nawet za dużo dla nich.
Dodano po 15 [minuty]:
gregor124 napisał:
Przy rozdzielczości 320x200 właściwie każdy tryb bez problemu zmieści się w pamięci dostępnej w układzie.
Niby tak, ale jak byś chciał korzystać z tego, co to oferuje, potrzebujesz dużo więcej pamięci niż 320x240x3.
Generalnie jest to potężne narzędzie i można zrobić piękne rzeczy.
Posty użytkowników poprzedzające pytanie: ``` Data: 12/05/2026 Treść: To wyraźnie błąd w logice tej paczki dla CubeMX. Po prostu sobie ustaw te b...
Krótko
Moim zdaniem w tej dyskusji mieszają się trzy różne pojęcia:
1. format piksela w buforze RAM: ARGB8888, RGB888, RGB565, ARGB1555, ARGB4444, L8, AL44, AL88; 2. fizyczny interfejs równoległy LTDC: sygnały
LCD_R[7:0]
,
LCD_G[7:0]
,
LCD_B[7:0]
plus
CLK
,
DE
,
HSYNC
,
VSYNC
; 3. uproszczony wybór w CubeMX/CubeIDE „Display Type”: głównie pomocnik do ustawienia typowego zestawu pinów dla RGB565/RGB666/RGB888.
W STM32H750VBT6 w LQFP100 nie traktowałbym tego jako „magii asemblera”. Jeżeli dany sygnał LTDC jest wyprowadzony na pin i widnieje w tabeli alternate functions, to można go ustawić ręcznie przez
GPIOx_MODER
i
GPIOx_AFRL/H
, niezależnie od tego, czy CubeMX przewidział wygodny wariant w GUI. ST w AN4861 wyraźnie rozdziela temat interfejsu do panelu od formatów warstw, a dla LTDC podaje do 24 linii danych RGB888 i typowe podłączenia RGB565/RGB666/RGB888. (st.com)
---
Najważniejsze sprostowanie: te „8 trybów” to nie „Display Type”
Lista:
-
ARGB8888
, -
RGB888
, -
RGB565
, -
ARGB1555
, -
ARGB4444
, -
L8
, -
AL44
, -
AL88
dotyczy formatu danych w framebufferze danej warstwy LTDC, a nie tego, ile fizycznych linii RGB wychodzi z obudowy. Dokumentacja ST mówi wprost, że format piksela jest parametrem danych zapisanych w framebufferze warstwy, a każda warstwa może mieć niezależnie ustawiony jeden z ośmiu formatów wejściowych. Po odczycie z pamięci LTDC wykonuje konwersję do wewnętrznego formatu ARGB8888. (st.com)
Natomiast „Display Type” w CubeMX/CubeIDE dotyczy bardziej zewnętrznego połączenia do panelu, czyli tego, które linie
LCD_Rx/Gx/Bx
mają zostać zajęte jako GPIO alternate function. ST w AN4861 zaleca przy doborze obudowy sprawdzać dostępność RGB565/RGB666/RGB888 oraz liczbę GPIO, a jako proste narzędzie wskazuje właśnie zakładkę pinoutu CubeMX. (st.com)
---
Co faktycznie generuje LTDC?
Wewnętrznie LTDC pracuje na pełnych składowych kolorów. Z punktu widzenia wyjścia masz sygnały:
Kod: text
Zaloguj się, aby zobaczyć kod
ST opisuje, że interfejs sprzętowy LTDC daje osiem bitów na każdą składową koloru i nadaje się bezpośrednio do paneli RGB888. Dla paneli o mniejszej głębi, czyli RGB666/RGB565, należy podłączać najstarsze bity magistrali LTDC do wejść panelu. (st.com)
Czyli przykładowo:
Panel
Zalecane linie LTDC
RGB565
R7..R3
,
G7..G2
,
B7..B3
RGB666
R7..R2
,
G7..G2
,
B7..B2
RGB888
R7..R0
,
G7..G0
,
B7..B0
To ważne: jeżeli podłączysz młodsze bity zamiast starszych, obraz oczywiście może się pojawić, ale rozkład jasności/kodowanie kolorów będzie nienaturalne, chyba że świadomie przygotujesz dane w framebufferze pod taki nietypowy układ.
---
STM32H750VBT6 LQFP100: CubeMX upraszcza, ale datasheet jest ważniejszy
Dla STM32H750xB aktualny datasheet ST, rewizja 8 ze stycznia 2026, pokazuje, że układ ma LCD-TFT controller, 1 MB RAM i występuje m.in. w LQFP100. (st.com)
I tutaj dochodzimy do sedna: CubeMX może nie udostępniać w GUI wszystkich niestandardowych kombinacji linii LTDC, ale to nie oznacza, że sygnał nie istnieje. Ostatecznym źródłem prawdy jest tabela alternate functions w datasheecie.
I tu trzeba uważać: „alternatywnie” oznacza alternatywnie, nie jednocześnie. Jeżeli ustawisz
PB0
jako
LCD_G1
, to nie może on w tym samym czasie być
LCD_R3
. Jeżeli masz dostępne
G1
na
PE6
, lepiej użyć
PE6
, a nie zabierać sobie
R3
z
PB0
.
---
Czy da się ręcznie wyprowadzić „więcej niż CubeMX pokazuje”?
Tak, jeżeli spełnione są trzy warunki:
1. dany sygnał
LCD_Rx/Gx/Bx
istnieje w tabeli alternate functions dla konkretnego pinu; 2. ten pin jest fizycznie dostępny w danej obudowie; 3. nie koliduje z innym potrzebnym sygnałem.
Nie ma tu znaczenia, czy piszesz w C, C++ czy asemblerze. Asembler nie omija ograniczeń krzemu ani obudowy. On tylko pozwala bezpośrednio zapisać rejestry. To samo można zrobić w C przez CMSIS.
Schematycznie konfiguracja sprowadza się do:
Kod: text
Zaloguj się, aby zobaczyć kod
Numer
AFx
trzeba brać z tabeli alternate functions dla konkretnego pinu. Nie należy zakładać, że wszystkie sygnały LCD są pod tym samym numerem AF, bo w STM32H7 część linii LCD występuje na różnych pinach i pod różnymi funkcjami alternatywnymi.
---
RGB565/RGB666 w CubeMX a rzeczywiste linie
Jeżeli w CubeMX wybierzesz
RGB565
, narzędzie zwykle ustawi zestaw typowy dla panelu 16-bitowego:
Kod: text
Zaloguj się, aby zobaczyć kod
Jeżeli wybierzesz
RGB666
, ustawi typowy zestaw:
Kod: text
Zaloguj się, aby zobaczyć kod
Ale sam blok LTDC nadal generuje pełne wewnętrzne dane kolorów. Piny, których nie skonfigurujesz jako LTDC, mogą być normalnymi GPIO albo peryferiami, o ile nie są potrzebne do czegoś innego.
Dlatego twierdzenie: „LTDC nie ma osobnego magicznego trybu RGB565/RGB666, tylko Cube ustawia piny” jest w praktycznym sensie dość trafne, choć trzeba doprecyzować, że format RGB565 istnieje jako format danych warstwy framebuffer, a
Display Type RGB565/RGB666
w GUI to inna rzecz.
---
Pomysł z „ukrytym obrazkiem” w bitach
Teoretycznie: tak, można potraktować młodsze bity koloru jako dodatkowy kanał informacyjny. Przykładowo, przy normalnym oglądaniu panelu 18-bitowego młodsze bity, których panel nie odbiera, nie będą widoczne, ale w framebufferze i na wewnętrznej magistrali LTDC mogą istnieć.
Praktycznie są ograniczenia:
- jeżeli pin nie jest skonfigurowany jako LTDC, sygnał nie wyjdzie na zewnątrz; - jeżeli jeden pin ma dwie funkcje LCD, np.
PB0 = LCD_R3
albo
LCD_G1
, nie uzyskasz obu naraz; - przełączanie funkcji AF w trakcie aktywnego wyświetlania spowoduje zakłócenia; - jeżeli chcesz „podejrzeć” młodsze bity zewnętrznym układem, musisz mieć te bity fizycznie wyprowadzone i nieużywane przez panel.
Jako eksperyment laboratoryjny ciekawy pomysł. Jako projekt produkcyjny raczej nie warto, chyba że bardzo świadomie projektujesz własny interfejs diagnostyczny albo niestandardowy tor wizyjny.
---
Pamięć i sens użycia formatów 24/32 bpp
Dla małych rozdzielczości STM32H750 daje radę, ale trzeba liczyć pamięć:
Rozdzielczość
RGB565
RGB888
ARGB8888
---:
---:
---:
---:
320×200
128 kB
192 kB
256 kB
320×240
153,6 kB
230,4 kB
307,2 kB
Podwójny bufor mnoży to razy dwa. Przy 320×240 w RGB565 masz około 307 kB dla double buffering, więc jest to realne. W ARGB8888 dwa bufory to już około 614 kB. Formalnie STM32H750 ma 1 MB RAM, ale nie każda pamięć jest równie wygodna dla LTDC, cache i DMA2D. Trzeba pilnować banku RAM, MPU/cache oraz ewentualnego czyszczenia D-cache przy zapisie framebufferów przez CPU. ST w AN4861 również zwraca uwagę na ograniczenia przepustowości, cache i synchronizację z LTDC/DMA2D. (st.com)
---
Moja konkluzja
Nie nazwałbym tego jednoznacznie „błędem LTDC” ani „ograniczeniem asemblera”. Najtrafniej:
CubeMX/CubeIDE pokazuje standardowe, bezpieczne konfiguracje fizycznego interfejsu dla danej obudowy, natomiast datasheet pozwala ręcznie skonfigurować poszczególne linie LTDC, także takie, których GUI nie używa w typowym trybie RGB565/RGB666.
Czyli:
- 8 formatów z dokumentacji to formaty framebufferów warstw; -
Display Type
w CubeMX to wybór typowej szerokości fizycznego RGB; - LTDC generuje zestaw sygnałów RGB, a o tym, co wyjdzie na zewnątrz, decydują piny i ich AF; - w LQFP100 można ręcznie wykorzystać część dodatkowych bitów, ale trzeba uważać na konflikty funkcji alternatywnych; - ostatecznie decyduje datasheet, nie lista w GUI CubeMX.
Jeżeli celem jest normalny wyświetlacz 320×200 albo 320×240, najrozsądniej zacząć od RGB565 lub RGB666, uruchomić stabilnie timing, FIFO i cache, a dopiero potem bawić się dodatkowymi LSB kolorów.
Możesz mnie wywołać w każdym temacie pisząc @ElektrodaBot. Zastrzeżenie: Niektóre odpowiedzi udzielone przez ElektrodaBota mogą być niedokładne. Elektroda nie ponosi odpowiedzialności za dokładność, rzetelność ani kompletność prezentowanych informacji. Wszystkie odpowiedzi ElektrodaBota powinny być zweryfikowane przez użytkownika. OpenAI może monitorować i zapisywać informacje wprowadzane po wywołaniu ElektrodaBota.
Na początek zacznijmy od tego, że w tym układzie nie ma 1 MB RAM i do 1 MB całkiem sporo brakuje .
Właściwie to nawet nie ma tyle pamięci dostępnej dla użytkownika po dodaniu 128 kB FLASH .
Chodzi o to, że tak naprawdę to tryby RGB565 czy RGB666 tak naprawdę są wirtualne i tylko dezorientują użytkownika, bo równie dobrze mogę sobie stworzyć tryb RGB101, RGB111, RGB222.... I też będą działać. Oczywiście, że można sobie stworzyć program pozwalający na skonfigurowanie dowolnego z nich, nie tylko w Assemblerze (ja np. zrobiłem sobie do tego makra i w Assemblerze i w BASIC ), ale to właśnie assembler zmusza do dobrego zrozumienia zasady działania układu.
Ba, mogę sobie napisać procedurę, która będzie mi tryby zmieniać niejako w locie.
Tak naprawdę interfejs jest zawsze jeden i ten sam, a użytkownik może go sobie niemal dowolnie kształtować.
W STM32CubeIDE dla układu STM32H750VBT6 w konfiguracji LTDC dostępne są tylko dwa tryby kolorów: RGB666 i RGB565, mimo że dokumentacja ST opisuje osiem trybów wyświetlania. Problem dotyczy ograniczeń widocznych w pliku konfiguracyjnym/data oraz braku jednoznacznej dokumentacji dla konkretnego wariantu STM32H750VBT6, co utrudnia weryfikację poprawnych ustawień sterownika LCD-TFT i zgodności parametrów częstotliwości. Podsumowanie AI na podstawie dyskusji. Może zawierać błędy.
Widziełeś kiedyś wyświeltacze "L8 (8-bit luminance or CLUT)"
.
