Fórum témák
» Több friss téma |
Ha nagyon akarod, és rá akarod szánni az időt, ám tedd
 Bár első lépésként nézd meg, hogy a stack kód mennyi RAM-ot igényel. Meg a proci idő igényen is el lehetne filozni. A C18-ban nincsen 64 bites integer support. Hirtelen ezek a buktatók jutottak eszembe.
Nem emlékszem, hogy találkoztam volna olyannal, hogy 64 bites integert használna valahol. Stack kód RAM igényébe szerintem bőven belefér még az SD kártya kezelése, amit csináltam cuccot, 1950 bájtot igényel, és még azon is lehetne valamennyit reszelni. Processzoridőtől nem félek, ha esetleg 150 helyett 250ms az oldal lekérési ideje, az nem különösebben lényeges.
Akkor hát hajrá. Látom nagyon unatkozol
Menet közben esetleg adhatnál egy tippet, mik lehetnek a tipikus hibák. 424j600-as van dsPIC-hez kötve, és élesztéssel szenvedek már mióta. Elementáris a szívás. A 424 modulárisan van összeforrasztva a környezetével, végig is csengettem, másvalaki is letesztelte, a modul hibátlan. A többi cumót dugaszpanelbe pakoltam, végignéztem már 3x a kötéseket (különféle módokon), nem nagyon lehet itt elkötve egyáltalán semmi se. Maga a stack kód az ENC vezérlőnél hal le init közben, amikor resetelni akarja az eszközt, és az EUDAST regisztert írja 0x1234-el egészen addig, amíg ugyan azt olvassa vissza (C:\Microchip Solutions\Microchip\TCPIP Stack\ENCX24J600.c, 1560. sor környéke). Hát sosem kapja azt vissza. 0x0000-t kap minden egyes alkalommal. Mintha a modul kimenete földre ragadt volna. Az SPI busz olvasására gyanakodtam a sokszoros ellenőrzés után is, de nem tiszta, mi lehet azzal baj. A PIC bemeneten leszedtem a modul bekötését, és felhúztam ellenállással, akkor frankón 0xFFFF-ek érkeztek. Kommunikáció nélkül is megcsinál olyat az ENC, hogy rádugom a gépre egy lan kábellel, és ahányszor csomagot küldök kifele, felvillan a zöld led. A PIC órajelet pld az ENC küldi, és stabilan megy. Szóval az alapból taccsrament ENC esete is kiesett. Valami alapvető dolgot szúrtam el, ami valószínűleg a szememet kiböki, és éppen azért nem látom  Pár tipp jól jönne.
Köszi a tippet, utána néztem.
Van valami Framed SPI support, ott használja az nSSx-et "as frame sync pulse input/output". Természetesen a config alapján ez a funkció a vezérlő bitben ki van kapcsolva, és az nSS használata is ki van kapcsolva (config bit), valamint nincs is kivezetve az nSS egyik külső lábra sem (peripheral pin selecttel kellene külön beállítani, de nincsen beállítva). Idézet: „Akkor hát hajrá. Látom nagyon unatkozol” Ezaz, hogy pont nem kéne ilyennel foglalkoznom, mert tanulni kellene vizsgára. Csak ilyenkor minden máshoz van kedvem a tanulást kivéve... Akkor a másik téma alapján lehet, hogy itt is az SPI modul hibája miatt nem működik a kommunikáció? Kódban nincs az errata-ra utalás? Máskor már találkoztam ilyen utalásokkal és megkerülő megoldásokkal a kódokban.
Nyamvadt JTAG bekapcsolva maradt, és nem működtek a felprogramozott lábak SPI buszként az ENC vezérlő felé. Szépet szívtam ám vele
Még mindig gyűröm a tcp stacket. Valahol gépidő szivárgás van, és egyenlőre nem találom.
Kimértem ilyen időtartamokat mint -hosszabb saját app rutin végrehajtás 141uSec, -beérkező csomag ellenőrzés + beolvasás + feldolgozás + válasz kiküldése összesen 480uSec -StackTsk() végrehajtása avg 50uSec, csúcs értéken viszont 38 mSec (!)  DHCP-n és UDP-n kívül semmi sincs a kódban. Már az ICMP támogatást is kivakartam.
Az ENC adatlapját olvasgatta valaki? Nekem az ERDPT read pointer és az ERXRDPT vételi buffer read pointer szerepe nem világos. Tudnátok ebben segítséget adni?
Ha jól látom, akkor a vételi pufferből olvasáskor mindig azt az adatot olvassa a kontroller, amire az ERDPT mutat. Ezt alapesetben nem kell bántani, csak be kell kapcsolni, hogy minden olvasáskor egyel növelje, és akkor szépen egymás után adja ki a bájtokat. Akkor van rá szükség, ha több csomag érkezett a pufferbe, és nem érkezési sorrendben akarjuk kiolvasni.
Az ERXRDPT pedig azt a címet tartalmazza, ameddig a vevő beírhatja az érkezett csomagokat. Tehát ez mutatja meg azt, hogy meddig lett kiolvasva a puffer, és hogy ettől a címtől kezdődően még nem írhatja be a bejövő adatokat, mert ez még nincs feldolgozva. Ilyenkor a vételi logika visszaküldi a csomagot és jelzi, hogy nem tud egyelőre több adatot fogadni. Ezt a pointert kell a csomag kiolvasása után aktualizálni, ha jól sejtem, akkor alapesetben az ERDPT tartalmát kell belé átmásolni. Most így gyorsan ennyit tudtam kihámozni, talán jön valaki, aki már használt ilyen chipet.
Köszi a választ, de még mindig zavaros kicsit. Összefoglalnám mire jutottam:
Az ERDPT szerepe egyértelműnek tűnik, a leírás alapján az ECON2.AUTOINC = 1 esetén Automatically increment ERDPT and EWRPT when the SPI RBM/WBM command is used. Tehát minden buffer memoria olvasáskor növekszik az ERDPT mutató értéke. Idézet: „Ezt alapesetben nem kell bántani, csak be kell kapcsolni” Szerintem a buffer első olvasásakor a mutató értékét az ERXST re (vételi buffer eleje) kell állítani. Jól gondolom? Aztán olvagathatok kedvemre, az ERDPT növekedni fog. Véletlen kiolvasákor az ERDPT értékét kell shiftelni. Az ERXRDPT már nehezebb ügy. Idézet: „Az ERXRDPT pedig azt a címet tartalmazza, ameddig a vevő beírhatja az érkezett csomagokat” Igazad van ebből is derül ki: Idézet: „The ERXRDPT registers define a location within the FIFO where the receive hardware is forbidden to write to. In normal operation, the receive hardware will write data up to, but not including, the memory pointed to by ERXRDPT. If the FIFO fills up with data and new data continues to arrive, the hardware will not overwrite the previously received data.” Az adatlapon később azt is olvasom, hogy miután a kontroller feldolgozott egy csomagot, és fel szeretné szabadítani a helyét, akkor az ERXRDP vel kell előrelépnie. Mint ahogy Te is írtad ezt. Azonban a buffer kiolvasását az ERDPT vel már ismert címig kiolvastuk, fel isdolgoztuk, mi szükség az ERXRDPT -re a felszabadításhoz? Talán csak az, hogyha véletlenül olvasunk, akkor tudjuk meddig dolgoztuk fel, és így az ERDPT vel "szabadon" ugrálhatunk??? A máik dolog meg az lehet, hogy ezekszerint kezdőrtékként az ERXRDP - nek ERXST -t nem adhatok, mert akkor nem fog írni az ERXST+1 re sem. Akkor miszerint lehet inicializálni?? Egyenlőre ennyi, de még kivesézném pl. az EPKTCNT -t is.
Hello
Mikropascal ENC28J60 mintakapcsolását szeretném megépíteni, de nem derül ki nekem a rajzból, hogy az ENC IC 4, 5, 6 lába testre van-e húzva a 74-es IC jobb oldalán? Sajnos ettől jobb minőségben nem találtam meg ezt a rajzot. Üdv.
nincs földre kötve, ezeket a lábakat a procinak kell fogadnia, a 245-ösön keresztül. viszont úgy látom a 245-ös -oe lába nincs bekötve, ezt viszont vagy a procinak kellene vezérelni, vagy földre kötni
Hello
Sikerült a Mikropascal példaprogramjával beüzemelnem az ENC28J60-at. Jelenleg patch kábellal van az otthoni switch-re kötve. Ráköthetem az áramkört patch kábellal közvetlenül a PC-re? Üdv.
rákötheted de nem működik
. Kösd rá cross patch kábellel, a pc-nek is és az enc panelodnak is adj fix ipcímet, igy működhet.
Üdv!
Valaki régebben linkelt ide be egy olyan Microchip-es példaprogramot ami egy lámpát kapcsolt Ethernetes PIC segítségével. Mindenfelé kerestem, de nem találom véletlenül nem tudja vki hol érhető el? Kösz
Hello
PIC18F4550 + ENC28J60 már működik, Mikropascal ENC library-ját használom. Egy egyszerű weblapot kéne visszaküldenie a böngészőnek, ami működik is, de kb. 10-15 perc után már nem töltődik be az oldal. Nem tudok rájönni, mi lehet a gond. A pic biztos nem fagy le, az ENC chip activity LED -je felvillan, amikor be akarom tölteni a böngészőben a weblapot. Nincs valakinek valami ötlete? Üdv.
Hello
Fórumozgatás után arra jutottam, hogy az Rbias ellenállás értékét 2,7kOhm-ra cseréltem. Most már stabilabb, viszont most egy napi tesz után ismét nem jön be a weboldal, szóval most már órákat kibír. Nagyon úgy néz ki, hogy az ENC28J60 lefagy. Senki se küszködik ilyen problémával? Üdv.
Amikor lefagy, akkor a PIC irányában van kommunikáció? Mert ha nincs, akkor a PIC resetelhetné a chipet. Persze ez csak tüneti kezelés lenne. Vagy esetleg a PIC fagy le (végtelen ciklusba kerül)? Kicsit pontosabban utána kellene járni, hogy mi fagy le.
Ez a kapcsolás egy kicsit hiányosnak tűnik. Ennek egy másik változatát már korábban megtárgyaltuk, akkor arra a konklúzióra jutottunk, hogy az áramkör hibásan van megtervezve. Az interrupt pl. elvileg sem működhet. Valószínűleg a gyári szoftver nem is használja...
Hello
A PIC nem fagy le. A főprogram MikroPascalban olyan, hogy végtelen ciklusban állandóan meg van hívva egy függvény (spi_ethernet-dopacket). Ezután beszúrtam egy utasítást, hogy az egyik kimenet állapota invertálódjon. Így végülis gyorsan villog azon a lábon a LED. Amikor nem töltődik be a weboldal, ez a LED akkor is villog (ezt persze szkóppal ellenőriztem). Rbias értéke legelőször 2x 1,2kOhm volt, most 1,2 + 1,5 kOhm, de megpróbálom pontosan 2,32kOhm-al. A MikroPascalos ENC28J60 kapcsolási rajza van nekem megépítve azzal a különbséggel, hogy a 74HCT245 OE lába csatlakozik a CS vonalra. Üdv.
A Mikroelektronika honlapján megtalálható a régi kapcsolás javított kiadása.
Hello
Szerinted akkor hardver hibám lehet? A 74HCT245 -s kapcsolás akkor rossz? Nem lehet javítani rajta? Sajna az általad belinkelt kapcsolásban levő ic-t nem tudnám beszerezni. Üdv.
A te rajzod hiányos és homályos, emiatt nem tudom ellenőrizni, hogy a többi jel hogy van illesztve. A 245 a te kapcsolásodban szerintem működőképes, ha az OE bemenetet a chip selecttel engedélyezted.
A régi kapcsolás, amire utaltam, azért volt hibás, mert az interrupt jelet is megkapuzta a chip select, ami nyilvánvalóan hülyeség: nem tudott interrupttal jelezni az ENC28J60... Az új kapcsolásban szereplő beszerezhetetlen szintillesztő helyett bármi más is megfelel, ami meg tudja hajtani az 5 V-os PIC bemenetét. Bővebben: Link
Szia!
Lehet rajta javítani, a 74HCT245 OE lábát földre kell húzni. Ez nem okoz galibát ha csak egy eszköz van a buszon. Bár a te esetedben ez nem hinném, hogy segít, mert ha polling-al veszed az adatot, a régi kapcsolásnak is működnie kell! Milyen revíziójú az enc?
Hello
Sajna nemtudom, hogy milyen revíziójú, ez áll rajta: ENC28J60-I/SP 0836VU4. Ebből meg lehet állapítani? Amikor nem jön be a weboldala, akkor ha megpingelem, nem válaszol. Máskor, amikor működik, akkor válaszol és kb 3-4ms a válaszidő. Üdv.
A fent leírtakból nem lehet megtudni. Ha létezik rá függvény uPascal-ban, érdemes lenne kiolvasni, és utánanézni, hogy a meglévő mikroe-s TCP/IP stack támogatja-e, vagy az errata-t elolvasni, hogy mit változtattak és sajátkezűleg javítani.
A régebbi ENC-k igen bug-osak voltak, én a rev5-tel dolgoztam és abban már kiküszöböltek jó néhány hibát, de ennek ellenére mégis bele kellett nyúlni a TuxGraphics féle stackbe néhány helyen. 
Hello
Sikerült kiolvasni, hogy a revíziós száma 6. Egyelőre nem találtam hozzá errata-t. Üdv.
Hello
Úgy néz ki, hogy a B7-es errata való hozzá. Ez 2,32kOhm-os Rbias ellenállásértéket ír, most 2,7 kOhm-os van benne, előtte meg 2,4kOhm-os volt. Ennyire nagyon számít, hogy 2,4kOhm vagy 2,32kOhm van benne? Próba szerencse, kicserélem 2,32-re, hátha megjavul. Üdv.
Nem volt kalandom ENC28J60-al, de a 18F97J60 nem tűnt érzékenynek az Rbias-ra. 2k2-t kapott, lassan egy éve megy, eddig nem volt panasz rá...
|
Bejelentkezés
Hirdetés |
