Bardzo wolny Ethernet w STM32F107

[atlantis86]

Pracuję właśnie nad projektem radia internetowego opartego na STM32F107 oraz sprzętowym dekoderze MP3/AAC VS1003. Projekt nie jest zupełnie nowy - tak naprawdę jest to nowsza wersja urządzenia, które do tej pory działało (zupełnie prawidłowo) na PIC32MX795F512L. Tak więc poszczególne komponenty sprzętowe i sporą część kodu już przetestowałem. Ponieważ użyty przeze mnie STM32 ma mniej RAM-u niż dotychczas używany mikrokontroler, postanowiłem dodać zewnętrzną pamięć RAM na interfejsie SPI (128 kB). Reszta sprzętu jest bardzo podobna: złącze karty SD, gniazdo USB do podłączenia pendrive'a oraz (co najważniejsze) Ethernet 100 Mbps, wykorzystujący wbudowany moduł MAC oraz zewnętrzny układ PHY (DP83848) podłączony przez Interfejs RMII. Spora część projektu płytki (w tym co ważne Ethernet) pochodzi wprost ze wcześniejszej wersji hardware'u.

I tutaj dochodzimy do sedna sprawy. Układ z PIC32 działał zupełnie prawidłowo. Każdy stream odtwarzał się płynnie, bez żadnych zacięć (no chyba, że coś akurat zadławiło łącze internetowe). Tutaj natomiast od razu pojawiły się problemy - transmisja jest tak wolna, że właściwie wszystkie standardowe radia internetowe, które nadają w stereo z bitrate większym niż 100 kbps są koszmarnie poszatkowane. Jako-takie efekty udało mi się uzyskać w przypadku Radia Kraków w wersji 32kbps, ale i tutaj nie jest idealnie - co jakiś czas pojawia się zająknięcie albo charakterystyczny zgrzyt.

Z całą pewności winny nie jest zewnętrzny układ pamięci RAM, na którym zrealizowałem cykliczny bufor do przechowywania nadchodzących danych audio. Jeśli próbuję nakarmić go danymi z karty SD, wszystko działa perfekcyjnie prawidłowo - jakość jest dobra, nic się nie przycina. Problemy pojawiają się dopiero przy próbie słuchania streama, co wskazuje na wolne połączenie. Wierzyć mi się nie chce, że moduł FastEthernet z STM32107 nie jest w stanie przesłać trochę ponad 100 kbps (i ledwie wyrabia przy 32kbps). Nie wydaje mi się też, żeby winę ponosił projekt części sprzętowej odpowiedzialnej za Ethernet - jest on przeniesiony niemal 1:1 ze starszej wersji sprzętu, gdzie wszystko działało idealnie. A gdybym pomylił ścieżki interfejsu RMII projektując płytkę, to raczej nic by nie działało.

Tymczasem na pierwszy rzut oka Ethernet zdaje się działać prawidłowo: łączy się z moją siecią, pobiera konfigurację z DHCP, uzyskuje adres IP zdalnego serwera przez DNS i jest w stanie się z nim skomunikować. Pingi mam poniżej 1 ms. Problem zaczyna się dopiero wtedy, gdy próbuję przepchnąć przez ten interfejs strumień audio. Gdybym wykorzystywał to urządzenie do przesyłania niewielkich ilości danych tekstowych, to pewnie nawet nie zorientowałbym się, że coś jest nie tak.

Podejrzewam, że winę ponosi konfiguracja stosu lwIP (a przynajmniej taką mam nadzieję). Czy ktoś mógłby mi podpowiedzieć jaka jest najbardziej optymalna konfiguracja przy tego typu zastosowaniach?

Edytowano Wrzesień 29, 2022 przez atlantis86

[piotr96]

Zacząłbym od zwiększenia liczby i pojemności deklarowanych buforów w ustawieniach konfiguracji lwIP oraz ogólnego rozmiaru pamięci (sterty). Nie pamiętam dokładnych nazw tych parametrów, kiedyś miałem do czynienia z tą biblioteką na układzie Zynq Xilinxa, a nie na STMie, ale wiem, że zmiana tych parametrów może przynieść dużą różnicę. Chociaż podane osiągi są bardzo słabe, nawet przy domyślnych ustawieniach oczekiwałbym jednak szybszej transmisji.

[atlantis86]

Ok, wychodzi na to, że głównym powodem wolnego działania była warstwa aplikacji, na której krztusiła się transmisja. Kod był pisany z myślą o zupełnie innym stosie (biblioteka wchodząca w skład MLA od Microchipa) na mikrokontroler PIC32, która miała zupełnie inna filozofię obsługi. Transmisja krztusiła się na komunikacji pomiędzy stosem, buforem audio oraz układem VS1003. Głównym źródłem problemów było to, że RAW API w lwIP nie pozwala mi w prosty sposób pobierać z bufora odbiorczego akurat takiej liczby bajtów, jaka w danym momencie jest potrzebna - trzeba jak najszybciej pobrać całość, zwolnić pamięć i poprosić o więcej. Próbowałem pogodzić to z istniejącym kodem, ale pojawiły się problemy z wydajnością.

Teraz próbuję odpalić na tej płytce FreeRTOS, aby mieć dostęp do Socket API, które powinno być bardziej kompatybilne z istniejącym kodem. Tylko tutaj trafiłem na inny problem z Ethernetem.