JLink GDB & Rust + VSCode + Docker + CMake + RTT + CubeMX + TouchGFX + Zewnętrzny FLASH

[Gieneq]

W ostatnim czasie pojawił się pomysł na opuszczenie STMCubeIDE i przerzucenie się na VS Code. Nie będę się zagłębiał dlaczego. Pomysł ten dał sposobność zapoznania się z czego składa się środowisko. Nie jestem tu ekspertem, nie jest to poradnik ale raczej okazja podzielenia się pewną wiedzą.

Tu MJPEG 800x480 lecący prosto z OctoSPI NOR FLASH. 

Projekt składa się z 2 części:

• Szablon projektu dla płytki STM32U5G9 DK2
• Loader zewnętrznych pamięci FLASH napisany w Ruście.

Szablon projektu po stornie Windowsa to:

• VS Code
• Docker Desktop
• JLink (Server, RTT Viewer)
• TouchGFXDesigner
• CubeMX

Szablon po stronie kontenera to:

• CMake
• testy jednostkowe GoogleTest po stornie hosta
• gdb-multiarch
• Netcat do komunikacji z serwerem JLink
• binutils do wycinania sekcji dla zewnętrznej pamięci.

Loader zewnętrznych pamięci to:

• Rust + Tokio + Clap - CLI do interakcji z subprocesem arm-none-eabi-gdb. Tokio daje asynchroniczność niezbędną do przechwytywania zdarzeń z STD out i err jednocześnie.
• wymagany arm-none-eabi-gdb i działający serwer JLink.

Celem szablonu było założenie projektu w Dokerze, a dokładniej w Dev Containerze, tak żeby projekt był przenośny, a za docelowe IDE wybrałem VS Code.

Szablon projektu bazuje na STMCubeMX ale nie korzysta z dodatku dla VS Code. Po zapoznaniu się z dodatkiem uznałem, że to słaby pomysł. Dodatek wymaga CubeCLT, a to kolejne narzędzie do pobrania ze strony ST. 

Za debugger wybrałem JLinka ponieważ działa dużo stabilniej od STLinka i Segger udostępnia pliki źródłowe do RTT (komunikacja z hostem podobna do UARTu, szybsza od multihostingu). Wewnątrz kontenera na pewno spotkamy się z problemem portu USB - nie jest on domyślnie dostępny, a próba wystawienia może skończyć się innymi problemy. Na szczęście JLink daje nam całkiem wygodny server debuggera. Wystarczy zmapować port dla kontenera i można pogadać z serwerem np Netcatem.

Do komunikacji przez RTT może służyć JLinkowy Viewer.

Szablon projektu przewiduje użycie TouchGFX z zewnętrzną pamięcią OctoSPI do przechowywania obrazków i pików video. Tym razem narzędzie od ST jest wymagane ale odpalamy je tylko po stronie Windowsa. Nie trzeba dodawać do do obrazu Dockera. Podobnie uruchamiamy CubeMX.

Po sklonowaniu projektu wystarczy odpalić Docker engine i w VS Code wybrać podłączenie do zdalnego kontenera:

i dalej opcję otwarcia w kontenerze:

Wewnątrz folderu .devcontainer są konfiguracje, spotkamy tam m.in. plik opisujący jakie dodatki do VS Code zostaną pobrane:

			"extensions": [
				"twxs.cmake",
				"actboy168.tasks",
				"marus25.cortex-debug",
				"josetr.cmake-language-support-vscode",
				"ms-vscode.cpptools-extension-pack"
			]

cortex-debug jest tu kluczowy, bo daje możliwość komunikacji z serwerem debugera. Dodatek tasks jest ułatwieniem, dzięi niemu na taskbarze można mieć wygodne ikonki do budowania i odświeżania CMake.

Wewnątrz .vscode znajdziemy pliki:

• tasks.sjon - zadania takie jak zbudowanie testów jednostkowych, odświeżenia CMake, zbudowanie firmwaru dla STM,
• launch.json - uruchomie wgrywania i debugging lub attach do działającego programu
• c_cpp_properites.json - miejce gdzie warto dodać ścieżki do plików źródłowych dla poprawy działania Intellisens.

