comunicacions mitjan§ant el bus usb - inici

Comunicacions mitjançant el bus USB

Pàg. 1


Pàg. 2

1. MEMÒRIA DESCRIPTIVA


Pàg. 3

1.1. Introducció

L’objectiu d’aquest apartat és descriure la totalitat de les funcions d’aquestprojecte, així com detallar les seves particularitats desglossant el muntatge quantes cregui necessari en parts més petites per a facilitar la seva comprensió.


Pàg. 4

1.2. Introducció al bus USB

Amb l’arribada d’ordenadors més potents destinats als usuaris domèstics, s’han fetpatents unes necessitats que aquests fins al moment no tenien o solucionaven deforma poc satisfactòria. D’aquesta manera, es tenia que eliminar el llast quesuposava la limitada capacitat d’ampliació de l’aparell en quant a número deperifèrics i la forma que tenia l’usuari per a interconectar-los amb l’ordinador, aligual que es tenia que eliminar la dificultat que això podia suposar en certs casoson era necessari obrir l’ordinador i seleccionar una configuració per hardware.

També es requereix una ampliació de l’ample de banda per a la connexió ambaquests perifèrics i finalment es necessitava un sistema estàndard, homologat irelativament barat per a poder llançar diferents productes al mercat d’una formamés econòmica.

Tot això es el que va motivar un grup d’investigadors a desenvolupar un nouestàndard per a la connexió de perifèrics a l’ordenador. Aquests van desenvoluparel USB (Universal Serial Bus). Un protocol destinat a solucionar les limitacionsanteriors amb uns avantatges difícils de superar.

Aquests son el sues principals avantatges respecte el port sèrie o paral·lel existentsactualment:

• ‘Hot-pluged’, el perifèric es pot connectar directament a l’ordenador sensetenir la necessitat de resetejar la màquina.

• Facilitat d’us, el nou hardware es configura automàticament i els driversnecessaris es carreguen al detectar la connexió del dispositiu.

• Connector unificat, tots els fabricants han de seguir l’estàndard a l’hora dellançar nous productes el qual inclou una definició per als connectors.

• Bon comportament, el protocol permet un comunicació fins a 12Mbpssuperior a la que ofereixen solucions usades actualment.

• Fins a 128 perifèrics. Si la configuració ho permet, es poden connectar enun sol ordenador un gran número de perifèrics.

• Alimentació pel propi cable, quant el perifèric requereix una petitaalimentació, aquesta la pot subministrar el propi ordenador.


Pàg. 5

• Els dispositius es desconnecten automàticament quant no estan essentutilitzats.

• Deteccions d’errors i solució dels mateixos pel propi protocol decomunicacions.

• No hi ha necessitat d’obrir l’ordenador per a permetre la connexió de nousperifèrics.

• Suport pel propi sistema operatiu en quant a disponibilitat de driversnecessaris.

No obstant no ens podem quedar exclusivament amb el avantatges que ens ofereixaquest nou protocol, hem d’ésser conscients, de la mateixa manera, de leslimitacions que aquest ens comporta.

Una enumeració més o menys exhaustiva seria la següent:

• Falta de suport en sistemes anteriors a l’aparició del protocol (sistemaoperatiu mínim recomanat Windows 98 o superior).

• Limitacions en la velocitat, molt superior als mitjans anteriors però encaralimitat per a la transmissió d’imatges de vídeo.

• Distancia limitada, la llargada màxima del cable es de 5 m. que elconverteix en un protocol on tots els perifèrics han d’estar relativament aprop.

• Novetat en el producte que fa que alguns perifèrics del mercat no s’adaptindel tot al protocol i puguin no funcionar correctament.

• Complexitat en el protocol al tenir que programar el hardware per a ques’adapti al protocol establert per a les comunicacions.

• Limitacions que sofreixen els drivers aportats pel sistema operatiu enquant a que encara s’estan desenvolupant.

• Sistemes de comunicació limitats i sempre amb comunicacionsdesencadenades pel controlador principal (comunicacions per polling).

• Temps compartit entre tots el dispositius connectats el que implica que amés elements pot arribar a disminuir el rendiment del sistema.


Pàg. 6

No obstant, tot i les limitacions observades anteriorment i la seva relativacomplexitat i novetat, aquest es un protocol amb molt de futur gràcies al suportque ha rebut per part de dissenyadors i desarrolladors tant de hardware com desoftware. Això unit a que futures versions com per exemple la 2.0 estarandisponibles amb un ample de banda de 480 Mbps fan que valgui la pena molestar-se a desenvolupar productes orientats al sistema.

El que veurem a continuació son unes explicacions que facilitaran la comprensiódels passos seguits en el projecte i el perquè de cada cosa que utilitzarem. De totesmaneres, no s’intenta que les explicacions següents siguin una explicació detalladade com funciona el protocol en el bus ni explicar quins són els passos que fa elsistema operatiu per a poder-se relacionar amb el nivell hardware. Amb aquestafinalitat ja es van desenvolupar les especificacions per al USB a les quals fanreferència els apartats que tractarem a continuació.

1.2.1. Requisits necessaris del sistema

El primer que farem serà enunciar els aspectes mínims que ha de complirl’ordenador amb la finalitat que la nostra aplicació es pugui comunicar amb elperifèric dissenyat:

El sistema operatiu ha de tenir el suport necessari per a les comunicacionsmitjançant USB. D’aquesta manera, el desenvolupament del producte es molt méssenzill si el sistema operatiu aporta les eines necessàries.

Windows 95 ja disposa d’algun del mitjans en les últimes versions però aquests esveuen millorats en gran mesura amb l’aparició del Windows 98. No obstant lesplataformes que fan servir el sistema operatiu DOS, Windows 3.x o Windows NTv.4.0 no disposen de cap suport per a dites comunicacions tot i que hi ha driversespecífics aportats per terceres companyies que ens podrien fer servei. Al igualque Windows 98, Windows 2000 ja disposa de totes les eines necessàries.

Per facilitar el desenvolupament del projecte la nostra aplicació està orientada ausuaris els quals disposen d’una plataforma amb el sistema operatiu Windows 98.

De la mateixa manera l’ordenador ha de tenir un controlador per a comunicacionsamb USB sense el qual aquestes son impossibles. Actualment la majoriad’ordenadors que surten al mercat disposen d’un controlador amb dos ports. Siaquest no es el cas, molts fabricants han tret al mercat targetes PCI amb elcontrolador i els ports necessaris inclosos.


Pàg. 7

Els components existents en la part de l’ordenador el componen un HC (HCController) o controlador principal que es l’encarregat de formatejar les dades pera la seva transmissió i el (Root Hub) o hub principal que es l’encarregat dedetectar l’annexió de nous components que poden ser perifèrics connectats alsnodes de sortida o més Hubs, i és al mateix temps, l’encarregat de transmetre lesinformacions i peticions del l’HC als diferents nodes.

Gràficament, tot el sistema podria descompondre en un seguit de connexions enmode piramidal com el que podem veure tot seguit:

La connexió es pot realitzar en forma de cascada, connectant a la sortida del Hubprincipal un altre Hub i així successivament. Aquesta estructura piramidal podriaésser una de les configuracions possibles físicament on 7 son el nivell màxims deHubs que es poden posar en cadena i 128 el número màxim de perifèrics o nodesque es poden connectar al sistema sempre que l’ample de banda i els recursosdisponibles ho permetin com veurem més endavant.


Pàg. 8

Com a comentari indicarem que revistes independents que han fet estudis alrespecte comencen a trobar limitacions i mancances en l’estàndard USB v.1.0 apartir de la connexió de 10 perifèrics.

1.2.1.1. Conceptes

En el món de l’USB hem de distingir i tenir clars els següents conceptes que sonbàsics per a la comprensió del protocol:

HC Controller (HC), que com hem vist abans i comentarem més endavant esl’encarregat de desencadenar totes les comunicacions.

Funció que és defineix com una utilitat exclusiva de les que disposa un perifèric.Així doncs, un component o perifèric pot tenir una o varies funcions. Per exempleun teclat té una funció per a comunicar la tecla premuda i una de diferent peril·luminar el led indicant la selecció de majúscules o altres seleccions.

Hub que és un component el qual està destinat a encadenar ports de sortida per aaltres components que poden ésser més perifèrics o altres hubs. Aquests han detenir els components necessaris per a realitzar funcions tal com identificar-se,transmetre ordres o alimentar altres components entre d’altres.

Algunes vegades es pot distingir entre component i perifèric, així per exemple uncomponent pot estar format per un perifèric i s’hi pot incloure funcions de Hub, laqual cosa a nivell de USB se l’hi atorgarien dos adreces diferents.

Endpoint o traduït literalment es pot definir com a destí. Aquest, com diu la sevapròpia traducció és el final i origen de tota comunicació en el bus. Cada dispositiudisposa d’un mínim d’un endpoint de control més els que siguin necessaris per ala pròpia finalitat de l’aplicació.

Finalment aclarirem el concepte de port el qual es diferent al que estàvemacostumats a veure. Fins ara relacionàvem el terme port amb una direccióespecifica amb la seva adreça i la seva forma i camí exclusiu per a l’informació.No obstant en el món del USB, cada perifèric està situat en un port exclusiu però adiferencia de l’anterior només tenim el HC (HC Controller) amb una direcció dememòria la qual cosa implica que tots els perifèrics, tot i tenir la seva connexió icables propis, comparteixen el temps i espai en memòria de comunicació i sols undels perifèrics o el HC pot enviar informació en cada instant.


Pàg. 9

1.2.2. Funcions específiques de cada element

Entrant una mica més en matèria, veurem quina es la funció de cada un delselements que componen el sistema, entenent per sistema tots els components queestan connectats al HC Controller.

1.2.2.1. Funcions del HC Controller

Començarem per llistar les funcions del propi HC les quals estan ben definides.

Podríem començar dient que el HC es l’encarregat de saber quins perifèrics estanconnectats i saber, de la mateixa manera, que pot i ha de fer cadascun d’aquestsperifèrics.

Tots aquests perifèrics han de poder enviar i rebre informació però com que eltemps es compartit les especificacions defineixen com s’ha de repartir el temps iés el HC l’encarregat de que això així sigui.

El suport que aporta Windows 98 fa que l’aplicació sols necessiti enviar i rebreinformació la qual cosa fa que la forma en que això es realitza sigui transparentper a l’usuari i el dissenyador de l’aplicació. D’aquest forma el dissenyador delsoftware sols ha de conèixer unes funcions, algunes de les quals veurem mésendavant i ens ajudaran en la tasca de controlar el perifèric.

De la mateixa manera en el component Hardware hem d’adaptar el perifèric per aque respongui a unes instruccions del HC sense necessitat de conèixer quin es elcomportament del software.

Continuant amb les funcions del HC, aquest ha de configurar un component quantel Hub detecta que aquest s’ha connectat al sistema. Això es realitza mitjançant unprocés que s’anomena enumeració. En aquest procés el HC designa una adreça peral perifèric i l’hi reclama informació per a saber més sobre aquest sistema.Veurem més endavant en detall aquest procés que es crític per al correctefuncionament del perifèric.


Pàg. 10

Totes les transmissions es realitzen en finestres d’1 milisegon de durada, això voldir que en aquest espai tots el perifèrics tenen un marge assignat pel HC per arebre i enviar informació. Durant el procés d’enumeració cada perifèric informa alHC de l’ample de banda que necessita per a comunicacions amb ample de bandagarantit (com poden ésser equips de música que necessiten rebre informació deforma continuada i de forma ininterrompuda). Si l’ample de banda que requereixel perifèric no està disponible per la saturació del sistema es denega al perifèricl’ús del bus. Es llavors quant el driver pot demanar un ample de banda inferior oesperar que aquest estigui disponible per a poder funcionar.

Una altra responsabilitat del HC consisteix en controlar l’informació per a poderdeterminar si hi ha hagut errors en la comunicació. D’aquesta manera pot afegirinformació per a que aquesta estigui enviada de forma redundant o be enviar bitsper a controlar errors. En cas de que existeixin errors es procedeix al reenvio del’informació. De totes maneres existeix la possibilitat d’enviar informació evitantque aquesta es vegi sotmesa a controls de paritat o d’errors de forma que esgaranteixi una quantitat de dades transmeses quant no es necessari o no es potperdre temps per mirar si aquesta té errors o no.

També es feina del HC detectar quant un perifèric te problemes en la recepció otransmissió d’informació, en aquest cas avisa al driver que al seu temps avisal’aplicació que hauria de prendre les mesures corresponents per a solucionar elproblema.

Finalment destacarem com a una última funció del HC alimentar els perifèricssempre que aquest ho demanin i aquests compleixi unes condicions (consummàxim limitat, possibilitat d’entrar en estat de Suspens reduint al mínim el consumperò amb atenció al canal de comunicacions per a despertar quant sigui requerit).


Pàg. 11

1.2.2.2. Funcions dels Hubs

S’ha de tenir present que en l’estàndard USB tots els perifèrics i dispositius s’hande connectar a un Hub. D’aquesta manera això implica que un perifèric connectatdirectament a l’ordenador, es troba connectat al Root Hub.

Ja hem pogut observar o hem comentat que un Hub es un dispositiu ‘intel·ligent’destinat a subministrar punts de connexió físics per a altres dispositius.

Aquest dispositiu, com veurem més endavant, en gran part es responsable decomunicar-se amb el HC per informar-l’ho de la presencia de dispositius nousacabats de connectar.

Una altra gran funció per a la qual estan dissenyats els Hubs és la de transmetreinformació del HC fins a la posició física del dispositiu, comunicant-se amb altresHubs si es necessari.

Finalment hem de destacar la tercera tasca per a la qual es imprescindible aquestdispositiu. Es l’encarregat de detectar dispositius que funcionen de formaincorrecta i un cop localitzats inhabilitar el port al qual estan connectats.D’aquesta forma aquest dispositiu no pot interferir en el correcte funcionament dela resta del sistema.

No es imprescindible saber en detall com tot això afecta a les comunicacions peròtenir algun dels punts clars es imprescindible per a poder dissenyar el nostreperifèric.


Pàg. 12

1.2.2.3. Funcions del perifèric

La principal funció que ha de complir un perifèric es la d’observar i respondre ales peticions del HC. Apart d’això s’ha de tenir en compte que aquests tenenfuncions pròpies que depenen en cada cas de la finalitat per a la qual ha estatdissenyat el perifèric en qüestió.

Un perifèric mai pot començar una comunicació de forma espontània amb el HC,d’aquesta manera ha d’esperar i respondre a peticions per part d’aquest ja sigui perpolling o per resposta a peticions.

El controlador USB o interface que incorpora cada perifèric controla en gran partles comunicacions amb el HC, de totes maneres depenent d’aquest controladorveurem fins a quin punt hem de programar en el dispositiu esclau de l’interfacepart de les respostes.

Cada perifèric controla en tot moment les comunicacions que es realitzen en elsistema, i aquest ha d’estar preparat per a respondre quant la direcció a que estàdirigida la comunicació es la que té assignada com a pròpia, que ha determinat elHC amb anterioritat.

El procés d’enumeració introduït amb anterioritat, està compost per 11 comandesde control concretes, el perifèric ha d’estar capacitat per a respondre a cada unad’elles i prendre les accions necessàries que la comanda impliqui.

Al igual que el HC envia bits de paritat, el perifèric ha de prendre les mesurespertinents quant detecta un error que en el seu cas equival a validar l’informació oignorar-la quant detecti un error en aquesta.

Si el perifèric està alimentat pel propi bus, a de complir les condicions necessàriesper a complir amb les limitacions que això imposa. Aquestes limitacions sónconsumir no més de 500 mA en funcionament estàndard, no consumir més de 100mA durant el procés d'enumeració o consumir un màxim d’entre 0.5 i 2.5 mAdepenent de la configuració en estat d’Standby.


Pàg. 13

1.2.2.4. Funcions del Sistema operatiu

Si fem una representació dels passos que segueixen les instruccions que executemveuríem com aquestes es desplacen en l’esquema que representem a continuació:

Win32 APIs

I/O request packets

I/O request packets

Interface específic del Hardware

Aplicació

Subsistema Win32

ModoUsuari

Hardware DD

Bus Drivers

ModoKernel

Hardware


Pàg. 14

Com veiem, Windows 98 fa servir un model escalar per als Drivers amb diversosDrivers per connectar els components i els seus diferents bussos. Si considerem unDriver com un programa de software específic que fem servir per comunicar-nosamb un dispositiu de hardware, el primer que hem de fer es especificar quin es eldriver que el nostre perifèric farà servir per relacionar-se amb el sistema i enconcret amb la nostra aplicació.

El que el sistema operatiu ha de fer es acabar d’omplir el trencaclosques, aixòsignifica detectar i instal·lar el Hardware DD o Device Driver. Aquest podria éssercreat específicament per a un perifèric en qüestió o, com en la solució queapliquem nosaltres, utilitzar els drivers que facilita Windows 98.

Els passos que es segueixen per a completar el trencaclosques al que ens referimson els següents: en primer lloc hem de connectar el dispositiu, Windows enaquest punt comença automàticament el procés d’enumeració a partir del qual, iun cop obtingudes les taules descriptores del dispositiu les compara amb els arxiusde descripcions *.INF d’on obté els drivers necessaris que pugui necessitarcadascun dels dispositius que componen la base de dades d’històrics ambdispositius connectats amb anterioritat.

El següent pas correspon a l’aplicació que ha d’aconseguir crear una comunicacióamb el dispositiu a partir de l’execució de certes instruccions que veurem mésendavant.

El problema o més ben dit limitació que hem d’afrontar en aquest moment es quefins ara Windows 98 només facilita els drivers per a una classe de dispositiusanomenats HID (Human Interface Device)

Primer definirem que és un HID. El bus USB engloba un conjunt de classes ogrups de dispositius que es consideren que tenen unes característiques semblantsla qual cosa implica que fan servir els mateixos recursos i de la mateixa manera.Diverses classes definides fins al moment són entre d’altres: equips d’àudio,impressores, escaners...

El fet d’englobar els diferents perifèrics en una classe determinada ens garanteixque aquests tindran unes necessitats de comunicacions molt semblants amb la qualcosa podrem fer servir els mateixos drivers sense que això ens limiti les capacitatsfuncionals. Una de les primeres classes que fins al moment esta suportadaplenament pel sistema operatiu son els HID que es poden generalitzar comperifèrics que interactuen directament amb l’usuari com per exemple teclats oratolins. No obstant s’espera que en un futur no molt llunyà Windows 98 o elsposteriors aportin els drivers necessaris per a totes les classes.


Pàg. 15

1.2.3. Entrant en matèria

El que veurem a continuació son els passos que el bus segueix per enumerar-sepassar informació i descripcions que ens ajudaran a entendre el que fem. De totesmaneres aquest apartat no intenta ésser un resum del que es pot trobar a lesespecificacions del USB sinó una explicació par a orientar a gent que sense volersaber-ho tot vol saber una mica més

La versió 1.0 del protocol USB suporta 2 velocitats de transmissió diferents. Enels apartats següents ens referim al protocol que nosaltres usarem, velocitat alta,que és el que permet transferir més informació i permet utilitzar tots els formatsd’informació disponibles (cosa que no passa amb el protocol de baixa velocitat).D’aquesta manera tota l’informació que donem fa referència a aquest protocol enconcret. S’ha de tenir en compte que existeixen diferencies rellevants amb el debaixa velocitat però que no destacarem.

El bus USB consisteix en un seguit de comunicacions bidireccionals entre uncontrolador principal i diversos perifèrics. Això es compleix mitjançant quatrecables, dos per a l’alimentació (Vcc amb una tensió de 5 Vols i massa) i dos líniesde dades D+ i D-. La transmissió que es realitza físicament és half-duplex (quesignifica que parla un després de l’altre) a partir d’una transmissió diferencial onl’element fonamental de comunicació son els paquets. Aquests s’envien codificatsen el format NRZI (nonreturn to zero inverted) de codificació en les línies detransmissió de dades. Per últim també considerem destacable a comentar que no hiha senyal de Clock per la qual cosa es considera un protocol asíncron. De totesmaneres son necessàries les transicions en les transmissions per a mantenir elsincronisme ja que cada perifèric incorpora el seu oscil·lador.

Per començar podem distingir les comunicacions ens dos grans grups laconfiguració i l’ús normal. Els dos tenen en comú moltes coses sense arribar aésser iguals. La primera té com a finalitat enumerar un dispositiu mentre que lasegona porta a terme les funcions per a les quals s’ha dissenyat el dispositiu.


Pàg. 16

1.2.4. Elements d’una transferència

Per poder entendre que és i com és una transferència, primer hem de conèixer unsconceptes nous fins al moment:

Endpoint (Destí): ja hem definit amb anterioritat aquest concepte però degut a laseva importància en recalquem la seva definició al igual que introduïm nousconceptes com la seva funcionalitat. Qualsevol comunicació va del o fins a unendpoint d’un perifèric, es pot considerar com un buffer amb capacitat per a uncert número de bytes. Aquesta informació ve o va al HC que es el punt de partidade totes les comunicacions. Cada perifèric pot tenir varis endpoints més unendpoint de control o Endpoint 0, encarregat de la configuració. Tots els següentsestan numerats del 1 a 15 (número màxim) i aquest número es la seva adreça.

Totes les comunicacions tenen com a destí una adreça d’endpoint i una indicacióde si és una transmissió de sortida o d’entrada d’informació (des de el punt devista del HC, sortida vol dir informació del HC cap al perifèric i entrada laconsiderarem del perifèric cap al HC). Apart de l’adreça del Endpoint, aquestacomunicació també conté l’adreça del dispositiu generada pel HC durant el procésd’enumeració.

Pipes (Canals): s’entén com a pipe un enllaç entre el software del controlador i unendpoint. Si tenim en compte que cada endpoint està orientat en una sola direcció,o be entrada o sortida de dades, es veu clarament que una pipe inclourà 2endpoints si aquest canal és bidireccional com és el cas del Pipe de control. No ésaixí en el nostre perifèric en tots els casos ja que el segon Pipe que usem,d’interrupció, com definirem més endavant sols usa un Endpoint i aquest és perdonar sortida a l’informació.

Un cop hem realitzat el projecte hem de destacar que és molt important per alcorrecte desenvolupament del mateix prestar molta atenció al fet d’enviar lesdades per la pipe i l’endpoint correcte, això significa no enviar dades per unendpoint destinat a rebre-les.

Aquest canal sols es pot establir si el perifèric esta correctament enumerat iexisteix l’ample de banda necessari per a la comunicació. Aquesta pipe es crea odestrueix segons es requereixi.


Pàg. 17

D’aquesta manera podem veure que qualsevol comunicació amb un perifèric técom a mínim un pipe o canal de comunicació obert per defecte amb endpoint 0més els pipes o canals que el propi usuari necessiti o cregui convenient obrir per alcorrecte funcionament de l’aplicació. D’aquesta manera cada pipe ens permet unintercanvi de comunicació el qual ens vindrà determinat per l’endpoint al qualapunti el canal en concret. També veurem que cada endpoint vindrà determinat perun sol tipus de transferència els quals veurem tot seguit. Al igual com un sol sentitde l’informació com ja hem dit.

Així doncs, en resum, per una pipe en concret passarà un tipus d’informació ambun format determinat i preestablert.


Pàg. 18

1.2.5. Tipus de transferències

Els següent que hem de definir son els tipus de transmissions de que els perifèricsdisposen per acomplir la seva finalitat. Aquestes son 4 i com hem vistanteriorment no tots ells estan disponibles per a cada classe, ni totes les classes elshan de fer servir tots. D’aquesta manera un tipus de transmissió crucial per unaclasse pot no estar present en una altra. Tots els tipus de transferència tenen unescaracterístiques diferents que determinaran la prioritat i quantitat d’informació quees transmetrà en el bus.

Control transfers (Transferències de control): totes les classes suporten aquesttipus de transferència i és entre d’altres coses usat en el procés d’enumeració.Inclou unes instruccions definides per les especificacions del USB a les quals hande respondre tots els perifèrics. Aquest tipus de transferència tenen prioritat en elperifèric. Així doncs un perifèric ha de prioritzar respondre a aquestestransferències de controls a enviar dades que pugui tenir emmagatzemades.

Bulk transfers (Bolcat d’informació): és una transmissió on no es fonamental lavelocitat en la transmissió però si ho és la gran quantitat d’informació i unacorrecta transmissió d’aquesta. Aquest sistema el fan servir perifèrics tipusimpressora, escaners...

Interrupt transfer (Interrupció): el fonamental en aquesta transmissió es obtenirl’atenció del HC de la manera més ràpida possible. De totes maneres dir que esuna transferència d’informació per mitjà d’una interrupció es podria classificar demolt generós ja que el que es fa amb anterioritat és designar una freqüència demostreig del perifèric per a mirar si aquest té informació preparada per a éssertransmesa, així doncs més aviat seria un polling.

Isochronous transfer (Transferència síncrona): el que premia aquest tipus detransferència es la velocitat en la transmissió ja que es requereix que en una certaquantitat de temps certa quantitat d’informació s’hagi transmès. Per aconseguiraquest objectiu es desactiva el sistema de detecció d’errors per no perdre temps enla correcció de l’informació rebuda amb errors. Un exemple seria uns altaveus onno és crucial rebre certa informació de forma correcta més que rebre certaquantitat d’informació.

En la taula següent veiem una comparativa de les característiques comparant entreels diferents tipus de transmissió:


Pàg. 19

Tipus detransferència

Control Bulk Interrupt Isochronous

Us normal ConfiguracióImpressores,escaners...

Teclat,ratolins

Àudio

Imprescindible Si No No No

Permès en baixavelocitat

Si No Si No

Transferènciamàxima permilisegon (bytes)

832 1216 64 1023

Transferènciamàxima en baixavelocitat

24 0,8

Ample de bandareservat (%)

10 Cap 90

Correcció d’errors Si Si Si No

Tipus d’informació Missatge Cadenes Cadenes Cadenes

Transferènciagarantida

No No No Si

Existeix tempsd’espera màxim

No No Si Si

Suportat per laclasse HID

Si No Si No

Es de destacar que el bus USB es guarda un 10% del temps d’execució perexecutar transferències de control i un 90% del temps per executar transferènciesd’interrupció i síncrones. Si després de servir a totes aquestes transferències tétemps restant el dedica a les transferències del tipus bulk.

De la mateixa manera també veiem que per seleccionar un driver per a un perifèricpertanyent a la classe HID limitem els tipus de transferència disponibles a Controli Interrupció. De totes maneres no és l’objectiu d’aquest projecte obtenir unsresultats que no es puguin aconseguir amb aquests dos tipus de transmissió.


Pàg. 20

1.2.6. Enumeració d’un dispositiu

Abans que un dispositiu es pugui comunicar amb cap aplicació, com hem vistanteriorment, s’ha d’enumerar correctament. Durant aquest procés el HCdetermina quin tipus de transaccions suporta i el número d’endpoints de quedisposa el dispositiu. Al mateix temps el HC adjudica una direcció al dispositiu.

Per a complir amb èxit aquest procés és necessari saber que el dispositiu disposad’unes taules amb informació que el perifèric envia al HC quant aquest l’hidemana. Aquesta informació està definida pel protocol USB el contingutd’aquestes taules determina unívocament les característiques físiquesconstructives i funcionals del perifèric. El conèixer aquestes taules, quantes són icom s’han de llegir es part fonamental per completar amb èxit el procésd’enumeració. Veurem les que utilitzarem en aquest projecte amb detall mésendavant i com les hem d’interpretar.

De moment ens centrarem en els estats pels quals passa el nostre perifèric mentreel configurem i detallarem els passos seguits pel HC i el sistema operatiu duranttot el procés.

Gràficament els estats pels quals passa el perifèric son representats en el gràficque veiem a continuació. Destacarem que per definició de l’estàndard, qualsevoldispositiu que, configurat o no, no detecti activitat en el bus durant un període de 3ms, aquest a de passar a la posició de suspens. Aquest es un estat especial que jahem comentat del qual el nostre perifèric només podrà recuperar-se quan recuperil’activitat o ho requereixi l’aplicació (un cas especial es quant el dispositiu es pot‘despertar’ a partir d’una senyal del perifèric, com ara rebre una trucada en untelèfon, de totes maneres aquest es un cas especial i sols volem deixar constànciade la seva existència).


Pàg. 21

També queda palès en el gràfic anterior les situacions que poden fer que undispositiu passi d’un estat a un altre.

Mentre que si enumerem i descrivim els passos seguits pel HC en tot el procésd’enumeració ens trobaríem amb una relació com la següent:

• El primer pas consisteix en connectar el dispositiu al port USB per la qualcosa aquest es troba en l’estat de connectat i pel fet de tenir el Hubconfigurat, el dispositiu passa directament a l’estat d’alimentat.

Connectat

Alimentat

Defecte

Direccionat

Configurat

Hub Configurat Hub Reset odesconfigurat

Reset Interrupcioalimentació

Direcció assignada Interrupcio alimentacióo Reset

Perifèric configurat Interrupcio alimentació o Reset oDesconfiguració

El dispositiu pot passar a l’estat de suspens en qualsevolmoment

Suspens

Suspens

Suspens

Suspens


Pàg. 22

• En aquest moment el Hub al qual s’hagi connectat el perifèric detecta lapresencia d’un perifèric i la seva velocitat de comunicació (alta velocitat12 Mbs o baixa velocitat 1.5 Mbs). Físicament el Hub disposa de dosresistències entre les dos línies de dades i massa mentre que el dispositiuen té una entre la línia d’alimentació i una de les línies de dades. Si aquestaes la D+ es tracta d’un dispositiu d’alta velocitat mentre que si aquesta estaconnectada a la línia de dades D- es tracta d’un dispositiu de baixavelocitat. El Hub es responsable de fer arribar la novetat de que unperifèric s’acaba de connectar al HC. En aquest moment el perifèric encarano està en condicions de rebre informació.

• A partir d’aquest moment el HC sap que alguna cosa passa en un delsHubs i envia la comanda Get_Port_Status per a determinar que ha passaten el port en concret, d’aquesta manera ara és el HC que ja té coneixementde l’annexió d’un nou perifèric.

• El que fa tot seguit el HC es ordenar al Hub que faci un reset al perifèricamb l’instrucció pròpia dels Hubs Set_Port_Feature exclusiva per un delsports en concret dels que disposi el Hub. D’aquesta manera altresperifèrics que puguin estar connectats en el mateix Hub no tenenconeixement del que passa a l’altre port.

• En finalitzar aquest reset el nostre perifèric es troba en l’estat queanomenen Defecte o Default State. En aquest moment el perifèric no potconsumir més de 100 mA, es l’únic del perifèrics que en aquest momentpot respondre a les instruccions que el HC envia a l’adreça per defecte quees la 0H i té establert un canal o pipe de comunicació amb l’Endpoint 0(anomenem Endpoint0 al conjunt format per l’Endpoint 0 In i l’Endpoint 0Out). A partir d’aquest moment el dispositiu està en condicions derespondre a les comandes de control.


Pàg. 23

• En algun d’aquests moments, abans o després del Reset, sempre depenentde cada Hub, es detecta la velocitat del perifèric però no és fins aquestmoment que el HC rep aquesta informació a través de la comandaGet_Port_Status.

• Tot seguit el HC es posa amb contacte amb el perifèric amb l’instrucció decontrol Get_Descriptor. Aquesta instrucció es dirigeix a l’adreça 0Endpoint 0. Sols un perifèric pot respondre ja que sols un perifèric es potenumerar cada cop (el HC es responsable que així sigui). El perifèricrespon amb una de les taules de que disposa en la memòria del dispositiuel qual en descriuen entre altres coses la capacitat màxima del Endpoint 0.

• El següent pas que pren el HC es assignar una adreça que serà única per alnostre perifèric mitjançant la comanda de control Set_Address. Aquestaadreça pot variar cada cop que el perifèric es connecta però un copconnectat i enumerat aquesta serà inalterable. Tenim en aquest punt elperifèric Direccionat.

• El HC a partir d’aquest moment envia un altre cop la comanda de controlGet_Descriptor a la nova adreça assignada al perifèric amb la finalitat decomprovar que aquest està on hauria d’estar i compara la respostaobtinguda amb l’obtinguda en l’apartat 7 per verificar que és el mateixdispositiu. Un cop verificat el correcte funcionament fins aquest punt essol·licita la resta d’informació dels descriptors o taules que emmagatzemael dispositiu. Això inclou informació sobre Endpoints, possiblesconfiguracions, consum, fabricant i també la classe a la que pertany eldispositiu.

