Mòdul d’Entrada/Sortida controlat via USB - deeea.urv.catdeeea.urv.cat/public/PROPOSTES/pub/pdf/828pub.pdf · 2.8.2.2 Component DLP-245M ... Pau a Tarragona. 2.2 Objecte del projecte

Mòdul d’Entrada/Sortida controlat via USB

Titulació: Enginyeria Tècnica Industrial en Electrònica Industrial

AUTOR: Lluís Llauradó Caballé

DIRECTORS: Dr. Ernest Gil Dolcet

DATA: Gener / 2006


2

1. ÍNDEX GENERAL


3

1. Índex General .....................................................................................1

2. Memòria Descriptiva ..........................................................................5

2.1 Fulls d’identificació........................................................................................6

2.1.1 Títol del projecte.....................................................................................6 2.1.2 Titular del projecte.................................................................................6

2.2 Objecte del projecte.......................................................................................6

2.3 Antecedents....................................................................................................6

2.4 Ordre del Document de Projecte.................................................................7

2.5 Idea Bàsica del projecte................................................................................8

2.5.1 Idea Bàsica Global................................................................................8 2.5.2 Possibles solucions i solució adoptada................................................11 2.5.3 Possibles aplicacions del projecte.........................................................11 2.5.4 Modalitats de funcionament del FT245BM.......................................12

2.6 Introducció al bus USB...............................................................................13

2.6.1 Requisits necessaris del sistema...........................................................14 2.6.2 Conceptes..............................................................................................16 2.6.3 Funcions específiques de cada element................................................17 2.6.4 Funcions del HC Controller.................................................................17 2.6.5 Funcions dels Hubs..............................................................................19 2.6.2 Funcions del perifèric..........................................................................20 2.6.2 Funcions del Sistema operatiu.............................................................21 2.6.2 Entrant en matèria al bus ....................................................................23 2.6.2 Tipus de transferències ........................................................................24

2.7 Normes y referències..................................................................................26

2.7.1 Bibliografia........................................................................................26 2.7.2 Programes de càlcul...........................................................................27

2.8 Descripció General.....................................................................................29

2.8.1 Software:..............................................................................................29

2.8.1.1 Funcions necessàries en la nostra aplicació.....................................................29 2.8.1.2 Drivers Software................................................................................................29 2.8.1.3 Classic Interface Functions..............................................................................34 2.8.1.4 Descripció de cada funció Clàssica d’interface...............................................39 2.8.1.5 Diagrames de flux.............................................................................................47 2.8.1.6 Manual d’usuari de l’aplicació........................................................................49


4

2.8.2 Hardware:..........................................................................................51 2.8.2.1 Descripció general del hardware......................................................................51 2.8.2.2 Component DLP-245M.....................................................................................52 2.8.2.3 Tipus de alimentació del DLP-USB245M........................................................54 2.8.2.4 Altres components.............................................................................................58

2.9 Planificació................................................................................................59

3. Memòria de càlcul..........................................................................60

3.1 Codi del dispositiu esclau (AT89C51).....................................................61

3.2 Codi de l’aplicació amb Visual ©++.......................................................63

4. Plànols.............................................................................................80

4.1 Introducció: .............................................................................................81

4.2 Esquema elèctric......................................................................................82

4.3 Circuits impresos.....................................................................................83

4.3.1 Disseny de la placa...........................................................................83 4.3.2 Components......................................................................................84

5. Pressupost......................................................................................85

5.1 Introducció...............................................................................................86

5.2 Mesures....................................................................................................87

5.3 Preus unitaris..........................................................................................88

5.4 Pressupost................................................................................................89

5.5 Resum del Pressupost.............................................................................90

6. Plec de Condicions........................................................................91

6.1. Introducció ...........................................................................................92

6.2. Condicions generals...............................................................................93

6.2.1.Descripció...........................................................................................93 6.2.2. Execució............................................................................................93 6.2.3. Recepció.............................................................................................93 6.2.4. Responsabilitat..................................................................................93 6.2.5. Modificacions....................................................................................94 6.2.6. Manteniment.....................................................................................94 6.2.7. Supervisió..........................................................................................94 6.2.8. Transport...........................................................................................94 6.2.9. Anul·lació del contracte....................................................................95


5

6.3. Condicions tècniques...........................................................................96

6.3.1.Generalitats.......................................................................................96 6.3.2. Normativa aplicada.........................................................................96 6.3.3. Utilització........................................................................................96 6.3.4. Valors límits.....................................................................................96 6.3.5. Circuits integrats.............................................................................97 6.3.6. Transistors i díodes.........................................................................97 6.3.7. Resistències......................................................................................97 6.3.8. Condensadors..................................................................................98 6.3.9. Circuits impresos.............................................................................98 6.3.10. Muntatge i cablejat intern............................................................98 6.3.11. Alimentació del muntatge............................................................99

6.4. Condicions facultatives....................................................................100

6.4.1. Generalitats...................................................................................100 6.4.2. Direcció.........................................................................................100 6.4.3. Realització....................................................................................101 6.4.4. Materials.......................................................................................101 6.4.5. Construcció...................................................................................101

6.5. Condicions econòmiques.................................................................102

6.5.1. Medicions.....................................................................................102 6.5.2. Preus unitaris...............................................................................102 6.5.3. Pagaments....................................................................................102 6.5.4. Multes...........................................................................................103 6.5.5. Revisió de preus...........................................................................103

6.6. Condicions administratives............................................................104

6.6.1. Adjudicació i contractes...............................................................104 6.6.2. Lliurament del projecte................................................................104


6

2. MEMÒRIA DESCRIPTIVA


7

2.1 Fulls d’identificació

2.1.1 Títol del projecte


2.1.2 Titular del projecte

TECHNOCHIP associat a la Xarxa de Centres d’Innovació tecnològica de Catalunya, director del centre Dr. Pere Pijoan Fibla. Ubicat al campus Sescelades de Sant Pere i Sant Pau a Tarragona.

2.2 Objecte del projecte L’objectiu d’aquest projecte és dissenyar un control de comunicacions entre un PC i un microcontrolador via USB, per així poder controlar la lectura d’entrades o activar determinades sortides d’un dispositiu esclau mitjançant una aplicació Windows executada en un PC estàndard

2.3 Antecedents Aquest projecte ha sigut una actualització i millora d’un altre projecte presentat fa uns anys, es pot dir que és completament nou ja que s’ha elaborat un nou pcb amb un canvi de microcontrolador, un canvi de USB controller i una nova implementació de l’aplicació de baix i alt nivell incrementant així la seva compatibilitat per a poder integrar-se a altres projectes que requereixin el bus USB.


8

2.4 Ordre del Document de Projecte

Segons la normativa de projectes de la ETSE la descomposició dels documents tindran aquest ordre:

1- Índex.

2- Memòria Descriptiva.

3- Memòria de Càlcul.

4- Plànols.

5- Pressupost.

6- Plec de condicions.


9

2.5 Idea Bàsica del projecte

2.5.1 Idea Bàsica Global

Fins el moment hem descrit les possibilitats del bus USB i hem conegut els avantatges i les limitacions que ens aporten els drivers que incorpora el sistema operatiu Windows relacionats amb la classe Human Interface Device. El següent pas és especificar els objectius que ens marquem. Un cop hàgim especificat els objectius veurem els passos que hem de seguir tant a nivell del hardware com en el software per acomplir-los. Finalment intentarem posar-ho tot a la pràctica per veure funcionar el nostre perifèric i comprovar com interactua amb la nostra aplicació que executem des de l’ordenador. Començant a descriure els objectius, el primer que hem de dir és que la finalitat primera d’aquest projecte és interaccionar amb un perifèric que utilitzi el bus USB. Hem de poder rebre i enviar informació del nostre ordenador i establir una base ferma des de la qual es pugui, més endavant, llençar projectes més ambiciosos sense tenir que començar de nou de zero. D’aquesta manera no pretenem comprovar tots els mètodes de transferència de dades existents ni necessitem crear un perifèric que suporti totes les possibilitats que ens permet el bus USB. Ja ens hem marcat els objectius principals. Per a dur-ho a terme el que farem es crear un perifèric el qual disposarà de 8 leds i 8 interruptors. Els interruptors estaran controlats per l’usuari i seran les entrades que el perifèric enviarà com a dades a la nostra aplicació software. Un cop aquesta informació estigui en el nostre ordenador, l’usuari tindrà la possibilitat de observar aquesta interactuació Aquesta operació s’aplicarà a l’entrada rebuda del perifèric i a uns interruptors virtuals que estaran controlats de la pròpia aplicació software pel mateix usuari. Finalment, el resultat d’aquesta operació s’enviaran de l’aplicació software al perifèric que la donarà a conèixer a l’usuari a través dels leds mencionats al principi.


10

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

Figura 1. Gràfic de l’Idea Global

L’utilitat pràctica d’aquesta aplicació tot i semblar molt senzilla, amb unes modificacions insignificants tant en el Hardware com en el llenguatge c (usat per a la programació del dispositiu esclau del interface USB en el nostre perifèric) es podria convertir en una eina molt potent. Una possible aplicació seria, per exemple, en el control d’obertura de portes o finestres d’una sala, informació que es podria enviar sense tenir que fer cap operació complicada a un ordenador el qual connectaríem al perifèric mitjançant el bus USB. A partir d’aquí es podria enviar informació d’hora d’obertura, hora en que es tanca ... tot amb el senzill fet de connectar el perifèric al ordenador sense tenir que aplicar cap configuració especial a cap de les dues parts ni tenir que resetejar-los amb els avantatges que el bus ens facilita. Hem intentat que el conjunt inclogui lectures, escriptures i control i veurem amb més detall com ho hem aconseguit i els passos que hem seguit per a que tot el conjunt funcioni. El que farem tot seguit és establir uns passos per al disseny del conjunt. Aquests passos són els que hem seguit per al disseny del nostre sistema i seran per tant, els mateixos que seguirem per fer una explicació detallada dels components del projecte, la seva utilitat i la seva configuració.

Aplicació Windows

PCB – Placa USB

SWITCHES LED’s

PLACA CONTROL

PC

USB

DATA OUT DATA IN


11

Per a crear qualsevol projecte relacionat amb l’estàndard USB i per a que aquest funcioni, es recomanable fer una realització a partir de mòduls i no passar al següent pas fins que l’anterior funcioni correctament. D’aquesta manera els passos a seguir en aquest projecte o en qualsevol que estigui basat en comunicacions amb el bus USB seran els següents: Delimitar les necessitats del perifèric com son ara: velocitats necessàries de transferència de l’aplicació (el qual ens definirà l’estàndard a seguir i els components a utilitzar), necessitats de drivers propis o possibilitat d’utilitzar els inclosos en el sistema operatiu, disponibilitat de circuits integrats, selecció d’un controlador i un interface USB ... Un cop tenim el primer pas clar i ja tinguem el material seleccionat, el següent pas és aconseguir que aquest conjunt sigui reconegut pel sistema operatiu (Windows XP en el nostre cas). Per aquesta finalitat, (si es possible sempre es recomana utilitzar un interface hardware subministrat pel propi fabricant del circuit integrat) hem d’escriure el programa en c per al dispositiu esclau que permeti que es dugui a terme correctament el procés de comunicació explicat anteriorment. De la mateixa manera que hem d’escriure en c com el perifèric ha de respondre a qualsevol de les peticions que el HC pot enviar com a comanda de control. Normalment el propi fabricant del circuit imprès en facilita documentació suficient. Quant ja tenim tot aquest material llest, el següent pas seria crear el hardware necessari per a que s’executi la nostra pròpia aplicació. Quant ja tenim el perifèric connectat i físicament preparat per a interactuar amb el PC, continuaríem amb el desenvolupament del llenguatge C que permeti l’intercanvi d’informació per a que el hardware executi la nostra aplicació. En aquest punt ja estem preparats per a crear el software necessari en el nostre ordenador i la nostra aplicació. Es en aquest moment i si ho requereix l’aplicació quant hem de crear els drivers per comunicar-se amb el perifèric (com hem vist no es necessari en el nostre cas però val la pena mencionar-ho). Finalment l’últim dels passos seria comprovar que el conjunt funciona correctament i prendre mesures de la fiabilitat del sistema. Hem de tenir sempre present, com hem comentat anteriorment, que no podem passar 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 no funciona correctament.


12

2.5.2 Possibles solucions i solució adoptada

En el projecte anterior es va fer servir un xip de Philips anomenat PDIUSBD12 aquest xip permet molta varietat de funcionalitats destacant, DMA operation, multi-configuration FIFO memory, Control de la sortida LazyClock durant l’estat de suspensió, la veritat es que aquest es un xip molt recomanable però bastant més difícil d’utilitzar que el FT245BM. Petita especificació del FT245BM Enviament i recepció de dades mitjançant USB a més de 1M Bytes/segon 384 bytes de buffer FIFO per transmissió i 128 bytes de buffer FIFO per recepció Fàcil interface entre CPU o MCU i el xip ( mitjançant 4 potes de control ) No necessita un gran coneixement del BUS USB. Virtual COM port drivers FTDI per la connexió USB mitjançant el port sèrie sense necessitat de cap driver. Integrat un regulador de 3.3v , amb aquest regulador no es necessari un regulador extern. Integrat un circuit de POWER-ON –RESET Transmissió de mode de dades per USB Bulk o asíncrona de 4.4v-5.25v agafant l’alimentació directament del port USB. UHCI / OHCI / EHCI host controller compatible Compatible per USB 1.1 i USB 2.0 Compatibilitat del VIRTUAL COM PORT (VCP) -W98 i W98 SE / W2000 / ME / XP / W CE / MAC OS-8-9 / MAC OS-X / Linux 2.40 o major Compatibilitat del D2XX ( USB direct Drivers + DLL S/W interface ) W98 / W98 SE / WINDOWS 2000 / WINDOWS ME / WINDOWS XP

2.5.3 Possibles aplicacions del projecte

• ISDN i ADSL USB modems • Integració dins d’una PDA. • Integració per a cameres digitals • Integració per reproductors de MP3 • Instrumentació de alta velocitat per USB. • Targetes de lectura (SC) • Integració en Modems Hardware / Wireless • Lectors de Codis de barres. Etc......


13

2.5.4 Modalitats de funcionament del FT245BM

Dins del FTDI FT245BM podem trobar dues modalitats de funcionament la primera correspon a Virtual COM Port i la segona a D2XX ( USB direct Drivers + DLL S/W interface ). Virtual COM Port ( VCP ) Aquesta opció es molt bona per aquells qui no vol una gran velocitat de transmissió ja que es capaç de comunicar-se a 300 Kilobytes / Segon, d’altra banda és una bona opció si es vol un una comunicació sense intervenció de drivers externs ni complicació en el disseny del sistema, és quasi directament un pont entre USB-COM port, Crea al sistema un port virtual per la transmissió de dades tal com ho fa USB però sense la gran velocitat de comporta, en resum diríem que es una solució per qui vulgui integrar USB al seu dispositiu sense preocupar-se de cap driver ni configuració. D2XX ( USB direct Drivers + DLL S/W interface ) Aquesta opció ha sigut la escollida ja que es volia aconseguir un ratio de transferència lo mes gran possible, ja que aquest projecte ha de servir per la integració de mòduls per el seu futur desenvolupament. El funcionament de la opció escollida és : La arquitectura de els drivers D2XX consisteix que els Windows WDM driver que comunica amb el dispositiu via Windows USB stack i una DLL la qual interactua amb l’aplicació de software ( escrita en Visual ©++, © ++Builder, Delphi,VB etc... ) al WDM driver, més endavant descriurem quines opcions han sigut escollides per la implementaria del codi i llenguatges.


14

