Milyen hosszúak voltak a vezetékek a modul és a kontroller között?

A vezeték egy sima szalagkábel volt olyan 8cm.
A pic paneljén pedig még plusz 2 cm szakaszon ment a pictől a kábelig.

Milyen órajeleket használtatok? 2,5MHz?
Nézegettem az adatlapját, jó kis illesztő...

Mivel nekem ilyen modulom van: Link, ezért kötött az órajel. Muszáj RMII-t használni, ami 50MHz-en megy (menne).

Vagy milyen órajelre gondolsz?

A nagysebességű vezetékekre a modul és a PIC közé raktál ~33ohm soros ellenállásokat, ahogy a PIC32 Ethernet Starter Kit kapcsolásán is látható?

A TP-LINK WR703N minirouternek van UART és USB portja is. Olyan mikrovezérlőt illeszthetsz tehát hozzá, amit akarsz. A perifériáidat elkezelgetheti a PIC, a hálózati protokolt, vagy a nagy teljesítményigényű feldolgozást végezheti a router. Nekem $18.50-ért sikerült megcsípni egyet, de 22-25 USD áron mindig kapható. Nyilván, nem ahhoz a feladathoz való, amit PIC1867J90-nel meg tudsz oldani, hanem olyanokhoz, amelyek nagyobb igényűek.

Pl. Wifi kapcsolat, nagyobb számítási- vagy memóriaigényű alkalmazások...

A TX_CLK és az RX_CLK ha 2,5MHz, akkor a kiolvasás sebessége a 4bites busz miatt 10Mb/s, ha 25MHz, akkor 100Mb/s. Képes a PIC32 ilyen órajelet előállítani úgy, hogy fel is tudja dolgozni(legalább pufferre pakolni) a fogadott adatokat? Én 2,5MHz-el használnám, de az igaz, hogy nagyon felületesen ismerem ezt a konfigurációt!

Szia! Igen, nagyobb feladatokhoz való. A PIC, egy kis ház monitorozásra, készülék távoli kezelésére, bőven jó és sokkal megbízhatóbb. Torrentezni nem jó!

Úgy könnyű! De hogy lesz olcsóbb? (persze, ha csak arra akarom használni, amire a PIC még alkalmas.)
Engem csak az zavart kicsit, hogy a topic címe adja, hogy itt PIC-el akarjuk megoldani. Ha nem azzal akarnánk, akkor más lenne a neve.

Valami ilyesmit kerestem régóta, ez már majdnem az, de persze ez sem tudja igazán ellátni azt a funkciót, amire én vágynék:
- fusson rajta az openwrt erőlködés nélkül
- legalább 32MB RAM (de inkább 64 vagy 128)
- legalább 8MB flash (de az is jó, ha ki tudom cserélni, csak értelmesen hozzá lehessen férni hőlégfúvóval)
- 10/100Mbps Ethernet (az se baj, ha gigabitet is tud)
- USB FS eszközöket támogató USB host interfész
- valami értelmesen kivezetett GPIO (optimális esetben hardveres I2C és SPI is)

Ez utóbbi két sorból minimum az egyik kell, hiszen ha csak USB-n tudom illeszteni a saját cuccokat hozzá, és ehhez USB HS eszközt kell használnom, akkor ott vagyok, ahol a part szakad, ha meg egy USB hubot is még bele kell rakni az egyenletbe, az szintén gázos...

Ja, és az egész kóceráj ne kerüljön 10 rugóba, de inkább legyen közel az 5-höz.

Nagyobb számítási kapacitást igénylő feladathoz szerintem inkább Raspberry Pi vagy hasonló mini számítógépet használnék.

Az lehet, hogy kimaradt. Nemsokára megyek haza és akkor próba.

Itt a modul rajza, amit kezelgetek. Ehhez már csak a picet kell "hozzádrótozni" és megy is, ha jó a program.

Annyit még majdnem elfelejtettem, hogy nekem ki kellett még kötnöm a 41-es lábat (RX_ER/MDIX_EN) a csatira, mert az gyárilag nem volt kivezetve.

2 bit(RX és TX 0 és 1) van csak használva és az órajelek nem is kellenek? Hogyan működik így?

Elvileg, ha jól értelmezem a doksi 22. oldalán a 3.2-as részt, akkor ezeknek a lábaknak a bekötése elég. Legalábbis RMII módnál.

Köszi! Akkor ezek szerint ilyenkor 50MHz az órajel és két biten megy a kommunikáció. Ez azért elég magas freki, hogy egy PIC fel tudja dolgozni nem? Vagy nem jól értek valamit?

Igen, ha jól értelmezem a doksit, akkor ez a helyzet.

Órákig ment a kommunikáció a teszt alatt, egy alkalommal sem volt gond vele. A tcp klienst használtam benne, ezzel egy számítógépen futó szerverre csatlakoztam és oda vissza adatokat mozgattam órákig. Bár az is igaz, hogy mivel csak vezérlési feladatokra tervezem használni így igazán nagy adatátvitel nem jelentkezik rajta. (Pár kilobyte/s maximum)

Az Ethernet hardver egy része benne van a picben, csak a fizikai illesztőt kell csatlakoztatni kívülről, hogy akár drótnélküli, akár optikai hálózathoz is csatlakoztathasd a picet. Tehát belül hardveresen elintéz egy csomó dolgot, kb. mint az USB is.

Én 18F87J60-at használok, abban benne van minden, csak trafó kellett. A te 32-esedben nincsen? Ahhoz ezt a dp83848-at ajánlják? Vagy van hozzá Microcip-es illesztő is?

