V rámci projektu se potřebuju obecně seznámit s ethernetem. Ve výsledku bude použita gigabitová varianta s kombinací softcoru v fpgačku (UDP přenost dat), ale pro začátek si chci tuto technologii osahat s kombinací s ARMama od ST kvůli zkušenostem na 10/100 Mbit.
Mohli byste prosím doporučit s čím začít? Kolega mi doporučil kity s KSZ8091RNB, koukám, že docela letí obvody ENC28J60 atd. Jak zhruba se pak liší práce s ARMama, co mají už nějakou ethernet periferii vestavěnou?
Seznámení s ethernetem
Moderátor: Moderátoři
-
HiGhLaNdEr
- Příspěvky: 912
- Registrován: 08 bře 2005, 00:00
- Bydliště: Českobudějovicko
- Kontaktovat uživatele:
Doporučuju prostudovat OSI model.
ENC28J60 je kompletní síťová karta která řeší i mac vrstvu.
KSZ8091RNB je jen konvertor MII na ethernet. Musí mít u sebe něco co řeší tu MAC vrstvu.
Pokud má jednočip integrovanou MAC vrstvu a má MII tak bude použit KSZ8091RNB, pak softwarově nad tím už musí být jen tcp/ip obsluha protokolu.
ENC28J60 se hodí k jednočipum který nemaji integrovanou MAC vstvu.
https://cs.wikipedia.org/wiki/ENC28J60
Chová se to jako síťová karta v PC. má to zběrnici pro setup a data a nohu pro vyvolání přerušení od prijatých dat. Aby to jednočip mohl zpracovat v obsluze protokolu TCP/IP.
V podstatě stejně se bude chovat intergrovaná MAC vrstva v nějakém pokročilejším jednočipu.
Ty softwarově nebudeš řešit jaký máš jednočip. Budeš používat hotovou obsluhu TCP/IP pro daný jednočip. Je potřeba nastudovat jak funguje TCP/IP protokol.
ENC28J60 je kompletní síťová karta která řeší i mac vrstvu.
KSZ8091RNB je jen konvertor MII na ethernet. Musí mít u sebe něco co řeší tu MAC vrstvu.
Pokud má jednočip integrovanou MAC vrstvu a má MII tak bude použit KSZ8091RNB, pak softwarově nad tím už musí být jen tcp/ip obsluha protokolu.
ENC28J60 se hodí k jednočipum který nemaji integrovanou MAC vstvu.
https://cs.wikipedia.org/wiki/ENC28J60
Chová se to jako síťová karta v PC. má to zběrnici pro setup a data a nohu pro vyvolání přerušení od prijatých dat. Aby to jednočip mohl zpracovat v obsluze protokolu TCP/IP.
V podstatě stejně se bude chovat intergrovaná MAC vrstva v nějakém pokročilejším jednočipu.
Ty softwarově nebudeš řešit jaký máš jednočip. Budeš používat hotovou obsluhu TCP/IP pro daný jednočip. Je potřeba nastudovat jak funguje TCP/IP protokol.
Rozběhal jsem po několika dnech udp komunikaci a ještě s tím blbnu.
Zkoušel jsem orientačně změřit rychlost odesílání dat přes dobu provedení kódu (měřeno pomocí časovače plus dodatečné ověření přes togglovaní GPIO a měření časového intervalu přes logický analyzátor).
Mám něco takového (STM32F407VG@168MHz, Raw mode lwip):
500B užitečných dat na paket:
80Mbit/s - bez zpoždění
30Mbit/s - se zpožděním (80us)
200B užitečných dat na paket:
48Mbit/s - bez zpoždění
15Mbit/s - se zpožděním (80us)
Tedy mcu nic nedělá než odesílá bloky dat nebo ještě k tomu řeší krátké obsluhovací rutiny.
Mohli by ty hodnoty odpovídat reálu nebo jsem se někde hrubě sekl?
Na tyhle věci nemám ještě inženýrský odhad
Zkoušel jsem orientačně změřit rychlost odesílání dat přes dobu provedení kódu (měřeno pomocí časovače plus dodatečné ověření přes togglovaní GPIO a měření časového intervalu přes logický analyzátor).
Mám něco takového (STM32F407VG@168MHz, Raw mode lwip):
500B užitečných dat na paket:
80Mbit/s - bez zpoždění
30Mbit/s - se zpožděním (80us)
200B užitečných dat na paket:
48Mbit/s - bez zpoždění
15Mbit/s - se zpožděním (80us)
Tedy mcu nic nedělá než odesílá bloky dat nebo ještě k tomu řeší krátké obsluhovací rutiny.
Mohli by ty hodnoty odpovídat reálu nebo jsem se někde hrubě sekl?
Na tyhle věci nemám ještě inženýrský odhad
počítal jsem to bez hlaviček - vzal jsem délku dat v udp datagramu * 8 * počet odeslaných paketů / (doba trvání kódu * 1024^2 - převod na Mbit/s)
Wireshark hlásí u přijatých paketů bez dat IPV4 total length 28B, UDP část má délku 8B.
Zkoušel jsem ještě utilitku Jperf (echo tam a zpátky) a ta tvrdí při 200B/500B datech na paket maximálně 70 Mbit/s
Nevím jak to myslíš s tou obsluhou, ale používám zprovozněný lwip, který tyhle věci řeší za mě (aspoň myslím). Zachytil jsem wiresharkem protokoly ICMP, ARP od mcu kitu s korektní komunikací pokaždé, když změním mac adresu vrstvy
Wireshark hlásí u přijatých paketů bez dat IPV4 total length 28B, UDP část má délku 8B.
Zkoušel jsem ještě utilitku Jperf (echo tam a zpátky) a ta tvrdí při 200B/500B datech na paket maximálně 70 Mbit/s
Nevím jak to myslíš s tou obsluhou, ale používám zprovozněný lwip, který tyhle věci řeší za mě (aspoň myslím). Zachytil jsem wiresharkem protokoly ICMP, ARP od mcu kitu s korektní komunikací pokaždé, když změním mac adresu vrstvy
jak jsem psal, tak jsem měřil dobu provádění úseku kódu, kde jsem posílal třeba 1000 paketů s tím, že payload byl určité délky (200B nebo 500B) naplněný nějakým balastem.
Takže např pro 500B payload, 10 000 paketů jsem změřil dobu provádění 1100ms.
Takže (500B × 8b × 10000paketů) ÷ (1,1s * 1024²) ≈ 34,7Mbit/s - rychlost přenosu užitečných dat
Proto jsem nechápal, kde jsi sebral těch 110Mbit/s, protože když k těm 500B přičtu 28/32B z hlaviček upd+ipv4, tak se požadavky na rychlost zvýšej o jednotky Mbit a ne o desítky...aspoň podle mě
Jak jsem psal, tak jsem zkoušel ještě utilitku Jperf, ale čistě jenom jako echo -tam a zpátky pro tisíce opakování...předtím to bylo, že přišla udp zpráva, co spustila pak valení tisíců paketů s udp datagramy.
Jperf mi pak házelo různý rychlosti pro různou délku dat, ale víc jak nad 70Mbit/s jsem se nedostal
Specifikace tvrdí, že do ethernetového rámce se dá cpát nějak těch 1500B payload...jelikož v cílové aplikaci bude na aplikační vrstvě jednoduchej protokol, tak si nemůžu dovolit jakoukoliv fragmentaci payload v ethernetovém rámci. Proto jsem zkoušel těch 200 nebo 500B na udp datagram. Stále do toho pomalu pronikám, tak nevím jestli tvrdím blbosti, protože se setkávám s názory (ať podložené zdrojem nebo ne), že v praxi lze posílat max 512B payloadu bez fragmentace, jinde zas, že to číslo je kolem 200B atd.
Teď se přesouvám na hw/sw army (čistý cpu nebo softcore mcu) na fpgačkách (to bude masakr
), protože bude třeba řešit přenos dat kolem 200-400 Mbit/s. Tam chci taky zprovoznit něco podobného.
Takže např pro 500B payload, 10 000 paketů jsem změřil dobu provádění 1100ms.
Takže (500B × 8b × 10000paketů) ÷ (1,1s * 1024²) ≈ 34,7Mbit/s - rychlost přenosu užitečných dat
Proto jsem nechápal, kde jsi sebral těch 110Mbit/s, protože když k těm 500B přičtu 28/32B z hlaviček upd+ipv4, tak se požadavky na rychlost zvýšej o jednotky Mbit a ne o desítky...aspoň podle mě
Jak jsem psal, tak jsem zkoušel ještě utilitku Jperf, ale čistě jenom jako echo -tam a zpátky pro tisíce opakování...předtím to bylo, že přišla udp zpráva, co spustila pak valení tisíců paketů s udp datagramy.
Jperf mi pak házelo různý rychlosti pro různou délku dat, ale víc jak nad 70Mbit/s jsem se nedostal
Specifikace tvrdí, že do ethernetového rámce se dá cpát nějak těch 1500B payload...jelikož v cílové aplikaci bude na aplikační vrstvě jednoduchej protokol, tak si nemůžu dovolit jakoukoliv fragmentaci payload v ethernetovém rámci. Proto jsem zkoušel těch 200 nebo 500B na udp datagram. Stále do toho pomalu pronikám, tak nevím jestli tvrdím blbosti, protože se setkávám s názory (ať podložené zdrojem nebo ne), že v praxi lze posílat max 512B payloadu bez fragmentace, jinde zas, že to číslo je kolem 200B atd.
Teď se přesouvám na hw/sw army (čistý cpu nebo softcore mcu) na fpgačkách (to bude masakr
), protože bude třeba řešit přenos dat kolem 200-400 Mbit/s. Tam chci taky zprovoznit něco podobného.
omlouvám se...po ujasnění s kolegou jsem se dozvěděl, že aplikační protokol má část řešící pořadí zpráv. Pokud se něco ztratí, tak se to neřeší - jde o valení dat vybraný z AD převodníků, kde nemá cenu řešit nedoručené pakety.
Narážel jsem na problém fragmentace a až teprve vím, že z pohledu obsluhy se to neřeší-buďto se ztratí celý paket nebo část fragmentu.
Zkoušel jsem třeba echo na 1500-2000B a na některé pakety jsem dostával jak od serveru tak od mcu ICMP zprávy (Time-to-live exceeded, Fragment reassembly time exceeded).
Jak do toho pronikám, tak si říkám, jestli jsem neměl jít studovat IT
Narážel jsem na problém fragmentace a až teprve vím, že z pohledu obsluhy se to neřeší-buďto se ztratí celý paket nebo část fragmentu.
Zkoušel jsem třeba echo na 1500-2000B a na některé pakety jsem dostával jak od serveru tak od mcu ICMP zprávy (Time-to-live exceeded, Fragment reassembly time exceeded).
Jak do toho pronikám, tak si říkám, jestli jsem neměl jít studovat IT