A Microchip TCP/IP Stack implementációjának alkalmazása a gyakorlatban

Átírás

1 A Microchip TCP/IP Stack implementációjának alkalmazása a gyakorlatban Ivanov Péter május 18.

2 i Tartalomjegyzék 1. Bevezető Köszönetnyilvánítás Soros vonal 3 3. A TCP/IP Stack felépítése A Stack rétegei User Datagram Protocol (UDP) 7 5. A TCP/IP Stack konfigurálása 9 6. A TCP/IP Stack moduljai Address Resolution Protocol modul ARP funkciók ARPTask funkciók User Datagram Protocol (UDP) modul Stack Manager modul A soros-udp átalakító modul HTTP szerver modul Dinamikus honlap generálás HTTP CGI Microchip fájlrendszer (MPFS) MPFS kép készítése MPFS könyvtár FTP szerver modul MPFS kép feltöltése FTP kliens segítségével Hardver Alkatrészek PIC18F452 mikrovezérlő RTL8019AS ethernet vezérlő LC256 típusú soros EEPROM MAX232A soros vonali illesztő

3 ii 8. Az eszköz használata és tesztelése Az eszköz használata Konfigurálás böngészőprogrammal Hálózat beállítása Soros vonal beállítása Statisztika Az eszköz tesztelése

4 iii Ábrák jegyzéke 1.1. A rendszer blokkvázlata Egy bájt átvitele soros vonalon A TCP/IP referencia modell rétegei A referencia modell és a Microchip TCP/IP Stack rétegei UDP csomag felépítése Az elő-fejléc felépítése A Stack Manager algoritmusának folyamatábrája A Serial2UDP_GetSerialData függvény folyamatábrája A Serial2UDP_ProcessUDPData függvény folyamatábrája Űrlapok kezelése MPFS képfájl felépítése MPFS FAT bejegyzés felépítése MPFS adatblokk felépítése MPFS képfájl feltöltése FTP kliens segítségével Soros vonali illesztő és tápfeszültség stabilizátor kapcsolási rajza A PIC18F452 típusú mikrovezérlő lábkiosztása A 24LC256 típusú soros EEPROM lábkiosztása A MAX232 típusú soros vonali illesztő lábkiosztása A doboz oldal- és elölnézete Az eszköz használata Konfigurálás böngészőprogrammal: index Hálózat beállítása böngészőprogrammal Soros vonal beállítása böngészőprogrammal Statisztika megtekintése böngészőprogrammal Az eszköz tesztelése Az UDP test program

5 iv Táblázatok jegyzéke 5.1 Konfigurációs definíciók ill. változók TCP/IP Stack moduljai A soros-udp átalakító modul konfigurációs változói A soros-udp átalakító modul belső változói A soros-udp modul átalakító állapotai

6 1 1. fejezet Bevezető Manapság az ethernet hálózat elterjedését láthatjuk a hétköznapi használatban és az iparban egyaránt. A csavart érpáros kábelek nagy távolságra vezethetők, olcsók, könnyen szerelhetők és az árnyékolatlan kábelek (UTP) is relatíve érzéketlenek az elektromos zavarokra, de ipari alkalmazásban általában árnyékolt kábeleket (STP) használnak. A most bemutatásra kerülő rendszerrel egyszerűen és gyorsan képessé tehetjük PIC mikrokontrolleres alkalmazásunkat, hogy kommunikáljon az intraneten vagy interneten. E szakdolgozatban egy a valóságban is felhasználható alkalmazást mutatok be, hogyan illeszthetjük a soros vonalon kommunikáló régebbi fejlesztésű eszközünket ethernet hálózathoz. A rendszer leegyszerűsített blokkvázlata az 1.1. ábrán látható ábra. A rendszer blokkvázlata A Microchip kifejlesztette a PIC18-as mikrokontroller családhoz a TCP/IP Stack-et és egy komplett web szervert. Fejlesztéseit szabadon hozzáférhetővé tette és letölthető az internetről. Ezeket a forráskódokat használtam fel. A programcsomaggal egy HTTP szervert építhetünk, aminek honlapját FTP-n frissíthetjük. Szükség van egy PIC 18-as mikrovezérlőre, egy NIC-re (például Realtek 8019AS). Kell még egy C fordító, a program lefordításához. Én a PIC C18 demó verzióját használtam. Érdemes letölteni az MPLAB legfrissebb verzióját. Ez egy integrált

7 2 fejlesztői környezet (IDE) amiben szerkeszthetjük a forrásfájlokat, lefordíthatjuk a programot és fel is tölthetjük a mikrovezérlőbe. Kell még egy PIC programozó is. Én az ICD2 nevezetű programozó és nyomkövető eszközt használtam. A szögletes zárójelben levő számokkal mindig az irodalomjegyzékben szereplő dokumentumokra hivatkozok Köszönetnyilvánítás Ezúton szeretném megköszönni Dr. Kónya László tanár úrnak és Kolinger Attilának a segítséget és a fejlesztéshez nélkülözhetetlen eszközöket.

8 3 2. fejezet Soros vonal Elsősorban az RS-232C szabványról lesz szó ebben a fejezetben. Ez az adatátviteli forma széles körben elterjedt és még most is nagyon sok eszköz használja az iparban és a számítástechnikában ezt a módszert. Az RS232 hátrányai közé tartozik, hogy aszimetrikus, tehát közös a föld, ezért zaj érzékeny és csak kis távolságra vezethető. Nagyobb távolságok áthidalására az RS-422 ill. RS-485 szabványú adatátvitel használható. Az átvitel aszinkron, full duplex és a bájtok átvitele mindig egy start bit elküldésével kezdődik, ezt követi 5 9 darab adatbit végül egy, másfél vagy kettő stop bit. A kilencedik bit lehet paritás bit is vagy a cél eszköz megcímzésére használhatjuk. A kilencedik bitet alapesetben RS-232C kapcsolatnál címzésre használni nem lehet (de lehet például az RS-422-nél és RS-485-nél). A legelterjedtebb a 8n1 típusú átvitel, ahol 8 adatbit egy stop bit küldése ill. fogadása lehetséges, paritás nélkül. Az általam elkészített program is ebben a formátumban kezeli az adatokat. Az adatátviteli sebesség 75, 150,..., 2400, 4800, 9600, 19200, 38400, 57600,... baud lehet. A baud az átvitt jel értékében történő változások száma egy másodperc alatt. Tehát a sebesség megadásánál a baud mértékegység nem egyezik meg a bit/másodperccel, mert az utóbbiba nem értendő bele a start-, stop- és paritás bitek átvitele. Egy bájt (0xC8) átvitele látható a 2.1. ábrán (TTL szintűek a jelek) ábra. Egy bájt átvitele soros vonalon

9 4 3. fejezet A TCP/IP Stack felépítése Számos TCP/IP implementáció követi a TCP/IP referencia modell nevű szoftver architektúrát. Azok a programok, amik erre a modellre alapulnak több rétegre vannak osztva, ezek a rétegek egymásra épülnek 1 és minden réteg egy vagy több alatta lévő réteggel kommunikál. A TCP/IP referencia modell a 3.1. ábrán látható ábra. A TCP/IP referencia modell rétegei A TCP/IP rétegek aktívak, vagyis nem csak akkor működnek, ha kérés érkezik egy szolgáltatáshoz, hanem akkor is, időtúllépés történt vagy egy új csomag érkezett. Egy olyan rendszer, ahol sok adat- és programmemória áll rendelkezésre könnyen teljesíti a kéréseket. Egy multitaszkos operációs rendszer extra képességei lehetővé teszik, hogy az implementáció moduláris legyen. A program viszont bonyolult lesz, ha csak egy 8 bites mikrovezérlő áll rendelkezésre néhány száz bájt RAM-mal és korlátozott programmemóriával. Továbbá, egy multitaszkos operációs rendszer nélkül sok időt kell arra fordítani a programozás során, hogy a Stack független maradjon a fő alkalmazástól. Relatíve könnyű elkészíteni és helytakarékos az a TCP/IP Stack, amely bele van integrálva a fő alkalmazásba. De sok probléma léphet fel, amikor újabb funkciókat szeretnénk a programhoz hozzáadni. 1 Az egymásra épülést angolul a stacked szóval fejezik ki, ezért hívják TCP/IP Stack-nek.

10 5 Ez a TCP/IP Stack moduláris, C programozási nyelven íródott és a Microchip C18 és a HiTech PICC 18 fordítókkal is lefordítható. A forrásfájl automatikusan eldönti, hogy milyen fordítóval szeretnénk fordítani. A két fordító közötti különbségekből eredő problémákat a compiler.h fájlban levő definíciókkal küszöböljük ki. Ez a TCP/IP Stack csak PIC 18-as mikrovezérlőkön fut A Stack rétegei A 3.2 ábrán is látható, hogy a Microchip TCP/IP Stack is különböző rétegekre van osztva. A kód úgy lett megírva, hogy minden réteg külön forrásfájlban van, míg az API 2 külön fejlécfájlban van ábra. A TCP/IP referencia modell és a Microchip TCP/IP Stack rétegeinek összehasonlítása Ellentétben a referencia modellel, a Microchip TCP/IP Stack-ben egyes rétegek nem csak a közvetlenül alatta levő réteget érik el. A legnagyobb különbség a hagyományos TCP/IP Stack implementációtól két új modul: StackTask és az ARPTask. A StackTask vezérli a Stack összes moduljának működését az ARPTask pedig az ARP réteg szolgáltatásait valósítja meg. Ez a Stack az általánosan ismert kooperatív multitaszk technikát alkalmazza, hogy független legyen a fő alkalmazástól. Egy kooperatív multitaszkos rendszerben több taszk működik, minden taszk végrehajt egy feladatrészt, majd a vezérlést visszaadja és a következő taszk fut. Ebben az értelmezésben a StackTask és az ARP- Task egy-egy kooperatív taszk. A főprogramba vagy az operációs rendszerbe is lehet implementálni a kooperatív vagy más típusú multitaszkot megvalósító kódot. A Stack úgy lett megtervezve, hogy független legyen bármilyen operációs rendszertől, vagyis saját kooperatív multitaszk rendszere van. Ennek eredményeként használható bármilyen rendszerben függetlenül attól, hogy használ-e multitaszkos operációs rendszert vagy sem. Azonban, ha a saját alkalmazásunk használja ezt a 2 Application Programming Interfaces, vagyis a felhasználói program interfész.

11 6 TCP/IP Stack-et, alkalmaznunk kell a kooperatív multitaszk technikát a saját taszkjaink megírásakor. Ez elérhető úgy is, hogy a feladatot több taszkra osztjuk vagy a feladatot egy FSM-nek (Finite State Machine, Véges Állapotú Automata) továbbítjuk ami a feladatot sok kis részfeladatra bontja és egymás után futtatja le őket. A HTTP szerver az utóbbi megoldást használja. Jegyezzük meg, hogy ebben a TCP/IP Stack-ben nincs implementálva az összes olyan modul, ami egy átlagos TCP/IP Stack-ben implementálva van, de ha szükség van egy olyan funkcióra, ami nincs implementálva, bármikor megírható külön taszkként vagy modulként.

12 7 4. fejezet User Datagram Protocol (UDP) Az RFC 768-as [2] dokumentumban található az UDP protokoll leírása. Ez a protokoll az Internet Protocol-ra (IP) épül. Előnye, hogy a programok nagyon egyszerűen küldhetnek és fogadhatnak üzeneteket, de nincs garantálva, hogy az üzenet nem veszik el ill. nem duplázódik. Azok az alkalmazások amelyeknél adatfolyamok megbízható továbbítására van szükség, a Transmission Control Protocol-t (TCP) használják ábra. UDP csomag felépítése Az UDP csomagok felépítése a 4.1. ábrán látható. A forrás port opcionális mező, akkor érdemes használni, ha a csomagot küldő folyamat választ vár. Ha nincs használva, nullát kell a helyére írni. A cél port a cél címen belül egy folyamatot vagy programrészt jelent, de lehet más jelentése is. A hossz a csomag oktetjeinek számát mutatja meg, beleértve a fejlécet és az adatokat is. Tehát a legkisebb érték, amit felvehet: nyolc. Az ellenőrző összeg az IP fejlécből készült elő-fejléc, az UDP fejléc és az adat egyes komplemense 16 bitre kiegészítve. Azért hívják elő-fejlécnek, mert az IP fejlécből másolódnak az adatok. Az elő-fejléc (4.2. ábra) az UDP fejléc előtt van és tartalmazza a forrás- és célcímet, protokoll típusát és az UDP csomag hosszát. Ez az információ véd az eltévedt csomagok ellen. Az ellenőrző összeg számítása hasonlít a TCP-ben használt ellenőrző összeg számításhoz. Ha a kiszámított ellenőrző összeg nulla, akkor az összeg egyes komplemense lesz elküldve (FFFFh). Ha az ellenőrző összegként nullát küld a forrás, az azt jelenti, hogy

13 ábra. Az elő-fejléc felépítése a küldő nem számolt összeget. Nyomkövetéskor alkalmazható vagy, ha a felsőbb szintű protokollok nem használják ezt az összeget. Ebben a TCP/IP Stack-ben az ellenőrző összeg számítás nincs implementálva. Az UDP modulnak ismernie kell a forrás és cél internet címét és a protokoll típusát. Ezt a protokollt használják az internetes név szerverek (DNS) és Trivial File Transfer Protocol (TFTP). Ha az Internet Protocol-on belül használjuk az UDP-t, akkor az a 17-es (oktálisan 21) számú protokoll.

14 9 5. fejezet A TCP/IP Stack konfigurálása Ez a kooperatív multitaszk rendszer lehetővé teszi, hogy a felhasználói alkalmazás saját taszkokat futtasson. Eközben a TCP/IP Stack-kel nem is kell foglalkoznia. Ehhez természetesen az kell, hogy a felhasználó úgy írja meg programját, hogy a kooperatív multitaszkos rendszerben működjön. Az egyszerű konfigurálás érdekében a program C definíciókat használ. A legtöbb paraméter engedélyezése, tiltása vagy beállítása a StackTsk.h fejléc fájlban lehetséges. Azok a paraméterek, amelyek más fájlban találhatóak, azoknak zárójelben megadom a fájl nevét. Ha valamelyik paramétert változtattuk, a projektet vagy egyes részeit újra kell fordítani 1. Azonosító Értékek Használ Megjegyzés CLOCK_FREQ (compiler.h) Órajel Tick.c Definiálja a rendszer órajel frekvenciáját, hogy frekv. (Hz) ki lehessen számolni az időzítő számláló értékét. TICKS_PER_SECONDS Tick.c Egy másodperc hány TICK_PRESCALE_VALUE 2, 4, 8, 16, 32, 64, 128, 256 taktusból áll. Tick.c Időzítéshez milyen előosztó legyen beállítva. MPFS_USE_PGRM - MPFS.c Ha a programmemóriát akarjuk használni adattárolásra. MPFS_USE_EEPROM - MPFS.c Ha külső soros EEPROM-ot akarunk adattárolásra használni. MPFS_RESERVE_BLOCK MPFS.c Az MPFS fájlrendszer előtt fenntartott bájtok száma. EEPROM_CONTROL Külső mem. kódja MPFS.c Hogy meg tudjuk címezni a külső EEPROMot. 1 Az MPLAB fejlesztői környezet érzékeli a változtatásokat és kezeli a függőségeket, csak azt fordítja le, ami szükséges.

15 10 Azonosító Értékek Használ Megjegyzés STACK_USE_ICMP - StackTsk.c Ha nincs szükség ICMP-re, ne definiáljuk. STACK_USE_SLIP - SLIP.c Ha nincs szükség SLIPre ne definiáljuk. STACK_USE_IP_GLEANING - StackTsk.c Ha nincs szükség IP Gleaning-re ne definiáljuk. STACK_USE_DHCP - DHCP.c, Ha nincs szükség DHCPre ne definiáljuk. StackTsk.c STACK_USE_FTP_SERVER - FTP.c Ha nincs szükség FTP STACK_USE_TCP - TCP.c, StackTsk.c STACK_USE_UDP - UDP.c, StackTsk.c STACK_CLIENT_MODE - ARP.c, TCP.c szerverre ne definiáljuk. Ha nincs szükség TCPre ne definiáljuk. Automatikusan engedélyezi, ha valamelyik modulnak szüksége van TCP-re. Ha nincs szükség UDPre ne definiáljuk. Automatikusan engedélyezi, ha valamelyik modulnak szüksége van UDP-re. Ha definiáljuk a kliens módú függvények engedélyeződnek. TCP_NO_WAIT_FOR_ACK - TCP.c A TCP várjon vagy ne az ACK-re a következő csomag küldése előtt. MY_DEFAULT_IP_ADDR_BYTE? felh. alk. Alap IP: MY_DEFAULT_MASK_BYTE? felh. alk. Alap netmaszk: MY_DEFAULT_GATE_BYTE? felh. alk. Alap átjáró: MY_DEFAULT_MAC_BYTE? felh. alk. Alap MAC: 00:04:163:00:00:00 MY_IP_BYTE? felh. alk. Aktuális IP. Ha DHCP engedélyezett akkor a szerver által adott konfiguráció. MY_MASK_BYTE? felh. alk. Aktuális netmaszk. MY_GATE_BYTE? felh. alk. Aktuális átjáró. MY_MAC_BYTE? felh. alk. Aktuális MAC.

16 11 Azonosító Értékek Használ Megjegyzés MAX_SOCKETS TCP.c Definiálja, hogy hány TCP socket használható (a RAM mennyiségétől függ). Fordítás közben ellenőrzi, hogy elegendő-e a TCP moduloknak a megadott érték. MAX_UDP_SOCKETS UDP.c Definiálja, hogy hány UDP socket használható (a RAM mennyiségétől függ). Fordítás közben ellenőrzi, hogy elegendő-e a UDP moduloknak a megadott érték. MAC_TX_BUFFER_SIZE TCP.c, MAC.c Definiálja a küldő puffer méretét. MAX_TX_BUFFER_COUNT MAC.c Definiálja a küldő pufferek számát. MAX_HTTP_CONNECTIONS HTTP.c Definiálja az egyszerre fenntartható HTTP kapcsolatok számát. MPFS_WRITE_PAGE_SIZE MPFS.c Definiálja a lapméretet (MPFS.h) az MPFS fájlrendszerhez. FTP_USER_NAME_LEN (FTP.h) 1-31 FTP.c Definiálja az FTP felhasználónév maximális hosszát. MAX_HTTP_ARGS (HTTP.c) 1-31 HTTP.c Definiálja az űrlapok mezőinek maximális számát, beleértve a mező nevét is. MAX_HTML_CMD_LEN (HTTP.c) HTTP.c Definiálja az űrlappal átadható sztring maximális hosszát. STACK_USE_SER2UDP - ser2udp.c Ha nincs szükség a soros-udp átalakító modulra ne definiáljuk. TARGET_DEFAULT_ ser2udp.c Alap cél IP cím: IP_ADDR_BYTE? (ser2udp.h DEFAULT_TARGET_PORT (ser2udp.h ser2udp.c Alap cél port: 2222.

17 12 Azonosító Értékek Használ Megjegyzés DEFAULT_LOCAL_PORT ser2udp.c Alap forrás port: (ser2udp.h INITWAIT_SEC (ser2udp.h ser2udp.c ARP kérés előtti várakozás ideje másodpercben. TIMEOUT_SEC (ser2udp.h SER2UDP_USE_INTERRUPT (ser2udp.h Alap: 4. ser2udp.c ARP kérés után hány másodpercig vár a válaszra. Alap: 4. - ser2udp.c A soros adatok vételéhez használjon-e megszakítást a modul táblázat: Konfigurációs definíciók ill. változók A fejlesztés során egy projektet érdemes használni. Projekt fájlból is van előre elkészített a programcsomagban. Én az MPNICEE.pjt fájlt használtam. Ezt a fájlt akkor érdemes használni, ha a Microchip C18 fordítót Realtek NIC-et és külső soros EEPROM-ot használunk, továbbá szükségünk van HTTP, FTP szerverre és ICMP-re. Ugyanis ezeket tudja alapból az a program, amit ezzel a projekt fájllal fordítunk. Fontos megjegyezni, hogy a projekt fájlokban is lehet definíciókat megadni.

18 13 6. fejezet A TCP/IP Stack moduljai A moduláris felépítés miatt könnyen beállíthajuk, hogy milyen szolgáltatásokra van szükségünk. Egy modul letiltása csak annyiból áll, hogy a megfelelő definíció elé egy megjegyzés jelet teszünk és a forrásfájlokat eltávolítjuk a projektből. A TCP/IP Stack moduljainak rövid áttekintése: Modul Fájl szükséges Leírás MAC MAC.c, Delay.c Közeghozzáférési réteg SLIP SLIP.c Közeghozzáférési réteg SLIPhez ARP ARP.c, ARPTsk.c, MAC.c Address Resolution Protocol vagyslip.c, Helpers.c IP IP.c, MAC.c vagy SLIP.c, Internet Protocol ICMP TCP UDP Stack Manager HTTP Server DHCP Client Helpers.c ICMP.c, StackTsk.c, IP.c, MAC.c vagy SLIP.c, Helpers.c StackTsk.c, TCP.c IP.c, MAC.c vagy SLIP.c, Helpers.c, Tick.c StackTsk.c, UDP.c, IP.c, MAC.c vagy SLIP.c, Helpers.c StackTsk.c, TCP.c, IP.c, ICMP.c, ARPTsk.c, ARP.c, MAC.c vagy SLIP.c, Tick.c, Helpers.c HTTP.c, TCP.c, IP.c, MAC.c vagy SLIP.c, Helpers.c, Tick.c, MPFS.c, XEEPROM.c DHCP.c, UDP.c, IP.c, MAC.c, Helpers.c, Tick.c Internet Control Message Protocol Transmission Control Protocol User Datagram Protocol Stack Manager (StackTask), ami vezérli a TCP/IP Stack moduljait. HyperText Transfer Protocol szerver Dynamic Host Configuration Protocol

19 14 Modul Fájl szükséges Leírás IP Gleaning StackTsk.c, ARP.c, IP cím konfiguráláshoz ARPTsk.c, ICMP.c, MAC.c vagyslip.c FTP Server FTP.c, TCP.c, IP.c, File Transfer Protocol szerver MAC.c vagyslip.c Serial2UDP ARP.c, UDP.c, MAC.c vagy Soros-UDP átalakító SLIP.c 6.1. táblázat: TCP/IP Stack moduljai Most a soros-udp átalakító modul által használt modulok részletes leírása következik. Az itt nem tárgyalt modulok (MAC, SLIP, IP, ICMP, TCP, DHCP) angol nyelvű leírása az AN833-as [1] dokumentumban található Address Resolution Protocol modul Az ARP modul gondoskodik arról, hogy az IP címekből megtudjuk, hogy milyen hardveres cím (MAC cím) tartozik hozzá és hogy más eszközök az IP címünket tudva, megkapják a MAC címünket. Az Microchip TCP/IP Stack-jének ARP rétege két modulból áll: ARP.c és ARP- Task.c. Az ARP modulban (ARP.c) az ARP alapvető függvényeit definiálja. Az ARP- Task ami az ARPTsk.c fájlban található ezeket a függvényeket felhasználva valósítja meg az ARP szolgáltatást. Az ARPTask válaszol az ARP kérésekre és egy egyszintű tárban tárolja a más hosztok ARP válaszát. Az ARPTask modulban nincs megvalósítva az időtúllépés kezelése, ezt a felsőbb szintű modulokban kell megoldani. Az ARPTask kétféle módban működhet: szerver illetve szerver/kliens. A szerver/kliens módban lehetséges ARP kérések generálása. Szerver módban ez a kódrész nincs befordítva. Általában az alkalmazások szerver módban futnak és érdemes is szerver módba fordítani, a kód méretének csökkentése érdekében. Továbbá szerver módban nem kerül lefoglalásra az egyszintű tár és ezzel RAM területet takaríthatunk meg. Ha a STACK_CLIENT_MODE definiálva van szerver/kliens módban fog működni az ARPTask modul. A soros-udp konverter szerver/kliens módban használja az ARP modult ARP funkciók ARPIsTxReady Ez egy makró ami megállapítja, hogy adatok küldése lehetséges-e. Szintaxis:ARPIsTXReady() Paraméter: Nincs Visszatérési érték: IGAZ: Ha legalább egy küldő puffer üres. HAMIS: Nincs üres küldő puffer. Előfeltétel: Nincs

20 15 Mellékhatás: Nincs Megjegyzés: Ez csak egy makródefiníció amacistxready függvényre. Példa: // Ha a küldő puffer üres, elküldünk egy ARP csomagot if ( ARPIsTxReady() ) // ARP csomag küldése ARPPut(&RemoteNode, ARP_REPLY); } ARPGet Ez a funkció beolvas egy ARP csomagot és visszatéréskor megadja a szükséges információkat a csomagról. Szintaxis: BOOL ARPGet(NODE_INFO *remote, BYTE *opcode) Paraméter: remote [kimenő] A távoli eszközhöz tartozó információk, a MAC és az IP cím. opcode [kimenő] ARP kód. A paraméter lehetséges értékei a következők: ARP_REPLY Egy ARP válasz csomag érkezett ARP_REQUEST Egy ARP kérés csomag érkezett ARP_UNKNOWN Egy ismeretlen ARP csomag érkezett Visszatérési érték: IGAZ: Ha egy érvényes ARP csomag érkezett és az a mi eszközünknek van címezve. HAMIS: Ha ismeretlen ARP kódja van a csomagnak vagy nem nekünk van címezve a csomag. Előfeltétel: MACGetHeader már meg volt hívva és a kapott MAC csomag típusa MAC_ARP Mellékhatás: Nincs Megjegyzés: Ez a funkció azt feltételezi, hogy az aktív pufferben van egy ARP csomag és a hozzáférési mutató az ARP csomag elejére mutat. Általában a magasabb szintű rétegek ellenőrzik a MAC puffert és csak akkor hívják ezt a függvényt, ha ARP csomagot érzékeltek. Ez a funkció beolvassa az egész ARP csomagot és felszabadítja az aktív puffert. Példa: // Ha MAC csomag érkezett if ( MACGetHeader(\&RemoteNode, \&PacketType) ) \ // Ha ez egy ARP csomag, beolvassuk if ( PacketType == MAC\_ARP ) \ // Ez egy ARP csomag ARPGet(\&RemoteNode, \&ARPCode);

21 16 ARPPut Ez a funkció feltölti a MAC puffert egy érvényes ARP csomaggal. Szintaxis: void ARPPut(NODE_INFO *remote, BYTE opcode) Paraméter: remote [bemenő] A távoli eszköz adatai, mint a MAC és az IP cím opcode [bemenő] ARP kód. Lehetséges értékei a következők: ARP_REPLY ARP válaszként küldi el a csomagot ARP_REQUEST ARP kérésként küldi el a csomagot Visszatérési érték: Nincs Előfeltétel: ARPIsTxReady == TRUE Mellékhatás: Nincs Megjegyzés: Felépíti az ARP csomagot és elküldi. Példa: // Megnézzük, hogy küldő puffer elérhető-e if ( ARPIsTxReady() ) // Igen, elküldjük ARPPut(&RemoteNode, ARP_REQUEST); } ARPTask funkciók ARPInit Ez a funkció inicializálja az ARPTask modult és előkészíti az ARP kérések küldésére és megválaszolására. Szintaxis:void ARPInit() Paraméter: Nincs Visszatérési érték: Nincs Előfeltétel: Nincs Mellékhatás: Nincs Megjegyzés: Szerver/kliens módban ez a funkció inicializálja az egyszintű tárolót. Példa: // Initialize ARPTask ARPInit(); ARPResolve Ez a funkció egy ARP kérést küld egy távoli eszköznek. Szintaxis: void ARPResolve(IP_ADDR *IPAddr) Paraméter: IPAddr [bemenő] A távoli eszköz IP címe, aminek a MAC címét szeretnénk tudni. Visszatérési érték: Nincs Előfeltétel: ARPIsTxReady == TRUE

22 17 Mellékhatás: Nincs Megjegyzés: Ez a funkció csak szerver/kliens módban elérhető. Példa: // Ellenőrizzük, hogy a küldő puffer elérhető-e if ( ARPIsTxReady() ) // ARP kérés küldése ARPResolve(\&RemoteNodeIP); } ARPIsResolved Ez a funkció ellenőrzi a belső tárolót és visszatérési értékként megadja a cél hoszt MAC címét. Szintaxis: BOOL ARPIsResolved(IP_ADDR *IPAddr, MAC_ADDR *MACAddr) Paraméter: IPAddr [bemenő] A távoli eszköz IP címe, aminek a MAC címét szeretnénk tudni. MACAddr [kimenő] A puffer ami a távoli hoszt MAC címét fogja tárolni. Visszatérési érték: IGAZ: Ha egyező IP cím van a belső tárolóban és az átmásolódott a MACAddr változóba. HAMIS: Ha nincs egyező IP cím a belső tárolóban. Ilyenkor a MACAddr értéke nem változik. Előfeltétel: Nincs Mellékhatás: A belső tárolóból az átmásolt adatok eltávolításra kerülnek. Megjegyzés: Az ARPTask csak egyszintű tárolóval dolgozik, ezért a felsőbb rétegnek kell arról gondoskodnia, hogy másik ARP kérést ne küldjön, míg az előzőre nem érkezett válasz. Ez a funkció csak szerver/kliens módban elérhető. Példa: // Ellenőrizzük, hogy érkezett-e válasz if ( ARPIsResolved(&RemoteIPAddr, &RemoteMACAddr) ) // MAC cím megvan. Más feladat következhet } else // Még nincs meg a MAC. Várunk } 6.2. User Datagram Protocol (UDP) modul Az UDP réteg azudp.c fájlban van implementálva. A fejléc fájlban (UDP.h) vannak definiálva a réteg szolgáltatásai. Ebben a Stack architektúrában az UDP egy aktív

23 18 réteg. Veszi az UDP csomagot és a megfelelő UDP socket-et értesíti az adat érkezéséről. Az UDP modul kooperatív taszkként van implementálva és automatikusan működik a fő alkalmazástól függetlenül. A réteg legfeljebb 254 UDP socket-et használhat. Ez az érték csak az elérhető memóriától és a fordítótól függ. Több socket használatával több szimultán UDP kapcsolat használható. Fontos megjegyezni, hogy minden socket körülbelül 19 byte memóriát használ (érdemes ellenőrizni az UDP.h fájlt) és minden socket növeli az UDP csomagok feldolgozásának idejét. Ellentétben a többi socket implementációtól, a Microchip TCP/IP Stack-ben minden socket egy küldő puffert használ. Ez csökkenti a RAM szükségletet, de problémát okozhat, ha néhány socket nem szabadítja fel a küldő puffert. Ebben az esetben a távoli hosztok és/vagy helyi alkalmazások nem tudnak kapcsolatba lépni az eszközzel. Ennek elkerülése érdekében a felhasználónak gondoskodnia kell arról, hogy az összes socket számára elegendően nagy puffer álljon rendelkezésre. A vételi oldalon is csak egy puffer van, ezért ha adatot olvasunk, az összes adatot be kell olvasni egy taszkban és üríteni a puffert, hogy a többi socket is tudja olvasni az adatát. Nem lehet azt tenni, hogy a taszk csak a puffer egy részét olvassa be és majd egy következő hívás esetén dolgozza fel a maradékot. A Microchip TCP/IP Stack-ben nincs implementálva az UDP ellenőrző összeg képzés. Az ellenőrző összeg helyére mindig nulla érték kerül. Ezért minden UDP-t használó modulnak magának kell gondoskodnia az adatok integritásáról. UDPInit Ez a funkció inicializálja az UDP modult és előkészíti a többszálú UDP kapcsolatokra. Szintaxis:void UDPInit() Paraméter: Nincs Visszatérési érték: Nincs Előfeltétel: Nincs Mellékhatás: Nincs Megjegyzés: Ezt a függvényt csak egyszer kell meghívni. Példa: // Initialize UDP UDPInit(); UDPOpen Ez a funkció előkészíti egy UDP socket-et, hogy a megadott porton adatokat tudjon továbbítani. Szintaxis: UDP_SOCKET UDPOpen(UDP_PORT localport, NODE_INFO *remotenode, TCP_PORT remoteport) Paraméter: localport [bemenő] A helyi UDP port, ahonnan az adat jön. remotenode [bemenő] A távoli hoszt, ahova az adatokat küldjük. remoteport [bemenő] A távoli hoszt egy UDP portja, ahova az adatokat küldjük.

24 19 Visszatérési érték: Egy érvényes socket azonosító, ha volt szabad socket vagy INVALID_UDP_SOCKET, ha nem volt szabad socket. Előfeltétel: Nincs Mellékhatás: Nincs Megjegyzés: Ez a funkció egyszerre használható helyi ill. távoli kezdeményezésű adattovábbításra. Nincs konkrét kapcsolódási séma az UDP-ben. Ha egy UDP socketet megnyitottak, akkor az kész az adatok küldésére és fogadására is, egészen addig, amíg be nem zárják a socket-et. Példa: switch(smstate) case SM_OPEN: // Megpróbálunk egy DHCP szerverhez kapcsolódni DHCPSocket = UDPOpen(68, &DHCPServerNode, 67); if ( DHCPSocket == INVALID_UDP_SOCKET ) // Nincs szabad socket // Hiba kiírása } else // Egy DHCP üzenet elküldése break; UDPClose Bezártja a megadott UDP socket-et és szabadnak jelöli. Szintaxis: void UDPClose(UDP_SOCKET socket) Paraméter: socket [bemenő] A bezárandó socket azonosítója. Visszatérési érték: Nincs Előfeltétel: Nincs Mellékhatás: Nincs Megjegyzés: Ezt a függvényt csak egyszer kell meghívni. Példa: switch(smstate) case SM_OPEN: // Megpróbálunk egy DHCP szerverhez kapcsolódni DHCPSocket = UDPOpen(68, &DHCPServerNode, 67); if ( DHCPSocket == INVALID_UDP_SOCKET ) // Nincs szabad socket // Hiba kiírása } else

25 20 // Egy DHCP üzenet elküldése // Socket bezárása UDPClose (DHCPSocket); } break; UDPIsPutReady Ez a makró állapítja meg, hogy a megadott socket kész-e az adatok küldésére. A socket akkor kész adatküldésre, ha legalább egy MAC küldő puffer üres. Amikor ezt a makrót meghívjuk, automatikusan aktív socket-té válik. Szintaxis: BOOL UDPIsPutReady(UDP_SOCKET socket) Paraméter: socket [bemenő] Az ellenőrizendő socket azonosítója. Visszatérési érték: IGAZ: Ha a megadott socket kész az adatok küldésére. HAMIS: Ha nincs szabad küldő puffer. Előfeltétel: Nincs Mellékhatás: Nincs Megjegyzés: Egy socket mindig kész az adatküldésre, amíg van üres MAC küldő puffer. Amikor ellenőrizzük a socket-et, az aktívvá válik és a többi UDP funkció is működőképes lesz:udpget,udpflush ésudpdiscard. Példa: switch(smstate) case SM_OPEN: // Megpróbálunk egy DHCP szerverhez kapcsolódni DHCPSocket = UDPOpen(68, &DHCPServerNode, 67); if ( DHCPSocket == INVALID_UDP_SOCKET ) // Nincs szabad socket // Hiba kiírása } else // Egy DHCP üzenet elküldése smstate = SM_BROADCAST; break; } case SM_BROADCAST: if ( UDPIsPutReady(DHCPSocket) ) // A socket kész az adatküldésre

26 21 } break; UDPPut Az aktív socket küldő pufferébe egy bájt adatot helyez. Szintaxis: BOOL UDPPut(BYTE byte) Paraméter: byte [bemenő] Az adat, amit a küldő pufferbe akarunk tenni. Visszatérési érték: IGAZ: Ha a megadott adatot sikerült a pufferbe tölteni és még van hely több adatnak. HAMIS: Ha az adatot sikerült a pufferbe tölteni, de nincs hely több adatnak. Előfeltétel: UDPIsPutReady == TRUE Mellékhatás: Nincs Megjegyzés: Ha egy socket küldésre kész, akkor összes adatot be kell töltenünk vagy addig tölthetjük fel amíg teljesen tele nem lesz a socket puffere. A felhasználó nem töltheti az adat egyik felét egy socket-be a másik felét egy másik socket-be. Fontos megjegyezni, hogy amikor betöltjük az adatokat, akkor az adatok küldése nem történik meg. Kivéve akkor, ha a puffer megtelik, ekkor a funkció automatikusan elkezdi az adatok küldését és HAMIS értékkel tér vissza. A felhasználói program később próbálhat adatot betölteni. Ha az elküldendő adat kevesebb, mint a küldő puffer, a felhasználói programnak kell kezdeményezni a puffer ürítését az UDPFlush funkció hívásával. Általában, érdemes a puffert üríteni, ha egy egységnyi adatot betöltöttünk a pufferbe, attól függetlenül, hogy a puffer még nincs tele. Példa: switch(smstate) case SM_OPEN: // Megpróbálunk egy DHCP szerverhez kapcsolódni DHCPSocket = UDPOpen(68, &DHCPServerNode, 67); if ( DHCPSocket == INVALID_UDP_SOCKET ) // Nincs szabad socket // Hiba kiírása } else // Egy DHCP üzenet elküldése smstate = SM_BROADCAST; break; } case SM_BROADCAST: if ( UDPIsPutReady(DHCPSocket) ) // A socket kész az adatküldésre

27 22 // Az UDPPut közvetlenül nem kapja meg az DHCPSocket paramétert // Az UDPPut az aktív socket-et használja, // amit az UDPIsPutReady() állít be, ez a DHCPSocket. UDPPut(0x55); } break; UDPFlush Az aktív socket küldő puffert küldésre késznek állítja be. Szintaxis:void UDPFlush() Paraméter: Nincs Visszatérési érték: Nincs Előfeltétel: Az UDPPut() függvény már meg volt hívva és a socket aktív, vagyis már futtattuk audpisputready() függvényt. Mellékhatás: Nincs Megjegyzés: Ez a funkció küldésre késznek állítja a küldő puffert, de a küldés nem indul el egyből. A felhasználónak nem kell ellenőriznie a küldési folyamat állapotát. A NIC 15-ször próbálja meg a elküldeni az adatot (legalábbis a RTL8019AS, más NIC esetén a NIC adatlapjában található ez az információ). Ha a socket puffer egyszer már ürítve volt és üres, a további UDPFlush hívásokat a program figyelmen kívül hagyja. Példa: switch(smstate) case SM_OPEN: // Megpróbálunk egy DHCP szerverhez kapcsolódni DHCPSocket = UDPOpen(68, &DHCPServerNode, 67); if ( DHCPSocket == INVALID_UDP_SOCKET ) // Nincs szabad socket // Hiba kiírása } else // Egy DHCP üzenet elküldése smstate = SM_BROADCAST; break; } case SM_BROADCAST: if ( UDPIsPutReady(DHCPSocket) ) // A socket kész az adatküldésre

28 23 // Az UDPPut közvetlenül nem kapja meg az DHCPSocket // paramétert. Az UDPPut az aktív socket-et használja, // amit az UDPIsPutReady() állít be, ez a DHCPSocket. UDPPut(0x55); // Most elküldjük UDPFlush(); } break; UDPIsGetReady Ez a funkció megállapítja, hogy a megadott socket tartalmaz-e vett adatokat és a socket-et aktívnak jelöli ki. Szintaxis: BOOL UDPIsGetReady(UDP_SOCKET socket) Paraméter: socket [bemenő] A socket azonosítója Visszatérési érték: IGAZ: Ha a megadott socket tartalmaz vett adatokat. HAMIS: Ha a megadott socket nem tartalmaz vett adatokat. Előfeltétel: AzUDPOpen() függvény már meg volt hívva. Mellékhatás: Nincs Megjegyzés: Nincs Példa: switch(smstate) case SM_OPEN: // Megpróbálunk egy DHCP szerverhez kapcsolódni DHCPSocket = UDPOpen(68, &DHCPServerNode, 67); if ( DHCPSocket == INVALID_UDP_SOCKET ) // Nincs szabad socket // Hiba kiírása } else // A DHCP szervertől választ várunk smstate = SM_WAIT_FOR_DATA; break; case SM_WAIT_FOR_DATA: if ( UDPIsGetReady(DHCPSocket) ) // Adatokat olvashatók a socket-ből. Kiolvassuk és // feldolgozzuk } break;

29 24 UDPGet Az aktív socket vételi pufferéből egy bájt adatot olvas ki. Szintaxis: BOOL UDPGet(BYTE *byte) Paraméter: byte [kimenő] A beolvasott adatbájt. Visszatérési érték: IGAZ: Ha sikerült egy bájtot beolvasni. HAMIS: Ha nem sikerült az adat beolvasása. Előfeltétel: UDPIsGetReady == TRUE Mellékhatás: Nincs Megjegyzés: Ha a socket-ben adatok vannak, a felhasználói programnak be kell olvasnia egy vagy több bájtot egy taszk ideje alatt és a socket puffert felszabadítani. Más socket-ből adatot kiolvasni addig nem szabad, amíg az előző puffer nem lett felszabadítva. Példa: switch(smstate) case SM_OPEN: // Megpróbálunk egy DHCP szerverhez kapcsolódni DHCPSocket = UDPOpen(68, &DHCPServerNode, 67); if ( DHCPSocket == INVALID_UDP_SOCKET ) // Nincs szabad socket // Hiba kiírása } else // A DHCP szervertől választ várunk smstate = SM_WAIT_FOR_DATA; break; case SM_WAIT_FOR_DATA: if ( UDPIsGetReady(DHCPSocket) ) // Adatokat olvashatók a socket-ből. Kiolvassuk és // feldolgozzuk // A buffer egy BYTE mutató while( UDPGet(buffer) ) buffer++; // Feldolgozzuk // Socket puffer ürítése } break;

30 25 UDPDiscard Az aktív socket vételi pufferét felszabadítja. Szintaxis:BOOL UDPDiscard() Paraméter: Nincs Visszatérési érték: IGAZ: Ha a vételi puffert sikerült felszabadítani. HAMIS: Ha a vételi puffer egyszer már fel lett szabadítva. Előfeltétel: Nincs Mellékhatás: Nincs Megjegyzés: Nincs Példa: switch(smstate) case SM_OPEN: // Megpróbálunk egy DHCP szerverhez kapcsolódni DHCPSocket = UDPOpen(68, &DHCPServerNode, 67); if ( DHCPSocket == INVALID_UDP_SOCKET ) // Nincs szabad socket // Hiba kiírása } else // A DHCP szervertől választ várunk smstate = SM_WAIT_FOR_DATA; break; case SM_WAIT_FOR_DATA: if ( UDPIsGetReady(DHCPSocket) ) // Adatokat olvashatók a socket-ből. Kiolvassuk és // feldolgozzuk // A buffer egy BYTE mutató while( UDPGet(buffer) ) buffer++; // Feldolgozzuk // Socket puffer ürítése UDPDiscard(); } break; UDPProcess Ez a funkció egy taszkként működik. Egy beérkezett UDP csomagról megállapítja, hogy melyik UDP socket-hez tartozik. Ezt a funkciót csak akkor kell meghívni,

31 26 ha egy UDP csomag érkezett. Szintaxis: BOOL UDPProcess(NODE_INFO *remote, WORD len) Paraméter: remote [bemenő] A távoli eszköz adatai, ahonnan az UDP csomag érkezett len [bemenő] Az UDP csomag teljes hossza a fejlécet is beleszámítva Visszatérési érték: IGAZ: Ha a taszknak sikerült teljesen feldolgoznia a megadott csomagot. HAMIS: Ha a taszknak csak részben sikerült feldolgoznia a megadott csomagot. Előfeltétel: IPGetHeader == TRUE és IPProtocol = IP_PRO_UDP Mellékhatás: Nincs Megjegyzés: Ahogy fentebb is megjegyeztük, ez a funkció valósítja meg az UDP taszk funkciót. Akkor kell meghívni, ha egy UDP csomag érkezett ez a funkció beolvassa és feldolgozza azt. A funkció visszatérési értéke mutatja meg a hívónak, hogy a StackTask állapotjelzőjét meg kell-e változtatni. Ebben a implementációban mindig IGAZ értékkel tér vissza a funkció. További információért a Stack Manager forráskódját érdemes megnézni, ami a StackTsk.c fájlban található. Fontos észben tartani, hogy ezzel a funkcióval nem kell törődni, ha astacktask funkciót használjuk. Példa: switch(smstate) case SM_STACK_IDLE: if ( MACGetHeader(&RemoveMAC, &MACFrameType) ) if ( MACFrameType == MAC_IP ) smstate = SM_STACK_IP; return; case SM_STACK_IP: if ( IPGetHeader(&RemoteNode, &IPFrameType, &IPDataCount) ) if ( IPFrameType == IP_PROT_UDP ) smstate = SM_STACK_UDP; return; case SM_STACK_UDP: if ( UDPProcess(&RemoteNode, IPDataCount) ) smstate = SM_STACK_IDLE; return;

32 Stack Manager modul Ahogy már korábban is említettem, ez a Stack különböző modulok gyűjteménye. Néhány modult (mint az IP, TCP, UDP és ICMP), akkor kell meghívni, ha olyan csomag érkezett. Annak az alkalmazásnak, ami a Microchip TCP/IP Stack-et használja, gondoskodnia kell arról, hogy ezek a modulok megfelelő időközönként fussanak. A Stack Manager modul csak a TCP/IP Stack moduljait vezérli. A fő alkalmazásban nem kell foglalkoznunk a különböző modulok meghívásával, csak astacktask nevű taszkot kell meghívnunk. Ez a modul egy külön réteg a StackTask réteg aminek a forrása a StackTask.c fájlban található. Amikor ez a taszk fut, megkérdezi a hálózatelérési réteget, hogy érkezett-e valamilyen csomag. Ha érkezett, akkor megnézi a fejlécét és a megfelelő modulnak átadja további feldolgozás céljából. Mielőtt a Stack Manager-t munkára fognánk, meg kell hívni a StackInit() funkciót, ami inicializálja a modult. Ha ez megtörtént a StackTask() függvényt kell periodikusan meghívni, hogy a beérkező csomagokat időben elirányítsuk és eközben az idő túllépést és hibákat is kezelni tudjuk. A StackTask pontos működésének algoritmusa a 6.1. ábrán látható A soros-udp átalakító modul Mivel ezt a modult írtam én, ezért részletesen leírom a belső működését. A modul használatához két darab UDP socket-re van szükség. A soros vonalon érkező adatokat megszakítással és polling eljárással is vételezhetjük. Természetesen érdemes a megszakítás használatát engedélyezni a ser2udp.h fájlban. A soros vonalról érkező adatok egy alapból 50 bájtos pufferbe kerülnek. Ha megtelik vagy enter (0xA, 0xD) karakter érkezik, akkor azonnal felépítjük és elküldjük az UDP csomagot. A soros adatok küldésekor sajnos nem lehet megszakítást használni, mert ha az UDP csomagot megkaptuk azt fel kell dolgozni és fel kell szabadítani a puffert ugyanabban a taszkban, ahol érzékeltük, hogy UDP csomag érkezett. Ha lenne elegendő memóriánk, akkor az adatokat átmásolva megoldható lenne a megszakításos adatküldés. AzAppConfig struktúrájába került új változók listája a 6.2. táblázatban látható. A 6.2. táblázatban látható változók awebsrvr.c fájlban azinitappconfig függvényben kapnak egy kezdeti értéket, ill. ha létezik elmentett beállítás a külső soros EEPROM-ban, akkor az értékük onnan töltődik be. Jelenleg sem soros adatfolyamszabályozás sem paritás ellenőrzés nincs implementálva. A 6.3. táblázatban levő belső változókat a modul függvényei használják. Serial2UDP_Init A modul inicializálását ez a függvény végzi el. Szintaxis:Serial2UDP_Init Paraméter: Nincs Visszatérési érték: Nincs

33 ábra. A Stack Manager algoritmusának folyamatábrája

34 29 NODE_INFO target A céleszköz adatai: IP cím és MAC cím. WORD target_port A cél port száma. WORD local_port A helyi port száma. BYTE refresh A statisztikák megtekintésekor a frissítések közötti idő másodpercben. BYTE baud Az baud-dal arányos kiszámított érték, ami az SPBRG változóba kerül. BYTE FlowCtrl Értéke lehet 0: nincs szabályozás, 1: szoftveres szabályozás, 2: hardveres adatfolyam szabályozás. (Jelenleg nincs használva, későbbi fejlesztéshez fenntartva.) BYTE Parity Értéke lehet 0: nincs paritás ellenőrzés, 1: páratlan paritás, 2: páros paritás ellenőrzés. (Jelenleg nincs használva, későbbi fejlesztéshez fenntartva.) 6.2. táblázat. A soros-udp átalakító modul konfigurációs változói static UDP_SOCKET UDPSocket Az adatok továbbításához használt socket. BYTE status A modul állapotát tároló változó. További információk a 6.4. táblázatban. DWORD rxbytes, txbytes A fogadott és elküldött oktetek száma. static WORD count A bemeneti soros pufferben elküldésre várakozó bájtok száma. static BYTE buf[buf_size] A bemeneti soros puffer. Alapesetben 64 bájt méretű. static BYTE buf_end Az adatok száma a soros pufferben. static BYTE_VAL misc Egyes bitjei más-más jelentéssel bírnak. A 0. bit: A SendSerialData függvény legközelebbi futásakor megpróbáljuk-e elküldeni az adatokat táblázat. A soros-udp átalakító modul belső változói Előfeltétel: Nincs Mellékhatás: A modul inicializálása legalább 4 másodpercig (INITWAIT_SEC) tart. Megjegyzés: Először vár 4 másodpercet. Ennyi idő elég, hogy feléledjen a NIC és érzékelje, hogy a kapcsolat él. (A későbbiekben érdemes lenne kódot átírni úgy, hogy a NIC interfészén keresztül kérdezze le, hogy él-e a kapcsolat.) Utána elküld egy ARP kérés csomagot, hogy megtudja a cél IP címhez tartozó MAC címet. Még négy másodpercig vár (TIMEOUT_SEC) utána Hiba: MAC cím lekérdezése közben időtúllépés történt hibaállapotba lép. Ha sikerült a MAC lekérdezése megpróbál egy UDP socket-et megnyitni. Ennek sikertelensége esetén Hiba: Nincs szabad UDP socket, ellenkező esetben Rendben állapotba kerül. A függvényt csak egyszer kell meghívni. Példa: Serial2UDP_Init ();

35 30 Serial2UDP_GetSerialData Beolvassa a soros vonalról jövő adatot és elhelyezi a buf pufferben, ha lehetséges. Ha a puffer megtelt vagy soremelés (0xD), kocsi vissza (0xA) karakter érkezett, akkor a flush vátozót igaz értékre állítja. Ha a soros vonali adatok vételénél keret hiba történt a modul Hiba: RS-232 keret hiba állapotba kerül. Ha az adatok vételekor a vételi puffer felülírása következett be, akkor a Hiba: Az RS-232 puffer felülírás állapot áll be. A függvény folyamatábrája a 6.2. ábrán látható. Az ábrán a szaggatott vonal akkor érvényes, ha ezt a függvényt a Serial2UDP függvény hívja meg és nem megszakítással működik. Szintaxis: void Serial2UDP_GetSerialData () Paraméter: Nincs Visszatérési érték: Nincs Előfeltétel: Nincs Mellékhatás: Nincs Megjegyzés: Megszakításos módban és a pollingolásnál is ez a függvény működik. Pollingnál aserial2udp függvény hívja meg ezt a függvényt. Példa: Nincs Serial2UDP_SendSerialData Ha abuf puffer tele van (aflush bit 1 értékű), akkor elkészít egy UDP csomagot és elküldi a beállított IP címnek. Szintaxis: void Serial2UDP_SendSerialData () Paraméter: Nincs Visszatérési érték: Nincs Előfeltétel: Nincs Mellékhatás: Nincs Megjegyzés: ASerial2UDP függvény hívja meg ezt a függvényt. Példa: Nincs Serial2UDP_ProcessUDPData A fogadott UDP csomagot azonnal elküldi a soros vonalon keresztül. Folyamatábrája a 6.3. ábrán látható. Szintaxis: void Serial2UDP_ProcessUDPData () Paraméter: Nincs Visszatérési érték: Nincs Előfeltétel: Nincs Mellékhatás: Nincs Megjegyzés: ASerial2UDP függvény hívja meg ezt a függvényt. Példa: Nincs

36 ábra. A Serial2UDP_GetSerialData függvény folyamatábrája Serial2UDP Ez egy kooperatív taszk, amit a fő ciklusban kell meghívni. Szintaxis: void Serial2UDP () Paraméter: Nincs Visszatérési érték: Nincs Előfeltétel: Inicializálás megtörtént. Mellékhatás: Nincs Megjegyzés: A soros vonalon beérkező adatokat a buf pufferben tárolja a Serial2UDP_GetSerialData () függvény segítségével (csak polling módszernél).

37 ábra. A Serial2UDP_ProcessUDPData függvény folyamatábrája A SendSerialData () eljárással küldi el a buf pufferben tárolt adatokat a soros vonalon és a ProcessUDPData () függvénnyel a megadott portra érkező UDP csomagokat egyből kiírja a soros vonalra. Példa: StackTask(); HTTPServer(); Serial2UDP(); Serial2UDP_ReInit A konfiguráció megváltozásakor kell meghívni. Szintaxis: void Serial2UDP_ReInit () Paraméter: Nincs Visszatérési érték: Nincs

38 33 Előfeltétel: Nincs Mellékhatás: Nincs Megjegyzés: Szinte teljesen megegyezik az Serial2UDP_Init funkcióval, de az ARP kérés kiküldése előtt nincs 4 másodperces várakozás. Példa: Serial2UDP_GetStatusString A modul állapotára vonatkozó stringre mutató mutatót ad vissza. Szintaxis: char *Serial2UDP_GetStatusString (void) Paraméter: Nincs Visszatérési érték: Egy sztring mutató, ami megegyezik a Serial2UDP_StatusString változóban levő értékkel. Előfeltétel: Nincs Mellékhatás: Nincs Megjegyzés: A sztring HTML kódokat tartalmaz, 0 kódú karakterrel van lezárva és a programmemóriában van. A lehetséges állapotok szövegei a 6.4. táblázatban láthatók. Sorszám Angolul Magyarul 0 Unknown Ismeretlen 1 Ok Rendben 2 Error: UDP socket not available Hiba: Nincs szabad UDP socket 3 Error: Can t resolve MAC address, time out Hiba: MAC cím lekérdezése közben időtúllépés történt 4 Error: Buffer is full Hiba: A puffer tele van 5 Error: RS-232 Framing error Hiba: RS-232 keret hiba 6 Error: RS-232 Overrun error Hiba: RS-232 puffer felülírás Példa: 6.4. táblázat. A soros-udp modul átalakító állapotai WORD HTTPGetVar(BYTE var, WORD ref, BYTE* val) switch(var) case VAR_DEVSTATUS: if (ref == HTTP_START_OF_VAR) Serial2UDP_GetStatusString (); ref = (BYTE)0; } *val = Serial2UDP_StatusString[(BYTE)ref]; if (Serial2UDP_StatusString[(BYTE)ref + 1] == \0 ) return HTTP_END_OF_VAR;

39 34 (BYTE)ref++; return ref; 6.5. HTTP szerver modul Ez a HTTP szerver kooperatív taszkként fut, amit a fő alkalmazásból kell meghívni. A szerver a HTTP.c forrásfájlban van implementálva és a felhasználói programban két segédrutint (angolul callback function) használhatunk. Az bemutató alkalmazás forrásfájlját a websrvr.c fájlt használtam fel a saját programom írásához. Ez a HTTP szerver egy csökkentett tudású program, direkt beágyazott rendszerekhez íródott. A szerver tulajdonságai: Többszálú HTTP kapcsolatok Egy egyszerű fájlrendszert támogat (MPFS) A honlapokat a belső programmemóriában és külső EEPROM-ban is tárolhatjuk Tartalmaz egy PC-s programot MPFS képfájl létrehozásához A HTTP GET metódust támogatja (más metódusok könnyen hozzáadhatók) Egy módosított Common Gateway Interface-t (CGI) támogat Dinamikusan generálható a honlapok tartalma. A HTTP szerver használatbavételéhez a következő lépéseket kell végrehajtani: 1. A StackTsk.h fájlban vagy a projekt beállításnál definiálni kell a STACK_USE_HTTP_SERVER definíciót. 2. AStackTsk.h fájlban be kell állítani amax_http_connections értékét. 3. Ahttp.c ésmpfs.c fájlokat hozzá kell adni a projekthez. 4. Attól függően, hogy hol szeretnénk a weblapokat tárolni, definiálni kell az MPFS_USE_PGRM vagy azmpfs_use_eeprom kulcsszavakat. Ha külső EEPROMot használunk tárolóelemnek az xeeprom.c fájlt is hozzá kell adni a projekthez. 5. Amain() függvényt módosítani kell, hogy a HTTP szerver működjön. Az összes weblapot egy MPFS (Microchip File System) fájlrendszerbe kell konvertálni. Ha az MPFS képfájlt külső EEPROM-ban tároljuk, akkor a felhasználói programba implementálni kell az adatok rögzítéséhez szükséges függvényt. A HTTP szerver alap honlapként az index.htm fájlt használja. Ha például egy böngésző a HTTP szerverhez fordul úgy hogy csak az IP címet adták meg a böngészőnek azindex.htm fájlt kapja meg a böngésző. Tehát minden MPFS képfájlban lennie kell egy index.htm fájlnak. Ha szükséges az alap fájlnév megváltoztatható, ha a http.c forrásban a HTTP_DEFAULT_FILE_STRING definíciót átírjuk. Fontos, hogy a weblap fájlok nevei ne tartalmazzák a következő karaktereket:

40 35 aposztróf és idézőjel ( és ") kisebb-nagyobb jelek (< és>) kettős kereszt jel (#) százalék jel (%) szögletes és kapcsos zárójelek ([,}, [,) szűrő jel ( ) vissza perjel (\) kalap jel Ha egy fájl neve tartalmaz ezek közül egy karaktert, akkor az a honlap nem lesz elérhető. A HTTP szerveren van egy lista a támogatott fájl típusokkal. Ezt az információt a böngésző használja fel; ebből állapítja meg, hogy hogyan értelmezze a kapott adatokat. A fájlok azonosítása a hárombetűs kiterjesztés alapján történik. Alapból a HTTP szerver a következő fájltípusokat támogatja:.txt,.htm,.gif,.cgi,.jpg,.cla,.wav. Ha egy alkalmazásban olyan fájltípust akarunk használni, ami nincs a listában, akkor a http.c fájlban httpfiles táblázatot kell módosítani utána a httpcontents felsorolást. Az ismert fájltípusok listáját a stíluslapok típussal bővítettem (.css) Dinamikus honlap generálás A HTTP szerver dinamikusan meg tudja változtatni a honlapok tartalmát. A CGI (.cgi kiterjesztésű legyen) fájlokban a %xx kulcsszó helyére tetszőleges adat helyettesíthető. A % jel egy vezérlő karakter. Az xx egy kétjegyű azonosító, hexadecimális formában. Ügyeljünk arra, hogy az A-F karakterek nagy betűvel legyenek írva! Így 256 féle változót használhatunk. Ha % jelet szeretnénk kiírni, írjunk egymás után két százalék jelet: %%. Az eredeti Microchip megoldásban nem teljes értékű hexadecimális számok voltak megadhatók. A % jel után két darab decimális számot kellett írni, amit a programban hexadecimális számként kellet feldolgozni. Így változó megadása lehetséges. Én írtam egy egyszerű konvertert, ami a hexadecimális stringet átalakítja egy bájttá. Így 00-tól FF-ig adhatók meg az azonosítók. HTTPGetVar Ez a funkció egy segédfüggvény (callback function) a HTTP-hez. Ha HTTP szerver egy %xx szöveget talál egy CGI lapon, akkor meghívja ezt a funkciót. Ezt a funkciót a felhasználói programban kell megírni és különböző változó adatokat tudunk vele továbbítani. Szintaxis: WORD HTTPGetVar(BYTE var, WORD ref, BYTE *val) Paraméter: var [bemenő] A változó azonosítója, aminek az állapotát akarjuk lekérdezni.

41 36 ref [bemenő] Ez az érték jelzi, hogy ha ez az első függvényhívás. Ekkor a változó értéke HTTP_START_OF_VAR. Ez első hívás után már ez a változó a felhasználói alkalmazásé. Egyszerre csak egy bájt átvitele lehetséges. Ez a változó teszi lehetővé, hogy több bájt átvitele esetén a HTTP szerver nyomon kövesse az adatok átvitelét úgy, hogy ebben a változóban az átvitt adat indexét kell tenni és visszatéréskor is ezt a változót kell átadni. Az utolsó bájt átvitelekorhttp_end_of_var értéket kell visszatérési értéknek megadni. A HTTP szerver egészen addig meghívja ezt a funkciót, amíg nem kap egyhttp_end_of_var értéket. val [kimenő] Egy bájt adat, amit küldeni szeretnénk. Visszatérési érték: A ref változó új értéke, amit a felhasználói alkalmazás állapít meg. Ha HTTP_END_OF_VAR értéket ad vissza, legközelebb csak akkor hívódik meg, ha megint szükség van a változó értékére. Előfeltétel: Nincs Mellékhatás: Nincs Megjegyzés: Ez a függvény egy változót kér a felhasználói alkalmazástól, de annak nem feltétlenül kell értékeket adni. Az hogy milyen információt ad át a függvény, az a hozzárendelt weblaptól függ. Példa: A soros-udp átalakítóhoz készítettem a stats.cgi fájlt, ebben a következő olvasható: <tr><td>device status</td><td>%01</td></tr> Amikor a HTTP szerver a fájl feldolgozása során a %01 szöveghez ér, meghívja a következő funkciót: HTTPGetVar(1, HTTP_START_OF_VAR, &value). A felhasználói alkalmazásban levőwebsrvr.c fájlban van ez a funkció és ehhez hasonlóan néz ki: WORD HTTPGetVar(BYTE var, WORD ref, BYTE* val) switch(var) case VAR_RXBYTES: if (ref == HTTP_START_OF_VAR) ltoa (rxbytes, TmpString); ref = (BYTE)0; } *val = TmpString[(BYTE)ref]; if (TmpString[(BYTE)ref + 1] == \0 ) return HTTP_END_OF_VAR; (BYTE)ref++; return ref; HTTP CGI A CGI-nek egy módosított verziója használható ebben az implementációban. Ezzel az interfésszel a HTTP kliens egy funkciót tud meghívni a felhasználói alkal-

42 37 mazásban a HTML GET módszerével. További információk az RFC1866-os dokumentumban [5] találhatók. A HTTP szerver nem dekódolja az átadott URL-t. Ez azt jelenti, hogy ha az átadott űrlapok mezője speciális karaktereket tartalmaz (<,>, %, ékezetes karakterek, stb.), akkor a funkciónak átadott paraméter %xx formátumú sztringeket fog tartalmazni, ahol a xx az ASCII karakter hexadecimális kódja. Az űrlapokat tartalmazó oldalakat.cgi kiterjesztéssel kell ellátni. Fontos észben tartani, hogy amikor jelszavakat továbbítunk CGI segítségével, a jelszavakat kódolatlanul továbbítjuk, tehát azok lehallgathatók. HTTPExecCmd Ez egy segédfüggvény (callback function). Ha a HTTP szerver a GET módszerrel történő lekérdezésnél több mint egy paramétert kap, akkor hívja meg ezt a funkciót. Ezt a funkciót a felhasználói alkalmazásnak kell tartalmaznia. Szintaxis: void HTTPExecCmd(BYTE **argv, BYTE argc) Paraméter: argv [bemenő] Ez egy sztring tömb. Az első sztring (argv[0]) az űrlap action mezőjének tartalma, a többi (argv[1..n]) a paraméterek. argc [bemenő] A paraméterek száma, beleszámítva az action mezőt is. Visszatérési érték: A felhasználói alkalmazásnak be kell állítania azargv[0] változót egy érvényes honlapnévre, ami a visszatérési eredményt tartalmazza. Előfeltétel: Nincs Mellékhatás: Nincs Megjegyzés: Ezt a függvényt a HTTP szerver hívja meg. A felhasználói alkalmazásnak ki kell tudnia szolgálnia az egymás utáni hívásokat. Alapesetben az argumentumok száma maximum 5 és az argumantumsztringek hossza legfeljebb 80 lehet. Ha egy alkalmazásnak ennél több argumentum vagy hosszabb sztring kell, a MAX_HTTP_ARGS vagy a MAX_HTML_CMD_LEN definíciót kell megváltoztatni. Ezek a http.c fájlban találhatók. Példa: A setup.cgi fájlt is a soros-udp átalakítóhoz készítettem. Ebben olvasható a következő: <form action="setup.cgi" method="get"> <table border=0> <tr><td>local IP</td> <td><input type="text" name="0" value="%0c"></td></tr> <tr><td>local Port</td> <td><input type="text" name="1" value="%0d"></td></tr> <tr><td>netmask</td> <td><input type="text" name="2" value="%0e"></td></tr> <tr><td>gateway</td> <td><input type="text" name="3" value="%0f"></td></tr> <tr><td>target IP</td> <td><input type="text" name="4" value="%09"></td></tr> <tr><td>target Port</td> <td><input type="text" name="5" value="%0a"></td></tr> <tr><td>refresh rate</td>

43 38 <td><input type="text" name="6" value="%06"></td> <td>sec</td></tr> <tr><td><input type="submit" name="7" value="save"></td></tr> </table> </form> Ennek a táblázatnak a második oszlopaiban adhatunk meg különféle szöveg formátumú adatokat. A képernyőn látható kép a 6.4. ábrán van. Az utolsó sorban egy gomb látható Save felirattal. Ha rákattintunk erre a gombra, akkor az űrlapot a GET módszerrel elküldi a böngésző ábra. Űrlapok kezelése A HTTP kérés ez lesz: setup.cgi?0= &1=2221&2= & 3= &4= &5=2222&6=5&7=Save Ennek hatására HTTP szerver pedig a következő paraméterekkel meghívja ahttpexeccmd függvényt: argc = 17 argv[0] = "setup.cgi" argv[1] = "0" argv[2] = " " argv[3] = "1" argv[4] = "2221" argv[5] = "2" argv[6] = " " argv[7] = "3" argv[8] = " " argv[9] = "4" argv[10] = " " argv[11] = "5" argv[12] = "2222" argv[13] = "6" argv[14] = "5" argv[15] = "7" argv[16] = "Save" Ehhez természetesenmax_http_args és amax_html_cmd_len értékét is meg kell növelni. Az adatokat feldolgozó függvény pedig így néz ki: void HTTPExecCmd(BYTE** argv, BYTE argc) BYTE i; BYTE var; for (i = 1; i < argc; i += 2) switch(argv[i][0] - 0 ) case CGI_CMD_LOCALIP: StringToIPAddress (argv[i + 1], &AppConfig.MyIPAddr);

44 39 } } break; case CGI_CMD_LOCALPORT: AppConfig.local_port = atoi (argv[i + 1]); break; case CGI_CMD_BUTTON: // Ez a parameter adodik at utolsonak Serial2UDP_ReInit (); SaveAppConfig (); break; Az egy karakterből álló azonosítók használata leegyszerűsíti a program kódját, ezért érdemes alkalmazni Microchip fájlrendszer (MPFS) A HTTP szerver egy egyszerű fájlrendszert használ a honlapok tárolására. A fájlrendszer képe a mikrovezérlő memóriájában és egy külső soros EEPROM-ban is tárolható. A fájlrendszer formátuma a 6.5. ábrán látható ábra. MPFS képfájl felépítése A fenntartott terület mérete azmpfs_reserve_block definícióban van megadva. A fenntartott területet a felhasználói alkalmazás használhatja a konfigurációs értékek tárolására. Egy MPFS tároló egy vagy több MPFS FAT (Fájl Elhelyezkedési Tábla, File Allocation Table) bejegyzést tartalmaz, amit egy vagy több adatblokk követ. A FAT bejegyzés határozza meg a fájl nevét, pozícióját a memóriában és a fájl állapotát. A FAT bejegyzés formátuma a 6.6. ábrán van.

45 40 Az állapotjelző mutatja meg, hogy a bejegyzés használatban van, törölve van ill. a FAT végét is jelezheti. Minden FAT bejegyzés tartalmaz egy 16 vagy 24 bites címet. A cím hossza a felhasznált memória típusától függ. Ha a belső programmemóriát használjuk kis (small) memóriamodellel, akkor 16 bites címeket fog használni. Ha a belső programmemóriát használjuk viszont nagy (large) memóriamodellel, akkor 24 bites címeket fog használni. A külső EEPROM eszközöknél mindig 16 bites címzési módszert használunk, függetlenül a memóriamodelltől. Ebben a fájlrendszerben a fájlnevek 8+3 bájt hosszúak. A fájl neve 8 bájtos és a kiterjesztés további 3 bájt hosszúságú. A 16 bites cím megadja az első adatblokkot. Minden fájlnév nagybetűkkel szerepel a könnyebb névkezelés érdekében. Az adatblokk formátuma a 6.7. ábrán szerepel. A blokk végét egy speciális karakter jelzi; az EOF (End Of File), amit 0xFFFF (16 bites címzésnél) vagy 0xFFFFFF (24 bites címzésnél) követ. Ha a fájl tartalmazza az EOF karaktert, akkor egy DLE (Data Link Escape) karakterrel jelezzük, hogy ez a fájl része. Ha a DLE karakter szerepel az adatblokkban, akkor két DLE karakter jelzi, hogy az a fájl része MPFS kép készítése A csomag része egy PC-s program (MPFS.exe), amivel MPFS képfájlokat hozhatunk létre. A program képes bináris és C nyelvű adatok létrehozására is. Az MPFS.exe használata: mpfs [/?] [/c] [/b] [/r<blokk>] [bemenet] [kimenet], ahol /? hatására segítséget ír ki, /c paraméter segítségével C kódot kérhetünk, /b paraméterrel bináris kódot készít (ez az alapbeállítás), /r paraméterrel megadhatjuk hány bájtot szeretnénk fenntartani saját használatra, (ez csak bináris módban működik, alap: 32 bájt), bemenet a bemenő adatokat tartalmazó könyvtár, 6.6. ábra. MPFS FAT bejegyzés felépítése 6.7. ábra. MPFS adatblokk felépítése

46 41 kimenet az MPFS képet tartalmazó fájl. Például:mpfs /c Honlap honlap.c Így egy C fájlt kapunk benne ahonlap könyvtárban lévő fájlok adatai. Bináris fájlt kapunk az mpfs Honlap honlap.bin parancs hatására. A bináris fájl elején 32 bájt fenntartott. Ha megváltoztatjuk a fenntartott terület méretét ne felejtsük el a StackTsk.h fájlban a MPFS_RESERVE_BLOCK definíciót megváltoztatni. Mielőtt a képfájlt létrehozzuk az összes honlapot egy könyvtárba kell másolni. Ha egy fájl kiterjesztése.htm, akkor a program az összes kocsi vissza, új sor karaktert törli, hogy csökkentse a képfájl méretét. Ha az MPFS képfájlt C adatként használjuk, akkor a projektünkhöz hozzá kell adni a C fájlt. Ha a képfájlt külső soros EEPROMban tároljuk, a bináris fájlt fel kell tölteni a memóriába. További információ a 41. oldalon az FTP szerver modul résznél. Az MPFS képkészítő program nem ellenőrzi az elkészült fájl méretét. Bináris adat készítése esetén ellenőrizni kell az adat méretét MPFS könyvtár Az MPFS fájlrendszer eléréséhez szükséges könyvtár az MPFS.c fájlban van implementálva. Az MPFS könyvtárat a HTTP és az FTP szerver használja a felhasználói alkalmazástól függetlenül. Az MPFS könyvtár jelenlegi verziójával nem lehet egy létező fájlrendszerhez új fájlokat adni ill. törölni. Bármilyen változás esetén egy újabb képfájlt kell létrehozni. Ha a belső programmemóriát használjuk a tárolásra, az MPFS_USE_PGRM szót definiálni kell. Ha viszont külső EEPROM-ot használunk, a MPFS_USE_EEPROM kulcsszót kell definiálni. Egyszerre csak egyik definíció szerepelhet a StackTsk.h fájlban; ennek ellenőrzésére a futásidő alatt egy ellenőrzőkód fut le. A memória típusától függően különböző lappuffer méretet kell beállítani. Az alap méret (amit az MPFS_WRITE_PAGE_SIZE határoz meg) 64 bájt. Ha más pufferméretre van szükség azmpfs_write_page_size definíciót kell megváltoztatni. Az MPFS könyvtárnak ez a verziója az xeeprom.c fájlt használja a külső EEPROM eléréséhez. Miközben egy fájlt olvas vagy ír kizárólagosan az MPFS irányítja az I 2 C buszt és nem engedélyezi más I 2 C eszközöknek legyen az szolga vagy mester a hozzáférést. Ha több I 2 C eszközt használunk, akkor a felhasználói alkalmazás írásakor ezt figyelembe kell venni FTP szerver modul Ez a modul is egy kooperatív taszkként funkcionál és azftp.c fájlban van a szerver forráskódja. Ez az FTP szerver nem tudja az összes szolgáltatást, ami az RFC 959- ben [6] le van leírva, mivel direkt beágyazott rendszerekhez lett tervezve, minimális a mérete és a tudása. A modul jellemzői: Egy szálú FTP kapcsolat. A felhasználó azonosítása az alkalmazás feladata, Automatikusan kezeli az MPFS fájlrendszert,

47 42 A PUT paranccsal egy új MPFS kép tölthető fel, A fájlok egyenkénti feltöltése nem lehetséges. A modul két részből áll: maga az FTP szerver és a felhasználó azonosító függvény, ami a felhasználói alkalmazásnak kell tartalmaznia. Egy FTPVerify függvényt kell írnia a felhasználónak, ami ellenőrzi az FTP felhasználót és a jelszót. Itt is megjegyzem, hogy a jelszót kódolatlanul küldi el a számítógép, tehát azok a megfelelő eszközökkel lehallgathatók. Az FTP szerver használatához a következőket kell megtettünk: 1. A STACK_USE_FTP_SERVER-t definiálni kell. A komment jelet el kell távolítani a StackTsk.h fájlban a definíció elől. 2. A definiált socket-ek számát növelni kell kettővel ugyancsak a StackTsk.h fájlban. 3. AzFTP.c és azmpfs.c fájlokat hozzá kell adni a projektünkhöz. 4. Vagy az MPFS_USE_PGRM MPFS_USE_EEPROM definíciót be kell állítani, attól függően, hogy milyen tárolóelemet használunk. Ha külső EEPROM-ot, az xeeprom.c fájlt is adjuk hozzá a projektünkhöz. 5. Módosítsuk a main() függvényt, hogy az FTP szerver inicializáló függvénye és taszkja fusson. Az FTP szerver 180 másodperc után jelez időtúllépést feltöltésnél és letöltésnél egyaránt. Ha egy kapcsolat 180 másodpercnél tovább van IDLE (tétlen) állapotban, akkor automatikusan megszakítja a szerver a kapcsolatot. Így a bennragadt kliensek nem gátolhatják meg a további FTP műveleteket MPFS kép feltöltése FTP kliens segítségével Az FTP szerver fő feladata ebben a Stack-ben, hogy távolról lehessen frissíteni az MPFS képfájlt. A jelenlegi verzió csak akkor működik, ha külső EEPROM-ot használunk adattárolásra. Egy képfájl feltöltése látható a 6.8. ábrán. A vastagon szedett betűk a felhasználó által beírt adatokat jelzi. A jelszó természetesen nem látszódik a képernyőn. FTPVerify Ez egy segédfüggvény (callback function), amit az FTP szerver akkor hív meg, ha kérést vesz a kapcsolat felépítésére. Ezt a funkciót a felhasználói alkalmazásnak kell tartalmaznia. Szintaxis: BOOL FTPVerify(char *login, char *password) Paraméter: login [bemenő] Egy sztring, ami tartalmazza a felhasználó nevét. password [bemenő] Sztring, ami a jelszót tartalmazza. Visszatérési érték: IGAZ: Ha a felhasználói név és a jelszó érvényes. HAMIS: Ha vagy a felhasználó neve, vagy a jelszó érvénytelen.

48 43 c:\> ftp ready User ( : (none)): ftp 331 Password required Password: microchip 230 Logged in ftp> put mpfsimg.bin 200 ok 150 Transferring data 226 Transfer Complete bytes transferred in 0.01Seconds Kbytes/sec. ftp> quit 221 Bye 6.8. ábra. MPFS képfájl feltöltése FTP kliens segítségével Előfeltétel: Nincs Mellékhatás: Nincs Megjegyzés: A felhasználónév hossza nullától kilencig változhat. Ha hosszabb felhasználónévre van szükség az FTP_USER_NAME_LEN definíciót kell megváltoztatni az ftp.h fájlban. A jelszó és az FTP utasítások hossza legfeljebb 31 karakter hosszú lehet. Ha hosszabb jelszó és/vagy parancs szükséges, akkor amax_ftp_cmd_string_len definíciót kell megváltoztatni azftp.c fájlban. Példa: ROM char FTP_USER_NAME[] = "ftp"; #define FTP_USER_NAME_LEN (sizeof(ftp_user_name)-1) ROM char FTP_USER_PASS[] = "microchip"; #define FTP_USER_PASS_LEN (sizeof(ftp_user_pass)-1) BOOL FTPVerify(char *login, char *password) if (!memcmppgm2ram(login, (ROM void*)ftp_user_name, FTP_USER_NAME_LEN) ) if (!memcmppgm2ram(password, (ROM void*)ftp_user_pass, FTP_USER_PASS_LEN) ) return TRUE; } return FALSE; }

49 44 7. fejezet Hardver A PIConNET kártya kapcsolási rajzát és a nyomtatott áramkört a ChipCad Kft. készítette. A kapcsolási rajz az 1. számú mellékleten látható. A rajzon látható 93LC46B típusú soros EEPROM nem lett beforrasztva. A kártyához készítettem egy soros vonali illesztőt és egy egyszerű tápfeszültségstabilizátort, ami a 7.1. ábrán látható. A soros vonal illesztését egy MAX232A típusú integrált áramkör valósítja meg. A rajzon MAX232 IC szerepel, a két IC között annyi a különbség, hogy a MAX232 mellé 1 µf-os kondenzátorokat kell tenni, míg a MAX232A megelégszik 100 nf-os kondenzátorokkal. A tápfeszültség stabilizálását pedig egy 78L05 IC végzi el Alkatrészek PIC18F452 mikrovezérlő Ez egy FLASH programmemóriával rendelkező RISC mikrokontroller10 MIPS teljesítményre képes és maximum 40 MHz-en működhet. 32 kilobájt FLASH építettek be a programmemóriának, 1536 bájt RAM és 256 bájt EEPROM van benne. Utasításkészlete 75 utasításból áll és úgy optimalizálták, hogy a C programnyelven történő fejlesztést megkönnyítse. 31 szintű verem van beépítve, ami ha szükséges szoftveresen bővíthető. A nyomtatott áramköri lapon felhasznált TQFP tok rajza a 7.2. ábrán látható. Az IC részletes leírása az angol nyelvű adatlapon [7] van. Perifériák jellemzői: A lábak áramleadása vagy -felvétele 25 ma lehet. Három külső megszakítást generáló láb áll rendelkezésre. Timer0 modul: 8 bit ill. 16 bites időzítő/számláló 8 bites programozható előosztóval. Timer1 modul: 16 bites időzítő/számláló. Timer2 modul: 8 bites időzítő/számláló 8 bites periódus regiszterrel (időalap a PWM-hez).

50 ábra. Soros vonali illesztő és tápfeszültség stabilizátor kapcsolási rajza

51 ábra. A PIC18F452 típusú mikrovezérlő lábkiosztása Timer3 modul: 16 bites időzítő/számláló. Opcionális másodlagos oszcillátor Timer1-es és Timer3-as modulokhoz. Két Capture/Compare/PWM modul. A modul háromféleképpen konfigurálható: Capture (mintavételező) bemenetként (16 bites, maximum felbontás 6, 25ns=T CY /16), Compare (összehasonlító) bemenetként (16 bites, maximum felbontás 100ns=T CY ), PWM kimenetként (felbontás 1 bittől 10 bitig változtatható, 8 bites felbontásnál f max = 156kHz, 10 bites felbontásnál f max = 39kHz). Szinkron soros port (Master Synchronous Serial Port, MSSP) modul. Három módban működhet: 3 vezetékes SPI módban (mind a négyfajta SPI módban működik), I 2 C mester módban, I 2 C szolga módban.

52 47 Címezhető USART modul. RS-232 és RS-485 módot is támogatja. Párhuzamos szolga port (PSP). Analóg paraméterek: 10 bites AD konverter jellemzői: Gyors mintavételező képesség, Működik szundi (SLEEP) módban, Linearitás 1Lsb. Programozható feszültségesés jelzés (Programmable Low Voltage Detection, PLVD): megszakítás kérhető, ha leesik a feszültség. Tápfeszültség-kiesés esetén beállítható reset folyamat (Brown-out Reset, BOR). Speciális jellemzők: Tipikusan százezerszer törölhető/írható a FLASH programmemória. Tipikusan egy milliószor törölhető/írható az adat EEPROM. A FLASH és az adat EEPROM legalább 40 évig megtartja tartalmát. A szoftverből lehet írni/olvasni a programmemóriát. Fejlett beépített reset áramkör: Power-on Reset (POR), Power-up Timer (PWRT), Oscillator Start-up Timer (OST). Watchdog időzítő (WDT) saját RC oszcillátorral. Programozható kódvédelem. Tápegységkímélő szundi (SLEEP) mód. Változtatható oszcillátorbeállítások: az elsődleges oszcillátor négyszerezése (PLL használatával), másodlagos órajel engedélyezése/tiltása. Soros programozás két lábon keresztül (In-Circuit Serial Programming, ICSP). Nyomkövetés két lábon keresztül (In-Circuit Debugging, ICD). CMOS technológia előnyei: Alacsony teljesítményű, nagy sebességű FLASH/EEPROM technológia Széles tápfeszültség-tartomány ( V) Ipari- és kiterjesztett hőmérsékleti tartományok Alacsony teljesítményigény: kisebb, mint 1,6 ma, ha 5V a tápfeszültség és 4 MHz a frekvencia 25µA, ha 3V a tápfeszültség és 32 khz a frekvencia kisebb, mint 0,2µA szundi üzemmódban

53 RTL8019AS ethernet vezérlő Ez az IC valósítja meg a fizikai kapcsolatot az ethernet hálózattal. A régebbi verziójú RTL8019-et továbbfejlesztették és 16 kilobájt SRAM-ot építettek be egy tokba. Full-duplex-es és 10 Mbit/s sebesség érhető el. Csavart érpáros (10baseT) és koaxiális kábellel (10base5, 10base2) is használható, továbbá a már igen elavult AUI csatlakozást is használhatunk. A PIConNET kártyán egy RJ45-ös csatlakozó lett kialakítva a csavart érpáros kapcsolathoz, továbbá van négy LED, amely a kapcsolat létrejöttét ill. a hálózati forgalmat jelzi. További információ az IC adatlapján [8] található. Ez az integrált áramkör a beépített SRAM-ot pufferként felhasználva ethernet kereteket küld ill. fogad manchester kódolással és kezeli az ütközéseket. Az OSI/ISO modellben gyakorlatilag a fizikai- és adatkapcsolati réteget valósítja meg LC256 típusú soros EEPROM Ebben a memóriában 32 kilobájt méretű EEPROM található és I 2 C buszon keresztül kommunikál a mikrokontrollerrel. Egy speciális formátumba csomagolva FTP-n keresztül tölthetjük fel honlapunkat a memóriába, továbbá ebben az EEPROM-ban tároljuk az alkalmazás beállításait. További információ az angol nyelvű adatlapon [11] van. A 7.3. ábrán látható a tok lábkiosztása. A tok jellemzői a következők: Kis fogyasztású CMOS technológiával készül: Az íráskor felvett áram 3 ma 5.5V-os tápfeszültségnél. Az olvasáskor felvett áram maximum 400µA 5.5V-os tápfeszültségnél. Nyugalmi áram átlagosan 100 na 5.5V-os tápfeszültségnél. Két vezetékes I 2 C kompatibilis soros busz. Kaszkádba köthető maximum 8 eszköz. Belső időzítésű írási- és olvasási ciklusok. 64 bájt méretű lapok írása támogatott. Maximális írási idő 5 ms. Hardveres írás védelem. Schmitt Trigger-es bemenetek. Egymillió törlés/írás ciklus. Minimum 4 kv-os elektrosztatikus kisülés ellen védett. Adatmegtartási idő legalább 200 év. 8 érintkezős PDIP, SOIC, TSSOP, MSOP, DFN és 14 érintkezős TSSOP tokkal is gyártják.

54 ábra. A 24LC256 típusú soros EEPROM lábkiosztása MAX232A soros vonali illesztő A soros vonal illesztését végzi ez az integrált áramkör (lábkiosztása a a 7.4. ábrán látható). Az 5V-os TTL szintű jeleket ±12V-os szintre alakítja, ehhez négy darab 100 nf-os kondenzátorra van szükség. Két darab bemenetet és két darab kimenetet kezel, ebből csak egyet-egyet használtam fel. Az IC részletes leírása az adatlapján [10] olvasható ábra. A MAX232 típusú soros vonali illesztő lábkiosztása

55 50 8. fejezet Az eszköz használata és tesztelése 8.1. Az eszköz használata A kész eszközön három csatlakozó és öt LED található(8.1. ábra). Jelmagyarázat: 8.1. ábra. A doboz oldal- és elölnézete 1. Soros vonal: egy DSUB9-es csatlakozó található a dobozon. Ezen keresztül történik az RS-232 szabvány szerinti kommunikáció. 2. Ethernet: egy RJ45-ös foglalat van a csavart érpáros kábelnek. 3. Tápfeszültség: a protokollkonverternek 5-15V egyenfeszültségre van szüksége. 4. Link LED (sárga): Ha világít, a kapcsolat létrejött a két ethernet-es készülék között. 5. RX LED (zöld): Ha villog, adatok érkeznek az ethernet hálózaton az eszköz felé. 6. TX LED (zöld): Ha villog, az eszköz adatokat küld az ethernet hálózaton. 7. OK LED (zöld): Ha világít, akkor az eszköz megfelelően működik. 8. ERROR LED (piros): Ha világít, akkor az eszköz működése során hiba lépett fel.

56 51 Az eszköz használata a 8.2. ábrán látható. Az ethernet hálózat kialakítására számtalan lehetőség van: lehet csak csavart érpáros technológiát használni vagy csavart érpáros kábeleket és optikai vagy mikrohullámú átvitelt is. Az áthidalható távolság akár több kilométer is lehet ábra. Az eszköz használata 8.2. Konfigurálás böngészőprogrammal Az eszköz konfigurálását bármilyen böngészőprogrammal elvégezhetjük. Alapesetben az eszköz IP címe hálózati maszkja A címet beírva a böngészőbe a 8.3. ábrán látható képet kell látnunk. A Help linkre kattintva ennek a fejezetnek a kivonatos verzióját olvashatjuk el. Az egyes linkekre kattintva beállíthatjuk a soros vonalat, a hálózatot ill. megtekinthetjük a statisztikákat Hálózat beállítása A Network setup linkre kattintva a 8.4. ábrán látható oldalon a következőket állíthatjuk be: Local IP: az eszköz IP címe (alap: ). Local Port: az eszköz ezen a porton várja az adatokat (alap: 2221). Netmask: hálózati maszk (alap: ). Gateway: ha a cél IP címe másik tartományba esik meg kell adni az átjárót (alap: ). Ha ugyanabban a hálózatban van, akkor az átjáró megegyezik az eszköz IP címével. Target IP: a soros vonalról érkező adatokat ennek az IP címnek fogja továbbítani (alap: ). Target Port: a soros vonalról érkező adatokat a megadott portra küldi (alap: 2222).

57 ábra. Konfigurálás böngészőprogrammal: index 8.4. ábra. Hálózat beállítása böngészőprogrammal

58 53 Refresh rate: A statisztika megtekintésekor ennyi másodpercenként fog frissülni a lap (alap: 10). A Save gombra kattintva az adatokat eltárolja a I 2 C buszos EEPROM-ba és az eszköz lekérdezi a megadott cél IP cím MAC címét Soros vonal beállítása A Serial port setup oldalon (8.5. ábra) a soros vonal sebességét lehet beállítani. A sebesség 2400-tól baud-ig állítható. A Save gombra kattintva a beállítás azonnal érvényes lesz és az értéket elmenti az EEPROM-ba ábra. Soros vonal beállítása böngészőprogrammal Statisztika A statisztikákat tartalmazó oldalon (a 8.6. ábra) láthatjuk az eszköz állapotát (rendben van ill. valamilyen hiba történt), a beállított paramétereket és az eddig átvitt adatok számát bájtban. Ez a HTML oldal automatikusan frissül alapesetben 10 másodpercenként. Ez frissítési érték (Refresh rate) a hálózati beállításokat tartalmazó lapon átállítható tetszőleges értékre.

59 ábra. Statisztika megtekintése böngészőprogrammal 8.3. Az eszköz tesztelése Mivel csak egy eszközt készült el, ezért a teszteléshez számítógépen egy programmal (UDP test) szimuláltam a másik eszközt és egy egyszerű terminálprogrammal küldtem és fogadtam a soros vonali adatokat. A 8.7. ábrán látható az eszköz és a számítógép összekötése ábra. Az eszköz tesztelése Az UDP test (8.8. ábra) nevű programot C++ nyelven írtam direkt azért, hogy a készüléket tesztelni tudjam. A program egy fő ablakból áll, ami két részre van osztva.

60 ábra. Az UDP test program A bal oldalon található egy UDP kliens: a megadott IP címre és annak megadott portjára elküldi a szövegdobozban található szöveget. A jobb oldalon az UDP szerver vezérelhetjük, ami a program futtatásakor automatikusan elindul. A szerver megadott portjára érkező adatokat a program egy szövegdobozban jeleníti meg. A program működését egyszerűen ki lehet próbálni: a szerver címének a loopback eszköz címét kell megadni (például ). Majd a kliensnek is ezt a címet és a szerver portját adjuk meg. Ha az elküld gombra kattintunk az üzenetnek meg kell jelennie a jobb oldali szövegdobozban.