Gieneq

W skrócie: chcesz zrobić projekt na STM32 za który dostaniesz wynagrodzenie, ale nie oczekujesz pracy na etacie. Hardware gotowy, wystarczy napisać firmware. Firma Enbio poszukuje programisty do współpracy przy realizacji firmwaru do nowego sterylizatora parowego. Wymagania: umiejętność napisania produkcyjnego kodu, STM32U5, TouchGFX, Git C/C++ FMC, OCTOSPI, NOR, PSRAM, SPI, UART, Modbus RTU, FileX, LevelX, Azurte RTOS, podstawy sterowania: PID, histereza, debugowanie softwaru + hardwaru Praca raczej na zasadzie zlecenia realizacji firmwaru, ewentualnie kontynuacji założonego projektu. Jest opcja dalszej współpracy przy kolejnych projektach, możliwe że nie tylko firmware ale i hardware. Do dogadania. Siedziba firmy Gdynia-Rumia.

@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.

@_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?

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_ wydaje mi się, że bez buforowania kilku sekund i kopii zapasowej się nie obędzie. Robiłem niedawno podobny mechanizm dla STM i skończyło się na takim procesie: zapis serializuje i wrzucam bajty w kolejkę bajty zbieram aż uzyskam 512B tyle ile zajmuje sektor lub do zdarzenia flush, np przy zakończeniu wgrywania. otwieram i dogrywam. Jeżeli często robisz zapisy to wearleveling szybko zfragmentuje pamięć i spadnie szybkość zapisu. Jest coś takiego (przynajmniej w FileX) jak failsafe, mechanizm po powrocie zasilania odtworzy to co zostało niedomknięte, ale kopia zapasowa będzie na pewno bezpieczniejsza.

@farmaceuta śmiesznie że w logu jest dalej STA. Może jednak nie zrobiło się AP. Widzisz w ogóle ten AP na liście sieci?

@farmaceuta Arduino dawno nie używałem, do ESP bardziej esp-idf. W pliku Esp32_servers_config.h masz sporo ustawień. Trzeba zastanwoić się jak to ma działać. Na początek będzie łatwiej jako // A(ccess) P(oint). Zakomentuj to co jest dla station i odkomentuj AP: // #define DEFAULT_AP_SSID HOSTNAME // <- replace with your information, // #define DEFAULT_AP_PASSWORD "YOUR_AP_PASSWORD" // <- replace with your information, at least 8 characters // #define DEFAULT_AP_IP "192.168.0.1" // <- replace with your information // #define DEFAULT_AP_SUBNET_MASK "255.255.255.0" // <- replace with your information I po restarie powinieneś móc wejsc do sieci wystawionej przez ESP. Dalej wchodzisz na IP które masz tu ustawione, może jest przekierowanie albo captive portal to dsamo powinno przerzucić na stronę. Jak ustawisz te definy to zobaczymy co dalej. Ale to może być problem z bibliotekami zaglądam, jak jest o czym mam większe pojęcie to napisze. A tak to sporo zajęć w pracy, życiu i nie zawsze czas.

@farmaceuta fajny projekt, pod względem UI wygląda przekonująco. Z czym właściwie masz problem? Jest plik .ino dla IDE, w pliku HTML masz pliki które twój serwer musi udostępnić na jakimś endpoinie, który dalej będzie widoczny dla użytkownika. W Arduino IDE pewnie jest jakiś sprytny przycisk to pakuje wszystko i wrzuca do FLASHa ESP.

@H1M4W4R1 tak ciężko to zorganizować, czasem trzeba przejść się na produkcję.

@szymarduino uczyć się najlepiej na komputerze, nie tracisz czasu na wgrywanie, masz łatwiejsze narzędzia. Później może lepiej ESP?

@DeadGeneratio fajnie jak e-ink waveshare to masz do niech przykłady nawet dla STM. Ale wystarczy że napiszesz funkcje wysyłania komend i danych i znajdziesz pasujacy zestaw ustawień i bedzie ok.

W ramach rozwoju działu R&D (praktycznie podwojenia składu) i rozwoju działów w tym związanych kilka ofert pracy: R&D Python Developer Project Engineer Process Engineer Mechanical Design Engineer Embedded Developer R&D Control System Engineer Specjalista ds. IT Wybrane oferty: oraz inne w linku powyżej.

@DeadGeneratio odczytujesz to po UARCIE w przerwaniu po 1 znaku? HAL_UART_Receive_IT(&huart1, (uint8_t*) rxBuffer, 1); Dodaj obsługę błędu od UARTu. Spróbuj też innej metody niż odczytywanie po 1 znaku. Np UARTex ma funkcję z odczytyweaniem do sygnału idle z DMA dla nieznanego rozmiaru danych. Sprawdź priorytety, 0 to najwyższy. Sprawdź czy nie kłuci się z timerem od delaya. I nie używaj delay

@MR1979 podczas webinaru ST dostałem taką odpowiedź:

@Kiko ok, a może da się jakoś uprościć temat grafik. Zamiast zaciągania pliku PNG może najpierw go przekonwertuj. Np LVGL ma bardzo przydatne narzędzie. Możesz następnie wrzucić taki const C array do kodu i zapisze sie we FLASHU. W ten sposob możesz zoptymalizować kolory i przezroczystości.