-
Path: news-archive.icm.edu.pl!news.icm.edu.pl!news.man.poznan.pl!newsfeed.pionier.net
.pl!3.eu.feeder.erje.net!feeder.erje.net!news2.arglkargh.de!news.mixmin.net!new
sreader4.netcologne.de!news.netcologne.de!peer03.ams1!peer.ams1.xlned.com!news.
xlned.com!peer01.ams4!peer.am4.highwinds-media.com!news.highwinds-media.com!new
sfeed.neostrada.pl!unt-exc-01.news.neostrada.pl!unt-spo-a-02.news.neostrada.pl!
news.neostrada.pl.POSTED!not-for-mail
Date: Thu, 6 Oct 2022 09:47:27 +0200
MIME-Version: 1.0
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.13.0
Subject: Re: lwIP - odbieranie danych przez TCP
Content-Language: pl
Newsgroups: pl.misc.elektronika
References: <632f2939$0$455$65785112@news.neostrada.pl>
<6339401f$0$448$65785112@news.neostrada.pl> <thkbri$777$1@gioia.aioe.org>
From: Atlantis <m...@w...pl>
In-Reply-To: <thkbri$777$1@gioia.aioe.org>
Content-Type: text/plain; charset=UTF-8; format=flowed
Content-Transfer-Encoding: 8bit
Lines: 72
Message-ID: <633e8810$0$555$65785112@news.neostrada.pl>
Organization: Telekomunikacja Polska
NNTP-Posting-Host: 31.0.94.23
X-Trace: 1665042448 unt-rea-b-01.news.neostrada.pl 555 31.0.94.23:12032
X-Complaints-To: a...@n...neostrada.pl
X-Received-Bytes: 4629
Xref: news-archive.icm.edu.pl pl.misc.elektronika:774690
[ ukryj nagłówki ]On 05.10.2022 18:37, a...@m...uni.wroc.pl wrote:
> To by wskazywalo na zbyt male bufory/okno danych. Sprzet wyraznie
> moze pracowac szybciej, ale kontrola przeplywu TCP mu nie pozwala.
Które opcja w konfiguracji lwIP za to odpowiada? W stosie TCP/IP od
Microchipa po prostu ustawiało się parametr określający wielkość bufora
odbiorczego i nadawczego przy konfiguracji konkretnego socketu. W lwIP
nie widzę czegoś takiego niestety.
> Ja bym sprawdzil co sie dzieje jak wywalisz caly kod odpowiedzialny
> za dzwiek i zostawisz tylko odbior strumienia, ale potwierdzajac
> w takim tempie (w przyblizeniu) jak kodek by je odbieral.
Najbliższą rzeczą do tego jaką zrobiłem było wywalenie zapisywania
nadchodzących danych do bufora cyklicznego. I wygląda na to, że wtedy
leciały z maksymalną dostępną prędkością, odpowiadającą bitrate'owi
streama. Nie bardzo wiem natomiast jak w przypadku lwIP narzucić tempo
odpowiadające tempu zapotrzebowania na dane przez VS10xx. W przypadku
stosu od Microchipa było to proste - przychodzące dane trafiały do
bufora FIFO socketa, z którego mogłem je pobierać porcjami o dowolnej
wielkości. Jeśli dobrze rozumiem w przypadku lwIP i RAW API jest inaczej
- mam obowiązek przyjąć całą porcję danych zgłoszoną przez callback
odbiorczy, zwolnić pamięć i wywołać tcp_recved. Stąd potrzeba stosowania
bufora cyklicznego.
> Jeszcze moze glupie pytanie: w jakim tempie piszesz/czytasz ten
> RAM SPI? DMA powinno przerzucac dane z maksymalna predkoscia
> SPI, ale RAM moze miec porabany protokol a jak go obsluzysz
> przez software to moga byc straty predkosci.
Na chwilę obecną nie używam DMA - dane są po prostu przepisywane z
jednego miejsca w drugie w pętli. Myślałem, że SPI może powodować
opóźnienia, jednak tę hipotezę można już odrzucić ponieważ:
- Urządzenie zachowuje się identycznie w przypadku bufora cyklicznego w
ulokowanego pamięci SPI, jak również (mniejszego) w zwykłym RAM-ie.
- Żadne problemy nie występują w przypadku odtwarzania z karty SD.
> Pytanie kiedy potwierdzasz odbior: przed czy po zapisie do SPI
> RAM. Jesli po to potwierdzenie jest opoznione i efektywnie
> zmniejsza dostepne okno.
To tak można? ;) Myślałem, że tcp_recved() wolno mi wywołać dopiero po
przetworzeniu odebranych danych i zwolnieniu pamięci za pomocą pbuf_free().
> Pisales ze jest 6kB na bufory LWIP. To 4 pakiety maksymalnej
> wielkosci. Jesli 1 to wlasnie odbierany pakiet (nie wiem
6kB to chyba było odnośnie wcześniejszej wersji urządzenia,
zrealizowanej na PIC-u. Tam dość łatwo było ustawić konkretną wielkość
bufora odbiorczego.
> Piszesz o jakims "buforze audio". Nie wiem co to ma byc,
> ale datasheet VS1003 mowi o przesylaniu bloku 32 bajtow,
> czyli w zasadzie jesli jest portrzebny jakis bufor to
> na poziomie max setek bajtow. Czyli pownny byc dziesiatki
> kilobajtow wolnej pamieci: STM32F107 ma 64KB RAM.
Dodatkowy bufor na dane audio, pośredniczący w komunikacji pomiędzy
źródłem danych (Ethernet, lokalny nośnik pamięci) a VS10xx. Praktyka
pokazała, że jego zastosowanie dość mocno zwiększa stabilność, zwłaszcza
w przypadku Ethernetu. Implementowałem go do tej pory na jeden z dwóch
sposobów:
- klasyczny bufor cykliczny
- Dwuczęściowy bufor. Gdy jedna część karmi dekoder MP3, druga jest
ładowana danymi z zewnątrz. Potem następuje zamiana.
To właśnie tę funkcję w projekcie pełni pamięć SPI RAM.
Następne wpisy z tego wątku
- 06.10.22 17:18 J.F
- 07.10.22 20:40 Atlantis
- 09.10.22 08:25 Marek
- 09.10.22 10:19 Atlantis
- 09.10.22 14:45 Marek
- 10.10.22 10:36 J.F
Najnowsze wątki z tej grupy
- Elektryczna łapka i szerszeń
- moduł dtmf
- 0.5V
- Odbiór SDR na mikrokontrolerach
- Taki uziom....
- Nałożnica?
- ładowanie akku
- Mikrofala
- organy
- Zasilacz, regulacja prądu, oscylacje
- Tester akumulatorów ACT612
- HD44780 i urządzenia 3,3V
- Odbiornik Ania R-612 - wyniesienie anteny ferrytowej
- Ładny rewersik
- Polski satelita i rozdzielczość
Najnowsze wątki
- 2024-09-02 Re: RP3 kasuje wizy studentom/"studentom" po wylądowaniu na lotnisku
- 2024-09-02 Wzór
- 2024-09-01 Polska-Chorwacja 650zł elektrykiem
- 2024-09-01 odrdzewiacz do amelinium
- 2024-09-01 Elektryczna łapka i szerszeń
- 2024-09-01 Jakie podatki za wynajem?
- 2024-09-02 Warszawa => Key Account Manager <=
- 2024-09-02 Warszawa => Projektant/Programista React Native <=
- 2024-09-02 Gdańsk => Head of International Freight Forwarding Department <=
- 2024-09-02 Warszawa => Sales Development Representative (in German) <=
- 2024-09-01 1. wrzesnia po niemiecku
- 2024-09-01 Od setki do setki...
- 2024-08-31 wpadłem w siodło
- 2024-08-25 cenka opada
- 2024-08-30 Elektryki takie bezpieczne cd.