2.6 Introducció al bus USB Amb l’arribada d’ordenadors més potents destinats als usuaris domèstics, s’han fet patents unes necessitats que aquests fins al moment no tenien o solucionaven de forma poc satisfactòria. D’aquesta manera, es tenia que eliminar el llast que suposava la limitada capacitat d’ampliació de l’aparell en quant a número de perifèrics i la forma que tenia l’usuari per a interconectar-los amb l’ordinador, al igual que es tenia que eliminar la dificultat que això podia suposar en certs casos on 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ó amb aquests perifèrics i finalment es necessitava un sistema estàndard, homologat i relativament barat per a poder llançar diferents productes al mercat d’una forma més econòmica. Tot això es el que va motivar un grup d’investigadors a desenvolupar un nou estàndard per a la connexió de perifèrics a l’ordenador. Aquests van desenvolupar el USB (Universal Serial Bus). Un protocol destinat a solucionar les limitacions anteriors amb uns avantatges difícils de superar. Aquests son el sues principals avantatges respecte el port sèrie o paral·lel existents actualment: ‘Hot-pluged’, el perifèric es pot connectar directament a l’ordenador sense tenir la necessitat de resetejar la màquina. Facilitat d’us, el nou hardware es configura automàticament i els drivers necessaris es carreguen al detectar la connexió del dispositiu. Connector unificat, tots els fabricants han de seguir l’estàndard a l’hora de llançar nous productes el qual inclou una definició per als connectors. Bon comportament, el protocol permet un comunicació fins a 12Mbps superior a la que ofereixen solucions usades actualment. Fins a 128 perifèrics. Si la configuració ho permet, es poden connectar en un sol ordenador un gran número de perifèrics. Alimentació pel propi cable, quant el perifèric requereix una petita alimentació, aquesta la pot subministrar el propi ordenador. Els dispositius es desconnecten automàticament quant no estan essent utilitzats. Deteccions d’errors i solució dels mateixos pel propi protocol de comunicacions. No hi ha necessitat d’obrir l’ordenador per a permetre la connexió de nous perifèrics. Suport pel propi sistema operatiu en quant a disponibilitat de drivers necessaris.


15

No obstant no ens podem quedar exclusivament amb el avantatges que ens ofereix aquest nou protocol, hem d’ésser conscients, de la mateixa manera, de les limitacions 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 (sistema operatiu mínim recomanat Windows 98 o superior). Limitacions en la velocitat, molt superior als mitjans anteriors però encara limitat. Distancia limitada, la llargada màxima del cable es de 5 m. que el converteix en un protocol on tots els perifèrics han d’estar relativament a prop. Novetat en el producte que fa que alguns perifèrics del mercat no s’adaptin del tot al protocol i puguin no funcionar correctament. Complexitat en el protocol al tenir que programar el hardware per a que s’adapti al protocol establert per a les comunicacions. Sistemes de comunicació limitats i sempre amb comunicacions desencadenades pel controlador principal (comunicacions per polling). Temps compartit entre tots el dispositius connectats el que implica que a més elements pot arribar a disminuir el rendiment del sistema.

2.6.1 Requisits necessaris del sistema

El primer que farem serà enunciar els aspectes mínims que ha de complir l’ordenador amb la finalitat que la nostra aplicació es pugui comunicar amb el perifèric dissenyat: El sistema operatiu ha de tenir el suport necessari per a les comunicacions mitjançant USB. D’aquesta manera, el desenvolupament del producte es molt més senzill si el sistema operatiu aporta les eines necessàries. Windows 95 ja disposa d’algun del mitjans en les últimes versions però aquests es veuen millorats en gran mesura amb l’aparició del Windows 98. No obstant les plataformes que fan servir el sistema operatiu DOS, Windows 3.x o Windows NT v.4.0 no disposen de cap suport per a dites comunicacions tot i que hi ha drivers específics aportats per terceres companyies que ens podrien fer servei. Al igual que Windows 98, Windows 2000, Windows XP ja disposa de totes les eines necessàries. Per facilitar el desenvolupament del projecte la nostra aplicació està orientada a usuaris els quals disposen d’una plataforma amb el sistema operatiu Windows XP. De la mateixa manera l’ordenador ha de tenir un controlador per a comunicacions amb USB sense el qual aquestes son impossibles. Actualment la majoria d’ordenadors que


16

surten al mercat disposen d’un controlador amb dos ports. Si aquest no es el cas, molts fabricants han tret al mercat targetes PCI amb el controlador i els ports necessaris inclosos. Els components existents en la part de l’ordenador el componen un HC (HC Controller) o controlador principal que es l’encarregat de formatejar les dades per a la seva transmissió i el (Root Hub) o hub principal que es l’encarregat de detectar l’annexió de nous components que poden ser perifèrics connectats als nodes de sortida o més Hubs, i és al mateix temps, l’encarregat de transmetre les informacions i peticions del l’HC als diferents nodes. Gràficament, tot el sistema podria descompondre en un seguit de connexions en mode piramidal com el que podem veure tot seguit:

Figura 2. Gràfic Host-Hub

La connexió es pot realitzar en forma de cascada, connectant a la sortida del Hub principal 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 de Hubs que es poden posar en cadena i 128 el número màxim de perifèrics o nodes que es poden connectar al sistema sempre que l’ample de banda i els recursos disponibles ho permetin com veurem més endavant.


17

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

2.6.2 Conceptes

En el món de l’USB hem de distingir i tenir clars els següents conceptes que son bàsics per a la comprensió del protocol: HC Controller (HC), que com hem vist abans i comentarem més endavant es l’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 exemple un teclat té una funció per a comunicar la tecla premuda i una de diferent per il·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 a altres components que poden ésser més perifèrics o altres hubs. Aquests han de tenir 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 un component pot estar format per un perifèric i s’hi pot incloure funcions de Hub, la qual 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 seva pròpia traducció és el final i origen de tota comunicació en el bus. Cada dispositiu disposa d’un mínim d’un endpoint de control més els que siguin necessaris per a la pròpia finalitat de l’aplicació. Finalment aclarirem el concepte de port el qual es diferent al que estàvem acostumats 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ò a diferencia de l’anterior només tenim el HC (HC Controller) amb una direcció de memòria la qual cosa implica que tots els perifèrics, tot i tenir la seva connexió i cables propis, comparteixen el temps i espai en memòria de comunicació i sols un dels perifèrics o el HC pot enviar informació en cada instant.


18

2.6.3 Funcions específiques de cada element

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

2.6.4 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 estan connectats i saber, de la mateixa manera, que pot i ha de fer cadascun d’aquests perifèrics. Tots aquests perifèrics han de poder enviar i rebre informació però com que el temps 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 XP fa que l’aplicació sols necessiti enviar i rebre informació la qual cosa fa que la forma en que això es realitza sigui transparent per a l’usuari i el dissenyador de l’aplicació. D’aquest forma el dissenyador del software sols ha de conèixer unes funcions, algunes de les quals veurem més endavant 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 a que respongui a unes instruccions del HC sense necessitat de conèixer quin es el comportament del software. Continuant amb les funcions del HC, aquest ha de configurar un component quant el Hub detecta que aquest s’ha connectat al sistema. Això es realitza mitjançant un procés que s’anomena enumeració. En aquest procés el HC designa una adreça per al 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 correcte funcionament del perifèric.


19

Totes les transmissions es realitzen en finestres d’1 milisegon de durada, això vol dir que en aquest espai tots el perifèrics tenen un marge assignat pel HC per a rebre i enviar informació. Durant el procés d’enumeració cada perifèric informa al HC de l’ample de banda que necessita per a comunicacions amb ample de banda garantit (com poden ésser equips de música que necessiten rebre informació de forma continuada i de forma ininterrompuda). Si l’ample de banda que requereix el perifèric no està disponible per la saturació del sistema es denega al perifèric l’ús del bus. Es llavors quant el driver pot demanar un ample de banda inferior o esperar que aquest estigui disponible per a poder funcionar. Una altra responsabilitat del HC consisteix en controlar l’informació per a poder determinar si hi ha hagut errors en la comunicació. D’aquesta manera pot afegir informació per a que aquesta estigui enviada de forma redundant o be enviar bits per a controlar errors. En cas de que existeixin errors es procedeix al reenviament de l’informació. De totes maneres existeix la possibilitat d’enviar informació evitant que aquesta es vegi sotmesa a controls de paritat o d’errors de forma que es garanteixi una quantitat de dades transmeses quant no es necessari o no es pot perdre temps per mirar si aquesta té errors o no. També es feina del HC detectar quant un perifèric te problemes en la recepció o transmissió d’informació, en aquest cas avisa al driver que al seu temps avisa l’aplicació que hauria de prendre les mesures corresponents per a solucionar el problema. Finalment destacarem com a una última funció del HC alimentar els perifèrics sempre que aquest ho demanin i aquests compleixi unes condicions (consum màxim limitat, possibilitat d’entrar en estat de Suspens reduint al mínim el consum però amb atenció al canal de comunicacions per a despertar quant sigui requerit).


20

2.6.5 Funcions dels Hubs

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

Figura 3. Gràfic Host-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 de comunicar-se amb el HC per informar-l’ho de la presencia de dispositius nous acabats de connectar. Una altra gran funció per a la qual estan dissenyats els Hubs és la de transmetre informació del HC fins a la posició física del dispositiu, comunicant-se amb altres Hubs si es necessari. Finalment hem de destacar la tercera tasca per a la qual es imprescindible aquest dispositiu. Es l’encarregat de detectar dispositius que funcionen de forma incorrecta i un cop localitzats inhabilitar el port al qual estan connectats. D’aquesta forma aquest dispositiu no pot interferir en el correcte funcionament de la 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 nostre perifèric.


21

2.6.6 Funcions del perifèric

La principal funció que ha de complir un perifèric es la d’observar i respondre a les peticions del HC. Apart d’això s’ha de tenir en compte que aquests tenen funcions pròpies que depenen en cada cas de la finalitat per a la qual ha estat dissenyat 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 per polling o per resposta a peticions. El controlador USB o interface que incorpora cada perifèric controla en gran part les comunicacions amb el HC, de totes maneres depenent d’aquest controlador veurem fins a quin punt hem de programar en el dispositiu esclau de l’interface part de les respostes. Cada perifèric controla en tot moment les comunicacions que es realitzen en el sistema, 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 el HC amb anterioritat. es i prendre les accions necessàries que la comanda impliqui. El procés d’enumeració introduït amb anterioritat, està compost per 11 comandes de control concretes, el perifèric ha d’estar capacitat per a respondre a cada una d’ell Al igual que el HC envia bits de paritat, el perifèric ha de prendre les mesures pertinents quant detecta un error que en el seu cas equival a validar l’informació o ignorar-la quant detecti un error en aquesta. Si el perifèric està alimentat pel propi bus, a de complir les condicions necessàries per a complir amb les limitacions que això imposa. Aquestes limitacions són consumir no més de 500 mA en funcionament estàndard, no consumir més de 100 mA durant el procés d'enumeració o consumir un màxim d’entre 0.5 i 2.5 mA depenent de la configuració en estat d’Standby.


22

2.6.7 Funcions del Sistema operatiu

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

Figura 4. Diagrama de flux OS

Win32 APIs

I/O request packets

I/O request packets

Interface específic del Hardware

Aplicació

Subsistema Win32

Modo Usuari

Hardware DD

Bus Drivers

Modo Kernel

Hardware


23

Com veiem, Windows XP fa servir un model escalar per als Drivers amb diversos Drivers per connectar els components i els seus diferents bussos. Si considerem un Driver com un programa de software específic que fem servir per comunicar-nos amb un dispositiu de hardware, el primer que hem de fer es especificar quin es el driver que el nostre perifèric farà servir per relacionar-se amb el sistema i en concret 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 ésser creat específicament per a un perifèric en qüestió o, com en la solució que apliquem nosaltres, utilitzar els drivers que facilita Windows XP. Els passos que es segueixen per a completar el trencaclosques al que ens referim son els següents: en primer lloc hem de connectar el dispositiu, Windows en aquest punt comença automàticament el procés d’enumeració a partir del qual, i un cop obtingudes les taules descriptores del dispositiu les compara amb els arxius de descripcions *.INF d’on obté els drivers necessaris que pugui necessitar cadascun dels dispositius que componen la base de dades d’històrics amb dispositius 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és endavant. Primer definirem que és un HID. El bus USB engloba un conjunt de classes o grups de dispositius que es consideren que tenen unes característiques semblants la 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 garanteix que aquests tindran unes necessitats de comunicacions molt semblants amb la qual cosa podrem fer servir els mateixos drivers sense que això ens limiti les capacitats funcionals. Una de les primeres classes que fins al moment esta suportada plenament pel sistema operatiu son els HID que es poden generalitzar com perifèrics que interactuen directament amb l’usuari com per exemple teclats o ratolins. No obstant s’espera que en un futur no molt llunyà Windows XP o els posteriors aportin els drivers necessaris per a totes les classes.


24

2.6.8 Entrant en matèria al bus

El que veurem a continuació son els passos que el bus segueix per enumerar-se passar informació i descripcions que ens ajudaran a entendre el que fem. De totes maneres aquest apartat no intenta ésser un resum del que es pot trobar a les especificacions del USB sinó una explicació par a orientar a gent que sense voler saber-ho tot vol saber una mica més La versió 1.0 del protocol USB suporta 2 velocitats de transmissió diferents. En els 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 formats d’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 en concret. S’ha de tenir en compte que existeixen diferencies rellevants amb el de baixa velocitat però que no destacarem. El bus USB consisteix en un seguit de comunicacions bidireccionals entre un controlador principal i diversos perifèrics. Això es compleix mitjançant quatre cables, dos per a l’alimentació (Vcc amb una tensió de 5 Vols i massa) i dos línies de dades D+ i D-. La transmissió que es realitza físicament és half-duplex (que significa que parla un després de l’altre) a partir d’una transmissió diferencial on l’element fonamental de comunicació son els paquets. Aquests s’envien codificats en el format NRZI (nonreturn to zero inverted) de codificació en les línies de transmissió de dades. Per últim també considerem destacable a comentar que no hi ha senyal de Clock per la qual cosa es considera un protocol asíncron. De totes maneres son necessàries les transicions en les transmissions per a mantenir el sincronisme ja que cada perifèric incorpora el seu oscil·lador.

Figura 5. Cable USB

Per començar podem distingir les comunicacions ens dos grans grups la configuració 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 la segona porta a terme les funcions per a les quals s’ha dissenyat el dispositiu.


25

2.6.9 Tipus de transferències

Els següent que hem de definir son els tipus de transmissions de que els perifèrics disposen per acomplir la seva finalitat. Aquestes son 4 i com hem vist anteriorment no tots ells estan disponibles per a cada classe, ni totes les classes els han de fer servir tots. D’aquesta manera un tipus de transmissió crucial per una classe pot no estar present en una altra. Tots els tipus de transferència tenen unes característiques diferents que determinaran la prioritat i quantitat d’informació que es transmetrà en el bus. Control transfers (Transferències de control): totes les classes suporten aquest tipus 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 han de respondre tots els perifèrics. Aquest tipus de transferència tenen prioritat en el perifèric. Així doncs un perifèric ha de prioritzar respondre a aquestes transferències de controls a enviar dades que pugui tenir emmagatzemades. Bulk transfers (Bolcat d’informació): és una transmissió on no es fonamental la velocitat en la transmissió però si ho és la gran quantitat d’informació i una correcta transmissió d’aquesta. Aquest sistema el fan servir perifèrics tipus impressora, escaners... Interrupt transfer (Interrupció): el fonamental en aquesta transmissió es obtenir l’atenció del HC de la manera més ràpida possible. De totes maneres dir que es una transferència d’informació per mitjà d’una interrupció es podria classificar de molt generós ja que el que es fa amb anterioritat és designar una freqüència de mostreig del perifèric per a mirar si aquest té informació preparada per a ésser transmesa, així doncs més aviat seria un polling. Isochronous transfer (Transferència síncrona): el que premia aquest tipus de transferència es la velocitat en la transmissió ja que es requereix que en una certa quantitat de temps certa quantitat d’informació s’hagi transmès. Per aconseguir aquest objectiu es desactiva el sistema de detecció d’errors per no perdre temps en la correcció de l’informació rebuda amb errors. Un exemple seria uns altaveus on no és crucial rebre certa informació de forma correcta més que rebre certa quantitat d’informació. En la taula següent veiem una comparativa de les característiques comparant entre els diferents tipus de transmissió:


26

Tipus de transferència

Control Bulk Interrupt Isochronous

Us normal Configuració Impressores, escaners...

Teclat, ratolins Àudio

Imprescindible Si No No No

Permès en baixa velocitat Si No Si No

Transferència màxima per milisegon (bytes) 832 1216 64 1023

Transferència màxima en baixa velocitat 24 0,8

Ample de banda reservat (%) 10 Cap 90

Correcció d’errors Si Si Si No

Tipus d’informació Missatge Cadenes Cadenes Cadenes

Transferència garantida No No No Si

Existeix temps d’espera màxim No No Si Si

Suportat per la classe HID Si No Si No

Figura 6. Taula de tipus de transferència

Es de destacar que el bus USB es guarda un 10% del temps d’execució per executar transferències de control i un 90% del temps per executar transferències d’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èric pertanyent a la classe HID limitem els tipus de transferència disponibles a Control i Interrupció. De totes maneres no és l’objectiu d’aquest projecte obtenir uns resultats que no es puguin aconseguir amb aquests dos tipus de transmissió.


27

2.7 Normes y referències

2.7.1 Bibliografia

Llibres / PFC

• Universal Serial Bus System Architecture Don Anderson Ed. Mindshare Inc • USB Complete Jan Axelson Lakeview Research • USB Design by Example John Hyde Wiley • El lenguaje de programación C

Brian W. Kernighan, Dennis M. Ritchie Prentice Hall

• C++ The core language Gregory Satir, Doug Brown Nutshell • Programación avanzada con Visual C++ Kruglinski, Shepherd, Wingo Mc Graw Hill • Visual ©++ 6 ( Guia Completa ) Edgar D’Andrea InforBook’s Ediciones • Introducción a los microcontroladores José Adolfo González Vázquez Mc Graw Hill • Comunicacions mitjançant el bus USB

PFC : Jaume Solé i Pardines Internet

• http://www.usb.org

• http://www.microsoft.com

• http://www.intel.com

• http://www.philips.com

• http://www.lvr.com

• http://www.usbman.com

• http://www.dlpdesign.com/


27

2.7.2 Programes de càlcul

Els programes utilitzats per la elaboració del projecte són: Paquet P-CAD 2002 S’ha triat PCAD ja que és una eina molt mes potent que ORCAD i permet una facilitat d’ús major a part de que anteriorment ja havia treballat amb aquesta eina lo que suposa un estalvi de hores d’aprenentatge. Dins del paquet P-CAD s’han utilitzat diverses eines per el disseny de components tant de forma esquemàtica com per pcb. Aquí podem veure quines aplicacions han sigut usades i per a que : P-CAD Schematic : Programa de disseny esquemàtic de circuits, amb aquest programa podem muntar el nostre circuit electrònic a mida mitjançant les eines de edició de components i configuració de cadascun. Per la completa edició de components P-CAD ha elaborat un altre aplicació anomenada PCAD Symbol Editor amb la que és possible crear al teu gust qualsevol tipus de component electrònic que estigui fora de les llibreries per defecte del propi programa PCAD. P-CAD PCB : Programa de disseny PCB de circuits, amb aquest programa podem fer el rutat del nostre circuit electrònic a partir del disseny del P-CAD Schematic, aquesta aplicació és molt interessant ja que pot elaborar mitjançant AUTO-ROUTER un rutat del pcb de forma automàtica triant unes regles concretes de rutat, així mateix la nostra placa ja que es tracta de una placa de desenvolupament i que el servei de creació de pcb de la URV no es capaç de crear pcb amb una exactitud adequada a aquesta aplicació vaig decidir de fer-ho de forma totalment manual assegurant així el mínim espai de components i una mida de pistes adequada per les necessitats del circuit, així mateix com te el P-CAD Schematic, amb P-CAD Pattern editor també es possible crear amb una sub-aplicació un component PCB particular fora de les llibreries PCAD, així es va fer i es van crear la majoria de components que després es van fer servir per el rutat de la placa. Keil Elektronik GmbH La Tria del software Keil es va fer per dur a terme un codi © fàcil d’entendre per qualsevol i també fàcil de reeditar per qualsevol que sàpiga el llenguatge, així com també per poder dur a terme una ampliació del codi segons les necessitats futures, Keil es capaç d’escriure en mode © o en mode assembler nosaltres vam triar Codi © Standard ja que es molt més editable i té moltes mes possibilitats a alt nivell que el assembler. Keil Software development tools per la família 8051 dóna suport a tots els nivells del desenvolupament de software desde el enginyer professional d’aplicacions fins els estudiants que volen aprendre sobre el desenvolupament del embedded software. Keil ofereix amb aquest paquet un compilador C Standard de la indústria, amb Macro Assemblers, Debuggers , Real-time Kernels.


28

Dins de Keil hi podem trobar varis subprogrames que intervenen en tot el procés de creació de codi embedded per a microcontroladors així com : U-Vision IDE : Aquesta aplicació combina la direcció de projecte, la facilitat d’ús, la edició de source code, el debugging del programa, i una gran entorn de completa simulació. L’editor i el debbuger estan integrats dins una sola aplicació i interactua amb un complet entorn de simulació que podrien ser , simulació de entrades, sortides, timers etc... Dins del U-vision IDE hi podem trobar : CX51 © Compiler: Es un compilador ANSI Standard © per arquitectura 51MX de Philips. Philips 51MX is una arquitectura basada en el microcontrolador 8051 que suporta 8 Mbytes de codi y 8 Mbytes de dades. CX51 Compiler ha de ser usat només per generar codi per 51MX i derivats. LX51 Enhanced Linker: LX51 combina la programació modular de objectes i crea els executables per aplicacions 8051. El Linker resol les external i plublic referències i assigna Adreces absolutes o fixes to segments relocalitzables del programa. LX51 processa fitxers objecte creats per C51 o A51 ( tant Codi © com codi Assembler ) també suporta Intel PL/M-51 i ASM-51 Assembler i genera mòduls objecte absoluts OMF2. Visual © ++ 6.0 Ha estat triat Visual © ++ ja que és el llenguatge per excel·lència de programació en sistema Windows, com que la nostra aplicació correrà per Windows OS, s’ha triat aquest programa. Visual © ++ és molt potent, capaç de crear qualsevol aplicació per Windows al ser © es capaç de baixar a baix nivell per configurar el sistema a l’estat que nosaltres desitgem.


29

2.8 Descripció General

2.8.1 Software:

2.8.1.1 Funcions necessàries en la nostra aplicació Un cop hem definit superficialment com serà físicament el nostre perifèric hem de determinar quines seran les funcions que la nostra aplicació farà servir per a comunicar-se amb el sistema i el perifèric en concret. D’aquesta forma el llenguatge de programació que farem servir serà el Visual C++, el qual ens permetrà una interacció més amplia amb el sistema apart de donar-nos eines per a construir una Interface més agradable per a l’usuari final de l’aplicació. De totes maneres el que volem realment en aquest apartat és mostrar quines seran les crides al sistema o que l’aplicació en si farà servir ja que suposem en aquest punt que el lector està més o menys instruït en el llenguatge de programació C/C++. La raó per la qual hem escollit aquest llenguatge de programació és entre d’altres motius pel fet que és relativament conegut i extens, es pot trobar molta documentació referent al llenguatge i la seva relació amb el protocol USB i en definitiva la seva gran modularitat a l’hora de programar farà del producte resultant un codi potent i extensible a altres aplicacions en quant es vulgui desenvolupar el projecte actual. També hem de destacar que fem servir crides al sistema que permeten la comunicació entre els drivers dels components i les aplicacions. L’inconvenient més gran que presenten aquestes crides és que requereixen que passem uns paràmetres molt determinats i que estan sols definits en C/C++ cosa que nosaltres solucionem al usar aquest mateix llenguatge. Si el nostre programa estès fet en un altre llenguatge, haguéssim necessitat adaptacions.

2.8.1.2 Drivers Software Els D2XX Direct Drivers per Windows ofereixen una solució per permetre una interacctuació entre l’aplicació de software amb el dispositiu FT245BM fent servir DLL’s. La arquitectura dels drivers de D2XX consisteixen de un Windows WDM driver que comunica amb el dispositiu FT245BM via Windows USB stack i una DLL que interactua amb la aplicació de Software( escrita amb VC++) a el WDM driver. Els D2XX Direct Drivers afegeixen el suport per simultanis accessos i control de múltiples dispositius FT245BM. Mitjançant la funció FT_OpenEx que permet obrir cada dispositiu per product description o per serial number, la funció FT_ListDevices permeten a la aplicació de software determinar quins dispositius estan actualment funcionant i els seus serial numbers i product descriptions.


30

Hi ha varies coses més que pot fer aquest driver, hi ha funcions específiques per programar una e2prom(FT_EE_Program), i llegir-la (FT_EE_Read). Sense fer servir espai addicional. ( dins el disseny hi ha una e2prom configurada ). Per entendre millor el funcionament del sistema es pot representar mitjançant un petit diagrama de flux.

Figura 7. Diagrama de flux interna d’aplicació WIN

Per instal·lar D2XX drivers per un dispositiu FT245BM sobre WINDOWS XP, s’han de seguir les següents instruccions. Un llistat d’aquestes crides al sistema es el següent:

• Si un dispositiu del mateix tipus ha sigut instal·lat al computador abans i els drivers que estan instal·lats son diferents als que instal·larem ara es necessari que els drivers originals es desinstal·lin.

Per desinstalar-ho ves a desinstal·lació D2XX drivers. Sinó segueix llegint. Descarregat els últims drivers per D2XX de la pagina FTDI i descomprimeix-los a qualsevol lloc del teu PC.


31

Si estàs treballant amb WINDOWS XP o Windows SP1, temporalment desconnecta el teu PC de internet. Això no es necessari si estàs treballant amb Windows XP SP2 si tens configurat el sistema de Windows Update com a preguntar abans de actualitzar. Connecta el dispositiu al connector USB del teu PC. Això engegarà una aplicació de Windows on detectarà automàticament que s’ha trobat un dispositiu. Seguint els passos del Wizard installation arribaràs amb aquesta pantalla.

Figura 8. Instal·lació Drivers pas 1


32

Clica a Finish i comprova que el dispositiu esta al teu sistema dins de administrador de dispositius de sistema.

Figura 8. Instal·lació Drivers pas 2

Ja s’haurà acabat l’instal·lació del driver D2XX.


33

Per desinstal·lar els D2XX drivers per el dispositiu FT245BM segueix aquestes instruccions: Desconnecta qualsevol dispositiu FTDI que estigui connectat al PC. Obre Dialog Afegir/Treure Programes utilitat dins de “\Panell de Control\Afegir/treure programes”. Selecciona “ FTDI FTD2XX USB Drivers “ de la llista de programes instal·lats.

Figura 9. Desinstal·lació Drivers pas 1

I clica el botó Canviar/Treure. Això carregarà el desinstal·lador FTDI. Apreta continuar desinstal·lant o Cancel·la per sortir. Quant el desinstal·lador hagi acabat de treure el dispositiu del teu sistema, el botó de cancel·lar s’ocultarà i només estarà operatiu el botó acaba, apreta’l i acaba el procés.


34

Figura 10. Desinstal·lació Drivers pas 2

Després de la explicació de com s’ha de instal·lar/desinstal·lar el driver D2XX explicarem de quina manera es pot accedir a aquesta dll per la seva programació. Podem accedir a la programació del driver de 2 maneres possibles mitjançant: Funcions Clàssiques d’interface ( Classic Interface Functions ) FT-Win32 API FT-Win32 API Són una alternativa a la interfície Clàssica, les API creades per FT es fan servir per el control del port, i poden ser convertides per fer-se servir a la interface D2XX simplement reemplaçant l’estàndard Win32 API calls per l’equivalent FT-Win32 API calls.

2.8.1.3 Classic Interface Functions

Són les funcions clàssiques per la comunicació entre l’aplicació i la dll, és la solució escollida ja que són més fàcils de fer servir ja que hi ha molta més ajuda d’aquest tipus de funcions que de les que proposa FT, ademés per el que consisteix el projecte no aporta cap millora per el comportament del xip. Aquests son les funcions utilitzades i la seva explicació.


35

Funció DLL Finalitat

FT_ListDevices D2XX.dll Recull la informació referent als dispositius connectats.

FT_Open D2XX.dll Obre el dispositiu i retorna la resposta a l’acció

FT_OpenEx D2XX.dll Obre un dispositiu determinat i retorna resposta a l’acció

FT_Close D2XX.dll Tanca el dispositiu obert.

FT_Read D2XX.dll Llegeix les dades del dispositiu

FT_Write D2XX.dll Escriu les dades al dispositiu

FT_ResetDevice D2XX.dll Envia una comanda de reset al Dispositiu.

FT_Purge D2XX.dll Purga la recepció i transmissió del buffer del dispositiu.

FT_SetTimeouts D2XX.dll Configura els timeout de escriptura i lectura del dispositiu

FT_GetStatus D2XX.dll Mira el status del dispositiu.

FT_GetQueueStatus D2XX.dll Captura el número de caràcters a la cua de recepció

FT_SetBreakOn D2XX.dll Configura la condició de BREAK del dispositiu

FT_SetBreakOff D2XX.dll Reseteixa la condició de BREAK del dispositiu

FT_SetEventNotification D2XX.dll Configura les condicions fer l’event de notificació

FT_GetDeviceInfo D2XX.dll Mira informació del dispositiu

FT_ResetPort D2XX.dll Envia una comanda de reset al port.

FT_GetLatencyTimer D2XX.dll Captura el valor actual del latency timer.

FT_SetLatencyTimer D2XX.dll Configura el latency timer.

FT_GetBitMode D2XX.dll Captura el valor instantani del bus de dades.

FT_SetBitMode D2XX.dll Configura el valor del bit mode.

FT_SetUSBParameters D2XX.dll Configura la petició de tamany del USB.

Figura 11. Taula de funcions FTDI

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


36

En aquest cas per a comunicar-se amb el dispositiu és una mica més complicat que enviar 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ó sobre com aquest ha de rebre l’informació (en el nostre cas això es una mica redundant ja que al haver dissenyat nosaltres el dispositiu sabem prèviament el tipus d’informació i la estructura que ha de tenir). Això ho fem mitjançant la crida d’unes funcions que detecten dispositius concrets. Aquest pas el podem fer anant directament al dispositiu que volem o fent una búsqueda recorrent. Un cop hem localitzat el dispositiu l’aplicació ha de crear els canals de comunicació i seguidament es pot comunicar amb aquest a partir d’enviar’l-hi i rebre'n dades amb un format concret que anomenarem ‘paquets’ el qual definim nosaltres i emmagatzemem en les taules descriptives del dispositiu que ja hem vist anteriorment. Amb aquest objectiu hem creat un programa amb Visual C++ que podríem descriure amb el següent diagrama de flux simplificat que mostrem a la pàgina següent:


37

Figura 12. Diagrama de flux del control USB

Programa Principal

Inicialització Variables

Buscar Perifèric Corresponent

Existeix el Dispositiu ?

No

Si

Error Perifèric

Creem el fil de lectura i escriptura

Rebem un caràcter

Modifiquem algun valor

Tractament i envio d’info.

Error al enviar

No No

Si


38

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ó una descripció de les funcions que hi podem trobar, quina és la seva aplicació i com fan la feina . Amb aquesta finalitat ens proposem desglossar la totalitat del programa en els següents apartats que tenen una relació directa amb la utilització del programa, els seus apartats i la seva execució.

Per aplicacions visual C ++, aquestes funcions han de ser pre-declarades dins el header FTD2XX.h la qual esta inclosa al driver realease. Per altres llenguatges, aquestes definicions seran convertides al tipus equivalent, i deuran definir-se l'arxiu include o dins el cos del codi.


