[STM32F107][STM32CubeMX][lwIP]Przenoszenie projektu na FreeRTOS

[atlantis86]

Mam pewien projekt oparty na STM32F017, gdzie wykorzystuję Ethernet (DP83848 podłaczony przez RMII) do pobierania z sieci streamów audio, które następnie są odtwarzane na VS1003. Hardware jest przetestowany i mogę z ogromną dozą pewności stwierdzić, że działa - podobnie jak spora część kodu, która pochodzi ze wcześniejszej rewizji tego sprzętu, zbudowanej w oparciu o mikrokontroler PIC32.

Niestety rozwijając ten projekt trafiłem na ścianę z powody RAW socketów lwIP (tych opartych na callbackach). Nie pozwalają one na pobranie dowolnej liczby bajtów z bufora odbiorczego w dowolnym momencie, a na takim założeniu opierało się działanie mojej aplikacji. Zamiast tego w momencie wywołania callbacka mam obowiązek jak najszybciej pobrać dane, zwolnić pamięć i poprosić o więcej. Wymagałoby to kompletnej zmiany przyjętych założeń i de facto napisania sporej części kodu od nowa.

Dlatego postanowiłem zastosować inne podejście - przenieść projekt na FreeRTOS, co pozwoli mi wykorzystać SocketAPI z lwIP. Otworzyłem ponownie plik projektu w STM32CubeMX i wyklikałem podstawową konfigurację FreeRTOS: dodałem główny task, ustawiłem mu rozmiar stosu nieco większy od domyślnego, upewniłem się, że opcje związane z RTOS-em są włączone w lwIP. W tym ostatnim przypadku pojawił się jakiś błąd w CubeMX, bo pole USE_NEWLIB_REENTRANT w konfiguracji lwIP zostało wypełnione jakimś łańcuchem tekstowym, który nie był rozpoznawany jako prawidłowa wartość, jednak kiedy wpisałem tam "1". Wszystko wróciło do normy.

Wygenerowałem nowy kod. Zacząłem od przenoszenia kodu z pętli głównej w funkcji main() do utworzonego tasku. Po skompilowaniu kodu przetestowałem biblioteki, które albo napisałem sam, albo ręcznie dodałem do projektu (to znaczy nie za pośrednictwem CubeMX) - zadziałały właściwie bez problemu.

Niestety okazało się że pojawił się problem z działaniem USB HOST (MSD) oraz Ethernetu. Obydwa te urządzenia działały poprawnie gdy kod był odpalony w trybie "bare metal", ale przestały po uruchomieniu RTOS-a.

1. W przypadku USB wyglądało to tak, jakby płytka zupełnie przestała widzieć podłączonego do niej PenDrive'a. FatFS przy próbie wykonania jakiejś operacji na tym nośniku zwracał FR_DISK_ERR, chociaż z dostępem do karty pamięci (obsługiwanej przez zewnętrzny driver korzystający z magistrali SPI) nie miał problemów. Ten problem udało mi się rozwiązać przez zwiększenie rozmiaru stosu dla głónego tasku oraz przestrzeni w RAM-ie, przeznaczonej na stosy dla tasków. Teraz jestem już w stanie korzystać z pendrive'a.
2. W przypadku Ethernetu problem polega na tym, że płytka nie otrzymuje adresu IP od servera DHCP. Logi na routerze potwierdzają otrzymanie wiadomoci DISCOVER z adresu MAC odpowiadającego mojemu urządzeniu. Odsyłany jest także OFFER z adresem IP, jednak płytka nigdy nie pojawia się na liście urządzeń podłączonych do routera. Próba ustawienia statycznego adresu IP nie przynosi żadnego rezultatu.

Czy ktoś ma pomysł gdzie mógłbym szukać przyczyny takiego zachowania Ethernetu/lwIP. Przypominam, że w trybie "bare metal" wszystko działało poprawnie, więc problem z całą pewnością nie jest sprzętowy i jego przyczyna wiąże się z przejściem na RTOS.

[atlantis86]

Ok, częściowo udało mi się rozwiązać problem. Okazało się, że Ethernet/lwIP nie chciał startować z powodu ustawienia zbyt małej przestrzeni w RAM-ie na stosy tasków. Gdy dodałem kilka kB, łączność sieciowa ruszyła.

Na chwilę obecną płytka uzyskuje adres IP z DHCP, pojawia się na liście urządzeń na routerze oraz można ją pingować.

Zabrałem się teraz za przenoszenie swojej aplikacji na Socket API i tutaj pojawił się kolejny problem. Mianowicie nie jestem w stanie uzyskać socketa. Funkcja lwip_scoket zwraca -1 i ustawia errno na 105 (No buffer space available). Czy ktoś ma jakiś pomysł o jaki bufor chodzi i jak bardzo powinienem go zwiększyć?

Byłbym też wdzięczny za sugestie gdzie mogę szukać oszczędności na pamięci - STM32CubeIDE pokazuje już ponad 86% wykorzystania RAM-u, którego STM32F107 nie ma zbyt wiele, bo tylko 64kB.