Először is köszi a választ. A program mikroPascal-ban íródot, egyenlőre a mintapélda van benne. SPI Ethernet Library-t használom, elvileg ez lekezel mindent. A CS és az RST-re kötött lábakat kell csupán beállítani.
SPI_ETHERNET_Rst: sbit at PORTC.0
SPI_ETHERNET_CS: sbit at PORTC.1
SPI_ETHERNET_Rst_Direction: sbit at PORTC.0
SPI_ETHERNET_Cs_Direction: sbit at PORTC.1

A főprogramban csak a SPI_Ethernet_doPacket() függvény van. Induljunk ki abból, hogy a program jó, hiszen próbapanelen összedugdosva működött. Készítettem egy panelt, miden ugyanaz, azon viszont nem. Szintillesztés viszont nincs egyszerűen össze van kötve a ethernet modul megfelelő lába a PIC-kel. Kellene valami felhúzó ellenállás bele? Bocs de nem vagyok egy elektronika guru.

Tehát a lábakat így kötöttem be:
CS-RC1, RST-RC0, SI-RC2, SCK-RC3, SO-RC4
A CLKOUT, INT, WOL lábak nincsenek bekötve.

Igaz a PIC 5V-ról, a modul 3,3V-ról megy, de én a szintillesztéssel nem foglalkoztam, gondoltam, hogy a PIC-nek a 3,3V elég a logikai 1-nek.

A chip engedélyező lába stabilan van? Mert az megtréfálhatja az embert - rendesen.... Az sem mindegy, hogy 5V-ról, vagy 3,3V -ról akarod meghajtani....

A CS lábat fel kéne húzni, mivel amikor éppen nem hajtja meg a PIC, akkor ugye ott random események történhetnek. Ugyanezen ok miatt szokás a PIC SDI adatbemenetét is felhúzni, hogy ha az SPI slave valamiért nem tevékenykedik, akkor ne "szemetet" olvassunk, hanem csupa magasat.
Az 5V-3.3V kérdéskörét körbe kéne járni. Ha az IC elviseli az 5V-ot a bemenetén, akkor elég a PIC bemenetére egy szintillesztőt rakni (a 3.3V-os tápról járatott CMOS IC kimenete nem mindig elég egy 5V-ról járatott PIC CMOS bemenetéhez), erre bármelyik 74HCT vagy 74AHCT sorozatú kapu/inverter/meghajtó jó lehet, mivel azok már 2V-nál kapcsolnak.

RC porton ST bemeneti pufferek vannak, tehát a 3,3V nem elég neki a magas szinthez megbízhatóan, 4V-tól lesz megbízható.

Azt nem lehet, hogy a kontrollert is 3,3V-ról járatnád?

A másik, hogy nem vagyok benne biztos, hogy az ENC 5V toleráns lábakkal rendelkezik, szóval a másik irányban sem okvetlenül van rendben a jelszint.

Most olvasom:

The first design powers the PIC at 5V and the ENC28J60 at 3.3V, but uses inline 180Ω resistors on the ENC28J60 SPI lines

Tehát az RC2 után kell egy soros 180 Ω.

A panelon van egy LCD kijelző is. Annak pedig kell az 5V azt hiszem, de megnézem a leírásban. Először is kipróbálom 3,3V-on. Mindjárt írom.

A helyzet javult. Ha az egész áramkört kihúzom, aztán a tápot visszadugom 200-4000 ms-os pingek jönnek vissza. Néha kihagy egyet-egyet tehát instabil az egész. De. Ha programozóval reszetelek egyet, tehát csak a pic indul újra 1 ms-os végig a ping, stabil a végtelenségig. Most 3,3V-on megy minden.

Az LCD-nek csak a tápra kell az 5V, a kommunikációs lábain a 3,3V már elég a magas szinthez.

Ez azért LCD-függő ám... a CMOS IC-k 5 Voltról táplálva vagy megelégszenek a ~3 Voltos magas szinttel, vagy nem.

Eddig amit láttam LCD-t, annak az adatlapja alapján TTL kompatibilisek voltak a lábai. Nem mondom, hogy mindegyik LCD ilyen, de amihez volt szerencsém, azok ilyenek voltak.

Pedig ha a MikroElektronika honlapját megturkáltad volna, találhattál volna kapcsolási rajzokat EN28J60 modulokról, abból megnézhetted volna, hogy hogyan oldották meg ők az illesztést.

Ide nem TRISC-ket kellett volna használni?

