stronę

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

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

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

Marek snipped-for-privacy@fakeemail.com napisał(a):

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

Atlantis snipped-for-privacy@wp.pl napisał(a):

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:

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

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

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