eGospodarka.pl
eGospodarka.pl poleca

eGospodarka.plGrupypl.misc.elektronikalwIP - odbieranie danych przez TCPRe: lwIP - odbieranie danych przez TCP
  • Data: 2022-09-28 09:30:56
    Temat: Re: lwIP - odbieranie danych przez TCP
    Od: Atlantis <m...@w...pl> szukaj wiadomości tego autora
    [ pokaż wszystkie nagłówki ]

    On 27.09.2022 15:35, J.F wrote:

    > A tak swoja drogą - te radia działają na TCP ?

    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.

    > Bo chyba powinny na UDP ...

    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.


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

    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.


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

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


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

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

Podziel się

Poleć ten post znajomemu poleć

Wydrukuj ten post drukuj


Następne wpisy z tego wątku

Najnowsze wątki z tej grupy


Najnowsze wątki

Szukaj w grupach

Eksperci egospodarka.pl

1 1 1

Wpisz nazwę miasta, dla którego chcesz znaleźć jednostkę ZUS.

Wzory dokumentów

Bezpłatne wzory dokumentów i formularzy.
Wyszukaj i pobierz za darmo: