Az Ethernetnek kötelezően van saját külső órajele, ezért nincs neki oszcillátora. Arról megy az egész MAC blokk.
Szerintem a leglényegesebb alsó korlát az lehet, hogy vétel közben a DMA képes legyen betolni az SRAM-ba a vett adatokat. Ez 10Mbps esetén (ha csak a DMA használhatná a memória buszát) 32bit -> 320ns -> 3.125MHz-es minimum buszsebességet jelentene. 100Mbps esetén meg 10x ennyit. Nyilván ennyivel még nem fog működni, hiszen a CPU feldolgozóegysége is igényel sávszélességet.

Fény derült a rejtélyre, köszönöm.

Amúgy butaságot írtam: 10Mbps esetén 100ns-onként jön egy bit, szóval 32 bit az 3.2us, azaz 312kHz, és 100Mbps-nél lesz 3.125MHz.

Sziasztok!
Szenvedek a Stack-el, nagyon kényes. Próbálok mellé illeszteni egy USART kommunikációt. Már ott elakadtam, hogy ha nem bájtonként megszakításdban veszek, küldök, akkor már 25bájt egyben vétele problémát okoz a StackTask() időzítésében. Igyekeztem a helpben erről infót keresni, de konkrét időket nem találtam. Ha tudtok erről valamit, kérem írjátok meg!
Jelenleg valahogy működik, de időnként kiakad még így is. POST módban küldök egy ajax kérést, amire 23 változót küld válaszként egy xml-be a HTML/Javascript program. Eközben USART-on veszek 50bájt körüli csomagot, amit megjelenítek a válaszon keresztül az oldalon.
Lehet, hogy nem az időtúllépés a gond, de jelenleg ezt szeretném kizárni, ha lehet.
Minden más fontosnak gondolt infót is szívesen veszek a Stack-el kapcsolatban!
Köszi!

A POST hatására indítasz valamit, aminek az eredményét kapod vissza a soros porton, és azt akarod a POST-ra válaszként visszaadni? Ez nem túl szerencsés megoldás. Én inkább azt csinálnám, hogy aszinkron legyen a művelet: a "művelet indítása" c. POST hatására elindítod a folyamatot, és visszaadod a választ, hogy "elindítva", majd utána a böngésző időnként megkérdezi egy "mi a státusz?" c. GET kéréssel, hogy hol tart az eredmény. A soros porton jövő választ természetesen interruptban fogadod, az eredményt letárolod a memóriában. Amikor jön a "mi a státusz?" c. kérés, akkor a memóriából szolgálod ki.
Az AJAX amúgy nagy barátja a JSON nevű formátumnak, ami "tisztább, szárazabb érzés" az XML-hez képest.

Szia!
Nem. Sorosan jön időnként egy csomag, amit ajax POST kérésre adok válaszul a böngészőnek, amit js kezel le XMLHttpRequest módszerrel.
A GET-el az a baj, hogy az IE nem jól kezeli a karakterkódolást, nemrég beszéltünk erről...
A JSON-t megnézem, de nem hiszem, hogy ezen múlna.

A soros vonalon jövő byte-okat mindenképpen interruptból kell fogadni, és persze amikor éppen nincs mit olvasni, akkor nem állhatunk meg az ISR közepén, hogy megvárjuk a következőt.
Logikusan a beérkezett dolgokat letárolod valami memóriaterületre, és a POST kérést ebből tudod kiszolgálni. Nem látok indokot arra, hogy ez ne működjön normálisan.
Az XML/JSON a problémád szempontjából mindegy, csak megemlítettem.
A GET/POST kérdéskör pedig szintén nem befolyásolja ennek a működését, azt használod, amelyik előnyösebb.

Igen, pont ez a bajom, hogy ez így történik, még is időnként belefagy a StackApplications() -> HTTPServer() rutinba. Próbálom kideríteni miért. Ehhez debuggolni kéne, de ez nem túl egyszerű és egyébként se szeretném, mert az a PIC, amit használok 1000x írható, így kicsit féltem.
Jelenleg változtattam a gyári megoldáson, egy Timer3 megszakításban pollingolom az egyébként main loop-ban lévő rutinokat, hogy biztosan rájuk kerüljön a sor időszakonként. Ez már az USB stack-nél bevállt. Így sikerül elkülöníteni, hogy hol fagy ki, mert benne marad a megszakításban, néhány LED-el követhető. Kicsit időigényes. Az érdekes lehet, hogy nem azonnal fagy ki, van mikor percekig jól működik.
Köszi, hogy foglalkoztál a kérdéssel!

Arra sikerült rájönnöm, hogy a megszakításból nem lehet pollingolni a rutinokat, mert az időzítésük az alacsony megszakításban futó timertől függ, ami nem fut le, ha nem ér ki valamelyik rutinból a stack, ha az a magas megszakításban kezelődik le és ott ragad.
A bonyolultság miatt nem tudom leírni, mi mindent módosítottam, de most úgy néz ki jobb lett, azaz egy ideje nem fagyott le.

Sokat szenvedek a kapcsolat szakadása miatt. Először azt hittem, én szúrok el valamit, de visszatöltöttem a gyári demót, ami belső hálón keresztül szépen megy, de kintről meghívva ugyanúgy lefagyogat, néha feléled, megy egy darabig, majd újra leakad, előfordul, hogy végleg.
Nincs valami ötletetek, hogy mitől lehet ez?

Hogyan hívod meg kintről? Valami routered van, és port-forwardingot használsz?

Igen. Az is lehet, hogy a szolgáltatónál van valami problem. Rajta vagyok ezen is...

Ha belső hálón stabilan megy, akkor nem valószínű, hogy a PIC-el lesz a probléma. Vagy a router szórakozik, vagy a szolgáltató. Vagy egyik sem, csak az internetről eleve nagy forgalom áramlik a géped felé (mindenféle portscan, ipscan, stb.), és mivel gondolom meghagytad a kontrollert a 80-as porton, ezért egyszerűen megfojtja a forgalom. Első körben állítsd át valami nagyobb számú portra, és nézd meg úgy, mi történik.

Köszönöm a tippet, kipróbálom!

Ha megadom az új portot az IP után (192.168.0.108:89) akkor megy(igaz így is kiakad gyorsan, amit én írtam oldalt, majd kicsit később magához tér stb.). Lehet átirányítani portra valahogy egy IP hívást? Vagy hol kell még beállítani valamit az ETH97.h-n (HTTP_PORT) kívül, hogy a beállított port legyen az alapértelmezett?

Függetlenül a tapasztalt jelenségtől (aminek vagy van ehhez köze, vagy nincs) az a nagy igazság, hogy szerintem ezek a KB-ban mérhető belső memóriával rendelkező mikrokontrollerek nem igazán nyerőek ilyen célokra úgy általában.
Több szituáció is van, amit nehéz értelmesen kezelni rajtuk:
- erőforráskorlátok: ha bárki válogatás nélkül el tudja érni, akkor nem tud hatékony stratégia lenni bennük arra az esetre, ha valaki elkezdi igénybevenni a mikrokontroller szűkös erőforrásait (pl. szimplán csak TCP kapcsolatokat kezd nyitni, és ennyi); erre lehet az megoldás, hogy egy VPN mögé dugod, azaz még TCP kapcsolatot se tudjon rájuk nyitni az, akit nem authentikált valami eszköz már korábban,
- erőforráskorlát + TCP RTT: a korlátozott memóriaméret miatt a TCP window nem tud nagy lenni, a TCP window méret * az RTT értéke pedig egy felső korlátot ad a mindenkor elérhető maximális sávszélességre; ez LAN-on kívül azért zavaróan alacsonnyá is válhat,
- hibakezelés: a TCP működésében kritikus tényező az újraküldés kezelése, mind a küldőnek, mind a fogadónak korrektül kell a szabványt implementálnia, különben csomagok vesztése esetén nagyon lelassul a kommunikáció; ha bugok vannak a TCP stack működési logikájában, akkor előfordulhat, hogy LAN-on még nagyjából működik, hiszen ritkán vesznek el csomagok, míg távolabbról már problémás lesz, és egy-egy elveszett csomagnál megfagy teljesen a kommunikáció.

