STM32F4 LWIP rychlost
Jaroslav Buchta
jaroslav.buchta na hascomp.cz
Neděle Duben 21 12:10:50 CEST 2013
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 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/4eb58d09/attachment.htm>
Další informace o konferenci Hw-list