Nem erre gondoltam. Igaz nem számoltam utána, csak érzésre mondom, hogy már a 10mbps-et sem lehetne feldolgozni a PIC-el, de 100-at tuti nem! Akkor meg mindek a 4 bites adatvonal, ha kettőn is átjön annyi, amennyit érdemben kezelni lehet.
LCD ügyben egyetértünk. 16F627A-val szoktam soros LCD modulokat csinálni. Én sem értem, miért nem lehet gyárilag sorosra építeni!?

Nem számít, hogy mennyi adatot akarsz átvinni, mivel azok a vezetékek szinkron fix órajellel mennek. Azaz ha másodpercenként csak 1kB-ot akarsz átvinni, akkor is 50MHz-cel fog átmenni az adat, és az idő nagy részében üresen ketyeg az órajel. Az RS232-nél, az I2C-nél, meg az SPI-nél szabadon megválaszthatod, hogy milyen órajellel menjen, itt nem.

Részemről fpga-t akarok netre kötni, nem pic-et. A pic csak közvetítő lenne. Az fpga-m pedig igényelni fog önmaga egy 40..50-es netet. Én nem azon aggódom, hogy egy switch-től milyen sebességgel menne tovább, mert az már teljesen más tészta. Ott egyébként is minimum gigabit lesz. (Míg MC-ék a 10-es net is bőven elég dolgokról álmodoznak, időközben már a gigabit is kommersz technológia lett.) 100-as net ugyan nekem sem kell, de a 10 nagyon lassú. Akad fpga-ra is ethernet kapcsolat, de olyan áron, hogy egy pic meg egy enc624 még az áramköri felülettel együtt is jobban jön ki. Meg aztán fpga-ra intelligens folyamatokat tervezni nagyon durván nőnek ott a költségek, és jelentőset tudnék spórolni rajta, ha pic kerülhetne mellé, és az rendezné el azt a pár dolgot, ami egyébként lassú folyamat, viszont sorrendi végrehajtó intelligenciát igényel. Én így kerültem abba a szituba, hogy pic-et kötni ethernetre, és nem 10-es sebességgel. Eddig a pic32 + enc624 34 vonalasan viszi a pálmát az én esetemben. Ha működni tud a DMA-s verzió is, akkor nem zuhanna be a speed-em olyan 60-80-ig (az mc lib real time programozza a psp-t, arra is megy ám az idő!), hanem koppra meglehetne a 100 is. Nem olyan rossz dolog egy kicsit rázsírozni a sebességre.

Na de várj, MII és RMII között nincs sebességkülönbség, csak a vezetékek száma az eltérés, én erre gondoltam a kérdésemben. És a PSP-t sem hiszem, hogy gyorsabb lenne.



Az lett, de szükség is van rá? A 10Mbit-et elhiszem, hogy van, ahol kevés, de a 100-nál többnek én eddig csak akkor láttam értelmét, ha nagy fájlokat másolok egyik számítógépről a másikra. Az persze más kérdés, hogy sok hálókártya a processzorral intéztet ezt-azt, aztán hiába gigabites háló, ha 100%-on megy a processzor már 17MB/s másolástól is... Úgyhogy én valamilyen szinten egyezek a Microchippel, hogy a feladatok nagyon nagy többségére a 10Mbit is bőven jó, a maradékra meg ott 100Mbit. Ha az nem elég, akkor ott már nem PIC-et kell használni, vagy az egész rosszul van kitalálva. Neked mi az, amire 40-50Mbit kell?

RMII-vel a 100-hoz az kellene, hogy ami 50MHz-es órajel van a phy oldalán, az közvetlenül data clock lehessen, és az adatvég eszköz ne tízzel ossza le azt a jelet, mert az olcsóbbik RMII interface azt az 50MHz-et a belső állapotgépéhez használja, és értékes adatjel mintavételezés csak minden tizedik órajelen van - így lesz 10 a 100-ból, még ha kompatibilis is. Süssék meg a kompatibilitást, nekem speed kell

