Nem értem, hogy mit nem értesz A HTTPPrint_led() függvényben van egy ilyen sor: Ez ad vissza nullát vagy egyet a led állapota alapján a kimenetre. A led állapota pedig direktben annak a portnak a LAT bitjét olvassa, amelyikre a kiválasztott led van kötve.

Szerk.: lehet ám, hogy mégis értem A leds.cgi-ben fixen az van, hogy a led(0)-t adja vissza. Szóval hiába adod be paraméternek azt, hogy ?led=1, ez mindig a nullás led állapotát fogja visszadni Viszont elvileg annak a lednek az állapotát változtatja ellentétesre enned a hívása, amelyiknek a számát beadod paraméterként. Kivéve a nullásét, mert azt nem itt villogtatjuk, és nincs is az eredeti kódban benne, hogy led=0 esetén mit csináljon, tehát nemis csinál ezesetben semmit.

Értem, tehát a visszaadott állapot a LED0 állapota, éppen a LED1 kapcsolásának időpontjában, ezért nem egyezik meg vele(időnként).

Viszont ha kiveszem a két LED callback lekezelését, még is visszajön a Succes! állapot nélkül. A gyári oldalon nem villog a LED, tehát a LED-ekre vonatkozó infó nem jön vissza. Az a gyanúm, hogy a leds.cgi ágon van valami kötelező penzum a válaszra, amit nem találok.

Két külön dolog történik, amikor a leds.cgi-t meghívod. Az egyik a CustomHTTPApp.c fájl 230. sora környékén (a legutóbbi stackben legalábbis), itt kezeli le a paramétert a bejövő kérés, ennek hatására vált állapotot a led. És van a másik dolog, ami egyszerűen a leds.cgi bármilyen hívása esetén a visszaadott fájlban lecseréli a változó(ka)t. Ezt csinálja a HTTPPrint.h fájl alapján a HTTPPrint_led() függvény, ami szintén a CustomHTTPApp.c fájlban található az 1695. sortól. Gondolom előbb a 230-as sorban levő dolog fut le, majd utána az 1695-ös sorban levő, így az átadott paraméter akár kihathat a visszaadott értékre is, de a gyári kódban nem hatnak ki egymásra. Megpróbálhatod azt, hogy ott a 230. sor környékén megjegyzed egy változóba, hogy mi volt a paraméter, majd az 1695-ös sor után az előbbi változó alapján választott led állapotát adod vissza, nem a függvénybe bejövő num paraméter alapján választott ledet.

Egyébként nemtudom, nézted-e, de nézz bele a leds.cgi fájlba a Webpages2 mappában. Ott van benne egy Success! szöveg, tehát bármikor ezt a fájlt meghívod, a Success szöveg mindig ott lesz a válaszban. Ha azt akarod, hogy változó szöveg legyen, akkor cseréld le pl. ~allapot~-ra, generált újra a HTTPPrint.h fájlt az előzőekben leírt módon, majd csinálj a CustomHTTPApp.c-ben egy HTTPPrint_allapot() nevű függvényt, ami tetszőleges szöveget ad vissza, és akkor az fog megjelenni a Success! helyén.

Ez rendben, de én pont azt akarom, hogy ne jöjjön válasz. Illetve azt keresem, hogy ha a callback kezelésénél a HTTPPrint_led() -eket kikommenetezem, akkor nem jöjjön vissza semmi a böngészőnek. Mi küld választ még a led callback-on kívűl?

De a HTTP protokoll az úgy működik, hogy megy egy kérés és arra jön válasz Akár csak egy üres válasz, de akkor is van válasz. Az nem elég, hogy figyelmen kívül hagyod a választ? Ha nem akarsz választ, akkor UDP kellene neked, az nem vár választ, de nemis lehetsz biztos benne, hogy megérkezett.

Egyébként két napja megint nem megy az DP83848. Világít rajta a sárga led (ez gondolom a link led lehet), a zöld meg kb. másodpercenként villan egyet, de a routerben nem jelenik meg a dhcp kliensek között, és nem válaszol az alapértelmezett ip-n sem. Tudja valaki, mit jelenthet, ha az act led így néha villan egyet?

Hát akkor talán ez a "baj"?
Csináltam egy ilyen próbát, ami a HTTPprint-ből hívódik meg a Callback kor:

Ilyenkor csak a *.cgi-ben lévő szöveg jelenik meg, mert az adat a kikommentelés miatt nem megy vissza. Tehát az alap választ nem itt kell keressem és akkor ezek szerint nem is kéne kigyomlálni, mert válasz mindenképpen várva van a protokol miatt.