39

2.8.1.4 Descripció de cada funció Clàssica d’interface

FT_ListDevices Get information concerning the devices currently connected. This function can return information such as the number of devices connected, the device serial number and device description strings, and the location IDs of connected devices. FT_STATUS FT_ListDevices (PVOID pvArg1, PVOID pvArg2, DWORD dwFlags) Parameters pvArg1 Meaning depends on dwFlags. pvArg2 Meaning depends on dwFlags. dwFlags Determines format of returned information. Return Value FT_OK if successful, otherwise the return value is an FT error code. Remarks This function can be used in a number of ways to return different types of information. In its simplest form, it can be used to return the number of devices currently connected. If FT_LIST_NUMBER_ONLY bit is set in dwFlags, the parameter pvArg1 is interpreted as a pointer to a DWORD location to store the number of devices currently connected. It can be used to return device information: if FT_OPEN_BY_SERIAL_NUMBER bit is set in dwFlags, the serial number string will be returned; if FT_OPEN_BY_DESCRIPTION bit is set in dwFlags, the product description string will be returned; if FT_OPEN_BY_LOCATION bit is set in dwFlags, the Location ID will be returned; if none of these bits is set, the serial number string will be returned by default. It can be used to return device string information for a single device. If FT_LIST_BY_INDEX and FT_OPEN_BY_SERIAL_NUMBER or FT_OPEN_BY_DESCRIPTION bits are set in dwFlags, the parameter pvArg1 is interpreted as the index of the device, and the parameter pvArg2 is interpreted as a pointer to a buffer to contain the appropriate string. Indexes are zero-based, and the error code FT_DEVICE_NOT_FOUND is returned for an invalid index. It can be used to return device string information for all connected devices. If FT_LIST_ALL and FT_OPEN_BY_SERIAL_NUMBER or FT_OPEN_BY_DESCRIPTION bits are set in dwFlags, the parameter pvArg1 is interpreted as a pointer to an array of pointers to buffers to contain the appropriate strings and the parameter pvArg2 is interpreted as a pointer to a DWORD location to store the number of devices currently connected. Note that, for pvArg1, the last entry in the array of pointers to buffers should be a NULL pointer so the array will contain one more location than the number of devices connected. The location ID of a device is returned if FT_LIST_BY_INDEX and FT_OPEN_BY_LOCATION bits are set in dwFlags. In this case the parameter pvArg1 is interpreted as the index of the device, and the parameter pvArg2 is interpreted as a pointer to a variable of type long to contain the location ID. Indexes are zero-based, and the error code FT_DEVICE_NOT_FOUND is returned for an invalid index. The location IDs of all connected devices are returned if FT_LIST_ALL and FT_OPEN_BY_LOCATION bits are set in dwFlags. In this case, the parameter pvArg1 is interpreted as a pointer to an array of variables of type long to contain the location IDs, and the parameter pvArg2 is interpreted as a pointer to a DWORD location to store the number of devices currently connected.


40

FT_Open Open the device and return a handle which will be used for subsequent accesses. FT_STATUS FT_Open (int iDevice, FT_HANDLE *ftHandle) Parameters iDevice Must be 0 if only one device is attached. For multiple devices 1, 2 etc. ftHandle Pointer to a variable of type FT_HANDLE where the handle will be stored. This handle must be used to access the device. Return Value FT_OK if successful, otherwise the return value is an FT error code. Remarks Although this function can be used to open multiple devices by setting iDevice to 0, 1, 2 etc. There is no ability to open a specific device. To open named devices, use the function FT_OpenEx . FT_OpenEx Open the specified device and return a handle that will be used for subsequent accesses. The device can be specified by its serial number, device description or location. This function can also be used to open multiple devices simultaneously. Multiple devices can be opened at the same time if they can be distinguished by serial number or device description. Alternatively, multiple devices can be opened at the same time using location IDs - location information derived from their physical locations on USB. Location IDs can be obtained using the utility USBView. FT_STATUS FT_OpenEx (PVOID pvArg1, DWORD dwFlags, FT_HANDLE *ftHandle) Parameters pvArg1 Meaning depends on dwFlags, but it will normally be interpreted as a pointer to a null terminated string. dwFlags FT_OPEN_BY_SERIAL_NUMBER, FT_OPEN_BY_DESCRIPTION or FT_OPEN_BY_LOCATION. ftHandle Pointer to a variable of type FT_HANDLE where the handle will be stored. This handle must be used to access the device. Return Value FT_OK if successful, otherwise the return value is an FT error code. Remarks The meaning of pvArg1 depends on dwFlags: if dwFlags is FT_OPEN_BY_SERIAL_NUMBER, pvArg1 is interpreted as a pointer to a null-terminated string that represents the serial number of the device; if dwFlags is FT_OPEN_BY_DESCRIPTION, pvArg1 is interpreted as a pointer to a null-terminated string that represents the device description; if dwFlags is FT_OPEN_BY_LOCATION, pvArg1 is interpreted as a long value that contains the location ID of the device. ftHandle is a pointer to a variable of type FT_HANDLE where the handle is to be stored. This handle must be used to access the device.


41

FT_Close Close an open device. FT_STATUS FT_Close (FT_HANDLE ftHandle) Parameters ftHandle Handle of the device. Return Value FT_OK if successful, otherwise the return value is an FT error code. FT_Read Read data from the device. FT_STATUS FT_Read (FT_HANDLE ftHandle, LPVOID lpBuffer, DWORD dwBytesToRead, LPDWORD lpdwBytesReturned) Parameters ftHandle Handle of the device. lpBuffer Pointer to the buffer that receives the data from the device. dwBytesToRead Number of bytes to be read from the device. lpdwBytesReturned Pointer to a variable of type DWORD which receives the number of bytes read from the device. Return Value FT_OK if successful, FT_IO_ERROR otherwise. Remarks FT_Read always returns the number of bytes read in lpdwBytesReturned. This function does not return until dwBytesToRead have been read into the buffer. The number of bytes in the receive queue can be determined by calling FT_GetStatus or FT_GetQueueStatus , and passed to FT_Read as dwBytesToRead so that the function reads the device and returns immediately. When a read timeout value has been specified in a previous call to FT_SetTimeouts , FT_Read returns when the timer expires or dwBytesToRead have been read, whichever occurs first. If the timeout occurred, FT_Read reads available data into the buffer and returns FT_OK. An application should use the function return value and lpdwBytesReturned when processing the buffer. If the return value is FT_OK, and lpdwBytesReturned is equal to dwBytesToRead then FT_Read has completed normally. If the return value is FT_OK, and lpdwBytesReturned is less then dwBytesToRead then a timeout has occurred and the read has been partially completed. Note that if a timeout occurred and no data was read, the return value is still FT_OK. A return value of FT_IO_ERROR suggests an error in the parameters of the function, or a fatal error like USB disconnect has occurred. FT_Write Write data to the device. FT_STATUS FT_Write (FT_HANDLE ftHandle, LPVOID lpBuffer, DWORD dwBytesToWrite, LPDWORD lpdwBytesWritten)


42

Parameters ftHandle Handle of the device. lpBuffer Pointer to the buffer that contains the data to be written to the device. dwBytesToWrite Number of bytes to write to the device. lpdwBytesWritten Pointer to a variable of type DWORD which receives the number of bytes written to the device. Return Value FT_OK if successful, otherwise the return value is an FT error code. FT_ResetDevice This function sends a reset command to the device. FT_STATUS FT_ResetDevice (FT_HANDLE ftHandle) Parameters ftHandle Handle of the device. Return Value FT_OK if successful, otherwise the return value is an FT error code. FT_Purge This function purges receive and transmit buffers in the device. FT_STATUS FT_Purge (FT_HANDLE ftHandle, DWORD dwMask) Parameters ftHandle Handle of the device. dwMask Any combination of FT_PURGE_RX and FT_PURGE_TX. Return Value FT_OK if successful, otherwise the return value is an FT error code. FT_SetTimeouts This function sets the read and write timeouts for the device. FT_STATUS FT_SetTimeouts (FT_HANDLE ftHandle, DWORD dwReadTimeout, DWORD dwWriteTimeout) Parameters ftHandle Handle of the device. dwReadTimeout Read timeout in milliseconds. dwWriteTimeout Write timeout in milliseconds. Return Value FT_OK if successful, otherwise the return value is an FT error code.


43

FT_GetQueueStatus Gets the number of characters in the receive queue. FT_STATUS FT_GetQueueStatus (FT_HANDLE ftHandle, LPDWORD lpdwAmountInRxQueue) Parameters ftHandle Handle of the device. lpdwAmountInRxQueue Pointer to a variable of type DWORD which receives the number of characters in the receive queue. Return Value FT_OK if successful, otherwise the return value is an FT error code. FT_SetBreakOn Sets the BREAK condition for the device. FT_STATUS FT_SetBreakOn (FT_HANDLE ftHandle) Parameters ftHandle Handle of the device. Return Value FT_OK if successful, otherwise the return value is an FT error code. FT_SetBreakOff Resets the BREAK condition for the device. FT_STATUS FT_SetBreakOff (FT_HANDLE ftHandle) Parameters ftHandle Handle of the device. Return Value FT_OK if successful, otherwise the return value is an FT error code. FT_GetStatus Gets the device status including number of characters in the receive queue, number of characters in the transmit queue, and the current event status. FT_STATUS FT_GetStatus (FT_HANDLE ftHandle, LPDWORD lpdwAmountInRxQueue, LPDWORD lpdwAmountInTxQueue, LPDWORD lpdwEventStatus) Parameters ftHandle Handle of the device. lpdwAmountInRxQueue Pointer to a variable of type DWORD which receives the number of characters in the receive queue.


44

lpdwAmountInTxQueue Pointer to a variable of type DWORD which receives the number of characters in the transmit queue. lpdwEventStatus Pointer to a variable of type DWORD which receives the current state of the event status. Return Value FT_OK if successful, otherwise the return value is an FT error code. Remarks For an example of how to use this function, see the sample code in FT_SetEventNotification 33 . FT_SetEventNotification Sets conditions for event notification. FT_STATUS FT_SetEventNotification (FT_HANDLE ftHandle, DWORD dwEventMask, PVOID pvArg) Parameters ftHandle Handle of the device. dwEventMask Conditions that cause the event to be set. pvArg Interpreted as the handle of an event. Return Value FT_OK if successful, otherwise the return value is an FT error code. Remarks An application can use this function to setup conditions which allow a thread to block until one of the conditions is met. Typically, an application will create an event, call this function, then block on the event. When the conditions are met, the event is set, and the application thread unblocked. dwEventMask is a bit-map that describes the events the application is interested in. pvArg is interpreted as the handle of an event which has been created by the application. If one of the event conditions is met, the event is set. If FT_EVENT_RXCHAR is set in dwEventMask, the event will be set when a character has been received by the device. If FT_EVENT_MODEM_STATUS is set in dwEventMask, the event will be set when a change in the modem signals has been detected by the device. FT_GetLatencyTimer Get the current value of the latency timer. FT_STATUS FT_GetLatencyTimer (FT_HANDLE ftHandle, PUCHAR pucTimer) Parameters ftHandle Handle of the device. pucTimer Pointer to unsigned char to store latency timer value. Return Value FT_OK if successful, otherwise the return value is an FT error code. Remarks In the FT8U232AM and FT8U245AM devices, the receive buffer timeout that is used to flush


45

remaining data from the receive buffer was fixed at 16 ms. In the FT2232C, FT232BM and FT245BM, this timeout is programmable and can be set at 1 ms intervals between 2ms and 255 ms. This allows the device to be better optimized for protocols requiring faster response times from short data packets. FT_SetLatencyTimer Set the latency timer. FT_STATUS FT_SetLatencyTimer (FT_HANDLE ftHandle, UCHAR ucTimer) Parameters ftHandle Handle of the device. ucTimer Required value, in milliseconds, of latency timer. Valid range is 2 - 255. Return Value FT_OK if successful, otherwise the return value is an FT error code. Remarks In the FT8U232AM and FT8U245AM devices, the receive buffer timeout that is used to flush remaining data from the receive buffer was fixed at 16 ms. In the FT2232C, FT232BM and FT245BM, this timeout is programmable and can be set at 1 ms intervals between 2ms and 255 ms. This allows the device to be better optimized for protocols requiring faster response times from short data packets. FT_GetBitMode Gets the instantaneous value of the data bus. FT_STATUS FT_GetBitMode (FT_HANDLE ftHandle, PUCHAR pucMode) Parameters ftHandle Handle of the device. pucMode Pointer to unsigned char to store bit mode value. Return Value FT_OK if successful, otherwise the return value is an FT error code. Remarks For a description of available bit modes for the FT2232C, see the application note "Bit Modes Functions for the FT2232C". For a description of Bit Bang Mode for the FT232BM and FT245BM, see the application note "FT232BM/FT245BM Bit Bang Mode". FT_SetBitMode Set the value of the bit mode. FT_STATUS FT_SetBitMode (FT_HANDLE ftHandle, UCHAR ucMask, UCHAR ucEnable) Parameters


46

ftHandle Handle of the device. ucMask Required value for bit mode mask. ucEnable Enable value, 0 = FLASE, 1 = TRUE. Return Value FT_OK if successful, otherwise the return value is an FT error code. Remarks For a description of available bit modes for the FT2232C, see the application note "Bit Modes Functions for the FT2232C". For a description of Bit Bang Mode for the FT232BM and FT245BM, see the application note "FT232BM/FT245BM Bit Bang Mode". FT_SetUSBParameters Set the USB request transfer size. FT_STATUS FT_SetUSBParameters (FT_HANDLE ftHandle, DWORD dwInTransferSize, DWORD dwOutTransferSize) Parameters ftHandle Handle of the device. dwInTransferSize Transfer size for USB IN request. dwOutTransferSize Transfer size for USB OUT request. Return Value FT_OK if successful, otherwise the return value is an FT error code. Remarks Previously, USB request transfer sizes have been set at 4096 bytes and have not been configurable. This function can be used to change the transfer sizes to better suit the application requirements. Note that, at present, only dwInTransferSize is supported.


47

2.8.1.5 Diagrames de flux

En aquest apartat podrem veure d’una manera més esquematitzada mitjançant diagrames de flux quins són els estats en que va passant el software d’alt nivell( Visual ©++ ) i de baix nivell ( microcontroller ) en el moment en que s’executa el codi i es van succeint els events. Primerament Tractarem el pograma/codi incorporat al microcontrolador, la seva funció primordial es la lectura/escriptura de les dades rebudes per el bus USB. Aquí podem veure el seu diagrama de flux.

Figura 13. Diagrama de flux del codi del microcontrolador

INICIALITZACIONS

Hi ha dades a rebre?

Lectura d’entrades

Enviament de l’status d’entrades per el bus USB

NO

SI

Lectura del bus USB

Escritura de les dades rebudes a les Sortides


48

Ara tractarem l’aplicació programada en visual ©++ per la seva interactuació amb el microcontrolador, igualment podrem veure quin és l’estatus de les entrades llegides per el microcontrolador i podrem enviar l’informació desitjada através del bus USB.

Figura 14. Diagrama de flux del codi de l’aplicació

INICI

Sel·lecció del tipus de búsqueda del dispositiu

Búsqueda del dispositiu

Sel·lecció del dispositiu trobat

Accès al dispositiu trobat

Recepció de dades del dispositiu

Enviament de dades al dispositiu


49

2.8.1.6 Manual d’usuari de l’aplicació

En aquest apartat tractarem d’explicar d’una forma sencilla com podem interactuar amb l’aplicació creada amb Visual C++, mitjançant la següent explicació gráfica podrem identificar com i quan es pot manipular les dades per l’enviament i la lectura a través el bus USB.

Aplicació USBtest-DLL

Figura 15. ScreenShot de l’aplicació