Nem akarom elkiabálni, de ha összejön, akkor egy lehetséges alkalmi munka, és talán több is. Egyenlőre arra kértek meg, komponensek szintjén szedjem össze, miből lehet meggyúrni a cuccot, és próbáljam olcsóra csiszolni. Van egy bit stream szerveren, amit célszerűen etherneten le kell küldeni egy eszköznek, ami lehetségesen megváltoztat benne dolgokat, és ha megváltoztatja, vissza is kell küldeni a szerverre. Dióhéjban ennyi a lényeg. Az eszköz átlagos adat sebessége 25 mbps. Szélső értékeket nem tudok. Ugyan jó nagy fifo-t is terveztem sram-ból, de akkor is nyugodtabb vagyok sokkal gyorsabb ethernettel. Ha valamit rosszul is találtam ebben ki, perpillanat nem érzékelem a hibámat.

Még mindig nem értelek. Azt mondod, hogy ha RMII-vel rákötöm mondjuk a PIC32-re a DP83848-at, akkor hiába mondja magát 100Mbit-nek a kapcsolat, csak 10-el fog menni a valós adatátvitel? Vagy mi ez a minden tizedik órajelen értékes mintavételezés?

Kicsit pontosabban én azon aggódok, hogy még csak nem is fogja magát 100-asnak mondani. Azt gyanítom, hogy a pic32 beépített mac-je _egyáltalán_ nem tud olyan sebességet. Se 2 vonalasan, se 4 vonalasan, se sehogy se. Maximum külső vezérlővel psp-n. Ezért is kérdeztem meg tőled, hogy ha már úgyis egybe gyúrtad a cuccot, és nálad rmii-vel működik, esetleg letesztelted-e a sebességet is? Leginkább nem egy nagy ügy pic-re az mc lib fölé írni egy programot, ami 1kbyte-os udp packeteket hajigál egy fix ip:port-ra (ahol legyen ott a géped valami módon), a gépen pedig egy socket szervert futtatni, ami az elmúlt másodpercekben beérkezett packetokat csak darabra megszámolja. Azt is felkínáltam, hogy segítek a programokkal, ha szükséges. Annyit reagáltál rá, hogy átmenetileg nincs egyben minden a teszteléshez. Részemről meg nem ér meg annyit, hogy külön a nyakadra járjak miatta. (Akár phy, akár psp, a külső tok az külső tok, egymás helyettesítői ebből a szempontból, és még árban is kb ugyan ott vannak: nudli olcsó mindkettő.) Igazából csak érdekesség jelleggel örülnék, ha kiderülne, mi is a szitu a pic32 rmii-jével.

Ha csak ennyi hiányzik a kipróbáláshoz, akkor mostmár lemérhetjük, hogy mi tud. Sosem használtam még UDP-t, de a jövő héten délutánonként ráérek, ha segítesz a pices oldali kóddal, akkor szívesen csinálok tesztet. Használsz valami skype, msn, gtalk-ot? Privátban küldj egy címet, amin el tudjuk érni egymást, úgy gyorsabb lesz, mint fórumon.

Szia potyo!
Elakadtam egy látszólag egyszerű dologban. A webkiszolgáló a PIC-ben van, van fix IP címe, stb. Ha feltöltök egy oldalt a PIC-re, akkor elég a XMLHttpRequest.open metódusában az url-nél a fájl nevét megadni(pl. led.cgi), egyértelmű, hogy melyik IP-re vonatkozik. De ha nem a szerveren szeretném elhelyezni a html-t, hanem mondjuk egy pendrive-on, vagy éppen a gépen fejlesztve, futtatva, akkor ide be kéne írnom az egész elérési utat, azaz IP címet. Ezt valahogy nem fogadja el, pedig normál HTML módon elérem a PIC-ben futó alkalmazásokat így, persze ott nem használom az XMLHttpRequest-et. Lehet, hogy ez csak szerverről megnyitva működik?