Hogyan lehet a választ figyelmen kívül hagyni, hogy a böngésző ne jelenítse meg?
Ha én csak utasításokat akarok küldeni visszajelzés nélkül, akkor nem szerencsés, ha minden gombnyomás után vissza gombot kell nyomjak.
Egyébként egyértelműen a *.cgi-ben lévő szöveg jelenik meg a felnyíló ablakban. Ha van paraméter, akkor az is, ha nincs akkor az nem.

Két módszer létezik. Vagy ajax-al küldöd a kérést, vagy rejtett iframe-be irányítod a választ. Esetleg a leds.cgi-be teszel egy javascriptet, ami visszairányít azonnal az előző oldalra, de ez nagyon taknyolt megoldás, meg lehet, hogy böngészőfüggő is. Én a magam részéről az ajaxosra szavazok.

Ez azt jelenti, hogy ajax nélkül mindenképpen egy új ablak nyílik meg, amit a szerver küld a válaszban? Ez eddig emiatt nem esett le, hogy milyen gáz ez a HTML szabvány és hogy miért találták ki az ajaxot!
Az a rejtett iframe az hogyan van?

Pl. akarsz a leds.cgi-nek küldeni egy paramétert egy form-ból, akkor a formot így csináld:


Tehát a lényeg, hogy a form target attribútuma az iframe id-jével legyen azonos. A display:none pedig elrejti az iframe-et, hogy a válasz ne legyen látható. Esetleg próbaképp a display:none-t kihagyod, és akkor látod, hogy mi történik valójában.

Ha ajaxot használnál (amit én tennék a helyedben), akkor ahhoz érdemes a jQuery nevű JavaScript függvénykönyvtárat használni. Elsőre durvának hangozhat, de nem olyan bonyolult és böngészőfüggetlenné teszi a dolgokat.

Most annyi változott, hogy egy új fülön jelenik meg a válasz ablak.
A method-ot get-re kell állítanom, mert ez a rész abban van lekezelve a PIC-ben. Ez okozhat eltérést?
Ezzel próbálom most:

A get-es dolog nem kellene, hogy gond legyen. Csatold a fájlodat és megnézem, mi lehet.

Szerk.: ja, most látom, hogy itt a kód Internet Explorerrel próbálkozol? Nem látok benne problémát. Elérhetővé tudod tenni interneten?

Íme:

Igen, IExplorer...
De Firefoxban is új fül nyílik

Tényleg, Firefoxban nekem is új fület nyit. Na majd ebéd után megpróbálok rájönni, mi a gond.

A dologhoz hozzátartozik, hogy ha nem AJAX-os "eseményt" generál a gombod, hanem rendes oldalletöltést (az iframe-es trükközés is az), akkor a böngészőben új oldal-állapot keletkezik, és egy új tétel kerül a "back" listájában. Azaz ha nyomsz ezután egy "back" gombot, akkor a böngésző visszavált az oldalon (vagy az iframe-ben!) az előző állapotra.
Ha 10x nyomtad meg a gombot, akkor 10 új oldal jött (vagy került az iframe-be), és ezután az első 10 "back" nyomás csak ezeket lapozza vissza, és csak a 11. "back" fogja azt csinálni, amit a felhasználó várt volna. Ez - szerintem - rettentő zavaró tud lenni felhasználói szemmel.

Ahogy nézem, az a gond, hogy firefox esetén neve is kell, hogy legyen az iframe-nek. Tehát tedd azt is hozzá, hogy name="iframe1". Jó tudni, mert nekem is van a cégben projektem, amiben használok ilyet (mert fájlfeltöltést nem lehet ajaxszal megoldani), azokat is jó lesz átnéznem

De ahogy _vl_ is említette, ajax jobb lenne. És nemis bonyolultabb a jQuery használatával. Pl. amit te akarsz csinálni, az ennyiből áll:



Lehet, hogy elsőre égnek áll az ember haja tőle, de gyorsan kézreáll a dolog

Na ez elég vacakul jelent meg, meg ki is felejtettem belőle ezt-azt, inkább csatolom.

Köszönöm a megoldást, hibátlan mindkét böngészőben!
Szeretek lépésenként haladni, ezért ragaszkodtam ahhoz, hogy a választ valahogy ignoráljam. Valószínű a választ is fel fogom dolgozni egy valós alkalmazásban, azaz ajax lesz a vége, de most ez fontos lépés nekem. Köszi még egyszer!