• A partir de l’informació obtinguda dels descriptors del perifèric icomparant el fabricant, producte i classe a la que pertany aquest, el sistemacompara l’informació amb l’emmagatzemada en els arxius de sistema .INFcomentats anteriorment i selecciona en aquest moment el drivers a carregarper a les comunicacions. Finalitzant en aquest moment el procésd’enumeració i deixant el dispositiu llest per a ésser utilitzat per lesaplicacions que es puguin executar en l’ordenador.

Son finalment aquests drivers els que seleccionen alguna de les configuracionspossibles si es que més d’una està disponible basant-se en disponibilitat delsistema, elecció del propi usuari o altres. A partir d’aquest moment el procésfinalitza i ja tenim el perifèric configurat i llest per a funcionar i respondre a lespeticions per enviar i rebre informació que facin les aplicacions de l’usuari.


Pàg. 24

1.3. Objectius del projecte

Fins el moment hem descrit les possibilitats del bus USB i hem conegut elsavantatges i les limitacions que ens aporten els drivers que incorpora el sistemaoperatiu Windows 98 relacionats amb la classe Human Interface Device.

El següent pas és especificar els objectius que ens marquem. Un cop hàgimespecificat els objectius veurem els passos que hem de seguir tant a nivell delhardware com en el software per acomplir-los.

Finalment intentarem posar-ho tot a la pràctica per veure funcionar el nostreperifèric i comprovar com interactua amb la nostra aplicació que executem des del’ordenador.

Començant a descriure els objectius, el primer que hem de dir és que la finalitatprimera d’aquest projecte és interaccionar amb un perifèric que utilitzi el busUSB. Hem de poder rebre i enviar informació del nostre ordenador i establir unabase ferma des de la qual es pugui, més endavant, llençar projectes mésambiciosos sense tenir que començar de nou de zero. D’aquesta manera nopretenem comprovar tots els mètodes de transferència de dades existents ninecessitem crear un perifèric que suporti totes les possibilitats que ens permet elbus USB.

Ja ens hem marcat els objectius principals. Per a dur-ho a terme el que farem escrear un perifèric el qual disposarà de 4 leds i 4 interruptors. Els interruptorsestaran controlats per l’usuari i seran les entrades que el perifèric enviarà com adades a la nostra aplicació software. Un cop aquesta informació estigui en elnostre ordenador, l’usuari tindrà la possibilitat d’escollir una operació aritmètica.

Aquesta operació s’aplicarà a l’entrada rebuda del perifèric i a uns interruptorsvirtuals que estaran controlats de la pròpia aplicació software pel mateix usuari.Finalment, el resultat d’aquesta operació s’enviaran de l’aplicació software alperifèric que la donarà a conèixer a l’usuari a través dels leds mencionats alprincipi.


Pàg. 25

Tot aquest procés es el que intentem descriure en la gràfica següent.

L’utilitzat pràctica d’aquesta aplicació tot i semblar molt senzilla, amb unesmodificacions insignificants tant en el Hardware com en el llenguatgeensamblador (usat per a la programació del dispositiu esclau del interface USB enel nostre perifèric) es podria convertir en una eina molt potent.

Una possible aplicació seria, per exemple, en el control d’obertura de portes ofinestres d’una sala, informació que es podria enviar sense tenir que fer capoperació complicada a un ordenador el qual connectaríem al perifèric mitjançantel bus USB. A partir d’aquí es podria enviar informació d’hora d’obertura, hora enque es tanca ... tot amb el senzill fet de connectar el perifèric al ordenador sensetenir que aplicar cap configuració especial a cap de les dues parts ni tenir queresetejar-los amb els avantatges que el bus ens facilita.

Hem intentat que el conjunt inclogui lectures, escriptures, transmissions perinterrupció i control i veurem amb més detall com ho hem aconseguit i els passosque hem seguit per a que tot el conjunt funcioni.

El que farem tot seguit és establir uns passos per al disseny del conjunt. Aquestspassos són els que hem seguit per al disseny del nostre sistema i seran per tant, elsmateixos que seguirem per fer una explicació detallada dels components delprojecte, la seva utilitat i la seva configuració.


Pàg. 26

Per a crear qualsevol projecte relacionat amb l’estàndard USB i per a que aquestfuncioni, es recomanable fer una realització a partir de mòduls i no passar alsegüent pas fins que l’anterior funcioni correctament. D’aquesta manera els passosa seguir en aquest projecte o en qualsevol que estigui basat en comunicacions ambel bus USB seran els següents:

• Delimitar les necessitats del perifèric com son ara: velocitats necessàriesde transferència de l’aplicació (el qual ens definirà l’estàndard a seguir iels components a utilitzar), necessitats de drivers propis o possibilitatd’utilitzar els inclosos en el sistema operatiu, disponibilitat de circuitsintegrats, selecció d’un controlador i un interface USB ...

• Un cop tenim el primer pas clar i ja tinguem el material seleccionat, elsegüent pas és aconseguir que aquest conjunt sigui reconegut pel sistemaoperatiu (Windows 98 en el nostre cas). Per aquesta finalitat, (si espossible sempre es recomana utilitzar un interface hardware subministratpel propi fabricant del circuit integrat) hem d’escriure el programa enensamblador per al dispositiu esclau que permeti que es dugui a termecorrectament el procés d’enumeració explicat anteriorment. De la mateixamanera que hem d’escriure en ensamblador com el perifèric ha derespondre a qualsevol de les peticions que el HC pot enviar com acomanda de control. Normalment el propi fabricant del circuit imprès enfacilita documentació suficient.

• Quant el dispositiu es troba correctament enumerat pel HC, el següent passeria que el sistema operatiu tingués les eines suficients per a poderreconèixer-l’ho i instal·lar els drivers necessaris. Això implica el crear unarxiu INF que també hem comentat anteriorment. Els veurem amb mésdetall en apartats següents i concretament crearem el nostre propi.

• Quant ja tenim tot aquest material llest, el següent pas seria crear elhardware necessari per a que s’executi la nostra pròpia aplicació. Si esdona el cas, com ara és el nostre, en que no es disposa d’un equip demostra per a verificar el correcte funcionament de l’aplicació creada pernosaltres, el pas número 4 serà el segon a realitzar per seguidamentcontinuar amb al que hem apuntat en aquesta llista com a apartat número 2que inclou el procés d’enumeració.

• Quant ja tenim el perifèric connectat i físicament preparat per a interactuaramb el PC, continuaríem amb el desenvolupament del llenguatgeensamblador que permeti l’intercanvi d’informació per a que el hardwareexecuti la nostra aplicació.


Pàg. 27

• En aquest punt ja estem preparats per a crear el software necessari en elnostre ordenador i la nostra aplicació. Es en aquest moment i si horequereix l’aplicació quant hem de crear els drivers per comunicar-se ambel perifèric (com hem vist no es necessari en el nostre cas però val la penamencionar-ho).

• Finalment l’últim dels passos seria comprovar que el conjunt funcionacorrectament i prendre mesures de la fiabilitat del sistema.

Hem de tenir sempre present, com hem comentat anteriorment, que no podempassar al pas següent fins que no tinguem el pas anterior funcionant correctament.D’altra forma seria molt difícil determinar quina part del sistema es la que nofunciona correctament.

Hem fet anteriorment un esquema genèric dels passos a seguir. Encara, perpuntualitzar una mica més les coses podríem delimitar una mica més la feina.D’aquesta manera dividirem el treball en tres grans àrees: el punt 4, del punt 1 al5, i els punts 6 i 7. El primer grup el classificarem com a eminentment hardware,mentre que el segon serà el llenguatge ensamblador necessari en el perifèric per acontrolar la interacció amb l’interface i conseqüentment amb el bus i finalment eltercer equivaldria al software, es per tant necessari disposar del hardware percontinuar amb el projecte.


Pàg. 28

1.3.1. Construcció del nostre perifèric

Un cop hem arribat a aquest punt ja sabem que ha de fer el nostre perifèric per acomplir amb les especificacions del bus USB.

Sabem en concret com s’ha d’enumerar i quin és el procés per a fer-ho, lespreguntes que rebrà en forma de comandes de control també les respostes que hade retornar. De la mateixa manera sabem quins tipus de transmissions ha desuportar. Pel fet de formar part de la classe HID (Human Interface Device), comhem vist anteriorment, disposa dels modes de transmissió de control id’interrupció.

Constructivament hem escollit una configuració que facilitarà el desenvolupamentde l’aplicació ja que tenim per separat el microcontrolador i un controlador USB.El microcontrolador escollit serà de la sèrie 8051 mentre que el controlador USBserà el PDIUSBD12 de Philips.

Aquest es un del més estesos, disposa de 6 Endpoints més un de control, integra laresistència que el determina com a alta velocitat i es comunica amb elmicrocontrolador amb un bus paral·lel.

L’avantatge que ens facilita aquest interface respecte als altres es que respon aordres que passi el microcontrolador. D’aquesta manera disposa d’unacaracterística única al mercat que consisteix a connectar la resistència de Pull Upusada per a indicar al Hub de l’existència del nostre dispositiu per software. Aixòimplica que en el procés d’enumeració no es passa del apartat 1 al apartat 2 finsque el microcontrolador no està preparat.

També destaquem que pel fet d’usar un bus paral·lel entre l’interface i eldispositiu esclau es millora molt la capacitat de transmissió d’informació entreambdós arribant aquesta a ésser de 2 Mbytes/seg.

Altres característiques d’aquest estan disponibles en el full de característiquesinclòs en el CD-Rom adjunt a la documentació o a la pròpia web del fabricant.L’imatge següent ens mostra una connexió possible entre el controlador USB i elmicrocontrolador.


Pàg. 29

Veurem amb més detall les raons per les quals escollim la opció d’escollir uninterface separat del microcontrolador a altres opcions com podien ésser unmicrocontrolador amb interface USB incorporat, els avantatges i elsinconvenients, en els capítols següents.


Pàg. 30

1.4. Hardware

Al no disposar d’una placa evaluadora del codi de programació del dispositiuesclau, el primer pas seria la creació del Hardware que constituirà el nostreperifèric, aquest seria l’apartat 4 mencionat anteriorment.

Ho farem seguint els passos següents:

1.4.1. Elecció dels components

Ja hem comentat en apartats anteriors que el sistema operatiu emprat seràWindows 98 o posterior. Basarem el nostre perifèric amb un element HID,d’aquesta manera podem fer us dels avantatges que ens ofereix el sistemaoperatiu, entre d’altres l'utilització dels propis drivers creats per a ésser utilitzatsper aquesta classe.

Pel que fa referència a les especificacions del bus USB, ens basarem amb la versió1.1 de l’estàndard USB que és l’estàndard més estès, de totes maneres s’estàactualitzant aquest amb la nova versió 2.0, que amplia notablement l’ample debanda respecte al que farem servir nosaltres. De totes maneres aquesta última noes encara operativa.

Dintre la versió 1.1, existeixen dos velocitats com ja hem mencionat anteriormenten aquest treball. De la mateixa manera, pels motius vistos, i que ara repeteixo,nosaltres ens basarem amb els perifèrics d’alta velocitat. Tot i que les exigènciesque requereix el fet d’usar aquesta velocitat son una mica més exigents pel que faa traçat de pistes, aconseguim uns grans avantatges en velocitats i volum detransferència, que tot i no ésser crucials en aquest treball. Si poden ser-ho enfuturs treballs que puguin succeir a aquest. D’aquesta manera els canvis que estindrien que fer al projecte en referència als estàndard de la velocitat serienmínims.

Centrant-nos ara ja en el dispositiu físic, el que farem serà crear un sistemadistribuït i amb les funcions delimitades al màxim entre els dos mòduls en que esvol descompondre el circuit. Amb aquesta finalitat diferenciem el circuit integratque farà la feina de comunicacions amb el HC via el bus USB que podríem definircom a primer mòdul.


Pàg. 31

Pel que fa referència al segon mòdul el compon un microcontrolador que seràl’encarregat d’executar totes les feines per a les quals dissenyarem el perifèric igestionar tota la càrrega addicional que fa referència al control de lescomunicacions a través del primer mòdul mencionat anteriorment. Ja hem fetreferència a aquest mòdul amb anterioritat i és el que es podria anomenar com adispositiu esclau. Aquest dispositiu el programem amb llenguatge ensamblador iserà feina d’aquest entre altres coses, el que el nostre perifèric enviï l’informaciósol·licitada i en el format correcte al Host.

En concret, per al circuit integrat de comunicacions o mòdul primer, farem servirel PDIUSBD12 de Philips (l’anomenarem D12 d’ara endavant per facilitar lafluïdesa del llenguatge). Els motius per aquesta elecció, apart dels avantatges queaquest pugui tenir respecte als similars, es que té molta documentació que en fareferència i és un dels circuits integrats més usats en el mercat.

El diagrama de blocs referent a aquest element seria el següent:

Per part del microcontrolador, l’elecció ha estat també molt senzilla. Ens basaremamb la família de Intel 8X52. En concret per la seva extensió en el mercat, facilitatd’us i disponibilitat d’eines amb les quals hi podem treballar. També ens ajudaràque el propi fabricant del PDIUSBD12 ens facilita informació i models deprogramació per treballar amb el seu circuit integrat relacionat directament aaquesta família de microcontroladors.


Pàg. 32

Si observem el diagrama de blocs que té el 8052, que farem servir en el nostre cas,ens trobaríem amb esquema com el següent:

Es poden trobar a la documentació adjunta informació referent a ambdós circuitsintegrats com ja hem mencionat anteriorment.


Pàg. 33

1.4.1.1. Disseny del hardware

Pel que fa al disseny final del perifèric el podríem descriure gràficament de formamolt senzilla amb l’esquema següent:

D’aquesta manera podem veure com és el bus l’encarregat d’alimentar tots elscomponents, el circuit integrat de Philips rep l’informació del HC a través delcable USB i aquest passa l’informació al microcontrolador que actua sobre lamatriu de leds de la forma explicada anteriorment.

Al seu temps el microcontrolador controla les accions de l’usuari sobre elsinterruptors i envia l’informació al circuit integrat de Philips que al seu tempstransforma el missatge de forma que pugui ésser enviat al HC per al seutractament, també segons el vist anteriorment.

El disseny detallat del circuit imprès amb els seus components es pot veure mésendavant en la memòria de càlcul. De totes maneres n’introduïm un explicaciódetallada a continuació de forma que sigui més comprensible el disseny de laplaca i el perquè de les connexions.


Pàg. 34

1.4.1.2. Muntatge

Per a l’explicació genèrica del muntatge del circuit que formarà el perifèric ensbasarem en el gràfic següent al qual fan referència totes les explicacions:

En l’esquema anterior podem veure quin és el connexionat del que hem classificatcom a primer mòdul que està constituït bàsicament pel circuit integrat D12 i elHardware necessari per al correcte funcionament del mateix (oscil·lador,condensadors i resistències). També hi ha present la connexió del mòdulmencionat amb el 8052.

Per a la transferència d’informació entre els dos mòduls existeixen dos formes decomunicació possible respectant sempre el bus paral·lel, es pot fer o be per un busmultiplexat en el temps entre la direcció i les dades o be sense multiplexar com ésel cas del muntatge que figura en l’esquema anterior. La diferencia a nivell físic ésmolt poca i radica bàsicament en la forma d’enviar i rebre les dades.

En el nostre cas farem servir un sistema multiplexat. Basant-nos en això podemdefinir els accessos de lectura i escriptura al D12 com si es tractés d’un dispositiude memòria amb la peculiaritat de que té únicament dos direccions. La direcció‘1’ és l’usada per enviar les instruccions mentre que la ‘0’ és l’usada per rebre ienviar dades.


Pàg. 35

D’aquesta manera amb una simple instrucció MOVX amb un direccionamentindirecte accedirem del microcontrolador al circuit integrat D12. El fabricant peragilitar la transferència d’informació entre el HC i el perifèric ens permet escriureen aquest a partir del 8052 mentre que el D12 rep informació del HC i de lamateixa manera podem llegir-ne l’informació anterior amb el 8052 mentre el D12n’envia al HC. Per a fer-ho disposem de piles de memòria integrades en el propicomponent.

Un cop seleccionada una de les piles en podem llegir l’informació enmagatzemadasense preocupar-nos per que el D12 hagi d’enviar informació. La lectura de lespiles en aquest cas es seqüencial, hem de llegir tota l’informació anterior si el queens interessa és un byte concret.

També per a facilitar que a la llarga el bus intern de dades es pugui estendre ad’altres circuits integrats o memòries externes, hem connectat la patilla 11 (ChipSelect) del D12 a una patilla del port 2 del microcontrolador. D’aquesta formapodríem seleccionar, si la direcció on volem accedir està repetida ens els circuitsintegrats externs, a quin del circuits integrats volem accedir.

Per altra banda, el que hem anomenat com a segon mòdul, el componen el 8052,tot el hardware necessari per al seu correcte funcionament, (la qual cosa inclou unoscil·lador diferent al que fa servir el D12) i tot el hardware necessari per alfuncionament de la nostra aplicació.

El port ‘0’ del microcontrolador estarà destinat exclusivament a l’utilització com abus intern, el qual ja hem dit que estarà multiplexat en el temps, i la seva funcióestarà destinada a les comunicacions internes entre els components de la placa. Enaquest cas l’únic element que estarà connectat al bus serà el D12 però no s’exclouque en un futur aquest pugui ésser utilitzat per a accessos a RAMs externes oaltres dispositius.

Recordem que s’intenta fer el projecte amb la suficient flexibilitat per a permetreque futures ampliacions no tan sols sigui possible sinó que siguin el més senzillpossible.

El port ‘1’ del microcontrolador serà l’encarregat de gestionar els recursoshardware per interactuar amb l’usuari. Aquests recursos són els 4 leds i els 4interruptors.

Del port ‘2’ farem servir exclusivament un pin, com hem mencionat anteriormentper a seleccionar o deseleccionar el D12, però en el nostre cas aquest estaràseleccionat sempre, a partir del llenguatge ensamblador.


Pàg. 36

Finalment tenim el port ‘3’ del microcontrolador, d’aquest port en farem servir elspins com a funcions secundaries i les utilitzarem per a seleccionar lectura oescriptura del D12 entre d’altres. També s’ha de destacar que les interrupcions quegenerarà el D12 estan connectades directament al pin 13 del 8052, això significaque la Int1, s’activarà cada cop que s’hagi rebut informació a partir del bus USB.De la mateixa manera farem servir el pin 3.5, o T1, per a fer un Reset perhardware del controlador de les comunicacions o D12.


Pàg. 37

1.5. Programació del dispositiu esclau

Ja sabem fins al moment quina és la forma en que està dissenyat el sistema i comhem d’accedir a l’informació enviada pel HC de la mateixa manera que sabemquina és la forma que hem d’utilitzar per enviar-l’hi informació.

Conseqüentment el següent pas es escriure el llenguatge ensamblador que farà lafeina de gestionar l’informació a transmetre pel bus.

1.5.1. Procés d’enumeració

Però primerament, per a poder entrar de ple amb el procés d’enumeració i amb elllenguatge en ensamblador que hem d’escriure per a que tot funcionicorrectament, hem d’aprofundir una mica més en els coneixements del bus USB.D’aquesta manera hem de conèixer que són i com funcionen les taulesdescriptores que hem introduït anteriorment amb la descripció genèrica del busUSB però que encara no hem detallat.

També hem de tenir en compte que els propis creadors del bus USB tenen adisposició dels desarrolladors d’utilitats i perifèrics exemples i eines que facilitenla feina de desenvolupament d’aquestes taules. Aquestes eines es podenaconseguir sense cap tipus de compromís i les hem fetes servir per a crear algunad’aquestes taules que ara veurem. Ho detallarem quan sigui el moment.

1.5.1.1. Els descriptors

Els descriptors són taules o blocs d’informació que permeten al HC obtenir mésconeixements sobre el perifèric. Cada taula pot contenir informació sobre elperifèric com a un tot o sobre les parts en que es divideix.

Qualsevol perifèric ha d’ésser capaç d’emmagatzemar aquestes taules i passar-lesen la forma correcta, amb el format adequat quan el HC així o requereixi.

Els diferents descriptors existents van fent referència de forma successiva a partsmés petites en les que es pot dividir el funcionament del perifèric. D’aquestamanera si fem una llista dels diferents descriptors ens trobaríem amb la següentenumeració:


Pàg. 38

En primera instància existeix el device descriptor que conté informació generaldel perifèric i el número de configuracions possibles (concretant en el nostre cas,aquest sols disposa d’una configuració possible).

Continuant en l’escala, cada perifèric està format d’un o més configurationdescriptor, un per cada configuració possible (veurem com a conseqüència del pasanterior que es exclusiva en la nostre enumeració). En concret es guarda enaquesta taula informacions sobre consums i números d’interfaces.

El tercer en ordre d’aparició es l’interface descriptor que al igual que l’anteriorn’hi haurà tants com hem indicat en la taula precedent. En aquest cas guardainformació sobre el número d’endpoints que farem servir . Si el númerod’enpoints indicat es zero això significa que l’únic endpoint que utilitzarà elperifèric és el de control o endpoint 0. Entenem en aquest cas, interface com aconjunt d’endpoints utilitzats per un perifèric per a desenvolupar una funció.

La configuració de cada endpoint la podem trobar a la quarta taula que anomenemendpoint descriptor. Aquesta guarda informació sobre el tipus de transferència quesuporta (sempre un tipus concret sols) i el seu sentit. Tots els endpoints tenen elseu descriptor excepte l’endpoint 0 que ja es trobarà definit en els anteriors per laseva major importància.

El cinquè descriptor que mencionarem i farem servir és el string descriptor, elfarem servir en combinació amb qualsevol dels anteriors quant l’informació quevulguem guardar és una cadena de caràcters que emmagatzemi un nom, perexemple el nom del fabricant.

Un descriptor que nosaltres hem de fer servir però que no és comú a tots elsperifèrics és el HID descriptor que ens determinarà el nostre perifèric com ahuman interface device i emmagatzemarà el número de reports.

Finalment l’última taula que haurem de crear es la del report descriptor queinclourà el format i la finalitat de l’informació transmesa.

Tot i que hàgim donat els diferents tipus de descriptors per separat, quant aquestataula es posa en llenguatge ensamblador, s’escriu com si sols existís una taula ambtota l’informació seguida. D’aquesta manera queda una taula més o menys llargaen funció de la complexitat del perifèric.


Pàg. 39

Un esquema que pot incloure les diferents taules per a poder veure de qui depeneni com estan organitzades seria aproximat al següent:

Si ens centrem en el nostre cas en concret i omplim els diferents camps ambl’informació que ens serà necessària en el nostre cas tindríem les següents taulesdescriptores:


Pàg. 40

Device Descriptor

Camp Mida(bytes) Valor Descripció

bLength 1 18 Número total de bytes del descriptor

bDescriptor Type 1 1 Identificació per mitjà d’una constant del

descriptor

bcdUSB 2 110H Versió de l’estàndard a la qual estem subjectesv1.1

bDeviceClass 1 0 0 indica que especificarem al interface descriptor

la classe a la que pertany el nostre elementbDeviceSub Class 1 0 Per estar l’anterior a 0 aquest també o ha d’estar

bDeviceProtocol 1 0 Protocol específic per alguna classe concreta

bMaxPacket Size0 1 64 Capacitat màxima del Endpoint 0 1

idVendor 2 1111H Identificació del fabricant 2

idProduct 2 2222H Número del producte assignat pel fabricant

BcdDevice 2 1 Versió del producte en bcd assignat pel fabricant

iManufacturer 1 1 Índex a la cadena de caràcters número 1

iProduct 1 2 Índex a la cadena de caràcters número 2

iSerialNumber 1 0 No existeix cadena per a aquest camp

bNumConfigurations

1 1 Número de configuracions possibles del nostreelement

1 Les úniques capacitats possibles son: 8, 16, 32 o 642 Valor assignat per USB després de pagar una taxa. Al no estar el nostre producte destinat al mercat,ens el podem inventar.


Pàg. 41

Configuration Descriptor

CampMida(bytes)

Valor Descripció

BLength 1 9 Número total de bytes del descriptor

bDescriptorType 1 2 Identificació per mitjà d’una constant del

descriptorWTotalLength 2 Suma total de totes les taules que estan a

continuacióBNumInterfaces 1 1 Número de les interfaces que suporta aquesta

configuracióBconfigurationValue 1 1 Identificatiu per aquesta configuració

IConfiguration 1 3 Índex a la cadena de caràcters número 3

BmAttributes 1 80H Bitmap que ens determina que l’element està

alimentat pel Bus i no accepta Remote Wakeup

MaxPower 1 50 Consum total quant està en us expressat en unitatsde 2mA


Pàg. 42

Interface Descriptor

CampMida(bytes)

Valor Descripció

Blength 1 9 Número total de bytes del descriptor


descriptorbInterfaceNumber 1 1 Número d’interface per ordre d’aparició

bAlternateSetting 1 0 Número de interfaces que poden substituir aquest

bNumEndpoints 1 1 Número d’endpoints que fa servir aquest interface,

excepte l’endpoint 0bInterfaceClass 1 3 Classe a la que pertany l’interface3

bInterfaceSub Class 1 0 Subclasses en les que pot estar englobat

bInterfaceProtocol 1 0 Protocol específic de cada classe

iInterface 1 4 Índex a la cadena de caràcters número 4

3 El valor està definit per a cada classe, els HID tenen en aquest camp el valor de 3


Pàg. 43

Endpoint Descriptor

CampMida(bytes)

Valor Descripció



descriptorbEndpointAddress 1 81H Adreça i direcció de les comunicacions

bmAttributes 1 3H Definim el tipus de transferència com ainterrupció

wMaxPacketSize 2 6400H Capacitat màxima del buffer per a enviar o

rebre

bInterval 1 100 Temps entre els pollings (0,1s)


Pàg. 44

HID Descriptor

CampMida(bytes)

Valor Descripció


bDescriptorType 1 21H Identificació per mitjà d’una constant del

descriptor

bcdHID 2 110H Versió de l’estàndard a la qual estem subjectesv1.1

bCountryCode 1 25 Identificació del país (25 espanya, 0 global)

bNumDescriptors 1 1 Identificatiu per aquesta configuració

bDescriptorType 1 22H Tipus de Report Descriptor (22H per HID)

WDescriptor Length 2 Longitud total dels Report Descriptors


Pàg. 45

Per crear el Report Descriptor hem fet us d’una eina específica, HID ReportCreator (que es pot aconseguir de forma freeware del fòrum del USB). Elsreports son taules complexes i complicades d’informació el qual no és tan senzillde crear com les taules vistes fins al moment.

El nostre Report Descriptor és el següent:

Usage Page (Vendor Specific), ;Utilitzem informació definida per nosaltresUsage (Vendor Specific),Collection (Application), ;Comença l’enumeració

Usage Minimum,Usage Maximum, ;Els camps poden tenir qualsevol valor entreLogical Minimum (0), ;aquest paràmetresLogical Maximum (255),Report Count (8), ;8 bits equivalen a un byteReport Size (1), ;Contem els bytesInput (Data, Variable, Absolute), ;Afegeix camps a l’informació d’entradaUsage Minimum,Usage Maximum, ;Els camps poden tenir qualsevol valorOutput (Data, Variable, Absolute), ;Els reports d’entrada i sortida són iguals

End Collection,End Collection,


Pàg. 46

Finalment comentar que els índex a cadenes apuntaran a cadenes amb el format iel contingut que ve representat a continuació. També recordarem que totes lescadenes que utilitza l’estàndard USB estan definides en UNICODE per aquestmotiu abans de cada caràcter ASCI s’hi afegeix un ‘0’:

String Descriptor

CampMida(bytes)

Valor Descripció

bLength 1 Número total de bytes del descriptor

bDescriptorType 1 03H Identificació per mitjà d’una constant deldescriptor

bString N Cadena Cadena codificada en UNICODE

Cadena 1 (iManufacturer): ’Produit a la URV’Cadena 2 (iProduct): ’Disseny de JSP’Cadena 3 (iConfiguration): ‘Periferic I/O’Cadena 4 (iInterface): ‘PFC’

Fins aquí les taules comentades. Es poden veure escrites en llenguatgeensamblador amb els mateixos continguts i llestes per a ésser usades integrades enel programa, en el llistat del mateix que tenim detallat en la memòria de càlcul.


Pàg. 47

1.5.2. Respostes a comandes de control

Ja hem comentat anteriorment que qualsevol dispositiu ha de respondre a lespeticions que arribin del HC i siguin del tipus de transferència de control. Tambéhem comentat que aquestes sempre tindran un format determinat i per tant hem deprogramar al nostre dispositiu les respostes adequades que ha de transmetre.

En l’esquema següent veiem com es porten a terme les transmissionsd’informació. El D12 detecta que un paquet acaba d’arribar a la direcció que hatingut assignada pel Host, en detecta l’endpoint de destí i al arribar el següentpaquet amb les dades, al detectar que no hi ha hagut errors de transmissió, passal’informació al dispositiu esclau (8052) en el nostre cas. Aquest executa lesinstruccions pertinents i retorna l’informació necessària

Degut a la relativa simplicitat del nostre dispositiu, aquest no ha d’executar capfunció ni retornar cap informació en algunes de les peticions estàndard queexisteixen. D’altra manera la resposta a peticions desconegudes en el nostredispositiu serà retornar un error mitjançant una situació de Stall.

Finalment hem de tenir present que depenent del paràmetre que es passi en lapetició de control s’haurà de contestar amb informació que faci referènciaexclusivament al component, a l’interface o a l’endpoint.


Pàg. 48

Per a entendre una mica més les comandes de control hem d’aprofundir una micamés en l’estàndard USB. Hem definit que hi ha quatre tipus de transmissióinterrupt, bulk, isochronous i control. De totes aquestes l’única que té un formatpredefinit és la de control. Per tant hem de conèixer aquest format i el seucontingut.

Les transferències de control estan formades per tres fases, la fase de Setup, unaopcional de transferència de dades i la tercera, també obligatòria d’estatus. En laprimera fase el HC envia 8 bytes al perifèric que estan definits de la següentmanera:

1er byte Request Type (bmRequestType) Direccionable bit a bit2on byte Request (bRequest) Veure taula següent3er i 4rt byte Data Value (wValue) Dos bytes d’informació5er i 6er Índex Value (wIndex) Punter a una estructura7er i 8er Length (Data) Llargada info. enviada

En el nostre cas i degut a la simplicitat del programa farem servir únicament elsdos primers bytes rebuts en la majoria dels casos però en algun cas concret serànecessari accedir al contingut de Data Value de forma molt puntual.


Pàg. 49

Indiquem tot seguit la codificació del primer byte (Request Type):

Bit 7 0 = es requereix una transferència d’informació del HC al device.(direcció) 1 = es requereix una transferència d’informació del device al HC.Bit 6-5 00 = Standard(interpretació) 01 = Class

10 = Vendor11 = Reserved

Bit 4-0 0000 = Device(destí) 0001 = Interface

0010 = Endpoint0011 = Altres

Qualsevol altre valor està reservat

Vegem a continuació quina informació ens codifica el camp Request i quesol·liciten que el nostre dispositiu faci:

Tipus Petició AccióGeneral Get_Status Es torna l’estat en que es troba l’element concret.

General Clear_Feature Desactiva una característica concreta de l’element. *

General Set_Feature Activa una característica concreta de l’element. *

General Set_Address Estableix l’adreça per a la comunicació en futures transaccions.

General Get_Descriptor Sol·licita una taula descriptora concreta.

General Set_Descriptor Afegeix o actualitza una taula descriptora. *

General Get_Configuration Sol·licita el valor de l’actual configuració.

General Set_Configuration Demana que el dispositiu treballi segons una configuració concreta. *

General Get_Interface Sol·licita el valor de l’actual interface.

General Set_Interface Demana que el dispositiu treballi segons un interface concret. *

General Sync_Frame Envia una senyal de sincronisme als endpoints. *

General Altres Error mitjançant un Stall

Específica Get_Report Es retorna el report descriptor.

Específica Set_Idle Estableix un temps d’espera per a un canal de comunicacions.

Específica Get_Idle Sol·licita el temps d’espera en un canal de comunicacions.

Específica Get_Protocol Mira quin protocol té el perifèric actiu. *

Específica Set_Report El dispositiu rep el report descriptor.

Específica Set_Protocol Estableix un protocol com a actiu. *

Específica Altres Error mitjançant un Stall

Definirem el tipus com a tipus general utilitzada per qualsevol classe o específica usada enconcret pels HID.Indiquem que el nostre dispositiu no ha de prendre cap acció concreta.


Pàg. 50

La segona fase es opcional i en ella s’envia l’informació sol·licitada, si el volumd’informació a enviar o rebre és massa gran per a ésser enviat en un cicle, aquestaes pot enviar en varis cicles de lectura o escriptura. La gestió del volumd’informació a enviar o rebre la realitza el D12, raó per la qual sols hem d’escriurel’informació i la resta la farà el circuit integrat.

Finalment la tercera fase, que torna a ésser obligatòria consisteix en enviar unpaquet d’acceptació per verificar no tan sols que s’ha efectuat correctamentl’última transmissió de dades sinó que s’ha executat de forma correcta tota latransacció. En cas que hàgim rebut l’informació indiquem al HC si aquesta haestat rebuda correctament i hem dut a terme la comanda de control correctament osi no ha estat així. En el cas que hagi estat el nostre perifèric el que ha enviatl’informació, serà el HC qui ens indicarà de la mateixa manera si ha rebut iacceptat l’informació.

Gràficament l’esquema que seguiria una transferència de control es podriarepresentar de la forma següent:

Entrarem una mica més en detall a les comandes de control generals pel bus USB iles específiques de la classe HID. Tot i estar clarament explicades en lesespecificacions, en destaquem seguidament l’informació més important i si espossible hi incorporem el fluxograma de la subrutina que en controlarà el servei.


Pàg. 51

1.5.2.1. Set_Address

Request: 05h.

Finalitat: El HC especifica una adreça per a ésser utilitzada en futurescomunicacions amb el dispositiu.

DataValue: La nova adreça a utilitzar. Son valors possibles de 1 a 127.

IndexValue: 0

Length: 0

Hem de comentar referent a aquesta petició el següent, el HC ens adjudica unanova adreça, i l’usarem a partir d’aquest moment per a qualsevol comunicacióamb el HC. Això implica modificar l’adreça abans de respondre amb elHandShake al HC. També aprofitarem el canvi de l’adreça per habilitar el bit 7 enel registre del D12 per tal d’habilitar la pròpia funció. Un cop adjudicada la novaadreça en el D12 acabem, en el nostre cas, habilitant l’ús dels endpoints genèrics(que no son exclusivament de control) i de configurar els registres per a que no hihagi transmissions de dades usant el DMA.

El fluxograma de servei d’aquesta subrutina és el següent:


Pàg. 52

1.5.2.2. Get_Descriptor

Request: 06h.

Finalitat: El HC requereix informació sobre una taula descriptora concreta.

DataValue: Byte alt, tipus del descriptor. Byte baix, Valor del descriptor.

IndexValue: Diferent de zero per indicar una string.

Length: Llargada de l’informació sol·licitada.

Aquesta és sense cap mena de dubtes la funció més complexa amb que ens podemtrobar en el procés d’enumeració. Tenim dos coses a observar en aquesta petició.

El primer és la llargada d’informació a enviar com a resposta. En aquest cas el HCens sol·licita certa quantitat d’informació o número màxim de bytes que ha deformar la nostra resposta. Nosaltres no hem de superar mai aquesta llargada,d’aquesta forma si el Descriptor sol·licitat és més llarg que el número de bytessol·licitats, enviarem exclusivament fins a complir amb aquest. Si es donés el casque en té menys que els sol·licitats, enviaríem exclusivament aquesta quantitat. ElHC detectarà en aquest moment que ja hem acabat d’enviar informació.

El segon punt a observar correspon a l’informació concreta que hem d’enviar. Hiha tres casos possibles en aquesta petició. Si l’informació sol·licitada esexclusivament el Device Descriptor enviarem aquest. Si ens demanen elConfiguration Descriptor enviarem la resta dels descriptors sense incloure elsStrings. Finalment ens pot sol·licitar alguna de les diferents String que tinguem.La nostra rutina haurà de ser prou hàbil per a diferenciar l’informació i la quantitata enviar.

El que fem d’aquesta manera en la nostra aplicació es observar tots els possiblesdetalls. Mirem quina de les taules descriptores ens sol·licita, si la del Device o laConfiguration. Hem de destacar que si la sol·licitada es la Configuration enviemtotes les que tenim excloent la de Device, els Strings i el Report Descriptor i lesenviem segons l’ordre establert per la “Device Class Definition for HID” que és elsegüent: “Configuration Descriptor”, tots els “Interface Descriptor”, “HIC classDescriptor” i tots els “EndPoint Descriptor”.


Pàg. 53

D’aquesta manera ens quedaria un fluxograma molt semblant al següent esquemaper a la mencionada petició del HC:

Get Descriptor

DeviceDescriptor

Config.Descriptor

StringDescriptor

No

SiAdaptar llargada i

enviar

No


enviar

No


enviar

Existeixsegüent

Si

STALLEndPoint

End Get Descriptor


Pàg. 54

1.5.2.3. Set_Descriptor

Request: 07h.

Finalitat: El HC actualitza els descriptors o n’envia de nous.

DataValue: Byte alt, tipus del descriptor. Byte baix, Valor del descriptor.

IndexValue: Diferent de zero per indicar una string.

Length: Llargada de l’informació que enviarà.

Aquesta comanda està pensada de forma que el nostre perifèric pugui modificarels Descriptors que té incorporats o per a que en pugui incorporar de nous. En elnostre perifèric no acceptem aquesta comanda i com a conseqüència ho indiquemal HC fent un STALL del EndPoint.


Pàg. 55

1.5.2.4. Set_Configuration

Request: 09h.

Finalitat: El HC indica al perifèric la configuració que haurà d’utilitzar.

DataValue: Byte baix, indica el valor de la configuració que haurem de ferservir en cas que siguin varies.

IndexValue: 0

Length: 0

El servei a aquesta comanda serà el que ens determinarà que el nostre perifèriccanvia de l’estat de Direccionat a estar Configurat. En el nostre cas sols tenim unaconfiguració possible, si no fos així el HC ens indicaria de la mateixa maneraquina és la configuració que hauria d’adoptar el nostre dispositiu.


Pàg. 56

1.5.2.5. Get_Configuration

Request: 08h.

Finalitat: El HC sol·licita el valor de la configuració actual.

DataValue: 0

IndexValue: 0

Length: 1

Si el dispositiu no està configurat retornarem un 0. Retornaríem el valor de 1 siaquest està configurat. En el supòsit que el dispositiu tingués variesconfiguracions possibles, retornaríem el valor de la configuració establerta.


Pàg. 57

1.5.2.6. Set_Interface

Request: 0Bh.

Finalitat: Si la configuració suporta varies Interfaces, el HC determina quinahem d’usar.

DataValue: Configuració alternativa

IndexValue: Interface

Length: 0

En el nostre cas sols en tenim una de possible. Aquesta comanda, està pensada deforma que el nostre perifèric pugui modificar l’elecció d’un Interface diferent alconfigurat en aquell moment sempre que n’hi hagi algun altre per a elegir, cosaque no passa en el nostre perifèric. En el nostre perifèric no acceptem aquestacomanda i com a conseqüència ho indiquem al HC fent un STALL del EndPoint.


Pàg. 58

1.5.2.7. Get_Interface

Request: 0Ah.

Finalitat: Si la configuració suporta varies Interfaces, el HC sol·licita quinaestem usant.

DataValue: 0

IndexValue: Interface.

Length: Número de l’Interface actual.

En el nostre perifèric no acceptem aquesta comanda i com a conseqüència hoindiquem al HC fent un STALL del EndPoint.


Pàg. 59

1.5.2.8. Set_Feature

Request: 03h.

Finalitat: El HC sol·licita que hem d’habilitar alguna de les característiquespossibles en el dispositiu. (DEVICE_REMOTE_WAKEUP oENDPOINT_HALT)

DataValue: Característica a habilitar.

IndexValue: 0 per a un Device, el numero de l’interface o l’endpointseleccionats.

Length: 0

En el nostre dispositiu no tenim cap funció que es pugui habilitar ni en l’EndPointni en l’Interface. D’aquesta manera no acceptem aquesta comanda i com aconseqüència ho indiquem al HC fent un STALL del EndPoint. El fluxogramaseria el següent:


Pàg. 60

1.5.2.9. Clear_Feature

Request: 01h.

Finalitat: El HC sol·licita que hem de deshabitar alguna de lescaracterístiques possibles en el dispositiu.

DataValue: Característica a deshabitar.


Length: 0

En el nostre dispositiu no tenim cap funció que es pugui deshabilitar ni enl’EndPoint ni en l’Interface. D’aquesta manera no acceptem aquesta comanda icom a conseqüència ho indiquem al HC fent un STALL del EndPoint. Elfluxograma seria el següent:


Pàg. 61

1.5.2.10. Get_Status

Request: 00h.

Finalitat: El HC ens sol·licita quins son els estats de les característiquesconcretes del Device, Interface o l’Endpoint

DataValue: 0


Length: 2

Retornem l’estat de les característiques de l’element concret. Les respostesinclouen dos bytes en totes els casos els valors dels quals estan definits bit a bit entots ells. En el nostre cas, al no disposar de la funció Remote Wakeup, ésser undispositiu alimentat pel propi bus i no acceptar transferències d’informació Bulk oIsochronous, respondrem en els tres casos enviant 2 bytes en blanc.


Pàg. 62

1.5.2.11. Synch_Frame

Request: 0Ch.

Finalitat: El dispositiu estableix i informa sobre la finestra de sincronització.

DataValue: 0

IndexValue: Endpoint concret.

Length: 2

Es retorna el número de la finestra de sincronització. De totes maneres, aquestacomanda està pensada de forma que el nostre perifèric pugui modificar elsDescriptors que té incorporats o per a que en pugui incorporar de nous. En elnostre perifèric no acceptem aquesta comanda i com a conseqüència ho indiquemal HC fent un STALL del EndPoint.


Pàg. 63

1.5.2.12. Get_Report (petició específica de la classe HID)

Request: 01h.

Finalitat: Habilita el HC a rebre informació a través de les transferències decontrol.

DataValue: Byte alt, conté el tipus (1 input, 2 output, 3 feature). Byte baix,Report ID

IndexValue: Número de l’interface que suporta aquest Report

Length: Llargada del report.

Comanda usada puntualment quant el HC necessita una informació concreta delperifèric. No és la comanda que hem de fer servir per a fer un polling deldispositiu. Normalment es fa servir de forma puntual quant s’està configurant eldispositiu per a saber el valor d’alguna de les variables. La resposta doncs, en elnostre cas, al no tenir que donar cap valor en concret en la inicialització, seràrespondre amb un valor qualsevol de forma arbitraria.


Pàg. 64

1.5.2.13. Set_Report (petició específica de la classe HID)

Request: 09h.

Finalitat: Habilita el dispositiu a rebre informació a través de lestransferències de control.

DataValue: Byte alt, conté el tipus (1 input, 2 output, 3 feature). Byte baix,Report ID

IndexValue: Número de l’interface que suporta aquest Report.

Length: Llargada del report.

En el nostre cas és l’única forma en que el HC pot enviar informació al nostredispositiu. El procés per a la recepció de l’informació és una mica més complexdel que podria semblar en un primer moment, però no és extremadament complex.

La diferència que caracteritza aquesta comanda de les altres és que l’informacióconcreta que hem de rebre, la rebem en la segona fase de les fases que componentuna transferència de control. Això implica que un cop hem detectat la comanda isabem ja que el pròxim byte a rebre serà la informació concreta que envial’aplicació que s’executa en el HC, haurem d’esperar a rebre una altra transmissiópel canal de control que a diferència de les altres no serà de SETUP sinó de dades.

Un cop rebuda ja podrem mostrar la nova informació pels Leds del nostreperifèric.


Pàg. 65

1.5.2.14. Set_Idle (petició específica de la classe HID)

Request: 0Ah.

Finalitat: El HC estableix una freqüència en la temporització de rebreinformació.

DataValue: Byte alt, temps màxim. Byte baix, Report ID al que fa referència.

IndexValue: Número de l’interface que suporta aquest Report.

Length: 0

Comanda que s’utilitza per a poder limitar el període de demanda d’informacióper a poder ocupar menys ample de banda en les comunicacions. En el nostreperifèric no acceptem aquesta comanda i com a conseqüència ho indiquem al HCfent un STALL del EndPoint.


Pàg. 66

1.5.2.15. Get_Idle (petició específica de la classe HID)

Request: 02h.

Finalitat: El HC llegeix el valor emmagatzemat.

DataValue: Byte alt, 0. Byte baix, Report ID


Length: 1

Retornem al HC el valor del període de mostreig en la fase de transferència dedades en unitats de 4 milisegon. En el nostre perifèric no acceptem aquestacomanda i com a conseqüència ho indiquem al HC fent un STALL del EndPoint.


Pàg. 67

1.5.2.16. Get_Protocol (petició específica de la classe HID)

Request: 0Ah.

Finalitat: l HC obté informació referent a si els protocols de Boot o Reportestan actius.

DataValue: 0


Length: 1

Retornem al HC el valor 0 si tenim actiu el protocol del Boot o 1 si és el deReport. En el nostre perifèric no acceptem aquesta comanda i com a conseqüènciaho indiquem al HC fent un STALL del EndPoint.


Pàg. 68

1.5.2.17. Set_Protocol (petició específica de la classe HID)

Request: 0Bh.

Finalitat: El HC Especifica quin protocol hem d’usar.

DataValue: 0


Length: 1

El HC ens envia el valor 0 si hem d’activar el protocol del Boot o 1 si hemd’activar el de Report. En el nostre perifèric no acceptem aquesta comanda i coma conseqüència ho indiquem al HC fent un STALL del EndPoint.


Pàg. 69

1.5.3. Punter de comanda

Per a fer un control eficient en la rutina que servirà l’interrupció generada per larecepció d’un paquet de Setup, hem creat una taula de comandes el punter de laqual es fa seguint el següent esquema:

Aquí veiem els bits que han de ser 0, si algun d’aquests bits no ho fos, aixòimplicaria que l’informació rebuda no es valida i per tant l’ignoraríem.

Un cop creat el ‘Command Índex’ ja sabem amb quines peticions ens trobarem iper tant ja podem crear el codi que faci que el microcontrolador respongui a lespeticions del HC en quant a comandes de control.

La definició concreta del contingut dels bytes en cada comanda de control i el seusignificat es troben detallats de forma clarificadora en estàndard USB capítol 9 raóper la qual no repetirem aquí l’informació.


Pàg. 70

1.5.4. Programació del dispositiu esclau

El que correspon al següent pas es crear el programa en ensamblador per almicrocontrolador de forma que ja tinguem les eines necessàries per a fer queaquest respongui als transfer controls, que el HC pugui enviar.

Per a fer-ho ens hem d’endinsar una mica més en el PDIUSBD12 (o D12) per aveure com és aquest, com funciona, com es configura i finalment quinainformació envia al microcontrolador al rebre informació pel canal decomunicació de control o qualsevol altre.

Primerament hem de destacar que el D12, un cop configurat correctament,funciona enviant una interrupció al microcontrolador. Es feina delmicrocontrolador, llegint uns registres d’estat interns al D12, determinar quin es elmotiu pel qual s’ha activat l’interrupció i executar la funció que sigui necessàriaper a processar l’informació rebuda de forma adequada, així com retornarl’informació al D12 per a que l’enviï al HC com a resposta.

Per aquest motiu podem dividir el programa principal en tres apartats bendiferenciats. El primer que serà preparar totes les inicialitzacions necessàries per aque el sistema funcioni correctament, junt amb el programa principal. El programaprincipal destaca per la seva simplicitat ja que la majoria de les funcions que esrealitzen es desencadenen a partir interrupcions.

El segon estarà format per totes les taules que són necessàries per al procésd’enumeració. El contingut d’aquestes ja els hem descrit anteriorment per la qualcosa no ho repetirem en aquest apartat.

Finalment, podem definir el tercer apartat com el que porta el gruix de les accionsa realitzar. Aquest servirà per a respondre a les interrupcions generades pel D12 iexecutar les subrutines per a que les comunicacions funcionin correctament.


Pàg. 71

El fluxograma equivalent al primer apartat que acabem de descriure seria elsegüent:

Un organigrama de la rutina que servirà l’interrupció generada pel D12 podriaésser molt semblant a la següent (destacarem que es bastant seqüencial i laprincipal cosa a fer es actuar segons el contingut dels registres del D12).D’aquesta forma veiem que el que fa aquest apartat és indicar quines subrutiness’haurà d’executar. D’aquesta manera fem que la ISR interrupt service rutine espugui executar amb la major celeritat possible:

Programa Principal

Inicialitzar elmicrocontrolador

No fer res

Inicialitzar elPDIUSBD12

Inicialitzar lesvariables


Pàg. 72


Pàg. 73

El primer apartat del llenguatge en codi ensamblador ja hem comentat que eramolt senzill degut a que les tasques es realitzen, en el nostre projecte, com aconseqüència del servei a una interrupció. El contingut del segon apartat, ja hemdit que eren les taules descriptores específiques per al nostre perifèric i que hemcomentat amb anterioritat. Finalment tenim el servei a la interrupció generada pelD12 l’organigrama de la qual acabem de veure que comentem de forma general acontinuació.

El primer que cal comentar es que configurem el D12 de forma que sols generiuna interrupció si el paquet que ha rebut no té cap error. D’aquesta manera ensevitem tractar amb errors que es pugin generar en el propi bus USB. Seria el propiD12 l’encarregat, en aquest cas, que el HC re-envies l’informació.

Seguidament, el D12 genera una interrupció de forma que ja sabem que hem rebutun paquet correcte i el que hem de fer es detectar la raó per la qual s’ha generatl’interrupció, el contingut del registre DATA FLOW COMMAND intern al D12 ensaportarà tota l’informació necessària per a la primera classificació.

A partir de la lectura del registre anterior podem saber si l’interrupció ens vegenerada per un bus reset, bus suspend, SOF (Start Of Frame) o be quin endpointdels sis possibles ens genera l’interrupció.

Nosaltres en el nostre cas servirem interrupcions que estiguin generades pel busreset, suspend, SOF o be els endpoints 0 out, 0 in o 1 in. Per l’endpoint 0 out(sortida d’informació del HC cap al perifèric) ens pot arribar qualsevol de lescomandes de control. Hem vist ja amb anterioritat quines són aquestes comandes icom les servim al igual que els organigrames de les funcions que hem creat.

Començarem estudiant els fluxogrames del programa i la forma que tenim per arespondre a cadascuna de les causes de les interrupcions possibles. La primera quetractem de les mencionades anteriorment es la generada per SOF (recordem queun Start Of Frame es dona cada 1 milisegon i el fa servir el HC com a finestres enque es desenvolupen les comunicacions amb tots els dispositius).

Aquesta interrupció podríem no rebre-la si així ho configurem al inicialitzar elD12, però creem el programa de forma que a cada SOF observem l’estat delsinterruptors per a veure si l’usuari ha realitzat cap modificació en el valor. Si elprograma està correctament configurat i l’usuari ha variat el valor delsinterruptors, el programa enviarà el nou valor al HC, i aquest a l’aplicació.


Pàg. 74

La rutina que servirà al SOF serà la responsable de fer una lectura de l’estat delsinterruptors i comparar-lo amb l’estat emmagatzemat en la memòria de lesposicions anteriors. En el supòsit que hi hagi hagut alguna modificació en l’estatd’aquests, enviarem la nova informació mitjançant una transferència del tipusd’interrupció al HC per que aquest o notifiqui a l’aplicació.

El fluxograma que en correspon és el següent:

SOF

Configurat

Si

No

Variació

Obtenir valorinterruptors

Si

No

Enviar nou valor alHC

Fi SOF


Pàg. 75

Les dues subrutines que tractem a continuació en el nostre programa corresponenal Bus Reset i Suspend. Aquestes operacions afectarien al nostre perifèric siféssim un control exhaustiu del consum del mateix però no és la nostra finalitatconstruir un perifèric que compleixi amb les estrictes normes que imposa el BusUSB per a l’estat de Suspend en el punt que fa referència al consum màxim enaquest estat, cosa que imposa que es consumeixi un màxim de 50 nA. Si tenim encompte el consum del microcontrolador en funcionament, veurem que aquest ja éssuperior cosa que fa impossible que en complíssim els requisits tenint aquest enfuncionament..

Pel que fa referència al Reset, l’única acció que pren el nostre programa es la demodificar l’estat de forma que el perifèric passi a l’estat de no configurat al’espera que es torni a configurar més endavant.

Seguidament ens trobaríem amb el tractament de les subrutines per als endpoints 1Out, 2 Out i 2 In. De la forma que tenim configurat el nostre perifèric el HC hauriade detectar de la mateixa manera que ho fa el microcontrolador que no accepteminformació ni n’enviem per aquest canals. D’aquesta forma no hauria d’éssernecessari programar les respostes a aquestes interrupcions. Així doncs en el nostrecodi fem el mínim possible, en aquest cas, llegir el byte Read Last TransactionStatus, però sense manipular-ne l’informació ni contemplant el contingut delmateix. La raó per la qual executem aquesta comanda és que ens assegurem que esfaci un reset del bit corresponent en el registre d’interrupció del D12.

Qualsevol informació que ens arribi a través d’aquests endpoints que hemcomentat fins al moment no serà vàlida en el nostre programa. Tot i que pot ser-hoen qualsevol ampliació futura que es vulgui fer a aquest programa.

Seguidament, i abans de tractar l’endpoint de control ens trobem amb la rutina queserveix l’interrupció generada per l’endpoint 1 In (recepció d’informació per partdel HC). És el que nosaltres farem servir com a endpoint amb mode detransferència de l’informació per interrupció. D’aquesta manera quant nosaltresdetectem que tenim alguna informació a enviar, usarem aquest endpoint per a fer-ho, veurem més endavant com detectem que tenim informació per a enviar. Com aconseqüència, en el nostre projecte rebrem una interrupció generada per aquestendpoint per a indicar-nos si l’informació ha estat rebuda pel HC de formasatisfactòria o no. No fem cap variació respecte als endpoints anteriors però enaquest cas si que es podria establir una rutina per a verificar que s’ha enviatl’informació correctament. De totes maneres el fet de tractar amb un bus coml’USB, ens dona la garantia que s’hi no s’ha rebut l’informació correctament, elpropi bus s’encarregarà, amb les comunicacions amb el D12 de demanar que esre-envïi l’informació.


Pàg. 76

Ens queda en aquest punt tractar les interrupcions generades per l’Endpoint decontrol (Endpoint 0 Out i 0 In).

La primera que estudiarem és la corresponent a 0 In. Aquesta és la que fem servirper respondre a les peticions d’informació del HC. Si rebem una interrupciógenerada per aquest Endpoint això implica que el HC ha rebut el paquet anterior.El que faríem seguidament es comprovar si queda informació a enviar i si es aixíes continua enviant fins a que ja no en quedi més.

El fluxograma d’aquest apartat seria el següent:

EP 0 In

Queda info

Si

No

Enviar següent paquetde dades

Fi EP 0 In


Pàg. 77

Si desglossem les subrutines comentades, de les que nosaltres tractarem, sense capmena de dubte, la que tracta l’Endpoint 0 Out n’és la més complexa. Aquesta hade tractar de forma diferent el fet que es rebi un paquet de Setup o de dades.

Si es detecta un paquet de Setup, els passos a seguir son el següents:

Primerament fem una copia dels 8 bytes en que hem vist en que es descomponaquesta transmissió de dades.

El següent pas seria notificar al D12 que hem verificat que aquest és un paquet deSetup fent un Acknowledge Setup a l’endpoint 0

Seguidament és el moment que implementem el punter a comanda introduïtanteriorment i que saltem a la subrutina correcta per a poder servir la comanda decontrol que s’ens requereixi. I contestar enviant al HC l’informació sol·licitada(aquesta sempre s’envia per l’Endpoint 0 In com hem vist anteriorment).

Per últim, hem de manipular l’informació obtinguda de tractar i detectar lacomanda de control correcta. Seria doncs el moment de respondre enviantl’informació necessària tenint en compte si hem de respondre retornant una tauladescriptora, un seguit de bytes, modificant l’adreça configurada en el nostreperifèric o senzillament, fent un Stall de l’endpoint.

Si hem rebut un primer paquet de Setup indicant que el pròxim és un paquet dedades, el que fa el programa és esperar el paquet i tractar-lo com si fos informaciórebuda per l’aplicació que s’executa en el HC i encén o apaga els Leds delHardware segons l’informació que rebem.


Pàg. 78

Si fem l’organigrama d’aquest apartat en concret ens trobaríem amb un esquemasemblant al següent:

EP 0 Out

Fi EP 0 In

Copia bytes Setup

Acknowledge Setup

Executar subrutinacorrecta

STALL

Si

No

Stall EP 0

Quedainfo

Si

No

Enviar paquet dedades


Pàg. 79

La primera conseqüència a destacar és que, si mai es vol modificar el programaper adaptar-se a qualsevol nova utilitat, la major part de la feina a nivell llenguatgeensamblador serà la de desenvolupar novament la part referida a la nostraaplicació (o programa principal) mentre que les parts dedicades a lescomunicacions seran eminentment la mateixes (ens referim en aquest cas al serveide l’interrupció).

L’informació necessària per a programar el D12 s’ha obtingut dels manuals quefacilita Philips. D’aquesta manera per a ampliar coneixements us remeto alfabricant i als manuals del propi D12.


Pàg. 80

1.5.5. Configuració per a proves

Un cop tinguem el codi ensamblador i el perifèric llestos per funcionar, serà elmoment de fer les primeres proves per debugar el codi i els possibles errors quepuguin existir. Amb aquesta finalitat muntarem el perifèric amb la configuraciósegüent:

En ella es pot veure que el que tindrem seran dos ordenadors treballant perseparat. Un ordenador el connectarem la placa dissenyada i ho farem mitjançant elconnector USB. Aquest serà el responsable de realitzar tots els passos necessarisper a enumerar el dispositiu i fer que aquest funcioni correctament.

El segon ordenador estarà configurat per a fer les feines d’emulació delmicrocontrolador 8052, d’aquesta manera no serà necessari introduir i programarel codi en el microcontrolador i tindrem accés directe als registres i estat dels flagsdel mateix per a facilitar la correcta avaluació del funcionament del llenguatgeensamblador que hem programat per a realitzar totes les rutines.


Pàg. 81

1.6. Configuració del dispositiu segons el nostre sistema operatiu

En aquest apartat podem distingir clarament entre el software propi per a executarla nostra aplicació i la resta d’informació que requerirà el sistema operatiu per afer viable el correcte funcionament del sistema que creem.

Veurem primerament tots els arxius que requereix el sistema i seguidamententrarem plenament en el que és l’aplicació que nosaltres hem creat.

1.6.1. Creació de l’arxiu INF

Sempre que el sistema operatiu detecta un nou perifèric que es connecta alordenador, aquest ens demana que li facilitem informació per a seleccionar elsdrivers que el nou equipament necessita. Nosaltres, en aquest moment,direccionem el sistema per a que accedeixi a un arxiu .INF. Aquest contél’informació necessària per a que el sistema es pugui comunicar amb el perifèricen qüestió, mitjançant la càrrega dels drivers necessaris. Seguidament, la restad’aplicacions del ordenador poden comunicar-se sense més problemes amb elperifèric.

La creació de l’arxiu d’informació sobre el sistema es un pas que ens podríemsaltar perfectament. La raó és que quant el sistema operatiu enumera el nouperifèric en llegeix les seves característiques i detecta que és un HID. De lamateixa manera que el sistema operatiu incorpora els drivers per aquestadeterminada classe de perifèrics, també disposa d’un arxiu per defecte per als seuscomponents. Aquest arxiu es pot veure i llegir , s’anomena hiddev.inf i es trobaper defecte en el directori windows\inf.

D’aquesta manera el primer cop que es connecta el perifèric, el sistema operatiuens demana que seleccionem els drivers. Els següents cop que connectarem eldispositiu ja tindrà l’informació necessària i aquest pas ja no serà necessari.

L’inconvenient que volem solucionar creant el nostre propi arxiu INF es qued’aquesta manera en l’administrador de dispositius de Windows 98 apareixerà ladescripció que nosaltres vulguem fer del nostre dispositiu i no tan sols ‘StandardHID Device’ que sortiria per defecte. Al igual que serà més fàcil per a nosaltresincloure nous drivers per a facilitar el moment en que es vulgui incloure novesclasses de transmissió de dades.


Pàg. 82

Per a crear el nostre propi arxiu ens hem basat en l’arxiu que el sistema utilitza perdefecte, modificant el contingut i adaptant-l’ho als descriptors de les nostrestaules. En concret, el sistema operatiu per seleccionar un arxiu INF es basa en elcontingut del Device Descriptor, Vendorid i Productid. D’aquesta manera si tantel nostre Device Descriptor com l’arxiu INF tenen el mateix contingut, el sistemasap que aquesta es la configuració correcta i és la que seleccionarà sempre que esconnecti el nostre perifèric.

De totes maneres hem de saber primer quins son els Drivers que el nostreprograma ha de carregar. D’aquesta manera ja hem comentat anteriorment quinssón els passos pels que passa una funció per arribar a comunicar-se amb elperifèric USB. Si substituïm les referències anteriors pels arxius que ho permeten,l’estructura ens quedaria d’aquesta nova forma:

La descripció dels mòduls que aquí presentem és la següent:

HIDCLASS.SYS és el driver de la classe HID. Envia i rep els HID reports de icap als seus minidrivers.

HIDUSB.SYS és el driver dels components HID. Envia i rep els HID reports através del bus USB.

USBHUB.SYS és el driver dels hubs. Aquest es carrega cada cop que elUSBD.SYS enumera el root hub que incorporen tots el HC controllers. Al mateixtemps el USBD.SYS és el controlador exclusiu del root hub. També hem dedestacar que cada cop que es detecta un hub addicional es carrega elUSBHUB.SYS.

HIDCLASS.SYS

HIDUSB.SYS

Altres driverspropis del’aplicació

USBHUB.SYS

USBD.SYS

PCI Enumerator

USB Bus

UHCD.SYS OpenHCI.SYS

USBDriverInterface

USBDriverStack


Pàg. 83

UHCD.SYS i l’OpenHCI.SYS son controladors del HC.

PCI Enumerator és l’encarregat de carregar els components del USB Driver Stackcada cop que el sistema detecta la presencia d’un bus USB al sistema.

1.6.2. Execució i control de la nostra aplicació

Arribat aquest punt ja tenim el nostre perifèric connectat i correctamentconfigurat. És l’hora doncs de fer que aquest executi l’aplicació que hem comentatanteriorment. Amb aquesta finalitat tant sols hem d’afegir el llenguatgeensamblador necessari. Fins al moment el microcontrolador sols controlava lescomunicacions a través del bus USB, escriurem doncs les eines necessàries per aque pugui executar la funció per a la qual hem dissenyat tot aquest projecte.

De totes maneres tot això no funcionaria sense l’aplicació software que hemprogramat. El conjunt està pensat per a que ambdues parts estiguin directamentrelacionades i no puguin funcionar l’una sense l’altra.


Pàg. 84

1.7. Aplicació software executada en el Master

El següent pas, un cop tenim el perifèric creat i llest per a interactuar amb el nostreordenador es crear un programa per a l’ordenador que comprovi el correctefuncionament del perifèric i ens hi permeti interactuar de el propi ordenador.

1.7.1. Funcions necessàries en la nostra aplicació

Un cop hem definit superficialment com serà físicament el nostre perifèric hem dedeterminar quines seran les funcions que la nostra aplicació farà servir per acomunicar-se amb el sistema i el perifèric en concret.

D’aquesta forma el llenguatge de programació que farem servir serà el VisualC++, el qual ens permetrà una interacció més amplia amb el sistema apart dedonar-nos eines per a construir una Interface més agradable per a l’usuari final del’aplicació.

De totes maneres el que volem realment en aquest apartat és mostrar quines seranles crides al sistema o APIs que l’aplicació en si farà servir ja que suposem enaquest punt que el lector està més o menys instruït en el llenguatge deprogramació C/C++.

La raó per la qual hem escollit aquest llenguatge de programació és entre d’altresmotius pel fet que és relativament conegut i extens, es pot trobar moltadocumentació referent al llenguatge i la seva relació amb el protocol USB i endefinitiva la seva gran modularitat a l’hora de programar farà del producteresultant un codi potent i extensible a altres aplicacions en quant es vulguidesenvolupar el projecte actual.

També hem de destacar que fem servir crides al sistema o APIs (applicationprogrammer’s interface) que permeten la comunicació entre els drivers delscomponents i les aplicacions. L’inconvenient més gran que presenten aquestescrides és que requereixen que passem uns paràmetres molt determinats i que estansols definits en C/C++ cosa que nosaltres solucionem al usar aquest mateixllenguatge. Si el nostre programa estès fet en un altre llenguatge, haguéssimnecessitat adaptacions.


Pàg. 85

Un llistat d’aquestes crides al sistema es el següent:

Funció API DLL Finalitat

HidD_GetHidGuid hid.dll Detecta la presencia d’elements d’una classe en concret

SetupDiGetClassDevs setupapi.dll Retorna informació sobre tots els elements de la classe

SetupDiEnumDeviceInterface setupapi.dll Retorna informació d’un dispositiu concret

SetupDiGetDevice InterfaceDetail setupapi.dll Retorna el del dispositiu determinat

CreateFile kernel32.dll Obre la comunicació amb el dispositiu

HidD_GetAttributes hid.dllRetorna informació emmagatzemada en les taulesdescriptores

HidD_GetPreparsedData hid.dll Retorna informació sobre el buffer del dispositiu

HidD_GetCaps hid.dll Retorna informació sobre les utilitats del dispositiu

HidD_GetValueCaps hid.dll Retorna una estructura amb valors sobre el dispositiu

HidD_GetButtonCaps hid.dll Retorna una estructura amb valors sobre el controls del disp.

WriteFile kernel32.dll Envia informació al dispositiu

ReadFile kernel32.dll Llegeix informació al dispositiu

CloseHandle kernel32.dll Allibera recursos creats per CreateFile

SetupDiDestroyDeviceInfoList setupapi.dll Allibera recursos creats per SetupDiGetClassDevs

HidD_FreePreparsedData hid.dll Allibera recursos creats per HidD_GetPreparsedData

Més endavant mostrarem com fem servir les crides mostrades anteriorment i quinsson el paràmetres que hem de passar amb la finalitat que aquestes s’executin de laforma esperada.


Pàg. 86

En aquest cas per a comunicar-se amb el dispositiu és una mica més complicat queenviar uns certs paràmetres a una direcció i tot seguit llegir o escriure dades.Primerament l’aplicació a de localitzar el dispositiu i obtenir informació sobrecom aquest ha de rebre l’informació (en el nostre cas això es una mica redundantja que al haver dissenyat nosaltres el dispositiu sabem prèviament el tipusd’informació i la estructura que ha de tenir).

Això ho fem mitjançant la crida d’unes funcions API que detecten dispositiusconcrets, en el nostre cas pertanyent a la classe HID. Aquest pas el fem de formarecorrent fins a trobar el dispositiu que nosaltres busquem ja que el sistema no téforma d’anar directament a un dispositiu HID concret.

Un cop hem localitzat el dispositiu l’aplicació ha de crear els canals decomunicació i seguidament es pot comunicar amb aquest a partir d’enviar’l-hi irebre'n dades amb un format concret que anomenarem ‘reports’ el qual definimnosaltres i emmagatzemem en les taules descriptives del dispositiu que ja hem vistanteriorment.

Amb aquest objectiu hem creat un programa amb Visual C++ que podríemdescriure amb el següent diagrama de flux simplificat que mostrem a la pàginasegüent:


Pàg. 87

ProgramaPrincipal

InicialitzacióVariables

Buscar PerifèricCorresponent

Existeix elDispositiu ?

No

Si

Error Perifèric

Creem el fil delectura i escriptura

Rebem un caràcter Modifiquem algunvalor

Tractament i enviod’info.

Error al enviar

NoNo

Si


Pàg. 88

La totalitat del codi del programa comentat el podem trobar la memòria de càlcul.Per a facilitar una millor comprensió d’aquest codi fem a continuació unadescripció de les funcions que hi podem trobar, quina és la seva aplicació i comfan la feina .

Amb aquesta finalitat ens proposem desglossar la totalitat del programa en elssegüents apartats que tenen una relació directa amb la utilització del programa, elsseus apartats i la seva execució.


Pàg. 89

1.7.2. Classe CPFCDlg

Com ja es pot deduir pel nom d’aquesta classe, fem servir una pantalla basada enun diàleg, Modal en el nostre cas. Aquesta classe inclou les característiquespròpies i funcions que incorporen el diàlegs Modals de la llibreria MFC deWindows. Aquest en concret inclou unes funcions pròpies definides per nosaltres in’hem modificades les necessàries per aconseguir el resultat final desitjat.

Destacarem les següents funcions que hem afegit a la classe per a respondre a lesnostres necessitats:


Pàg. 90

La funció OnCrearCanal() s’executa com a resposta de la pulsació de l’usuari albotó amb la mateixa comanda, Crear Canal. La primera tasca que té aquestafunció es executar les funcions de la classe USBInterface necessàries per a buscarel perifèric i connectar-si. Un cop ja estem connectats, la segona tasca d’aquestafunció és crear el segon fil del programa i assignar-l’hi la funció globalRebreInfo() que comentarem més endavant. També es feina d’aquesta funciódetectar si hi ha hagut algun error en el procés i informar-ne l’usuari.

OnDestruirCanal() és la segona de les funcions que s’executen directament avoluntat de l’usuari. És l’encarregada de cridar la seva equivalent en la classeUSBInterface per alliberar recursos i conta, al igual que l’anterior de duespossibilitats que habiliten o deshabiliten els botons i icones de la pantalla enfunció de l’estat de la connexió. També cridem a aquesta funció al sortir del’aplicació per assegurar-nos que no queden recursos sense alliberar o quant en unestat de connexió amb el perifèric la comunicació es perd be sigui per ladesconnexió del mateix o per l’aparició d’un error no recuperable.

OnModificacioDialeg() s’executa com a resposta a la modificació per part del’usuari de qualsevol de les variables que interactuen amb el dispositiu (tant potésser qualsevol dels BotonsSoft com l’operació a realitzar). Com a resposta aaquesta acció el programa detecta la modificació. També està en paral·lel ambaquesta funció OnByteRebut() que s’executa com a resposta d’una crida delmissatge de Windows que hem definit com a resposta a la recepció d’un byte delperifèric. Ambdues s’encarreguem de mostrar per pantalla l’estat en que quedenles variables i fan una crida a la funció Tractament().

L’última funció que destacarem d’aquesta classe és la ja mencionadaTractament(). Es la responsable d’enviar l’informació a la classe USBInterfacemitjançant la variable USB, realitzar les operacions necessàries amb les dades ienviar l’informació resultant al perifèric per a que aquest mostri l’informaciómitjançant la matriu de leds. Al mateix temps s’actualitza per pantalla l’estatd’aquesta matriu en el seu display equivalent.


Pàg. 91

1.7.3. Classe USBInterface

Aquesta és la classe que hem creat per a englobar tota l’informació que utilitzemen les comunicacions al igual que totes les funcions que són imprescindibles per aportar a terme les comunicacions.

Començarem veient les variables que existeixen en aquesta classe i la sevafinalitat ja que són crucials per a la comprensió del programa i continuarem per lesprincipals funcions que incorpora i les operacions que fan.

Veurem primerament la definició de classe i entrarem seguidament a comentar endetall cadascuna de les variables i funcions que la componen. Així doncs ladefinició podria ésser la següent:

FFuunncciioonnss

ff11(()) BBuussccaarrDDiissppoossiittiiuu DDeetteeccttaa llaa pprreesseenncciiaa ddeell nnoossttrree ppeerriiffèèrriicc

ff22(()) DDeessttrruuiirrCCaannaall AAlllliibbeerraa eellss rreeccuurrssooss uussaattss ppeell pprrooggrraammaa

ff33(()) RReeaalliittzzaarrOOppeerraacciioo CCaallccuullaa eell nnoouu vvaalloorr aa eennvviiaarr

ff44(()) EEnnvviiaarrIInnffoo EEnnvviiaa eell nnoouu vvaalloorr aall ppeerriiffèèrriicc

VVaarriiaabblleess

BBoottoonnssHHaarrdd EEmmmmaaggaattzzeemmaa eell vvaalloorr ddeellss iinntteerrrruuppttoorrss eenn eell ddiissppoossiittiiuu

BBoottoonnssSSoofftt EEmmmmaaggaattzzeemmaa eell vvaalloorr ddeellss iinntteerrrruuppttoorrss ‘‘vviirrttuuaallss’’

DDiissppllaayyHHaarrdd EEmmmmaaggaattzzeemmaa eell vvaalloorr aa eennvviiaarr

CCoonneeccttaatt IInnddiiccaa ssii ss’’hhaa ttrroobbaatt eell ddiissppoossiittiiuu ii tteenniimm ccoommuunniiccaacciióó


Pàg. 92

1.7.3.1. Variables de USBInterface

El les variables i les funcions pròpies de la classe les podem veure en la següentpantalla del compilador de Visual C++ i les descrivim a continuació:


Pàg. 93

La variable més important ens guarda informació sobre si hem aconseguit establirconnexió amb el perifèric, es una variable booleana (Connectat) que val 0 perdefecte indicant que no hi ha connexió. També serà l’encarregada de comunicar elfil principal del programa amb el fil treballador, que creem més endavant.

Tenim tres unsigned chars, caràcters de vuit bits sense signe (rang de 0 -255) elsquals guardaran l’informació del byte rebut (BotonsHard), byte enviat(DisplayHard) i el byte que entra l’usuari a partir de la pantalla (BotonsSoft).

El byte a enviar (DisplayHard) serà el resultat de la operació bit a bit entre el byterebut (BotonsHard), i el byte de l’usuari (BotonsSoft). L’operació concreta vindràdefinida per una variable (Operacio) el contingut de la qual serà un número queens definirà les operacions segons els valors següents:

Valor numèric Operació realitzada Valor final a enviar

0 And bit a bit BotonsSoft & BotonsHard

1 Or bit a bit BotonsSoft | BotonsHard

2 Xor bit a bit BotonsSoft ^BotonsHard

3 Només byte usuari BotonsSoft

4 (per defecte) Només byte rebut BotonsHard

Tot i que no fem servir l’informació en cap moment, un cop establerta lacomunicació, sol·licitem al perifèric que ens enviï les cadenes que porten el nomdel fabricant i descripció del producte. Aquesta informació l’emmagatzemem enles variables ProductName i VendorName. De la mateixa manera hem definit dosconstants que contenen el ProductID i VendorID segons els hem definit a lestaules del perifèric i que serviran per identificar el nostre perifèric de formairrevocable.

VendorID = 0x1111;ProductID = 0x2222;

Per finalitzar amb les variables tenim dos Handle que son punters als canals decomunicació (o pipes) que crearem per a comunicar-nos amb el perifèric. Elscanals s’utilitzaran respectivament, un per a la lectura de l’informació enviada delperifèric (CanalLectura) i un per a escriptura d’informació cap al perifèric(CanalEscritura).


Pàg. 94

1.7.3.2. Funcions de USBInterface

En quant a les funcions, el codi que contenen es pot veure a l’apartat ja mencionatanteriorment i també els comentaris. De totes formes si les descrivim de formageneral en podríem destacar les següents finalitats:

Les primeres a utilitzar son el constructor i destructor. Sols hem modificat elconstructor inicialitzant tots els valors de les variables deixant el destructor de laforma original.

La següent funció que utilitzem és la de BuscarDispositiu(). És una funció cruciali per aquest motiu l’explicarem amb més detall. La seva finalitat es detectar elperifèric i crear els canals de comunicació que utilitzarem la resta del programa. Siaquesta funció no aconsegueix trobar el dispositiu, la resta del programa éssupèrflua.

Per a detectar el dispositiu ens basarem en el valor GUID (Globally UniqueIDentifier) de la classe. Aquest és un número que ve determinat per Windows iens serveix per a, un cop establerta comunicació amb l’administrador del sistema,obtenir una llista de dispositius connectats a l’ordenador que pertanyin a la classedeterminada pel valor. En el nostre cas la classe es HID (Human Interface Device)i com hem dit té un GUID únic i irrepetible.

El que fem a continuació es un bucle on ens connectem a cadascun delsdispositius d’aquesta classe i els demanem l’identificació del fabricant i delproducte. Això ho fem en tots fins que trobem el que coincideix amb els valorsque hem donat al nostre dispositiu i també sabem prèviament.

Els errors que pot tornar aquesta funció depenent de quin pas no hem pogutrealitzar i sols retornarà 0 si hem trobat el dispositiu i ens hi podem connectar (enaquest cas també es canviaria el valor de la variable Booleana indicant que jatenim comunicació i es crearien els canals de comunicació). La llista d’errors ambque ens podem trobar executant aquesta funció és la següent:

Error 1: No podem establir comunicació amb el controlador que ens ha dedeterminar quins dispositius hi ha connectats corresponents a la nostra classe.

Error 2: No hem trobat informació en el controlador anterior.

Error 3: Algun dels dispositius de la classe ha fallat a l’hora d’enviar-nos la sevapròpia informació.


Pàg. 95

Error 4: Hem pogut localitzar el dispositiu amb l’informació igual a la predefinidaperò no hem pogut crear els canals de comunicació.

Error 5: No hem pogut localitzar un dispositiu amb l’informació igual a lapredefinida i que per tant seria el nostre dispositiu.

La següent funció que utilitzem es RealitzarOperacio() que depenent del valor dela variable Operacio, executarà una o altra variació dels valors i tot seguit crida lafunció EnviarInformacio().

Aquesta última es l’encarregada d’adaptar els valors i passar l’informaciónecessària a la API WriteFile() que finalment envia l’informació al perifèric.Segons el valor de retorn de la funció també podem saber si l’informació ha estatenviada i si ho ha estat de forma correcta.

Finalment tenim la funció DestruirCanal() que es crida al sortir de l’aplicació, altenir algun error o a petició de l’usuari que allibera els recursos utilitzats i ensdesconnecta del perifèric.


Pàg. 96

1.7.4. Variables i funcions globals

En aquest apartat podem destacar l’existència d’una variable pertanyent a la classeUSBInterface que anomenem USB i la funció RebreInfo().

La variable USB serà la responsable de guardar tota l’informació pertanyent a lescomunicacions. Mentre que la funció mencionada serà la que executem en el fil detreballador que creem al trobar el dispositiu.

La finalitat de crear el fil treballador és fàcil d’entendre. Les crides a funcions I/Oen el sistema operatiu queden en suspens, es a dir esperant informació. Si féssimuna lectura en el fil principal del programa aquest es ‘penjaria’ fins que entréssiminformació del perifèric. Per evitar això la funció de RebreInfo() s’executa en elsegon fil i envia un missatge de Windows definit per nosaltres quant rebeminformació vàlida que hem de tractar. Al estar usada en un altre fil, el sistemaoperatiu ens obliga a que sigui una funció global i és per aquest motiu que no estàinclosa en la classe USBInterface com seria d’esperar.

També per conveniència, ja que la funció global RebreInfo() sols pot veurevariables globals, hem fet la variable USB global per a que sigui més fàcilintercanviar informació.

El fil escriptura s’executa directament quant el cridem raó per la qual s’executasempre de el fil principal del programa.

Fins aquí el que s’ha de destacar de les classes i les funcions que componen aquestprograma. Per a qualsevol informació més detallada o per veure la forma amb quees du a terme, us remeto al mateix codi de l’aplicació.


Pàg. 97

1.7.5. Resultat final

La pantalla principal o diàleg el qual es troba l’usuari un cop hem creat elprograma executable on fem us de totes les característiques anteriors és la següent:

En aquesta pantalla l’usuari troba les principals funcions a la part superior dreta,on pot crear i destruir el canal de comunicacions i sortir de l’aplicació.

Té també tres bateries d’icones amb l’indicatiu Display Hardware, Connexionssoftware A i Connexions hardware B, que representen respectivament la matriudel display del perifèric, els interruptors que canvia l’usuari de la pròpia aplicaciói, finalment, els botons que es poden trobar al perifèric.


Pàg. 98

Cada icona té dos estats, actiu, representat pel color vermell, que indica que el ledequivalent estar polaritzat o que l’interruptor perceptiu està connectat i passiu,indicant el contrari.

Els botons als que fem referència en l’apartat anterior, que pot variar l’usuari de lapròpia aplicació, estan situats sota mateix de la bateria d’icones que elsrepresenten cosa que els fa més fàcils de relacionar.

Entre els interruptors i el display està situada una ListBox on l’usuari potmodificar i escollir entre una de les cinc operacions que estan disponibles enaquesta aplicació.

Finalment, a la part inferior de la pantalla, podem trobar una barra d’estat. Enaquesta el programa escriu l’informació que es rellevant i és, per tant, necessarique l’usuari conegui. En aquesta es poden llegir els missatges d’error siexisteixen, l’estat de la connexió, i el fet de saber si s’ha rebut o enviatl’informació de forma correcta.

Finalment abans d’acabar veurem una mica com seria el diagrama dels eventsresultant:

1.Detecció del dispositiu2.L’usuari selecciona un nou valor a enviar3.Arriba un valor nou del perifèric i passem a esperar el següent4.En els dos casos s'avalua el nou valor a ésser enviat5.Al tancar l’aplicació s’espera que el segon fil del programa també alliberi elsrecursos usats

1 2 4 5

3


Pàg. 99


Pàg. 100

2. MEMÒRIA DE CÀLCUL


Pàg. 101

2.1. Introducció

L’objectiu d’aquest apartat del projecte és l’anàlisi i la justificació amb el càlculs iprogrames corresponents d’aquells apartats on es cregui necessària la sevaespecificació.

Per dur a terme el càlcul dels components més rellevants s’ha desglossat tot elconjunt en circuits més senzills tal com s’especifica en la memòria descriptiva.


Pàg. 102

2.2. Hardware

El que farem en aquest apartat és entrar en un detall molt més profund en laconstrucció del nostre perifèric i en farem una descripció detallada de les raonsdels components, material i funcionament.

Per començar veurem un esquema del connexionat de tots els elements per a podercomençar a comentar les coses més detallades. L’esquema és el següent:

La part més destacable és el connexionat que existeix entre el microcontrolador iel D12. Aquestes connexions destaquen per l’existència d’un bus de dades entreambdós circuits multiplexat, cosa que permetria en el futur l’incorporació de nouscomplements com poden ser memòries o altres components externs amb lamàxima simplicitat. Aquest bus inclou totes les senyals pròpies per a lasincronització.

Finalment tenim entre ambdós la part de comunicació principal, és la líniad’interrupció que els uneix, surt del canal d’interrupció del D12 i entre almicrocontrolador pel INT1. Aquesta línia, serà l’encarregada, a nivell hardware,de que totes les comunicacions en el bus USB rebin atenció pel propimicrocontrolador.


Pàg. 103

La major part dels components que inclou la placa son els elements necessaris pera la configuració dels dos circuits integrats principals (8052 i PDIUSBD12) compoden ser els dos cristalls necessaris, de 6 MHz per al D12 i de 12 MHz per al8052, alimentació i massa, condensadors i resistències necessàries per a generar lasenyal del Reset entre d’altres.

A partir d’aquí el microcontrolador utilitza el port 1 per a les funcions pròpies delpropi projecte com són la lectura de la posició dels interruptors i l’encesa i apagatdels leds. Per a facilitar aquesta última maniobra, això es farà per nivell baix,escriure un 0 al bit del port indicarà encendre el led. Això serà així per la pròpiaconfiguració hardware interna del 8052, que és en aquest nivell que elmicrocontrolador pot absorbir la potencia necessària per a fer que el leds’il·lumini.

Un cop vista la configuració i connexionat entre els diferents elements, el quemostrem a continuació es el Layout del apropia placa de circuit imprès:

Les característiques principals que tindrem en compte per a fer les plaques decircuit imprès seran les següents:

Dimensions en mm.Pistes d’alimentació 0,8Pistes de dades 0,5Espai mínim entre pistes 0,5Vies 0,5 forat / 1,1 courePads senzills 0,8 forat / 1,4 courePads grossos 0,8 forat / 1,6 coure


Pàg. 104

2.3. Programació del dispositiu esclau

De la mateixa manera que hem fet en l’apartat anterior, ara és el momentd’aprofundir fins al mínim detall en el que serà el llenguatge ensamblador quecontrolarà el dispositiu esclau o 8052. Ja hem vist en la memòria descriptiva queaquest és el codi que s’executarà en el microcontrolador i n’hem comentatigualment els detalls principals.

;***********************************************************;; Programa per a les comunicacions utilitzant; el protocol USB;;***********************************************************

.CODE

;-----------------------------------------------------------; Aquest mòdul inclou la declaració de totes les variables; que farem servir;-----------------------------------------------------------

;Constants

EP0Size: .EQU 16 ; Capacitat del buffer de resposta delD12D12address: .EQU 0001H ; Direcció del comando de dades del D12

; Variables globalsValorLed: .EQU 25H ; On guardem el valor dels ledsValorBotons: .EQU 26H ; On guardem el valor dels botonsFLAGS: .EQU 27H ; Registre controlat bit a bit

; Variable usada amb significat propi per a cada bit; definits de la següent manera:

;Configurat: FLAGS.0 ; Indica si tenim el dispositiuconfigurat;STALL: FLAGS.1 ; Hem de fer un STALL de l'endpoint 0;SendData: FLAGS.2 ; Hem d'enviar informació al HC com a

; resposta;Descriptor: FLAGS.3 ; L'informació a enviar es un descriptor

CurrentConf: .EQU 28H ; Var. que emmagatzema la conf. actual;(suposant varies)

Msec_Counter: .EQU 29H ; Comptador per a generar retardsSaveDPH: .EQU 2AH ; Guardem el punters a taulesdescriptoresSaveDPL: .EQU 2BHSaveLength: .EQU 2CH ; Numero de bytes que falten per enviar


Pàg. 105

SetupDataResv: .EQU 2DH ; Primer valor de la pila de lectura del; D12 (sempre 0)

SetupDataLen: .EQU 2EH ; Segon valor de la pila (llargada; d’informació rebuda)

SetupData: .EQU 2FH ; Buffer d’accés directa a memòriaRequestType: .EQU 2FH ; USB Setup Packet (1er byte)Request: .EQU 30H ; USB Setup Packet (2on byte)wValueLow: .EQU 31H ; USB Setup Packet (3er byte)wValueHigh: .EQU 32H ; USB Setup Packet (4art byte)wIndexLow: .EQU 33H ; USB Setup Packet (5er byte)wIndexHigh: .EQU 34H ; USB Setup Packet (6er byte)wLengthLow: .EQU 35H ; USB Setup Packet (7er byte)wLengthHigh: .EQU 36H ; USB Setup Packet (8er byte)ReplyCount: .EQU 37H ; Llargada del buffer de respostaReplyBuffer: .EQU 38H ; Contingut del buffer de resposta

; (Aquesta + 15 pos.)


Pàg. 106

;-----------------------------------------------------------; Taula de vectors d'interrupcions;-----------------------------------------------------------

.ORG 0000HLJMP RESET.ORG 0013HLJMP INTER

;------------------------------------------------------------; Rutines de suport que 'parlen' amb el D12;------------------------------------------------------------;; El D12 està compost per dos direccions o registres, el de dades; (0000H) i el de comandes; (0001H). El que fem aquí es fer un envio per seleccionar una; comanda i acabem com a conseqüència amb el DPTR apuntant a la; posició de dades per si fos necessari llegir-hi ho escriure-hi; informació complementaria.;;------------------------------------------------------------

D12write: ; Escrivim informació en els registres delD12

MOVX @DPTR,ANOP ; Introduïm un retard de forma que no violemNOP ; el temps entre accessos al D12NOPNOPRET

D12command: ; Enviem una comanda al D12MOV DPTR,#D12address ; Apuntem a la direcció de comandes del

; D12CALL D12writeDEC DPL ; Retornem apuntant al registre de dades delRET ; D12

D12GetStatus: ; Fem una lectura de l'estat del D12. AixíCALL D12command ; també es borra la petició d'interrupció

; Continuem amb l'instrucció D12read

D12read: ; Llegim informació en els registres del D12MOVX A,@DPTRNOP ; Introduïm un retard de forma que no violemNOP ; el temps entre accessos al D12NOPNOPRET


Pàg. 107

;-----------------------------------------------------------; Aquest apartat inicialitza el 8052 i el PDIUSBD12;-----------------------------------------------------------

.ORG 50H

RESET:

; Inicialitzem les variables del Codi ensambladorMOV SP,#80H ; Inicialitza l'StackCLR AMOV ValorLed,A ; Tenim tots els leds apagatsMOV ValorBotons,A ; Emmagatzemem els valors. Per defecte

; el software; els considera apagats. Si no es així; s'enviarà; el valor correcte amb el següent SOF

MOV FLAGS,A ; Inicialitzem la variable d'estatMOV SaveLength,A ; No tenim res pendent d'enviar

; Inicialitzem el Hardware del MicrocontroladorSETB IE1 ; INT1 per flancSETB EX1 ; Habilitem interrupció externa 1SETB EA ; Habilitem les interrupcionsMOV P1,#FFH ; Apaguem els leds i deshabilitem la

; lectura

; Inicialitzem el Hardware del D12CLR P3.5 ; Fem un reset per HARDWARE del D12MOV R7,#100 ; Donem temps per a fer el ResetCALL EsperarSETB P3.5 ; Final del reset HARDWARE del D12MOV R7,#100 ; Donem temps per a que el D12 estigui

; alimentatCALL EsperarMOV A,#F3H ; Set_Mode commandCALL D12commandMOV A,#00010110b ; Endpoint Configuration = 00 (Non-ISO)CALL D12write ; SoftConnect = 1 (Ens connectem al USB

; en aquest moment); Interrupt Mode = 0 (no interromp si; rebem un error); Clock running = 1; No LazyClock = 1

MOV A,#01000010b ; SOF-ONLY = 0CALL D12write ; Clock Division Factor = 2 == 16MHz

; Falta configurar els envios en DMA però ho fem un cop hem; configurat i executem la comanda Set_Address. Fins a aquell; moment no es necessari.; Final de les inicialitzacions


Pàg. 108

; Programa principal; Com es pot veure no fa gran cosa. Això ens permetria queaquest ; pogués fer altres coses mentre no hi ha cap instrucciópendent; de les comunicacions.

MAIN:NOP ; En el programa principal no fem resJMP MAIN ; Servim totes les comandes de com. Per

; interrupció

Esperar: ; Bucle per a generar un retard de 1ms; approx.

MOV DPTR,#-1200Mes: INC DPTR ; 3 cicles

MOV A,DPL ; + 2ORL A,DPH ; + 2JNZ Mes ; + 3 = 10 cycles x 1200 = 1msecDJNZ R7,EsperarRET


Pàg. 109

;-----------------------------------------------------------; Aquest apartat serveix les interrupcions del D12;-----------------------------------------------------------

INTER:

PUSH PSW ; Guardem l'informació a la pilaPUSH ACCPUSH DPLPUSH DPH

;El primer que hem de fer es determinar d'on be l'interrupcióMOV A,#F4H ; Seleccionem la comanda DATA FLOW

; COMMANDSCALL D12GetStatus ; Ens retorna el Acc. amb la causa de

; l'Int.CALL TrobarInt

POP DPH ; Restaurem els registresPOP DPLPOP ACCPOP PSWRETI

; Un cop sabem pel D12 quin EndPoint ha generat l'interrupció,; ho averigüem i servim la comanda que tingui pendent.

TrobarInt:

; Execució de la subrutina correcta com a resposta de la Int.JB ACC.7,Suspend ; Saltem si l'info. es troba aquiJB ACC.6,BusReset ; Saltem si l'info. es Bus ResetJB ACC.5,EP2In ; Saltem si l'info. es troba en EP2 inJB ACC.4,EP2Out ; Saltem si l'info. es troba en EP2 outJB ACC.3,EP1In ; Saltem si l'info. es troba en EP1 inJB ACC.2,EP1Out ; Saltem si l'info. es troba en EP1 outJB ACC.1,EP0In ; Saltem si l'info. es troba en Con. inJB ACC.0,EP0Out ; Saltem si l'info. es troba en Control

; out


Pàg. 110

; Si no ha sigut cap de les anteriors es per que estem davant ; d’ un Start Of Frame, que hem configurat que també generés; l'interrupció.; El que fem es enviar el valor de la lectura a cada SOF.

SOF:JNB FLAGS.0,Done ; Hem de tenir l'aplicació en marxaMOV A,#FFH ; Llegim l'informació del portXRL A,P1 ; Invertim el contingut ja que 0

; significa que tenim el valorSWAP A ; seleccionatANL A,#00001111b ; L'adaptem per a poder manipular-laMOV ValorBotons,A ; Copiem el nou valor per a la posicio

; dels botonsJMP SendReport ; RETurn a través de SendReport

; Aquí comencem a servir les interrupcions reconegudes; anteriorment

BusReset:CLR FLAGS.0 ; El D12 reinicialitza l'adreça interna

; a 0

Suspend: ; De moment ignorem aquesta comanda

; Un cop hem servit les interrupcions retornem.Done:

RET

; En els tres casos següents, no hauríem de rebre una interrupció.; D'aquesta manera en llegim l'estat i la pròpia funció D12GetSatatus; amb el seu Ret ens retornarà al fil normal del programa.;; Si es donés el cas que rebíem alguna d'aquestes interrupcions; podríem fer un tractament més acurat per saber que ha passat cosa; que no fem.

EP2In:MOV A,#45H ; Read_Last_Transaction_Status(EP2In)JMP D12GetStatus ; No hauríem de rebre informació per

; aquesta Int.

EP2Out:MOV A,#44H ; Read_Last_Transaction_Status(EP2Out)JMP D12GetStatus ; No hauríem de rebre informació per

; aquesta Int.

EP1Out:MOV A,#42H ; Read_Last_Transaction_Status(EP1Out)JMP D12GetStatus ; No hauríem de rebre informació per

; aquesta Int.


Pàg. 111

; Servei d'interrupció generada per l'Interrupt Pipe quan ja s'ha; enviat el byte.

EP1In:MOV A,#43H ; Read_Last_Transaction_Status(EP1In)JMP D12GetStatus ; Ens informa que el HC ha rebut

; l’últim Report

; Servei d'interrupció generada pel Control Pipe.;; La resta d'interrupcions estan generades per alguna de les funcions; de control o el seu servei.; El primer es el sentit d'informació enviada al HC. Si hi entrem es; per que s'han enviat les dades i faltaria mirar si en queden més; per enviar i si es així les enviem en aquest mateix moment.

EP0In: ; El buffer del EP0In esta disponibleMOV A,#41H ; Read_Last_Transaction_Status(EP0In)CALL D12GetStatus

; El que mirariem ara es per veure si tenim alguna taula; descriptora pendent d'ésser enviadaMOV A,SaveLength ; Comprovem la llargada d'informació a

; enviarJZ Done; Encara tenim informació per a ésser enviadaMOV DPH,SaveDPH ; Restaurem el punter a aquesta info.MOV DPL,SaveDPLJMP SendNextPieceOfDescriptor ; Retornem amb el Ret d'aquesta

; sub-rutina

; El segon respon a peticions que venen del HC, poden ser comandes de; Setup i dades les tractarem respecte al seu contingut.

EP0Out:MOV A,#40H ; Read_Last_Transaction_Status(EP0Out)CALL D12GetStatusJNB ACC.5,SendSTALL ; Comprovem que es us Setup Packet

; sinó ho es fem un STALL de l'EndPoint

; En aquest punt acabem de rebre un Setup Packet per part del; HC. El següent pas seria interpretar-lo i actuar en; conseqüència responent a la petició que ens hagi fet el HC.; Els packets que puguem rebre en aquest EndPoint que no; siguin de Setup els processem en un altre apartat d'aquest; programa.


Pàg. 112

SetupP:CLR AMOV SaveLength,A ; Eliminem els possibles envios que hi

; hagués pendentMOV A,#0 ; Select_Endpoint(EP0Out) commandCALL D12commandMOV A,#F0H ; Read_Buffer commandCALL D12commandMOV R0,#SetupDataResv ; Copiem la direcció del buffer de

; dades en R0MOV R7,#10 ; Registre temporal amb el número de

; bytes a llegir

; Final de la verificació conforme es un Setup Packet, i en fem; el bolcat del contingut al buffer preparat a la memòria.

CopiaSD:CALL D12read ; Llegim el registre del D12 on hi ha

; la dadaMOV @R0,A ; Guardem el contingut en el Buffer de

; dades rebudesINC R0 ; Al mateix temps anem recorrent tot el

; BufferDJNZ R7,CopiaSD

; El següent pas seria notificar al Hardware que hem rebut i; som conscients que tractem un Setup Packet. Això ho hem de; fer en els dos punters de l'endpoint 0

MOV A,#F1H ; Acknowledge_Setup commandCALL D12commandMOV A,#F2H ; Clear_Buffer commandCALL D12commandMOV A,#01 ; Select_Endpoint(EP0In) commandCALL D12commandMOV A,#F1H ; Acknowledge_Setup commandCALL D12command

; Un cop fet això tenim el D12 preparat per a rebre i enviar; informació; Per a fer-ho deixem seleccionat l' EP0In


Pàg. 113

CALL ServiceSetupPacket

; Ja hem tractat el packet ara fem les peticions pertinents; if STALL {Stall the endpoint}; else if SetAddress {Update SIE address}; else if SendData {; if IsDescriptor {send DPTR->descriptor, A =; length}; else {send ReplyBuffer}; }

JNB FLAGS.1,Continue

SendSTALL: ; Hem rebut una petició incorrecta; Al igual que Acknowledge_Setup ho fem en els dos punters de; l'EndPoint

MOV A,#40H ; Set_Status(EP0Out) commandCALL D12commandMOV A,#00000001b ; Fem un STALL del EndpointCALL D12writeMOV A,#41H ; Set_Status(EP0In) commandCALL D12commandMOV A,#00000001b ; Fem un STALL del EndpointJMP D12write ; RETurn a través del D12write

Continue:JNB FLAGS.2,HandShake ; No hem d'enviar info. però responem

; amb HandShakeJNB FLAGS.3,SendReplyBuffer ; No enviem un Descriptor com a

; resposta

; En aquest punt sabem que hem de respondre enviant una taula; descriptora de llargada A i amb inici on apunta el DPTR; Enviem els 16 primers bytes que el componen:

MOV R7,A ; Sempre que entrem aquí tenim el núm.; total de bytes del descritor en el; ACC (SaveLength)

; Hem de comparar "Requested Length" amb "Actual Length" i; enviar el menor dels dos.; Si "Requested Length" > 255 llavors enviem "Actual Length"; ja que no tenim descriptors > 255 en el nostre cas

MOV A,wLengthHighJNZ UsarActualMOV A,R7 ; Recuperem la llargada de la taulaCLR CSUBB A,wLengthLowMOV A,wLengthLow ; Aquesta operació o afecta al bit de

; CarryJNC UsarwLengthLow ; Depenent de quin sigui més gran

; deixem valor que ja tenim carregat o; el canviem


Pàg. 114

UsarActual:MOV A,R7 ; En el supòsit que no hàgim saltat,

; indica que ACC es menor i enviarem ;; aquest valor

UsarwLengthLow:SendNextPieceOfDescriptor: ; DPTR -> Apunta a l’informació a

; enviar

MOV R7,A ; Copiem en el registre temporal bytes; a enviar

MOV SaveLength,#0 ; Per defecte marquem tot enviat, sinó; ja ho canviarem

; Tenim mes bytes a enviar que els que podem enviar en l'EP0 ?CLR CSUBB A,#EP0SizeJC SendPacketToD12

; Hem de partir l'informació per a enviar-la en varies; transmissions.; Calculem la posició del DPTR del següent paquet i enviem el; 16 primers bytes

MOV SaveLength,A ; Enviarem els següents bytes desprésMOV R7,#EP0SizePUSH DPH ; Guardem la posició actual del DPTRPUSH DPLMOV A,R7CALL BumpDPTR ; Calculem on apuntarà el següent DPTRMOV SaveDPH,DPH ; i en guardem l'informacióMOV SaveDPL,DPLPOP DPL ; Restaurem la posició actual delPOP DPH ; punter

SendPacketToD12: ; Carreguem el paquet al buffer per; enviar al D12

MOV A,R7 ; Recuperem la llargada

SP2:MOV R0,#ReplyCount ; Apuntem al primer byte del buffer de

; respostaMOV @R0,A ; El segon byte a carregar es sempre la

; llargadaJZ SendReplyBuffer ; Cas especial = paquet llargada 0

; (HandShake)


Pàg. 115

CopySTD:INC R0 ; Apuntem als bytes del buffer deCLR A ; resposta on van les dadesMOVC A,@A+DPTR ; En llegim el contingut de la memòria

; de programaMOV @R0,A ; Copiem al buffer de respostaINC DPTRDJNZ R7,CopySTD

SendReplyBuffer: ; Enviem el contingut del buffer de; resposta

MOV A,#F0H ; Write_Buffer commandCALL D12commandCLR A ; Primer byte a enviar en el D12 es 0CALL D12write ; ja que aquest es un valor reservatMOV R0,#ReplyCount ; Apuntem al primer byte del buffer de

; respostaMOV A,@R0CALL D12write ; El segon byte a enviar és el número

; de bytes a enviarJZ ValidateBuffer ; Cas especial = paquet llargada 0

; (HandShake)MOV R7,A ; Salvem el valor per a fer una roda

CopyRB:INC R0 ; Apuntem al buffer de respostaMOV A,@R0CALL D12write ; Enviem l'informacióDJNZ R7,CopyRB

ValidateBuffer: ; Fem que el D12 validi el buffer i; l’enviï

MOV A,#FAH ; Validate_Buffer commandCALL D12command ; Quedem en espera del següent paquet.RET

HandShake: ; Handshake amb el HCCLR A ; Enviem un paquet de llargada 0JMP SP2 ; SendPacketToD12 (despres de fer un

; MOV A, R7)

SendReport: ; Enviem les dades entrades perl'usuari

; Seleccionem EP i enviem info.MOV A,#43H ; Set_Status(EP1In)CALL D12commandCLR A ; Escrivim un 0 així l'endpoint es

; reinicialitzaCALL D12writeMOV A,#03H ; Select_EndPoint(EP1In) pera resposta

CALL D12commandMOV A,#F0H ; Write_Buffer command


Pàg. 116

CALL D12commandCLR A ; Primer byte a enviar en el D12 es 0CALL D12write ; ja que aquest es un valor reservatMOV A,#01HCALL D12write ; Segon byte a enviar és el número de

; bytes a enviarMOV A,ValorBotonsCALL D12write ; Enviem l'informacióMOV A,#FAH ; Validate_Buffer commandCALL D12command ; D12 will respond to the next IN tokenRET


Pàg. 117

;-----------------------------------------------------------; Aquest apartat es la subrutina a les peticions de comandes de; control;-----------------------------------------------------------

ServiceSetupPacket:MOV A,RequestTypeMOV C,ACC.7 ; Bit 7 = 1 indica que el HC espera

; rebre informacióMOV FLAGS.2,C ; Ho indiquem al Flag corresponentANL A,#01011100b ; Si RequestType[6.4.3.2] = 1 llavors

; CodiDolentJNZ BadRequestMOV A,RequestType ; Si RequestType[1&0] = 1 llavors

; CodiDolentMOV C,ACC.0ANL C,ACC.1JC BadRequestJNB ACC.5,NotB5 ; Si RequestType[5] = 1 llavors

; RequestType[1,0] = [1,1]MOV A,#00000011b

NotB5:ANL A,#00000011b ; CommandIndex[5,4] = RequestType[1,0]SWAP AMOV R7,A ; Passem l’info al nivell alt i guardem

; temporalmentMOV A,RequestANL A,#11110000b ; Comp. que el valor sigui menor a 15JNZ BadRequest ; sinó ho fos tindríem un error ja que

; no definit.MOV A,RequestANL A,#00001111b ; Sol mirem quatre bits de menys pesORL A,R7 ; Restaurem l'informació

; Resetegem l'informació per a preparar les respostes

MOV ReplyCount,#1 ; Establim una resposta per defecteMOV ReplyBuffer,#0MOV ReplyBuffer+1,#0CLR FLAGS.4 ; Resetegem tots els flags pertinentsCLR FLAGS.1CLR FLAGS.3

; Saltem a la subrutina a que apunta el punter que hem creat

MOV DPTR,#CommandTableCALL BumpDPTR ; Apuntem a la resposta correctaCLR AMOVC A,@A+DPTR ; Obtenim l'offset principi l'aplicacióMOV DPTR,#SubrutinesJMP @A+DPTR ; Executem la subrutina correcta


Pàg. 118

BadRequest: ; El resultat de l'informació dona; una subrutina incorrecta, fem un

STALL; de l'Endpoint

SETB FLAGS.1RET

; Rutines de suport en els càlculs anteriors

NextDPTR: ; Retorna (DPTR+byte on apunta el DPTR)CLR AMOVC A,@A+DPTR

BumpDPTR: ; Retorna (DPTR + ACC)ADD A,DPLMOV DPL,AJNC SkipINC DPH ; Aritmètica de 16 bits

Skip: RET


Pàg. 119

;-----------------------------------------------------------; Aquest apartat es la subrutina a les peticions de comandes decontrol;-----------------------------------------------------------

CommandTable:

; Les primeres 16 comandes son per al DeviceDB (Dev_Get_Status-Subrutines).mod.256DB (Dev_Clear_Feature-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Dev_Set_Feature-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Set_Address-Subrutines).mod.256DB (Get_Descriptor-Subrutines).mod.256DB (Set_Descriptor-Subrutines).mod.256DB (Get_Configuration-Subrutines).mod.256DB (Set_Configuration-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256

; Les 16 comandes següents son per al InterfaceDB (Inter_Get_Status-Subrutines).mod.256DB (Inter_Clear_Feature-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Inter_Set_Feature-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Get_Class_Descriptor-Subrutines).mod.256DB (Set_Class_Descriptor-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Get_Interface-Subrutines).mod.256DB (Set_Interface-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256


Pàg. 120

; Les 16 comandes següents son per al EndpointDB (Ep_Get_Status-Subrutines).mod.256DB (Ep_Clear_Feature-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Ep_Set_Feature-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Ep_Sync_Frame-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256

; Les 16 comondes següents son per específiques de la classeDB (Invalid-Subrutines).mod.256DB (Get_Report-Subrutines).mod.256DB (Get_Idle-Subrutines).mod.256DB (Get_Protocol-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Set_Report-Subrutines).mod.256DB (Set_Idle-Subrutines).mod.256DB (Set_Protocol-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256DB (Invalid-Subrutines).mod.256


Pàg. 121

;-----------------------------------------------------------; Subrutines;-----------------------------------------------------------;; Algunes de les peticions no tenen sentit en aquest projecte; de totes maneres formen part de la taula.;; Aquestes són les següents:;-----------------------------------------------------------

Subrutines:Get_Protocol: ; No som un dispositiu de BOOTGet_Idle: ; Comanda opcional, no suportadaGet_Interface: ; No variem els nostres DescriptorsSet_Protocol: ; No som un dispositiu de BOOTSet_Idle: ; Comanda opcional, no suportadaSet_Interface: ; Només tenim un InterfaceSet_Descriptor: ; No variem els nostres DescriptorsSet_Class_Descriptor: ; No variem els nostres DescriptorsDev_Set_Feature: ; No tenim cap valor que es pugui

; establir o borrarDev_Clear_Feature: ; No tenim cap valor que es pugui

; establir o borrarInter_Set_Feature: ; No tenim cap valor que es pugui

; establir o borrarInter_Clear_Feature: ; No tenim cap valor que es pugui

; establir o borrarEp_Set_Feature: ; No tenim cap valor que es pugui

; establir o borrarEp_Sync_Frame: ; No som un dispositiu Isonchronous

Invalid: ; Petició no soportada, fem un STALLSETB FLAGS.1

Reply:RET


Pàg. 122

;-----------------------------------------------------------;; La resta de les rutines tenen una funció concreta i tot seguit; les implementem.;;-----------------------------------------------------------

Set_Address: ; Rebem la nova adreça que ens atorga; el HC

; S'ha de notar que el D12 no modificarà l'adreça del disp.; fins que no hagi enviat el handshake packet. L'adreça s'ha; d'escriure abans del handshake

MOV A,#D0H ; Set_Address commandCALL D12commandMOV A,wValueLow ; Byte del Setup Packet on hi ha la

; nova adreçaSETB ACC.7 ; Set address i habilitar el dispositiuCALL D12writeMOV A,#D8H ; Enable_Endpoints commandCALL D12commandMOV A,#01H ; Habilitem els Endpoints que no son de

; controlCALL D12write

; Re-configurem l'informació restant del D12

MOV A,#FBH ; Set_DMA mode commandCALL D12commandMOV A,#00100000b ; Habilitem l'int generada pel SOFCALL D12writeRET ; Finalitzem l'instrucció fent un

; HandShake mitjançant el FLAGS.2 (si 0; HS)

Get_Report: ; El HC ens demana un report. Aquesta; comanda, tot i les seves posibilitats; es utilitzada solament de forma molt; esporàdica principalment per a; configuracions.

JNB FLAGS.0,Invalid ; Hem d'estar configurats prèviamentMOV A,ValorBotonsMOV ReplyBuffer,A ; Retornem un valor qualsevol conegutRET


Pàg. 123

Get_Descriptor: ; El HC sol·licita informació sobre el; dispositiu

SETB FLAGS.3MOV A,wValueHighDEC A ; Son valors vàlids 1, 2 i 3MOV DPTR,#DeviceDescriptor; Apuntem a l’informació sol·licitadaJZ ReturnLength ; i retornariem amb aquesta funcióDEC AMOV DPTR,#ConfigurationDescriptorJNZ TryStringMOV A,#22H ; Suma directa dels bytes de les taules

; descriptoresRET ; Guardaríem la llargada i retornaríem

; si demana aquest

; Si no ens demana cap de les anteriors, ens sol·liciten un; String Descriptor

TryString:DEC AJNZ InvalidMOV DPTR,#String0 ; Apuntem a l'String 0MOV A,wValueLow ; Recuperem l'String Index

NextString:JZ ReturnLengthMOV R7,A ; Salvem l'String Index en un registre

; temporalCALL NextDPTR ; Retorna DPTR+@DPTRCLR AMOVC A,@A+DPTR ; Mirem l'S.Length (= 0 at Backstop)JZ Invalid ; Ens demanen una cadena que no tenimMOV A,R7DEC AJMP NextString ; Controlar si ja el tenim

Get_Class_Descriptor: ; Son valors vàlids 21H, 22H, 23H pel; Class Request

SETB FLAGS.3 ; Indiquem que la resposta es un; Descriptor

MOV A,wValueHighCLR CSUBB A,#21H ; Responem amb Descriptor equivalent a

; cada valorMOV DPTR,#HIDDescriptor ; segons les especificacions del

; Estàndard USBJZ ReturnLengthDEC AMOV DPTR,#ReportDescriptorJZ ReturnRDlength ; Tenim una forma diferent per a mirar

; aquesta llargada

; En el nostre cas no usem els Physical Descriptors

JMP Invalid


Pàg. 124

; Implementem tot seguit dos subrutines de suport per a obtenir; les llargades de les taules anteriors ja que es necessiten; anteriorment

ReturnLength:

CLR A ; El primer byte en la majoria dels; descriptors es la

MOVC A,@A+DPTR ; llargada del mateix o Desc. LengthRET

ReturnRDlength: ; Report Desc. té un format diferentMOV A,#1CH ; Suma directa dels bytes de les taules

; descriptoresRET

Set_Configuration: ; Valors possibles son 0 o 1MOV A,wValueLow ; en funció de si el dispositiu haJZ Desconfigurat ; d'estar configurat o noDEC AJNZ InvalidSETB FLAGS.0MOV CurrentConf,#1 ; Guardem a la variable de configuració

; el nou valorRET

Desconfigurat:CLR FLAGS.0MOV CurrentConf,ARET

Set_Report: ; El HC ens envia un Report.

; Aquest és l’únic cas en que el HC ens envia informació en; aquest exemple; Ens arriba com a paquet de dades després de rebre un Setup; Packet

JNB FLAGS.0,Invalid ; Hem d'estar configurats prèviamentCLR EX1 ; Deshabilitem l'interrupció

Wait4D:MOV A,#F4H ; Read_Interrupt_Register commandCALL D12GetStatusJNB ACC.0,Wait4D ; Esperem a rebre un Data PacketMOV A,#40H ; Read_Last_Transaction_Status_Register

; commandCALL D12GetStatusSETB EX1 ; Tornem a habilitar l'interrupció

; L’estàndard USB ens exigeix que es pugui interrompre sempre; un envio de dades si es tracta d'executar un SetupPacket. Per; aquest motiu verifiquem que el que acabem de rebre no ho; sigui.

JNB A.5,ContJMP SetupP


Pàg. 125

Cont:CLR A ; Select_Endpoint(EP0Out) commandCALL D12commandMOV A,#F0H ; Read_Buffer commandCALL D12commandCALL D12read ; 1er byte a llegir, 0 per defecteCALL D12read ; 2on byte, núm de bytes a rebre (=1)CALL D12read ; Llegim finalment la dada que ens

; interessa

; Un cop ja hem rebut l'informació la manipulem per a poder; mostrar-la en el nostre dispositiu.

MOV R7,A ; Fem copia del valor rebutMOV A,#FFH ; N'invertim el contingut, si hem

; d'encendre el LedXRL A,R7 ; hem de posar a 0 el bit del portORL A,#11110000b ; Màscara per conservar el bits de lectMOV ValorLed,A ; Guardem l'info. rebudaMOV P1,A ; Escrivim l'info. en el port

; Un cop ja hem rebut la dada hem d'enviar un HanShake per; l'EndPoint correcte per a que el HC en sigui conscient.

MOV A,#01H ; Select_EndPoint(ControlOut) per a la; resposta

CALL D12command

; Un cop fet això tenim el D12 preparat per a continuar rebent; i enviant informacióRET ; Retornem i al sortir fem el HS.

Dev_Get_Status: ; Només hi ha dos bits definits en; l'estatus; Bit 1=Remote Wakeup(=0), Bit 0=Self; Powered(=1)

Inter_Get_Status: ; L'estatus actual està difinit com 0Ep_Get_Status: ; L'estatus actual està difinit com 0

; sino STALLMOV ReplyCount,#2 ; Necessitem una resposta de 2 bytes

; que seran sempre 0RET


Pàg. 126

Get_Configuration: ; Responem enviant el valor de la; configuració actual

MOV ReplyBuffer,CurrentConf ; que guardem a la variable de; configuració

RET

Ep_Clear_Feature: ; Fem un DesSTALL de l'endpointMOV A,#43H ; Set_Status(EP1In)CALL D12commandCLR A ; Escrivim un 0 així l'endpoint es

; reinicialitzaCALL D12writeMOV A,#01H ; Select_EndPoint(ControlOut) per a la

; respostaCALL D12command

; Un cop fet això tenim el D12 preparat per a rebre i enviar; informació.; Per a fer-ho deixem seleccionat l' EP0In

RET


Pàg. 127

;-----------------------------------------------------------; Aquest mòdul declare els descriptors;; Aquí hi podem trobar un Device Descriptor amb:; Un Configuration Descriptor - un port d'entrada i un de sortida; Un Interface Descriptor - hi ha un sol mètode per accedir als; ports; Un HID Descriptor - per a simplificar el software en el PC; Un Endpoint Descriptor - Per als Reports HID; Un Report Descriptor - un byte d'entrada i un de sortida; Varios Sting Descriptors - per ajudar a l'usuari;-----------------------------------------------------------

DeviceDescriptor:.DB 12H ; Length.DB 01H ; Type.DB 10H,01H ; USB Rev 1.1.DB 00H ; Class code.DB 00H ; Subclass code.DB 00H ; Protocol code.DB EP0Size ; EP0 size.DB 11H,11H ; Vendor ID.DB 22H,22H ; Product ID.DB 01H,00H ; Version.DB 01H,02H,00H ; Cadenes del Manufacturer,

; Product & Serial#.DB 01H ; #Configs

EndDeviceDescriptor:

ConfigurationDescriptor:.DB 09H ; Length.DB 02H ; Type.DB 22H,00H ; Total length (34 bytes).DB 01H,01H,00H ; #Interfaces, Configuration#,

; Config. Name.DB 80H ; Attributes = Bus Powered.DB 32H ; Max. Power is 50x2 = 100mA

EndConfigurationDescriptor:

InterfaceDescriptor:.DB 09H ; Length.DB 04H ; Type.DB 00H,00H,01H ; No hi ha alternativa, HID fa

; servir EP1.DB 03H ; Class = Human Interface Device.DB 00H,00H ; Subclass i Protocol.DB 00H ; Interface Name

EndInterfaceDescriptor:


Pàg. 128

HIDDescriptor:.DB 09H ; Length.DB 21H ; Type.DB 00H,01H ; HID Class Specification

compliance.DB 00H ; Country (ningun).DB 01h ; Número de descriptors que

; segueixen.DB 22H ; Es un Report descriptor.DB 1CH,00H ; Número de bytes que el componen

EndHIDDescriptor:

EndpointDescriptor:.DB 07H ; Length.DB 05H ; Type.DB 81H ; Address = IN 1.DB 03H ; Interrupt.DB EP0Size,00H ; Maximum packet size.DB 64H ; Mostreig cada 0.1 seconds

EndEndpointDescriptor:

ReportDescriptor: ; Creat amb HID Tool.DB 06H,00H,FFH ; Usage_Page (Vendor Defined).DB 09H,01H ; Usage (I/O Device).DB A1H,01H ; Collection (Application).DB 19H,01H ; Usage_Minimum (Button 1).DB 29H,08H ; Usage_Maximum (Button 8).DB 15H,00H ; Logical_Minimum (0).DB 25H,01H ; Logical_Maximum (1).DB 75H,01H ; Report_Size (1).DB 95H,08H ; Report_Count (8).DB 81H,02H ; Input (Data,Var,Abs).DB 19H,01H ; Usage_Minimum (Led 1).DB 29H,08H ; Usage_Maximum (Led 8).DB 91H,02H ; Output (Data,Var,Abs).DB C0H ; End_Collection

EndReportDescriptor:


Pàg. 129

String0: ; Declare the UNICODE strings.DB 04H ; Length.DB 03H ; Type (3=String).DB 09H ; Language : English.DB 04H ; Sub-language : US

String1: ; Manufacturer.DB 22H,03H ; Llargada, Type.DB "P",0,"r",0,"o",0,"d",0,"u",0,"i",0,"t",0," ",0.DB "a",0," ",0,"l",0,"a",0," ",0,"U",0,"R",0,"V",0

String2: ; Product Name.DB 1EH,03H ; Length, Type.DB "D",0,"i",0,"s",0,"s",0,"e",0,"n",0,"y",0," ",0.DB "d",0,"e",0," ",0,"J",0,"S",0,"P",0

EndOfDescriptors:.DW 0 ; Final de les enumeracions de cadenes

.END


Pàg. 130

2.4. Configuració del dispositiu segons el nostre sistema operatiu

És el moment ja d’entrar en les necessitats del sistema operatiu. En aquest cas elque hem de fer és una mica més senzill, tan sols hem de explicar el contingut del’arxiu d’extensió INF. El funcionament d’aquest és necessari en els sistemesoperatius de Windows 98 i en el nostre cas en creem un per a la correctaconfiguració del nostre perifèric el primer cop que aquest es connecta al sistema.En les següents vegades que connectem el dispositiu, el sistema operatiu seràcapaç de reconèixer-lo gràcies a les taules emmagatzemades en les bases de dadesdel propi sistema.

L’enumeració següent és el contingut de l’arxiu periferic.inf que hem creat basant-nos en el propi del sistema hiddev.inf que es pot trobar en tots els ordenadors ambsistema operatiu Windows98 o superior en la carpeta \\WINDOWS\INF i quetambé carregaria els drivers necessaris per a la correcta configuració ifuncionament del nostre dispositiu.


Pàg. 131

[Version]Signature="$CHICAGO$"Class=HIDClassGUID={745a17a0-74d3-11d0-b6fe-00a0c90f57da}provider=%Provider%LayoutFile=layout.inf, layout1.inf

[ClassInstall]Addreg=Class.AddReg

[Class.AddReg]HKR,,Icon,,"-1"HKR,,Installer,,mmci.dll

[Manufacturer]%MfgName%=Projecte

[Projecte];Vendor ID 1111;Product ID 2222%USB\VID_1111&PID_2222.DeviceDesc%=SampleHID, USB\VID_1111&PID_2222

[DestinationDirs]SampleHID.CopyList = 11

[SampleHID]CopyFiles=SampleHID.CopyListAddReg=SampleHID.AddReg

[SampleHID.AddReg]HKR,,DevLoader,,*ntkernHKR,,NTMPDriver,,"hidusb.sys"

[SampleHID.CopyList]hidusb.syshidclass.syshidparse.sys

[Strings]Provider="Jaume Sole"MfgName="URV"USB\VID_1111&PID_2222.DeviceDesc="Perifèric bàsic USB"


Pàg. 132

2.5. Aplicació software executada en el Master

Finalment, per acabar amb la memòria de càlcul entrarem en més detall enl’aplicació que s’executarà en l’ordenador. També n’hem vist el funcionament enla memòria descriptiva però és ara el moment d’entrar en detall i entendren elcodi.

2.5.1. Crides a funcions

El que farem primerament és veure en detall les crides a funcions que utilitzem enla nostra aplicació i ho farem incloent en aquest apartat, degut a la sevaimportància, la descripció que la pròpia llibreria MSDN ens dona de les APIs.Recordem-ne però primer la llista vista anteriorment:

Funció API DLL Finalitat

HidD_GetHidGuid hid.dll Detecta la presencia d’elements d’una classe en concret

SetupDiGetClassDevs setupapi.dll Retorna informació sobre tots els elements de la classe

SetupDiEnumDeviceInterface setupapi.dll Retorna informació d’un dispositiu concret

SetupDiGetDevice InterfaceDetail setupapi.dll Retorna el del dispositiu determinat

CreateFile kernel32.dll Obre la comunicació amb el dispositiu

HidD_GetAttributes hid.dllRetorna informació emmagatzemada en les taulesdescriptores

HidD_GetPreparsedData hid.dll Retorna informació sobre el buffer del dispositiu

HidD_GetCaps hid.dll Retorna informació sobre les utilitats del dispositiu

HidD_GetValueCaps hid.dll Retorna una estructura amb valors sobre el dispositiu

HidD_GetButtonCaps hid.dll Retorna una estructura amb valors sobre el controls del disp.

WriteFile kernel32.dll Envia informació al dispositiu

ReadFile kernel32.dll Llegeix informació al dispositiu

CloseHandle kernel32.dll Allibera recursos creats per CreateFile

SetupDiDestroyDeviceInfoList setupapi.dll Allibera recursos creats per SetupDiGetClassDevs

HidD_FreePreparsedData hid.dll Allibera recursos creats per HidD_GetPreparsedData


Pàg. 133

HidD_GetHidGuid

VOID HidD_GetHidGuid( OUT LPGUID HidGuid );

HidD_GetHidGuid returns the GUID associated with HID devices.

ParametersHidGuidPoints to a variable to hold the GUID that is associated with all HIDdevices.CommentsOnly user mode clients can call HidD_GetHidGuid.


Pàg. 134

SetupDiGetClassDevs

HDEVINFO SetupDiGetClassDevs( IN PGUID ClassGuid, /* optional */ IN PCTSTR Enumerator, /* optional */ IN HWND hwndParent, /* optional */ IN DWORD Flags );

SetupDiGetClassDevs returns a device information set that containsall installed devices of a specified class.

ParametersClassGuidSupplies a pointer to the class GUID to use when creating the list ofdevices. If the DIGCF_ALLCLASSES flag is set, this parameter isignored and the resulting list contains all installed classes.

EnumeratorSupplies the name of the key under the Enum registry branch thatcontains device instances for which information is to be retrieved.If this parameter is not specified, device information is retrievedfor all device instances in the entire Enum tree.

hwndParentSupplies the handle of the top-level window to be used for any userinterface relating to the members of this set.

FlagsSupplies control options used in building the device information set.Can be one of the following values:DIGCF_PRESENTReturn only devices that are currently present.

DIGCF_ALLCLASSESReturn a list of installed devices for all classes. If this flag isset, the ClassGuid parameter is ignored.

DIGCF_PROFILEReturn only devices that are a part of the current hardware profile.Return ValueIf the function succeeds, it returns a handle to a device informationset containing all installed devices matching the specifiedparameters.

If the function fails, it returns INVALID_HANDLE_VALUE. To getextended error information, call GetLastError.


Pàg. 135

SetupDiEnumDeviceInterfaces

The SetupDiEnumDeviceInterfaces function returns a context structurefor a device interface of a device information set. Each call returnsinformation about one device interface. The function can be calledrepeatedly to get information about several interfaces exposed by oneor more devices.

BOOL SetupDiEnumDeviceInterfaces( HDEVINFO DeviceInfoSet, PSP_DEVINFO_DATA DeviceInfoData, CONST LPGUID InterfaceClassGuid, DWORD MemberIndex, PSP_DEVICE_INTERFACE_DATA DeviceInterfaceData);ParametersDeviceInfoSet[in] Pointer to a device information set containing the devices forwhich to return interface information. This handle is typicallyreturned by the SetupDiGetClassDevs or SetupDiGetClassDevsExfunction.DeviceInfoData[in] An optional pointer to an SP_DEVINFO_DATA structure thatconstrains the search for interfaces to those of just one device inthe device information set.InterfaceClassGuid[in] Pointer to a GUID that specifies the device interface class forthe requested interface.MemberIndex[in] Specifies a zero-based index to the list of interfaces in thedevice information set. You should first call this function with theMemberIndex parameter set to zero to obtain the first interface.Then, repeatedly increment MemberIndex and retrieve an interfaceuntil this function fails and GetLastError returnsERROR_NO_MORE_ITEMS.If the DeviceInfoData parameter specifies a particular device,MemberIndex applies only to the interfaces exposed by that device.

DeviceInterfaceData[out] Pointer to a buffer that contains, on successful return, acompleted SP_DEVICE_INTERFACE_DATA structure that identifies aninterface that meets the search parameters. You must set the cbSizemember to sizeof(SP_DEVICE_INTERFACE_DATA) before calling thisfunction.Return ValuesIf the function succeeds, the return value is nonzero.

If the function fails, the return value is zero. To get extendederror information, call GetLastError.


Pàg. 136

RemarksThe DeviceInterfaceData member is a pointer to a structure thatidentifies a requested device interface. To get detailed informationabout an interface, call the SetupDiGetDeviceInterfaceDetailfunction. The detailed information includes the name of the deviceinterface that can be passed to a function (such as CreateFile) toget a handle to the interface.

Requirements Windows NT/2000: Requires Windows 2000. Windows 95/98: Requires Windows 98. Header: Declared in Setupapi.h. Library: Use Setupapi.lib.


Pàg. 137

SetupDiGetDeviceInterfaceDetail

The SetupDiGetDeviceInterfaceDetail function returns detailedinformation about a specified device interface.

BOOL SetupDiGetDeviceInterfaceDetail( HDEVINFO DeviceInfoSet, PSP_DEVICE_INTERFACE_DATA DeviceInterfaceData, PSP_DEVICE_INTERFACE_DETAIL_DATA DeviceInterfaceDetailData, DWORD DeviceInterfaceDetailDataSize, PDWORD RequiredSize, PSP_DEVINFO_DATA DeviceInfoData);ParametersDeviceInfoSet[in] Pointer to the device information set that contains theinterface and its underlying device. This handle is typicallyreturned by the SetupDiGetClassDevs or SetupDiGetClassDevsExfunction.DeviceInterfaceData[in] Pointer to an SP_DEVICE_INTERFACE_DATA structure that identifiesthe interface. This structure is typically returned by theSetupDiEnumDeviceInterfaces function.DeviceInterfaceDetailData[out] An optional pointer to a SP_DEVICE_INTERFACE_DETAIL_DATAstructure to receive information about the specified interface. Youmust set the cbSize member to sizeof(SP_DEVICE_INTERFACE_DETAIL_DATA)before calling this function. The cbSize member always contains thesize of the fixed part of the data structure, not a size reflectingthe variable-length string at the end.This parameter must be NULL if the DeviceInterfaceDetailSizeparameter is zero.

DeviceInterfaceDetailDataSize[in] Specifies the size of the DeviceInterfaceDetailData buffer. Thebuffer must be at least (offsetof(SP_DEVICE_INTERFACE_DETAIL_DATA,DevicePath) + sizeof(TCHAR)) bytes, to contain the fixed part of thestructure and a single NULL character to terminate an empty MULTI_SZstring.This parameter must be zero if DeviceInterfaceDetailData is NULL.

RequiredSize[out] An optional pointer to a variable to receive the required sizeof the DeviceInterfaceDetailData buffer. This size includes the sizeof the fixed part of the structure plus the number of bytes requiredfor the variable-length device path string.DeviceInfoData[out] An optional pointer to an SP_DEVINFO_DATA structure to receiveinformation about the device that exposes the requested interface.You must set the cbSize member to sizeof(SP_DEVINFO_DATA).Return ValuesIf the function succeeds, the return value is nonzero.



Pàg. 138

RemarksUsing the SetupDiGetDeviceInterfaceDetail function to get detailsabout an interface is typically a two-step process:

Get the required buffer size. Call SetupDiGetDeviceInterfaceDetailwith a NULL DeviceInterfaceDetailData pointer, aDeviceInterfaceDetailDataSize of zero, and a valid RequiredSizevariable. In response to such a call, this function fails,GetLastError returns ERROR_INSUFFICIENT_BUFFER, and the RequiredSizeparameter receives the required buffer size.Allocate an appropriately sized buffer and call the function again toget the interface details.The interface details returned by this function include a device paththat can be passed to Win32 functions such as CreateFile. Do notattempt to parse the device path symbolic name. Note that the devicepath can be reused after the system is rebooted.

The SetupDiGetDeviceInterfaceDetail function can be used to get onlythe DeviceInfoData parameter. If the interface exists but theDeviceInterfaceDetailData parameter is NULL, the function fails,GetLastError returns ERROR_INSUFFICIENT_BUFFER, and theDeviceInfoData structure is filled with information about the devicethat exposes the interface.

Requirements Windows NT/2000: Requires Windows 2000. Windows 95/98: Requires Windows 98. Header: Declared in Setupapi.h. Library: Use Setupapi.lib.


Pàg. 139

CreateFile

The CreateFile function creates or opens the following objects andreturns a handle that can be used to access the object:

ConsolesCommunications resourcesDirectories (open only)Disk devices (Windows NT/2000 only)FilesMailslotsPipesHANDLE CreateFile( LPCTSTR lpFileName, // file name DWORD dwDesiredAccess, // access mode DWORD dwShareMode, // share mode LPSECURITY_ATTRIBUTES lpSecurityAttributes, // SD DWORD dwCreationDisposition, // how to create DWORD dwFlagsAndAttributes, // file attributes HANDLE hTemplateFile // handle to templatefile);ParameterslpFileName[in] Pointer to a null-terminated string that specifies the name ofthe object to create or open.Windows NT/2000: In the ANSI version of this function, the name islimited to MAX_PATH characters. To extend this limit to nearly 32,000wide characters, call the Unicode version of the function and prepend"\\?\" to the path. For more information, see File Name Conventions.

Windows 95/98: This string must not exceed MAX_PATH characters.

dwDesiredAccess[in] Specifies the type of access to the object. An application canobtain read access, write access, read/write access, or device queryaccess. This parameter can be any combination of the followingvalues. Value Meaning0 Specifies device query access to the object. An application canquery device attributes without accessing the device.GENERIC_READ Specifies read access to the object. Data can be readfrom the file and the file pointer can be moved. Combine withGENERIC_WRITE for read/write access.GENERIC_WRITE Specifies write access to the object. Data can bewritten to the file and the file pointer can be moved. Combine withGENERIC_READ for read/write access.


Pàg. 140

In addition, you can specify the following access flags. ValueDocumentedDELETE Standard Access RightsREAD_CONTROL Standard Access RightsWRITE_DAC Standard Access RightsWRITE_OWNER Standard Access RightsSYNCHRONIZE Standard Access RightsSTANDARD_RIGHTS_REQUIRED Standard Access RightsSTANDARD_RIGHTS_READ Standard Access RightsSTANDARD_RIGHTS_WRITE Standard Access RightsSTANDARD_RIGHTS_EXECUTE Standard Access RightsSTANDARD_RIGHTS_ALL Standard Access RightsSPECIFIC_RIGHTS_ALL ACCESS_MASKACCESS_SYSTEM_SECURITY ACCESS_MASKMAXIMUM_ALLOWED ACCESS_MASKGENERIC_READ ACCESS_MASKGENERIC_WRITE ACCESS_MASKGENERIC_EXECUTE ACCESS_MASKGENERIC_ALL ACCESS_MASK

dwShareMode[in] Specifies how the object can be shared. If dwShareMode is 0, theobject cannot be shared. Subsequent open operations on the objectwill fail, until the handle is closed.To share the object, use a combination of one or more of thefollowing values. Value MeaningFILE_SHARE_DELETE Windows NT/2000: Subsequent open operations on theobject will succeed only if delete access is requested.FILE_SHARE_READ Subsequent open operations on the object will succeedonly if read access is requested.FILE_SHARE_WRITE Subsequent open operations on the object willsucceed only if write access is requested.

lpSecurityAttributes[in] Pointer to a SECURITY_ATTRIBUTES structure that determineswhether the returned handle can be inherited by child processes. IflpSecurityAttributes is NULL, the handle cannot be inherited.Windows NT/2000: The lpSecurityDescriptor member of the structurespecifies a security descriptor for the object. IflpSecurityAttributes is NULL, the object gets a default securitydescriptor. The target file system must support security on files anddirectories for this parameter to have an effect on files.

dwCreationDisposition[in] Specifies which action to take on files that exist, and whichaction to take when files do not exist. For more information aboutthis parameter, see the Remarks section. This parameter must be oneof the following values. Value MeaningCREATE_NEW Creates a new file. The function fails if the specifiedfile already exists.


Pàg. 141

CREATE_ALWAYS Creates a new file. If the file exists, the functionoverwrites the file and clears the existing attributes.OPEN_EXISTING Opens the file. The function fails if the file does notexist.For a discussion of why you should use the OPEN_EXISTING flag if youare using the CreateFile function for devices, see Remarks.

OPEN_ALWAYS Opens the file, if it exists. If the file does not exist,the function creates the file as if dwCreationDisposition wereCREATE_NEW.TRUNCATE_EXISTING Opens the file. Once opened, the file is truncatedso that its size is zero bytes. The calling process must open thefile with at least GENERIC_WRITE access. The function fails if thefile does not exist.

dwFlagsAndAttributes[in] Specifies the file attributes and flags for the file.Any combination of the following attributes is acceptable for thedwFlagsAndAttributes parameter, except all other file attributesoverride FILE_ATTRIBUTE_NORMAL. Attribute MeaningFILE_ATTRIBUTE_ARCHIVE The file should be archived. Applications usethis attribute to mark files for backup or removal.FILE_ATTRIBUTE_ENCRYPTED The file or directory is encrypted. For afile, this means that all data in the file is encrypted. For adirectory, this means that encryption is the default for newlycreated files and subdirectories.This flag has no effect if FILE_ATTRIBUTE_SYSTEM is also specified.

FILE_ATTRIBUTE_HIDDEN The file is hidden. It is not to be included inan ordinary directory listing.FILE_ATTRIBUTE_NORMAL The file has no other attributes set. Thisattribute is valid only if used alone.FILE_ATTRIBUTE_NOT_CONTENT_INDEXED The file will not be indexed bythe content indexing service.FILE_ATTRIBUTE_OFFLINE The data of the file is not immediatelyavailable. This attribute indicates that the file data has beenphysically moved to offline storage. This attribute is used by RemoteStorage, the hierarchical storage management software in Windows2000. Applications should not arbitrarily change this attribute.FILE_ATTRIBUTE_READONLY The file is read only. Applications can readthe file but cannot write to it or delete it.FILE_ATTRIBUTE_SYSTEM The file is part of or is used exclusively bythe operating system.FILE_ATTRIBUTE_TEMPORARY The file is being used for temporarystorage. File systems attempt to keep all of the data in memory forquicker access rather than flushing the data back to mass storage. Atemporary file should be deleted by the application as soon as it isno longer needed.


Pàg. 142

Any combination of the following flags is acceptable for thedwFlagsAndAttributes parameter. Flag MeaningFILE_FLAG_WRITE_THROUGH Instructs the system to write through anyintermediate cache and go directly to disk. The system can stillcache write operations, but cannot lazily flush them.FILE_FLAG_OVERLAPPED Instructs the system to initialize the object,so that operations that take a significant amount of time to processreturn ERROR_IO_PENDING. When the operation is finished, thespecified event is set to the signaled state.When you specify FILE_FLAG_OVERLAPPED, the file read and writefunctions must specify an OVERLAPPED structure. That is, whenFILE_FLAG_OVERLAPPED is specified, an application must performoverlapped reading and writing.

When FILE_FLAG_OVERLAPPED is specified, the system does not maintainthe file pointer. The file position must be passed as part of thelpOverlapped parameter (pointing to an OVERLAPPED structure) to thefile read and write functions.

This flag also enables more than one operation to be performedsimultaneously with the handle (a simultaneous read and writeoperation, for example).

FILE_FLAG_NO_BUFFERING Instructs the system to open the file with nointermediate buffering or caching. When combined withFILE_FLAG_OVERLAPPED, the flag gives maximum asynchronousperformance, because the I/O does not rely on the synchronousoperations of the memory manager. However, some I/O operations willtake longer, because data is not being held in the cache.An application must meet certain requirements when working with filesopened with FILE_FLAG_NO_BUFFERING:

File access must begin at byte offsets within the file that areinteger multiples of the volume's sector size.File access must be for numbers of bytes that are integer multiplesof the volume's sector size. For example, if the sector size is 512bytes, an application can request reads and writes of 512, 1024, or2048 bytes, but not of 335, 981, or 7171 bytes.Buffer addresses for read and write operations must be sector aligned(aligned on addresses in memory that are integer multiples of thevolume's sector size).One way to align buffers on integer multiples of the volume sectorsize is to use VirtualAlloc to allocate the buffers. It allocatesmemory that is aligned on addresses that are integer multiples of theoperating system's memory page size. Because both memory page andvolume sector sizes are powers of 2, this memory is also aligned onaddresses that are integer multiples of a volume's sector size.

An application can determine a volume's sector size by calling theGetDiskFreeSpace function.


Pàg. 143

FILE_FLAG_RANDOM_ACCESS Indicates that the file is accessed randomly.The system can use this as a hint to optimize file caching.FILE_FLAG_SEQUENTIAL_SCAN Indicates that the file is to be accessedsequentially from beginning to end. The system can use this as a hintto optimize file caching. If an application moves the file pointerfor random access, optimum caching may not occur; however, correctoperation is still guaranteed.Specifying this flag can increase performance for applications thatread large files using sequential access. Performance gains can beeven more noticeable for applications that read large files mostlysequentially, but occasionally skip over small ranges of bytes.

FILE_FLAG_DELETE_ON_CLOSE Indicates that the operating system is todelete the file immediately after all of its handles have beenclosed, not just the handle for which you specifiedFILE_FLAG_DELETE_ON_CLOSE.Subsequent open requests for the file will fail, unlessFILE_SHARE_DELETE is used.

FILE_FLAG_BACKUP_SEMANTICS Windows NT/2000: Indicates that the fileis being opened or created for a backup or restore operation. Thesystem ensures that the calling process overrides file securitychecks, provided it has the necessary privileges. The relevantprivileges are SE_BACKUP_NAME and SE_RESTORE_NAME.You can also set this flag to obtain a handle to a directory. Adirectory handle can be passed to some Win32 functions in place of afile handle.

FILE_FLAG_POSIX_SEMANTICS Indicates that the file is to be accessedaccording to POSIX rules. This includes allowing multiple files withnames, differing only in case, for file systems that support suchnaming. Use care when using this option because files created withthis flag may not be accessible by applications written for MS-DOS or16-bit Windows.FILE_FLAG_OPEN_REPARSE_POINT Specifying this flag inhibits thereparse behavior of NTFS reparse points. When the file is opened, afile handle is returned, whether the filter that controls the reparsepoint is operational or not. This flag cannot be used with theCREATE_ALWAYS flag.FILE_FLAG_OPEN_NO_RECALL Indicates that the file data is requested,but it should continue to reside in remote storage. It should not betransported back to local storage. This flag is intended for use byremote storage systems or the Hierarchical Storage Management system.

If the CreateFile function opens the client side of a named pipe, thedwFlagsAndAttributes parameter can also contain Security Quality ofService information. For more information, see Impersonation Levels.When the calling application specifies the SECURITY_SQOS_PRESENTflag, the dwFlagsAndAttributes parameter can contain one or more ofthe following values. Value Meaning


Pàg. 144

SECURITY_ANONYMOUS Specifies to impersonate the client at theAnonymous impersonation level.SECURITY_IDENTIFICATION Specifies to impersonate the client at theIdentification impersonation level.SECURITY_IMPERSONATION Specifies to impersonate the client at theImpersonation impersonation level.SECURITY_DELEGATION Specifies to impersonate the client at theDelegation impersonation level.SECURITY_CONTEXT_TRACKING Specifies that the security tracking modeis dynamic. If this flag is not specified, Security Tracking Mode isstatic.SECURITY_EFFECTIVE_ONLY Specifies that only the enabled aspects ofthe client's security context are available to the server. If you donot specify this flag, all aspects of the client's security contextare available.This flag allows the client to limit the groups and privileges that aserver can use while impersonating the client.

hTemplateFile[in] Specifies a handle with GENERIC_READ access to a template file.The template file supplies file attributes and extended attributesfor the file being created.Windows 95: The hTemplateFile parameter must be NULL. If you supply ahandle, the call fails and GetLastError returns ERROR_NOT_SUPPORTED.

Return ValuesIf the function succeeds, the return value is an open handle to thespecified file. If the specified file exists before the function calland dwCreationDisposition is CREATE_ALWAYS or OPEN_ALWAYS, a call toGetLastError returns ERROR_ALREADY_EXISTS (even though the functionhas succeeded). If the file does not exist before the call,GetLastError returns zero.

If the function fails, the return value is INVALID_HANDLE_VALUE. Toget extended error information, call GetLastError.

RemarksUse the CloseHandle function to close an object handle returned byCreateFile.

As noted above, specifying zero for dwDesiredAccess allows anapplication to query device attributes without actually accessing thedevice. This type of querying is useful, for example, if anapplication wants to determine the size of a floppy disk drive andthe formats it supports without having a floppy in the drive.

MAPI: For more information, see Syntax and Limitations for Win32Functions Useful in MAPI Development.


Pàg. 145

FilesIf you are attempting to create a file on a floppy drive that doesnot have a floppy disk or a CD-ROM drive that does not have a CD, thesystem displays a message box asking the user to insert a disk or aCD, respectively. To prevent the system from displaying this messagebox, call the SetErrorMode function with SEM_FAILCRITICALERRORS.

When creating a new file, the CreateFile function performs thefollowing actions:

Combines the file attributes and flags specified bydwFlagsAndAttributes with FILE_ATTRIBUTE_ARCHIVE.Sets the file length to zero.Copies the extended attributes supplied by the template file to thenew file if the hTemplateFile parameter is specified.When opening an existing file, CreateFile performs the followingactions:

Combines the file flags specified by dwFlagsAndAttributes withexisting file attributes. CreateFile ignores the file attributesspecified by dwFlagsAndAttributes.Sets the file length according to the value of dwCreationDisposition.Ignores the hTemplateFile parameter.Ignores the lpSecurityDescriptor member of the SECURITY_ATTRIBUTESstructure if the lpSecurityAttributes parameter is not NULL. Theother structure members are used. The bInheritHandle member is theonly way to indicate whether the file handle can be inherited.Windows NT/2000: If you rename or delete a file, then restore itshortly thereafter, Windows NT searches the cache for fileinformation to restore. Cached information includes its short/longname pair and creation time.

Windows NT/2000: Some file systems, such as NTFS, support compressionor encryption for individual files and directories. On volumesformatted for such a file system, a new file inherits the compressionand encryption attributes of its directory.

You cannot use the CreateFile function to set a file's compressionstate. Use the DeviceIoControl function to set a file's compressionstate.

PipesIf CreateFile opens the client end of a named pipe, the function usesany instance of the named pipe that is in the listening state. Theopening process can duplicate the handle as many times as requiredbut, once opened, the named pipe instance cannot be opened by anotherclient. The access specified when a pipe is opened must be compatiblewith the access specified in the dwOpenMode parameter of theCreateNamedPipe function. For more information about pipes, seePipes.


Pàg. 146

MailslotsIf CreateFile opens the client end of a mailslot, the functionreturns INVALID_HANDLE_VALUE if the mailslot client attempts to opena local mailslot before the mailslot server has created it with theCreateMailSlot function. For more information about mailslots, seeMailslots.

Communications ResourcesThe CreateFile function can create a handle to a communicationsresource, such as the serial port COM1. For communications resources,the dwCreationDisposition parameter must be OPEN_EXISTING, and thehTemplate parameter must be NULL. Read, write, or read/write accesscan be specified, and the handle can be opened for overlapped I/O.For more information about communications, see Communications.

Disk DevicesVolume handles may be opened as noncached at the discretion of thefile system, even when the noncached option is not specified withCreateFile. You should assume that all Microsoft file systems openvolume handles as noncached. The restrictions on noncached I/O forfiles apply to volumes as well.

A file system may or may not require buffer alignment even though thedata is noncached. However, if the noncached option is specified whenopening a volume, buffer alignment is enforced regardless of the filesystem on the volume. It is recommended on all file systems that youopen volume handles as noncached and follow the noncached I/Orestrictions.

Windows NT/2000: You can use the CreateFile function to open a diskdrive or a partition on a disk drive. The function returns a handleto the disk device; that handle can be used with the DeviceIOControlfunction. The following requirements must be met in order for such acall to succeed:

The caller must have administrative privileges for the operation tosucceed on a hard disk drive.The lpFileName string should be of the form \\.\PHYSICALDRIVEx toopen the hard disk x. Hard disk numbers start at zero. For example:String Meaning\\.\PHYSICALDRIVE2 Obtains a handle to the third physical drive onthe user's computer.

For an example showing how to open a physical drive, see CallingDeviceIoControl on Windows NT/2000.

The lpFileName string should be \\.\x: to open a floppy drive x or apartition x on a hard disk. For example:String Meaning\\.\A: Obtains a handle to drive A on the user's computer.\\.\C: Obtains a handle to drive C on the user's computer.


Pàg. 147

There is no trailing backslash in a drive name. The string "\\.\c:\"refers to the root directory of drive C.

On Windows 2000, you can also open a volume by referring to itsunique volume name. In this case also, there should be no trailingbackslash on the unique volume name.

Note that all I/O buffers must be sector aligned (aligned onaddresses in memory that are integer multiples of the volume's sectorsize), even if the disk device is opened without theFILE_FLAG_NO_BUFFERING flag.

Windows 95: This technique does not work for opening a logical drive.In Windows 95, specifying a string in this form causes CreateFile toreturn an error.

The dwCreationDisposition parameter must have the OPEN_EXISTINGvalue.When opening a floppy disk or a partition on a hard disk, you mustset the FILE_SHARE_WRITE flag in the dwShareMode parameter.Tape DrivesWindows NT/2000: You can open tape drives using a file name of theform \\.\TAPEx where x is a number indicating which drive to open,starting with tape drive 0. To open tape drive 0 in C, use the filename "\\\\.\\TAPE0". For more information on manipulating tape drivesfor backup or other applications, see Tape Backup.

ConsolesThe CreateFile function can create a handle to console input(CONIN$). If the process has an open handle to it as a result ofinheritance or duplication, it can also create a handle to the activescreen buffer (CONOUT$). The calling process must be attached to aninherited console or one allocated by the AllocConsole function. Forconsole handles, set the CreateFile parameters as follows.

Parameters ValuelpFileName Use the CONIN$ value to specify console input and theCONOUT$ value to specify console output. CONIN$ gets a handle to the console's input buffer, even if theSetStdHandle function redirected the standard input handle. To getthe standard input handle, use the GetStdHandle function.CONOUT$ gets a handle to the active screen buffer, even ifSetStdHandle redirected the standard output handle. To get thestandard output handle, use GetStdHandle.dwDesiredAccess GENERIC_READ | GENERIC_WRITE is preferred, but eitherone can limit access.dwShareMode If the calling process inherited the console or if achild process should be able to access the console, this parametermust be FILE_SHARE_READ | FILE_SHARE_WRITE.lpSecurityAttributes If you want the console to be inherited, thebInheritHandle member of the SECURITY_ATTRIBUTES structure must beTRUE.


Pàg. 148

dwCreationDisposition You should specify OPEN_EXISTING when usingCreateFile to open the console.dwFlagsAndAttributes Ignored.hTemplateFile Ignored.

The following list shows the effects of various settings of fwdAccessand lpFileName.

lpFileName fwdAccess ResultCON GENERIC_READ Opens console for input.CON GENERIC_WRITE Opens console for output.CON GENERIC_READGENERIC_WRITE Windows 95: Causes CreateFile to fail; GetLastErrorreturns ERROR_PATH_NOT_FOUND.Windows NT/2000: Causes CreateFile to fail; GetLastError returnsERROR_FILE_NOT_FOUND.

DirectoriesAn application cannot create a directory with CreateFile; it mustcall CreateDirectory or CreateDirectoryEx to create a directory.

Windows NT/2000: You can obtain a handle to a directory by settingthe FILE_FLAG_BACKUP_SEMANTICS flag. A directory handle can be passedto some Win32 functions in place of a file handle.

Some file systems, such as NTFS, support compression or encryptionfor individual files and directories. On volumes formatted for such afile system, a new directory inherits the compression and encryptionattributes of its parent directory.

You cannot use the CreateFile function to set a directory'scompression state. Use the DeviceIoControl function to set adirectory's compression state.

Requirements Windows NT/2000: Requires Windows NT 3.1 or later. Windows 95/98: Requires Windows 95 or later. Header: Declared in Winbase.h; include Windows.h. Library: Use Kernel32.lib. Unicode: Implemented as Unicode and ANSI versions on WindowsNT/2000.


Pàg. 149

HidD_GetAttributes

BOOLEAN HidD_GetAttributes( IN HANDLE HidDeviceObject, OUT PHIDD_ATTRIBUTES Attributes );

HidD_GetAttributes retrieves device attributes for the specified HIDdevice.

ParametersHidDeviceObjectSpecifies the open handle of a HID device for which the attributesare retrieved.AttributesPoints to a caller-allocated HIDD_ATTRIBUTES structure that is filledwith the attribute information for the HID device specified byHidDeviceObject.Return ValueHidD_GetAttributes returns TRUE if the attribute structure providedin Attributes was filled without error.

CommentsOnly user mode clients can call HidD_GetAttributes.


Pàg. 150

HidD_GetPreparsedData

BOOLEAN HidD_GetPreparsedData( IN HANDLE HidDeviceObject, OUT PHIDP_PREPARSED_DATA *PreparsedData );

HidD_GetPreparsedData

retrieves preparsed data that is used to describe the data returnedfrom a HID device.

ParametersHidDeviceObjectSpecifies the open handle of a HID device from which the preparseddata is to be retrieved.PreparsedDataPoints to a variable to hold the address of a routine-allocatedbuffer containing the preparsed data from the device.Return ValueHidD_GetPreparsedData returns TRUE if the routine completed withouterror.

CommentsOnly user mode clients can call HidD_GetPreparsedData.

When the preparsed data returned by this routine is no longer needed,clients should call HidD_FreePreparsedData to free the bufferallocated for the preparsed data.


Pàg. 151

HidP_GetCaps

NTSTATUS HidP_GetCaps( IN PHIDP_PREPARSED_DATA PreparsedData, IN PHIDP_CAPS Capabilities );

HidP_GetCaps returns the capabilities of a HID device based on thegiven preparsed data.

ParametersPreparsedDataPoints to a caller-allocated buffer that holds the top levelcollection description retrieved from the HID device.CapabilitiesPoints to a caller-allocated buffer that, on return, contains theparsed capability information for this HID device.Return ValueHidP_GetCaps returns HIDP_STATUS_SUCCESS if the routine completedparsing of the data successfully. HIDP_STATUS_INVALID_PREPARSED_DATAis returned if the preparsed data pointed to by PreparsedData ismalformed.

CommentsDrivers obtain the top level collection data used at PreparsedData bycalling HidD_GetPreparsedData.

For kernel mode clients, the caller-allocated buffer supplied atPreparsedData must be allocated from nonpaged pool.

Callers of this routine must be running at IRQL PASSIVE_LEVEL.


Pàg. 152

HidP_GetValueCaps

NTSTATUS HidP_GetValueCaps( IN HIDP_REPORT_TYPE ReportType, OUT PHIDP_VALUE_CAPS ValueCaps, IN OUT PULONG ValueCapsLength, IN PHIDP_PREPARSED_DATA PreparsedData );

HidP_GetValueCaps retrieves the capabilities of all values for agiven top level collection.

ParametersReportTypeSpecifies the type of report for which to retrieve the valuecapabilities. This parameter must be one of the following values:HidP_InputSpecifies that HidP_GetUsages return the value capabilities for allinput reports.HidP_OutputSpecifies that HidP_GetUsages return the value capabilities for alloutput reports.HidP_FeatureSpecifies that HidP_GetUsages return the value capabilities for allfeature reports.ValueCapsPoints to a caller-allocated buffer that will contain, on return, anarray of HIDP_VALUE_CAPS structures that contain information for allvalues in the top level collection.ValueCapsLengthSpecifies the length on input, in array elements, of the bufferprovided at ValueCaps. On output, this parameter is set to the actualnumber of elements that were set by this routine, into the bufferprovided at ValueCaps.The correct length necessary to retrieve the value capabilities canbe found in the capability data returned for the device byHidP_GetCaps.

PreparsedDataPoints to the preparsed data returned for the device when collectioninformation was obtained at initialization.Return ValueHidP_GetValueCaps returns a HIDP_XXX status code from the followinglist:

HIDP_STATUS_SUCCESSIndicates that the routine completed successfully.HIDP_STATUS_INVALID_PREPARSED_DATAIndicates the preparsed HID device data provided at PreparsedData ismalformed.


Pàg. 153

CommentsThis routine will retrieve the capability data for all values in thetop level collection without regard to the usage, usage page, or linkcollection of the value. To retrieve value capabilities for aspecific usage, usage page, or link collection useHidP_GetSpecificValueCaps instead.

Callers of this routine must be running at IRQL <= DISPATCH_LEVEL.


Pàg. 154

HidP_GetButtonCaps

NTSTATUS HidP_GetButtonCaps( IN HIDP_REPORT_TYPE ReportType, OUT PHIDP_BUTTON_CAPS ButtonCaps, IN OUT PULONG ButtonCapsLength, IN PHIDP_PREPARSED_DATA PreparsedData );

HidP_GetButtonCaps returns the capabilities for all buttons for agiven top level collection.

ParametersReportTypeSpecifies the type of report for which to retrieve the buttoncapabilities. This parameter must be one of the following:HidP_InputSpecifies that HidP_GetButtonCaps return the button capabilities forall input reports.HidP_OutputSpecifies that HidP_GetButtonCaps return the button capabilities forall output reports.HidP_FeatureSpecifies that HidP_GetButtonCaps return the button capabilities forall feature reports.ButtonCapsPoints to a caller-allocated buffer that will contain, on return, anarray of HIDP_BUTTON_CAPS structures that contain information for allbuttons on the HID device.ButtonCapsLengthSpecifies the length on input, in array elements, of the bufferprovided at ButtonCaps. On output, this parameter is set to theactual number of elements that were returned by this routine, in thebuffer provided at ButtonCaps if the routine completed without error.The correct length necessary to retrieve the button capabilities canbe found in the capability data returned for the device byHidP_GetCaps.

PreparsedDataPoints to the preparsed data returned for the device when top-levelcollection information was obtained at initialization.Return ValueHidP_GetButtonCaps returns one of the following HIDP_XXX statuscodes:

HIDP_STATUS_SUCCESSIndicates that the routine completed successfully.HIDP_STATUS_INVALID_PREPARSED_DATAIndicates the preparsed HID device data provided at PreparsedData ismalformed.


Pàg. 155

CommentsThis routine will retrieve the capability data for all buttons in thetop level collection without regard to the usage, usage page, or linkcollection. To retrieve button capabilities for a specific usage,usage page, or link collection use HidP_GetSpecificButtonCapsinstead.

Callers of this routine must be running at IRQL PASSIVE_LEVEL.


Pàg. 156

WriteFile

The WriteFile function writes data to a file and is designed for bothsynchronous and asynchronous operation. The function starts writingdata to the file at the position indicated by the file pointer. Afterthe write operation has been completed, the file pointer is adjustedby the number of bytes actually written, except when the file isopened with FILE_FLAG_OVERLAPPED. If the file handle was created foroverlapped input and output (I/O), the application must adjust theposition of the file pointer after the write operation is finished.

This function is designed for both synchronous and asynchronousoperation. The WriteFileEx function is designed solely forasynchronous operation. It lets an application perform otherprocessing during a file write operation.

BOOL WriteFile( HANDLE hFile, // handle to file LPCVOID lpBuffer, // data buffer DWORD nNumberOfBytesToWrite, // number of bytes to write LPDWORD lpNumberOfBytesWritten, // number of bytes written LPOVERLAPPED lpOverlapped // overlapped buffer);ParametershFile[in] Handle to the file to be written to. The file handle must havebeen created with GENERIC_WRITE access to the file.Windows NT/2000: For asynchronous write operations, hFile can be anyhandle opened with the FILE_FLAG_OVERLAPPED flag by the CreateFilefunction, or a socket handle returned by the socket or acceptfunction.

Windows 95/98: For asynchronous write operations, hFile can be acommunications resource opened with the FILE_FLAG_OVERLAPPED flag byCreateFile, or a socket handle returned by socket or accept. Youcannot perform asynchronous write operations on mailslots, namedpipes, or disk files.

lpBuffer[in] Pointer to the buffer containing the data to be written to thefile.nNumberOfBytesToWrite[in] Specifies the number of bytes to write to the file.A value of zero specifies a null write operation. A null writeoperation does not write any bytes but does cause the time stamp tochange.

Named pipe write operations across a network are limited to 65,535bytes.

lpNumberOfBytesWritten[out] Pointer to the variable that receives teh number of byteswritten. WriteFile sets this value to zero before doing any work orerror checking.


Pàg. 157

Windows NT/2000: If lpOverlapped is NULL, lpNumberOfBytesWrittencannot be NULL. If lpOverlapped is not NULL, lpNumberOfBytesWrittencan be NULL. If this is an overlapped write operation, you can getthe number of bytes written by calling GetOverlappedResult. If hFileis associated with an I/O completion port, you can get the number ofbytes written by calling GetQueuedCompletionStatus.

Windows 95/98: This parameter cannot be NULL.

lpOverlapped[in] Pointer to an OVERLAPPED structure. This structure is requiredif hFile was opened with FILE_FLAG_OVERLAPPED.If hFile was opened with FILE_FLAG_OVERLAPPED, the lpOverlappedparameter must not be NULL. It must point to a valid OVERLAPPEDstructure. If hFile was opened with FILE_FLAG_OVERLAPPED andlpOverlapped is NULL, the function can incorrectly report that thewrite operation is complete.

If hFile was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is notNULL, the write operation starts at the offset specified in theOVERLAPPED structure and WriteFile may return before the writeoperation has been completed. In this case, WriteFile returns FALSEand the GetLastError function returns ERROR_IO_PENDING. This allowsthe calling process to continue processing while the write operationis being completed. The event specified in the OVERLAPPED structureis set to the signaled state upon completion of the write operation.

If hFile was not opened with FILE_FLAG_OVERLAPPED and lpOverlapped isNULL, the write operation starts at the current file position andWriteFile does not return until the operation has been completed.

Windows NT/2000: If hFile was not opened with FILE_FLAG_OVERLAPPEDand lpOverlapped is not NULL, the write operation starts at theoffset specified in the OVERLAPPED structure and WriteFile does notreturn until the write operation has been completed.

Windows 95/98: For operations on files, disks, pipes, or mailslots,this parameter must be NULL; a pointer to an OVERLAPPED structurecauses the call to fail. However, Windows 95/98 supports overlappedI/O on serial and parallel ports.

Return ValuesIf the function succeeds, the return value is nonzero.


RemarksAn application must meet certain requirements when working with filesopened with FILE_FLAG_NO_BUFFERING:

File access must begin at byte offsets within the file that areinteger multiples of the volume's sector size. To determine avolume's sector size, call the GetDiskFreeSpace function.


Pàg. 158

File access must be for numbers of bytes that are integer multiplesof the volume's sector size. For example, if the sector size is 512bytes, an application can request reads and writes of 512, 1024, or2048 bytes, but not of 335, 981, or 7171 bytes.Buffer addresses for read and write operations must be sector aligned(aligned on addresses in memory that are integer multiples of thevolume's sector size). One way to sector align buffers is to use theVirtualAlloc function to allocate the buffers. This functionallocates memory that is aligned on addresses that are integermultiples of the system's page size. Because both page and volumesector sizes are powers of 2, memory aligned by multiples of thesystem's page size is also aligned by multiples of the volume'ssector size.If part of the file is locked by another process and the writeoperation overlaps the locked portion, this function fails.

Accessing the output buffer while a write operation is using thebuffer may lead to corruption of the data written from that buffer.Applications must not read from, write to, reallocate, or free theoutput buffer that a write operation is using until the writeoperation completes.

Characters can be written to the screen buffer using WriteFile with ahandle to console output. The exact behavior of the function isdetermined by the console mode. The data is written to the currentcursor position. The cursor position is updated after the writeoperation.

The system interprets zero bytes to write as specifying a null writeoperation and WriteFile does not truncate or extend the file. Totruncate or extend a file, use the SetEndOfFile function.

When writing to a nonblocking, byte-mode pipe handle withinsufficient buffer space, WriteFile returns TRUE with*lpNumberOfBytesWritten < nNumberOfBytesToWrite.

When an application uses the WriteFile function to write to a pipe,the write operation may not finish if the pipe buffer is full. Thewrite operation is completed when a read operation (using theReadFile function) makes more buffer space available.

If the anonymous read pipe handle has been closed and WriteFileattempts to write using the corresponding anonymous write pipehandle, the function returns FALSE and GetLastError returnsERROR_BROKEN_PIPE.

The WriteFile function may fail with ERROR_INVALID_USER_BUFFER orERROR_NOT_ENOUGH_MEMORY whenever there are too many outstandingasynchronous I/O requests.

To cancel all pending asynchronous I/O operations, use the CancelIofunction. This function only cancels operations issued by the callingthread for the specified file handle. I/O operations that arecanceled complete with the error ERROR_OPERATION_ABORTED.


Pàg. 159

If you are attempting to write to a floppy drive that does not have afloppy disk, the system displays a message box prompting the user toretry the operation. To prevent the system from displaying thismessage box, call the SetErrorMode function withSEM_NOOPENFILEERRORBOX.


Requirements Windows NT/2000: Requires Windows NT 3.1 or later. Windows 95/98: Requires Windows 95 or later. Header: Declared in Winbase.h; include Windows.h. Library: Use Kernel32.lib.


Pàg. 160

ReadFile

The ReadFile function reads data from a file, starting at theposition indicated by the file pointer. After the read operation hasbeen completed, the file pointer is adjusted by the number of bytesactually read, unless the file handle is created with the overlappedattribute. If the file handle is created for overlapped input andoutput (I/O), the application must adjust the position of the filepointer after the read operation.

This function is designed for both synchronous and asynchronousoperation. The ReadFileEx function is designed solely forasynchronous operation. It lets an application perform otherprocessing during a file read operation.

BOOL ReadFile( HANDLE hFile, // handle to file LPVOID lpBuffer, // data buffer DWORD nNumberOfBytesToRead, // number of bytes to read LPDWORD lpNumberOfBytesRead, // number of bytes read LPOVERLAPPED lpOverlapped // overlapped buffer);ParametershFile[in] Handle to the file to be read. The file handle must have beencreated with GENERIC_READ access to the file.Windows NT/2000: For asynchronous read operations, hFile can be anyhandle opened with the FILE_FLAG_OVERLAPPED flag by the CreateFilefunction, or a socket handle returned by the socket or acceptfunction.

Windows 95/98: For asynchronous read operations, hFile can be acommunications resource opened with the FILE_FLAG_OVERLAPPED flag byCreateFile, or a socket handle returned by socket or accept. Youcannot perform asynchronous read operations on mailslots, namedpipes, or disk files.

lpBuffer[out] Pointer to the buffer that receives the data read from thefile.nNumberOfBytesToRead[in] Specifies the number of bytes to be read from the file.

lpNumberOfBytesRead[out] Pointer to the variable that receives the number of bytes read.ReadFile sets this value to zero before doing any work or errorchecking. If this parameter is zero when ReadFile returns TRUE on anamed pipe, the other end of the message-mode pipe called theWriteFile function with nNumberOfBytesToWrite set to zero.Windows NT/2000: If lpOverlapped is NULL, lpNumberOfBytesRead cannotbe NULL. If lpOverlapped is not NULL, lpNumberOfBytesRead can beNULL. If this is an overlapped read operation, you can get the numberof bytes read by calling GetOverlappedResult. If hFile is associatedwith an I/O completion port, you can get the number of bytes read bycalling GetQueuedCompletionStatus.


Pàg. 161

Windows 95/98: This parameter cannot be NULL.

lpOverlapped[in] Pointer to an OVERLAPPED structure. This structure is requiredif hFile was created with FILE_FLAG_OVERLAPPED.If hFile was opened with FILE_FLAG_OVERLAPPED, the lpOverlappedparameter must not be NULL. It must point to a valid OVERLAPPEDstructure. If hFile was created with FILE_FLAG_OVERLAPPED andlpOverlapped is NULL, the function can incorrectly report that theread operation is complete.

If hFile was opened with FILE_FLAG_OVERLAPPED and lpOverlapped is notNULL, the read operation starts at the offset specified in theOVERLAPPED structure and ReadFile may return before the readoperation has been completed. In this case, ReadFile returns FALSEand the GetLastError function returns ERROR_IO_PENDING. This allowsthe calling process to continue while the read operation finishes.The event specified in the OVERLAPPED structure is set to thesignaled state upon completion of the read operation.

If hFile was not opened with FILE_FLAG_OVERLAPPED and lpOverlapped isNULL, the read operation starts at the current file position andReadFile does not return until the operation has been completed.

Windows NT/2000: If hFile is not opened with FILE_FLAG_OVERLAPPED andlpOverlapped is not NULL, the read operation starts at the offsetspecified in the OVERLAPPED structure. ReadFile does not return untilthe read operation has been completed.

Windows 95/98: For operations on files, disks, pipes, or mailslots,this parameter must be NULL; a pointer to an OVERLAPPED structurecauses the call to fail. However, Windows 95/98 supports overlappedI/O on serial and parallel ports.

Return ValuesThe ReadFile function returns when one of the following is true: awrite operation completes on the write end of the pipe, the number ofbytes requested has been read, or an error occurs.

If the function succeeds, the return value is nonzero.

If the return value is nonzero and the number of bytes read is zero,the file pointer was beyond the current end of the file at the timeof the read operation. However, if the file was opened withFILE_FLAG_OVERLAPPED and lpOverlapped is not NULL, the return valueis FALSE and GetLastError returns ERROR_HANDLE_EOF when the filepointer goes beyond the current end of file.


RemarksIf part of the file is locked by another process and the readoperation overlaps the locked portion, this function fails.


Pàg. 162

An application must meet certain requirements when working with filesopened with FILE_FLAG_NO_BUFFERING:

File access must begin at byte offsets within the file that areinteger multiples of the volume's sector size. To determine avolume's sector size, call the GetDiskFreeSpace function.File access must be for numbers of bytes that are integer multiplesof the volume's sector size. For example, if the sector size is 512bytes, an application can request reads and writes of 512, 1024, or2048 bytes, but not of 335, 981, or 7171 bytes.Buffer addresses for read and write operations must be sector aligned(aligned on addresses in memory that are integer multiples of thevolume's sector size). One way to sector align buffers is to use theVirtualAlloc function to allocate the buffers. This functionallocates memory that is aligned on addresses that are integermultiples of the system's page size. Because both page and volumesector sizes are powers of 2, memory aligned by multiples of thesystem's page size is also aligned by multiples of the volume'ssector size.Accessing the input buffer while a read operation is using the buffermay lead to corruption of the data read into that buffer.Applications must not read from, write to, reallocate, or free theinput buffer that a read operation is using until the read operationcompletes.

Characters can be read from the console input buffer by usingReadFile with a handle to console input. The console mode determinesthe exact behavior of the ReadFile function.

If a named pipe is being read in message mode and the next message islonger than the nNumberOfBytesToRead parameter specifies, ReadFilereturns FALSE and GetLastError returns ERROR_MORE_DATA. The remainderof the message may be read by a subsequent call to the ReadFile orPeekNamedPipe function.

When reading from a communications device, the behavior of ReadFileis governed by the current communication time-outs as set andretrieved using the SetCommTimeouts and GetCommTimeouts functions.Unpredictable results can occur if you fail to set the time-outvalues. For more information about communication time-outs, seeCOMMTIMEOUTS.

If ReadFile attempts to read from a mailslot whose buffer is toosmall, the function returns FALSE and GetLastError returnsERROR_INSUFFICIENT_BUFFER.

If the anonymous write pipe handle has been closed and ReadFileattempts to read using the corresponding anonymous read pipe handle,the function returns FALSE and GetLastError returnsERROR_BROKEN_PIPE.

The ReadFile function may fail and return ERROR_INVALID_USER_BUFFERor ERROR_NOT_ENOUGH_MEMORY whenever there are too many outstandingasynchronous I/O requests.


Pàg. 163

The ReadFile code to check for the end-of-file condition (eof)differs for synchronous and asynchronous read operations.

When a synchronous read operation reaches the end of a file, ReadFilereturns TRUE and sets *lpNumberOfBytesRead to zero. The followingsample code tests for end-of-file for a synchronous read operation:

// Attempt a synchronous read operation.bResult = ReadFile(hFile, &inBuffer, nBytesToRead, &nBytesRead, NULL);// Check for end of file.if (bResult && nBytesRead == 0, ){ // we're at the end of the file}An asynchronous read operation can encounter the end of a file duringthe initiating call to ReadFile, or during subsequent asynchronousoperation.

If EOF is detected at ReadFile time for an asynchronous readoperation, ReadFile returns FALSE and GetLastError returnsERROR_HANDLE_EOF.

If EOF is detected during subsequent asynchronous operation, the callto GetOverlappedResult to obtain the results of that operationreturns FALSE and GetLastError returns ERROR_HANDLE_EOF.

To cancel all pending asynchronous I/O operations, use the CancelIofunction. This function only cancels operations issued by the callingthread for the specified file handle. I/O operations that arecanceled complete with the error ERROR_OPERATION_ABORTED.

If you are attempting to read from a floppy drive that does not havea floppy disk, the system displays a message box prompting the userto retry the operation. To prevent the system from displaying thismessage box, call the SetErrorMode function withSEM_NOOPENFILEERRORBOX.

The following sample code illustrates testing for end-of-file for anasynchronous read operation:

// set up overlapped structure fieldsgOverLapped.Offset = 0;gOverLapped.OffsetHigh = 0;gOverLapped.hEvent = hEvent;

// attempt an asynchronous read operationbResult = ReadFile(hFile, &inBuffer, nBytesToRead, &nBytesRead, &gOverlapped) ;


Pàg. 164

// if there was a problem, or the async. operation's still pending...if (!bResult){ // deal with the error code switch (dwError = GetLastError()) { case ERROR_HANDLE_EOF: { // we're reached the end of the file // during the call to ReadFile

// code to handle that }

case ERROR_IO_PENDING: { // asynchronous i/o is still in progress

// do something else for a while GoDoSomethingElse() ;

// check on the results of the asynchronous read bResult = GetOverlappedResult(hFile, &gOverlapped, &nBytesRead, FALSE) ;

// if there was a problem ... if (!bResult) { // deal with the error code switch (dwError = GetLastError()) { case ERROR_HANDLE_EOF: { // we're reached the end of the file //during asynchronous operation }

// deal with other error cases } } } // end case

// deal with other error cases

} // end switch} // end ifMAPI: For more information, see Syntax and Limitations for Win32Functions Useful in MAPI Development.



Pàg. 165

CloseHandle

The CloseHandle function closes an open object handle.

BOOL CloseHandle( HANDLE hObject // handle to object);ParametershObject[in/out] Handle to an open object.Return ValuesIf the function succeeds, the return value is nonzero.


Windows NT/2000: Closing an invalid handle raises an exception whenthe application is running under a debugger. This includes closing ahandle twice, and using CloseHandle on a handle returned by theFindFirstFile function.

RemarksThe CloseHandle function closes handles to the following objects:

Access tokenCommunications deviceConsole inputConsole screen bufferEventFileFile mappingJobMailslotMutexNamed pipeProcessSemaphoreSocketThreadCloseHandle invalidates the specified object handle, decrements theobject's handle count, and performs object retention checks. Afterthe last handle to an object is closed, the object is removed fromthe system.

Closing a thread handle does not terminate the associated thread. Toremove a thread object, you must terminate the thread, then close allhandles to the thread.

Use CloseHandle to close handles returned by calls to the CreateFilefunction. Use FindClose to close handles returned by calls toFindFirstFile.



Pàg. 166



Pàg. 167

SetupDiDestroyDeviceInfoList

BOOLEAN SetupDiDestroyDeviceInfoList( IN HDEVINFO DeviceInfoSet );

SetupDiDestroyDeviceInfoList destroys a device information set andfrees all associated memory.

ParametersDeviceInfoSetSupplies a handle to the device information set to destroy.Return ValueThe function returns TRUE if it is successful. Otherwise it returnsFALSE and the logged error can be retrieved with a call toGetLastError.


Pàg. 168

HidD_FreePreparsedData

BOOLEAN HidD_FreePreparsedData( IN PHIDP_PREPARSED_DATA PreparsedData );

HidD_FreePreparsedData releases the resources allocated to holdpreparsed data for the HID device.

ParametersPreparsedDataPoints to a buffer, returned from HidD_GetPreparsedData, that is tobe freed.Return ValueHidD_FreePreparsedData returns TRUE if the buffer was freedsuccessfully. If FALSE is returned it indicates that the buffer wasnot a preparsed data buffer.

CommentsOnly user mode clients can call HidD_FreePreparsedData.


Pàg. 169

2.5.2. Codi de l’aplicació

Un cop ja hem vist les APIs que utilitzarem en la nostra aplicació, el següent passeria estudiar l’aplicació que farem servir i hem creat exclusivament per al nostreprojecte. Recordem de totes maneres que hem intentat que sigui el més genèricpossible i amb aquesta finalitat hem creat la classe USB que amb molt poquesmodificacions, podria ésser utilitzada en aplicacions molt diverses.

El primer que incloem en aquesta relació serà l’arxiu USBInterface.h que inclou ladescripció de les variables i funcions que la componen.

////////////////////////////////////////////////////////////////////////// USBInterface.h: interface for the USBInterface class.////////////////////////////////////////////////////////////////////////

class USBInterface{

public:

int RealitzarOperacio();int EnviarInfo();BOOL DestruirCanal();int BuscarDispositiu();USBInterface();virtual ~USBInterface();unsigned char DisplayHard, BotonsSoft, BotonsHard;int Operacio;BOOL Conectat;HANDLE CanalLectura;HANDLE CanalEscritura;CWinThread* FilLectura;

private:

CString ProductName;CString VendorName;

};


Pàg. 170

El següent que incloem és l’arxiu USBInterface.cpp que consta de l’enumeracióde les funcions que hem enumerat anteriorment.

////////////////////////////////////////////////////////////////////////// USBInterface.cpp: implementation of the USBInterface class.////////////////////////////////////////////////////////////////////////

#include "stdafx.h"#include "PFC.h"#include "USBInterface.h"

extern "C" {

// Declarem altres llibreries necessaries per a les funcions// Totes es poden trobar en el Windows 98DDK

#include "setupapi.h"#include "hidsdi.h"#include "process.h"}

// Variables Globals iguals als valors de referència introduïts enel // Harware

const VendorID = 0x1111;const ProductID = 0x2222;

//////////////////////////////////////////////////////////////////////// Construction/Destruction//////////////////////////////////////////////////////////////////////

USBInterface::USBInterface(){// Inicialitzem els valors per defecte

BotonsHard = 0;DisplayHard = 0;BotonsSoft = 0;Operacio = 1;CanalLectura = 0;CanalEscritura = 0;Conectat = false;

}


Pàg. 171

USBInterface::~USBInterface(){

}

//////////////////////////////////////////////////////////////////////// Funcions de suport//////////////////////////////////////////////////////////////////////

// La finalitat d'aquesta funció es buscar entre els dispositius// connectats el nostre.// Es la base per al treball

int USBInterface::BuscarDispositiu(){// Variables local necessàries

struct _GUID HidGuid;SP_INTERFACE_DEVICE_DATA DeviceInterfaceData;struct {

DWORD cbSize;char DevicePath[256];

} FunctionClassDeviceData;_HIDD_ATTRIBUTES ThisHidDevice;int Success, Dispositiu, i;HANDLE PnPHandle;HANDLE HidHandle;unsigned long BytesReturned;byte buffer[256];BOOL Trobat = FALSE;CString temp;

// Obtenim el nostre identificador de classe 'guid'HidD_GetHidGuid(&HidGuid);

// Creem un enllaç amb el controlador de dispositius PnPPnPHandle = SetupDiGetClassDevs(&HidGuid,0,0,0x12);if (int(PnPHandle) == -1) {

Trobat=FALSE;return 1; // retornem 1 si no ens podem conectar

al// controlador PnP

}Trobat=FALSE;


Pàg. 172

// Mirem en un màxim de 20 dispositius HID o mentres no trobem el// nostre

for (Dispositiu = 0; (Dispositiu < 20) && !Trobat;Dispositiu++) {

// Inicialitzem la nostra informacióDeviceInterfaceData.cbSize = 28; // Numero de bytes de la

// estructura o taula arebre

// Hi ha algún dispositiu HID a la taulaSuccess = SetupDiEnumDeviceInterfaces(

PnPHandle,0,&HidGuid,Dispositiu,&DeviceInterfaceData);

if (Success == 1) {// Hi ha un element a la posició concreta, obtenim informació

FunctionClassDeviceData.cbSize = 5;Success = SetupDiGetDeviceInterfaceDetail(

PnPHandle,&DeviceInterfaceData,PSP_INTERFACE_DEVICE_DETAIL_DATA

(&FunctionClassDeviceData),256,&BytesReturned,0);

if (Success == 0) {return 2; } // retornem 2 si no podem rebre

// informació del dispositiu// En aquest punt ens connectem al dispositiu acabat de trobar

HidHandle = CreateFile(FunctionClassDeviceData.DevicePath,GENERIC_READ|GENERIC_WRITE,FILE_SHARE_READ|FILE_SHARE_WRITE,NULL,OPEN_EXISTING,0,NULL);

if ((int)HidHandle == -1)return 3; // retornem 3 si no ens podem

// connectar al dispositiu PnP

// A partir d’aquí mirem si el dispositiu al que estem connectats esel // nostre per a fer-ho n'obtenim els valors VID i PID

Success = HidD_GetAttributes(HidHandle,&ThisHidDevice);

if ((ThisHidDevice.VendorID == VendorID) &&(ThisHidDevice.ProductID == ProductID)){

// Es el nostre dispositiu i n'agafem la resta d'informacióTrobat = true;


Pàg. 173

// Obtenim del nom del fabricant encara que de moment no en fem resif (HidD_GetManufacturerString(

HidHandle,buffer,sizeof(buffer))){i = 0;temp = "";// Convertim de UNICODE a CStringwhile (buffer[i] != 0) {temp = temp + char(buffer[i]);i = i + 2;

}VendorName = temp;

} else VendorName = "- desconegut -";

// Obtenim del nom del producteif (HidD_GetProductString(

HidHandle,buffer,sizeof(buffer))){i = 0;temp = "";// Convertim de UNICODE a CString

while (buffer[i] != 0) {temp = temp + char(buffer[i]);i = i + 2;

}ProductName = temp;} else ProductName = "- not present -";

// i creem dos Handles un per cada threadCanalEscritura = CreateFile

(FunctionClassDeviceData.DevicePath, \GENERIC_READ|GENERIC_WRITE, \FILE_SHARE_READ|FILE_SHARE_WRITE, \NULL, \OPEN_EXISTING, \0, \NULL);

CanalLectura = CreateFile(FunctionClassDeviceData.DevicePath, \GENERIC_READ|GENERIC_WRITE, \FILE_SHARE_READ|FILE_SHARE_WRITE, \NULL, \OPEN_EXISTING, \0, \NULL);

}


Pàg. 174

}CloseHandle(HidHandle);// if (SetupDiEnumDeviceInterfaces

.

} // for (Dispositiu = 0; (Dispositiu < 20) && !Openned;// Dispositiu++)

CloseHandle(PnPHandle);if (Trobat) {

Conectat = TRUE;return 0;

}else return 4; // retornem 4 si no existeix el dispositiu

}

// Cridem aquesta funció per alliberar tots els recursos queutilitzem// en les comunicacions amb el dispositiu

BOOL USBInterface::DestruirCanal(){

if (Conectat){Conectat = 0; // Tanquem el segon fil de

comunicacions i// lliverem recursos

CloseHandle(CanalEscritura);CloseHandle(CanalLectura);return true;} else return false; // No existia una conexio per a

// destruir}

// Cridem aquesta funció per a enviar l’informació

int USBInterface::EnviarInfo(){

DWORD BytesEnviats = 0;char BufferEscritura[2]; // Els valors a enviar son els

que// carreguem al buffer

// Insertem un caràcter de control ( tot ceros )BufferEscritura[0] = 0;

// El valor que hem calculatBufferEscritura[1] = DisplayHard;


Pàg. 175

// Enviem el valor i n'analitzem el resultat de la operacio

WriteFile (CanalEscritura,BufferEscritura,2,&BytesEnviats,NULL);

// podem mirar quin error hi ha mitjançant GetLastError

return 1;

}

// Cridem aquesta funcio per a calcular el valoor a enviar

int USBInterface::RealitzarOperacio(){

// Realitzem la operacio amb els elements i enviem el resultatswitch (Operacio){case 0: //A anb B

{DisplayHard = BotonsSoft & BotonsHard;if (EnviarInfo()) return 1;else return 0;

}

case 1: //A or B{

DisplayHard = BotonsSoft | BotonsHard;if (EnviarInfo()) return 1;else return 0;

}

case 2: //A xor B{

DisplayHard = BotonsSoft ^ BotonsHard;if (EnviarInfo()) return 1;else return 0;

}

case 3: //Solament A{

DisplayHard = BotonsSoft;if (EnviarInfo()) return 1;else return 0;

}


Pàg. 176

// L’operació per defecte es representar els botons del propiperifèric

default : //Solament B{

DisplayHard = BotonsHard;if (EnviarInfo()) return 1;else return 0;

}// retornem 1 si tot funciona correctament o 0 si hi ha algunproblema// indeterminat

}}