Taski w połączeniu z dodatkiem do skrótów mogą dać ałkiem użyteczne menu:

Wybieramy: Regenerate > Build (lub standardowo Ctrl+Shift+B)

i na koniec Debugujemy (standardowo F5) lub tu:

Ciekawie robi się gdy chcemy wgrać coś na zewnętrzną pamięć, tu wchodzi temat loadera.

Pierwsze to idziemy do linkerscripta i upewniamy się, że sekcje które mają powędrować do zewnętrznego FLASHA są opatrzone przez NOLOAD. Ich symbole pojawią się w pliku .map ale nie będą w binarce. W przeciwnym razie binarka miałaby z kilka MB. Tej konfiguracji używamy do wgrania firmwaru do FLASHA STMki:

/* Attempt to move it to external memory */
  ExtFlashSection (NOLOAD) :
  {
    *(ExtFlashSection ExtFlashSection.*)
    *(.gnu.linkonce.r.*)
    . = ALIGN(0x4);
  } >EXT_FLASH

W pliku .map wygląda to tak:

ExtFlashSection
                0xa0000000   0x3465f8
 *(ExtFlashSection ExtFlashSection.*)
 ExtFlashSection
                0xa0000000    0x1ba80 CMakeFiles/tmplatemkfileu5dk.dir/TouchGFX/generated/images/src/image_AI.cpp.obj
                0xa0000000                image_ai
 ExtFlashSection
                0xa001ba80    0x1155c CMakeFiles/tmplatemkfileu5dk.dir/TouchGFX/generated/images/src/image_chatlogo.cpp.obj
                0xa001ba80                image_chatlogo
 ExtFlashSection
                0xa002cfdc     0x91e8 CMakeFiles/tmplatemkfileu5dk.dir/TouchGFX/generated/images/src/image_you.cpp.obj
                0xa002cfdc                image_you
 ExtFlashSection
                0xa00361c4   0x310432 /workspaces/STM32U5_CMake_DevContainer_TouchGFX_Template/target/TouchGFX/generated/videos/obj/evil_parrot_3sec_800_480.bin.o
                0xa00361c4                video_evil_parrot_3sec_800_480_bin_start
                0xa03465f6                video_evil_parrot_3sec_800_480_bin_end

Teraz potrzeba przygotować binarkę z grafikami do zewnętrznego FLASHa. Najpierw usuwamy NOLAOD żeby można było wyciagnąć z pliku elf sekcje ExtFlashSection.

Używamy polecenie:

arm-none-eabi-objcopy -O binary --only-section=ExtFlashSection target/build/tmplatemkfileu5dk.elf gdb/jlink_flash_loader/images.bin

I znajdujemy plik gotowy do wrzucenia.

W tym miejscu upewniamy się że w firmwarze jest dodane API. 

#define LOADER_RAM_BUFFER_SIZE (64 * 1024)
uint8_t __attribute__((section(".loader_ram_buff_section"))) loader_ram_buffer[LOADER_RAM_BUFFER_SIZE];

uint32_t __attribute__((section(".loader_ram_keep_section"))) loader_checksum;

