STM32F4 LWIP rychlost
Jaroslav Buchta
jaroslav.buchta na hascomp.cz
Neděle Duben 21 12:50:12 CEST 2013
Je to jen priklad co jsem nasel a zda se mi sympaticky jednoduchy, tyto
namety samozrejme zohlednim, diky ;-)
Dne 21. 4. 2013 12:33, Marek Sembol napsal(a):
> Respektive - podival jsem se do dokumentace na ReceiveFrom a ten port
> 0 je zda se OK, ale musite si ten socket nabidnovat pomoci Bind
> Marek
>
>
> 2013/4/21 Marek Sembol <hwm.land na gmail.com <mailto:hwm.land na gmail.com>>
>
> Tak jen tak na prvni pohled:
> a) ten prvni new Byte[1024] je zbytecny, ten Encoding si naalokuje
> sam (nepodstatny detail)
> b) jste si naprosto jisty, ze bude fungovat ReceiveFrom s portem
> 0? Mne se to moc nezda (ale hadat se nebudu).
>
> Marek
>
>
> 2013/4/21 Jaroslav Buchta <jaroslav.buchta na hascomp.cz
> <mailto:jaroslav.buchta na hascomp.cz>>
>
> No funguje to divne... Jeste me napada, jestli za to nahodou
> nemuzou Win8... Kazdopadne po odeslani bajtu to prijima, po
> nejake dobe ne, pak poslu prikaz - odpoved neprijme a po
> dalsim prikazu uz odpoved prijme. Kdyz to zkousim z Hercules
> terminalu, tak to funguje jak z praku. Navic na pouziti
> UdpClient snad neni co zkazit, proste new UdpClient(lokalni
> port), a pak by IMHO hned melo fungovat Receive a ono prd. Ani
> v ruznych variantach, kdy v konstruktoru pouziju EndPoint s
> Ipaddress.Any atd.
>
> Kdyz bych pouzil primo Socket treba podle tohoto prikladu, je
> tam nejaky zadrhel? (ted nejsem na compu kde bych to mohl
> zkusit, protoze popijim pivo na zahrade ;-) )
>
> {
> *byte*[] data = *new **byte*[1024];
> string input, stringData;
> IPEndPoint ip = *new *IPEndPoint(IPAddress.Parse("127.0.0.1"),
> 9999);
>
> Socket server = *new
> *Socket(AddressFamily.InterNetwork,SocketType.Dgram, ProtocolType.Udp);
>
> string welcome = "Hello";
> data = Encoding.ASCII.GetBytes(welcome);
> server.SendTo(data, data.Length, SocketFlags.None, ip);
>
> IPEndPoint sender = *new *IPEndPoint(IPAddress.Any, 0);
> EndPoint Remote = (EndPoint)sender;
>
> data = *new **byte*[1024];
> *int *receivedDataLength = server.ReceiveFrom(data, ref Remote);
>
> Console.WriteLine("Message received from {0}:", Remote.ToString());
> Console.WriteLine(Encoding.ASCII.GetString(data,
> 0, receivedDataLength));
>
> server.Close();
> }
>
> Vypada to jednoduse a premyslim, v cem je zadrhel. Myslim, ze
> vzhledem k pozadavku na vetsi objemy dat, cim na nizsi level
> pujdu, tim lip... A se siti jsem v .NET jeste nedelal.
>
> Dne 21. 4. 2013 10:39, Marek Sembol napsal(a):
>> no mne to chovani prijde minimalne hodne zvlastni a asi bych
>> intenzivne hledal chybu u sebe. Pripadne bych opustil
>> UdpClient a pracoval primo se Socket. Ale fakt si myslim, ze
>> za to .NET nemuze. Podle mne trida Socket pouze zabali WinAPI
>> a UdpClient "zjednodusi" pouzivani Socket (spolu se
>> specializaci na UDP a radou omezeni)
>> Marek
>>
>>
>> 2013/4/21 Jaroslav Buchta <jaroslav.buchta na hascomp.cz
>> <mailto:jaroslav.buchta na hascomp.cz>>
>>
>> Ajo vidite, Close, to me nenapadlo ;-) Zkusim. Ale stejne
>> to casem asi udelam ve Win API, kdyz s tim polem bytu
>> nebude problem.
>>
>> Dne 21. 4. 2013 10:12, Marek Sembol napsal(a):
>>> vyjadrim se jen castecne:)
>>> Pokud pri tom volani z C# -> WinAPI ty "velke objemy
>>> dat" jsou Byte[], tak ta konverze je prakticky zadarmo.
>>> .NET si to pole proste jen prispendli v pameti a preda
>>> dal ukazatel.
>>>
>>> Synchronni vs. asynchronni - no tady se to asi nebude
>>> chovat rozdilne. Ono to synchronni volani byva proste
>>> jen par volani BeginAsyncXXX a EndAsyncXXX.
>>>
>>> Aplikace se samozrejme ukoncit da. Staci treba zavrit
>>> ten socket a volani prijmu skonci na vyjimku (a tu je
>>> mozno osetrit, ze). Moznosti jak ten socket zavrit je
>>> cela rada. Jako rekce na CTRL-C (pri konzolove
>>> aplikaci), jako reakci na service-stop (pri service),
>>> jako volani naschedulovane pomoci timeru (kdykoliv) a
>>> podobne.
>>>
>>> Marek
>>>
>>>
>>> 2013/4/21 Jaroslav Buchta <jaroslav.buchta na hascomp.cz
>>> <mailto:jaroslav.buchta na hascomp.cz>>
>>>
>>> Diky za namety, zarizeni zda se funguje docela
>>> zpusobne, co nefunguje podle predstav je trida .NET
>>> UdpClient na PC - proste pokud neodeslu aspon bajt
>>> na zarizeni, nic neprijme a i potom za nejaky
>>> timeout chcipne a pomuze az odeslani dalsiho byte
>>> aby zase bylo neco prijmuto - nic jineho takze port
>>> atd. je asi nasteveno spravne... Neni nejaka option,
>>> kterou jsem zatim nepostrehnul, aby to fungovalo
>>> primitivne a jen cekalo, az na port neco prijde???
>>> Zkousel jsem uz vsechny mozne varianty synchronni
>>> (tam je vtipne, ze Receive nema zadny timeout a
>>> aplikace se nakonec ani neda ukoncit...) i
>>> asynchronni. C# je dobre asi fakt jen na GUI...
>>>
>>> Co zatim hledam, tak jsou s touto tridou jen
>>> problemy - je jina cesta nez pouzit DLL kde to bude
>>> realizovano jako WinAPI (coz by snad mohlo
>>> fungovat...) Zase konverze velkych objemu dat do C#
>>> pak bude asi narocna na rezii...
>>>
>>>
>>>
>>>
>>> Dne 21. 4. 2013 9:35, Ondrej napsal(a):
>>>
>>> Někde v lwipopts.h jde nastavit max. velikost
>>> paketu. 1400B je velikost paketu (náhoda :-) -
>>> takže by se někde měla ještě povolit
>>> fragmentace. Ale 100% jistý si tím nejsem.
>>> Nicméně zrovna ST má pěkné PDF s návodem na
>>> lwip. Byly tam myslím i nějaké testy rychlosti.
>>>
>>> Add: ztrácení paketů: Nainstalujte si Wireshark
>>> a zkontrolujte, jestli jsou pakety tam. To je
>>> naprostý základ. Je docela slušná šance, že ST
>>> odesílat stíhá a nestíhá přijímat jen program.
>>> Ono obecně odeslat UDP paket není problém a to i
>>> na velkých rychlostech. Obvykle je problém pak
>>> data napřijímat (ať už v PC nebo na uP).
>>>
>>> Jinak UDP fragmentace smysl má a to velký. Pro
>>> velké toky je problém přijímat 1400B pakety, ale
>>> pokud je fragmentuje třeba na 14000B (10x
>>> větší), tak u to může PC stíhat. Už jen třeba
>>> protože "callback" fce./přerušení se bude volat
>>> 10x méně často.
>>>
>>> Ondřej
>>>
>>> Dne 20.4.2013 22:54, Jaroslav Buchta napsal(a):
>>>
>>> Mate nekdo zkusenost jak na to? Jednak jsem
>>> zjistil, ze je nekde omezena velikost UDP
>>> paketu proste tak, ze pri prekroceni to
>>> poskodi haldu a cele to jde do kytek,
>>> hranice je nekde kolem 1400B
>>> Dal je zajimave, ze kdyz odesilam pakety
>>> bezprostredne za sebou, ztraceji se (ale az
>>> od nejakeho poctu a zalezi na delce) a kdyz
>>> treba ted za kazdy 4. vlozim pauzu 1ms tak
>>> to funguje OK (cili rychlost 4MB/s stabilne,
>>> coz mi prijde OK, samozrejme prime pripojeni
>>> do pocitace)
>>> Otazkou je, jestli se pakety ztraci u STM
>>> nebo na strane PC... Ale na PC je gigabit,
>>> to by snad melo byt slusne dimenzovane.
>>> Dalsi zahada je u C# s UdpClient, dokud
>>> aspon bajt nevyslu, nic neprijmu (i kdyz
>>> data na port prokazatelne chodi, overeno
>>> hercules terminalem). To jsem v dokumentaci
>>> nikde nenasel, melo by to snad fungovat pro
>>> prijem bez volani Connect a Send, ne?
>>>
>>> Jinak teda s rychlosti spokojenost, mozna by
>>> to slo i o chlup vyse, prilezitostne
>>> vyzkousim. Taky by asi pomohlo zvysit delku
>>> paketu - vi nekdo jak na to? Pochopil jsem,
>>> ze jsou ruzne metody alokace pameti v LwIP.
>>> _______________________________________________
>>> HW-list mailing list - sponsored by
>>> www.HW.cz <http://www.HW.cz>
>>> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>
>>>
>>> _______________________________________________
>>> HW-list mailing list - sponsored by www.HW.cz
>>> <http://www.HW.cz>
>>> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>
>>>
>>> _______________________________________________
>>> HW-list mailing list - sponsored by www.HW.cz
>>> <http://www.HW.cz>
>>> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> HW-list mailing list - sponsored bywww.HW.cz <http://www.HW.cz>
>>> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>>> http://list.hw.cz/mailman/listinfo/hw-list
>>
>>
>> _______________________________________________
>> HW-list mailing list - sponsored by www.HW.cz
>> <http://www.HW.cz>
>> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>> http://list.hw.cz/mailman/listinfo/hw-list
>>
>>
>>
>>
>> _______________________________________________
>> HW-list mailing list - sponsored bywww.HW.cz <http://www.HW.cz>
>> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
>> http://list.hw.cz/mailman/listinfo/hw-list
>
>
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz <http://www.HW.cz>
> Hw-list na list.hw.cz <mailto:Hw-list na list.hw.cz>
> http://list.hw.cz/mailman/listinfo/hw-list
>
>
>
>
>
> _______________________________________________
> HW-list mailing list - sponsored by www.HW.cz
> Hw-list na list.hw.cz
> http://list.hw.cz/mailman/listinfo/hw-list
------------- další část ---------------
HTML příloha byla odstraněna...
URL: <http://list.hw.cz/pipermail/hw-list/attachments/20130421/958d5050/attachment.htm>
Další informace o konferenci Hw-list