On 24.01.2023 21:48, Marek wrote:

> Ło matko, a w Harmony też tak jest? Nie zrobili jeszcze w "normalnego"
> httpd serwującego pliki z fatfs + handlery cgi-bin? Przecież jakakolwiek
> aktualizacja kontentu strony to rekompilacja całości, nonsens...

Jeszcze nie zagłębiałem się w ten temat za bardzo. Na razie jedynie
włączyłem serwer HTTP na płytce z PIC32MZ i zobaczyłem, że działa (to
znaczy zwraca 404).

Jednak z tego co widzę w opcjach to działa to w ten sposób, że możesz po
prostu wskazać katalog w systemie plików, w którym będzie trzymana nasza
strona.

Jeśli chodzi o system plików, to Harmony czerpie z uniksowych konwencji.
Chociaż FAT obsługiwany jest za pomocą FatFS-a, to framework dostarcza
własne wrappery. W efekcie np. karta SD jest widoczna jako /dev/mmcblk1
a dysk USB jako /dev/sda1. Montujesz je również do katalogu, np.
/mnt/myDrive0.
Harmony zawiera także biblioteki do obsługi innych nośników, np. pamięci
Flash na SPI czy NVM we wbudowanym flashu. Poza FAT-em są też jakieś
dodatkowe systemy plików, bodajże littlefs i jakiś system od Microchipa,
ale im się jeszcze nie przyglądałem.

Co do aktualizacji zawartości strony to z tego co widzę można to robić
przez sieć, np. za pomocą FTP albo HTTP.

Co do lwIP to odnoszę wrażenie, że ten ich serwer HTTPD jest traktowany
trochę po macoszemu i stanowi raczej dodatek. W Internecie trudno nawet
o jakieś materiały albo instrukcje. Z tego co widzę frameworki do
obsługi ESP8266/ESP32 dostarczają własny serwer HTTP, pomimo korzystania
ze stosu lwIP.

do góry

Hmm... Szukając rozwiązania trafiłem jeszcze na coś takiego:

https://community.st.com/s/question/0D53W00001iI95pS
AC/http-request-to-stm32-lwip-results-that-ping-stop
s-working

"The mentioned bug is confirmed.
It is due to Hardware limitation, in fact the Ethernet MAC does not have
access to the Flash (in STM32F407 device) to download http's data."

Tłumaczyłoby to dlaczego problem dotyka tylko nowej wersji płytki,
wyposażonej w STM32F407, podczas gdy stara wersja na STM32F107 działa
poprawnie. Przyznaję, że brzmi to dziwnie. Ethernet nie jest zdolny do
transferów DMA danych z flasha? Tylko czy przypadkiem te strony i tak
nie powinny być przechowywane w jakiejś skompresowanej formie, a przed
wysłaniem trafiać do bufora w RAM-ie?

Jest też sugerowane rozwiązanie:

"The solution is to move HTTP files to SRAM in by removing the const. (...)
In httpserver.c file (lines 32, 35, 42) remove the keyword const ."

Tylko tutaj nie pasuje ani nazwa pliku (httpd.c zamiast httpserver.c)
ani numery linii (u mnie w tej części wypadają jeszcze komentarze z
opisem zawartości pliku).

do góry

On Tue, 24 Jan 2023 22:59:07 +0100, "Grzegorz Niemirowski"
<g...@g...net> wrote:
> Nie zawsze masz jakąś pamięć poza Flashem wewnątrz uC.

Wiem, ale nie rozważam takich opcji jako mało użyteczne.

--
Marek

do góry

Marek <f...@f...com> napisał(a):
> Wiem, ale nie rozważam takich opcji jako mało użyteczne.

Wszystko zależy od potrzeb. Realizowałem takie projekty i tam akurat potrzeba
rekompilacji przy zmianie w kodzie strony
nie była problemem.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

Atlantis <m...@w...pl> napisał(a):
> Ethernet nie jest zdolny do transferów DMA danych z flasha?

Używałem FreeRTOS i socketów na F407, więc nie spotkałem się z tym problemem, ale
zerkam sobie na notę aplikacyjną
AN4031. Zobacz obrazek 7. O ile dobrze czytam matrycę, to Ethernet ma dostęp do
SRAM1, SRAM2 i FSMC. Do Flasha nie. Dla
szybszego dostępu zrzut ekranu: https://i.imgur.com/nG3dGxS.png

> Tylko czy przypadkiem te strony i tak nie powinny być przechowywane w jakiejś
skompresowanej formie, a przed wysłaniem
> trafiać do bufora w RAM-ie?

Nie wiem czy zawsze powinny, ale ogólnie jest to dobry pomysł. Nawet napisałem sobie
własną wersję programu makefsdata,
która wszystkie pliki gzipuje a dopiero potem robi z nich tablice w kodzie C. W ten
sposób mój serwer od razu serwuje
skompresowane pliki. Przeglądarki je sobie rozkompresowują.

> Jest też sugerowane rozwiązanie:
> "The solution is to move HTTP files to SRAM in by removing the const.
> (...) In httpserver.c file (lines 32, 35, 42) remove the keyword const ."
> Tylko tutaj nie pasuje ani nazwa pliku (httpd.c zamiast httpserver.c) ani numery
linii (u mnie w tej części wypadają
> jeszcze komentarze z opisem zawartości pliku).

Stawiam na roztargnienie postującego, zapewne chodziło mu o fsdata.c.

--
Grzegorz Niemirowski
https://www.grzegorz.net/

do góry

On 25.01.2023 22:35, Grzegorz Niemirowski wrote:

> Wszystko zależy od potrzeb. Realizowałem takie projekty i tam akurat
> potrzeba rekompilacji przy zmianie w kodzie strony nie była problemem.

Swoją drogą przyjrzałem się temu HTTPD dołączonemu do lwIP z STM32CubeMX
(na działającej płytce z STM32F107) i bynajmniej nie jestem pod
wrażeniem. Stworzony dekadę temu HTTP2 od Microchipa wygrywa z nim
zdecydowanie. Sposób obsługi statycznych stron wygląda podobnie
(generujemy plik zawierający tablice C z danymi stron) ale jednocześnie
znacznie lepiej zrealizowano komunikację pomiędzy przeglądarką i MCU.

W HTTP2 dużo lepiej wyglądała kwestia przekazywania parametrów w
requestach GET i POST. Mogłem też dośc wygodnie tworzyć sobie adresy do
dynamicznego pobierania informacji o stanie aplikacji w formie JSON-a,
dzięki czemu interfejs w przeglądarce mógł działać jak interaktywna
aplikacja.

HTTPD właściwie narzuca przestarzałe podejście z przeładowywaniem stron
i przekierowywaniem do kolejnego adresu po wywołaniu cgi. Możliwość
przekazywania parametrów przez GET też jest dość mocno ograniczona. Może
da się to zrobić lepiej, ale raczej nie w sposób oczywisty i najlepiej
udokumentowany w internecie.

Już dużo lepiej wygląda serwer na ESP32/ESP8266. Tam co prawda na
starcie trzeba było trochę pokombinować, np. ręcznie napisać funkcje do
odczytywania i odsyłania statycznych stron z FS-a i osobne do tych
dynamicznie generowanych (np. odsyłających JSON-a) ale za to już samą
stronę łatwo się pisało i przenosiło. Serwer właściwie wymuszał
stosowanie AJAXa. Będę musiał zobaczyć czy nie jest gdzieś dostęopny i
czy przypadkiem nie dałoby się go zaimplementować w projekcie na STM32...

do góry