Przenoszenie internetowego radia z PIC32 na STM32 za pomocą lwIP i TCP

Sat Sep 24, 2022 3:58 pm   

Chciałem ostatnio popchnąć trochę do przodu jeden ze swoich poprzednich
projektów - sprzętowe radio internetowe o którym pisałem już wcześniej,
tylko tym razem w wersji ze zaktualizowaną częścią hardware'ową.
Poprzednia wersja była tworzona na PIC32, teraz powoli chciałem
przenieść go na STM32.

Większość softu właściwie już przeniosłem, teraz zostało najważniejsze -
przeportowanie samej aplikacji odpowiedzialnej za odtwarzanie streamu z
Internetu. W przypadku biblioteki MLA na PIC32 było to relatywnie
proste. Socket sieciowy dysponuje buforem FIFO o zdefiniowanej
pojemności - do niego trafiają dane przychodzące z serwera. Dane te
pobieram i ładuję do bufora audio. Robię to jednak dopiero wtedy, gdy
sterownik układu VS1003 stwierdzi, że dane są potrzebne.

W przypadku PIC32 było to relatywnie proste. Miałem kilka funkcji:
- TCPIsGetReady() - zwracała liczbę bajtów w buforze
- TCPGetArray() - funkcja zapisywała pod podany adres w pamięci
określoną maksymalną liczbę bajtów z bufora. Zwracała liczbę bajtów,
które w rzeczywistości udało się pobrać.

Sprawa była prosta - wystarczyło albo pobrać wszystkie dostępne dane,
ale (jeśli było ich za dużo) tylko tyle, żeby wypełnić dostępne miejsce.
W tym drugim przypadku nadwyżka pozostawała w buforze gniazda sieciowego
i była sukcesywnie uzupełniania o kolejne przychodzące dane, które
mogłem pobrać wtedy, gdy znów były potrzebne.

Widzę, że w przypadku lwIP (RAW API) sprawa nie jest już tak prosta.
Zamiast tego muszę zarejestrować callback, który jest wołany za każdym
razem, gdy przyjdą nowe dane. Callback otrzymuje w jednym z parametrów
wskaźnik do struct ptr, w której mam m.in.
- void* paylod
- int len
- int tot_len
- struct pbuf* next

Istnieje więc możliwość, że wszystko co będę musiał zrobić to pobranie
skopiowanie len bajtów spod adresu na który wskazuje payload. Istnieje
jednak szansa, że danych jest więcej - wtedy tot_len > len i kolejnej
porcji danych trzeba szukać w kolejnej strukturze, na którą wskazuje
wskaźnik next.

Jeśli już zakończymy odczytywać dane, trzeba zawołać tcp_recved
informując stos, że czekamy na kolejną paczkę. Tu jeszcze jest wszystko
jasne.

Co jednak w sytuacji, gdy powiedzmy do zakończenia wypełniania bufora
pozostało mi 100 bajtów, a w otrzymanej struct pbuf mam ich 500? Na
PIC32 po prostu pobierałem 100, a reszta czekała na swoją kolej. W jaki
sposób uzyskuje się podobny efekt na lwIP?

Sat Sep 24, 2022 4:06 pm   

Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):

Użyć socketów zamiast męczyć się z RAW API?

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

Sat Sep 24, 2022 5:28 pm   

On 24.09.2022 18:06, Grzegorz Niemirowski wrote:


Sockety w lwIP chyba wymagają RTOS-a. Tak to jest zrealizowane na
ESP8266/ESP32 i tam faktycznie nie ma problemu z odbieraniem danych.
Tutaj jednak chciałem to zrobić bezpośrednio na krzemie, więc jestem
skazany na RAW API.

Sun Sep 25, 2022 11:34 am   

Sun Sep 25, 2022 6:08 pm   

Sun Sep 25, 2022 6:11 pm   

Atlantis <marekw1986NOSPAM@wp.pl> napisał(a):

Nie znam Twojego projektu, ale tego nie powinno być dużo. I tak mniej niż
użerać się z RAW API.


FreeRTOS także RAM-u nie potrzebuje dużo.

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

Mon Sep 26, 2022 5:11 am   

Atlantis <marekw1986NOSPAM@wp.pl> wrote:

Nie uzywalem lwIP ale zerknelem do dokumentacji.
Z dokumantacji lwIP wychodzi ze to ma byc "zero copy". Czyli trzymasz
buforki tak dlugo jak sa potrzebne, a potem zwalniasz. Jak cos
zostalo to sobie zapamietujesz polozenie bufora i uzywasz przy kolejnym
callbacku. tcp_recved _nie_ zwalnia buforow, wyglada ze musisz to
robic oddzielnie przez pbuf_free.

--
Waldek Hebisch

Mon Sep 26, 2022 7:09 am   