1. Option buttons per elegir quin tipus de búsqueda es farà 2. Display on mostra el dispositiu seleccionat 3. Status del dispositiu 4. Status del enviament de dades al dispositiu, i dades a enviar. 5. Botó de sortida d’aplicació 6. Pantalla de tria de selecció de dispositiu i/o lectura de dades 7. Botó de búsqueda de dispositiu 8. Botó d’accés al dispositiu 9. Botó d’enviament d’informació 10. Número de dades rebudes 11. Botó de neteja de la pantalla de dades

Aquesta és una completa eina de comunicació entre el PC i el dispositiu esclau a controlar, la finalitat de l’aplicació és poder connectar-se al dispositiu triat i iniciar una comunicació bidireccional per la seva lectura i escriptura de dades simultània, aquesta eina ha sigut programada amb Visual © ++ i porta incorporada una sèrie d’opcions que fa que sigui molt fàcil la tria de dispositiu amb la seu ràpid accés.

2 3

4

5 6

7 8

9

10

11


50

Funcionament de l’aplicació Per poder accedir al dispositiu desitjat primer haurem d’escollir de quina manera hem de triar la búsqueda de dispositiu, tenim tres tipus de búsqueda.

• Per descripció del dispositiu • Per número de sèrie • Per número de dispositiu

Al seleccionar quin tipus de búsqueda volem, hem d’apretar el botó SEARCH, llavors a la pantalla número 6 es mostraran els dispositius trobats, hem de seleccionar el que nosaltres vulguem apretant amb el ratolí i llavors es quan podrem accedir al dispositiu apretant el botó OPEN, a la pantalla 3 sortirà l’status del dispositiu, si està tancat o ja tenim accés, si tenim accés s’activaran els botons per poder fer l’enviament de dades al dispositiu i començarem a rebre les dades de la lectura d’entrades del dispositiu quan vulguem enviar alguna dada al dispositiu només haurem d’escriure-la al requadre 4 i apretar el botó SEND INFO, dins la pantalla d’status podrem veure si l’informació ha sigut enviada correctament. Si volem esborrar les dades de la pantalla podem apretar el botó CLEAR, i en qualsevol moment podem apretar el botó EXIT per sortir de l’aplicació. L’aplicació està creada per que si hi ha qualsevol problema de connexionat entre el dispositiu i el PC ens avisi adequadament amb un missatge d’error de connexió, així podríem dir que es una aplicació robusta i difícil de penjar-se.


51

2.8.2 Hardware

2.8.2.1 Descripció general del hardware

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

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

Figura 16. Esquema elèctric del circuit

En aquest circuit podem destacar el bus de dades entre el 89c51 i el FT245M situat al port 1 per el qual fem al comunicació entre els dos integrats, per controlar aquesta informació fem servir 4 senyals de control situats al port 3 per així controlar el enviament i recepció de dades.


52

Tal com mostra aquesta gràfica. Senyals de control ( RXF# , TXE#, WR , RD# )

Figura 17. Esquema de connexió genérica

Farem una descripció general del component DLP-USB245M.

2.8.2.2 Component DLP-245M

DLP-USB245M és mètode fàcil per transferència de dades a/de un perifèric i un host a 1 Mbyte/segon. Una simple FIFO fa una fàcil interface per el microcontrolador o microprocesador via IO ports. L’enviament de dades desde el perifèric al host PC es una simple escriptura del byte al bus de dades quant la senyal de control TXE# esta a nivell baix. Si els (384 bytes ) del buffer de transmissió estan plens o estan ocupats gravant l'últim byte escrit anteriorment, el dispositiu fica la senyal de control TXE# a nivell alt per parar l’escriptura dades fins que totes les dades de la FIFO hagin sigut transferides del USB al host. Quan el host envia dades al perifèric per mitjà USB, el dispositiu ficarà RXF# a nivell baix per deixar al perifèric saber que per lo menys 1 byte esta disponible al bus. El perifèric llavors llegeix les dades fins que la senyal de control RXF# va a nivell alt la qual cosa indica que no hi ha mes dades a llegir. Per entendre millor el funcionament dels cicles de lectura i escriptura aquí hi ha les especificacions relacionades amb aquests processos.


53

Cicle de lectura

Figura 17. Gràfica de cicle de lectura

Cicle d’escriptura

Figura 18. Gràfica de cicle d’escriptura


54

Com hem vist això es el control del bus per la transmissió de dades entre el nostre host i el perifèric. Ara anomenarem les diverses formes de connexionat que pot tenir el component DLP-USB245M a lo que l’alimentació pertany.

2.8.2.3 Tipus de alimentació del DPL-USB245M

Basic bus powered a 5 volts Self-powered 5 volts del sistema Bus-Powered per 5V i sistema amb 3.3 volts de interface lògica. Power controlat per SLEEP Basic bus powered a 5 volts Aquesta configuració es fa servir ja que no necessita alimentació exterior i agafa l’alimentació directament del connector USB que dóna uns 5V, el problema d’aquesta configuració es que hi ha unes regles que limiten el funcionament del sistema, així com la intensitat que dóna del mateix bus.

Figura 19. Basic Bus-Powered


55

Self-powered 5 volts del sistema

Figura 20. Self--Powered

Aquesta configuració és la que s’ha fet servir per la implementació del projecte ja que tenim una alimentació externa la qual ens assegura un corrent més gran i sense limitacions del sistema, s’ha triat la configuració també per una futura adhesió de noves plaques connectades també amb la nostra.


56

Bus-Powered per 5V i sistema amb 3.3 volts de interface lògica.

Figura 21. Basic Bus-Powered

Aquesta configuració s’alimenta del seu propi regulador de 3.3 volts implementat dins del xip i que alimenta a tots els altres components, molt usat per a sistemes amb alts requeriments energètics.


57

Power controlat per SLEEP

Figura 22. Power Controlled by Sleep Aquesta configuració es molt interessant per els sistemes que requereixen un sistema de wake up/sleep per assegurar que quant el sistema esta en un punt de suspensió tota la seva electrònica esta en consum mínim.

2.8.2.4 Altres components

El nostre circuit es compon de un array de led’s per indicar el moviment de dades del bus, la informació que s’envia desde el PC fins el Ucontrolador mitjançant el bus USB es mostrada en forma lumínica amb els led’s. Els led’s són smd ja que d’aquesta manera ocupaven menys espai dins la nostra placa, les resistències per crear la intensitat per alimentar els led’s són de 470 ohms definits segons la potencia dels leds. El circuit també compta amb un array de switches connectades a un port per enviar la informació al PC mitjançant el bus USB. El status d’aquest switches es mostrà a la pantalla Windows del PC. Per la integració dels switches dins el circuit em triat un switch Standard array de 8 canals, es un circuit integrat on podem canviar el valor de la senyal de entrada del microprocesador. La part de oscil·lació del circuit s’ha fet amb un cristall de quarz de 10mhz amb els seus corresponents condensadors de 33pF. El cristall ha sigut situat el més prop possible de la entrada XTAL1/2 per no tenir pertorbacions externes.


58

La senyal de reset te un condensador de 10uF recomanat per el fabricant del xip 89c51. La part de regulació del circuit parteix de la entrada de tensions de entre +12 a +5 volts gràcies al regulador L7805, Que proporciona una regulació a 5 vols estables, els condensadors de entrada i sortida són els recomanats per el fabricant del xip. La part de protecció del circuit conforma la integració de un díode a la entre la tensió de entrada i la entrada a la pota del regulador, assegurant així la no inversió de polaritat. Els condensadors de protecció dels xips entre Vcc i GND han sigut rutejats el més prop possible per el seu correcte funcionalment


59

2.9 Planificació La representació del temps estimat per la elaboració del projecte és :

Figura 23. Planificació del projecte

Disseny de l'esquematic 10Disseny del PCB 5Fabricacio i montatge del PCB 3Disseny del software Ucontrolador 20Disseny del software VisualC++ 30Ajustaments del sistema 10Redacció Projecte 20

Total dies

Activitats a realitzar \ dies

98


60

3. MEMÒRIA DE CÀLCUL


61

3.1 Codi del dispositiu esclau (AT89C51)

Un cop vist el quin programa s’ha utilitzat per programar el dispositiu esclau i el hardware que tindrem a la nostra placa, aquí podrem veure el codi en C, del microcontrolador AT89C51ED2, que s’encarregarà de comunicar amb el xip USB i mantenir una comunicació via Bus de dades. //*******************INICIALITZACIONS*********************************/ //**************Autor:Lluís Llauradó Caballé**************************/ //********************************************************************/ //DEFINES #include "Delay.h" sfr P0 = 0x80; // Port dedicat a la escriptura de outputs sfr P1 = 0x90; // Port/bus bi-direccional de dades sfr P2 = 0xA0; // Port dedicat a la lectura de inputs sfr P3 = 0xB0; // Port de control sbit PIN_3_7 = P3^7; sbit PIN_3_6 = P3^6; sbit PIN_3_5 = P3^5; sbit PIN_3_4 = P3^4; #define TXE PIN_3_7 // TXE #define RXF PIN_3_6 // RXF #define WR PIN_3_5 // WR #define RD PIN_3_4 // RD char data8; char data0; //VOID DE LES FUNCIONS //FUNCIÓ DELAY EN MILISEGONS// void delay_ms(volatile unsigned int count) { for(count *= DELAY_MULTPLR; count > 0; count--) continue; return; } //********************************************************************/ int read_usb() { //Lectura de dades via USB while( RXF == 1 ); //Espera que la dada arribi RD = 0; //Fica RD a nivell baix delay_ms(1); //Espera 1 milisegon data8 = P1; //Llegeix del port P1 la informació enviada pel bus USB. RD = 1; //Fica RD a nivell alt } //********************************************************************/ int escritura_outputs() { P0 = data8; // Activació del led's/Sortides }


62

//********************************************************************/ int lectura_inputs() { data0 = P2; // Lectura de les entrades del switch } //********************************************************************/ void send_usb() { //Enviament de dades via USB while( TXE == 1 ); //Si TXE esta a nivell alt no es pot escriure P1=data0; //Fiquem al port1 les dades a enviar delay_ms(100); //Ens esperem 100ms WR = 0; //Fiquem a nivell baix WR delay_ms(100); //Ens esperem 100ms WR = 1; //Fiquem a nivell baix WR } //*******MAIN*************************************************************/ void main() { //*******INICIALITZACIONS*************************************************/ WR = 1; //init USB WR RD = 1; //init USB RD //****FI*INICIALITZACIONS*************************************************/ delay_ms(200); while(1) { while ( RXF ) { lectura_inputs();//Fem la lectura d'entrades dels switches delay_ms(2000);//Esperem 2 segons abans d'enviar les dades send_usb(); //Enviem l'informació } if ( RXF == 0 ) { read_usb(); //Llegim les dades del bus USB delay_ms(2000);//Esperem 2 segons abans d'escriure les dades escritura_outputs();//Escrivim l'informació al port de sortida } } }


63

3.2 Codi de l’aplicació amb Visual ©++

Un cop ja hem vist les Funcions Clàssiques d’interfície que utilitzarem en la nostra aplicació a la memòria descriptiva, el següent pas serà estudiar l’aplicació que farem servir i hem creat exclusivament per al nostre projecte. Recordem de totes maneres que hem intentat que sigui el més genèric possible i amb aquesta finalitat hem creat la classe USB que amb molt poques modificacions, podria ésser utilitzada en aplicacions molt diverses. El primer que incloem en aquesta relació seran els arxius USBtest.h i USBtestDlg.h que inclouen les descripcions de les variables i funcions que la componen. USBtest.h //--------------------------------------------------------------------------- // // Copyright (C) 2005 Lluís Llauradó Caballé, All Rights Reserved. // //--------------------------------------------------------------------------- // USBtest.h : main header file for the USBTEST application // #if !defined(AFX_USBTEST_H__07909304_D75E_11D4_A644_93781B97CC41__INCLUDED_) #define AFX_USBTEST_H__07909304_D75E_11D4_A644_93781B97CC41__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 #ifndef __AFXWIN_H__ #error include 'stdafx.h' before including this file for PCH #endif #include "resource.h" // main symbols ///////////////////////////////////////////////////////////////////////////// // CUSBtestApp: ///////////////////////////////////////////////////////////////////////////// class CUSBtestApp : public CWinApp { public: CUSBtestApp(); // Overrides // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CUSBtestApp) public: virtual BOOL InitInstance(); //}}AFX_VIRTUAL // Implementation //{{AFX_MSG(CUSBtestApp) // NOTE - the ClassWizard will add and remove member functions here. // DO NOT EDIT what you see in these blocks of generated code ! //}}AFX_MSG DECLARE_MESSAGE_MAP() }; ///////////////////////////////////////////////////////////////////////////// //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line.


64

#endif // !defined(AFX_USBTEST_H__07909304_D75E_11D4_A644_93781B97CC41__INCLUDED_)

USBtestDlg.h

//--------------------------------------------------------------------------- // // Copyright (C) 2005 Lluís Llauradó Caballé, All Rights Reserved. // //--------------------------------------------------------------------------- // USBtestDlg.h : header file // #if !defined(AFX_USBTESTDLG_H__07909306_D75E_11D4_A644_93781B97CC41__INCLUDED_) #define AFX_USBTESTDLG_H__07909306_D75E_11D4_A644_93781B97CC41__INCLUDED_ #if _MSC_VER > 1000 #pragma once #endif // _MSC_VER > 1000 #include "ftd2xx.h" UINT ThreadProc1(LPVOID param); const int ON = 100; const int OFF = 101; // CUSBtestDlg dialog class CUSBtestDlg : public CDialog { // Construction public: CUSBtestDlg(CWnd* pParent = NULL); // standard constructor void CUSBtestDlg::buttons(int onoff); void CUSBtestDlg::Loadem(); FT_STATUS Write(LPVOID, DWORD, LPDWORD); FT_STATUS CUSBtestDlg::OpenBy(); // Dialog Data //{{AFX_DATA(CUSBtestDlg) enum { IDD = IDD_USBTEST_DIALOG }; CListBox m_Received; CString m_PortStatus; CString m_EchoRes; long m_NumRecd; CString m_NameNmbr; int m_SerDesc; int m_sentinfo; //}}AFX_DATA // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CUSBtestDlg) protected: virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support virtual BOOL OnCommand(WPARAM wParam, LPARAM lParam); //}}AFX_VIRTUAL // Implementation protected: HICON m_hIcon; HMODULE m_hmodule; FT_HANDLE m_ftHandle; void LoadDLL(); typedef FT_STATUS (WINAPI *PtrToOpen)(PVOID, FT_HANDLE *); PtrToOpen m_pOpen; FT_STATUS Open(PVOID); typedef FT_STATUS (WINAPI *PtrToOpenEx)(PVOID, DWORD, FT_HANDLE *);


65

PtrToOpenEx m_pOpenEx; FT_STATUS OpenEx(PVOID, DWORD); typedef FT_STATUS (WINAPI *PtrToListDevices)(PVOID, PVOID, DWORD); PtrToListDevices m_pListDevices; FT_STATUS ListDevices(PVOID, PVOID, DWORD); typedef FT_STATUS (WINAPI *PtrToClose)(FT_HANDLE); PtrToClose m_pClose; FT_STATUS Close(); typedef FT_STATUS (WINAPI *PtrToRead)(FT_HANDLE, LPVOID, DWORD, LPDWORD); PtrToRead m_pRead; FT_STATUS Read(LPVOID, DWORD, LPDWORD); typedef FT_STATUS (WINAPI *PtrToWrite)(FT_HANDLE, LPVOID, DWORD, LPDWORD); PtrToWrite m_pWrite; //FT_STATUS Write(LPVOID, DWORD, LPDWORD); typedef FT_STATUS (WINAPI *PtrToResetDevice)(FT_HANDLE); PtrToResetDevice m_pResetDevice; FT_STATUS ResetDevice(); typedef FT_STATUS (WINAPI *PtrToPurge)(FT_HANDLE, ULONG); PtrToPurge m_pPurge; FT_STATUS Purge(ULONG); typedef FT_STATUS (WINAPI *PtrToSetTimeouts)(FT_HANDLE, ULONG, ULONG); PtrToSetTimeouts m_pSetTimeouts; FT_STATUS SetTimeouts(ULONG, ULONG); typedef FT_STATUS (WINAPI *PtrToGetQueueStatus)(FT_HANDLE, LPDWORD); PtrToGetQueueStatus m_pGetQueueStatus; FT_STATUS GetQueueStatus(LPDWORD); // Generated message map functions //{{AFX_MSG(CUSBtestDlg) virtual BOOL OnInitDialog(); afx_msg void OnSysCommand(UINT nID, LPARAM lParam); afx_msg void OnPaint(); afx_msg HCURSOR OnQueryDragIcon(); virtual void OnOK(); afx_msg void OnButtonSend64Echo(); //afx_msg void OnButtonBlinkOn(); afx_msg void OnTimer(UINT nIDEvent); afx_msg void OnButtonClear(); afx_msg void OnButtonHello(); afx_msg void OnRadioNameNum(); afx_msg void OnRadioSernum(); afx_msg void OnChangeEditNameNumber(); afx_msg void OnRadioDevno(); afx_msg void OnButtonSearch(); afx_msg void OnSelchangeList1(); //}}AFX_MSG DECLARE_MESSAGE_MAP() }; //{{AFX_INSERT_LOCATION}} // Microsoft Visual C++ will insert additional declarations immediately before the previous line. #endif // !defined(AFX_USBTESTDLG_H__07909306_D75E_11D4_A644_93781B97CC41__INCLUDED_)


66

El següent que incloem són els arxius USBtest.cpp i USBtestDlg.cpp que és on podem trobar el codi de l’aplicació. USBtest.cpp

//--------------------------------------------------------------------------- // // Copyright (C) 2005 Lluís Llauradó Caballé, All Rights Reserved. // //--------------------------------------------------------------------------- // USBtest.cpp : Defines the class behaviors for the application. // #include "stdafx.h" #include "USBtest.h" #include "USBtestDlg.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif ///////////////////////////////////////////////////////////////////////////// // CUSBtestApp BEGIN_MESSAGE_MAP(CUSBtestApp, CWinApp) //{{AFX_MSG_MAP(CUSBtestApp) // NOTE - the ClassWizard will add and remove mapping macros here. // DO NOT EDIT what you see in these blocks of generated code! //}}AFX_MSG ON_COMMAND(ID_HELP, CWinApp::OnHelp) END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CUSBtestApp construction CUSBtestApp::CUSBtestApp() { // TODO: add construction code here, // Place all significant initialization in InitInstance } ///////////////////////////////////////////////////////////////////////////// // The one and only CUSBtestApp object CUSBtestApp theApp; ///////////////////////////////////////////////////////////////////////////// // CUSBtestApp initialization BOOL CUSBtestApp::InitInstance() { AfxEnableControlContainer(); // Standard initialization // If you are not using these features and wish to reduce the size // of your final executable, you should remove from the following // the specific initialization routines you do not need. #ifdef _AFXDLL Enable3dControls(); // Call this when using MFC in a shared DLL #else Enable3dControlsStatic(); // Call this when linking to MFC statically #endif CUSBtestDlg dlg; m_pMainWnd = &dlg; int nResponse = dlg.DoModal(); if (nResponse == IDOK) { // TODO: Place code here to handle when the dialog is


67

// dismissed with OK } else if (nResponse == IDCANCEL) { // TODO: Place code here to handle when the dialog is // dismissed with Cancel } // Since the dialog has been closed, return FALSE so that we exit the // application, rather than start the application's message pump. return FALSE; }

USBtestDlg.cpp

//--------------------------------------------------------------------------- // // Copyright (C) 2005 Lluís Llauradó Caballé, All Rights Reserved. // //--------------------------------------------------------------------------- // USBtestDlg.cpp : implementation file // includes #include "stdafx.h" #include "USBtest.h" #include "USBtestDlg.h" #include "ftd2xx.h" #ifdef _DEBUG #define new DEBUG_NEW #undef THIS_FILE static char THIS_FILE[] = __FILE__; #endif /////////////////////////////////////////////////////// // globals variables int running; int board_present; int bus_busy; /////////////////////////////////////////////////////// // CAboutDlg dialog used for App About class CAboutDlg : public CDialog { public: CAboutDlg(); // Dialog Data //{{AFX_DATA(CAboutDlg) enum { IDD = IDD_ABOUTBOX }; //}}AFX_DATA // ClassWizard generated virtual function overrides //{{AFX_VIRTUAL(CAboutDlg) protected: virtual void DoDataExchange(CDataExchange* pDX); // DDX/DDV support //}}AFX_VIRTUAL // Implementation protected: //{{AFX_MSG(CAboutDlg) //}}AFX_MSG DECLARE_MESSAGE_MAP() }; CAboutDlg::CAboutDlg() : CDialog(CAboutDlg::IDD) { //{{AFX_DATA_INIT(CAboutDlg) //}}AFX_DATA_INIT }


68

void CAboutDlg::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); //{{AFX_DATA_MAP(CAboutDlg) //}}AFX_DATA_MAP } BEGIN_MESSAGE_MAP(CAboutDlg, CDialog) //{{AFX_MSG_MAP(CAboutDlg) // No message handlers //}}AFX_MSG_MAP END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CUSBtestDlg dialog CUSBtestDlg::CUSBtestDlg(CWnd* pParent /*=NULL*/) : CDialog(CUSBtestDlg::IDD, pParent) { //{{AFX_DATA_INIT(CUSBtestDlg) m_PortStatus = _T(""); m_EchoRes = _T(""); m_NumRecd = 0; m_NameNmbr = _T("Enter device Description or Serial Number here."); m_SerDesc = 0; m_sentinfo = 0; //}}AFX_DATA_INIT // Note that LoadIcon does not require a subsequent DestroyIcon in Win32 m_hIcon = AfxGetApp()->LoadIcon(IDR_MAINFRAME); } void CUSBtestDlg::DoDataExchange(CDataExchange* pDX) { CDialog::DoDataExchange(pDX); //{{AFX_DATA_MAP(CUSBtestDlg) DDX_Control(pDX, IDC_LIST1, m_Received); DDX_Text(pDX, IDC_EDIT_PORT_STATUS, m_PortStatus); DDX_Text(pDX, IDC_EDIT_ECHO_RESULT, m_EchoRes); DDX_Text(pDX, IDC_EDIT_NUM_RECD, m_NumRecd); DDX_Text(pDX, IDC_EDIT_NAME_NUMBER, m_NameNmbr); DDX_Radio(pDX, IDC_RADIO_NAME_NUM, m_SerDesc); DDX_Text(pDX, IDC_EDIT1, m_sentinfo); //}}AFX_DATA_MAP } BEGIN_MESSAGE_MAP(CUSBtestDlg, CDialog) //{{AFX_MSG_MAP(CUSBtestDlg) ON_WM_SYSCOMMAND() ON_BN_CLICKED(IDC_BUTTON_SEND128_ECHO, OnButtonSend64Echo) ON_WM_TIMER() ON_BN_CLICKED(IDC_BUTTON_CLEAR, OnButtonClear) ON_BN_CLICKED(IDC_BUTTON_HELLO, OnButtonHello) ON_BN_CLICKED(IDC_RADIO_NAME_NUM, OnRadioNameNum) ON_BN_CLICKED(IDC_RADIO_SERNUM, OnRadioSernum) ON_EN_CHANGE(IDC_EDIT_NAME_NUMBER, OnChangeEditNameNumber) ON_BN_CLICKED(IDC_RADIO_DEVNO, OnRadioDevno) ON_BN_CLICKED(IDC_BUTTON_SEARCH, OnButtonSearch) ON_LBN_SELCHANGE(IDC_LIST1, OnSelchangeList1) //}}AFX_MSG_MAP END_MESSAGE_MAP() ///////////////////////////////////////////////////////////////////////////// // CUSBtestDlg message handlers void CUSBtestDlg::OnSysCommand(UINT nID, LPARAM lParam) { if ((nID & 0xFFF0) == IDM_ABOUTBOX) { CAboutDlg dlgAbout; dlgAbout.DoModal(); } else { CDialog::OnSysCommand(nID, lParam); }