Sajnos csak ide írtam rosszul (copy, paste) , a programban helyesen van.

Sziasztok.

A következőben kérném a segítségeteket. Egy "IP relét" szeretnék építeni. Tulajdonképpen eszközök távoli újraindítására lenne használva. Nekem annyi elég lenne, hogy a panel rá lenne dugva hálózatra és ha a böngészőmbe beírom az IP címét (amit lehet változtatni), akkor távolról kapjak egy olyan felületet, hogy relé meghúz/relé elenged. Ha tud valaki benne segíteni, megköszönném. További szép napot.

Üdv, Laciveszp

Hali!
Ezt a microchip gyári tcpip demója nagyjából tudja, a led(ek) helyére kell egy relémeghajtó tranyó.
Ha nem akarsz hardwerrel bajlódni, az olimexes fejlesztőpanelek nem túl drágák, van Bp képviselet: Bővebben: Link
Arra figyelj hogy jelszóvédett oldalra kell tenni, különben a kismanók is fogják kapcsolgatni, szóval a szoftvert kell hozzá kicsit faragni.
Az IP címét csak helyi hálón tudod szabadon választani, ha internetről akarod, akkor a szolgáltató adja az ipcímet, és dyndns is kell neked, vagy veszel drágájé fix ipcímet.

Végül is elindult az áramkör. Tulajdonképpen szoftverhiba volt, mert nem állítottam be azokat a lábakat amelyeket nem használok, így azok (gondolom néhányan bemenetként viselkedtek alapból) összeszedtek egy csomó zavar jelet. Szóval induláskor beállítottam minden portot digitális kimenetre, majd a számomra szükségeseket annak megfelelően. Innentől kezdve minden tökéletesen működik. Ekkor még 3,3V-ot kapott a proci is. Gondoltam egyet, visszaraktam a 5V-os stab IC-t és kipróbáltam úgy is. Az ethernet modul 3,3V-on a PIC 5V-on. És így is működik tökéletesen, szintillesztés nélkül. Gondoltam akkor kimérem mikor is kapcsolnak PORTC lábak. Ahogy beszéltük 0,8*Vpp kellene hogy legyen azaz 4V. De nem így van. Már 2,2V-nál kapcsolgat, 2,5 V körül stabilan 1-esbe fordul a bemenet.

Hali!

Köszi a gyors választ. Az IP cím változtatás és a védett hálózat nem probléma. Nekem valami olcsó eszköz kéne, az lenne a legjobb, ha én építeném meg. A lehető legkevesebb alkatrészből szeretném megcsinálni, egy LAN csatiból, egy ENC28J60 IC-ből, egy PIC-ből illetve a szükséges többi alkatrészből. És egy beépített webserverrel rendelkezzen. Üdv, Laciveszp

Hali!
Mi a kérdés? Továbbra is azt mondom microchip gyári demót kell megszerelni,
ENC helyett jobban jársz ha megépítesz egy PIC18F97J60 vagy 67J60-al egy webszervert,
rajz a microchiptől, vagy olimextől, ill hemzseg a net.

Sziasztok!

Írt már valaki mini webszerver enc28j60-at használva úgy, hogy POST-tal küldi az adatokat?
Régóta keresem a neten, de nem találtam egy használható megoldást. Ha olvasom a küldött adatokat, (POST /....) szépen átjön minden, csak éppen a paraméterek nem, ami POST esetén a csomag végén kellene lenni.
A libstock-tól letöltött net_ethernet_enc28j60 library-t használom 18f4620-al.

Szia!

Amikor én próbálkoztam, bár az AVR-el volt, nem volt probléma. Ha a "GET"-tel megy, akkor a "POST"-tal is kell. Az eredmény ugyanaz a mikrovezérlő oldalán. Arra gyanakodnék, hogy a böngésződ nem küld paramétert "POST" esetében. Én Firefox-ot használok + Live HTTP headers add-ont, amivel látom, hogy milyen fejlécet küldött. Ez sokat segített hibakereséskor. Ha látod, hogy a paraméterek a fejlécben vannak, akkor már csak a vezérlőnél lehet probléma.
Én a következőt használtam: AVRnet
Remélem hasznodra lesz.

Szia, köszi a választ. Mellékelek egy képernyőképet. Én Chrome-ot használok, ott a fejlesztői eszközök között lehet monitorozni a küldött adatokat. Amit látsz a képen megy is ki sorban, addig hogy "Origin: http:". és itt megszakad és jön a favico kérés: GET /favico...
Így a post adatok nem érkeznek meg, hiszen azoknak a csomag legvégén kellene jönniük.