Pàg. 177

Finalment el que incloem és l’arxiu que mostra el codi de la classe PFCDlg.Primerament tenim l’arxiu PFCDlg.h que mostrem a continuació:

// PFCDlg.h : header file//

#if!defined(AFX_PFCDLG_H__0C4ACE07_036B_11D4_90E2_00DF4AC14000__INCLUDED_)#define AFX_PFCDLG_H__0C4ACE07_036B_11D4_90E2_00DF4AC14000__INCLUDED_

#if _MSC_VER > 1000#pragma once#endif // _MSC_VER > 1000

#define WM_BYTEREBUT WM_USER + 5UINT RebreInfo(LPVOID pParam);

typedef CTypedPtrArray<CPtrList, CBitmapButton*>CBitmapButtonArray;

/////////////////////////////////////////////////////////////////////////// CPFCDlg dialog/////////////////////////////////////////////////////////////////////////

class CPFCDlg : public CDialog{

LRESULT OnByteRebut(WPARAM wParam, LPARAM lParam);

// Constructionpublic:

CPFCDlg(CWnd* pParent = NULL); // standard constructor

// Dialog Data//{{AFX_DATA(CPFCDlg)enum { IDD = IDD_PFC_DIALOG };//}}AFX_DATA

// ClassWizard generated virtual function overrides//{{AFX_VIRTUAL(CPFCDlg)protected:virtual void DoDataExchange(CDataExchange* pDX);// DDX/DDV support//}}AFX_VIRTUAL


Pàg. 178

// Implementationprotected:

HICON m_hIcon;// Generated message map functions//{{AFX_MSG(CPFCDlg)virtual BOOL OnInitDialog();afx_msg void OnSysCommand(UINT nID, LPARAM lParam);afx_msg void OnPaint();afx_msg HCURSOR OnQueryDragIcon();afx_msg void OnCrearCanal();afx_msg void OnDestruirCanal();afx_msg void OnModificacioDialeg();virtual void OnOK();//}}AFX_MSGDECLARE_MESSAGE_MAP()

private:

VOID Tractament ();VOID Enmascarar(

int i,CBitmapButton* pBB,int mascara,unsigned char* resultat);

VOID DeshabilitarPantalla ();VOID HabilitarPantalla ();CBitmapButton m_software[4];CBitmapButton m_hardware[4];CBitmapButton m_display[4];CComboBox* pEleccio;

// Creem una taula dinàmica de punters on no hi ha límit i anirem// afegint els elements al final

CBitmapButtonArray pDisplay, pHardware, pSoftware;CButton* pSeleccio[4];

};


Pàg. 179

Finalment el que incloem és l’arxiu PFCDlg.cpp que consta de l’enumeració deles funcions que hem enumerat anteriorment.

/////////////////////////////////////////////////////////////////////////// PFCDlg.cpp : implementation file/////////////////////////////////////////////////////////////////////////

#include "stdafx.h"#include "PFC.h"#include "PFCDlg.h"#include "USBInterface.h"

/* Creem la variable global de la classe USBInterfaceper a que aquesta es pugui veure desde totes les funcionsi en concret desde la funció global RebreInfo()*/

USBInterface USB;

/* Funció que s'executa en el segon fil del programa queha de ser global per definició d'un fil de programatreballador (no te finestres pròpies) */

UINT RebreInfo(LPVOID pParam){// Gestiona la recepció d'informació desde el perifèric

char ReadBuffer[2]; // Lloc on fiquem l'informació rebudaint Retorn; // Informació retornada per ReadFileunsigned long BytesRebuts; // Numero de bytes rebuts per la

funció

while (USB.Conectat) {// Hi haura segon fil mentres estiguem conectatsRetorn = ReadFile(

USB.CanalLectura,ReadBuffer,2,&BytesRebuts,NULL);

if (BytesRebuts >= 1) { // Rebem informació iconcretament 2

// bytesUSB.BotonsHard = ReadBuffer[1];

// El segon byte es l’informació concreta


Pàg. 180

// Hem de fer notar que hem rebut un caràcter// enviem un missatge de Windows definit per l'usuari

::PostMessage((HWND) pParam, WM_BYTEREBUT, 0, 0);}

// Sempre que es rebi informació però no arribi en el formatdeterminat// serà depreciada

}return 0;

}


Pàg. 181

/////////////////////////////////////////////////////////////////////////// CPFCDlg dialog/////////////////////////////////////////////////////////////////////////

// Cridem aquesta funció quant destruïm el canal o es destrueix i no// te sentit que estiguin habilitats els botons per a interactuar

VOID CPFCDlg::DeshabilitarPantalla(){

CButton* pB;CBitmapButton* pBB;int i;

// Habilitem el boto per permetre la conexio del canalpB = (CButton*) GetDlgItem(IDC_DestruirCanal);pB->EnableWindow(FALSE);pB = (CButton*) GetDlgItem(IDC_CrearCanal);pB->EnableWindow(TRUE);

// Deshabilitem els menús de diàlegpB = (CButton*) GetDlgItem(IDC_Missatge1);pB->EnableWindow(FALSE);pB = (CButton*) GetDlgItem(IDC_Missatge2);pB->EnableWindow(FALSE);pB = (CButton*) GetDlgItem(IDC_Missatge3);pB->EnableWindow(FALSE);pB = (CButton*) GetDlgItem(IDC_Missatge4);pB->EnableWindow(FALSE);pB = (CButton*) GetDlgItem(IDC_Missatge5);pB->EnableWindow(FALSE);

// Deshabilitem els botons per a variar informació de l'usuarifor (i=0; i<=3; i++){

pSeleccio[i]->SetCheck(0);pSeleccio[i]->EnableWindow(FALSE);

}pEleccio->SetCurSel(-1);pEleccio->EnableWindow(FALSE);

// Desactivem tots els botons que puguin estar seleccionats per// l'usuari

POSITION pos = pSoftware.GetHeadPosition();// Variables d'apoyo a la iteració

while (pos != NULL){

pBB = ((CBitmapButton*)(pSoftware.GetNext(pos)));pBB->EnableWindow(FALSE);

}


Pàg. 182

// Desactivem tots els botons que pugui seleccionar el perifèricpos = pHardware.GetHeadPosition();while (pos != NULL){

pBB = ((CBitmapButton*)(pHardware.GetNext(pos)));pBB->EnableWindow(FALSE);

}

pos = pDisplay.GetHeadPosition();while (pos != NULL){

pBB = ((CBitmapButton*)(pDisplay.GetNext(pos)));pBB->EnableWindow(FALSE);

}

}

// Fem servir aquesta funció per a modificar el valor del display de// la pantalla segons el valor de la variable// Els valors que l'hi passem son si( actiu o no actiu) pBB( elbitmap// que el representa)// màscara( quin valor de la variable) resultat( lloc on guardem el// resultat escrit a pantalla)

VOID CPFCDlg::Enmascarar(int i, CBitmapButton* pBB, int mascara,unsigned char* resultat){

int temp = 1; // Mascara a aplicarint cont; // Contador

for (cont=1; cont <= mascara; cont++)temp <<= 1;

if (i){

*resultat = *resultat | temp;pBB->EnableWindow(TRUE); // Assignem el valor nou

com a// referencia per a futures operacions

}else{

*resultat = *resultat & (~temp);pBB->EnableWindow(FALSE);

}}


Pàg. 183

// Cridem aquesta funció per a que tots els elements necessaris// estiguin actius

VOID CPFCDlg::HabilitarPantalla(){

int i;CButton* pB;

// Habilitem el boto per permetre la desconnexió del canalpB = (CButton*) GetDlgItem(IDC_DestruirCanal);pB->EnableWindow(TRUE);pB = (CButton*) GetDlgItem(IDC_CrearCanal);pB->EnableWindow(FALSE);

// Habilitem els menús de diàlegpB = (CButton*) GetDlgItem(IDC_Missatge1);pB->EnableWindow(TRUE);pB = (CButton*) GetDlgItem(IDC_Missatge2);pB->EnableWindow(TRUE);pB = (CButton*) GetDlgItem(IDC_Missatge3);pB->EnableWindow(TRUE);pB = (CButton*) GetDlgItem(IDC_Missatge4);pB->EnableWindow(TRUE);pB = (CButton*) GetDlgItem(IDC_Missatge5);pB->EnableWindow(TRUE);

// Habilitem els botons per a variar informació de l'usuarifor (i=0; i<=3; i++)

pSeleccio[i]->EnableWindow(TRUE);

// Inicialitzem una opcio per defecte aixi evitem que no ho faci// l'usuari

pEleccio->EnableWindow(TRUE);pEleccio->SetCurSel(4);

}

// Es crida a aquesta funció com a resultat del missatge enviat// pel segon fil. L’usuari ha modificat un bit del Hardware

LRESULT CPFCDlg::OnByteRebut(WPARAM wParam, LPARAM lParam){

// Actualitzem el contingut del nou byte rebut a la pantallaint mascara = 1;unsigned char prescindible;int i = 0; //ContadorCBitmapButton* pBB;


Pàg. 184

if (USB.Conectat){

POSITION pos = pHardware.GetHeadPosition(); // Varialbles// d'apoyo a la iteracio


pBB = ((CBitmapButton*)(pHardware.GetNext(pos)));Enmascarar((USB.BotonsHard & mascara), pBB, i++,

&prescindible);mascara <<= 1;

}

// I tot seguit fem que s'executi el tractament de l'informacióTractament();

}return 0;

}

// S'executa aquesta funció quant premem de la pantalla el boto per// crear el canal

void CPFCDlg::OnCrearCanal(){

int VarRetorn; // Variable de retorn de les// funcions que cridem

CWinThread* Temp; // Variable temporal per a la creaciódel

// segon fil// Obrim el canal de comunicacions amb el perifèric

VarRetorn = USB.BuscarDispositiu();

switch (VarRetorn){case 0:

{ // La funcio troba el dispositiu correctament// Creem el segon fil d'execucio del programa en una funcio global

Temp = AfxBeginThread(RebreInfo,GetSafeHwnd(),THREAD_PRIORITY_NORMAL);

if (Temp == NULL)SetDlgItemText(IDC_MissatgeInfo, "Impossible crear fil de treball");

else{HabilitarPantalla();SetDlgItemText(IDC_MissatgeInfo,"Conexio realitzada amb exit");


Pàg. 185

// Indiquem al Hardware que hem posat en marxa l'aplicació i quel'hem// detectat// Inicialitzem les variables

USB.DisplayHard=0;USB.BotonsSoft=0;USB.BotonsSoft=0;}

break;}

// Qualsevol altre valor de retorn implica un problema diferentcase 1:

{SetDlgItemText(IDC_MissatgeInfo,"Impossible establir comunicacions amb node PnP");break;

}case 2:

{SetDlgItemText(IDC_MissatgeInfo,"No existeix informacio en el controlador PnP sobreperiferic");break;

}case 3:

{SetDlgItemText(IDC_MissatgeInfo,"Impossible conectarse a un dispositiu trobat");break;

}case 4:

{SetDlgItemText(IDC_MissatgeInfo,"No existeix el dispositiu especific");break;

}default:

{SetDlgItemText(IDC_MissatgeInfo,"Error no determinat en la localitzacio deldipositiu");break;

}}

}


Pàg. 186

// S'executa aquesta funció quant premem de la pantalla el boto per// destruir el canal o be volem sortir del programa

void CPFCDlg::OnDestruirCanal(){

// Destruim el canal de comunicacionsDeshabilitarPantalla();(USB.DestruirCanal())?

SetDlgItemText(IDC_MissatgeInfo,"Canal de comunicacions destruit"):SetDlgItemText(IDC_MissatgeInfo,"No existeix cap conexio per a poder ser destruida");

}

// S'executa aquesta funció quant variem qualsevol valor de les// variables de control

void CPFCDlg::OnModificacioDialeg(){

int i = 0; // ContadorPOSITION pos = pSoftware.GetHeadPosition(); // Varialbles

d'apoyo// a la iteracio

// Fem un lectura de tots els controls que pot modificar iactualitzem// el que es veu per pantalla


Enmascarar((pSeleccio[i]->GetCheck()),((CBitmapButton*)(pSoftware.GetNext(pos))), i,&USB.BotonsSoft);i++;

}

// Mirem quina es la funcio a realitzarUSB.Operacio = pEleccio->GetCurSel();

// Fem finalment totes les operacions necessaries i// enviem els resultats

Tractament ();}


Pàg. 187

// La utilitzem per sortir de l'aplicació

void CPFCDlg::OnOK(){

OnDestruirCanal(); // Abans de sortir destruïm tots els canals// creats i el segon fil

CDialog::OnOK();}

// Es la funció encarregada de tractar les dades rebudes, fer les// operacions necessàries i mostrar per pantalla els resultats

VOID CPFCDlg::Tractament(){

// Realitzem el calcul del valor a enviar i enviem l’informacióif (USB.RealitzarOperacio()){

// El valor calculat ja ha estat enviatSetDlgItemText(IDC_MissatgeInfo, "Valor enviat amb

exit");

// Mostrem per pantalla el valor enviat i que també tindrà elperifèric

int mascara = 1;unsigned char prescindible;int i = 0; //ContadorPOSITION pos = pDisplay.GetHeadPosition();

// Varialbles d'apoyo a la iteraciowhile (pos != NULL){

Enmascarar((USB.DisplayHard &mascara),((CBitmapButton*)(pDisplay.GetNext(pos))), 0,&prescindible);mascara <<= 1;i++;

}}else{

DeshabilitarPantalla(); // No es pot enviar elvalor

// per tant no hi ha comunicacioSetDlgItemText(IDC_MissatgeInfo,"Impossible enviar valor, revisi la conexio");

}}


Pàg. 188


Pàg. 189

3. PLÀNOLS


Pàg. 190

3.1. Introducció

En aquest apartat mostrarem d’una forma detallada tots els plànols necessaris pera la realització d’aquest projecte. També es detallaran els esquemes elèctrics,plaques de circuit imprès i situació dels components en les mateixes plaques.


Pàg. 191

3.2. Esquema elèctric

A continuació adjuntem l’esquema elèctric que obtenim un cop realitzat aquestutilitzant el programa de disseny ORCAD, per a MS-DOS i imprimim el circuit enl’utilitat SCHEMATIC DESIGN TOOLS.


Pàg. 192

3.3. Circuits impresos

Tot seguit adjuntem l’esquema del circuit imprès que obtenim un cop realitzataquest utilitzant el programa de disseny ORCAD, per a MS-DOS i imprimim elcircuit en l’utilitat LAYOUT DESIGN TOOLS.

3.3.1. Disseny de la placa

El que mostrem en aquest sub-apartat són les pistes que tindrà en propi circuitimprès un cop hem definit les pistes correctes i els traçats adequats.

Cara Soldadura Cara Components


Pàg. 193

3.3.2. Transparència

El que tenim en aquest apartat son els fulls anteriors però impresos sobretransparència amb la finalitat que amb un laboratori adequat es puguin fer lesplaques de forma correcta.


Pàg. 194

Cara Components

Cara Soldadura


Pàg. 195

3.4. Components

Finalment mostrarem quin és l’emplaçament dels components en la placa decircuit imprès fent servir, un altre cop el programa de disseny ORCAD, per a MS-DOS i imprimim el circuit en l’utilitat LAYOUT DESIGN TOOLS.


Pàg. 196


Pàg. 197

4. PRESSUPOST


Pàg. 198

4.1. Introducció

En aquest apartat del projecte es pretén detallar els preus unitaris dels materialsutilitzats així com les mesures i pressupostos dels diversos blocs del muntatge.


Pàg. 199

4.2. Mesures

Número UnitatsQuantitat per

circuit Quantitat total Element

1 unitat 1 500 Condensador electrolític de 10uF2 unitat 1 500 Condensador electrolític de 100uF3 unitat 1 500 Condensador electrolític de 4,7uF4 unitat 4 2000 Condensador 33pF5 unitat 4 2000 Condensador 100nF6 unitat 4 2000 Led color vermell7 unitat 1 500 Led color verd8 unitat 5 2500 Resistències de 10k Ohms9 unitat 2 1000 Resistències de 22 Ohms Tol. 1%

10 unitat 1 500 Resistències de 470 Ohms11 unitat 1 500 Resistències de 1k Ohms12 unitat 1 500 Resistències de 1M Ohms13 unitat 1 500 Resistències de 4k7 Ohms14 unitat 1 500 Pack 4 resistències 330 Ohms15 unitat 1 500 Pack 4 resistències 10k Ohms16 unitat 1 500 Pack 4 commutadors17 unitat 1 500 Regleta connexionat USB18 unitat 1 500 Regleta connexionat RS48519 unitat 1 500 Jumper alimentació20 unitat 1 500 Microcontrolador 805221 unitat 1 500 Circuit integrat PDIUSBD1222 unitat 1 500 Circuit integrat 74HC1423 unitat 1 500 Circuit integrat 75176B24 unitat 1 500 Cristall 6 MHz25 unitat 1 500 Cristall 12 MHz26 unitat 1 500 Placa circuit imprès 5x10 cm27 hores 1 500 Muntatge de l'equip28 hores 300 300 Fase de I+D


Pàg. 200

4.3. Preus unitaris

Número Element Unitats Preu

1 Condensador electrolític de 10uF unitat 102 Condensador electrolític de 100uF unitat 153 Condensador electrolític de 4,7uF unitat 104 Condensador 33pF unitat 105 Condensador 100nF unitat 106 Led color vermell unitat 157 Led color verd unitat 158 Resistències de 10k Ohms unitat 29 Resistències de 22 Ohms Tol. 1% unitat 5

10 Resistències de 470 Ohms unitat 211 Resistències de 1k Ohms unitat 212 Resistències de 1M Ohms unitat 213 Resistències de 4k7 Ohms unitat 214 Pack 4 resistències 330 Ohms unitat 10015 Pack 4 resistències 10k Ohms unitat 10016 Pack 4 commutadors unitat 15017 Regleta connexionat USB unitat 10018 Regleta connexionat RS485 unitat 10019 Jumper alimentació unitat 1020 Microcontrolador 8052 unitat 100021 Circuit integrat PDIUSBD12 unitat 200022 Circuit integrat 74HC14 unitat 80023 Circuit integrat 75176B unitat 80024 Cristall 6 MHz unitat 7025 Cristall 12 MHz unitat 7026 Placa circuit imprès 5x10 cm unitat 150027 Muntatge de l'equip hora 80028 Fase de I+D hora 1500


Pàg. 201

4.4. Pressupost

Número Element Unitats QuantitatPreu

unitariTotal

parcialTOTAL

1 Condensador electrolític de 10uF unitat 500 10 5.0002 Condensador electrolític de 100uF unitat 500 15 7.5003 Condensador electrolític de 4,7uF unitat 500 10 5.0004 Condensador 33pF unitat 2000 10 20.0005 Condensador 100nF unitat 2000 10 20.0006 Led color vermell unitat 2000 15 30.0007 Led color verd unitat 500 15 7.5008 Resistències de 10k Ohms unitat 2500 2 5.0009 Resistències de 22 Ohms Tol. 1% unitat 1000 5 5.000

10 Resistències de 470 Ohms unitat 500 2 1.00011 Resistències de 1k Ohms unitat 500 2 1.00012 Resistències de 1M Ohms unitat 500 2 1.00013 Resistències de 4k7 Ohms unitat 500 2 1.00014 Pack 4 resistències 330 Ohms unitat 500 100 50.00015 Pack 4 resistències 10k Ohms unitat 500 100 50.00016 Pack 4 commutadors unitat 500 150 75.00017 Regleta connexionat USB unitat 500 100 50.00018 Regleta connexionat RS485 unitat 500 100 50.00019 Jumper alimentació unitat 500 10 5.00020 Microcontrolador 8052 unitat 500 1000 500.00021 Circuit integrat PDIUSBD12 unitat 500 2000 1.000.00022 Circuit integrat 74HC14 unitat 500 800 400.00023 Circuit integrat 75176B unitat 500 800 400.00024 Cristall 6 MHz unitat 500 70 35.00025 Cristall 12 MHz unitat 500 70 35.00026 Placa circuit imprès 5x10 cm unitat 500 1500 750.00027 Muntatge de l'equip hora 500 800 400.00028 Fase de I+D hora 300 1500 450.000

1.889.000


Pàg. 202

4.5. Resum del pressupost

Pressupost d'execució material 1.889.000 pessetes

Gastos generals (6%) 113.340 pessetes

Benefici industrial (16%) 302.240 pessetes

Total 2.304.580 pessetes

I.V.A. (15%) 345.687 pessetes

TOTAL PRESSUPOST EXECUCIÓ PER CONTRACTA 2.650.267 pessetes

El pressupost d’execució per contracta puja a la quantitat de dos milions sis-centescinquanta mil dues-centes seixanta set pessetes per a la fabricació de les 500 unitats.

Tarragona a 20 de Gener de 2001-01-12L’enginyer Tècnic Industrial

Jaume Solé i Pardines


Pàg. 203


Pàg. 204

5. PLEC DE CONDICIONS


Pàg. 205

5.1. Introducció

L'objectiu d'aquest apartat és especificar les condicions generals, tècniques,facultatives, econòmiques i administratives per a la correcta realització d'aquestprojecte.


Pàg. 206

5.2. Condicions generals

5.2.1. Descripció

La disposició d'aquest muntatge és el necessari i suficient per la realització d'unperifèric que es comuniqui amb un ordenador utilitzant el bus de comunicacionsUSB.

5.2.2. Execució

Primerament s'adjudicarà l'obra segons les condicions que s'indiquin; desprésl’empresa adjudicatària, guiant-se per aquest projecte realitzarà l’execució del’obra.

En cas que es necessiti o es cregui convenient efectuar algun canvi, l’empresa esposarà en contacte amb l’autor del projecte i arribaran a un acord per escrit perrealitzar el canvi o modificació oportuns.

5.2.3. Recepció

La finalització del muntatge i lliurament del sistema haurà d'efectuar-se en untermini de 30 dies a partir del dia de la data d'adjudicació de l’obra.

Es tindrà en compte la possible modificació de la data per imprevistos, falta dematerial, etc.


Pàg. 207

5.2.4. Responsabilitat

El constructor o l’empresa adjudicatària és l’únic responsable de l’execució delprojecte, al qual s'ha compromès per lliure voluntat, sense tenir dret a laindemnització per l’increment de preus de les diferents unitats, ni per maniobreserrònies que es cometin durant la seva realització.

L 'administració presenta, doncs, un paper passiu limitant-se a acceptar l’ofertaque se li ha fet i ha d'atendre's a aquesta, com perfectament meditada iresponsabilitzada, per ser complida en seriositat i absoluta fe.

L 'adjudicat és responsable també davant els tribunals dels accidents que perinexperiència, negligència o desig immoderat de lucre sobrevinguin, així compossibles incompliments de les disposicions legals vigents.

5.2.5. Modificacions

Si l’empresa adjudicatària desitja per la seva banda realitzar alguna modificació,no bàsica, haurà de donar-la a conèixer per escrit al departament corresponent i ald'adquisició de la firma.

Si es considera raonable i s'accepta, serà confirmada per escrit, així com les novescondicions econòmiques que mútuament s'acceptin.

Si tot l’anterior no es realitza tal com s'ha especificat, no s'acceptarà capmodificació.

Si per decisió de la direcció de l’Oficina Tècnica s’introduïssin millores,pressupostos addicionals o reformes d'adjudicatari, queda obligat a executar-hoamb la baixa corresponent aconseguida a la baixa adjudicació.


Pàg. 208

5.2.6. Manteniment

Es donarà opció a l’executant, al seu dia i a través d'un contracte a banda, a laconservació i manteniment de l’equip. També tindrà preferència a les obresd'ampliació que al futur puguin produir-se.

5.2.7. Supervisió

La firma es reserva el dret a supervisar i controlar la marxa de l’equip, tant alperíode de fabricació com al muntatge, a través dels seus tècnics que en totmoment tindran accés lliure a les dependències i plànols, i estaran a més facultatsper refusar en qualsevol moment determinats materials i suggerir l’utilitzaciód'altres de similars.

5.2.8. Transport

Les despeses de transport, embalatges i assegurances dels equips, fins al punt dedestí, aniran a càrrec de l’empresa adjudicatària.


Pàg. 209

5.2.9. Anul·lació del contracte

L 'anul·lació del contracte només podrà ser portada a terme per alguna de lescauses següents:

• Mort o incapacitació del contractista.

• Fallida de l’empresa contractista.

• Modificació del projecte per una alteració de menys d'un 25% del valorcontractat.

• Modificació del volum de l’obra en més d'un 40%.

• El no compliment de les dades per part del contractista.

• La suspensió durant 2 mesos de les obres ja començades.

• Abandonament de l’obra sense causa justificada.


Pàg. 210

5.3. Condicions tècniques

5.3.1. Generalitats

Les característiques tècniques seran, mitjançant mutu acord, rectificades en cas denecessitat imperiosa.

De no ser així, compliran les condicions elèctriques i de paràmetres senyalats enaquest document, així com també les condicions de seguretat senyalades.

5.3.2. Normativa aplicada

Per la fabricació i instal·lació del sistema dissenyat en aquest projecte es tindranen compte les normes que estableixen els fabricants d'aparells electrònics.

5.3.3. Utilització

Si algun cop alguna operació no consta al quadre de característiques de l’equipelectrònic, haurà de posar-se una especial atenció al disseny del circuit per evitartota sobrecarrega, deguda a condicions desfavorables de funcionament.

No s'han d'utilitzar dispositius electrònics en circumstancies en que es puguindonar situacions de funcionament no controlades pel fabricant.


Pàg. 211

5.3.4. Valors límits

Aquests són els valors límits de funcionament i de condicions ambientals defuncionament aplicables a qualsevol dispositiu electrònic d'un tipus especificat, talcom el defineixen les dades publicades, les quals i a les pitjors circumstancies ocondicions, no han d'excedir d'aquests límits.

Aquests valors són elegits pel fabricant per assegurar el bon funcionament deldispositiu, declinant tota responsabilitat per canvis de l’equip o ambientals, degutsa les variacions de les característiques del dispositiu en consideració i de tots elsaltres circuits als quals esta connectat.

El fabricant d'equips haurà de realitzar el disseny de manera que no se sobrepassi,ni inicialment, ni durant tota la seva vida útil, cap valor considerat pel fabricantcom a límit ni en les condicions normals, ni als pitjors casos de treball i ambient.

5.3.5. Circuits integrats

Els circuits integrats estaran indicats als plànols i no podran ser substituïts peraltres models que no tinguin les mateixes característiques.

5.3.6. Transistors i díodes

Els transistors i díodes utilitzats seran els especificats als plànols, o al seu defecte,models equivalents.

Es verificaran aquestes condicions conforme a les mesures següents:

• Mesura dels valors límits.

• Mesura dels paràmetres de treball.


Pàg. 212

Les mesures de les tensions, corrents i potències, es faran mitjançant un muntatgede prova que faciliti i permeti subministrar en cada cas i a cada un dels transistors,les tensions desitjades i disposant així mateix d’aparells de mesura de tensions icorrents que ens permetin controlar en cada moment les tensions i corrents quecirculen pel transistor.

Si durant alguna de les proves realitzades resultés algun component danyat, sensehaver-se sobrepassat els límits específics i els danys fossin de caràcter permanent,no implicaria cap compromís per la firma en qüestió, essent la responsabilitatenterament de l’empresa o casa adjudicada.

5.3.7. Resistències

Les resistències seran dels valors òhmics especificats. Totes les resistències serande 0.25W i amb una tolerància del 5%, excepte les fixades als plànols que hoindiquin d’altra forma. Les proves a realitzar amb totes elles consistiran en:

• Mesura de valors de toleràncies.

• Mesura de dissipació i voltatge.

Per aquestes proves es classificaran:

• Potencia nominal.

• Resistències ajustables.

• Potenciòmetres.

La mesura dels valors de resistència i tolerància s'estendran a totes les resistènciesi totes hauran de mantenir la seva tolerància dins d'un límit compres entre el 0.5 ie15% segons el tipus a que correspongui.

Les mesures de potencia es realitzaran sometent les resistències a tensionsadequades per a que la seva dissipació sigui la que indiqui el fabricant.

Es veuran sotmeses a aquesta tensió durant un temps de 6 hores per a que permetiveure amb suficiència la seva variació de resistència amb el temps.


Pàg. 213

5.3.8. Condensadors

Tots els condensadors seran del valor capacitiu especificat als plànols. La sevatensió màxima també s'especifica als plànols.Els condensadors electrolítics seran de muntatge vertical o horitzontal segons lesespecificacions dels plànols. És necessari posar especial atenció en no invertir lapolaritat al moment de muntar-los.

5.3.9. Circuits impresos

Les plaques de circuit imprès hauran de tenir un aïllament superficial igual osuperior a 10M i seran de fibra de vidre presensibilitzades positivament, una a unacara i dues a doble cara.Les seves dimensions seran les necessàries per a que puguin contenir elsesquemes.El full de coure ha de tenir un gruix normalitzat de 0.075 mm. per les pistes desenyal i 0.76 mm. per les pistes d'alimentació.La separació mínima entre pistes serà d' 1.14mm, mentre que el taladrat esrealitzarà amb una broca d'1mm o inferior.La realització dels circuits impresos es farà a partir dels plànols, respectantestrictament el disseny de les pistes.Les plaques estaran cobrejades per les dues cares, de tal manera que lesconnexions es puguin fer per les esmentades cares encara que els elements actiussols es trobaran a una de les cares.Els connectors, encarregats de realitzar les connexions entre l’exterior i lesplaques, així com les connexions entre elles, es revisaran per garantir el correctecontacte amb les plaques i s'imprimiran una sèrie d'indicacions per la seva correctecol.1ocació.Un cop soldats els components i comprovats, es procedirà a l’aplicació d'una capade vernís especial per evitar la possible oxidació del coure amb el pas del temps.


Pàg. 214

5.3.10. Muntatge i cablejat intern

Totes les plaques a realitzar en aquest muntatge aniran a l’interior de caixes ambunes característiques apropiades d'aïllament davant possibles interferències,accions ambientals externes i altres factors negatius pel funcionament del sistema.

El connexionat entre plaques i altres elements es realitzarà sense alterar l’ordreindicat als plànols.

Per la connexió externa s'utilitzarà cable connectat amb els connectorsnormalitzats segons l’estàndard USB.

5.3.11. Alimentació del muntatge

Les tensions d'alimentació del muntatge seran +5V i GND.

Tal com s'indica al plànol corresponent a la lamina 1, el connector d'alimentació icomunicació tindrà 4 cables que corresponen a tensions d'alimentació i masses icomunicació el HC i el perifèric (segons l’estàndard USB).

Amb el cable d'alimentació general es col·locarà en sèrie un portafusibles amb unfusible ràpid de 0.5A.


Pàg. 215

5.4. Condicions facultatives

5.4.1. Generalitats

La disposició d'aquest muntatge ha de ser la necessària i suficient per la realitzaciódel projecte.

5.4.2. Direcció

La direcció i control de l’execució d'aquest projecte estarà encomanada a un tècnicdesignat per la propietat.

El facultatiu de la propietat tindrà en allò que afecta les seves relacions amb elcontractista les funcions següents:

• Fer que s'executin totes les parts del projecte de manera que s'ajustin almateix i dins del termini fixat al contracte i terminis parcials fixatsposteriorment, exigint al contractista el compliment de totes les condicionscontractuals.

• Definir aquelles prescripcions tècniques que el present Plec deixi a la sevadecisió.

• Resoldre totes les qüestions tècniques que sorgeixin pel que fa ainterpretació de plànols o del present Plec de Condicions, característiquesdels materials; forma d'execució d'unitats constructives, medició iabonament, etc., sempre que no es modifiquin les condicions del contracte.

• Estudiar les incidències o problemes plantejats que impedeixin el normalcompliment del contracte o aconsellin la seva modificació, tramitant al seucas les propostes corresponents.

• Obtenir dels organismes interessats els permisos necessaris per l’execuciód'aquest projecte.


Pàg. 216

• Acreditar al contractista les obres realitzades conforme el disposat alcontracte i legislació vigents.

El director podrà prohibir la participació a l’execució d'aquell personal que nocompleixi les ordres donades per la direcció, cometi faltes de respecte o incorreixien faltes omissions que pertorbin la bona marxa de l’execució.

5.4.3. Realització

El personal encarregat del muntatge haurà de ser el suficientment especialitzat perportar a terme aquest muntatge, segons les exigències i normes dictades al projectesegüent.

La realització d'aquest muntatge serà tal com s'indica als plànols d'aquest projecte.

Si a judici del director tècnic fos precisa qualsevol modificació, s'haurà deredactar el conseqüent projecte reformat, el qual es considerarà a partir del dia dela data com a part integrant del projecte primitiu.

En cas de contradicció entre els plànols i les prescripcions tècniques, preval elprescrit en aquestes últimes. En qualsevol cas allò mencionat al Plec deCondicions i exclòs als plànols i viceversa haurà de ser executat com si estiguésexposat en ambdós documents, sempre que a judici del director quedin les unitatssuficientment definides.

5.4.4. Materials

Tots els materials que s'utilitzin hauran de complir amb rigor les condicionsnecessàries a judici del director tècnic, qui dins d'un criteri d'equitat i justícia esreserva el dret d'ordenar, retirar o reemplaçar, si al seu judici perjudiquessind'alguna manera qualsevol mesura de seguretat del muntatge.


Pàg. 217

5.4.5. Construcció

El procés de construcció serà el següent:

• Adquisició de tots els components.

• Muntatge segons les característiques.

• Comprovació a posteriori de tot el muntatge.

• Prova final del funcionament.

L’execució del muntatge es portarà a terme fins al seu complet acabament ambestricta subjecció a totes les condicions especificades en aquesta secció delprojecte i del tècnic encarregat de l’instal·lació.

D'altra banda no es donarà per acabat el muntatge fins haver aconseguit un ajustde tots els elements, el qual és exigit per obtenir un rendiment i característiques defuncionament adequats.


Pàg. 218

5.5. Condicions econòmiques

5.5.1. Medicions

La forma de realitzar la medició i les unitats de mesura a utilitzar seran lesdescrites al present Plec de Condicions, aplicant quan no es prevegi unitat o se'nprevegin diverses la que fixi la direcció d'obra. Totes les mesures es faran seguintles unitats del sistema mètric decimal.

Els excessos que resultin de mesurar l’obra realment executada, en relació amballò projectat no seran d'abonament si aquests excessos són evitables; fins i tot laDirecció podrà exigir que es corregeixi l’executat perquè es corresponguiexactament a allò projectat.

Encara que quan aquests excessos siguin a judici del director inevitables no serand'abonament si els mateixos formen part dels treballs auxiliars necessaris perl’execució de la unitat, ni tampoc si aquests excessos estan inclosos al preu de lacorresponent unitat.

Quan els excessos inevitables no estiguin en algunes de les suposicions anteriorsseran d'abonament al contractista als preus unitaris aplicats a la resta de la unitat.

Si l’executat té dimensions inferiors al projectat, sigui per ordre de la Direcció oper error d'execució, la medició per abonament serà la medició d'allò realmentexecutat.

Les peces i unitats soltes es valoraran com a tals aplicant la mesura apropiadasegons els preus que figurin al mercat.


Pàg. 219

5.5.2. Preus unitaris

El preu unitari que apareix en lletra a l’apartat de preus unitaris del pressupost seràel que s'aplicarà a les medicions per obtenir l’import d'execució material de cadaunitat d'obra. La descripció de les operacions i materials necessaris per executar launitat que figura als corresponents articles del present plec no és exhaustiva sinómerament enunciativa, per a la millor comprensió dels conceptes que s'inclouen acada unitat.

Per aquest motiu, les operacions o materials no relacionats però necessaris perexecutar en la seva totalitat la unitat d'obra formen part de la unitat iconseqüentment es consideraran inclosos al preu unitari corresponent.

5.5.3. Pagaments

En subscriure el contracte, l'empresa adjudicatària percebrà el 35% del total delpressupost i en donar per acabada l’instal·lació percebrà un altre 35%. El 30%restant quedarà com a garantia durant sis mesos.

Si transcorregut aquest període no s'ha detectat cap anomalia s’abonarà aquestaquantitat i al seu moment es consideraran finalitzades les obligacions existentsentre les dues empreses o entitats.

5.5.4. Multes

En cas que no siguin complerts els terminis de muntatge concretats, es reduirà el0.01% del total de l'import per cada dia que excedeixi l'esmentat termini.


Pàg. 220

5.5.5. Revisió de preus

L'adjudicatari d'aquest muntatge podrà sol·licitar la revisió del preu unitari,sempre i quan aquest es consideri superior a 10% del pressupost. Igualment estindrà dret per part de l'administració, en cas contrari.


Pàg. 221

5.6. Condicions administratives

Per l'adjudicació d'aquest projecte s’obrirà concurs/subhasta pública mitjançantanuncis durant sis dies consecutius i podran presentar-s'hi totes les empreses oentitats, radicades dins el territori de l'estat o comunitat, que ho sol·licitin.

5.6.1. Adjudicació i contractes

El departament d'adjudicació de la firma decidirà dins un termini de 15 dies apartir de la determinació de lliurament d'ofertes l'adjudicació de la instal·lació imuntatge.

Per aquesta finalitat, es tindran en compte els punts següents:

• Import econòmic.

• T ermini de lliurament.

• Condicions de garantia ofertes.

• Circumstancies dignes de consideració.

L 'empresa adjudicatària subscriurà el contracte davant notari, on a part delsextrems legals i els corresponents a les condicions econòmiques que s'indiquen,també es notificarà el termini de lliurament i conformitat amb la sanció que puguiderivar-se del seu incompliment.


Pàg. 222

5.6.2. Lliurament del projecte

L 'adjudicatari tindrà dret tant aviat com rebi l'ofici de l'adjudicació a disposard'una copia completa de cada un dels documents d'aquest projecte.

Els originals li seran facilitats per l'autor al seu domicili o oficina, sense que puguitreure'ls d'allí.

Quan l'adjudicatari o els seus delegats hagin obtingut les copies, les deixarà enmans de l'autor del treball, que un cop comprovada l'exactitud de la copia hocertificarà sota la seva pròpia signatura.


Pàg. 223Pàg. i


Pàg. 224

Continguts

1. MEMÒRIA DESCRIPTIVA

2. MEMÒRIA DE CÀLCUL

3. PLÀNOLS

4. PRESSUPOST

5. PLEC DE CONDICIONS

Pàg. ii


Pàg. 225Pàg. iii


Pàg. 226

Índex

1. MEMÒRIA DESCRIPTIVA 2

1.1. Introducció 3

1.2. Introducció al bus USB 41.2.1. Requisits necessaris del sistema 61.2.2. Funcions específiques de cada element 91.2.3. Entrant en matèria 151.2.4. Elements d’una transferència 161.2.5. Tipus de transferències 181.2.6. Enumeració d’un dispositiu 20

1.3. Objectius del projecte 241.3.1. Construcció del nostre perifèric 28

1.4. Hardware 301.4.1. Elecció dels components 30

1.5. Programació del dispositiu esclau 371.5.1. Procés d’enumeració 371.5.2. Respostes a comandes de control 471.5.3. Punter de comanda 691.5.4. Programació del dispositiu esclau 701.5.5. Configuració per a proves 80

1.6. Configuració del dispositiu segons el nostre sistema operatiu 811.6.1. Creació de l’arxiu INF 811.6.2. Execució i control de la nostra aplicació 83

1.7. Aplicació software executada en el Master 841.7.1. Funcions necessàries en la nostra aplicació 841.7.2. Classe CPFCDlg 891.7.3. Classe USBInterface 911.7.4. Variables i funcions globals 961.7.5. Resultat final 97

2. MEMÒRIA DE CÀLCUL 100

2.1. Introducció 101

2.2. Hardware 102

2.3. Programació del dispositiu esclau 104

Pàg. iv


Pàg. 227

2.4. Configuració del dispositiu segons el nostre sistema operatiu 130

2.5. Aplicació software executada en el Master 1322.5.1. Crides a funcions 1322.5.2. Codi de l’aplicació 169

3. PLÀNOLS 189


3.2. Esquema elèctric 191

3.3. Circuits impresos 1923.3.1. Disseny de la placa 1923.3.2. Transparència 193

3.4. Components 195

4. PRESSUPOST 197


4.2. Mesures 199

4.3. Preus unitaris 200

4.4. Pressupost 201

4.5. Resum del pressupost 202

5. PLEC DE CONDICIONS 204


5.2. Condicions generals 2065.2.1. Descripció 2065.2.2. Execució 2065.2.3. Recepció 2065.2.4. Responsabilitat 2075.2.5. Modificacions 2075.2.6. Manteniment 2085.2.7. Supervisió 2085.2.8. Transport 2085.2.9. Anul·lació del contracte 209

5.3. Condicions tècniques 2105.3.1. Generalitats 2105.3.2. Normativa aplicada 2105.3.3. Utilització 2105.3.4. Valors límits 2115.3.5. Circuits integrats 2115.3.6. Transistors i díodes 2115.3.7. Resistències 212

Pàg. v


Pàg. 228

5.3.8. Condensadors 2135.3.9. Circuits impresos 2135.3.10. Muntatge i cablejat intern 2145.3.11. Alimentació del muntatge 214

5.4. Condicions facultatives 2155.4.1. Generalitats 2155.4.2. Direcció 2155.4.3. Realització 2165.4.4. Materials 2165.4.5. Construcció 217

5.5. Condicions econòmiques 2185.5.1. Medicions 2185.5.2. Preus unitaris 2195.5.3. Pagaments 2195.5.4. Multes 2195.5.5. Revisió de preus 220

5.6. Condicions administratives 2215.6.1. Adjudicació i contractes 2215.6.2. Lliurament del projecte 222

Pàg. vi

comunicacions mitjan§ant el bus usb - inici

Documents