Közben megoldódott! Köszi!

Lehet belőle tanulni ?!

Én is kíváncsi lennék. Bár a kérdést sem értem teljesen Abba futottál bele, hogy a böngésző nem enged XMLHttpRequest-et futtatni eltérő domain felé?

A XMLHttpRequest.open metódusa nem fogadta el az IP címet az url helyén. Aztán valahogy még is!
Most ott vagyok elakadva, hogy három böngésző háromféleképpen írja ki, amit a PIC visszaküld a *.cgi-ben válaszként. Egyedül a Mozilla írja jól ki. Mindegyiken ugyanaz a karakterkódolás van beállítva(ISO-8859-2).
Az biztos, hogy a PIC-be még jó adatok vannak, mert soros porton keresztül elküldöm terminálra, ott jól jelenik meg.
Az igaz, hogy a forrásban még nem állítottam be a kódot, most ezzel próbálkozom.

Legjobb lenne mindenhol UTF-8 kódolást használni, mert az XMLHttpRequest azzal dolgozik függetlenül mindentől. Bár ez felvethet egyéb problémákat, de gondolom úgysem akarsz szöveget vágni a PIC-el ékezetes karakterek mentén és hasonló elvetemült dolgokat csinálni.

Hogy néz ki az a háromféle kiírás és hogy néz ki a kód, ami ezt csinálja?

Két helyen lehet karakterkódolást "mondani" a browser számára.
Egyrészt a HTTP fejlécben (Content-Type), másrészt META tagben a dokumentumon belül. Ha mind a kettő szerepel, de a kettő eltér egymástól, akkor véletlenszetű eredményekkel találkozhatsz.

Ezzel a kezdeménnyel kísérletezek, de ezt legalább már én raktam össze. Meg kellett tanulnom a javascriptet, a DOM-ot, a HTML-t és pár egyéb témával összefüggő dolgot, de nem sok időm van rá. Ezért elég lassan haladok, de legalább már van fény az alagút végén!
A PIC oldali dolgokat is meg kellett fejtenem, részben kezdem átlátni, mi miért van, de még ott is vannak foltok.

Szia!

Csak gyorsan rápislantottam a kódodra. A feldolgozandó XML-nek is megfelelő kódolásúnak kell lennie! Sokszor futottam már bele abba, hogy az XML fejlécbe UTF-8 volt beírva, de ANSIként volt elmentve az XML fájl, ami miatt értelmezésbeli problémák voltak. Így első blikkre neked is valami hasonló gondod lehet, mivel a html fejléced rendben lévőnek tűnik.

Egy *.cgi kiterjesztésű szöveges fájl van hozzárendelve a callback-hez. Ez van benne:


Esetleg a PIC programja keverhet el valamit a TCPPutArray() -ban. ?

Itt van néhány kép az eredményekről:

Ez szerintem pontosan attól van, hogy keveredik az ISO-8859-2 és az UTF8 kódolás, mivel az XMLHttpRequest UTF8-at használ mindenképpen. Ki tudod úgy próbálni, hogy átállítod a böngésződben az oldal kódolását kézzel UTF8-ra (ekkor a Küldés gomb felirata és az "itt jelenik meg a válaszüzenet" lesz majd hibásan kimutatva, de ez lényegtelen), és úgy megpróbálsz beírni ékezetes karaktereket a mezőbe. Úgy már szerintem minden böngészőben jó lesz a picből visszajött és megjelenített szöveg. A következő lépés, hogy az index.html fájlodat átkonvertálod BOM nélküli UTF8 kódolásúra (ez ha Notepad++-t használsz, akkor Kódolás->Átalakítás UTF8 kódolásra BOM nélkül), és akkor már a statikus szövegek is jók lesznek.

Hogy a PIC is jó headert küldjön, ha minden igaz, akkor a Microchip/TCPIP Stack/HTTP2.c fájlban kell ezt a részt:

lecserélni erre:


Ki nem próbáltam, de elvileg ez kellene.

Illetve a meta tagban is UTF8-at kell beállítani. Ez az ilyenolyan ISO meg ANSI kódolás ma már túlhaladott az interneten.

Szia! Köszi, kipróbálom délután!
Azt írod, az XMLHttpRequest UTF-8-at használ. A fura az, hogy a .send() is ennek a metódusa, még is a PIC-be jó kód érkezik, legalább is a soros vonalon visszaküldött bájtokat a terminál jól jeleníti meg. Igaz nem néztem, hogy a terminál mire van állítva, illetve, hogy lehet-e állítani a kódolását. Megnézem majd, hogy a karakter kód értéke más-e, mint amit elvileg elküldtem. Fel kell hajtanom az eltérő kódtáblákat...
Aki ezt kitalálta! Elég sok ilyen ócska dolgot használunk, ami csak azért működik még, mert nagyon fájna változtatni rajta egy húzással. Ilyen a PC architektura is...

Ethernetes fejlesztéshez szerintem nélkülözhetetlen dolog egy Ethernet sniffer használata, akár mikrokontrollerre fejleszt az ember, akár PC-re, vagy bármi másra.
Nekem a kedvencem: Wireshark.
Így nem kell találgatni, hogy vajon mit küldött a PIC, mit küldött a PC.

Ezt nem ismertem, köszönöm, hasznos lesz!

Szia!
Kipróbáltam a kódot, látszólag semmi nem változott.
Viszont megnéztem az adatfogalmat(köszi _vl_!). Az ö helyén a kódja 0xf6 küldődik és ez is lesz visszaküldve. Úgy tűnik nem itt lesz a baj, hanem a megjelenítéssel a DOM-ban.

A DOM kezelés az így jó. Szerintem továbbra sem jó a karakterkódolás valahol. Átállítottál mindent UTF8-ra? Milyen kódolásúnak ismeri fel az oldalt a böngésző, ha automatikuson hagyod? Chrome-ban nyisd meg a kontrollerről az oldalt, nyomj F12-t, majd frissítsd az oldalt, és nézd meg, hogy a képen látható helyen (azzal, hogy nálad az index.html-t válasz ki a baloldali listából), a Response headers alatt a Content-Type-nál pontosan az szerepel-e, ami itt a képen.

Szia watt!

Ajánlom figyelmedbe az alábbi szösszenetet:
responseText vs. nem UTF-8 kódtábla

Amúgy ha már Wiresharkolsz, akkor érdemes a szűrökkel is megismerkedned, mert nagyon jól lehet vele adatforgalmat figyelni (meg persze jelszavakat szerezni ). Nekem egyik kedvenc szűrőm TCP-IP forgalom figyelésénél az ip.src == ipcím, illetve ip.dst == ipcím no és persze az egyéb szűrőkkel simán vegyítheted a szokásos && (és), || (vagy) logikai kapcsolatokkal kedved szerint.

Gondolom az nem jelent eltérést, ha kisbetűvel van írva a kódolás:


Nem tudtam, hogy a chrome ilyeneket tud, nem rossz!

De közben a chrome-alatt jó lett, de az IE9 alatt még mindig nem.

Próbáltam így is:

Hátha a kezelés hibádzik. Ekkor a chrome és a fox nem működött(érthetően), az IE9 ugyanúgy rosszul!

IE alatt nem állítottad be véletlenül kézzel a karakterkódolást, és úgy maradt?

Ha ez azt mutatja, akkor nem, mert auton van és az utf-8-at választotta.

Az ie és az ff fejlesztőeszközeit is érdemes használgatnod. (ie esetén F12, ff-ben nem tudom van-e gyorsgomb hozzá)
Ezekben anélkül tudod a forrást módosítgatni, hogy közben az eredeti is megváltozna, de a változtatásaidat rögtön látni fogod, hogy mit eredményeznek. (Én sokat használom őket weboldalak alakításánál.)