69

} //*********************************************************************** //*********************************************************************** //***************************IMPLEMENTATION CODE************************* //*********************************************************************** //*********************************************************************** BOOL CUSBtestDlg::OnInitDialog() { CDialog::OnInitDialog(); // Set the icon for this dialog. // when the application's main window is not a dialog SetIcon(m_hIcon, TRUE); // Set big icon SetIcon(m_hIcon, FALSE); // Set small icon // TODO: Add extra initialization here buttons(OFF); //turn em off till a port is active bus_busy=0; board_present=0; SetTimer(15, 100, NULL);//check for new USB data in the buffer every 100mS //read the last settings from the registry m_SerDesc = AfxGetApp()->GetProfileInt("MyUSBTestAp", "SerDesc", 0);//default to Description if(m_SerDesc==0) m_NameNmbr = AfxGetApp()->GetProfileString("MyUSBTestAp", "DescString", "Enter device Description or Serial Number here."); if(m_SerDesc==1) m_NameNmbr = AfxGetApp()->GetProfileString("MyUSBTestAp", "SerialString", "Enter device Description or Serial Number here."); if(m_SerDesc==2) m_NameNmbr = AfxGetApp()->GetProfileString("MyUSBTestAp", "DevNmbr", "Enter device Description or Serial Number here."); UpdateData(FALSE); Loadem(); // Load DLL and test for presense of DLP-USB return TRUE; // return TRUE unless you set the focus to a control } //********************* ENABLE & DISABLE THE BUTTONS ******************** //*********************************************************************** void CUSBtestDlg::buttons(int onoff) { if(onoff == OFF) { GetDlgItem(IDC_BUTTON_SEND128_ECHO)->EnableWindow(FALSE); } if(onoff == ON) { GetDlgItem(IDC_BUTTON_SEND128_ECHO)->EnableWindow(TRUE); GetDlgItem(IDC_BUTTON_HELLO)->EnableWindow(TRUE); } } //********************** EXIT BUTTON ************************************ //*********************************************************************** void CUSBtestDlg::OnOK() { // Exit application running=0;


70

Close(); FreeLibrary(m_hmodule); CDialog::OnOK(); } //********************** PRELIMINARY CHECKING *************************** //*********************************************************************** void CUSBtestDlg::OnButtonSend64Echo() { //send XX bytes and verify each is echoed back correctly unsigned char tx[3], rx[3]; int t,sentinfo; BOOL err; DWORD ret_bytes; if(!board_present) return; bus_busy=1; //keep the timer function from grabbing return data buttons(OFF); GetDlgItem(IDOK)->EnableWindow(FALSE); UpdateData(TRUE); m_EchoRes = _T("Testing..."); UpdateData(FALSE); UpdateWindow(); //clear the ports of any data Purge(FT_PURGE_RX || FT_PURGE_TX); err=0; m_EchoRes = _T("DATA SENT"); for(t=0; t<1; t++) { //write data sentinfo = m_sentinfo; tx[0] = sentinfo; Write(tx, 1, &ret_bytes); } if(err==1) m_EchoRes = _T("--ERROR--"); UpdateData(FALSE); UpdateWindow(); bus_busy=0; buttons(ON); GetDlgItem(IDOK)->EnableWindow(TRUE); } //********************** READ USB DATA ****************************** //******************************************************************* void CUSBtestDlg::OnTimer(UINT nIDEvent) { unsigned char rx[600]; DWORD ret_bytes; DWORD bytes_in_buf; FT_STATUS status; if(!board_present) return; if(bus_busy) //don't interfere with another test return; status = GetQueueStatus(&bytes_in_buf); if(status != FT_OK) { UpdateData(TRUE);


71

m_PortStatus = _T("DLP_Closed"); Close(); board_present=0; UpdateData(FALSE); UpdateWindow(); bytes_in_buf = 0; } if(bytes_in_buf) { status = Read(rx, bytes_in_buf<600 ? bytes_in_buf : 600, &ret_bytes); if((status == FT_OK) || ((status == FT_IO_ERROR) && (ret_bytes > 0)) /* Read timeout */) { if(ret_bytes) { CString str; UpdateData(TRUE); for(DWORD x=0; x<ret_bytes; x++) { m_Received.ResetContent(); m_NumRecd++; str.Format("%d 0x%.2X", rx[x], rx[x]); m_Received.AddString(str); m_EchoRes = _T("WAITING DATA"); } } } UpdateData(FALSE); UpdateWindow(); } CDialog::OnTimer(nIDEvent); } //********************** DISABLE ESC KEY ************************************* //**************************************************************************** BOOL CUSBtestDlg::OnCommand(WPARAM wParam, LPARAM lParam) { if(wParam==2) return FALSE; return CDialog::OnCommand(wParam, lParam); } //********************** CLEAR TEXT INFORMATION ****************************** //**************************************************************************** void CUSBtestDlg::OnButtonClear() { UpdateData(TRUE); m_NumRecd=0; m_Received.ResetContent(); UpdateData(FALSE); UpdateWindow(); } //********************** LOAD DLL FUNCTIONS ********************************** //**************************************************************************** void CUSBtestDlg::LoadDLL() { m_hmodule = LoadLibrary("Ftd2xx.dll"); if(m_hmodule == NULL) { AfxMessageBox("Error: Can't Load ft8u245.dll"); return; } m_pWrite = (PtrToWrite)GetProcAddress(m_hmodule, "FT_Write"); if (m_pWrite == NULL) {


72

AfxMessageBox("Error: Can't Find FT_Write"); return; } m_pRead = (PtrToRead)GetProcAddress(m_hmodule, "FT_Read"); if (m_pRead == NULL) { AfxMessageBox("Error: Can't Find FT_Read"); return; } m_pOpen = (PtrToOpen)GetProcAddress(m_hmodule, "FT_Open"); if (m_pOpen == NULL) { AfxMessageBox("Error: Can't Find FT_Open"); return; } m_pOpenEx = (PtrToOpenEx)GetProcAddress(m_hmodule, "FT_OpenEx"); if (m_pOpenEx == NULL) { AfxMessageBox("Error: Can't Find FT_OpenEx"); return; } m_pListDevices = (PtrToListDevices)GetProcAddress(m_hmodule, "FT_ListDevices"); if(m_pListDevices == NULL) { AfxMessageBox("Error: Can't Find FT_ListDevices"); return; } m_pClose = (PtrToClose)GetProcAddress(m_hmodule, "FT_Close"); if (m_pClose == NULL) { AfxMessageBox("Error: Can't Find FT_Close"); return; } m_pResetDevice = (PtrToResetDevice)GetProcAddress(m_hmodule, "FT_ResetDevice"); if (m_pResetDevice == NULL) { AfxMessageBox("Error: Can't Find FT_ResetDevice"); return; } m_pPurge = (PtrToPurge)GetProcAddress(m_hmodule, "FT_Purge"); if (m_pPurge == NULL) { AfxMessageBox("Error: Can't Find FT_Purge"); return; } m_pSetTimeouts = (PtrToSetTimeouts)GetProcAddress(m_hmodule, "FT_SetTimeouts"); if (m_pSetTimeouts == NULL) { AfxMessageBox("Error: Can't Find FT_SetTimeouts"); return; } m_pGetQueueStatus = (PtrToGetQueueStatus)GetProcAddress(m_hmodule, "FT_GetQueueStatus"); if (m_pGetQueueStatus == NULL) { AfxMessageBox("Error: Can't Find FT_GetQueueStatus"); return; } } //*********************** FUNCTIONS ****************************************** //**************************************************************************** //********************** READ FUNCTION *************************************** //**************************************************************************** FT_STATUS CUSBtestDlg::Read(LPVOID lpvBuffer, DWORD dwBuffSize, LPDWORD lpdwBytesRead)


73

{ if (!m_pRead) { AfxMessageBox("FT_Read is not valid!"); return FT_INVALID_HANDLE; } return (*m_pRead)(m_ftHandle, lpvBuffer, dwBuffSize, lpdwBytesRead); } //********************** WRITE FUNCTION ************************************** //**************************************************************************** FT_STATUS CUSBtestDlg::Write(LPVOID lpvBuffer, DWORD dwBuffSize, LPDWORD lpdwBytes) { if (!m_pWrite) { AfxMessageBox("FT_Write is not valid!"); return FT_INVALID_HANDLE; } return (*m_pWrite)(m_ftHandle, lpvBuffer, dwBuffSize, lpdwBytes); } //********************** OPEN DEVICE FUNCTION ******************************** //**************************************************************************** FT_STATUS CUSBtestDlg::Open(PVOID pvDevice) { if (!m_pOpen) { AfxMessageBox("FT_Open is not valid!"); return FT_INVALID_HANDLE; } return (*m_pOpen)(pvDevice, &m_ftHandle ); } //********************** OPEN SEVERAL DEVICES FUNCTION *********************** //**************************************************************************** FT_STATUS CUSBtestDlg::OpenEx(PVOID pArg1, DWORD dwFlags) { if (!m_pOpenEx) { AfxMessageBox("FT_OpenEx is not valid!"); return FT_INVALID_HANDLE; } return (*m_pOpenEx)(pArg1, dwFlags, &m_ftHandle); } //********************** ENUMERATE DEVICES FUNCTION ************************** //**************************************************************************** FT_STATUS CUSBtestDlg::ListDevices(PVOID pArg1, PVOID pArg2, DWORD dwFlags) { if (!m_pListDevices) { AfxMessageBox("FT_ListDevices is not valid!"); return FT_INVALID_HANDLE; } return (*m_pListDevices)(pArg1, pArg2, dwFlags); } //********************** CLOSE FUNCTION ************************************** //**************************************************************************** FT_STATUS CUSBtestDlg::Close() { if (!m_pClose) {


74

AfxMessageBox("FT_Close is not valid!"); return FT_INVALID_HANDLE; } return (*m_pClose)(m_ftHandle); } //********************** RESET DEVICE FUNCTION ******************************* //**************************************************************************** FT_STATUS CUSBtestDlg::ResetDevice() { if (!m_pResetDevice) { AfxMessageBox("FT_ResetDevice is not valid!"); return FT_INVALID_HANDLE; } return (*m_pResetDevice)(m_ftHandle); } //********************** PURGE DEVICE FUNCTION ******************************* //**************************************************************************** FT_STATUS CUSBtestDlg::Purge(ULONG dwMask) { if (!m_pPurge) { AfxMessageBox("FT_Purge is not valid!"); return FT_INVALID_HANDLE; } return (*m_pPurge)(m_ftHandle, dwMask); } //********************** SET TIMEOUTS FUNCTION ******************************* //**************************************************************************** FT_STATUS CUSBtestDlg::SetTimeouts(ULONG dwReadTimeout, ULONG dwWriteTimeout) { if (!m_pSetTimeouts) { AfxMessageBox("FT_SetTimeouts is not valid!"); return FT_INVALID_HANDLE; } return (*m_pSetTimeouts)(m_ftHandle, dwReadTimeout, dwWriteTimeout); } //********************** GET QUEUE STATUS FUNCTION *************************** //**************************************************************************** FT_STATUS CUSBtestDlg::GetQueueStatus(LPDWORD lpdwAmountInRxQueue) { if (!m_pGetQueueStatus) { AfxMessageBox("FT_GetQueueStatus is not valid!"); return FT_INVALID_HANDLE; } return (*m_pGetQueueStatus)(m_ftHandle, lpdwAmountInRxQueue); } //**************************************************************************** //**************************************************************************** //********************** GET DEVICE DESCRIPTION ****************************** //****************************************************************************


75

void CUSBtestDlg::OnRadioNameNum() { CWinApp* pApp = AfxGetApp(); //write the new setup to the registry pApp->WriteProfileInt("MyUSBTestAp", "SerDesc", 0); UpdateData(TRUE); m_NameNmbr = AfxGetApp()->GetProfileString("MyUSBTestAp", "DescString", "Enter device Description or Serial Number here."); UpdateData(FALSE); UpdateWindow(); } //********************** GET DEVICE SERIAL NUMBER DESCRIPTION **************** //**************************************************************************** void CUSBtestDlg::OnRadioSernum() { CWinApp* pApp = AfxGetApp(); //write the new setup to the registry pApp->WriteProfileInt("MyUSBTestAp", "SerDesc", 1); UpdateData(TRUE); m_NameNmbr = AfxGetApp()->GetProfileString("MyUSBTestAp", "SerialString", "Enter device Description or Serial Number here."); UpdateData(FALSE); UpdateWindow(); } //********************** GET DEVICE POSITION NUMBER ************************** //**************************************************************************** void CUSBtestDlg::OnRadioDevno() { CWinApp* pApp = AfxGetApp(); //write the new setup to the registry pApp->WriteProfileInt("MyUSBTestAp", "SerDesc", 2); UpdateData(TRUE); m_NameNmbr = AfxGetApp()->GetProfileString("MyUSBTestAp", "DevNmbr", "Enter device Description or Serial Number here."); UpdateData(FALSE); UpdateWindow(); } //********************** SHOW THE OPTION CHOOSEN ****************************** //**************************************************************************** void CUSBtestDlg::OnChangeEditNameNumber() { UpdateData(TRUE); //write the new setup to the registry if(m_SerDesc==0) AfxGetApp()->WriteProfileString("MyUSBTestAp", "DescString", m_NameNmbr); if(m_SerDesc==1) AfxGetApp()->WriteProfileString("MyUSBTestAp", "SerialString", m_NameNmbr); if(m_SerDesc==2) AfxGetApp()->WriteProfileString("MyUSBTestAp", "DevNmbr", m_NameNmbr); if(m_NameNmbr.GetLength() < 1) m_SerDesc = 2; UpdateData(FALSE); UpdateWindow(); } //********************** TEST FOR PRESENT OF BOARD *************************** //**************************************************************************** void CUSBtestDlg::Loadem() { unsigned char txbuf[25], rxbuf[25]; DWORD ret_bytes; LoadDLL();


76

UpdateData(TRUE); //open the device FT_STATUS status = OpenBy(); if(status) { m_PortStatus = _T("USB1 not responding"); board_present=0; GetDlgItem(IDC_BUTTON_HELLO)->EnableWindow(TRUE); } else { ResetDevice(); SetTimeouts(3000, 3000);//extend timeout while board DLP-USB finishes reset Purge(FT_PURGE_RX || FT_PURGE_TX); //test for presence of board txbuf[0] = 0xFF; Write(txbuf, 1, &ret_bytes); Read(rxbuf, 1, &ret_bytes); if(ret_bytes==0)//if no response maybe windows was busy... read it again Read(rxbuf, 1, &ret_bytes); if(rxbuf[0] != 0xFF) { m_PortStatus = _T("No response from DLP-USB"); int c = (int)rxbuf[0]; CString str; str.Format(" (0x%.2X)", c); m_PortStatus += str; board_present=0; GetDlgItem(IDC_BUTTON_HELLO)->EnableWindow(TRUE); } else { m_PortStatus = _T("DLP-USB ready."); buttons(ON);//turn em off till a port is active board_present=1; } } SetTimeouts(300, 300); UpdateData(FALSE); UpdateWindow(); } //******** OPEN DEVICE DEPENDING ON OPTION SELECTED ************************** //**************************************************************************** FT_STATUS CUSBtestDlg::OpenBy() { UpdateData(TRUE); if(m_NameNmbr.Find("Enter device Description") > -1) { //highlight the descriptor/serial number to draw attention... CEdit *pEdt; pEdt = (CEdit *)GetDlgItem(IDC_EDIT_NAME_NUMBER); pEdt->SetFocus(); pEdt->SetSel(0, -1, FALSE); AfxMessageBox("You must enter a Device Description or Serial Number."); return FT_DEVICE_NOT_OPENED; } FT_STATUS status; ULONG x=0; if(m_SerDesc==0) status = OpenEx((PVOID)(LPCTSTR)m_NameNmbr, FT_OPEN_BY_DESCRIPTION); if(m_SerDesc==1) status = OpenEx((PVOID)(LPCTSTR)m_NameNmbr, FT_OPEN_BY_SERIAL_NUMBER); if((m_SerDesc==2) || (m_SerDesc==-1))//if open by device OR no method was selected { if(m_NameNmbr.GetLength() < 1)//nothing entered - open default device 0 { status = Open((PVOID)x);//load default device 0 }


77

else { if(m_NameNmbr.GetLength() > 2)//no Open() method selected... { AfxMessageBox("Select a method to open or enter a valid device number (0-64)."); return FT_DEVICE_NOT_OPENED; } //convert string to decimal number and open(x) char str[3]; strcpy(str, (LPCTSTR)m_NameNmbr); x = atoi(str); if((x<0) || (x>64)) { AfxMessageBox("Select a method to open or enter a valid device number (0-64)."); return FT_DEVICE_NOT_OPENED; } status = Open((PVOID)x); } } return status; } //******************** OPEN DLP-USB DEVICE ********************************** //**************************************************************************** void CUSBtestDlg::OnButtonHello() //code for the "Open" button { unsigned char txbuf[25], rxbuf[25]; DWORD ret_bytes; UpdateData(TRUE); m_PortStatus = _T("DLP-USB Opened"); UpdateData(FALSE); UpdateWindow(); Close(); //open the device FT_STATUS status = OpenBy(); if(status>0) { m_PortStatus = _T("Could not open DLP-USB"); board_present=0; } else { m_PortStatus = _T("DLP-USB ready."); buttons(ON);//turn em off till a port is active board_present=1; } UpdateWindow(); } //******************** GET FROM TEXT BOX THE SELECTED OPTION **************** //**************************************************************************** void CUSBtestDlg::OnSelchangeList1() { UpdateData(TRUE); int pos = m_Received.GetCurSel(); m_Received.GetText(pos, m_NameNmbr); UpdateData(FALSE); UpdateWindow(); if(m_SerDesc==0) AfxGetApp()->WriteProfileString("MyUSBTestAp", "DescString", m_NameNmbr); if(m_SerDesc==1) AfxGetApp()->WriteProfileString("MyUSBTestAp", "SerialString", m_NameNmbr);


78

if(m_SerDesc==2) AfxGetApp()->WriteProfileString("MyUSBTestAp", "DevNmbr", m_NameNmbr); } //******************** SEARCH DEVICES THROUGH THE 3 OPTIONS ****************** //**************************************************************************** void CUSBtestDlg::OnButtonSearch() { //search for Descriptions or Serial Numbers depending on the current mode FT_STATUS ftStatus; DWORD numDevs; Close();//must be closed to perform the ListDevices() function UpdateData(TRUE); m_PortStatus = _T("DLP-USB Closed."); m_NumRecd=0; m_NameNmbr = _T(""); m_Received.ResetContent(); UpdateData(FALSE); UpdateWindow(); ftStatus = ListDevices(&numDevs, NULL, FT_LIST_NUMBER_ONLY); if(ftStatus == FT_OK) { // FT_ListDevices OK, show number of devices connected in list box CString str; str.Format("%d device(s) attached:", (int)numDevs); m_Received.AddString(str); //if current mode is open "by device #" then list device numbers if((m_SerDesc==2) && (numDevs>0)) { for(DWORD d=0; d<numDevs; d++) { str.Format("%d", d); m_Received.AddString(str); } } //if current mode is open "by description" then list descriptions of all connected devices if((m_SerDesc==0) && (numDevs>0)) { ftStatus = ListDevices(&numDevs, NULL, FT_LIST_NUMBER_ONLY); if(ftStatus == FT_OK) { char *BufPtrs[64]; // pointer to array of 64 pointers for(DWORD d=0; d<numDevs; d++) BufPtrs[d] = new char[64]; BufPtrs[d] = NULL; ftStatus = ListDevices(BufPtrs, &numDevs, FT_LIST_ALL|FT_OPEN_BY_DESCRIPTION); if (FT_SUCCESS(ftStatus)) { for(DWORD u=0; u<numDevs; u++) { str.Format("%s", BufPtrs[u]); m_Received.AddString(str); } } else { str.Format("ListDevices failed"); m_Received.AddString(str); } //free ram to avoid memory leaks for(d=0; d<numDevs; d++) {


79

delete BufPtrs[d]; } } } //if current mode is open "by serial number" the list descriptions //of all connected devices if((m_SerDesc==1) && (numDevs>0)) { //AfxMessageBox("by serial"); ftStatus = ListDevices(&numDevs, NULL, FT_LIST_NUMBER_ONLY); if(ftStatus == FT_OK) { char *BufPtrs[64]; // pointer to array of 64 pointers for(DWORD d=0; d<numDevs; d++) BufPtrs[d] = new char[64]; BufPtrs[d] = NULL; ftStatus = ListDevices(BufPtrs, &numDevs, FT_LIST_ALL|FT_OPEN_BY_SERIAL_NUMBER); if (FT_SUCCESS(ftStatus)) { for(DWORD u=0; u<numDevs; u++) { str.Format("%s", BufPtrs[u]); m_Received.AddString(str); } } else { str.Format("ListDevices failed"); m_Received.AddString(str); } //free ram to avoid memory leaks for(d=0; d<numDevs; d++) delete BufPtrs[d]; } } } else { // FT_ListDevices failed AfxMessageBox("FT_ListDevices failed"); } }


80

4. PLÀNOLS


81

4.1 Introducció En aquest apartat mostrarem d’una forma detallada tots els plànols necessaris per a 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.


82

4.2 Esquema elèctric A continuació adjuntem l’esquema elèctric que obtenim un cop realitzat aquest utilitzant el programa de disseny PCAD, per a WINDOWS i imprimim el circuit en l’utilitat SCHEMATIC APPLICATION.

Figura 24. Esquema elèctric


83

4.3 Circuits impresos

Tot seguit adjuntem l’esquema del circuit imprès que obtenim un cop realitzat aquest utilitzant el programa de disseny ORCAD, per a MS-DOS i imprimim el circuit en l’utilitat LAYOUT DESIGN TOOLS.

4.3.1 Disseny de la placa

El que mostrem en aquest sub-apartat són les pistes que tindrà en propi circuit imprès un cop hem definit les pistes correctes i els traçats adequats.

Figura 25. Pcb’s Top & Bottom


84

4.3.2 Components

Finalment mostrarem quin és l’emplaçament dels components en la placa de circuit imprès fent servir, un altre cop el programa de disseny P-CAD, per a WINDOWS i imprimim el circuit en l’utilitat PCB APPLICATION.

Figura 26. Vista de components


85

5. PRESSUPOST


86

5.1 Introducció En aquest apartat del projecte es pretén detallar els preus unitaris dels materials utilitzats així com les mesures i pressupostos dels diversos blocs del muntatge.


87

5.2 Mesures

Figura 27. Taula de mesures

Número Element Valor

1 AT89C51 ( PLASTIC ) 2 DLP-USB245M 3 SWITCH ( 8PADS ) 4 XTAL 10MHZ 5 COND. 27PICOS 6 COND. 10UF 7 LED'S 8 RESISTENCIS 8,8K 9 RESISTENCIAS 10K

10 L7805 11 DIODE 1N4007 12 COND. 100n 13 COND. 33P/50V 14 COND. 47U/50V 15 Placa circuit imprès 5x10 cm 16 Regleta connexió ( POS/NEG ) 17 Sòcol ( AT89C51 ) 18 Sòcol DLP-USB245M 19 Sòcol 16 pins


88

5.3 Preus unitaris

Número Element Valor Preu

1 AT89C51 ( PLASTIC ) 8 2 DLP-USB245M 20,8 3 SWITCH ( 8PADS ) 4 4 XTAL 10MHZ 4,5 5 COND. 27PICOS 0,15 6 COND. 10UF 0,15 7 LED'S 0,24 8 RESISTENCIS 8,8K 0,2 9 RESISTENCIAS 10K 0,4

