On Tue, 24 Jan 2023 11:07:40 +0100, Atlantis <m...@w...pl>
wrote:
> już próbowałem zwiększać przydziały pamięci do dość znacznych
> wartości,

No ale co, nie ma możliwości zdebugowania w którym miejscu kodu się
zatrzymuje?

--
Marek

do góry

On 23.01.2023 23:45, Atlantis wrote:

> Problemy zaczynają się dopiero wtedy, gdy próbuję wysłać sekwencję "GET
> " (spacja na końcu) + pusta linia. Wtedy już płytka traci połączenie z
> siecią. Tak samo wygląda oczywiście sytuacja, jeśli próbuję np "GET
> /index.htm HTTP/1.1".
>
> Jakiś pomysł co może odpowiadać za taki stan rzeczy?
>

Czyli httpd nic nie zwraca - najwyraźniej ma problem z wysłaniem
czegokolwiek.
Podejrzewałem jeszcze jakiś krzak w danych strony - jakiś niedozwolony
znak czy po prostu niemożliwość odczytania tych danych... ale wtedy 404
powinien zwracać bez problemu... no chyba że on sprawdza czy ma coś
takiego do wysłania, próbuje odczytać i dup.


> W przypadku zdrowej płytki wysłanie "GET " + pusta linia skutkuje po
> prostu zwróceniem błedu 404.

No właśnie, w a w przypadku innych śmieci ta zdrowa wyrzuca bad request
400 czy też tylko się rozłącza?

--
Mirek.

do góry

On 24.01.2023 20:15, Marek wrote:
.
> Na stosie MLA mam urządzenia mission  critical obsługujące procesy
> produkcyjne chodzące 24h już z 8 lat non stop, nie wyobrażam sobie by
> urządzenie miało niestabilny stos wieszając się i wstrzymując/zaburzając
> produkcję. Nie  wspominajac o mało poważnych pierdołach typu
> inteligentny dom.

Już od paru lat stosuję w swoich projektach sos MLA i mam podobne
obserwacje. Urządzenia działające 24/7 właściwie nigdy same z siebie nie
gubiły połączenia ani się nie zawieszały.
Od jakiegoś czasu stosuję też ESP8266/ESP32, gdzie pod maską również
siedzi lwIP. I tutaj także stabilność wygląda bardzo dobrze. Jeden ze
swoich starszych projektów przeniosłem z tandemu PIC32+ENC28J60 na
ESP8266. Doświadczenia z korzystania były bardzo zbliżone - płytka
działała nieprzerwanie tygodniami (albo i miesiącami) podczas testów.
Zawieszeń albo niestabilności nie zauważyłem.

STM32 w zastosowaniach sieciowych używam od niedawna. Projekt z którym
mam problemy jest drugą płytką tego rodzaju. Ta pierwsza zachowywała się
stabilnie. Dopiero teraz trafiłem na ten problem.

Dlatego jednak podejrzewam, że możliwości są dwie:
- Ja zrobiłem coś nie tak i teraz muszę znaleźć przyczynę (najbardziej
prawdopodobne).
- Za wadliwe działanie odpowiada fragment kodu wygenerowany przez
STM32CubeMX, wtedy będę musiał go znaleźć i naprawić.

do góry

On 24.01.2023 20:34, Mirek wrote:

> Czyli httpd nic nie zwraca - najwyraźniej ma problem z wysłaniem
> czegokolwiek.
> Podejrzewałem jeszcze jakiś krzak w danych strony - jakiś niedozwolony
> znak czy po prostu niemożliwość odczytania tych danych... ale wtedy 404
> powinien zwracać bez problemu... no chyba że on sprawdza czy ma coś
> takiego do wysłania, próbuje odczytać i dup.

Hmm... Ta hipoteza ma sens w kontekście tego jak działa serwer HTTPD z
lwIP. Stronę WWW konwertuje się do tablic C za pomocą odpowiedniego
narzędzia (windowsowy plik exe, jednak działa pod Linuksem z Wine),
podobnie jak miało to miejsce z HTTP2 z MLA na PIC32.
Treść wyświetlana w przypadku błedu 404 powinna być dostarczona w formie
pliku "404.htm", umieszczonego w głównym katalogu konwertowanej strony.
Dzięki temu mamy możliwość przygotowania komunikatu o błędzie w formie
konsystentnej wizualnie z całą resztą. Nie wiem jak z innymi kodami
błędów - nie sprawdzałem.

