Üdv!
Az lenne az alapprobléma, hogy egy speciális hálózatban működik a Realtek csip, ahol minden csomag broadcast (IP és MAC is) és pl a csomag 20-dik byte-ja jelöli a címzettet.Azt szeretném megoldani, hogy a 8019ből elöször csak azt az 1 byte-ot olvasom ki,ha nekem szól, kiolvasom a keretet, ha nem nekem akkor eldobom. A kérdésem az lenne hogy milyen módon valósítható meg, illetve megvalósítható-e egyéltalán.Segítségeteket előre is köszönöm
RTL8019 speciális csomagkiolvasás
Szerintem úgy lehetne megoldani, hogy a getpacket részben, még mielőtt elkezdi a teljes csomagot beolvasni, kiolvasod egy változóba a 20. bájtot, és ha az az ami neked kell, akkor elkezded kiolvasni a teljes csomagot, ha meg nem, akkor Call Write_rtl8019as(isr , &HFF) és kilépsz a rutinból! Ez az előbbi parancs nem biztos, de szerintem ez állítja a RTL csipet olyan állapotba, hogy fogadja a következő csomagot! Ha nem , akkor bocsi, és passz 
A Getpacketet át kell másolni a prociba (ha a M32-es programmintát használod az oldalról). Utána úgyis alaphelyzetbe rakod a chipet. A Getpacket esetén ugye a SRAMban otta teljes csomag már. Így a SRAM overlay at &H20-at megnézed neked szól-e. ha igen feldolgozod, ha nem, akkor kilépsz a megszakításrutinból.
Ha az ethernut rensdzert használod, ott a chip 1500 byte-s SRAM ablakon át látszik. Ott direktben meg tudod lesni, hogy neked szólt-e.
Milyen hálózat az ami Boradcast címekkel kommunikál? Csak kíváncsiságból...
Ha az ethernut rensdzert használod, ott a chip 1500 byte-s SRAM ablakon át látszik. Ott direktben meg tudod lesni, hogy neked szólt-e.
Milyen hálózat az ami Boradcast címekkel kommunikál? Csak kíváncsiságból...
ArtNet, legalábbis nekem egyenlőre broadcast csomagok jönnek. Ez egy, a színházi világítástechnikában használatos szabvány. a DMX rendszerek korlátainak áttörése miatt találták ki (kevés volt az 512 csatorna, ArtNet 40*512-t tud).Egyébként nem AVR-rel dolgozom, hanem 8051-el (DS89c450).A DMA-s módszert használom kiolvasásra, de lehet a párhuzamos kiovasás nekem előnyösebb lenne, csak arról még nemsok infót láttam, megnézem ethernut hogy van megoldva.
Így már fogram.
A DMX esetén a címzés télleg kicsit másabb, mint hagyományos ethernet esetén.
A 8051 szinte ugyanaz. Itt mondjuk az órajel lehet nálad érdekes (1 utasítás 12 órajel), de úgy tudom van már 125 MHz-s 8051 klón is... És a Bascom jó x51 procira is...
Az Ethernutban M128-as chip van, és külső SRAM. A Külső SRAM területre van be MAP-elve a RTL8019AS memóriaterülete. Még nem építettem meg, így a buktatókról nem tudok nyilatkozni - egyenlőre.
Az oldalon lévő WEBszerver is a DMA-sat használja, ez a leggyorsabb. A memóriabeágyazás után:).
A DMX esetén a címzés télleg kicsit másabb, mint hagyományos ethernet esetén.
A 8051 szinte ugyanaz. Itt mondjuk az órajel lehet nálad érdekes (1 utasítás 12 órajel), de úgy tudom van már 125 MHz-s 8051 klón is... És a Bascom jó x51 procira is...
Az Ethernutban M128-as chip van, és külső SRAM. A Külső SRAM területre van be MAP-elve a RTL8019AS memóriaterülete. Még nem építettem meg, így a buktatókról nem tudok nyilatkozni - egyenlőre.
Az oldalon lévő WEBszerver is a DMA-sat használja, ez a leggyorsabb. A memóriabeágyazás után:).
A Dallas 33MHz-en pörög és órajelenként hajtja végre az utasításokat(33MIPS),így talán a sebesség nem gond, viszont a főnököm a C
hallatán is problémázott, hátmégha basic-ben csinálnám. Már a forrás kb fele
Assembly, hogy így is optimalizáljak, viszont az a problémám hogy olyan 1,5-2Mbit/s sávszélességet elérve kifagy a hw és nem tudom mitől. Arra gondoltam, hogy nem tudolyan sok kérést kiszolgálni, bár ez mind olyan csomag amire nincs válasz(DMX adat) és talán rosszul kezeltem le a realtek tulcsordulását. Pontosan hogy kell Map-pelt üzemmódba állítani a 8019-et?mert amelyik ethernut-ot néztem (mega128-al) a forráskód szerint szintén DMA-val dolgozik és nekem 3 okból is jobb lenne a memory-map mód (1: gyorsabb,2: egyszerübben elérném azt a 2 byte-ot ami cimez jelen esetben,3: általában igy illesztem a perifériákat:)
hallatán is problémázott, hátmégha basic-ben csinálnám. Már a forrás kb fele
Assembly, hogy így is optimalizáljak, viszont az a problémám hogy olyan 1,5-2Mbit/s sávszélességet elérve kifagy a hw és nem tudom mitől. Arra gondoltam, hogy nem tudolyan sok kérést kiszolgálni, bár ez mind olyan csomag amire nincs válasz(DMX adat) és talán rosszul kezeltem le a realtek tulcsordulását. Pontosan hogy kell Map-pelt üzemmódba állítani a 8019-et?mert amelyik ethernut-ot néztem (mega128-al) a forráskód szerint szintén DMA-val dolgozik és nekem 3 okból is jobb lenne a memory-map mód (1: gyorsabb,2: egyszerübben elérném azt a 2 byte-ot ami cimez jelen esetben,3: általában igy illesztem a perifériákat:)
Az Ethernut kezeli le legegyszerűbben a chipet. Esetleg gyorsabb x51-t berakni?
Bascom alatt a következő, ha jól látom memoryMap:
http://members.home.nl/bzijlstra/softwa ... 8019as.htm
Az INT kezelés: 25-50 órajel, plusz sz utasítások. Így ha 33MIPS, akkor ha csak Intbe lépek és ki, az bizony:
33MIPS/50órajel=0,66MIPS. Ez bizony 660kMIPS.
8Mbit: az bizony 1 MByte/sec Hát nem hiszem hogy mikrokontrollerrel ennékl gyorsabbat el tudsz érni. Legalábbis amiket láttam, ott 1-2 Mbit/secig bírták lekezelni. És ekkor csak a fogadás van és nem csináltál semmit a csomaggal!
WorstCase: mi van ha 5 egymás utáni csomagban is valami tennivaló van? Ekkor amíg az első bejött csomagot dolgozod fel, az 5. már elveszett, mert a chip buffere elfogyott....
Szóval ide gyorsabb processzor kell mindenképpen....
Az hogy ASMban írod meg csak hajtépés. A C ugyanúgy fordít. Sőt optimalizálni is sokkal jobban mint amit Te tudnál. A Bascom picit pazarlóbb (5-25% - alkalmazásfüggő), de sokkal gyorsabb a fejlesztés.
Bár ha van a kifejlezstésre 3-5 éved, akkor ASM. Ha csak 1-2 hónap, akkor Bascom v. C.
Az ideális amúgy erre a feladatra én már ARM processzort raknék be (150-400 MIPS). A mikroproci kevés rá:(.
Bascom alatt a következő, ha jól látom memoryMap:
http://members.home.nl/bzijlstra/softwa ... 8019as.htm
Az INT kezelés: 25-50 órajel, plusz sz utasítások. Így ha 33MIPS, akkor ha csak Intbe lépek és ki, az bizony:
33MIPS/50órajel=0,66MIPS. Ez bizony 660kMIPS.
8Mbit: az bizony 1 MByte/sec Hát nem hiszem hogy mikrokontrollerrel ennékl gyorsabbat el tudsz érni. Legalábbis amiket láttam, ott 1-2 Mbit/secig bírták lekezelni. És ekkor csak a fogadás van és nem csináltál semmit a csomaggal!
WorstCase: mi van ha 5 egymás utáni csomagban is valami tennivaló van? Ekkor amíg az első bejött csomagot dolgozod fel, az 5. már elveszett, mert a chip buffere elfogyott....
Szóval ide gyorsabb processzor kell mindenképpen....
Az hogy ASMban írod meg csak hajtépés. A C ugyanúgy fordít. Sőt optimalizálni is sokkal jobban mint amit Te tudnál. A Bascom picit pazarlóbb (5-25% - alkalmazásfüggő), de sokkal gyorsabb a fejlesztés.
Bár ha van a kifejlezstésre 3-5 éved, akkor ASM. Ha csak 1-2 hónap, akkor Bascom v. C.
Az ideális amúgy erre a feladatra én már ARM processzort raknék be (150-400 MIPS). A mikroproci kevés rá:(.
nyilván nem irom át az egészet ASM-be,csak azokat amelyik erőforrásigényes illetve időkritikus.ezenkívül kevés válasz kell , vagy felküldés eth irányba, vagy fogadás. a leghoszabb keret is max 600byte, adni max 4-et kell 22ms-onként,fogadni szintén igy adóbuffernek elég 3k, vételnek meg marad 13. egyébként a gyári cuccokban egy PIC16 van és a hálón szabvány szerint csak artNet csomagok lehetnek.még vmi : a c jol optimalizál az igaz, de ha egyik függvényből meghivok egy másikat akkor stackbe pakol mindent,míg ha assemblyben progizok én pakolok a stackbe és csakazt amit használok.egyébként ne érts félre,nem ellenzem a c-t, sőt! de ahol van idő oda c-t használok, ahol időigényesebb a progi ott assembly (inline ass!) pl nem rtl_write(ISR,0xff); hanem:
asm
mov dptr,#ISR
mov a,#0x0ff
movx @dptr,a
endasm
elmarad a stackhivás(kb 8-10ut),és a ramot is kevésbé eszi, igaz több progmemet,de az van dögivel
asm
mov dptr,#ISR
mov a,#0x0ff
movx @dptr,a
endasm
elmarad a stackhivás(kb 8-10ut),és a ramot is kevésbé eszi, igaz több progmemet,de az van dögivel
azt el is felejtettem, hogy én csak egy 32 byte-os ablakot(08300-0x831F) látok a realteknek, a külső sramot a mega használja:
'Data Memory
'$0000-$001F 32 registers
'$0020-$005F 64 I/O reg.
'$0060-$00FF 160 Ext I/O reg.
'$0100-$10FF Internal SRAM
'$1100-$7FFF External SRAM
'$8300-$831F RTL8019as[/img]
'Data Memory
'$0000-$001F 32 registers
'$0020-$005F 64 I/O reg.
'$0060-$00FF 160 Ext I/O reg.
'$0100-$10FF Internal SRAM
'$1100-$7FFF External SRAM
'$8300-$831F RTL8019as[/img]
Ha 22 msec egy csomag, abba lazán bele kell férned, még DMA módban is. Nálam a M32@7372800Hz eseténa PING esetén - ami méri az időt - a válaszidő 2-3 msec volt (~7 MIPS). Ha soros kommunikáció volt kifele, az lefogta a chipet és így lett pár eldobott csomag (váalszidő felment nagyon). Valahol elölrébb írtam ilyen teszteket, hoyg hogy alakulnak a válaszidők terhelésfüggően. A PIC sebessége (16F 40MHz esetén 10MIPS csak! - jellemzően -20 MHz chipet használnak, ez 5MIPSt jelent!) Így a 22 msec ablakba illetve a feldolgozás bármiben gyakorlatilag beleférsz!
Az ASM a PIC lassúsága miatt van!
Azaz 7 MIPS megfelel mondjuk 5 msecnek (torlódás, bénázás stb) - 1 csomag válasza.
PIC 5 MIPS megfelel csak adatcsomag másolás feldolgozásnak éppenhogy. Ezért lehet itt kell a ASM rutin.
Nálad a 33MIPS meg baromisok, azaz szinte bármit tudsz közben csinálni. A SOROS kivitel lehet macera, ami megfogja a chipet.
Viszont a 10MBps és a 22 msec nem egyezetthető össze.
Vagy 10MBIT vagy 22 msec.
10MBIT 1400 byte-s TCPIPvel számolva:
10Mbit: 1.25 Mbyte/sec. 1 csomag 1400 byte: 892 csomag/sec, azzaz 1 csomag ideje: 1.1msec!
Szóval faltól-falig kitolva a sávot ciki. A sima PINGhez (fogadás: minimálfeldolgozás:visszaküldés) 7MIPS esetén 3 msec kell, akkor 1 msec idő esetén 3*7=21 MIPS kell. A 33 MIPS-ed ehhez is elég kell legyen....
A feldolgozással szálhatsz el valkahol időben. Mit csinál még chip amikor adatot fogad?
Az ASM a PIC lassúsága miatt van!
Azaz 7 MIPS megfelel mondjuk 5 msecnek (torlódás, bénázás stb) - 1 csomag válasza.
PIC 5 MIPS megfelel csak adatcsomag másolás feldolgozásnak éppenhogy. Ezért lehet itt kell a ASM rutin.
Nálad a 33MIPS meg baromisok, azaz szinte bármit tudsz közben csinálni. A SOROS kivitel lehet macera, ami megfogja a chipet.
Viszont a 10MBps és a 22 msec nem egyezetthető össze.
Vagy 10MBIT vagy 22 msec.
10MBIT 1400 byte-s TCPIPvel számolva:
10Mbit: 1.25 Mbyte/sec. 1 csomag 1400 byte: 892 csomag/sec, azzaz 1 csomag ideje: 1.1msec!
Szóval faltól-falig kitolva a sávot ciki. A sima PINGhez (fogadás: minimálfeldolgozás:visszaküldés) 7MIPS esetén 3 msec kell, akkor 1 msec idő esetén 3*7=21 MIPS kell. A 33 MIPS-ed ehhez is elég kell legyen....
A feldolgozással szálhatsz el valkahol időben. Mit csinál még chip amikor adatot fogad?
semmi mást nem csinál egyenlőre, annyi hogy ha csomag jön akkor led felvilllant (felkapcs+nop+lekapcs). szoval a dolog ugy van, hogy 1 dmx csatorna 250kbit/sec és ebből 40 csatorna közlekedik max a 10Mbites hálón, de miután max 4 csatornám lehet kifelé ezért a DMX pult nem tud küldeni nekem, csak 1Mbit/sec-kel (1 DMX csatorna 1 csomagja 44msec),viszont másik DMX eszközök is kapják a csomagokat ugyanazon a hálón, tehát ki lehet teljesen használva a 10megás sávszélesség. Azért lenne jó,ha párhuzamosan hozzáférnék a chiphez mert akkor egyből látnám ,hogy a keret nekem szól-e (nem IP, hanem Universe ID alapján). soros kimenetet majd valszeg CPLD vagy FPGA csinálja szintén memóriába ágyazva,vétel ugyszintén.
TCP nincs, csak IP+UDP. UDP-n van az ArtNet protokoll.
a 10Mbit és a 22msec pedig ugy egyeztethető, hogy a hálón mehet a 10Mbit/sec de abból nekem egy 22msec-es intervallumon belül csak 4 (max572byte-os ) csomag jöhet(egyébként a DMX egységek se birnák fogadni, illetve a DMX pult se ad többet).
egyébként se ping se arp, fix IP-kkel dolgozik a szabvány, amik a MAC-ből vannak számolva. de a probléma még mindig a párhuzamos olvasás megvalósítása a 8019ből. A végén az lesz hogy tiltom vhogy a realtek belső sramját és egy dualportos lesz kivülről ráakasztva azt már be lehet ágyazni
TCP nincs, csak IP+UDP. UDP-n van az ArtNet protokoll.
a 10Mbit és a 22msec pedig ugy egyeztethető, hogy a hálón mehet a 10Mbit/sec de abból nekem egy 22msec-es intervallumon belül csak 4 (max572byte-os ) csomag jöhet(egyébként a DMX egységek se birnák fogadni, illetve a DMX pult se ad többet).
egyébként se ping se arp, fix IP-kkel dolgozik a szabvány, amik a MAC-ből vannak számolva. de a probléma még mindig a párhuzamos olvasás megvalósítása a 8019ből. A végén az lesz hogy tiltom vhogy a realtek belső sramját és egy dualportos lesz kivülről ráakasztva azt már be lehet ágyazni
Re: RTL8019 speciális csomagkiolvasás
A segítségeteket szeretném kérni rtl8019 chip programozásával kapcsolatban.Van egy pár AT89s8252 és RTL8019 IC-vel panelom assemblyben szeretném a programot megírni.Kezdő vagyok.Tudtok-e ajánlani hozzá valamilyen segédanyagot ha lehet Magyar nyelvűt.A feladat az lenne hogy egy egyszerű webfelületen gombokra kattintva a soros porton RS232 vagy és RS485 re karakter sorokat küldeni minden gombnak más és vissza olvasni hogy a másik készülék vette-e ha igen át kell szinezni a gombot a webfelületen.Fix IP lehet.Köszönöm ha tud valaki segíteni.
Re: RTL8019 speciális csomagkiolvasás
Kiolvasható az RTL-ből, hogy hol kezdődik/végződik a csomag. Innen byte szinten kiszeded az adatot, ami neked kell. Majd a csomagot kiolvasod/eldobod.
Az RTL8019AS chip igen régi, ha ilyen alacsony szintű azonosítás van, akkor inkább az ENC28J60-at használnám.
Az RTL8019AS chip igen régi, ha ilyen alacsony szintű azonosítás van, akkor inkább az ENC28J60-at használnám.