10 L7805 0,5 11 DIODE 1N4007 0,1 12 COND. 100n 0,15 13 COND. 33P/50V 0,15 14 COND. 47U/50V 0,15 15 Placa circuit imprès 5x10 cm 6 16 Regleta connexió ( POS/NEG ) 0,4 17 Sòcol ( AT89C51 ) 1 18 Sòcol DLP-USB245M 0,45 19 Sòcol 16 pins 0,35

Figura 28. Taula de preus unitaris


89

5.4 Pressupost

Figura 29. Taula del pressupost

Número Element Valor Tipus Quantitat Preu unitat Total

1 AT89C51 ( PLASTIC ) 1 8,00 € 8,00 €2 DLP-USB245M 1 15,00 € 15,00 €3 SWITCH ( 8PADS ) 1 2,00 € 2,00 €4 XTAL 10MHZ BAJO 1 3,50 € 3,50 €5 COND. 27PICOS SMD 2 0,15 € 0,30 €6 COND. 10UF DIP 1 0,15 € 0,15 €7 LED'S SMD 8 0,24 € 1,92 €8 RESISTENCIS 8,8K Tol. 1% DIP 1 0,20 € 0,20 €9 RESISTENCIAS 10K Tol. 1% SIL 1 0,40 € 0,40 €

10 L7805 DIP 1 0,50 € 0,50 €11 DIODE 1N4007 DIP 1 0,10 € 0,10 €12 COND. 100n/50V SMD 3 0,15 € 0,45 €13 COND. 33P/50V SMD 1 0,15 € 0,15 €14 COND. 47U/50V SMD 1 0,15 € 0,15 €15 Placa circuit imprès 5x10 cm 1 5,00 € 5,00 €16 Regleta connexió ( POS/NEG ) 1 0,40 € 0,40 €17 Sòcol ( AT89C51 ) PASTIC 1 1,00 € 1,00 €18 Sòcol DLP-USB245M DIP 1 0,45 € 0,45 €19 Sòcol 16 pins DIP 1 0,35 € 0,35 €


90

5.5 Resum del pressupost

Pressupost d'execució material 40,02 € Gastos generals ( 6 % ) 2,40 € Benefici industrial ( 16 % ) 6,40 € Total 48,82 € IVA ( 16%) 7,81 € Total pressupost d'execució per contracte 56,64 €

Figura 30. Resum del pressupost


91

6. PLEC DE CONDICIONS


92

6.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'aquest projecte.


93

6.2 Condicions generals

6.2.1 Descripció

La disposició d'aquest muntatge és el necessari i suficient per la realització d'un perifèric que es comuniqui amb un ordenador utilitzant el bus de comunicacions USB.

6.2.2 Execució

Primerament s'adjudicarà l'obra segons les condicions que s'indiquin; després l’empresa adjudicatària, guiant-se per aquest projecte realitzarà l’execució de l’obra. En cas que es necessiti o es cregui convenient efectuar algun canvi, l’empresa es posarà en contacte amb l’autor del projecte i arribaran a un acord per escrit per realitzar el canvi o modificació oportuns.

6.2.3 Recepció

La finalització del muntatge i lliurament del sistema haurà d'efectuar-se en un termini 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 de material, etc.

6.2.4 Responsabilitat

El constructor o l’empresa adjudicatària és l’únic responsable de l’execució del projecte, al qual s'ha compromès per lliure voluntat, sense tenir dret a la indemnització per l’increment de preus de les diferents unitats, ni per maniobres errònies que es cometin durant la seva realització. L 'administració presenta, doncs, un paper passiu limitant-se a acceptar l’oferta que se li ha fet i ha d'atendre's a aquesta, com perfectament meditada i responsabilitzada, per ser complida en seriositat i absoluta fe. L 'adjudicat és responsable també davant els tribunals dels accidents que per inexperiència, negligència o desig immoderat de lucre sobrevinguin, així com possibles incompliments de les disposicions legals vigents.


94

6.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 al d'adquisició de la firma. Si es considera raonable i s'accepta, serà confirmada per escrit, així com les noves condicions econòmiques que mútuament s'acceptin. Si tot l’anterior no es realitza tal com s'ha especificat, no s'acceptarà cap modificació. 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-ho amb la baixa corresponent aconseguida a la baixa adjudicació.

6.2.6 Manteniment

Es donarà opció a l’executant, al seu dia i a través d'un contracte a banda, a la conservació i manteniment de l’equip. També tindrà preferència a les obres d'ampliació que al futur puguin produir-se.

6.2.7 Supervisió

La firma es reserva el dret a supervisar i controlar la marxa de l’equip, tant al període de fabricació com al muntatge, a través dels seus tècnics que en tot moment tindran accés lliure a les dependències i plànols, i estaran a més facultats per refusar en qualsevol moment determinats materials i suggerir l’utilització d'altres de similars.

6.2.8 Transport

Les despeses de transport, embalatges i assegurances dels equips, fins al punt de destí, aniran a càrrec de l’empresa adjudicatària.


95

Anul·lació del contracte

L 'anul·lació del contracte només podrà ser portada a terme per alguna de les causes següents:

• Mort o incapacitació del contractista.

• Fallida de l’empresa contractista.

• Modificació del projecte per una alteració de menys d'un 25% del valor

contractat.

• 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.


96

6.3 Condicions tècniques

6.3.1 Generalitats

Les característiques tècniques seran, mitjançant mutu acord, rectificades en cas de necessitat imperiosa. De no ser així, compliran les condicions elèctriques i de paràmetres senyalats en aquest document, així com també les condicions de seguretat senyalades.

6.3.2 Normativa aplicada

Per la fabricació i instal·lació del sistema dissenyat en aquest projecte es tindran en compte les normes que estableixen els fabricants d'aparells electrònics.

6.3.3 Utilització

Si algun cop alguna operació no consta al quadre de característiques de l’equip electrònic, haurà de posar-se una especial atenció al disseny del circuit per evitar tota sobrecarrega, deguda a condicions desfavorables de funcionament. No s'han d'utilitzar dispositius electrònics en circumstancies en que es puguin donar situacions de funcionament no controlades pel fabricant.

6.3.4 Valors límits

Aquests són els valors límits de funcionament i de condicions ambientals de funcionament aplicables a qualsevol dispositiu electrònic d'un tipus especificat, tal com el defineixen les dades publicades, les quals i a les pitjors circumstancies o condicions, no han d'excedir d'aquests límits. Aquests valors són elegits pel fabricant per assegurar el bon funcionament del dispositiu, declinant tota responsabilitat per canvis de l’equip o ambientals, deguts a les variacions de les característiques del dispositiu en consideració i de tots els altres 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 fabricant com a límit ni en les condicions normals, ni als pitjors casos de treball i ambient.


97

6.3.5 Circuits integrats

Els circuits integrats estaran indicats als plànols i no podran ser substituïts per altres models que no tinguin les mateixes característiques.

6.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.

Les mesures de les tensions, corrents i potències, es faran mitjançant un muntatge de 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 i corrents que ens permetin controlar en cada moment les tensions i corrents que circulen pel transistor. Si durant alguna de les proves realitzades resultés algun component danyat, sense haver-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 responsabilitat enterament de l’empresa o casa adjudicada.

6.3.7 Resistències

Les resistències seran dels valors òhmics especificats. Totes les resistències seran de 0.25W i amb una tolerància del 5%, excepte les fixades als plànols que ho indiquin 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.


98

La mesura dels valors de resistència i tolerància s'estendran a totes les resistències i totes hauran de mantenir la seva tolerància dins d'un límit compres entre el 0.5 i e15% segons el tipus a que correspongui. Les mesures de potencia es realitzaran sometent les resistències a tensions adequades 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 permeti veure amb suficiència la seva variació de resistència amb el temps.

6.3.8 Condensadors

Tots els condensadors seran del valor capacitiu especificat als plànols. La seva tensió màxima també s'especifica als plànols. Els condensadors electrolítics seran de muntatge vertical o horitzontal segons les especificacions dels plànols. És necessari posar especial atenció en no invertir la polaritat al moment de muntar-los.

6.3.9 Circuits impresos

Les plaques de circuit imprès hauran de tenir un aïllament superficial igual o superior a 10M i seran de fibra de vidre presensibilitzades positivament, una a una cara i dues a doble cara. Les seves dimensions seran les necessàries per a que puguin contenir els esquemes. El full de coure ha de tenir un gruix normalitzat de 0.075 mm. per les pistes de senyal i 0.76 mm. per les pistes d'alimentació. La separació mínima entre pistes serà d' 1.14mm, mentre que el taladrat es realitzarà amb una broca d'1mm o inferior. La realització dels circuits impresos es farà a partir dels plànols, respectant estrictament el disseny de les pistes. Les plaques estaran cobrejades per les dues cares, de tal manera que les connexions es puguin fer per les esmentades cares encara que els elements actius sols es trobaran a una de les cares. Els connectors, encarregats de realitzar les connexions entre l’exterior i les plaques, així com les connexions entre elles, es revisaran per garantir el correcte contacte amb les plaques i s'imprimiran una sèrie d'indicacions per la seva correcte col.1ocació. Un cop soldats els components i comprovats, es procedirà a l’aplicació d'una capa de vernís especial per evitar la possible oxidació del coure amb el pas del temps.

6.3.10 Muntatge i cablejat intern

Totes les plaques a realitzar en aquest muntatge aniran a l’interior de caixes amb unes característiques apropiades d'aïllament davant possibles interferències, accions ambientals externes i altres factors negatius pel funcionament del sistema.


99

El connexionat entre plaques i altres elements es realitzarà sense alterar l’ordre indicat als plànols. Per la connexió externa s'utilitzarà cable connectat amb els connectors normalitzats segons l’estàndard USB.

6.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ó i comunicació tindrà 4 cables que corresponen a tensions d'alimentació i masses i comunicació 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 un fusible ràpid de 0.5A.


100

6.4 Condicions facultatives

6.4.1 Generalitats

La disposició d'aquest muntatge ha de ser la necessària i suficient per la realització del projecte.

6.4.2 Direcció

La direcció i control de l’execució d'aquest projecte estarà encomanada a un tècnic designat per la propietat. El facultatiu de la propietat tindrà en allò que afecta les seves relacions amb el contractista les funcions següents:

• Fer que s'executin totes les parts del projecte de manera que s'ajustin al mateix i

dins del termini fixat al contracte i terminis parcials fixats posteriorment, exigint al contractista el compliment de totes les condicions contractuals.

• Definir aquelles prescripcions tècniques que el present Plec deixi a la seva

decisió.

• Resoldre totes les qüestions tècniques que sorgeixin pel que fa a interpretació de plànols o del present Plec de Condicions, característiques dels materials; forma d'execució d'unitats constructives, medició i abonament, etc., sempre que no es modifiquin les condicions del contracte.

• Estudiar les incidències o problemes plantejats que impedeixin el normal

compliment del contracte o aconsellin la seva modificació, tramitant al seu cas les propostes corresponents.

• Obtenir dels organismes interessats els permisos necessaris per l’execució

d'aquest projecte.

• Acreditar al contractista les obres realitzades conforme el disposat al contracte i

legislació vigents.

El director podrà prohibir la participació a l’execució d'aquell personal que no compleixi les ordres donades per la direcció, cometi faltes de respecte o incorreixi en faltes omissions que pertorbin la bona marxa de l’execució.


101

6.4.3 Realització

El personal encarregat del muntatge haurà de ser el suficientment especialitzat per portar a terme aquest muntatge, segons les exigències i normes dictades al projecte segü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à de redactar el conseqüent projecte reformat, el qual es considerarà a partir del dia de la data com a part integrant del projecte primitiu. En cas de contradicció entre els plànols i les prescripcions tècniques, preval el prescrit en aquestes últimes. En qualsevol cas allò mencionat al Plec de Condicions i exclòs als plànols i viceversa haurà de ser executat com si estigués exposat en ambdós documents, sempre que a judici del director quedin les unitats suficientment definides.

6.4.4 Materials

Tots els materials que s'utilitzin hauran de complir amb rigor les condicions necessàries a judici del director tècnic, qui dins d'un criteri d'equitat i justícia es reserva el dret d'ordenar, retirar o reemplaçar, si al seu judici perjudiquessin d'alguna manera qualsevol mesura de seguretat del muntatge.

6.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 amb estricta subjecció a totes les condicions especificades en aquesta secció del projecte i del tècnic encarregat de l’instal·lació.

D'altra banda no es donarà per acabat el muntatge fins haver aconseguit un ajust de tots els elements, el qual és exigit per obtenir un rendiment i característiques de funcionament adequats.


102

6.5 Condicions econòmiques

6.5.1 Medicions

La forma de realitzar la medició i les unitats de mesura a utilitzar seran les descrites al present Plec de Condicions, aplicant quan no es prevegi unitat o se'n prevegin diverses la que fixi la direcció d'obra. Totes les mesures es faran seguint les unitats del sistema mètric decimal. Els excessos que resultin de mesurar l’obra realment executada, en relació amb allò projectat no seran d'abonament si aquests excessos són evitables; fins i tot la Direcció podrà exigir que es corregeixi l’executat perquè es correspongui exactament a allò projectat. Encara que quan aquests excessos siguin a judici del director inevitables no seran d'abonament si els mateixos formen part dels treballs auxiliars necessaris per l’execució de la unitat, ni tampoc si aquests excessos estan inclosos al preu de la corresponent unitat. Quan els excessos inevitables no estiguin en algunes de les suposicions anteriors seran 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ó o per error d'execució, la medició per abonament serà la medició d'allò realment executat. Les peces i unitats soltes es valoraran com a tals aplicant la mesura apropiada segons els preus que figurin al mercat.

6.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 cada unitat d'obra. La descripció de les operacions i materials necessaris per executar la unitat que figura als corresponents articles del present plec no és exhaustiva sinó merament enunciativa, per a la millor comprensió dels conceptes que s'inclouen a cada unitat. Per aquest motiu, les operacions o materials no relacionats però necessaris per executar en la seva totalitat la unitat d'obra formen part de la unitat i conseqüentment es consideraran inclosos al preu unitari corresponent.

6.5.3 Pagaments

En subscriure el contracte, l'empresa adjudicatària percebrà el 35% del total del pressupost i en donar per acabada l’instal·lació percebrà un altre 35%. El 30% restant quedarà com a garantia durant sis mesos.


103

Si transcorregut aquest període no s'ha detectat cap anomalia s’abonarà aquesta quantitat i al seu moment es consideraran finalitzades les obligacions existents entre les dues empreses o entitats.

6.5.4 Multes

En cas que no siguin complerts els terminis de muntatge concretats, es reduirà el 0.01% del total de l'import per cada dia que excedeixi l'esmentat termini.

6.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 es tindrà dret per part de l'administració, en cas contrari.


104

6.6 Condicions administratives

Per l'adjudicació d'aquest projecte s’obrirà concurs/subhasta pública mitjançant anuncis durant sis dies consecutius i podran presentar-s'hi totes les empreses o entitats, radicades dins el territori de l'estat o comunitat, que ho sol·licitin.

6.6.1 Adjudicació i contractes

El departament d'adjudicació de la firma decidirà dins un termini de 15 dies a partir de la determinació de lliurament d'ofertes l'adjudicació de la instal·lació i muntatge. 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 dels extrems 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 pugui derivar-se del seu incompliment.

6.6.2 Lliurament del projecte

L 'adjudicatari tindrà dret tant aviat com rebi l'ofici de l'adjudicació a disposar d'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 pugui treure'ls d'allí. Quan l'adjudicatari o els seus delegats hagin obtingut les copies, les deixarà en mans de l'autor del treball, que un cop comprovada l'exactitud de la copia ho certificarà sota la seva pròpia signatura.

Documents

Mòdul d’Entrada/Sortida controlat via USB - deeea.urv.catdeeea.urv.cat/public/PROPOSTES/pub/pdf/828pub.pdf · 2.8.2.2 Component DLP-245M ... Pau a Tarragona. 2.2 Objecte del projecte