Szia! Sok űr van még nálam a témában, de szerintem a TCP stack a ludas. Belső hálón próbálva is gázos. Elmegy egy kérés POST formában, majd erre válaszol egy csomaggal, amit a program szerint egyenként tölt fel az XML-be (void HTTPPrint(DWORD callbackID) HTTPPrint.h) egy switch ágait ütem szerint meghívogatva. Ha egy bizonyos kritikus ponton megszakad a folyamat(pl. egy megszakítás), belefagy az egészbe. Ha frissítem az oldalt, megint működik egy darabig. A pontot nem tudom elcsípni, mert nem szó szerint fagy le, akkor a frissítést sem tudná fogadni, csak a kapcsolat szakad meg. Bevallom nem tiszta milyen kapcsolat van itt, egyáltalán hogyan folyik a kommunikáció bájt szinten, ebbe sokkal jobban bele kellene ásnom magam, de reméltem, hogy erre nem lesz szükség (ettől kellene megmentenie egy gyári stacknek, nem? ) . Bele kell ásnom magam az egész lelkébe, de még az elején vagyok, sok a zűrzavar a fejemben...

Szerintem kb. egy rendes oprendszer (pl. egy Linux) van azon a szinten, hogy megmentsen teljesen a TCP stack problémáitól. Ott van elég erőforrás ahhoz, hogy mindenféle "hack" nélkül korrektül lehessen implementálni a szabványt, és ott van reálisan annyi tesztelési emberév beleölve, hogy zökkenőmentesen menjen.
A kliens oldalra kell egy tcpdump/wireshark, abból általában látszik, hogy melyik ponton áll meg a kommunikáció.

Jelenleg egy button-al hívom meg az ajax függvényt, ami elküldi a POST csomagot, de a PIC ezt már nem veszi észre. Az MPLAB-ban nem látom az ethernet puffert, illetve nem tudom hogyan lehetne belenézni. Csatolom a fájlokat, amikkel most próbálkozok. A JavaScript a gyáriból átemelve működik(amit én írtam, azt hittem hibás, de ez ugyanúgy gázos, talám még jobban is).

Azt hiszem akkor akad ki, amikor a callback közben a válaszokat küldi és ez megszakad. Próbálok valami jelzőt betenni, hogy a folyamat során ne történjen megszakítás. Annyiban jelent ez gondot, hogy nem egy körben kerül elküldésre az adat. Nem is értem, hogyan áll ez össze az xml-be?

Ez se jött be, kicsit jobb, de így is leakad.

Néztem a Whireshark-al, a böngésző nem küldi el a gomb nyomására a csomagot. Legalább is ha jól gondolom, hogy az elküldött kérés akkor is látszik, ha nem érkezik rá válasz.

Ezt ki tudod úgy próbálni, hogy kikapcsolod a picet, és megnézed, úgy látszik-e a böngésző adatküldése.

A wireshark minden egyes Ethernet csomagot megmutat. Praktikus lenne viszont olyan HTML/AJAX/Javascript kódot használni, amit előtte PC-n (= nem PIC-es webszerverrel) kipróbáltál...

Hogyan lehet szűrni, hogy csak az a forgalom jelenjen meg, ami a szerverrel kapcsolatos?

Szia!

Pl. beírod a Filter sorba a következőt:

ip.src == 192.168.0.2

vagy éppen ezt:

ip.dst == 192.168.0.2

Aztán végül mellette az "Apply" gomb.

Sziasztok!

Microchip WIFI G Demo board-dal (DV102412, PIC32) kapcsolatban van tapasztalatotok? Bekapcsolom, kettot-harmat villog a zold LED es lerohad. Amikor megvettuk, nem ment. Visszavittuk a csipkedbe, ott mukodott, utana itthon is. Rejtély. Egy hetig nem nyultunk hozza, most megint rossz. Elem jo, tapot mertem szkoppal a radio modulon, nem rogyik meg, semmi gond. Tudtok errol valamit? Masik kerdes, hogy az ebbe a modulba gyarilag egetett sw forrasa honnan szerezheto meg? A neten nem talaljuk sehol, a microchip-nel nincs meg, csak a nem G-s modulhoz valo.

Elore is koszi,
Andor

De a kettot kombinalhatod is:

ip.src == 192.168.0.2 || ip.dst == 192.168.0.2

Igy minden csomagot latsz, ami errol vagy erre az IP-re jon/megy.

De a tcp.source == 80 is hasznos lehet. Zarojelezhetsz, van && || operator.

Szuper, köszi mindkettőtöknek!

Sziasztok!

Apróhirdetésbe tedd.