Diskuzní fórum Elektro Bastlírny

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?

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.

díky za rady

pro záčátek zkusím STM32F4DISCOVERY s rozšiřující deskou STM32F4DIS-BB. Samotný mcu by mělo mít nějakou MAC vrstvu v sobě a na rozšiřující desce je nějaký obdobný čip s převodem mii na ethernet.

A co pouzit nejaky hotovy modul, treba od Lantronixu? X-port?

Omlouvám se, že jsem nepochopil zadání
Budu o to víc sledovat další příspěvky

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

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

mohl bys mi prosím vysvětlit, jak si došel k tomu součtu 110 Mbit/s?

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.

a když to bude připojeno přímo na PC?

A navyse UDP paket moze len tak zahodit, ked ho nestihne spracovat.

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