On 26.09.2022 05:11, antispam@math.uni.wroc.pl wrote:


Ok, czyli chyba faktycznie najprościej będzie posłużyć się dodatkowym
buforem pomocniczym, w którym trzymałbym nadwyżkę. Na dobrą sprawę można
by nawet alokować te dane dynamicznie, na stercie. Wtedy po prostu przed
zapisaniem kolejnej paczki sprawdzałoby się czy wskaźnik do bufora
pomocniczego ma wartość inną niż NULL, zapisywało te dane do głównego
bufora, zwalniało pomocniczy i przypisywało NULL do wskaźnika. Dopiero
wtedy go głównego bufora szłaby paczka nowych danych, a jeśli coś by
zostało, to nadwyżka trafiałaby do zaalokowanego na nowo bufora
dynamicznego.
To chyba jednak bardziej eleganckie rozwiązanie niż opóźnianie
zwalniania całej struktury pbuf do kolejnego callbacka.

Po prostu miałem nadzieję, że można to zrobić bez takich kombinacji,
jedynie pobierając potrzebny w danej chwili kawałek bufora, jak w
przypadku MLA na PIC32.

Mon Sep 26, 2022 3:33 pm   

W sumie mam jeszcze inny pomysł. W układzie mam układ pamięci RAM na
SPI. W późniejszej wersji softu planowałem go wykorzystać w roli nieco
większego bufora audio, jednak chyba wykorzystam go jako bufor
cykliczny, pośredniczący w komunikacji pomiędzy siecią a dekoderem MP3.
W callbackach lwIP będę po prostu ładował kolejne przychodzące dane do
kolejnych adresów w tym układzie, a maszyna stanów obsługująca
odtwarzanie będzie je sobie pobierała, uzupełniając swój własny,
mniejszy bufor w pamięci mikrokontrolera. To powinno mi pozwolić na
rozwiązanie kwestii przekazywania danych w sposób asynchroniczny.

Tue Sep 27, 2022 1:35 pm   

On Sat, 24 Sep 2022 17:58:49 +0200, Atlantis wrote:

A tak swoja drogą - te radia działają na TCP ?
Bo chyba powinny na UDP ...

Kolejna sprawa - jak te radia działają?
Dawniej podawali jakies parametry do bezposredniej transmisji,
dzis wszystko pochowane. Wyswietl nasza strone www.

A radia (te niby "sprzetowe") jakos działają ... maja jakies serwery
z listami parametrów ?


Na moj gust, gdzies musisz sobie założyc bufor odpowiedniej dlugosci,
wpychac tam dane które przyszly, i potwierdzac otrzymanie, lub
poczekac jak sie bufor konczy ... aby zatrzymac transmisje.

J.

Tue Sep 27, 2022 3:12 pm   

2022-09-27 o 15:35 +0200, J.F napisał:

Z reguły jednak TCP. Co gorsze - nierzadko z dodatkową warstwą TLS.
Przykłady streamów:

https://31.192.216.10/RMF2
https://radiovassiviere.ice.infomaniak.ch/radiovassiviere-128.aac
http://stream3.nadaje.com:9000/;stream/1


Da się znaleźć, np. tu:
https://online-radio.eu/

W domu mały NAS Linuksowy z VLC robi za radio, podaję mu URLe
skopiowane właśnie z powyższej strony.

Mateusz

Tue Sep 27, 2022 3:22 pm   

On 27/09/2022 14:35, J.F wrote:

Wszysto idzie po TCP. UDP jest cięzkie do implementacji po stronie
klienta bo trzeba ogarnąć:
- jitter
- packet loss
- out of order packets

Oczywiście da się to ogarnąc bo tak działa cały VoIP...
Myślę że łatwość implementacji klienta tutaj wygrała - większość
streamów to TCP (HTTP)

Wed Sep 28, 2022 7:30 am   

On 27.09.2022 15:35, J.F wrote:


Działają na TCP, a konkretnie na zwyczajnym protokole HTTP. Otwierasz
połączenie z serwerem i wysyłasz GET-a, prosząc o udostępnienie
konkretnego streamu. W odpowiedzi dostajesz odpowiedź i nagłówki. Jeśli
jest to 200 OK, możesz zacząć odbierać i dekodować przychodzące dane
audio. Oczywiście trzeba też obsłużyć inne sytuacje, jak np.
przekierowanie pod inny adres.


Po co? Strumień audio nie potrzebuje niskiej latencji - wszystko i tak
jest buforowane po stronie serwera. Można się o tym dość łatwo przekonać
włączając jednocześnie dowolne radio FM i jego sieciowy odpowiednik,
albo jeszcze lepiej - Jedynkę na falach długich i tę samą stację
nadawaną on-line.



