On 9.02.2024 01:05, Marek wrote:

> Nie mam zbyt dużo doswiadczenia z Harmony, Kiedyś krótko to testowałem
> ale nie wdrażałem produkcyjnie. Natomiast na MLA + enc28j60 mam na
> produkcji urządzenia chodzące już 10 rok 24h i nigdy nie było problemu z
> łącznością z nimi, uważam, że stos MLA jest bardzo stabilny (TCP + UDP,
> jedyne co nie używam, ze stosu to DHCP oraz tego ich serwera HTTP,
> używam własny).

Ja też właśnie przez długie lata korzystałem z z MLA i ciągle korzystam
z niego w projektach z mniejszymi MCU. W przypadku PIC18/PIC24 innego
wyjścia właściwie nie ma, a i część PIC32 ma za mało zasobów, żeby
obsłużyć Harmony. Jednak jakby nie patrzeć, MLA jest już dość starą i
nierozwijaną biblioteką, która z kolei nie wspiera nowszych układów.
To jest właśnie główny powód, dla którego przeniosłem ten projekt na
Harmony - nowsza wersja hardware'u wykorzystuje PIC32MZ2048.

Harmony ma też swoje zalety - kod łatwo generuje się z konfiguratora,
jest też dostępnych więcej bibliotek. Pamiętam, że kiedyś spędziłem
kilka tygodni naprawiając jakiś krzywy kod z GitHuba, aby mieć na MLA
obsługę klienta MQTT. W Harmony taki klient po prostu jest zaimplementowany.

Co do stabilności - jak wspomniałem, na PIC32MZ2048 nie natknąłem się na
podobne problemy. Dlatego podejrzewam, że kwestia może się kryć gdzieś w
optymalizacji konfiguracji pod kątem wykorzystania zasobów.


> Był jeden incydent w trakcie jakiś testów właśnie podobny do tego co
> opisujesz, ale ciągle nie pamiętam szczegółów.

Pamiętasz czy to było na MLA czy Harmony?
W każdym razie, odkąd wczoraj zmieniłem priorytet tasku z moja
aplikacją, problem się nie pojawił. To znaczy był inny crash, ale
znacznie mniej uciążliwy: klient z utracił łączność i nie chciał się
połączyć ponownie (DNS wywalał błąd -5) ale nie było już efektu
świecenia diody ACT i blokady ruchu na poziomie switcha. Tym razem
wystarczyło tylko odpiąć o ponownie podpiąć kabel ethernetowy, bez
resetowania całego urządzenia.