Igen, én is használtam 18F86J65-öt, ahhoz valóban csak trafó kellett. A PIC32-ben viszont a fizikai illesztő réteg (PHY) nincs belül, azért, hogy tetszés szerinti átviteli közeget használó hálózathoz csatlakoztathasd. Tehetnél pl. MRF24W illesztőt, akkor wifi hálózathoz csatlakoztathatnád a PIC32-t.

Microchipes MII-UTP illesztőről nem tudok, de a DP83848 szerepel a Microchip Ethernet Starter Kit nevű demó paneljén is, és a súgóban is emlegetik, így tehát gyárilag támogatott.

Pontosan, ezért is tudtam a gyári programot használni átalakítás nélkül ehhez.
Pontosan: PIC32 Ethernet Starter Kit DM320008

Értem, köszönöm!

Jelentem, pár perce elindult

Valószínűleg valami érintkezési probléma lehetett, mert újravezetékeltem az egészet, és most megy. Most bekapcsolva hagyom holnap délutánig, böngészőben futnak az ajax kérések a weboldalra, és fut ping folyamatosan, kíváncsi vagyok, holnap délutánig hogyan alakul a helyzet

Köszönöm a segítséget mindenkinek

Üdv !

potyo a DP83848 Ethernet modulhoz hol lehet hozzájutni, és mennyi be volt mire kézhez kaptad?

Ettől az eladótól vettem ebay-en. Az ott kiírt $9.99+$7 vagyis $17-be került szállítással együtt.

Köszönöm, a gyors segítséget!

Sziasztok!
Egy 18F87J60-al játszok mikor ráérek. A C18-PICDN2_ETH87 demóból indultam ki.
Célom, hogy egy asztali alkalmazást elindítva hozzáférjek HTTP-n keresztül adatokhoz. Az alkalmazás lehet böngészőben futtatható, vagy egyéb program, ami HTTP-n keresztük kommunikál.
Most ott akadtam el, hogy a demo egy kapott adatcsomag után, ami LED-et vezérel, vagy adatokkal, fájlokkal dolgozik, egy válasz üzenetet dob, amit a böngésző kiír, mint szöveges oldalt. Jelen esetben LED be-ki kapcsolgatásakor egy Sucess! feliratot, mögötte az állapottal(1, 0).
Nem találom, hogy ezt a választ hol küldi el a demo, illetve nem vagyok járas abban, hogy ezt melyik réteg küldi vissza és a böngészőnek hogyan kell erre reagálnia. A demo AJAX-al lekezeli a válaszokat, ezt egy sima htm nem tudja, illetve nem készítettem fel rá, de nem lenne szükség a válaszra ebben a stádiumban, illetve tudni szeretném hol és hogyan keletkezik a válasz, hogy én is létre tudjak hozni sajátot ha kell.
Remélem van aki tud segíteni!
Köszi!

A leds.cgi-ben van ilyen szöveg: Success! ~led(0)~
Ha jól emlékszem, a hullámvonalak közötti részt futás közben, dinamikusan lecseréli az aktuális értékre.

Ja, én még nem tartok ilyen finomságoknál, mint te...

Tényleg! Ez benne van a WebPages2 könyvtárban, ami belefordítódik a hex-be. Valószínű ezt a fájlt(ill. tartalmát) adja vissza a válaszban, de még nem tudom hogyan. De most egyel már közelebb vagyok, köszi!
Még az is érdekes, hogy a forrásban is megvan a ROM-ba irányítva a szöveg, de azonosíthatatlan a hozzáférés.

Van a HTTPPrint.h fájl, ami tartalmaz minden egyes ilyen hullámos vonal közé rakott változóhoz egy-egy függvényhívást. Maguk a függvények pedig a CustomHTTPApp.c fájlban találhatóak. Pl. ~version~ változóhoz tartozik egy HTTPPrint_version nevű függvény. Vagy ~led(0)~ változóhoz tartozik egy HTTPPrint_led(WORD num) függvény, ami paraméterben megkapja a led-nél a zárójelben levő számot. A HTTPPrint.h fájlt és az MPFSImg2.* fájlokat a Microchip Solutions\Microchip\TCPIP Stack\Utilities\MPFS2.jar fájl tudja generálni (Java kell a futtatásához, de amikor legutóbb játszottam vele, akkor csak windows-on működött, a Linuxos mappaelválasztó / jeleket hibásan kezelte). Ennek megadod a Webpages2 mappát, amiben a forrás weboldalad van, és ez generálja belőle a szükséges cuccokat, amik már be vannak includolva a projektbe, és fordításkor a helyére kerül minden. Ha nem teszel be új ~-as változót vagy veszel ki és külső memórián van tárolva a webes holmi, akkor nemis muszáj újraégetni a kontroller kódját a webfelület módosításakor, elég csak a kapott MPFSImg2.bin fájlt feltölteni a webes felületen. Nem tudom a pontos url-t, hogy hová kell, ennek utána kell nézni a súgóban. Valami /mpfsupload rémlik.

Szia! Ez eddig oké, ismerem a folyamatot. A HTTPProcess-ben kerül meghívásra az smHTTP=SM_HTTP_SEND_FROM_CALLBACK esetén a HTTPPrint(curHTTP.callbackID);
A gondom az, hogy nem találom, hogy mi küldi vissza a választ és hogyan az egyes callbackID-k esetén meghívott rutinokban. Pl. ha kikommentelem a HTTPPrint_led(1); -t, akkor a gyári weboldal LED visszajelzője nem működik, de ha egy formból egy gombbal elküldöm a http://192.168.0.108/leds.cgi?led=1 GET csomagot, akkor hívó oldal helyett feljön egy üres, amin csak az van, hogy Sucess! 0, de van mikor Sucess! 1(sajnos az érték nem tükrözi mindig a LED1 állapotát). A LED fizikailag működik egyébként...