Ha bírod még, lenne még kérdésem. A miért a *.cgi tartalma, kiegészítve a visszaküldött változó értékkel lesz a válasz? Hol hívódik meg a *.cgi és mikor? Ha nem küldök vissza változót, akkor is meghívódik, tehát nem a HTTPprint-nél történik a válasz generálása, ott csak kiegészül a változó értékével. A válasz szabványos, van valami felépítése, amit érdemes tudni?

Azt pontosan én sem tudom, hogy hol dől el, hogy a kérésre azt a választ adja. Ebbe a részbe nem másztam bele, mert jól működött úgy, ahogy nekem kellett. De úgy tippelem, hogy a HTTP2.c fájlban dől ez el.

Szerk.: nézd meg az említett fájlban a case SM_HTTP_PARSE_REQUEST: utáni részt.

OKé, megnézem!
Közben egy újabb kérdés, hogy a válasz egy karaktersor, mint egy TXT? Ezért jelenik meg új ablakot nyitva, vagy lecserélve az előzőt? Mert a *.cgi nem a PC-n van, hanem a PIC-be fordítva, onnan küldődik vissza. Ha nem csak egy karaktersor, akkor milyen lehet a valós adatsor, hogy láthatnám?

És még egy, hogy lehet egy form-on belül két gombbal két eltérő *.cgi-t meghívni? Jó lenne a gombokat egymás mellé tenni, de a form-ban kell meghatározni a *.cgi nevét. Ki lehet egészíteni a form action= tartalmát menet közben egy gomb megnyomásakor? (GET módban).

A válasz valóban egy sima karaktersor. Itt nézhetsz utána, hogy pontosan hogyan is épül fel.

Ki lehet egészíteni. Pl. így

Inkább csatolom, rosszul működik a kód formásáza.

Bár nem szoktam ilyet csinálni, de elvileg működik.

Köszi, a kiegészítés működik! Azt meg lehet csinálni, hogy a gombokhoz hozzárendelni egy formon belül egy-egy adatmezőt(text), aminek tartalmát el kell küldenie?

Meg. De akkor már csinálhatnál két külön formot is

Igen azt gondoltam, hogy megoldás, de érdekelt volna, hátha! Tudsz valami jó oldalt példákkal?

watt:

Idézet a DP83848c rev.E adatlapjából (forrás itt: http://www.ti.com/lit/ds/symlink/dp83848c.pdf) a 21. oldalról:


Ahogy a vezérlő is megcsinálja, hogy valami belső állapotgépet táplál meg 50 MHz-en, és az adat mintavétel igazából csak 5 MHz-en ketyeg, úgy a pic is meg tudja csinálni, hogy azt az órajelet simán csak leosztja 10-el. Ezt végül is nevezhetjük "feldolgozás"-nak, bár van egy sanda gyanúm, hogy te igazából nem ilyen feldolgozásban reménykedsz. Ami azt illeti, én sem..

Nálatok milyen hosszú vezetékek vannak a PIC32 és a DP83848 között?

Nekem ahogy a múltkor egyszer elindult, és ment több mint egy napig, azóta semmi életjelet nem ad. A sárga led világít a modulon, a zöld másodpercenként villog (ahogy nézem, szinkronban a kontrolleren levő LED0-val), de a router felületén nem jelenik meg semmi és persze ping-re sem válaszol. Pedig a kód nem változott semmit. Debuggolva a kódot azt látom, hogy a _PhyDetectReset() függvény nullát ad vissza, mert a bmcon.RESET folyamatosan egyen van. Először azt hittem, hogy a vezetékhosszúság lehet a probléma, és a múltkor csak véletlenül úgy álltak a vezetékek, hogy elindult, de azóta lerövidítettem, amennyire lehetett, de semmi életjelet nem ad a hálózaton. Próbáltam másik UPT kábellel is, de nem hozott javulást, pedig a kábelek biztosan jók.

Hidegítésekkel és a pikós kondik cseréjével próbálkoznék. Legutóbb találkoztunk egy olyan esettel, hogy rosszak voltak a kvarc körüli kondik. Egyéb ötletem nincs, nem ismerem ezt a konfigot.

Azóta már az is lehet, hogy kinyírtam a modulkát, mert véletlenül kettővel arrébb dugtam rá a tüskesorra. Így az MDC, MDIO, OSCIN, meg ott a következő lábakon kapott tápot és gnd-t. Ugyanazt csinálja továbbra is, miután helyreraktam, de nem kizárt, hogy ott valami kimenetet kinyírtam. Úgyhogy egyelőre más ötlet hiányában visszaállok az ENC28J60-ra (abból van otthon 2-3 darab), és majd rendelek mégegy ilyen DP83848 modult.