Niektóre stacje nadal podają bezpośrednie URL-e do swoich streamów. Jest
też trochę różnych zestawień w Internecie. W przypadku stacji
narzucających własną aplikację na stronie i tak bardzo często pod spodem
mamy zwyczajne połączenie HTTP - wtedy wystarczy wyłuskać adres
analizując ruch, np. za pomocą narzędzi deweloperskich Chrome'a.



Tak. I to jest właśnie głównym powodem dla którego zabrałem się za ten
projekt. Wkurzał mnie fakt, że większość dostępnych komercyjnie
rozwiązań będzie działała tak długo, jak długo producent raczy
utrzymywać infrastrukturę. Tutaj sam wpisuję URL-e stacji, które chcę
słuchać.



No właśnie tutaj jak na razie rozbijam się o szczegóły. W przypadku
stosu MLA z PIC32 po prostu pobierałem sobie z bufora odbiorczego tyle
danych, ile w danym momencie potrzebowałem. Stos robił pod spodem całą
resztę - jeśli w buforze było miejsce, prosił serwer o więcej danych.
Efekt był taki, że dekoder MP3 z automatu narzucał prędkość transmisji i
nawet przy stosunkowo niewielkich buforach wszystko działało płynnie.

Tutaj sprawa jest trochę bardziej skomplikowana. Dane nie są buforowane
w taki sposób i nie mogę po prostu pobrać dowolnej ilości w dowolnym
momencie. Jeśli zostanie wywołany callback odbiorczy, mam obowiązek
odebrać całą paczkę, zwolnić pamięć i wywołać tcp_recved. Jednak z tego
co rozumiem ta ostatnia funkcja jedynie zwiększa rozmiar okna
odbiorczego, więc nawet pomimo braku jej wywołania nie mam gwarancji, że
jeszcze przez chwilę nie przyjdą kolejne callbacki - być może uda mi się
uzyskać taki efekt odpowiednio manipulując ustawieniami stosu.

Przerobiłem wczoraj nieco swoją aplikację, implementując bufor cykliczny
do którego trafiają dane ze strumienia. Serwer jednak wysyła je nieco
szybciej niż wynikałoby to z bitrate'u strumienia audio - ma to sens, bo
nadmiarowe dane w normalnych warunkach mogą zostać użyte do uzupełniania
bufora. Tak więc jeśli po prostu odbieram dane, wrzucam je do bufora i
potwierdzam otrzymanie, to dość szybko dochodzi do przepełnienia bufora
- dźwięk jest, ale postrzępiony. Próbowałem wywoływać tcp_recved() w
innym miejscu dopiero wtedy, gdy w buforze była dostatecznie dużo
wolnego miejsca, jednak jak na razie nie udało mi się uzyskać poprawnego
działania. Będę jeszcze eksperymentował.

Eksperymenty z zewnętrzną pamięcią SPI RAM 128 kB jak na razie też nie
przyniosły idealnych rezultatów. Nawet przy maksymalnej
dostępnej prędkości (18 MHz) wydaje się ona zwyczajnie zbyt wolna.
Trochę mnie to zaskoczyło, bo karta SD przy dwa razy wolniejszej
transmisji spokojnie wyrabiała z dostarczaniem danych z pliku MP3. Z
drugiej strony jednak tutaj mam operacje odczytu i zapisu, występujące
naprzemiennie w krótkich odstępach czasu.

Zaczynam zastanawiać się czy faktycznie dobrym pomysłem nie będzie
zastosowanie FreeRTOS-a i socketów. Nie wiem tylko czy problemem nie
będzie niewielka ilość RAM-u mikrokontrolerze (64kB).

Wed Sep 28, 2022 7:35 am   

On 27.09.2022 17:12, Mateusz Viste wrote:


Moje pierwsze podejście do tematu autonomicznego radia internetowego
polegało właśnie na wykorzystaniu Raspberry Pi (Zero) z zewnętrznym
DAC-iem i standardowym oprogramowaniem do odtwarzania audio (MPD) pod
spodem. Otwierało to sporo dodatkowych możliwości, jednak trochę
absurdalny wydawał mi się fakt, że urządzenie musi najpierw załadować i
uruchomić cały system operacyjny, żeby zacząć odbierać stację. W celach
edukacyjnych postanowiłem więc złożyć wersję na mikrokontrolerze.

Wed Sep 28, 2022 8:52 am   

2022-09-28 o 09:35 +0200, Atlantis napisał:

Chwalebnie... i ambitnie - bo trzeba samemu obsłużyć TCP, HTTP,
kilka popularnych kodeków, TLS... sporo warstw do przebicia.
Niemniej doceniam i rozumiem myśl. Też mnie denerwuje, że po włączeniu
"radia" muszę czekać niemal minutę na dźwięk.

Mateusz