eGospodarka.pl
eGospodarka.pl poleca

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

    On 28.09.2022 10:52, Mateusz Viste wrote:

    > Chwalebnie... i ambitnie - bo trzeba samemu obsłużyć TCP

    Od tego jest stos. Generalnie projekt zaczynałem jeszcze na PIC24, potem
    przeniosłem go na PIC32. W obydwu przypadkach korzystałem już z nieco
    leciwych, ale całkiem fajnych bibliotek MLA (w ostatnich latach
    Microchip przestał je wspierać, zastępując środowiskiem Harmony). Ich
    obsługa jest bardzo prosta, trzeba tylko potrafić napisać odpowiednią
    maszynę stanów, ale taki sposób programowania mikrokontrolerów jest dla
    mnie najbardziej naturalny.


    > HTTP

    Tak naprawdę nie potrzeba pełnej obsługi HTTP. Inicjując połączenie za
    każdym razem wysyłamy takiego samego GET-a, z kilkoma podmienionymi
    polami (adres serwera i lokalizacja streama na serwerze). Dostajemy
    odpowiedź, którą trzeba przeparsować. Tutaj też nie ma konieczności,
    żeby implementować jakąś pełną bibliotekę do obsługi klienta HTTP.
    Wystarczy uwzględnić kilka odpowiedzi. Najważniejsze to 200 OK oraz
    przekierowanie pod inny adres. Wszystkie inne można uznać za błąd
    oznaczający konieczność zamknięcia połączenia (i ewentualnie podjęcia
    kolejnej próby).


    > kilka popularnych kodeków

    To w całości załatwia sprzętowy dekoder VS10xx. W przypadku
    software'owego podejścia de facto można by się ograniczyć do MP3
    (zdecydowana większość stacji nadaje właśnie w tym formacie) i tutaj
    sprawę załatwia popularna biblioteka libmad. Większość współczesnych
    32bitowych mikrokontrolerów powinna ją udźwignąć (u mnie nie miało z tym
    najmniejszych problemów Raspberry Pi Pico) jednak w przypadku tego
    projektu nie chciało mi się z tym bawić. Bibliotekę najwygodniej
    obsługuje się za pomocą wysokopoziomowego API, które wymaga RTOS-a (to
    znaczy nie wymaga, ale bez niego będzie nam blokowało pętlę główną) a
    niskopoziomowego jeszcze nie rozgryzłem.


    > TLS...

    To jest właśnie plan na dalszą rozbudowę projektu. W wersji na PIC32
    było to trochę kłopotliwe, bo biblioteka TLS z MLA jest dość leciwa. Da
    się ponoć wykorzystać wolfSSL-a, jednak jeszcze się w to nie wgryzłem. W
    przypadku STM32 dodanie tej funkcjonalności ogranicza się do wyklikania
    MBEDTLS-a w STM32CubeMX. To był jeden z powodów dla których w ogóle
    zacząłem eksperymenty z przeniesieniem projektu na STM32. Niestety nie
    wziąłem pod uwagę tego, że obsługa stosu będzie bardziej problematyczna.
    Niezbyt przemyślany był także wybór układu STM32F107, który ma
    stosunkowo mało RAM-u i nie ma nawet parametrów pozwalających na
    uruchomienie na nim MBEDTLS-a. Mam nadzieję, że w serii STM32F4 znajdę
    coś pinowo kompatybilnego, mającego wszystkie peryferia w tych samych
    miejscach, co pozwoliłoby mi wykonać łatwą podmianę. ;)

    Tak czy inaczej, na szczęście ciągle jeszcze całkiem sporo stacji
    internetowych nadaje po czystym HTTP. W tym właściwie wszystkie te, na
    których mi najbardziej zależało.


    > Niemniej doceniam i rozumiem myśl. Też mnie denerwuje, że po włączeniu
    > "radia" muszę czekać niemal minutę na dźwięk.

    Ten projekt tak naprawdę i tak jest trochę przesadnie skomplikowany, w
    celach edukacyjnych. Widziałem już w internecie znacznie prościej
    robione radia internetowe na ESP32. :)

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: