Laborator 14

APLICAIE SERVER HTTP PENTRU BLACKFIN BF537

CUPRINS

Privire de ansamblu asupra funcionalitii unui Embedded Server.................................3 Server-based vs. Embedded Web Servers..............................................................................3 Cerinele Severelor Embedded ..............................................................................................4 Serverul Embedded GoAhead............................................................................................6 Controller-ul Ethernet BF-537 EMAC................................................................................6 Stiva de protocoale LwIP, kernelul VDK i API-ul BSD socket..........................................8 Configurarea i rularea serverului HTTP GoAhead........................................................9Paii necesari configurrii mediului de lucru:..................................................................................10 Paii necesari configurrii i rulrii serverului HTTP:.....................................................................15 Configurarea unui IP static:.............................................................................................................21

Generarea propriilor pagini pentru server-ul web ............................................................24 Crearea paginilor cu coninut dinamic................................................................................27 Procesarea CGI (Common Gateway Interface) n memorie..............................................28 Aplicaie pentru controlul ledurilor de pe BF537...............................................................31

Lucrarea de fa i propune prezentarea principalelor aspecte ale funcionalitii unui server HTTP Embedded, cu particularizare pe serverul Web GoAhead, inclus n exemplele ilustrative ale mediului de lucru2

VisualDSP++. Pentru implementarea aplicaiei cu procesorul Blackfin, mediul VisualDSP++ are incluse: driverele pentru controllerul Ethernet, stiva LwIP ( Light-weight TCP/IP ) i VisualDSP++ Kernel (VDK). Lucrarea conine i un tutorial step-by-step pentru configurarea i rularea serverului GoAhead, crearea de pagini noi, precum i o descriere general a nivelurilor de servicii oferite de server, care permit studenilor s neleag modul de funcionare al acestuia i s i formeze o baz pentru dezvoltarea aplicaiior ulterioare. n ultima parte, este descris pas cu pas implementarea unei aplicaii de control a ledurilor de pe placa Blackfin BF537 din cadrul unei pagini web gzduite pe serverul HTTP GoAhead.

Privire de ansamblu asupra funcionalitii unui Embedded ServerCreterea dramatic a numrului dispozitivelor conectate la Internet este o cauz direct a ieftinirii drastice a hardware-ului, a expansiunii sistemelor de operare puternice pe 32 i chiar 64 de bii precum i a omniprezenei Internet-ului. Pe msura extinderii continue a internetului, n curnd vor fi mai multe aparate i dispozitive conectate la Internet dect oameni care acceseaz internetul. Prin urmare, exist o cretere puternic a cerinei pentru un server Web ncorporat pentru utilizarea n toate aceste dispozitive. Pe msur ce tot mai multe dispozitive sunt conectate la Internet, acestea devin din ce n ce mai puternice i complexe - i vor ajunge rapid cele mai semnificative computere din societatea contemporan. Aparate noi cu sisteme de operare n timp real, protocoale Internet i aplicaii bazate pe dispozitiv apar zilnic i viitorul unei ere post-PC arat promitor. Cu toate acestea, pentru ca astfel de aparate s devin i mai larg rspndite, au nevoie de o metod universal pentru acces i control. Utiliznd un browser pentru client, dispozitivul poate oferi acces de la distan i control printr-un Embedded Server. Cu toate acestea, cele mai multe servere Web nu sunt proiectate pentru a fi ncorporate, iar cele mai multe servere comerciale ncorporate folosesc scheme de proprietate n redarea datelor dinamice.

Server-based vs. Embedded Web Servers

3

La ultima numrtoare (http://webcompare.internet.com), existau peste 39 de servere Web enumerate de WebCompare. Dei exist mult mai multe la ora actual, doar 5 au fost clasificate ca servere Embedded. Deci, care este diferena ntre un server Embedded i un server Serverbased ?

Un server Server-based are un set de cerine foarte diferite i este destinat pentru a satisface nevoile site-urilor care public pagini World Wide Web Server-based i / sau gzduiesc comer electronic. De exemplu, unele dintre cerinele pentru un server Web Server-based includ:

Posibilitatea de a scrie log-uri multiple S suporte Servere Virtuale S confere un agent SNMP

S suporte SSL v. 3 S aib certificare integrat Posibilitatea ntreinerii de la distan S confere motor de cutare

Aceste cerine sunt vitale pentru serverele Server-based de capacitate mare, dar de o valoare mult mai mic pentru serverele Embedded. Serverele Embedded sunt preocupate ndeosebi cu amprentarea de memorie, capacitatea de a genera date dinamice precum i cu portabilitatea codului surs pentru dispozitive din ce n ce mai personalizate.

Cerinele Severelor EmbeddedSistemele integrate au nevoie de servere Web pentru a mbunti funciile existente, fr a afecta funcionalitatea dispozitivelor existente. Cum multe dintre aceste dispozitive sunt constrnse de costuri, resursele de memorie i CPU sunt de multe ori limitate. Este vital ca serverele Embedded s fie foarte eficiente i puin consumatoare de resurse. Cerinele impuse unui server Web Embedded includ:

a) Amprent de memorie redus

O amprent de memorie redus este una dintre cerintele vitale. Pe lng faptul c serverul trebuie s utilizeze o cantitate de memorie redus (cod, heap i stiv), el nu trebuie s fragmenteze memoria. Multe4

dispozitive embedded au scheme de baz de alocare a memoriei care nu utilizeaz memoria n mod eficient. Chiar dac exist mecanisme de alocare eficient a memoriei, serverele Web pot fragmenta memoria prin concurena pentru resurse cu alte aplicaii embedded - n special deoarece serverele Web trebuie s rspund la solicitri rapid pentru a servi paginile. Odat ce memoria utilizat pentru a servi o pagin este eliberat, aceasta poate deveni inutil, deoarece nu poate fi unificat cu blocurile de memorie adiacente din heap. Pentru a rezolva aceast problem, serverele Embedded trebuie s fie fixe n memoria pe care o folosesc. Pre-alocarea sau schemele de alocare static pot fi folosite pentru a rezolva aceast problem.

b) Integrarea facil n dispozitiv Este o cerin vital pentru serverele Embedded ca acestea s poat fi integrate cu uurin. Exist dou aspecte ale integrrii unui server Web: Integrarea aplicaiei serverului Web n RTOS (Real Time Operating System). Integrarea funciilor de acces la dispozitiv n serverul Web. Integrarea unui server Web ntr-o aplicaie este cel mai usor de realizat atunci cnd codul surs este disponibil. Adesea, aplicaiile dispozitivului solicit ca serverul Web s fie integrat ntr-o aplicaie existent sau ca bucla de evenimente a serverului s fie accesibil. n cazul n care serverul web este furnizat numai n form binar, sau obinerea codului surs este prea costisitoare, acest tip de integrare este dificil. Integrarea funciilor de acces la dispozitiv ntr-un server Web necesit crearea unei legturi ntre API-urile de dispozitiv existente i URLuri. Acest lucru poate fi realizat n mai multe moduri, dar de obicei este implementat printr-o metod specific dispozitivului, dictat de furnizorul serverului Web. Este de preferat o metod industrial standard de conectare a dispozitivului la Web.c) Suport pentru stocarea paginilor Web n ROM

Multe dispozitive fr un disc sau un mediu permanent de stocare se doresc a fi accesate i controlate prin intermediul Web-ului. Pentru astfel de dispozitive, o metod de stocare a paginilor Web n ROM este necesar. Serverele Embedded ar trebui s fie capabile s compileze paginile Web i apoi s link-eze obiectul paginii la executabilul rezultat. Serverele bazate pe server Web nu au o astfel de cerin.5

d) Portabilitatea

Pe msur ce inginerii trec adesea de la un proiect hardware la altul, este important ca serverul Web Embedded s aib un grad ridicat de portabilitate. Experiena anterioar trebuie s poat fi transferat de la un proiect la altul. Codul surs care a fost deja portat i testat pe o gam larg de platforme este necesar.

Serverul Embedded GoAheadCu scopul de a fi cel mai rspndit server Web din lume, serverul GoAhead este conceput ca un server Web Embedded, nu att de mult pentru a satisface nevoile de astzi, ct pentru a satisface nevoile de mine, cnd utilizarea sistemelor Embedded, att acas ct i la locul de munc, va cunoate un progres remarcabil. GoAhead Web Server este o parte din GoAhead Embedded Management Framework 2.0, care ncearc s abordeze toate problemele legate de dezvoltarea viitoare a sistemelor Embedded. Ca atare, GoAhead este un server Web miniaturizat, cu o amprent de resurse foarte redus (versiunea compilat pe o main Windows CE ocup sub 60K). Poate deservi pn la 50 cereri pe secund pe un Pentium la 266-MHz. Serverul Embedded GoAhead este scris n C i a fost portat pe diferite sisteme de operare, precum Windows 95/98/NT/CE, Linux, eCos, Embedded Linux, ChorusOS, OSP, MicroC / OS, VxWorks, Lynx, IRIX i Novell Netware. GoAhead Webserver necesit o stiv TCP / IP (descris n paragrafele urmtoare), un timer de evenimente i aproximativ 60 KB de RAM.

Controller-ul Ethernet BF-537 EMACModelul OSI ( Open System Interconnection Reference Model ) este o descriere abstract a unui protocol de comunicaii ce cuprinde apte niveluri, fiecare avnd un rol bine definit i oferind servicii nivelului su imediat superior. TCP/IP (Transmission Control Protocol / Internet Protocol) este un protocol de comunicaii ce conine patru niveluri. Acest protocol de

6

comunicaii permite aplicaiilor s trasmit date indiferent de mediul de comunicaie folosit. Procesoarele ADSP-BF537 sunt echipate cu un controller Ethernet pentru MAC care este compatibil cu standardul IEEE 802.3. Procesoarele folosesc o interfa de standard MII/RMII pentru a conecta dispozitive de reea. Placa ADSP-BF537 KIT-Lite are inclus un circuit SMSC LAN85C183, pentru transmisia la nivel fizic, care se conecteaz la interfaa MII a procesorului, ca n figura 1.

Figura 1

Legtura dintre dintre modelul OSI, TCP/IP i placa ADSP-BF537 se poate observa n figura de mai jos:

7

Figura 2.2

Comunicaiile TCP/IP se realizez ntre o aplicaie client i o aplicaie server, serverul fiind cel care ascult n reea dup un client. Orice aplicaie va realiza urmtorii pai pentru a seta stiva i pentru a iniializa comunicarea ntre cele dou aplicaii : 1. Crearea unei stive (pentru fiecare aplicaie n parte).

2. Crearea unei adrese IP (pentru ca aplicaiile s poat comunica n reea, fiecare trebuie s aibe o adres IP, unic). De asemenea, aplicaiei i se va asocia o adres de port. 3. 4. 5. Stabilirea legturii dintre client i server Realizarea transferului de date nchiderea conexiunii

Stiva de protocoale LwIP, kernelul VDK i API-ul BSD socketPentru a programa o aplicaie n reea, avem nevoie de un RTOS (Real Time Operating System), care este oferit de ctre VisualDSP++ prin kernelul VDK. Acesta este un kernel multitasking, care are ncorporate mecanisme de planificare i de alocare a resurselor compatibile cu8

spaiul de memorie i cu constrngerile de timp necesare programrii procesorului Blackfin. Alte faciliti oferite de VDK sunt realizarea unor aplicaii performante, folosind template-uri (precum cel de realizare al aplicaiilor TCP/iP).

VisualDSP++ are inclus o stiv de protocolale TCP/IP open source, LwIP, compatibil cu arhitectura plcii ADSP-BF537. Folosirea acestei stive implic existena unui sistem de operare, care n cazul nostru este VDK (Visual DSP++ Kernel).

Stiva de compenente:

protocoale

LwIP

are

trei

1. Stiva de protocoale TCP/IP 2. O bibliotec de interfaare cu kernelul folosit 3. (VDK n cazul nostru) 4. O bibliotec de drivere pentru a conecta stiva la controllerul Ethernet (BF537 EMAC n cazul nostru) Un alt lucru ce trebuie menionat este faptul ca stiva LwIP folosete standardul Berckely Sockets Interface (sau socket-uri), ceea ce nseamna c aplicaiile client i server folosesc socket-uri API pentru a transmite i pentru a recepiona date.

Configurarea i rularea serverului HTTP GoAheadAplicatia web este portat de pe un server web Go-Ahead pe Blackfin folosind stiva LwIP ( Light-weight TCP/IP ) i kernelul VDK ( VisualDSP++ Kernel ). Serverul HTTP poate fi gsit n exemplele din folderul de instalare al mediului de lucru, mai concret n: C:\Program Files\Analog Devices\VisualDSP 5.0\Blackfin\Examples\ADSP-BF537 EZ-Kit Lite\LAN\HTTP_Server

9

Paii necesari configurrii mediului de lucru:

1. Conectai cablul USB Debug Agent la placa ADSP-BF537 EZKit Lite i cellalt capt conectai-l la un port USB liber al calculatorului. Conectai placa folosind adaptorul AC la o surs de curent.

Conectai cablul cross-over EIA/TIA 568-B la portul RJ45 al plcii i la cel al calculatorului sau la al unui router ( posibilitate de conectare dispozitive mobile prin wireless).

Se pornete mediul de lucru VisualDSP++, prin dublu-click pe iconia de pe Desktop:2.

10

Adresa IP a plcii poate fi obinut de la un server DHCP. n cazul n care aceast opiune de lucru este disponibil n configuraia aleas, se selecteaz Settings --> Preferences.3.

Din seciunea Plugins se bifeaz TCP/IP Configuration Manager ca n figur, apoi se salveaz cu OK:

Apoi se selecteaz Settings --> TCP/IP Configuration, se alege Network0 i se verific dac este setat opiunea Use DHCP.

11

Selectai din meniul principal Session - New Session, care lanseaz Session Wizard.4.

Session Wizard

12

5.

n fereastra Select processor, se selecteaz din Choose a target processor, ADSP BF537 . Asigurai-v c procesorul din familia Blackfin este selectat. Se apas butonul Next.

6.

Din fereastra Select Connection Type se selecteaz EZ-KIT Lite. Se apas Next.

13

7.

Din fereastra Select Platform se selecteaz ADSP-BF537 EZKIT Lite via Debug Agent din meniul Select your platform. Se completeaz numele sesiunii sau se accepta numele implicit, Session name. Se apas Next.

14

8.

n fereastra Finish se verific nc o dat configuraia setat, iar apoi se apas Finish. Noua sesiune ADSP-BF537 EZ-KIT Lite a fost creat.

Odat configurat mediul de lucru VisualDSP++, trecem la configurarea proiectului HTTP Server n vederea ncrcrii i rulrii sale pe placa EZ-KIT BF537.

Paii necesari configurrii i rulrii serverului HTTP:Vom deschide grupul de proiecte necesare serverului HTTP prin butonul "File --> Open --> Project Group" :1.

15

2.

n Open Project Group Dialog-ul care apare se urmeaz calea C:\Program Files\Analog Devices\VisualDSP 5.0\Blackfin\Examples\ADSP-BF537 EZ-Kit Lite\LAN\HTTP_Server\ i se selecteaz fiierul httpsvrgrpbf537.dpg, dup care se confirm cu Open.

Se deschid doua proiecte, httpserver-BF537.dpj i libwebsvrbf537.dpj, ale cror fiiere pot fi vizualizate n FileBrowserul din partea stng a ecranului.

16

3.

Pentru vizualizarea i eventual, modificarea setrilor generale ale Web serverului, se extinde submeniul cu fiierele surs ale proiectului httpserver-BF537, Source Files, i se face dublu click pe fiierul web_main.c. n partea dreapt se afieaz codul surs al fiierului selectat, unde putem regsi, n regiunea evideniat i n figura de mai jos, principalii parametrii configurabili ai serverului:

17

Numrul portului. Numrul de port implicit pentru webserver este setat la 80. Pentru a schimba numrul portului implicit, se modific linia port = 80. Dac aceast setare implicit este schimbat, atunci cnd se acceseaz pagina de start, va trebui s utilizai "http://xxx.xxx.xxx xxx:yy", unde yy este numrul de port setat. Numrul de rencercri. n mod implicit, serverul web GoAhead rencearc de cinci ori pentru a gsi un port alternativ utilizabil n cazul n care portul implicit nu este disponibil. Aceast valoare implicit poate fi modificat prin schimbarea liniei retries = 5.

Parola. Pentru a proteja prin parol accesul la server, parola poate fi nscris n fiierul de fa. Linia de unde se poate modifica parola este *password = T(""); unde noua parol este nscris ntre ghilimele "". Parola implicit este goal, ceea ce permite accesul iniial la server utilizatorului fr o parol. Pagina de start implicit. Pentru adugarea de pagini noi, vor trebui modificate paginile web din subdirectorul web, aa cum vom vedea n partea urmtoare a tutorialului. Paginile18

web actuale ofer un bun punct de plecare pentru noile modele de pagini web. Dac numele paginii de start implicite este schimbat, codul trebuie s fie, de asemenea, modificat, pentru a reflecta noua pagin de start. Definiia acesteia este situat pe linia websRedirect (WP, T ("home.asp ")); noua pagin de start este nscris n locul celei predefinite: home.asp.

Se salveaz eventualele modificri i se trece la compilarea surselor proiectului. Se acceseaz Project -> Build Project, sau se face click pe iconia din figura de mai jos, sau se apas direct F7 ( Shortcut Key-ul pentru Build ):4.

Dac Build-uirea proiectelor s-a ncheiat fr erori, se trece la execuia programului, mai concret, la rularea efectiv a serverului. Se apas butonul Run din meniul Debug sau se face click pe iconia din figura de mai jos sau se apas F5.

19

Aplicaia red URL-ul pe care trebuie s l accesai , asemntor cu figura de mai jos:

Deschidei un browser de Internet (pe calculatorul conectat la plac, sau pe orice alt dispozitiv conectat n aceeai reea prin intermediul routerului) i scriei URL-ul afiat n VisualDSP++. Serverul HTTP rspunde cu paginile accesate:

20

Configurarea unui IP static:n cazul n care configuraia realizat pentru rularea serverului HTTP nu ofer posibilitatea conectrii la un server/router capabil s fac DHCP sau pur i simplu se dorete configurarea unui IP static pentru plac, mediul de lucru VisualDSP++ ofer aceast posibilitate.

Pentru un IP static, se selecteaz Settings -> Preferences, apoi se alege Plugin i se bifeaz TCP/IP Configuration Manager, dac nu este deja bifat, exact ca la pasul 1 de la configurarea DHCP. Se confirm cu OK.

21

Apoi, se selecteaz Settings > TCP/IP Configuration, se alege Network0 i se debifeaz opiunea Use DHCP, n caz c aceasta este bifat. Se completeaz adresa IP, Subnet Mask-ul , adresa Gateway i adresa MAC. Iat un exemplu n figura urmtoare:

22

Dup completarea acestor rubrici, se confirm cu butonul OK. Ni se cere salvarea configuraiei alese ntr-un fiier cu extensia .tcp ( TCP/IP Configuration File ). Se denumete dup plac fiierul cu configuraia aleas, dup care se salveaz cu Save.

De menionat c dispozitivul conectat n reea cu placa, fie el chiar calculatorul de pe ncrcm proiectul, fie un telefon mobil sau alt calculator conectat prin intermediul routerului, trebuie s fie configurat la rndul lui cu un ip static, din aceeai clas de ip-uri cu cel setat pentru plac. Aceast setare este esenial pentru stabilirea conexiunii, din moment ce nu mai avem serverul de DHCP, care realiza acest lucru.

23

Recompilm proiectele i rulm programul, relund aceeai pai de la configuraia care folosete DHCP. Observaie! n cadrul testelor din laborator, am folosit configuraia cu ip static pentru plac, atunci cnd ne-am conectat prin intermediul telefoanelor mobile folosind sisteme de operare precum Android, sau Windows Mobile, respectiv dintr-o main virtual ce emula sistemul de operare MeeGo.

Generarea propriilor pagini pentru server-ul webAa cum am observat n exemplul de configurare i rulare a serverului HTTP, pagina exemplu a fost un fiier HTML, pus la dispoziie tot n folderul cu materialele exemplificatoare. Dar dac utilizatorul dorete generarea propriilor pagini de ctre serverul HTTP, spre a putea fi apoi accesate de orice client care acceseaz serverul? Acest lucru l putem realiza cu ajutorul Webcomp-ului, un utilitar care preia paginile dorite dintr-un fiier (denumirile lor) i genereaz un fiier de date, webrom.c, care conine descrierea static a coninutului paginilor. n plus, vom vedea n capitolul urmtor, c utilitarul webcomp poate compila i fiiere cu alte extensii n afar de .html sau imagini, cu coninut dinamic, precum fiiere .ASP. Paii necesari generrii propriilor pagini web sunt urmtorii:

24

Copierea fiierelor aferente paginilor proprii (fiiere .html sau .ASP + eventualele poze referite n acestea ) n directorul web, din cadrul proiectului. Aceste pagini se presupun1.

a fi anterior create de utilizator n orice editor text simplu sau mediu pentru Site Developement. Condiia fireasc este ca sintaxa HTML/ASP a paginilor s fie corect. Pentru exemplificare, am creat un fiier HTML basic, test.html, n care afim un text pe ecran i o imagine, test_image.gif.

Copiem cele dou fiiere n directorul web din cadrul proiectului, aa cum am precizat mai sus. Deschidem fiierul files din acelai director menionat anterior, web, cu orice editor de text, pentru a aduga n lista fiierelor ce urmeaz a fi compilate de utilitarul webcomp cele dou fiiere dorite.2.

25

Salvm noul coninut al fiierului i nchidem editorul de text. Pornim un terminal linie de comand, de unde urmeaz s introducem comanda pentru generarea fiierului webrom.c cu ajutorul utilitarului webcomp.exe.3.

Pentru aceasta, trebuie s ne plasm n directorul n care se afl executabilul webcomp, fiierul files i, respectiv, paginile noastre, n cazul de fa chiar directorul web.

Odat realizat acest lucru, introducem n linia de comand urmtoarea comand, pentru generarea fiierului webrom.c, cu coninutul static al paginilor dorite :

webcomp.exe / files > webrom.c

4. Se copiaz noul fiier generat, webrom.c, in directorul ws031202 ( one level-up ), avnd grij s l nlocuim pe cel anterior. 5. Se reiau toi paii pentru compilarea i rularea proiectului. Dup ce serverul rspunde cu adresa IP, putem verifica existena noilor pagini create, introducnd n browser urmtorul URL :26

http://172.16.2.22/test.html unde 172.16.2.22 este adresa IP atribuit de ctre serverul DHCP (sau cea setat static de utilizator) la aceast rulare. Serverul rspunde cu pagina web nou adugat:

Crearea paginilor cu coninut dinamicExist dou modaliti principale de a crea o pagin Web dinamic n cadrul serverului HTTP GoAhead:

Generarea tag-urilor HTML prin cod convenional C Crearea paginii Web i a introducerea datelor dinamice prin tag-uri de expansiune

Generarea de tag-uri HTML prin cod C nu necesit o manipulare special de ctre serverul Web i poate prea o abordare atractiv la nceput. Cu toate acestea, nu dureaz mult timp pn ce ntreg ciclul repetitiv "editare, compilare, display, re-editare, re-compilare, re-display" devine foarte obositor. Paginile Web sunt greu de manageriat fr un rezultat final imediat. Cea de-a doua abordare permite cicluri de dezvoltare mult mai rapide. Instrumente de proiectare HTML, cum ar fi DreamWeaver, pot fi folosite pentru a crea pagini Web ntr-o manier WYSIWYG (What-YouSee-Is-What-You-Get). Tot ceea ce rmne, sunt datele dinamice care trebuie nlocuite la momentul execuiei.27

Procesarea CGI (Common Gateway Interface) n memorieProcesarea Common Gateway Interface (CGI), pus n aplicare ca un procesor de formulare n memorie reprezint o metod specific serverului GoAhead de a conferi coninut dinamic paginilor. Procesarea CGI n stil vechi rezulta n crearea unui nou proces pentru fiecare cerere a unui URL CGI. Din moment ce unul din scopurile principale ale CGI este adesea prelucrarea datelor introduse de utilizator, acest aspect era foarte lent i greoi. Din aceast cauz, serverul web GoAhead folosete o implementare proprie a CGI, numit generic GoForms, care este o soluie mult mai potrivit pentru sisteme integrate care solicit solutii compacte, de nalt performan. Procedurile GoForms ruleaz n memorie fr a crea un nou proces pentru fiecare conexiune browser. Prin partajarea spaiului de adrese cu serverul web GoAhead, procedurile GoForms pot accesa direct contextul complet al cererii. De asemenea, handler-ul GoForm decodific i parseaz toate datele POST pentru facilizarea accesului la date. GoForms este implementat ca un Handler URL Handler care interpreteaz adresele URL care ncep cu "/goform". Segmentul URL ce preced "goform" definete numele form-ului, urmat de eventualele variabile POST. De exemplu: / goform / myForm? name =John&vrst=30 Apeleaz procedura GoForm denumit "myForm" i decodific automat querystring-ul "name = John & vrst = 30", definind variabilele GoForm numite "nume" i "vrst". Procedura trebuie declarat i ulterior definit n cadrul fiierului main.c al proiectului HTTP Server. Pentru a nelege mai bine ntreg mecanismul procedurilor GoForms, de la declararea i definirea acestora, pn la apelarea procedurilor i modul de trasmitere si parsare al parametrilor, s construim un exemplu simplu de prelucrare a datelor utilizatorului. Iat paii necesari:1.

Crem un fiier cu extensia .html/.asp, n care vom scrie urmtorul coninut :

28

Codul HTML realizeaz un simplu form pentru inputul a dou cmpuri de ctre utilizator, unul pentru nume, respectivul unul pentru adres. De remarcat modul n care se definete handlerul pentru POST-ul form-ului. De menionat c fiierul cu codul surs este prezent i pe DVD-ul cu materialele proiectului, chiar n folderul web, sub numele de forms.asp. Este de datoria studentului de a verifica nc o data validitatea codului i de a aduga numele fiierului n fiierul files , dac acest lucru nu a fost fcut deja, n vederea generrii paginilor cu ajutorul webcomp.exe.

Se reiau paii 3. i 4. de la generarea propriilor pagini web, n care se genereaz din nou fiierul webrom.c cu ajutorul utilitarului webcomp.exe.2.

nainte de a trece la rularea serverului i testarea paginii, trebuie s definim ns procedura GoForm apelat de aciunea de submit a form-ului din documentul HTML. Acest lucru se realizeaz n acelai fiier din care am vzut c se poate configura Webserverul GoAhead, i anume fiierul web_main.c. Deschidem din nou fiierul n mediul de lucru VisualDSP++ i completm, ca n figura de mai jos, partea de declaraii ale antetelor de funcii, cu antetul procedurii GoForm :3.

29

Corpul procedurii formTest l vom scrie n partea de jos a fiierului, printre celelalte definiii de funcii deja existente, salvnd ulterior fiierul cu modificrile fcute:

Aceasta ar trebui s afieze n pagina din browser input-ul utilizatorului din form-ul HTML creat anterior. De menionat c procedura GoForm este responsabil pentru scrierea antetului HTTP i a coninutului HTML al documentului napoi n browser-ul utilizatorului. Funcia websHeader creeaz un antet HTTP30

standard cu tag-uri HTML iniiale. websFooter nchide documentul cu o etichet de nchidere HTML. n interiorul procedurilor GoForm, websGetVar, websRedirect, websWrite, i websWriteBlock sunt unele dintre cele mai utile apeluri API.

Se recompileaz sursele proiectului, dup care se ruleaz. Dup ce serverul afieaz adresa IP ( obinut prin DHCP sau setat static ), se introduce n browser URL-ul pentru form-ul creat de noi anterior:4.

http://172.16.2.22/forms.asp,

Dup ce completm cele dou cmpuri cu valori de test i apsm butonul OK ( event-ul de submit al form-ului ), putem observa c serverul execut procedura definit de noi i reafieaz noul coninut al paginii HTML ( aa cum a fost el redefinit n procedur, incluznd i datele POST ale utilizatorului ):

Aplicaie pentru controlul ledurilor de pe BF537n cele ce urmeaz, vom prezenta o aplicaie pentru controlul ledurilor de pe placa BF537, de la distan, prin intermediul unor butoane din cadrul unei pagini ncrcate pe serverul HTTP GoAhead. Mecanismul principal de preluare a datelor utilizatorului (controlul butoanelor) i de comandare a led-urilor de pe plac este procesarea CGI, implementat prin procedurile GoForms, prezentate anterior.

31

Observaie! n cadrul documentaiei, folderul Aplicaie HHTP_Server conine proiectul prezentat de fa n stadiul final. Totui, se recomand studentului reluarea tuturor pailor descrii i realizarea mcar a unei proceduri pentru un led, pentru a nelege mai bine cele prezentate. Folderul HTTP_Server conine sursele iniiale ale web serverului, aa cum se gsesc ele n exemplul celor de la Analog Devices, studentul putnd porni de la acesta i modifica sursele, urmnd tutorialele step-by-step din proiectul de fa. Vom ncepe cu realizarea interfeei grafice pentru controlul LEDurilor, i anume chiar pagina web care va fi ncrcat pe serverul HTTP. Am ales o interfa simplist, dar destul de sugestiv i intuitiv:

Cele 6 butoane corespund celor 6 led-uri principale de pe placa Blackfin BF537, iar cele dou stri ale butoanelor corespund aprinderii/stingerii ledurilor. Codul aferent design-ului paginii de mai sus este prezent n cadrul documentaiei, n fiierul butoane.asp, din acelai folder web ( folderul cu toate paginile web ). Iat-l ilustrat i n captura de mai jos:

32

Urmeaz definirea procedurilor din spatele butoanelor HTML, care vor fi apelate odat cu evenimentul de click asociat fiecrui buton n parte. Pentru fiecare led n parte vom avea dou proceduri, una asociat aprinderii acestuia, respectiv cealalt asociat stingerii ledului. Vom ncepe prin declaraiile celor 12 proceduri (6 leduri X 2 proceduri pentru fiecare), declaraii ce trebuie inserate n sursa C principal a proiectului, web_main.c, procednd exact ca la exemplul cu formularul din capitolul anterior, cel cu procedurile GoForms, insernd codul din figurile de mai jos:

33

De asemenea, tot n cadrul acestui fiier, trebuie s introducem codul necesar iniializrii configuraiei ledurilor, precum i headerele n care sunt definii regitrii responsabili cu controlul celor 6 leduri. Codul de mai jos este importat din proiectul exemplificativ LED Blink (C), din cadrul fiierului surs Initialization.c:

Continum cu definirea procedurilor responsabile cu aprinderea/stingerea ledurilor i respectiv, cu reconstrucia paginii web iniiale n care modificm ns starea butonului apsat, ntruct coninutul paginii iniiale, butoane.asp, este pierdut practic la momentul postprocesrii CGI. Acesta este motivul pentru care trebuie s rescriem n fiecare procedur liniile de cod responsabile cu trimiterea codului HTML34

ctre browser. Simulm astfel dinamicitatea paginii web prin reconstrucia ei la apsarea fiecrui buton (n fiecare procedura GoForm). ntreg codul pentru cele 12 proceduri este scris n cadrul fiierului web_main.c de pe DVD-ul cu documentaia. n cele ce urmeaz vom ilustra i explica partea de cod aferent aprinderii/stingerii unui led, pentru celelalte raionamentul fiind analog. Iat procedura led1_on, asociat aprinderii ledului 1:

Explicaii figur:1.

Vectorul leduri[7] este un vector de ntregi, declarat alturi de celelelalte prototipuri ale funciilor, n partea de nceput a fiierului web_main.c: static int leduri[7]; indexul acestui vector se asociaz fiecrui led n parte ( leduri[1] pentru ledul 1, leduri[2] pentru ledul 2...) iar valoarea poate fi 0-led stins, 1-led aprins. Acesta va folosi la comandarea ledurilor din funcia aprinde(), descris mai jos.

2.

Funcia aprinde() are codul ilustrat n figura urmtoare:

35

Funcia realizeaz stingerea tuturor ledurilor, prin setarea registrului *pPORTFIO_CLEAR, urmnd apoi a le aprinde pe cele ale cror valori corespunztoare din vectorul leduri[] sunt 1-ledul trebuie aprins. Celelelate rmn stinse.3.

Funcia webswrite() este folosit pentru trimiterea codului HTML ctre browser, urmnd a reconstrui pagina HTML iniial.

4. Cele 6 condiii, pentru fiecare led n parte, sunt folosite n determinarea pozei corespunztoare strii fiecrui led n parte, poz a crei cale este transmis browserului pentru a fi afiat i a reda fidel starea ledurilor. Procedura pentru stingerea ledului este identic procedurii pentru aprinderea sa, cu excepia faptului c vom seta valoarea 0 n vectorul de leduri, mai concret linia leduri[1]=1 va fi nlocuit de leduri[1]=0, corespunztoare stingerii ledului 1. Celelalte proceduri, corespunztoare celorlalte leduri, sunt identice procedurii ledului 1, exceptnd indicele din vectorul de leduri, care se va schimba n funcie de ledul curent ( leduri[2] pentru ledul 2, leduri[3] pentru ledul 3 etc.). Dup scrierea tuturor celor 12 proceduri corespunztoare ambelor stri posibile pentru cele 6 leduri, relum paii de Build-uire a proiectului, urmnd a rula serverul dup corectarea tuturor eventualelor erori de compilare sau linkeditare.

36

Dac proiectul se ncarc cu succes pe plac i ruleaz, vom introduce n browser URL-ul: http://192.168.0.3/butoane.asp,

unde 192.168.0.3 este ip-ul serverului web la aceast rulare ( setat static n cazul de fa ). Serverul web rspunde cu pagina cu design-ul implementat de noi, pagin n care toate ledurile sunt stinse, stare redat i la nivelul plcii, aa cum este i normal pentru starea iniial ( setrile iniiale includ stingerea tuturor ledurilor, dac acestea nu sunt deja stinse ).

37

Apsnd pe oricare dintre leduri, observm c pagina se modific corespunztor butonului apsat (poza butonului), concomitent cu aprinderea/stingerea ledului corespunztor pe plac.

38

Apsnd mai multe butoane, observm c aplicaia red fidel modificrile n pagin precum i starea ledurilor de pe plac:

39

De remarcat modificarea URL-ului paginii la fiecare click cu URL-ul corespunztor ultimei rutine GoForm apelate n cadrul proiectului. Astfel, pentru ultima captur din browser, URL-ul este http://192.168.0.3/goform/led3_on, deci ultimul input al utilizatorului din browser a fost click pe butonul pentru aprins ledul 3.40