Czyli w przypadku prośby o nieistniejący plik, serwer również będzie
chciał pobrać stronę z tego miniaturowego fs-a we flashu.

Mamy więc dwie prawdopodobne możliwości:
- Serwer wiesza się na próbie dostania pobrania pliku
- Serwer wiesza się na próbie wysłania danych

To drugie wydaje się trochę bardziej prawdopodobne biorąc pod uwagę
fakt, że awaria wykrzacza całą komunikacje sieciową, ale nie powoduje
zawieszenia schedulera RTOS-a.


> No właśnie, w a w przypadku innych śmieci ta zdrowa wyrzuca bad request
> 400 czy też tylko się rozłącza?

Zdrowa płytka po prostu się rozłącza, nie odsyłając niczego.
Telnet zostawia tylko informację "Connection closed by foreign host."

do góry

On 24.01.2023 20:16, Marek wrote:

> No ale co, nie ma możliwości zdebugowania w którym miejscu kodu się
> zatrzymuje?

Taki jest plan. Problemem jest mocno ograniczona ilość czasu na
debugowanie tego wieczorami. ;)

do góry

On Tue, 24 Jan 2023 21:20:27 +0100, Atlantis <m...@w...pl>
wrote:
> lwIP. Stronę WWW konwertuje się do tablic C za pomocą odpowiedniego
> narzędzia (windowsowy plik exe, jednak działa pod Linuksem z Wine),
> podobnie jak miało to miejsce z HTTP2 z MLA na PIC32.

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

--
Marek

do góry

On 24.01.2023 21:20, Atlantis wrote:

> Mamy więc dwie prawdopodobne możliwości:
> - Serwer wiesza się na próbie dostania pobrania pliku
> - Serwer wiesza się na próbie wysłania danych
>
No to wyprintuj tą stronę, będzie wiadomo że ją prawidłowo czyta z tablicy.

> To drugie wydaje się trochę bardziej prawdopodobne biorąc pod uwagę
> fakt, że awaria wykrzacza całą komunikacje sieciową, ale nie powoduje
> zawieszenia schedulera RTOS-a.
>
No coś tam mówiłeś, że nie odpowiada na pingi. A który wątek odpowiada
na pingi?
A pingi z większymi pakietami chodzą?

A w ogóle to masz tam jeszcze coś, co może wysyłać dane? Może jakiś
netcat udp-sender albo coś?

--
Mirek.

do góry

Marek <f...@f...com> napisał(a):
> Ł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...

Nie zawsze masz jakąś pamięć poza Flashem wewnątrz uC.

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

do góry

Marek <f...@f...com> napisał(a):
> Nie pojmuję co Ty pokazujesz. IwIP jest aż tak niedopracowany/niestabilny czy tylko
trudny w poprawnej implementacji
> przy pierwszym podejściu??
> Myślałem, że to pewna i dobra alternatywa np. dla stosów mchp (MLA/Harmony) a tu
takie kwiatki?

Jest dopracowany. To dojrzały projekt, stosowany masowo. Sam też używam. Stawiam na
nieumiejętność implementacji.

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

do góry

On 24.01.2023 21:21, Atlantis wrote:

> Taki jest plan. Problemem jest mocno ograniczona ilość czasu na
> debugowanie tego wieczorami. ;)

Ok, dodałem jeszcze kilka printf-ów w kodzie.
Udało mi się na razie ustalić jeszcze tyle, że:
1. Płytka odbiera i parsuje request GET, wyciągając z niego ścieżkę
dostępu do żądanego pliku.
2. Funkcje fs_open() jest wołana z tą ścieżką jako parametrem.
3. Plik jest znajdowany, ponieważ funkcja zwraca status "ok".
4. Wywoływana jest jeszcze funkcja fs_close.

do góry