uint32_t __attribute__((section(".loader_code_section"))) loader_copy_to_ext_flash(uint32_t flash_offset, uint32_t loader_bytes_count) {

GDB ma możliwość wgrywania do pamięci RAM poprzez polecenie "restore" oraz wywoływania funkcji przez polecenie "call" i zbieranie wyników. Dlatego też trzeba upewnić się, że bufor w ramie i funkcja są widoczne tj. mają adresy inne niz NULL:

 .loader_ram_buff_section
                0x201ef8d8    0x10000 CMakeFiles/tmplatemkfileu5dk.dir/Core/Src/main.c.obj
                0x201ef8d8                loader_ram_buffer

Żeby takie nieużytki były załączone w firmwarze trzeba je w linkerze opatrzeć przez KEEP. Bez tego byśmy mieli tam NULL.

  .loader_ram_buff_section (NOLOAD) : {
    . = ALIGN(4);
    KEEP(*(.loader_ram_buff_section))
  } > RAM
  

Nie polecam też używania static - w wyniku zniknie symbol. Dla bufora jest to akceptowalne, ale dla funkcji już nie.

Następnie uruchamiam CLI z parametrami opisującymi pamięć oraz nazwy funkcji, bufor. Dodany plik .elf służy za odszyfrowanie jakie adresy kryją się za buforem i funkcją. Dzięki temu nie musimy posługiwać się samymi adresami podatnymi na zmiany.

gdbloader -b C:\WS\STM32U5_CMake_DevContainer_TouchGFX_Template\gdb\jlink_flash_loader\images.bin -g arm-none-eabi-gdb -e C:/WS/STM32U5_CMake_DevContainer_TouchGFX_Template/target/build/tmplatemkfileu5dk.elf -B Loader_Breakpoint

Warto zwrócić uwagę gdzie dobrze jest zatrzymać program. Na pewno po inicjalizacji peryferiów. Dla pamięci dostępnej na płytce DK2 trzeba też uwzględnić, że zapis odbywa się przez odpowiednie funkcje, ale do odczytu można posłużyć się wygodnym trybem memory-mapped. Dlatego po znaczniku breakpointu i potencjalnej wymianie binarki trzeba zmienić tryb pracy na memory-mapped.

  Loader_Breakpoint();

  int status = BSP_HSPI_NOR_EnableMemoryMappedMode(0);
  if (status != 0) {
      Error_Handler();
  }

I tyle, albo aż tyle. Czy warto? To już sprawa dyskusyjna. Mam wrażenie że programy budują się szybciej. Dodatkowy target dla hosta i testy niezależnych funkcji to niezłe udogodnienie. A kłopotliwe wyciąganie binarki dla zewnętrznej pamięci można rozwiązać dodając kolejny target dla CMake.

Dużą zaletą wgrywania po debugerze to szybkość, 6MB wgrywa się z 40sekund. Ale dużą wadą jest to, że nie mamy dostępu do debugera i RTT. Loader po USB byłby pewnie lepszy 🙂 Na pewno ciekawe wrażenie to zamiganie diodą przy pomocy debuggera.

 

 

 

[_LM_]

Pokazałbyś może jak zrobić kontener tak żeby był wybór pomiędzy kompilatorem dla stm32 lub xtensa esp32? 

[Gieneq]

@_LM_ możnaby sie temu przyjrzeć. Widziałem że w przykładach dla ESP-IDF są dołączone konfiguracje DevContainera. Nas stronie Espressifa jest instrukcja, tylko z tą różnicą, że wchodzą w temat podłączenia portu USB do kontenera. U mnie to właśnie nie działało przez problemy z adminem dla WSLa. A później było jeszcze więcej problemów z okręcaniem sterowników do urządzeń USB. 

Ale jak sie z tym uda uporać to dalej jest łatwo. Dodatek do ESP-IDF bazuje na CMake. Reszta jest raczej bezproblemowa.

A chcesz mieć w 1 projekcie 2 targety?

[_LM_]

1 minutę temu, Gieneq napisał:

A chcesz mieć w 1 projekcie 2 targety?

Wystarczy żebym mógł w miarę bez problemowo przełączać się pomiędzy kompilatorami, póki co VSC domyślnie widzi ten od espressif, i dla STM32 również próbuje za jego pomocą skompilować, będę przy kompie to pokażę w czym problem. W tej chwili dla ST używam cube MXa który generuje projekt cmake później import w rozszerzeniu STM32 (w vsc) 

[Polecacz 101]

Produkcja i montaż PCB - wybierz sprawdzone PCBWay!
   • Darmowe płytki dla studentów i projektów non-profit
   • Tylko 5$ za 10 prototypów PCB w 24 godziny
   • Usługa projektowania PCB na zlecenie
   • Montaż PCB od 30$ + bezpłatna dostawa i szablony
   • Darmowe narzędzie do podglądu plików Gerber
Zobacz również » Film z fabryki PCBWay

[matsobdev]

Strzał na oślep. W CMakeLists.txt można zdefiniować:

set(CMAKE_C_COMPILER /media/mateush/Dane/Pico_2/riscv-embecosm-embedded-ubuntu2004-20240407/bin/riscv32-unknown-elf-clang)
set(CMAKE_CXX_COMPILER /media/mateush/Dane/Pico_2/riscv-embecosm-embedded-ubuntu2004-20240407/bin/riscv32-unknown-elf-clang++)
set(CMAKE_ASM_COMPILER /media/mateush/Dane/Pico_2/riscv-embecosm-embedded-ubuntu2004-20240407/bin/riscv32-unknown-elf-clang)

np. tutaj ulep, żeby Pico SDK używało Clang/LLVM dla RISC-V. Ale to lokalnie. Nie mam pojęcia o Dokerze, tak tylko powiedziałem,  może się przyda, a może nie 😄 Może sam się czegoś też nauczę nowego 😄

[virtualny]

STM32U5G9J-DK2 - bardzo fajny zestaw z LCD 5" 800x480.

Dla Rusta to chyba jedyna droga do Visual Studio Code plus rozszerzenia, bo raczej trudno by było w CubeIDE podmienić kompilator z C na Rusta i jeszcze zachować zgodność w opcjach Settings...

Mnie przed przesiadką na VSC powstrzymuje fakt, że CubeIDE może istnieć bez VSC, ale VSC bez toolsów od ST miałoby nikłe szanse na powodzenie i ukończenie projektu dla STM32. Nie inaczej jest tutaj:

Dev Container

Host Google Tests

Target build, flash, debug

CubeMX version: 6.13.0

TouchGFX 4.24.2

CMake

JLink RTT

 

Co do JLink mogę powiedzieć, że kupiłem kiedyś to cudo, które kosztowało fortunę a daje ful ograniczeń że się nawet nie chce wymieniać. U mnie leży w nieużyciu. 

Nowa Rust moda, który chyba nie jest zły wygląda w tym projekcie tak, że szkielet projektu z CubeMX jest w C, Projekt w TouchGFX jest w C++, i kilka procent albo jeszcze mniej zarządzającego kodu jest w Rust który zrealizuje np. takie jak wywołanie funkcji odtwarzającej GIF'a.

Ja nie chciałbym w jakiś szczególny czy złośliwy sposób piętnować Rusta, ani tym bardziej tego projektu, mi chodzi o jakby nieciągłość logiczną w trendach programowania, którą odbieram z mojego punktu widzenia:

Obejrzałem filmik, który pokazywał trendy programowania od bodaj połowy ubiegłego wieku. Przelatując od Assemblera, Fortrany, Ady, Pascala i co nie tylko doszło do C, w którym nadmieniam napisano Windowsa czy Linuxa. Tak więc potem nastała era, która opiewała C++, jaki on wspaniały i lepszy, aż tu nagle okazało się że nieprawda, bo C# jest zajebisty! Cała reszta wcześniej to nieudolne G! I nie to jeszcze w tym filmiku było najstraszniejsze - najstraszniejszy był czas dzisiejszy, w którym oznaczono największą grupę programującą obecnie. I tą największą grupą okazała się grupa Pyton!!! I czy naprawdę należy rzucać wszystko owczym pędem i przesiadać się na tego... Pytona? Bo moja obawa wynika z tego, że ta największa grupa rzekomych programistów Pytona nie będzie w stanie w tym całym Pytonie napisać Windowsa czy Linuxa, tylko korzystając z udostępnionych rozszerzeń dla skryptów z Linux czy Windows zabawiać się udostępnionymi interfejsami, być może stworzyć jakiś super prymitywny system operacyjny, którym będzie zarządzał host skryptów.

Ja wiem że Rust jest o wiele bliżej C/C++/C# i o wiele dalej od Pytona. Jeżeli ja z ledwością opanowałem podstawy C, a cały czas uważam siebie za naprawdę lichego specjalistę od C, to co mogłaby mi dać przesiadka na Rusta, poza tym że musiałbym się uczyć nowego języka od nowa? Języka który dla mnie jest jak Norton Commander dla DOS, tylko że w tym wypadku jest on nasadką dla C/C++

[ethanak]

Python jako język interpretowany niespecjalnie się nadaje do pisania systemów operacyjnych - w jakim języku musiałby być napisany interpreter Pythona?

Każdy język ma swoje zastosowanie.

[SOYER]

1 godzinę temu, virtualny napisał:

STM32U5G9J-DK2 - bardzo fajny zestaw z LCD 5" 800x480.

Dla Rusta to chyba jedyna droga do Visual Studio Code plus rozszerzenia, bo raczej trudno by było w CubeIDE podmienić kompilator z C na Rusta i jeszcze zachować zgodność w opcjach Settings...

Mnie przed przesiadką na VSC powstrzymuje fakt, że CubeIDE może istnieć bez VSC, ale VSC bez toolsów od ST miałoby nikłe szanse na powodzenie i ukończenie projektu dla STM32. Nie inaczej jest tutaj:

Dev Container

Host Google Tests

Target build, flash, debug

CubeMX version: 6.13.0

TouchGFX 4.24.2

CMake

JLink RTT

 

Co do JLink mogę powiedzieć, że kupiłem kiedyś to cudo, które kosztowało fortunę a daje ful ograniczeń że się nawet nie chce wymieniać. U mnie leży w nieużyciu. 

Nowa Rust moda, który chyba nie jest zły wygląda w tym projekcie tak, że szkielet projektu z CubeMX jest w C, Projekt w TouchGFX jest w C++, i kilka procent albo jeszcze mniej zarządzającego kodu jest w Rust który zrealizuje np. takie jak wywołanie funkcji odtwarzającej GIF'a.

Ja nie chciałbym w jakiś szczególny czy złośliwy sposób piętnować Rusta, ani tym bardziej tego projektu, mi chodzi o jakby nieciągłość logiczną w trendach programowania, którą odbieram z mojego punktu widzenia:

Obejrzałem filmik, który pokazywał trendy programowania od bodaj połowy ubiegłego wieku. Przelatując od Assemblera, Fortrany, Ady, Pascala i co nie tylko doszło do C, w którym nadmieniam napisano Windowsa czy Linuxa. Tak więc potem nastała era, która opiewała C++, jaki on wspaniały i lepszy, aż tu nagle okazało się że nieprawda, bo C# jest zajebisty! Cała reszta wcześniej to nieudolne G! I nie to jeszcze w tym filmiku było najstraszniejsze - najstraszniejszy był czas dzisiejszy, w którym oznaczono największą grupę programującą obecnie. I tą największą grupą okazała się grupa Pyton!!! I czy naprawdę należy rzucać wszystko owczym pędem i przesiadać się na tego... Pytona? Bo moja obawa wynika z tego, że ta największa grupa rzekomych programistów Pytona nie będzie w stanie w tym całym Pytonie napisać Windowsa czy Linuxa, tylko korzystając z udostępnionych rozszerzeń dla skryptów z Linux czy Windows zabawiać się udostępnionymi interfejsami, być może stworzyć jakiś super prymitywny system operacyjny, którym będzie zarządzał host skryptów.

Ja wiem że Rust jest o wiele bliżej C/C++/C# i o wiele dalej od Pytona. Jeżeli ja z ledwością opanowałem podstawy C, a cały czas uważam siebie za naprawdę lichego specjalistę od C, to co mogłaby mi dać przesiadka na Rusta, poza tym że musiałbym się uczyć nowego języka od nowa? Języka który dla mnie jest jak Norton Commander dla DOS, tylko że w tym wypadku jest on nasadką dla C/C++

Mnie najbardziej interesuje co symbolizują/opisują te liczby przy słupkach. Na jakiej podstawie te słupki?

 

[ethanak]

11 minut temu, SOYER napisał:

Na jakiej podstawie te słupki?

A to bardzo proste. Wyobraź sobie, że siedzi sobie facet na krzesełku przy autostradzie, ma zeszycik i wpisuje przejeżdżające pojazdy. Po podsumowaniu wychodzi, że Scanii przejechało 50, BMW tylko 11, a roweru ani jednego. Wniosek. Scanie wśród kierowców są bardziej popularne niż BMW, a rowery w ogóle się nie liczą.

A jakie ładne słupki można potem narysować 🙂

A drugi facet siedzi przy drodze do wsi Wólka Nurecka z zakazem wjazdu powyżej 3.5 tony. Notuje: rowerów było 40, BMW jeden od sołtysa, a Scanii żadnej. No i rysuje swoje słupki.

Jaka potem może być dyskusja kto ma rację!

[virtualny]

To niby było tak że...

Tyle słów, a jaka jest prawda to wie autor 🙂

Cytat

 

In this video I present a detailed timeline of the most used programming languages from 1958 to 2025, based on comprehensive data analysis. Historical rankings were based on a combination of aggregated national surveys, the number of educational books published about each programming language, and how often these languages are mentioned in global software and technology publications. For recent years, rankings were adjusted using data from multiple programming language popularity indexes, GitHub repository access patterns, and programmer surveys. Popularity in this ranking is defined by the number of developers proficient in or actively learning each language. The scale is normalized to a relative value of 100, allowing for consistent comparisons across languages and time periods. The flame emoji represents languages that have reached the number one spot at least once. The skull emoji represents languages that are no longer officially supported and no longer have an active developer community. Several errors have been corrected from the previous video. I also extended the timeline by nearly a decade, starting from 1958, and added new data from 2023, 2024, and 2025. Your feedback is always welcome. Got topic suggestions? Drop me a message!

 

 

 

[SOYER]

5 minut temu, ethanak napisał:

A to bardzo proste. Wyobraź sobie, że siedzi sobie facet na krzesełku przy autostradzie, ma zeszycik i wpisuje przejeżdżające pojazdy. Po podsumowaniu wychodzi, że Scanii przejechało 50, BMW tylko 11, a roweru ani jednego. Wniosek. Scanie wśród kierowców są bardziej popularne niż BMW, a rowery w ogóle się nie liczą.

A jakie ładne słupki można potem narysować 🙂

A drugi facet siedzi przy drodze do wsi Wólka Nurecka z zakazem wjazdu powyżej 3.5 tony. Notuje: rowerów było 40, BMW jeden od sołtysa, a Scanii żadnej. No i rysuje swoje słupki.

Jaka potem może być dyskusja kto ma rację!

Tego właśnie się obawiałem, bo jakoś te liczby ciągle w tych samych zakresach oscylowały… 

 

[virtualny]

Tak to jest wytłumaczone:

Cytat

The scale is normalized to a relative value of 100, allowing for consistent comparisons across languages and time periods. 

[ethanak]

3 minuty temu, virtualny napisał:

Tak to jest wytłumaczone:

No zupełnie jak u mnie z samochodami i rowerami.

 

[Gieneq]

Dnia 15.03.2025 o 11:39, virtualny napisał:

Ja nie chciałbym w jakiś szczególny czy złośliwy sposób piętnować Rusta, ani tym bardziej tego projektu,

@virtualny W tym projekcie do CLI sprawdziłby się też Python. Wybór na Rusta padł dlatego, że chcę się przesiąść na ten język. Faktycznie możnaby się poprzerzucać co lepsze. Przez ostatni rok uczę się Rusta, przez pół roku praktycznie codziennie coś w tym robię. Testowałem programowanie STMów i przyznam, że nie widzę tego w produkcji. Narzędzia są całkiem dobre, ale daleko od Cuba. Biblioteki napisali hobbyści i na jakimś etapie wypalili się i porzucili.

Ale są pewne nisze, w których Rust to język "goto", np. blockchain. Poza tym znajdzie się kilka innych obszarów zainteresowania z high performance w nazwie.