Bocs a késésért, kicsit utána kellett járnom . Régen volt már. Csatolok én is képet (Chrome), hogy lásd. Ugyanaz a kérés, egyik GET-tel, másik POST-tal. GET esetében az eredmény: "GET /?MAC=53-57-49-54-43-48 HTTP/1.1", még POST esetén a paraméter nem rögtön utána következik, hanem a "Form data" alatt található. Esetemben a paraméret a "MAC" változó lenne. Ezt küldi. Először benéztem, de a képed alapján a form korrekt. A képemről kivehető, hogy nálam milyen, hasonlítsd össze vele, hátha. Egyenlőre ennyit vettem észre .

Aha, alakul. Jön az a post data, csak ki kell várni. Az volt a baj, hogy ahogy beeset a POST / az egyik csomagban, rögtön elkezdtem küldeni kifelé a weboldalt. Ezért "szakadhatott" meg a folyamat. De ha nem küldök (most egyenlőre semmit) átjön minden és az utolsó csomagban ott jön a postdata. Már csak azt kellene tudni melyik az utolsó csomag, és akkor küldhetem az oldalt a böngészőnek.

Azt onnan lehet tudni, hogy a Content-Length nevű fejléc megmondja, hogy az utolsó fejléc + az üres sor után hány byte a POST "tartalma".

Köszi a válaszokat, innentől már menni fog!

Sziasztok!
Egy kis segítséget kérnék.
Van egy ENC28J60-as panelem és szerettem volna életre kelteni.
Nem is kell, hogy mondjam, hogy rengeteg időt vett igénybe, mire azt mondtam, hogy jóó, elég.
Ki akartam próbálni egy gyári kódot, hogy legalább működik-e a kapcsolás. Szóval találtam egy oldalt (lásd melléklet) és az ottani hex-et beégetve a PIC-be, láss csodát, működött a dolog.
Na felbuzdulva megpróbáltam azt a projektet modifikálni egy kicsit.
Először csak az IP címet akartam átírni. De amint a MikroC-vel lefordítom, majd beégetem, se kép, se hang. Néztem szkópon, de a PIC meg se nyikkan.
Na most a verziószám, amivel a projekt lett csinálva, illetve ami nekem van, megegyezik, v5.61.
Jó lehet, az enyém torrentes MikroC.
Gondoltam az a baj, biztos nem jól fordít (hogy crackes). Írtam vele egy egyszerű futófényt, gondolván arra, hogy akkor ez sem fog menni. De hát nem, mert a futófény rendkívüli módon meg fut.
Szóval az ideg összeroppanás szélén állva kérnék valakitől segítséget. Mit nem csinálok jól?
Előre is köszönöm.

Előrebocsájtom, hogy sem MikroC sem PIC16F887 mikrovezérlővel nincs tapasztalatom!

Ha az eredeti hex működik, a módosítatlan program pedig újrafordítás után nem, akkor nyilván valami fordítási beállítás nem stimmel. A letöltött csomagban levő .log, .lst és hasonló állományok összehasonlítása segíthet annak feltárásában, hogy mi lett más.

Első körben a konfig biteket nézd meg, ugyanúgy állnak-e az eredeti hexben és az általad fordítottban.

Azok rendben vannak, leellenőriztem.
Viszont most hasonlítgattam össze az icserny által említett fájlokat és az első fele nem ugyanaz. Azt hiszem a fordító csinál alami butaságot. Lehet, hogy beleszaladtam a ködbe ezzel a torrentes verzióval.

No, szóval a MikroC volt a hibás. Mivel crack-es volt és ráadásul nem is jó, így kisebb kódoknál jól fordított, nagyobbaknál meg nem fulladt le hogy: demo limit, hanem megcsinálta a hex-et rosszul. Szóval ezért volt ez az aprócska kis gond, ami már (nem egybefüggően) 3. hónapja szivatott. Szóval találtam egy jó verziót és azzal szépen működik minden. Azért köszönöm potyonak meg icsernynek is, hogy foglalkoztak a dologgal.

Szerintem egyszerűen csak gondoltak a crackerekre. Szándékosan beleraktak valami egyszerűen átvágható ellenőrzést, amire a crackerek ráharapnak, majd valahol a mélyén a kódnak egy másik ellenőrzés észleli a kavarást, és nem panaszkodik, hanem rossz kódot gyárt. Ötletes