Full text
Enginyeria Tècnica Industrial: Especialitat Electrònica Industrial METODOLOGIA DE DESENVOLUPAMENT D’APLICACIONS PC EMBEDDED FIDEL MIRAS LLOPART JULIÁN HORRILLO TELLO PRIMAVERA 2009
Resum Aquest projecte tracta sobre el procés de disseny i creació d’aplicacions embedded, especialment aquelles implementades sobre plataformes PC. Des d’un punt de vista conceptual, es donen a conèixer els principals aspectes que conformen un sistema embedded: desde les plataformes hardware, les comunicacions i els sistemes operatius fins a la metodologia de creació d’aplicacions. En el marc de desenvolupament s’explica de forma detallada la creació de la imatge executable d’un sistema operatiu i la seva transferència a un dispositiu embedded, mitjançant Windows Embedded CE 6.0. El resultat final del projecte s’obté amb la creació i transferència d’una imatge de Windows Embedded CE per al seu funcionament com a sistema operatiu al PC industrial Advantech PCM-9575. Resumen Este proyecto trata sobre el proceso de diseño y creación de aplicaciones embedded, especialmente aquellas implementadas sobre plataformas PC. Desde un punto de vista conceptual, se dan a conocer los principales aspectos que conforman un sistema embedded: desde las plataformas hardware, las comunicaciones y los sistemas operativos hasta la metodología de creación de aplicaciones. En el marco de desarrollo se explica de forma detallada la creación de la imagen ejecutable de un sistema operativo y su transferencia a un dispositivo embedded, mediante Windows Embedded CE 6.0. El resultado final del proyecto se obtiene con la creación y transferencia de una imagen de Windows Embedded CE para suyo funcionamiento como sistema operativo en el PC industrial Advantech PCM-9575 .
Abstract The primary goal of this project is the design and development of embedded applications, specifically those running over PC platforms. From a conceptual point of view, the main aspects that constitute an embedded system are presented: from hardware platforms, communication protocols and operative systems to the application development methodologies. The creation of a runtime operative system image, as well as its transmission to an embedded device using Windows Embedded CE 6.0, is described in more detail within the development framework. Finally, an example of this approach is presented. The development and transmission of a runtime Windows Embedded CE image to an Industrial PC Advantech PCM-9575, and all the documentation related, will represent a useful tool to present this kind of methodologies within the University context.
Metodologia de desenvolupament d’aplicacions PC embedded I ÍNDEX DE CONTINGUTS 1 Objecte del projecte 2 2 Abast del projecte 3 3 Marc Conceptual 5 3.1 El concepte embedded 5 3.2 El PC i la planta industrial 7 3.3 Els sistemes embedded 9 3.3.1 Plataformes PC embedded 10 3.4 Els estàndards embedded PC/104 12 3.4.1 PC/104 13 3.4.2 PC/104-Plus 14 3.4.3 PCI-104 15 3.4.4 PCI/104-Express 16 3.4.5 Evolució de l’arquitectura PC/104 17 3.4.6 Altres formats PC/104 19 3.4.7 Avantatges del PC/104 20 3.5 El processador 22 3.6 Comunicacions embedded 26 3.6.1 Comunicacions sèrie 27 3.6.1.1 RS-232 29 3.6.1.2 Wireless LAN 31 3.6.2 Comunicacions paral·lel 33 3.6.2.1 Dispositius gràfics d’E/S 34
II Índex de continguts 3.6.3 Ethernet 35 3.6.3.1 Per què utilitzar Ethernet? 36 3.6.3.2 Ethernet als sistemes embedded 37 3.6.4 Funcionament de les E/S 39 3.6.5 Board Buses 40 3.7 El sistema operatiu 41 3.7.1 Què és el sistema operatiu? 41 3.7.2 Estructura d’un sistema operatiu 42 3.7.3 Sistemes operatius de temps real 43 3.7.4 Factors de selecció d’un RTOS 45 3.7.5 Principals sistemes operatius embedded 46 3.7.5.1 Linux 47 3.7.5.2 VxWorks 48 3.7.5.3 QNX 49 3.7.5.4 Windows Embedded CE 50 4 Marc de desenvolupament 53 4.1 Desenvolupament d’aplicacions embedded 53 4.1.1 Desenvolupament entre plataformes 53 4.1.2 Emmagatzematge i actualització del software 54 4.1.3 Creació d’un entorn de desenvolupament PC embedded 55 4.2 Windows Embedded CE 6.0 57 4.2.1 Introducció 57 4.2.2 Evolució de Windows Embedded CE 58
Metodologia de desenvolupament d’aplicacions PC embedded III 4.2.3 Instal·lació de Windows Embedded CE 6.0 59 4.2.4 Terminologia de Windows Embedded CE 61 4.2.5 Entorn de disseny i eines de desenvolupament 62 4.2.6 Board Support Packages 64 4.2.7 Creació d’una imatge executable personalitzada 70 4.2.8 Connexió amb el dispositiu target 91 4.2.9 Eines i entorns de depuració 102 4.3 Creació de la imatge executable de SO per al PCM-9575 108 4.3.1 Introducció 108 4.3.2 Característiques principals del PCM-9575 109 4.3.3 Configuració del PCM-9575 110 4.3.4 Transferència de la imatge al PCM-9575 111 5 Conclusions 115 6 Glossari 117 7 Bibliografia 121 7.1 Llibres 108 7.2 Revistes i catàlegs 108 7.3 Pàgines web 109
2 Abast de projecte 2 ABAST DEL PROJECTE Amb aquest projecte es pretén posar sobre la taula les eines i els coneixements necessaris per a iniciar-se dins el món dels sistemes embedded, concretament d’aquells que es desenvolupen dins una arquitectura PC, establint una sèrie de pautes a l’hora de dissenyar un sistema d’aquesta naturalesa per a que resolgui una aplicació concreta. El projecte està dividit en dos grans blocs: el marc conceptual i el marc de desenvolupament. El marc conceptual ofereix la informació necessària per a entendre la naturalesa d’un sistema embedded, les parts que el composen i les plataformes actuals disponibles al mercat que el suporten. Està dividit en diferents apartats, que descriuen els components principals que conformen un sistema embedded: plataformes hardware, comunicacions i els sistemes operatius. El marc de desenvolupament mostra la metodologia per a la creació d’imatges executables de sistema operatiu per a sistemes embedded. Es pretén donar les pautes inicials necessàries per a poder iniciar un projecte de desenvolupament d’una aplicació embedded amb els requisits necessaris per a cada dispositiu. El marc de desenvolupament es centra en la metodologia de desenvolupament de plataformes amb Windows Embedded CE. Aquesta metodologia de desenvolupament es porta a terme en una aplicació real basada en la creació d’una imatge de Windows Embedded CE i la seva transferència al PC industrial Advantech PCM-9575. L’objectiu final del projecte és el funcionament òptim d’una imatge executable personalitzada de Windows Embedded CE com a sistema operatiu del PC industrial Advantech PCM-9575, disponible a les instal·lacions de l’Escola Universitària Politècnica de Mataró.
Metodologia de desenvolupament d’aplicacions PC embedded 3 3 – MARC CONCEPTUAL En aquest capítol 3 s’explica, de forma general, tots els aspectes teòrics previs necessaris per al desenvolupament d’aplicacions embedded. Tot enginyer de disseny de sistemes embedded ha de els conèixer aspectes conceptuals bàsics sobre la tecnologia embedded. Només així pot mesurar de forma precisa l’abast dels seus projectes des d’un punt de vista tan tecnològic com econòmic. Per a oferir una lectura més còmode i entenedora, el capítol 3 d’aquest projecte està dividit en els diferents subapartats: - El concepte embedded: Definició del concepte embedded i estat de l’art de la tecnologia embedded. - Plataformes hardware: Plataformes hardware que suporten sistemes embedded, amb una especial atenció a l’arquitectura PC/104, molt implantada al mercat actual. Processadors a sistemes embedded, principals famílies de processadors i consells per a l’elecció del processador adequat. - Comunicacions: Aspectes generals sobre comunicacions, amb especial atenció a les interfícies emprades a sistemes embedded. En aquests apartat es descriuen els principals protocols de comunicació sèrie i paral·lel i el paper que juguen a les plataformes embedded. - El sistema operatiu: Explicació conceptual del sistema operatiu i la importància d’aquest en un sistema embedded. Concepte de sistema operatiu de temps real i factors clau en l’elecció d’un sistema operatiu per a un sistema embedded. Nota: Cal tenir en compte que a la informàtica industrial actual, cada cop hi ha més complicitat entre aspectes hardware, software i de comunicacions. Per tant, la divisió anterior que s’estableix no pot ser totalment estricte i el vincle entre diferents apartats és inevitable.
4 Marc Conceptual 3.1 – EL CONCEPTE EMBEDDED 3.1.1 - El PC i la planta industrial Desde principis dels anys 70, l’evolució dels sistemes de control i automatització industrials ha caminat de forma paral·lela a l’evolució dels equips informàtics disponibles per a la realització de tasques concretes. En el control industrial, s’ha anat passant progressivament de la utilització de relés electromecànics, a l’ús de sofisticats computadors industrials, amb la conseqüent reducció de grandària dels equips i l’augment de la flexibilitat dels sistemes. Les importants millores de l’arquitectura PC en aspectes com la relació preu/prestacions, la dissipació de potència i la reducció de grandària possibiliten l’augment de la disponibilitat de productes PC ja disponibles al mercat amb diferents grandàries, configuracions, nivells de prestacions i preus. D’altra banda, la pressió en relació als temps de sortida al mercat dels productes és cada cop més alta. Això obliga als enginyers de desenvolupament a oferir solucions ràpides i flexibles en el disseny d’aplicacions. Tradicionalment, per a volums importants de producció, quan els costos de desenvolupament propi eren inferiors al cost d’adquisició d’un determinat equip, s’optava pel disseny propietari. La tendència actual va en detriment del disseny propietari i s’opta per a l’ús de tecnologies conegudes i disponibles. La omnipresència de l’arquitectura PC al mercat, amb una major disponibilitat de productes, i les notables millores en prestacions i fiabilitat del hardware, han facilitat l’ús del PC a la planta industrial. D’altra banda, les dures condicions de treball que imposa l’entorn industrial exigeixen al PC industrial major immunitat a les agressions externes. Apareixen en aquest punt presentacions constructives molt diferents a les del PC de sobretaula (xassís per a muntatge en rack, format panell, estació de treball, etc.); i equips amb una major robustesa
Metodologia de desenvolupament d’aplicacions PC embedded 5 (estanquitat, resistència mecànica al xoc i vibracions i major resistència elèctrica a sobretensions i paràsits ). Aquestes millores han anat acompanyades de la introducció de nous sistemes operatius (capacitats de multitasca i temps real), i de millores importants en les interfícies d’usuari i de comunicació amb altres sistemes. Tot plegat a propiciat la creixent entrada d’aquesta tecnologia en el camp de les aplicacions industrials, on la alternativa PC és ja una realitat. 3.1.2 – Sistemes embedded Embedded és un terme anglès que significa integrat, encastat. En termes tecnològics, un sistema embedded és el resultat de la combinació de certes funcions hardware i software, que realitzen una determinada activitat sense casi intervenció d’un usuari i formant part d’un sistema major. Poden trobar-se a les llars, oficines, plantes de producció, maquinària i automoció, i generalment controlen, protegeixen o monitoritzen alguns aspectes vitals del sistema que els conté. Generalment, un sistema embedded es configura al voltant d’un microprocessador o un microcontrolador, i incorpora els elements continguts a la figura 3.1. Habitualment, un sistema embedded consta, com a elements bàsics, de CPU, memòria de programa, memòria de dades i E/S i, generalment, no incorpora recursos d’emmagatzament de massa, com discs durs, cintes, etc. Tot i que alguns sistemes concrets poden incorporar-los . Figura 3.1. Diagrama funcional sistema embedded. Referència: article “PC embedded” del nº 316 de la revista “Automática e Instrumentación” (Març 2001), Julián Horrillo.
6 Marc Conceptual El que casi sempre existeix és algun tipus de funció de comunicació amb l’exterior que permet l’establiment dels paràmetres de funcionament de l’aplicació, així com el registre de successos. Per tant, existeix algun tipus d’interfície home-màquina, tot i que la interactivitat acostumi a ser molt reduïda. El hardware dels sistemes embedded, acostuma a estar muntat a plaques de circuit imprès (PCB); on es connecten els diferents components electrònics que formen el sistema. Tot el hardware del sistema embedded està localitzat a la capa hardware del model de sistemes embedded. Figura 3.2. Model de Sistema Embedded. Referència: “Real-Time Concepts for Embedded Systems”, Qing Li, ed. CMP Books, (2006). Els components hardware d’un sistema embedded es poden classificar en cinc principals grups: - Central Processing Unit (CPU). El processador principal. - Memòria. On s’emmagatzema el software de sistema. - Dispositius d’entrada. - Dispositius de sortida. - Components del bus. Les cinc categories estan basades en el model de Newmann, mundialment utilitzat per a l’estudi de les arquitectures hardware de dispositius electrònics.
Metodologia de desenvolupament d’aplicacions PC embedded 7 3.2 – PLATAFORMES HARDWARE 3.2.1 - Plataformes PC Embedded Existeixen diferents formats d’implementació de la plataforma PC, des d’una placa base activa que incorpora la CPU, els recursos de memòria activa i passiva i els circuits auxiliars del sistema (format utilitzat pels PC de sobretaula), fins a la utilització d’un backplane passiu que simplement conté els connectors per a la inserció de les diferents targetes que configuren el sistema. A la figura 3.3 podem observar un exemple de backplane de iEi Technology Corporation que incopora 1 slot de PCIe i 16 slots PCI, per a la connexió de tot tipus de dispositius. Aquest tipus de backplane va fixat en un rack industrial RACK-3200G-R20. Figura 3.3. Backplane PXE-19S2 de iEi Technology Corporation. Referència: http://www.ieiworld.com/ . Per a aplicacions industrials, no obstant, és molt habitual que bona part dels recursos hardware i software que incorpora un PC de propòsit general no siguin necessaris per a l’aplicació concreta que es desenvolupa. És aquí on apareix en concepte Embedded, com a plataforma que incorpora els recursos estrictament necessaris i que s’integra en un sistema major realitzant unes funcions específiques. A partir d’aquest moment, comença a guanya força l’ús d’ordinadors en una sola targeta de circuit imprès (SBC: Single Board Computer). Els SBC combinen una CPU amb alguns perifèrics, permetent configurar solucions amb un elevat grau d’integració. En la pràctica totalitat dels casos, aquesta targeta incorpora vies d’expansió a través d’algun bus extern que permet acomodar mòduls de disseny propi o comercials.
8 Marc Conceptual Els SBC no necessariament incorporen un processador Pentium IV. En moltes aplicacions serà suficient l’ús d’un 386 o un 486. De fet, les principals empreses de microprocessadors destinen processadors ja obsolets per aplicacions ofimàtiques a les línies de productes d’aplicació industrial, on sí reuneixen les característiques adequades per al seu ús. Els requisits de l’aplicació determinaran la potència del processador i quins perifèrics ha d’incorporar el SBC; intentant minimitzar d’altra banda, necessitats d’expansió del sistema en futures modificacions. Una de les arquitectures més adoptades pels fabricants de SBC és l’estàndard PC/104. L’arquitectura PC/104 pot integrar, en una targeta de 96mm x 90 mm, el processador, la memòria, la controladora de vídeo, controladora Ethernet, el bus d’expansió i les E/S, entre d’altres coses. Per exemple, sota l’estàndard EBX (que forma part també del consorci PC/104) podem trobar SBC que incorporen processadors Intel Core Duo a 667 MHz, slots de memòria 2xDDR fins a 3 GB, controladora de vídeo i àudio, ports sèrie i paral·lel, USB 2.0, interfície d’E/S de 8 bits i tots els requeriments necessaris en una board de 146.05mm x 203.20mm. Figura 3.4. Targeta 104-1462CLDN SBC PC/104 486 SBC amb CPU (133MHz), memòria i LCD, VGA, SSD, i LAN. Referència: www.evoc.com . En el següent subapartat s’explica de forma detallada l’estàndard PC/104, desde el seu origen, les diferents configuracions actuals i els principals avantatges i inconvenients d’aquesta tecnologia.
Metodologia de desenvolupament d’aplicacions PC embedded 9 3.2.2 - Els estàndards embedded PC/104 A finals dels vuitanta, el grup Ampro Computers (www.ampro.com), va crear el consorci PC/104 Embedded; per a la creació d’especificacions d’arquitectures desktop a sistemes embedded. Així es va crear l’arquitectura PC/104, un estàndard que defineix el format de la placa base (form factor) i el bus del sistema per aplicacions PC embedded. L’especificació formal del format PC/104 (IEEE P996.1), no obstant, no es publica fins l’any 1992. El nom de l’arquitectura es deu a la configuració d’una plataforma PC al voltant d’un bus ISA de 16 bits (mantenint els seus 104 pins i afegint-ne algunes línies de massa per a millorar la integritat dels senyals). Al 1997 apareix l’estàndard PC/104-Plus (bus de 120 pins), versió compacta que incorpora també el bus PCI. Al 2003 es publica l’estàndard PCI-104; que ve seguit de l’especificació PCI/104 Express que publica el consorci durant l’any 2008. Actualment, el consorci administra els estàndards PC/104, PC/104-Plus, PCI-104, EBX i EPIC, amb una gran presència al mercat; i que poden ser consultats desde la pàgina web del consorci www.pc104.org . PC/104 Un sistema PC/104 compren una targeta amb la CPU i alguns recursos generals, incorporant-se els recursos perifèrics necessaris per a l’aplicació, a targetes addicionals. Aquesta arquitectura no necessita backplanes ni motherboards; les targetes disposen de connectors que permeten la connexió directa entre elles, utilitzant una estructura de targetes apilades. D’aquesta manera es millora el grau d’integració i es redueix la grandària dels equips informàtics. Els inconvenients d’aquesta arquitectura radiquen en els problemes d’accessibilitat a les targetes d’una columna, especialment si es tracta de la zona intermitja; lo qual dificulta la substitució d’algun mòdul. Entre les seves característiques principals es destaquen: - Grandària: mòduls de 3.55 x 3.775 polzades ( 90.17 x 95,89 mm ), tal com indica la figura 3.4.
10 Marc Conceptual - Arquitectura expansible: les targetes es poden apilar, amb una separació entre mòduls de 0.6 polzades (tal com indica la figura 3.5), reduint espai i cost. - Resistència: al xoc i les vibracions. - Baix consum: estalvi energètic amb consums de 6mA (1 o 2 watts) per mòdul. - Baix cost Figura 3.5. Dimensions bàsiques (versió de 8 bits) i apilació de mòduls autònoms. Referència: http://www.pc104.org/pc104_specs.php . Una altra possibilitat que ofereix l’arquitectura PC/104 és la d’utilitzar els mòduls com a components altament integrats, assemblats dins de targetes que contenen una lògica i una interfície per a una aplicació específica; tal com indica la figura 3.6. L’arquitectura està preparada per l’addició de múltiples mòduls en una ubicació; facilitant l’actualització i ampliació del hardware durant la depuració o test del programa. Figura 3.6. Components com a aplicacions. Referència: http://www.pc104.org/pc104_specs.php .
Metodologia de desenvolupament d’aplicacions PC embedded 11 PC/104-Plus L’especificació PC/104-Plus estableix l’estàndard d’utilització del bus d’alta velocitat PCI a aplicacions embedded. Es tracta d’un versió del bus PCI, de 32 bits i 120 pins d’alta densitat (2mm), que possibilita la ràpida transferència de dades (132 Mbytes per segon). Format flexible, fiable i robust que manté les característiques de l’arquitectura PC/104. Nombrosos fabricants ofereixen productes de desenvolupament amb l’especificació PC/104-Plus com computadores SBC, high-speed LAN, interfícies de vídeo, interfícies de comunicacions (100BaseT, USB, IEEE-1394, etc.) i mòduls de control i adquisició de dades. A la figura 3.7 es poden observar les dimensions de les targetes PC/104-Plus. Figura 3.7. Dimensions bàsiques de PC/104-Plus. Referència: http://www.pc104.org/pc104_plus_specs.php . PCI-104 La diferència de l’estàndard PCI-104 respecte el seu antecessor està en l’eliminació dels connectors AT i AX, del bus ISA, encara presents a l’especificació PC/104-Plus. Com a contrapartida a la seva robustesa, el bus PCI-104, de 120 pins, no suporta extensions de 64 bits, ni els senyals JTAG, PRSNT o CLKRUN; a diferència del bus local de 32 bits PCI, amb connector de 124 pins.
18 Marc Conceptual - Els x86 tenen inconvenients associats al consum de potència, la dissipació de temperatura (amb la necessitat d’incorporar un ventilador al xip) i grandària. És molt recomanable la x86 com la plataforma d’elecció si és vol desenvolupar un sistema en reduïdes unitats o un prototip que contingui moltes característiques variades de hardware sense una gran despesa en temps de depuració del programa.. És també una bona elecció per a una sèrie de producció inicial, per a ser testejada, de cara a una segona etapa de disseny amb hardware més barat, personalitzant més el disseny. Si parlem de sistemes embedded integrats en aplicacions de producció industrial, l’arquitectura x86, fonamentalment dissenyada per a plataformes PC, pot ser una bona elecció. Com ja s’ha explicat en seccions anteriors, la omnipresència de productes compatibles amb PC al mercat ofereix grans facilitats d’actualització i modificació dels equips d’aquesta arquitectura. Això, juntament amb la gran familiaritat per part dels dissenyadors en la programació i configuració del software en l’arquitectura PC, són els factors claus per a l’elecció dels sistemes PC embedded. El fet d’utilitzar un processador x86 no significa que hagi d’anar implementat en una motherboard típica d’un PC desktop, de grandària considerable. Els formats SBC, amb el suport d’estàndards com PC/104 (del que s’ha parlat àmpliament al tema 3), ofereixen solucions amb una alt poder computacional en reduïdes mides. Una altra família de microprocessadors de 32 bits a sistemes embedded digna de ser comentada és l’arquitectura ARM. És un dels processadors més utilitzats en el món embedded, de la mateixa manera que els x86 ho són en el món PC desktop. És una arquitectura consolidada, amb molts productes compatibles al mercat, que garanteixen el subministrament i suport de la plataforma en diferents mides, funcionalitats i dissenys. A més, són processadors petits i amb un baix consum en relació amb el seu rendiment. Amb tot això es pot dir que és una alternativa interessant per als sistemes embedded.
Metodologia de desenvolupament d’aplicacions PC embedded 19 3.3 – COMUNICACIONS 3.3.1 – Aspectes generals Un camp de vital importància dintre de la informàtica industrial és el de les comunicacions embedded. Sovint, els sensors, actuadors, monitors i d’altres elements que composen un sistema embedded estan ubicats a diferents llocs. Això fa necessària l’existència d’una xarxa de comunicacions. A més, el sistema embedded també ha de comunicar-se amb el sistema superior al que està subordinat, o amb altres sistemes embedded. Aquesta funció d’interconnexió la pot fer una targeta d’E/S ( I/O board ) o una targeta CPU embedded que tingui les E/S integrades a la placa. Les interfícies d’E/S poden estar composades per algun o varis de les següents elements: - Medi de transmissió, cablejat o sense fils, connecta el dispositiu d’E/S amb la targeta embedded per la comunicació i l’ intercanvi de dades. - Port de comunicació, a través del qual el medi de transmissió connecta amb la targeta d’E/S. En el cas de comunicacions wireless, serà el receptor del senyal wireless. - Interfície de comunicació, que gestiona la comunicació de dades entre la master CPU i el dispositiu o controlador d’E/S i és el responsable de codificar i descodificar les dades. - Controlador d’E/S, un processador slave que gestiona el dispositiu d’E/S. - Busos d’E/S, la connexió entre la targeta d’E/S i el processador master. - Processador mestre, amb E/S integrades.
20 Marc Conceptual Quan parlem de xarxes de comunicació, hem de parlar del model OSI. El model de referència d’Interconnexió de Sistemes Oberts OSI (Open System Interconnection) publicat al 1984, fou un el model de xarxa descriptiu creat por ISO (International Organization for Standardization); esdevenint un marc de referència per a la definició d’arquitectures d’interconnexió de sistemes de comunicacions. El model OSI està format per diferents nivells o capes. Les capes de nivell més baix proporcionen serveis a les capes immediatament superiors. No obstant, totes les capes tenen una responsabilitat durant la transmissió de dades. Per als sistemes de comunicació embedded, els nivells OSI més importants són els nivells 1 i 2, corresponents al nivell físic i d’enllaç de dades respectivament (observar figura 3.12). Figura 3.12. Capes o nivells OSI i TCP/IP d’un sistema de xarxa. Com es pot observar, Ethernet correspon als nivells físic i d’enllaç de dades. Referència: http://es.wikipedia.org/wiki/Modelo_OSI . La figura 3.12 ens mostra una comparativa entre els models OSI i TCP/IP. Tal com es pot observar, Ethernet pertany als nivells físic i d’enllaç de dades; que són els més importants per als sistemes embedded, tal com ja hem indicat.
Metodologia de desenvolupament d’aplicacions PC embedded 21 TCP/IP (Transmmition Control Protocol / Internet Protocol) és el nom que s’empra per a referir-se a un important número d’especificacions de protocols (TCP/IP/ARP/RARP/ ICMP/IGMP/UDP/BOOTP/D HCP/FTP/HTTP), i que es basa, d’igual manera que el model OSI, en el concepte de capa o nivell, on cada nivell realitza un treball específic i delimitat. Ethernet té diverses propietats que el fan ideal per la majoria d’aplicacions de sistemes embedded distribuïts. Primer, Ethernet és un protocol completament descentralitzat. No hi ha una estació centralitzada de polling que pugui fallar. Segon, Ethernet en la majoria de les seves versions bàsiques corre en 10 Mbit/s, una magnitud molt major que la de la majoria dels protocols embedded. I tercer, és un protocol de xarxa conegut i àmpliament estès a plataformes desktop, lo qual redueix el temps de configuració i assegura la connectivitat. Seguirem parlant d’Ethernet amb més profunditat més endavant. Protocols com Fieldbus, ControlNet, Interbus, i CAN han estat desenvolupats específicament per a la connexió de sistemes embedded de temps real. Aquests protocols acostumen a ser lents (al voltant de 1 Mbit/s), però ofereixen un major determinisme que múltiples mètodes d’accés utilitzats per xarxes desktop. Per a aplicacions de temps real dur (del que en parlarem més endavant), el determinisme és clau, atès que la pèrdua de missatges pot tenir resultats catastròfics. Ethernet no es determinista. No obstant això, per a sistemes de temps real suau, que no fallen perillosament si un missatge és perdut ocasionalment, és possible que el protocol d'una xarxa local d’alta velocitat com LAN (Local Area Network) pugui proporcionar un funcionament comparable a un protocol embedded específic. A la taula 3.2 es mostra una comparativa de diferents interfícies de comunicació. Podem observar com els protocols més actuals, com firewire o USB, ofereixen una velocitat molt superior a protocols tradicionals com el RS-232, d’un ús més industrial.
22 Marc Conceptual Interface Format Número màxim de dispositius Longitud màxima (m) V elocitat màxima (bits/seg.) asíncron RS-232 (TIA/EIA- 232) sèrie 2 15 - 30 20K (115K amb alguns drivers) asíncron RS-485(TIA/EIA- 232) sèrie 32 unitats en càrrega 1200 10M asíncron IrDA infraroig sèrie 2 1.8 115K síncron Microwire sèrie 8 3 2M síncron SPI sèrie 8 3 2.1M síncron Taula 3.2. Comparativa d’interfícies de comunicació populars. Referència: “Serial port complete: programming and circuits for RS-232 and RS-485 links and networks”, Jan Axelson, ed. Ilustrated. 3.3.2 - Comunicacions sèrie A les comunicacions sèrie les dades són emmagatzemades, transferides i rebudes una a una (un bit per instant de temps). Les interfícies sèrie gestionen la transmissió i recepció de dades entre la CPU master i el controlador o dispositiu d’E/S. Aquestes dades poden ser transmeses de tres maneres diferents: - Simplex: Un node exerceix de transmissor i l’altre de receptor, i no poden intercanviar els papers. Observar figura 3.13. - Half-Duplex: Ambdós nodes poden transmetre i rebre dades, però no simultàniament. Quan un node està enviant dades l’altre exerceix de receptor i a la inversa. Observar figura 3.14. - Full-Duplex: Ambdós nodes poden transmetre i rebre dades simultàniament. sèrie 40 5.5 400K asíncron 2 I C sèrie 127 5 12M USB sèrie 64 4.5 400M Firewire paral·lel 15 18 1M IEEE-488 (GPIB) sèrie / paral·lel 1024 487 10M Ethernet bucle de corrent sèrie 2 4.5 31.5K MIDI Paralell Printer Port paral·lel 2 o 8 (amb suport) 03-Sep 1M
Metodologia de desenvolupament d’aplicacions PC embedded 23 Figura 3.13. Esquema exemple d’una transmissió Simplex. Figura 3.14. Esquema exemple d’una transmissió Half-duplex. Figura 3.15. Esquema exemple d’una transmissió Full-duplex. Referència: “Embedded hardware, know it all”, Jack Ganssle, ed. Newnes, 2008. Aquestes transmissions poden fer-se de forma síncrona, per intervals regulars de temps (el clock de la CPU determina les transferències) o asíncrona, amb intervals de temps irregulars. El gran avantatge de les comunicacions sèrie és la suficiència d’un o dos pins d’E/S per a realitzar la comunicació, en comparació amb els vuit o més pins necessaris a les
24 Marc Conceptual comunicacions paral·leles. Molts perifèrics de sistemes embedded comuns, com convertidors ADC i DAC, LCD, i sensors de temperatura, suporten interfícies sèrie. Els busos sèrie poden també realitzar comunicacions entre processadors. Això permet realitzar tasques, amb grans volums de processament de dades, que requeririen un processador més potent, realitzar-les amb petits processadors, generalment més econòmics. Els estàndards sèrie més populars i àmpliament utilitzats són els pertanyents a la família EIA-RS-232/422/485. Ideals per aplicacions de baix cost que requereixen interconnexió sèrie. A la taula 3.3 es mostra una comparativa dels tres estàndards, amb les seves característiques principals. Paràmetre RS-232 RS-422 RS-485 Mode d’operació Simple Diferencial Diferencial Número de dispositius 1 emissor - 1 receptor 1 emissor - 10 receptors 32 emissors - 32 receptors Màx. longitud cable 15 m 1200 m 1200 m Màx. Velocitat 20 Kbps 10 Mbps 10 Mbps Càrrega driver De 3k a 7k 100 mínim 60 mínim Entrada receiver De 3k a 7k 4k 16k Tensió en mode comú ±25V ±7V De -7V a 12V Taula 3.3. Anàlisi comparatiu entre estàndards de comunicació sèrie. Referència: “Instrumentación virtual: Adquisición, procesado y análisis de señales”, Antoni Mànuel, Edicions UPC1901. RS-232 L’estàndard RS-232 o EIA-232 (Electronic Industries Association-232) és un dels protocols sèrie més àmpliament implementats a transmissions síncrones i asíncrones. Va ser utilitzat originàriament per a connectar teletips i computadors a mòdems. Molts dispositius, ja obsolets, com impressores i plotters van utilitzar l’estàndard RS-232C. Amb la necessitat de transferir grans quantitats de dades de forma ràpida, el RS-232 va ser suplantat com a connexió estàndard per a protocols més ràpids, com Ethernet. No obstant, segueix sent una interfície molt útil per a la connexió de dispositius a sistemes embedded.
Metodologia de desenvolupament d’aplicacions PC embedded 25 Figura 3.16. Aplicació original del RS-232: connectar teletips a mòdems. Referència: “Designing Embedded Hardware”, John Catsoulis, ed. O’Reilly. Es tracta d’un interfície punt a punt, de velocitats de comunicació baixes i distàncies curtes (20Kbps i 18 metres respectivament). Tot i no estar reflexat a l’especificació, l’interfície pot treballar a majors velocitats i longituds amb resultats acceptables. Connexions de fins a 115 Kbps, amb connexions de curta distància, i fins a 60 metres, emprant cable de baix capacitància, han estat implementades amb èxit. R-232 és un bus no equilibrat capaç d’establir comunicacions full-duplex entre dos parells receptor/transmissor, anomenats data terminal equipment (DTE) i data communication equipment (DCE). Cadascun té un senyal de transmissió connectat al pin del senyal de recepció de l’altre. Normalment, el PC o el sistema embedded és un DTE i el perifèric connectat és un DCE. Cada transmissor envia les dades variant el voltatge a la línia. Un voltatge més alt de 3V és un “0” binari, mentre que un voltatge de menys que -3V és un “1” binari. Entre aquests voltatges, el valor és indefinit. Per a convertir aquests nivells en nivells de lògica (0 i 5V), pot ser utilitzat un CI de conversió a R-232, com els 1488, 1489, o MAX232. Una comunicació típica RS-232 consisteix en un bit de start, bits de dades, bits de paritat (si n’hi ha) i un bit de stop (8N1). L’estàndard RS-232 defineix un total de 25 senyals, junt amb el connector és el DB25. No obstant, EIA RS-232 Standard EIA547 defineix només vuit senyals, compatibles amb el connector DB9 i l’estàndard EIA561 defineix vuit senyals , compatibles amb el connector RJ45.
26 Marc Conceptual Taula 3.4. Descripció dels senyals i pins de RS-232 a connectors DB25. Referència: “Embedded hardware, know it all”, Jack Ganssle, ed. Newnes, 2008. Figura 3.17. Pinatge del connector mascle DB25, RS-232. Referència: “Embedded hardware, know it all”, Jack Ganssle, ed. Newnes, 2008.
Metodologia de desenvolupament d’aplicacions PC embedded 27 Taula 3.5. Descripció dels senyals RS-232 al connector DB9. Referència: “Embedded hardware, know it all”, Jack Ganssle, ed. Newnes, 2008. Taula 3.6 i Figura 3.18. Descripció dels senyals RS-232 al connector RJ45. Referència: “Embedded hardware, know it all”, Jack Ganssle, ed. Newnes, 2008. Dos dispositius DTE poden comunicar-se entre si, utilitzant una variació interna del cables sèrie anomenada null modem, que canvia la naturalesa dels DTE i permet comunicacions coordinades. Molts sistemes embedded utilitzen el bus RS-232 per a la comunicació amb PC o amb perifèrics de PC com mòdems. Normalment, els fabricants de microcontroladors ofereixen productes que inclouen suport de hardware per a RS-232. Per a comunicacions síncrones els anomenats SPI (Serial Peripheral Interface). Per a
34 Marc Conceptual El motor geomètric és el responsable de definir els models de color, la geometria física i les propietats lluminoses i materials dels objectes. El motor d’interpretació (rendering engine) és el responsable de captura la descripció dels objectes; proveint funcionalitats de suport per a les transformacions geomètriques, projeccions, mapejat, sombrejat i il·luminació. El motor de trama i presentació és, llavors, el responsable de la presentació física de l’objecte; allà on entra el hardware de sortida. Els dispositius gràfics de sortida són principalment pantalles i/o impressors i treballen amb interfícies en paral·lel. Les configuracions de ports paral·lels actuals difereixen d’estàndard a estàndard en termes de senyals i cables requerits. 3.3.4 – Ethernet Per què utilitzar Ethernet? Les comunicacions mitjançant Ethernet han estat emprades tradicionalment per a connectar estacions de treball d’empresa i per a transferir dades en temps no real. L’èxit d’Ethernet en el món desktop és a causa de la seva senzillesa, expandibilidad, robustesa, i econòmica implementació. Basades en l’èxit d’Ethernet com a xarxa de dades, les xarxes de comunicació embedded de temps real suau van començar a aplicar l’estàndard Ethernet de 10 Mbit/s per motius d’economia, familiaritat, i compatibilitat amb les xarxes d’empresa. A partir d’aquest moment, començaren a sonar amb força paraules com Embedded Ethernet o Embedded TCP/IP i, actualment, ja són possibles implementacions TCP/IP amb reduïts requisits d’emmagatzament i de potència computacional, exigències pròpies dels sistemes embedded. El mètode ideal per a resoldre la interconnexió de diferents sistemes embedded, i de permetre alhora que aquests puguin ser globalment accessibles per a les xarxes d’empresa, és la utilització de protocols de xarxa ja existents (per exemple, TCP/IP), de manera que no sigui necessària la programació del mateix, reduint tant els costos com el temps de desenvolupament.
Metodologia de desenvolupament d’aplicacions PC embedded 35 Figura 3.25. Targeta PCB Ethernet model ETHERNUT 1. Amb microcontrolador de 8 bits ATMEGA 128 treballant a 14.7456 MHz, controladora Ethernet de 10 Mbit/s REALTEK i 32 KB de SRAM externa. Referència: http://www.ethernut.de/ . Al mercat hi ha disponibles SBC amb implementacions de l’especificació original Ethernet a 10Mbits/s i FastEthernet a 100Mbits/s. En aquest últim cas es requereix major potència de processament, i sol ser necessari un bus de tipus PCI, que és possible trobar inclús als SBC del format més petit, com el PC/104. Ethernet als sistemes embedded Ethernet és el protocol LAN més àmpliament utilitzat. Està basat principalment en la família d’estàndards 802.3, que defineixen els principals components que formen un sistema Ethernet. Diferents arquitectures i sistemes embedded poden implementar components Ethernet de diferents maneres. No obstant, a la majoria del casos Ethernet és implementat quasi totalment amb hardware. El hardware correspon al nivell físic del model OSI i , el software necessari per habilitar les funcions d’Ethernet correspon a la capa o nivell d’enllaç de dades. Els dispositius Ethernet es connecten en xarxa a través dels cables Ethernet, que poden ser del tipus coaxial, parells trenats, fibra òptica, etc. Els cables utilitzats estan referenciats segons tres components: el ràtio de transmissió de dades, el tipus de senyal utilitzada i el tipus o la longitud del cable utilitzat.
36 Marc Conceptual Per exemple, un cable 10Base-T té un ràtio de transmissió de dades de 10 Mbps, empra només senyals Ethernet i és del tipus parells trenats. El cable 10Base-F, en canvi, té les mateixes característiques de funcionament, però és un cable de fibra òptica. El tipus de cable que es connectarà a la targeta d’E/S és, de fet, el que determinarà si la transmissió Ethernet serà sèrie o paral·lela. El port de comunicacions de la targeta d’E/S per on es connectarà el cable s’anomena MDI (Medium Dependent Interface). Existeixen diversos MDI per als diferents tipus de cables Ethernet. Per exemple, el cable Base10-T té un MDI del tipus jack RJ-45. Alguns dispositius LAN implementen diferents combinacions de components Ethernet i assoleixen grans velocitats de transmissió. És el cas de l’IEEE 802.3u Fast Ethernet ( de 100Mbps) i de l’IEEE 802.3z Gigabit Ethernet (de 1000Mbps). 3.3.5 – Funcionament de les E/S És un dels aspectes més importants d’un disseny embedded, ja que poden alterar negativament el funcionament del sistema esdevinguent “el coll d’ampolla” del sistema. s’ha d’entendre el funcionament de cada dispositiu d’E/S de forma individual. Sobretot, en el cas de dissenys propietaris, el dissenyador haurà de tenir en consideració cada dispositiu d’E/S per a prevenir aquestes situacions. Alguns dels aspectes més importants del funcionament compartit d’E/S que poden afectar al sistema són: - Les velocitats de transmissió dels diferents dispositius d’E/S. Diferents dispositius d’E/S, connectats a una mateixa targeta, poden variar en tasses de transmissió de dades d’uns pocs caracters per segon (com els teclats o ratolins) fins a varis Mbytes per segon (con en el cas de discos). - Sincronització de velocitats entre el processador mestre i les E/S. Agafant d’exemple els casos de funcionament més extrem, les velocitats de treball entre el processador mestre i les E/S poden variar considerablement. Tenint connectat un dispositiu d’E/S extremadament ràpid, el processador podria no
Metodologia de desenvolupament d’aplicacions PC embedded 37 estar llest a temps per a processar el volum de dades entrant, cada cop que les E/S demanessin la seva atenció. D’altra banda, amb un dispositiu d’E/S processant molt més lentament que la velocitat de transmissió del processador, es podrien perdre les dades transmeses. - Comunicació entre el processador mestre i les E/S. Això varia segons si hi ha un controlador d’E/S que fa d’intermediari entre el processador mestre i les E/S, alliberant la CPU per a processar dades més ràpidament. Respecte el controlador d’E/S, pot variar el comportament del sistema segons si funciona per interrupcions, pulling o mapeig a memòria (amb una DMA dedicada també a alliberar de tasques a la CPU). En el funcionament per interrupcions, àmpliament estès, uns dispositius d’E/S poden interrompre’n d’altres o es poden formar cues d’espera de torn; funcionant el sistema de forma eficient. Per a evitar aquests “colls d’ampolla” els dissenyadors han d’examinar els diferents esquemes de comunicacions entre processadors mestres i E/S per assegurar el correcte funcionament del sistema. S’han de tenir en compte certs aspectes, com el temps de resposta o d’execució dels diferents dispositius. Idealment, es realitzarà el disseny tenint en compte que el dispositiu de menor rendiment serà el que determinarà el rendiment global del sistema. 3.3.6 – Busos interns Els principals components d’un sistema (processador, memòria, E/S) són connectats a la targeta embedded mitjançant, com a mínim un bus. No obstant, targetes més complexes poden integrar varis bussos; amb bridges (ponts) instal·lats a la targeta que interconnecten els diferents busos entre sí. Els bridges poden proveir automàticament informació de mapejat d’adreces, quan les dades són transmeses d’un bus a un altre; o implementar diferents requeriments de senyals de control de diversos busos. Els busos interns poden classificar-se en les tres categories que es descriuen a continuació: - Busos de sistema: També anomenats busos principals, locals o de processador-memòria, interconnecten la memòria externa principal i el cache
38 Marc Conceptual a la master CPU o als ponts cap als altres busos. Són normalment més curts i ràpids que els busos convencionals. - Busos de backplane: Interconnecten la memòria, el processador mestre i les E/S en un únic bus. També anomenats busos d’expansió, externs o de host, actuen com a extensions del bus de sistema, connectant la resta de components a la master CPU, als bridges d’interconnexió de busos i/o el mateix sistema embedded a un port de comunicacions. - Busos d’E/S: Acostumen a ser busos estandarditzats, que poden ser petits i ràpids com PCI o USB, o més grans i lents com SCSI. La principal diferencia entre els busos d’E/S i els busos de sistema és la possible presència de senyals de control IRQ (interrupt request) als busos d’E/S. Una línia IRQ habilita els dispositius d’E/S al bus, per a indicar al processador mestre que un esdeveniment està tenint lloc o que una operació ha estat completada. Diferents busos d’E/S tenen diferents comportaments en els mecanismes d’interrupció. Un bus ISA, per exemple, necessita que cada targeta que genera una interrupció tingui assignat un valor únic d’IRQ (configurant els switches o jumpers de la mateixa targeta). El bus PCI, d’altra banda, assigna un mateix valor d’IRQ a més d’una targeta d’E/S. Dins d’una mateixa categoria de busos, aquests poden ser dividits entre expandibles o no expandibles. Un bus expandible (PCMCIA, PCI, IDE, SCSI, USB, entre d’altres és aquell al qual se li poden afegir i connectar components addicionals a la targeta. Els busos no expandibles (DIB, VME i I2C en són exemples) no permeten la addició i connexió de components addicionals a la targeta i comunicar aquests a través del bus amb els altres components. Tot i que els sistemes que implementen busos expandibles són molt més flexibles, aquests també tendeixen a ser més cars d’implementar. Si la placa no està inicialment dissenyada amb tots els possibles components que pugui necessitar en un futur, el funcionament es veurà afectat negativament per la addició d’excessius components addicionals.
Metodologia de desenvolupament d’aplicacions PC embedded 39 3.4 – EL SISTEMA OPERATIU 3.4.1 – Què és el Sistema Operatiu? El sistema operatiu és aquell conjunt de programes (software i firmware) responsable de gestionar els recursos en un ordinador, posant a disposició de l’usuari tot el seu poder computacional. En altres paraules, el sistema operatiu constitueix una capa d’abstracció que permet als programes de l’usuari accedir als recursos del sistema, utilitzant els serveis que ofereix el propi SO. D’aquesta manera, l’ordinador és vist per l’usuari com una màquina virtual fàcil d’utilitzar. Aquest fet és l’impulsor de l’auge que està experimentant la utilització de sistemes basats en PC embedded en el desenvolupament d’aplicacions específiques, tant en l’àmbit domèstic com en l’industrial. Els aspectes funcionals que puguin ser resolts pel SO no tindran que ser dissenyats específicament, amb el conseqüent estalvi de temps i costos de desenvolupament. El SO s’encarrega de la gestió, assignació i maximització de l’ús dels recursos, d’implementar les funcions de control necessàries per a fer operatius els programes d’usuari i els dispositius d’E/S, i d’incorporar funcions de gestió de la memòria, la CPU i la E/S; tot això amb l’objectiu de facilitar l’ús de la màquina, resoldre els aspectes generals de control del sistema i aconseguir un funcionament eficient del mateix. Aquesta situació permetrà al dissenyador centrar tota la seva atenció en el desenvolupament del software – i en ocasions del hardwarede l’aplicació que s’està desenvolupant. Un aspecte interessant del sistema operatiu és la modularitat, que permetrà incorporar a l’aplicació concreta aquelles funcionalitats que són estrictament necessàries per a la mateixa. No s’ha d’oblidar que en la majoria dels casos, el PC embedded no incorpora sistema d’emmagatzament de massa i, per tant, el SO ha de residir en memòria del semiconductor, raó per la qual interessa que ocupi el menor espai possible.
40 Marc Conceptual Algunes de les característiques que incorpora el sistema operatiu són les següents: - Multitasca. Realitza varis procediments per a funcions com la creació de noves tasques; o decidir quina tasca s’ha d’executar en cada moment, proporcionant mecanismes per a que el processador pugui canviar d’una tasca a una altra. - Proporciona una interfície de màquina virtual als dispositius d’E/S connectats al sistema. Això significa que el sistema operatiu conté un software per a comunicar aplicacions d’usuari al hardware. A més, el sistema operatiu ha de controlar l’accés a aquest hardware, tenint en compte que diverses tasques poden voler accedir al mateix perifèric en el mateix moment. - Proporciona funcions de gestió de memòria. Aquestes funcions permeten l’assignació de memòria a tasques d’usuari. - Proporciona software de control d’arxius; el qual habilita aplicacions de manipulació de fitxers a dispositius com discos; sense haver de preocupar-se de l’assignació de blocs físics en el mitjà d’emmagatzament dels arxius. Els sistemes operatius es poden classificar en dues categories principals segons la naturalesa del seu comportament en vers al temps: - Sistemes operatius de temps real (RTOS) - Sistemes operatius de no temps real (NRTOS) L’elecció d’una de les dues categories dependrà del temps de resposta necessari, a partir de les especificacions de l’aplicació. Si el temps de resposta pot ser gran, un SO de propòsit general. Per assegurar la resposta dins d’intervals de temps reduïts, un RTOS. L’elecció del SO es un aspecte clau del desenvolupament de l’aplicació, i ha de realitzar-se després d’establir de forma detallada les especificacions de la mateixa. La oferta de SO per a PC embedded és cada cop més amplia i interessant i, en el moment
Metodologia de desenvolupament d’aplicacions PC embedded 41 actual, ja permet cobrir les necessitats de la majoria d’aplicacions en l’entorn industrial, que requereixen sistemes de gama baixa i mitja. Poden trobar-se al mercat sistemes de propòsit general, de temps real i reduïda grandària, desenvolupats especialment per a controlar sistemes embedded. 3.4.2 - Estructura d’un sistema operatiu Els sistemes operatius estan basats en una estructura de capes o nivells, on cada nivell té un rol ben definit. L’estructura típica d’un sistema operatiu basat en capes es mostra a la figura 3.26. La part central anomenada kernel és la encarregada de donar suport multitasca al sistema. És a dir, és la part encarregada de canviar d’una tasca a una altra dins del sistema. Normalment està escrit en llenguatge assembler, donat que requereix l’accés a funcionalitats de molt baix nivell en el processador. La tendència moderna als sistemes operatius és tenir un “micro-kernel” (“un kernel molt petit”, tot i que en alguns casos pot arribar a ocupar 100 kbytes). Figura 3.26. Estructura de capes d’un sistema operatiu genèric. Referència: “Introduction to Real-Time Operating Systems”, Robert Betz, 2001.
42 Marc Conceptual Per sobre del kernel, es troba la memòria virtual. És una capa també molt privilegiada en l’accés al processador i s’encarrega de l’assignació de memòria i la protecció del sistema. Les altres capes acostumen a consistir en grans quantitats de codi i proporcionen facilitats a les E/S, al sistema de fitxers, a l’interfície d’usuari, etc. La profunditat d’una capa en un sistema operatiu en mode protegit indica el grau de confiança. Un clar exemple és el nivell d’usuari, amb menys privilegi, per a evitar l’error humà. No obstant, la figura 3.21 ens mostra un model d’estructura de capes molt bàsic. Els sistemes operatius actuals tenen estructures molt més complexes, com veure’m més endavant. 3.4.3 – Sistemes operatius de temps real Els sistemes operatius de temps real (RTOS: Real-Time Operating Systems) faciliten la creació de sistemes de temps real, però no garanteixen que el resultat final sigui un sistema de temps real estricte; aquests requereixen un desenvolupament correcte del software. Un RTOS no necessàriament ha de tenir una velocitat de funcionament alta; més aviat, proporciona facilitats, les quals, utilitzades apropiadament, garanteixen la finalització de les operacions dins d’un temps establert. Els RTOS es divideixen en: - Soft Real-Time Operating Systems: Els Sistemes operatius de temps real tou són aquells que finalitzen les operacions GENERALMENT dins de les restriccions temporals marcades. - Hard Real-Time Operating Systems: Els Sistemes operatius de temps real dur són aquells que finalitzen les operacions DETERMINÍSTICAMENT dins de les restriccions temporals marcades. En poques paraules, un RTOS es valora més per lo ràpidament i/o previsiblement que pot respondre a un esdeveniment particular, que per la quantitat de treball que pot realitzar sobre un període de temps donat.
Metodologia de desenvolupament d’aplicacions PC embedded 43 Els factors clau en un RTOS són, per tant, la latència mínima d’interrupció (minimal interrupt latency) i la latència mínima de commutació de fil (minimal thread switching latency). La latència d’interrupció és el temps transcorregut entre el moment en que és genera una interrupció, per part d’un dispositiu, i el moment en el que aquesta interrupció és atesa pel sistema. La latència de commutació de fil és el temps que necessitat el sistema operatiu per canviar de la CPU a un altre fil. Una altra classificació que es pot donar per als sistemes operatius es la següent: - Sistema operatiu estàtic: Un sistema operatiu estàtic és aquell en el que el nombre de tasques pot ser definit, de forma exacta, abans de que s’executin. Per tant, quan s’inicia el sistema es crea el nombre de tasques a realitzar, i aquest nombre no canvia. - Sistema operatiu dinàmic: És aquell en el qual el nombre de tasques a efectuar-se no se sap a priori. Les tasques són creades i destruïdes mentre el sistema està operant. Un clar exemple d’això el trobem als sistemes informàtics de temps compartit, en el que el nombre de tasques canvia de forma indeterminada segons els usuaris van entrant i sortint del sistema. Moltes aplicacions de temps real dels sistemes operatius embedded van emmagatzemades en una ROM. Com el SO i el codi estan emmagatzemats en una ROM, les tasques no poden ser creades o esborrades. Per tant, molts sistemes de temps real són estàtics. Evidentment hi ha moltes excepcions a aquesta afirmació, i es poden trobar RTOS dinàmics en aplicacions que requereixin una interactivitat amb l’usuari.
50 Marc Conceptual 3.4.7 – QNX Sistema operatiu de temps real desenvolupat per QNX Software Systems Ltd. Està constituït per un autèntic micro-kernel rodejat d’un conjunt de mòduls opcionals (resource managers) que poden ser inclosos segons les necessitats de l’usuari. Cada driver, aplicació, protocol stack i sistema d’arxius s’executen fora del kernel, a l’espai d’usuari de memòria protegida. Això fa que la falla de qualsevol component no afecti el kernel i, per tant, la fiabilitat del sistema. QNX Neutrino (la seva última versió) pot acabar un procés amb un component en falla i refer el sistema, sense la necessitat de reiniciar-lo. Els seus algoritmes de planificació són similars als empleats per VxWorks, reunint les característiques pròpies del emprats pels RTOS de més altes prestacions. QNX ofereix tots els avantatges d’un RTOS d’aplicació en sistemes embedded: mida reduïda (permet la ubicació del SO en memòria ROM), escalable, extensible i ràpid. Una configuració reduïda de QNX, incorporant el micro-kernel i algun mòdul opcional bàsic, poc ocupar al voltant de 64KB de memòria. Les principals característiques de QNX Neutrino són les següents: - Processos de watchdog per a aplicacions de monitorització i recuperació de processos de comunicacions, amb drivers de reiniciació de dispositius i serveis de sistemes operatius - Suport a tecnologies networking IPv4, IPv6, IPSec, FTP, HTTP, SSH i Telnet entre d’altres. - Completa interfície gràfica d’usuari Photon microGUI.
Metodologia de desenvolupament d’aplicacions PC embedded 51 - Eines de visualització per a la traça d’esdeveniments del sistema, incloent interrupcions, sincronització i utilització de la CPU - Alta escalabilitat i capacitats incorporades de multiprocessament multi-nucli. - Gran portabilitat amb el suport extensiu de l’estàndard POSIX , que permet la ràpida migració de Linux, Unix i altres programes de codi obert. - Suport en temps d’execució i BSP per als principals chipsets, incloent MIPS, PowerPC, SH-4, ARM, StrongArm, XScale, i x86. 3.4.8 – Windows Embedded CE Windows Embedded CE és un sistema operatiu de 32 bits, de temps real dur, desenvolupat per Microsoft per a satisfer les necessitats de portàtils, mòbils, i dispositius embedded. Amb suport per a múltiples arquitectures de processador (x86, MIPS, ARM i SH4), Windows Embedded CE pot ser adaptat a una gran varietat de dispositius com Smartphones, PocketPCs, càmeres digitals, caixers automàtics, routers de xarxa, projectors wireless, computadors industrials, etc. Alguns dels dispositius, com els Smartphone o els PocketPC, tenen una interfície molt visual. D’altres aplicacions, en canvi, no són visibles al usuari final. Aquests dispositius són construïts per a proporcionar un conjunt de funcions concretes, com és el cas d’instruments de prova, dispositius d’adquisició de dades, computadors industrials, entre d’altres. La tendència dominant als anys 90 en el desenvolupament de sistemes embedded era la utilització de microprocessadors de 8 o 16 bits amb funcionalitat limitada, requerint l’ús de llenguatges de programació de baix nivell. La ràpida evolució de la tecnologia del
52 Marc Conceptual silici, va donar entrada a processadors de 32 bits, més petits i ràpids, de forma relativament econòmica. Una nova generació de hardware de 32 bits és ara fàcilment disponible a baix cost. Les companyies poden desenvolupar nous productes amb característiques addicionals al baixar el temps de desenvolupament d’aquests. Això possibilita l’ús de sistemes operatius de 32 bits com és el cas de Windows Embedded CE. Windows Embedded CE és una versió minimalista de les versions desktop de Windows. La seva nova arquitectura de kernel, amb capacitat expandida per a processos, és capaç de funcionar en un mínim espai de memòria. El SO, per tant, podria configurar-se com a un sistema tancat, sense dispositius d’emmagatzematge ni interfície d’usuari; introduït directament en una ROM. Un altre gran atractiu de Windows Embedded és la possibilitat d’implementar-lo tant a dispositius cablejats com inalàmbrics, oferint suport a connexions PAN (Personal Area Network), LAN (Local Area Network) i WAN (Wide Area Network), incloent Bluetooth, IrDA i WiFi 802.11. El comportament de Windows Embedded CE és el d’un autèntic RTOS, amb una latència d’interrupció determinista i capaç de gestionar 256 nivells de prioritat. Incorpora, a més, nombroses eines de desenvolupament com Visual Studio, Embedded Visual C++ i Free Pascal. Ofereix una gran varietat de configuracions, amb la possibilitat d’ajustar el SO a les estrictes necessitats de l’aplicació. Aquesta flexibilitat es fa patent tant en el software com en les formes de distribució del producte. Pot adquirir-se una versió de prova totalment funcional de Windows Embedded CE 6.0, la seva última versió, per un període de 6 mesos a la pàgina web de Microsoft http://www.microsoft.com/windowsembedded . A més, disposa d’una extensa comunitat de desenvolupadors que ofereixen suport a les diferents plataformes hardware existents.
Metodologia de desenvolupament d’aplicacions PC embedded 53 4. MARC DE DESENVOLUPAMENT 4.1 – Desenvolupament d’aplicacions embedded En aquest apartat s’explica de forma general el procés de disseny d’un sistema embedded. És molt important a les primeres etapes del desenvolupament la correcta elecció dels components hardware i software que composaran el disseny final del dispositiu. En els següents subapartats es dona informació útil sobre aquests aspectes i els elements principals que integren qualsevol disseny d’una aplicació embedded. 4.1.1 – Desenvolupament entre plataformes Una de les característiques habituals del desenvolupament de sistemes embedded és la seva metodologia de desenvolupament del software, anomenada cross-plataform development, desenvolupament entre plataformes. Això vol dir que el software d’un sistema embedded es desenvolupa en una plataforma i es transfereix a una altra definitiva en la qual funciona. En aquest context, la plataforma és el hardware (com, per exemple, el tipus de processador), el sistema operatiu i les eines de desenvolupament de software que s’empren en el desenvolupament. El sistema amfitrió, host system, és el sistema en el qual és desenvolupa el software embedded. Normalment es tracta d’un computador desktop, que se l’acostuma a anomenar estació de treball o workstation. El sistema target, target system, és el sistema embedded en desenvolupament. L’eina de software principal del desenvolupament cross-plataform és el cross-compiler. És un compilador que funciona en una arquitectura concreta de processador, com podria ser la família x86, però produeix codi objecte per a diferents tipus d’arquitectures de processadors. Un exemple d’això el trobem en el compilador DIAB de Wind River Systems. El compilador DIAB funciona sobre un sistema operatiu Microsoft Windows en una arquitectura de processador IA-32; i és capaç de produir codi objecte per nombrosos tipus de processadors, com els Motorola s68000, MIPS, i ARM.
54 Marc de desenvolupament Els components bàsics en l’entorn de desenvolupament de sistemes embedded són el sistema amfitrió, el sistema embedded target, i les eines de connectivitat entre les dues plataformes. Figura 4.1. Model típic d’entorn de desenvolupament Cross – plataform. Referències: “Real – Time Concepts for Embedded Systems”, Qing Li i Carolin Yao, ed. CMP Books, 2003. Les principals eines de desenvolupament que ofereix el sistema host són el compilador, el linker o enllaçador, i la depuració del codi font. El sistema target probablement inclourà un dynamic loader, un link loader, un monitor, i un agent depurador. El sistema host transferirà les imatges de programa al sistema target, a través de les diferents connexions entre ambdós (sèrie, Ethernet, USB, etc.). També es pot transferir informació sobre la depuració entre el host debugger i el target debug agent. Es desenvolupa el software de sistema, el RTOS, el kernel i el codi d’operació; es compila, i s’empaqueta tot plegat, dins una imatge executable. El programador escriu aplicacions que executa en el mateix entorn utilitzat en el desenvolupament; sense la necessitat de traspassar, a cada moment, els canvis creats per a la seva comprovació. 4.1.2 – Emmagatzematge i actualització del software El software dels sistemes embedded es pot dividir en dues parts: software de sistema i software d’aplicació. Aquest és habitualment emmagatzemat a dispositius de memòria
Metodologia de desenvolupament d’aplicacions PC embedded 55 ROM i NVRAM. Actualitzar el software pot suposar crear una nova PROM, desplegar uns equips especials o mètodes especials per a reprogramar la EPROM, o reprogramar la memòria flash. L’elecció del dispositiu d’emmagatzematge del software té un impacte en el desenvolupament. El procés de reprogramar una EPROM, que pot consumir molt de temps, és habitual durant el desenvolupament. Cal tenir cura, però, de no malmetre la EPROM al treure-la del seu sòcol. 4.1.3 – Creació d’un entorn de desenvolupament PC embedded Un dels primers passos a seguir, a l’hora de crear la nostra pròpia bancada de desenvolupament de sistemes embedded, és conèixer els requeriments hardware i software de la mateixa. La nostra bancada de desenvolupament ha de tenir les eines necessàries per a que puguem construir imatges de SO, desenvolupar drivers, crear aplicacions; i transferir-ho tot al sistema embedded target, amb èxit. El sistema host és, normalment, un PC de propòsit general amb les interfícies de comunicació necessàries per a comunicar-se amb el sistema target. Aquest PC contindrà també un sistema operatiu de propòsit general, com per exemple Windows XP Professional. Per sobre d’aquest SO de propòsit general anirà instal·lat el constructor de plataformes, amb el paquet d’eines de desenvolupament d’aplicacions, que ens permetrà empaquetar tot el software necessari per a fer funcionar el sistema embedded target. S’elegirà un RTOS concret en funció de les necessitats, la relació qualitat/preu i les seves prestacions. Existeix, actualment, una gran quantitat i varietat de RTOS al mercat. De fet, són bastants els factors a tenir en compte en l’elecció d’un RTOS; tal com ja hem pogut veure a la secció 3.4.4 d’aquest projecte. De forma resumida es pot considerar que els principals factors són: - Restriccions temporals del SO necessàries per al sistema embedded - Suport: disponibilitat d’un suport tècnic i una comunitat de desenvolupament que ofereixi ajuda als dissenyadors.
56 Marc de desenvolupament - Eines de desenvolupament: que permetin construir el software necessari per al funcionament del sistema embedded. - Facilitat d’utilització: que permeti reduir el temps de desenvolupament i fer més còmode la feina dels dissenyadors. - Compatibilitat: amb les diferents arquitectures de processadors i tecnologies embedded. El sistema operatiu elegit condicionarà els requisits hardware i software del sistema host de la nostra bancada de desenvolupament. Per exemple, Windows Embedded CE 6.0 requereix com a mínim un processador de 933 MHz i 512 MB de memòria RAM. Un cop escollit el sistema operatiu, la metodologia que es durà a terme per a la creació del sistema embedded és la següent: [1] Seleccionar la plataforma hardware. [2] Seleccionar els components perifèrics hardware addicionals. [3] Adquirir o dissenyar el software de compatibilitat amb la plataforma hardware i els seus perifèrics. [4] Desenvolupar el disseny del sistema operatiu. [5] Desenvolupar les aplicacions. [6] Construir el prototip. [7] Realitzar la depuració i el test del sistema. [8] Transferir al sistema target la imatge final de SO al target. La plataforma software escollida en aquest projecte és Windows Embedded CE 6.0, que es mostra de forma detallada durant el següent apartat del projecte.
Metodologia de desenvolupament d’aplicacions PC embedded 57 4.2 – Windows Embedded CE 6.0 A l’apartat 4.2 d’aquest projecte es dona a conèixer una de les principals plataformes software de sistemes embedded: Microsoft Windows Embedded CE 6.0. 4.2.1. Introducció Windows Embedded CE no és un sistema operatiu de propòsit general (com Windows XP o Vista). Windows CE està preconfigurat per a configuracions i hardware de dispositius embedded. El seu disseny modular permet personalitzar imatges de SO per a plataformes hardware de limitades prestacions computacionals, incorporant només allò necessari per a l’aplicació concreta del dispositiu. A la majoria dels casos, no és necessari modificar configuracions per defecte del dispositiu embedded (BIOS, Jumpers, DMA, IRQ, adreces de memòria i E/S, etc.), ja que la última versió de Windows CE, la 6.0, incorpora suport software a la majoria del hardware de dispositius embedded del mercat. Aquest sistema operatiu està molt estes al mercat actual, sobretot en el sector de l’electrònica de consum; on dispositius mòbils com PDAs, GPS o consoles tenen una gran presència. Windows Embedded CE pot ser implementat en un caixer automàtic, un reproductor MP4, o inclús en un computador industrial, gestionant la lògica de processos automatitzats. En aquest apartat es mostra una metodologia de creació d’aplicacions embedded amb Windows CE 6.0. Partint desde zero, podràs conèixer factors clau com el procés d’instal·lació de les eines de desenvolupament, la creació d’una imatge executable de SO i la transferència de la imatge creada al dispositiu target.
58 Marc de desenvolupament 4.2.2. Evolució de Windows Embedded CE La primera versió de Windows Embedded CE (CE 1.0) va ser creada per Microsoft l’any 1996. Inicialment va ser creat per a dispositius diferents d’un PC, posicionant-se especialment dins el mercat del Pocket Pc. Al 1997, el sistema (CE 2.0) es tornà componentitzat i dissenyat per a un ampli rang de dispositius i múltiples famílies de processadors. La versió CE 3.0, llançada al 2000, conté suport per a operacions en temps real i tecnologies multimèdia avançades com DirectDraw, DirectShow, i Windows Media Player. La versió CE 4.0 arribà al 2001. Aquesta versió conté suport per a Direct3D, Universal Disk File System (UDFS), Simple Object Access Protocol (SOAP) i base de dades SQL Server CE. Els posteriors llançaments 4.1 i 4.2 van proporcionar als dissenyadors funcionalitats d’accessibilitat expandida, afegint suport per a visionar arxius, perfils Bluetooth i IPv6, i suport per a telefonia VoIP (Voice over Internet Protocol). Al 2005, Microsoft llançà la versió CE 5.0 amb suport per a Universal Serial Bus (USB) 2.0, Simple Object Acces Protocol Input/Output (SDIO), Windows Media 9, i Microsoft Explorer 6; així com un sistema constructiu unificat i una infraestructura de desenvolupament general de BSPs amb capa d’adaptació OEM anomenada OAL (OEM Adaptation Layer) disponible per al dissenyador. Amb Windows Embedded CE 6.0, llançat al 2006, l’arquitectura del sistema ha experimentat canvis substancials. Ara cada procés té 2 GB de memòria virtual (anteriorment 32 MB), i el nombre de possibles processos en marxa de forma simultània incrementa a 32000 (anteriorment 32). En versions anteriors, parts del sistema kernel eren implementades com un conjunt de processos separats, mentre que a Windows Embedded CE 6.0, estan combinades en un sol kernel. Els processos del sistema són DLLs (Dynamic Link Libraries) carregades dins l’espai del kernel. Això incrementa el rendiment del sistema operatiu, redueix les crides a APIs (Aplication Programming Interface) i unifica la interfície del kernel. Ara el dissenyador pot carregar drivers a l’espai del kernel i també crear drivers que es carreguin en un procés especial d’usuari.
Metodologia de desenvolupament d’aplicacions PC embedded 59 4.2.3. Instal·lació de Windows Embedded CE 6.0 Un dels factors més importants per a establir un entorn apropiat per al desenvolupament és tenir les eines instal·lades apropiadament, amb tots els components necessaris. La incorrecta instal·lació o manca d’eines necessàries per al desenvolupament, pot causar problemes i ocasionar que no es pugui completar la creació de la imatge de SO d’un projecte. Per això, és necessari seguir de forma precisa la seqüència d’instal·lació del software i mantenir –lo amb les actualitzacions necessàries. Suport a processadors Windows CE està dissenyat per a suportar quatre famílies de processadors (CPUs): ARM, MIPS, SuperH, i x86. Hi ha nombrosos models de processadors d’aquestes famílies disponibles per a diferents fabricants amb diferents nivells de prestacions i preu. Microsoft proporciona llibreries de suport a les quatre famílies de processadors. Les llibreries de suport a processadors facilitades per Microsoft es troben al directori: WINCEROOT\PLATFORM\COMMON. Nota: En aquest projecte, es prendrà com a convenció anomenar WINCEROOT al directori arrel de Windows Embedded CE (amb WINCE600 de nom per defecte). Obtenció del software Existeixen diverses alternatives en l’obtenció d’una versió de Windows Embedded CE 6.0. Es pot adquirir el producte amb llicència a través d’un proveïdor oficial; però si no disposes d’una versió llicenciada de Windows Embedded CE, pots obtenir una versió de prova de 6 mesos, emplenant prèviament un formulari de registre, a la pàgina web http://www.microsoft.com/windowsembedded . La versió trial disponible a la pàgina web no incorpora les eines de Visual Studio 2005 Professional, necessàries per al desenvolupament; per tant, hauràs d’instal·lar prèviament el Visual Studio 2005 per a poder desenvolupar els dissenys.
66 Marc de desenvolupament Per a reduir el temps de desenvolupament, és habitual clonar un BSP ja existent; canviant només el codi font referent al nou hardware. Això és possible si, per exemple, ambdós comparteixen la mateixa arquitectura de CPU. Es pot trobar molta informació sobre desenvolupament de BSPs per a Windows Embedded CE a la direcció web: http://channel9.msdn.com/wiki/cedeveloper/windowscebsp/ . Clonació d’un BSP El procés de clonació d’un BSP ja existent té la funció de poder modificar la copia feta sense que els canvis afectin al BSP original. Fem un exercici d’exemple. Obre el Visual Studio 2005 i dins el menú desplegable Herramientas selecciona del submenú Platform Builder for CE 6.0 la opció Clone BSP, per a obrir l’assistent Clone Board Package Wizard (figura 4.3). Figura 4.3. Finestra de Clone BSP. A la casella Source Board Support Package selecciona el BSP que desitgis clonar. Per aquest exercici d’exemple, selecciona CEPC: x86. A la casella Name introdueix el nom del nou BSP, per exemple, MyCEPCBSP i crea un directori (casella Platform directory) amb el mateix nom.
Metodologia de desenvolupament d’aplicacions PC embedded 67 Les caselles de Vendor i Version són informatives i no tenen cap impacte sobre el disseny. Pots emplenar-les o simplement deixar-les en blanc. Cliqueja finalment el botó Clone. Els nous BSPs clonats els pots veure a la vista del catàleg d’ítems, a la carpeta Third Party (figura 4.4). En aquesta carpeta es dipositen tots els BSPs creats i els subministrats pels fabricants de hardware. Figura 4.4. Finestra Catalog Items View. Ara anem a editar el nou BSP clonat. Seleccionant la opció Open new BSP catalog file in Catalog Editor de l’assistent de clonació de BSPs es pot accedir a l’edició dels BSPs. Un altre mètode per a editar el BSP que ja has clonat és accedint, a través del navegador, a la carpeta PLATFORMROOT\Nom_del_BSP\CATALOG. Entra a la carpeta del BSP desitjat, i obre’l amb VS2005. En el cas d’aquest exercici d’exemple, la ruta del BSP clonat serà PLATFORMROOT\MyCEPCBSP\CATALOG. Dins d’aquesta carpeta selecciona l’arxiu MyCEPC.pbcxml i cliqueja Abrir con... Microsoft Visual Studio 2005. El BSP CEPC és un dels BSPs inclosos a Windows Embedded CE com a part de la instal·lació del Platform Builder. Dona suport a plataformes hardware basades en processadors x86.
68 Marc de desenvolupament Si tens un ordinador vell amb processador x86 de 32 MB o més de memòria de sistema, del tipus 486 o superior, és possible que aquest BSP et serveixi, com a suport software, per al teu vell PC. És a dir, pots crear una imatge de SO de Windows Embedded CE 6.0 i fer-la funcionar al teu ordinador obsolet. Eliminar components del BSP Ara anem a esborrar components del BSP clonat. A la interfície del VS2005, expandeix la carpeta Storage Drivers de l’arxiu MyCEPCBSP.pbcxml obert. Per al hardware típic basat en x86, és poc probable que necessitem els drivers de PCI NAND Flash i Spansion Flash Memory. Cliqueja amb el botó dret del ratolí cadascun dels dos drivers i selecciona Remove, per a eliminar-los. Agregar components al BSP Ara anem a veure com s’afegeixen components a un BSP clonat. A l’editor de MyCEPCBSP.pbcxml del VS2005 posiciona el ratolí sobre MyCEPCBSP: x86 i fes clic al botó dret del ratolí. Selecciona la opció Add Catalog Item. A la finestra de Propietats del costat esquerre, introdueix de títol ATAPI Storage Driver i a la casella Sysgen Variable escriu SYSGEN_ATAPI. El driver VGA Linear (Flat) Framebuffer suporta la majoria de displays emprats a equips PC. Per afegir-lo a la nova BSP segueix els mateixos passos que en l’exemple anterior. Introdueix VGA Linear (Flat) a la casella Title i BSP_DISPLAY_FLAT a la casella de Sysgen Variable. A la figura 4.5 es mostra l’aspecte del catàleg del MyCEPCBSP.pbcxml un cop eliminats i afegits els corresponents components. Figura 4.5. Carpeta BSP de Catalog Items View.
Metodologia de desenvolupament d’aplicacions PC embedded 69 Clonació de codi públic de BSPs Un cop clonats els BSPs, és el moment de modificar-los. Encara que els components SYSGEN_ATAPI i BSP_DISPLAY_FLAT ja s’han afegit al MyCEPCBSP, hem de introduir les variables d’entorn dels drivers del dispositiu. El codi font i els arxius binaris per a aquests components es troben dins el directori PUBLICROOT. Per a modificar el codi font dels nous components del MyCEPCBSP és recomanable clonar el codi font del BSP original. Ara anem a fer un exercici d’exemple de clonació del codi font dels drivers VGA Linear (Flat) Framebuffer al BSP MyCEPCBSP, i nombrar la versió clonada MyVGA display driver. Els passos a seguir es descriuen a continuació: [1] Crear una carpeta per a MyVGA display driver al directori: _PLATFORMROOT\MyCEPCBSP\SRC\Drivers\. [2] Copiar tots els arxius de _PUBLICROOT\Common\Oak\Drivers\ Display\VGAFlat a la nova carpeta creada. [3] Renombrar l’arxiu ddi_ flat.def amb el nom MyVGA.def . I per últim, s’ha de modificar el contingut del codi font del nou BSP clonat. Per a fer-ho s’ha d’obrir amb un editor de text (com per exemple, el bloc de notes) l’arxiu Source de la carpeta _PLATFORMROOT\MyCEPCBSP\SRC\Drivers\ i fer els canvis desitjats. Com ja s’ha comentat al principi de l’apartat, explicar de forma detallada el disseny i edició de BSPs podria ocupar un llibre sencer. Si desitges obtenir més informació sobre aquest tema, pots consultar la documentació de MSDN Visual Studio 2005 i la direcció web: http://channel9.msdn.com/wiki/cedeveloper/windowscebsp/ . També es recomanable consultar el llibre “Microsoft Embedded CE 6.0” de edicions Wrox, escrit per Samuel Phung; d’on s’ha estret gran part de la informació continguda en aquest apartat.
70 Marc de desenvolupament 4.2.7. Creació d’una imatge executable personalitzada En aquest apartat es mostren els passos a donar per a crear un disseny de sistema operatiu, incloent components addicionals del catàleg de components, configurar variables d’ambient, personalitzar el disseny de SO, i generar una imatge executable. Per a crear una imatge executable CE 6.0, hem de seguir els següents passos: [1] Crear el projecte de disseny del sistema operatiu. [2] Seleccionar els BSPs (Board Support Packages). [3] Seleccionar els components addicionals necessaris del catàleg de components de CE 6.0. [4] Generar la imatge executable del SO del projecte de disseny del SO. Creació d’un disseny de SO inicial Començarem creant un nou projecte. Fes clic al menú Archivo, després a Nuevo, i per últim a Proyecto. Apareixerà la següent finestra (figura 4.6): Figura 4.6. Finestra inicial de l’assistent d’un nou projecte.
Metodologia de desenvolupament d’aplicacions PC embedded 71 Selecciona la opció Platform Builder for CE 6.0. Introdueix a Nombre el nom del projecte. Per defecte, apareix el nom OSDesign1. Deixa d’entrada aquest nom i cliqueja Aceptar. Figura 4.7. Pantalla inicial de l’assistent OS Design Wizard. En aquest punt, l’assistent OS Design Wizard es mostra a la pantalla (figura 4.6). Aquest segueix una sèrie de passos, presentant opcions diferents per a seleccionar els BSPs, la plantilla de disseny del SO, components multimèdia, i components d’aplicació; permetent també crear l’entorn inicial de desenvolupament per al projecte. Per a avançar al pròxim pas, fes clic a Siguiente. La següent pantalla és l’assistent de selecció del BSPs (Board Support Packages), tal com es pot observar a la figura 4.8. Aquesta pantalla mostra un llistat de tots els BSPs actualment instal·lats a la teva estació de desenvolupament. Per a un mateix projecte, poden ser seleccionats múltiples BSPs; tot i que cada un està dissenyat per a donar suport a un únic hardware. Seleccionant múltiples BSPs, el disseny de SO pot configurar-se per a generar múltiples imatges runtime de SO, una per a cada BSP (donant suport així al hardware associat a cada BSP).
72 Marc de desenvolupament Figura 4.8. Selecció de BSPs. Selecciona CEPC: x86 i Device Emulator: ARMV41 per a poder implementar el SO que crearem. Cliqueja ara Siguiente per accedir a la pantalla Design Templates (figura 4.9). Figura 4.9. Selecció de la plantilla de disseny.
Metodologia de desenvolupament d’aplicacions PC embedded 73 La pantalla Design Templates presenta diferents categories de plantilles de disseny. Fes clic a sobre de cada plantilla i a la part esquerra apareixerà una breu descripció de la mateixa. Per a la realització d’aquest exercici d’exemple selecciona la opció Industrial Device, i després fes clic a Siguiente. Per a cada plantilla de disseny de SO, l’assistent OS Design Wizard proporciona una o varies variables de plantilla per a escollir (pantalla Design Template Variants, figura 4.10). Per a aquest exercici d’exemple, escull Internet Appliance i fes clic a Siguiente. Figura 4.10. Selecció de les variants de plantilles. La següent pantalla (figura 4.11) de l’assistent OS Design Wizard correspon a Applications & Media. Proporciona la opció d’incloure aplicacions, components multimèdia, i llibreries programables; que poden proporcionar al disseny una funcionalitat addicional. El component de llibreries NET. Compact Framework 2.0 dona suport al codi font d’aplicacions. Internet Explorer 6.0 dona suport a la funció de navegador d’Internet. I els components Media de Windows proporcionen funcionalitats multimèdia bàsiques.
74 Marc de desenvolupament Figura 4.11. Selecció d’aplicacions multimèdia.. Seguim avançant al proper pas per a seleccionar les opcions addicionals proporcionades per l’assistent. Fes clic a Siguiente per a passar a la selecció de components de comunicacions Networking. Expandeix els menús Local Area Network (LAN), Personal Area Network (PAN), i Wide Area Network (WAN), tal com es mostra a la figura 4.12. Figura 4.12. Selecció d’ítems per a les comunicacions.
Metodologia de desenvolupament d’aplicacions PC embedded 75 Les funcionalitats Networking són de gran utilitat per a dispositius embedded, donat que proporcionen les següents funcions: - Components LAN (Local Area Network). Proporcionen les llibreries i utilitats necessàries per al suport a LAN, com Ethernet i RAS (Remote Access Service). - Components PAN (Personal Area Network). Proporcionen les utilitats i llibreries de suport necessàries per a PAN, com IrDA i Bluetooth. - Components Remote Desktop Connection. Proporcionen les utilitats i llibreries de suport necessàries per a establir sessions remotes desktop. - Components de Seguretat. Proporcionen les utilitats i llibreries de suport necessàries per a l’ús de funcions de seguretat i encriptació. - Components TCP/IPv6. Proporcionen les utilitats i llibreries de suport necessàries per al nou stack TCP/IPv6. - Components WAN (Wide Area Network). Proporcionen les utilitats i llibreries de suport per a comunicacions Dial-up, Point-to-Point i Virtual Private. Els components addicionals de comunicació disponibles al catàleg de components poden ser afegits posteriorment, un cop creat el disseny de SO. Cliquejant la opció Siguiente, s’arriba a la última pantalla de OS Design Wizard, que dóna per finalitzat l’assistent. L’assistent OS Design Wizard, un cop completats tots els passos, genera una carpeta de projecte amb subcarpetes i arxius del disseny de SO. Al primer pas de l’assistent, hem deixat el nom que dóna el programa per defecte OSDesign1. VS2005 crea una carpeta amb el mateix nom a WINCEROOT\OSDesigns\OSDesign1 i crea diverses subcarpetes i arxius. A continuació es descriuen les subcarpetes i arxius utilitzats.
82 Marc de desenvolupament Figura 4.20. Propietats de configuració del disseny de SO. La configuració dels paràmetres de l’apartat Local, et permet especificar aspectes com els idiomes suportats, les pàgines de codi, etc. Observa la figura 4.21. Figura 4.21. Opcions locals del disseny de SO.
Metodologia de desenvolupament d’aplicacions PC embedded 83 Cliquejant sobre Build Options, apareix una finestra que et permet configurar les variables utilitzades més freqüentment per a controlar el procés de creació, tal com ens mostra la figura 4.22. Figura 4.22. Opcions constructives del disseny de SO. A continuació es descriuen les diferents opcions constructives seleccionables al menú Propiedades de configuración. - Build tracked events in RAM. Variable: IMGOSCAPTURE. Afegeix el mòdul OSCapture.exe a la imatge. Durant la càrrega, el mòdul de SO comença a escriure esdeveniments de sistema dins la RAM. - Enable eboot space in memory. Variable: IMGEBOOT. Reserva espai bootable a la memòria. Habilita al mòdul per a preservar les dades que poden ser llegides pel sistema durant la càrrega. - Enable event tracking during boot. Variable: IMGCELOGENABLE. Afegeix l’arxiu CELog.dll a la imatge i inicialitza la col·lecció d’esdeveniments del sistema quan és carregat.
84 Marc de desenvolupament - Enable hardware - assisted debugging support. Variable: IMGHDSTUB. Habilita el suport a la depuració del hardware. - Enable kernel debugger. Variable: IMGNODEBUGGER. Inclou suport a la depuració del kernel. - Enable KITL. IMGNOKITL. Inclou suport a KITL (Kernel Independent Transport Layer). - Enable profiling. Variable: IMGPROFILER. Inclou suport al perfil del kernel. - Enable ship build. Variable: WINCESHIP. Quan aquesta opció és seleccionada, la imatge resultant de sistema operatiu no dona sortida a missatges de depuració. Quan aquesta opció no és seleccionada, el sistema operatiu proporciona detallats missatges per ajudar a la depuració. Aquesta opció està només disponible per a la construcció del llançament i està oculta a la configuració de la depuració. - Flush tracked events to release directory. Variable: IMGAUTOFLUSH. Permet netejar l’apuntador d’esdeveniments del directori de llançament. - Runtime image can be larger than 32 MB. Variable: IMGRAM64. Permet el suport per a imatges executables més llargues de 32 MB. - Use xcopy instead of links to populate release directory. Variable: BUILDREL_USE_COPY. Copia arxius al directori de llançament en comptes de crear enllaços durs. - Write runtime image to flash memory. Variable: IMGFLASH. Permet escriure de la imatge executable a la memòria flash desprès de la descàrrega. Les opcions d’entorn del submenú Environment, figura 4.23, et permeten modificar els paràmetres constructius especificant variables d’entorn addicionals.
Metodologia de desenvolupament d’aplicacions PC embedded 85 Figura 4.23. Especificació de variables d’entorn addicionals. El paràmetre Custom Build Actions et permet realitzar accions constructives personalitzades durant certs instants de la creació, tal com es pot observar a la figura 4.24. Figura 4.24. Accions constructives personalitzades.
86 Marc de desenvolupament Per a l’exercici d’exemple actual, selecciona les opcions: - Enable eboot space in memory. Selecciona aquesta opció per a reservar espai de memòria per a l’arrencada del sistema, on es guardaran dades de paràmetres, com la resolució de pantalla o l’idioma del teclat; i permetre al SO llegir-les durant l’arrencada. - Enable KITL. Selecciona aquesta opció per habilitar el KITL (Kernel Independent Transport Layer), l’enllaç de comunicació entre l’estació de desenvolupament i el dispositiu target, per a la depuració. - Run-time image can be larger than 32 MB. Quan aquesta opció està activada, s’habilita la variable d’entorn IMGRAM64, que configura la imatge runtime per a utilitzar un sistema de memòria de 64 MB. Variables d’entorn A més de les opcions constructives, es poden afegir variables addicionals d’entorn al disseny, des del menú de propietats de disseny del SO. Per exemple, si volguéssim excloure tots els components d’àudio de la imatge, per mitjà de la variable d’entorn BSPNOAUDIO, necessitem fer el següent: [1] Selecciona al menú desplegable Proyecto la opció Propiedades de OSDesign1. [2] A la part esquerra, expandeix les Propiedades de Configuración i cliqueja sobre Environment, per a desplegar les propietats d’entorn. Fes clic a New i escriu el nom de la variable i el seu valor associat, tal com indica la figura 4.25. Nota: Per a habilitar el funcionament d’una variable se li ha d’adjudicar el valor 1. Exemple: BSP_NOAUDIO = 1.
Metodologia de desenvolupament d’aplicacions PC embedded 87 Figura 4.25. Variable d’entorn. Les variables d’entorn juguen una paper important en com el disseny construeix, habilita i deshabilita certes característiques fonamentals i configura la forma en que la imatge executable del SO és creada. Per a més informació sobre les diferents variables d’entorn i les seves funcions associades, consulta l’apartat BSP environment variables de la documentació de Windows Embedded CE 6.0. Generació de la imatge executable de SO El Platform Builder construeix, compila, i crea una imatge executable del SO. El procés de construcció d’una imatge és llarg. Depenent de l’estació de desenvolupament, aquest procés pot durar de 15 a 30 minuts, o inclús més. Selecciona del menú desplegable Generar la opció Generar solución. Durant el procés de construcció de la imatge, la finestra de sortida de VS2005 mostra els mòduls i llibreries que s’estan construint en aquest moment (figura 4.26). Figura 4.26. Finestra de sortida de Visual Studio 2005.
88 Marc de desenvolupament Finalitzada la creació, la finestra de sortida de VS2005 mostra els resultats de la mateixa, tal com mostra la figura 4.27. Figura 4.27. Resultats de sortida. Quan el procés de creació s’ha completat amb un o varis errors, la creació entra en fallida i no es genera la imatge del sistema operatiu. Per a poder crear una imatge executable de sistema operatiu, el procés de creació no ha de tenir cap error. Tal com es pot observar a la figura 4.28, el procés de creació de la imatge té 16 missatges d’advertència i cap missatge d’error, completant-se així amb èxit. Els arxius generats per la creació de la imatge (d’aquest exercici d’exemple) són emmagatzemats a la carpeta: C:\WINCE600\OSDesigns\OSDesign1\OSDesign1. La imatge executable del SO (d’aquest exercici d’exemple) queda guardada a la carpeta: OSDesign1\RelDir\DeviceEmulator_ARMV4I_Release. Dins d’aquesta carpeta es genera la imatge executable de SO, nk.bin, juntament amb més de 1.000 objectes. A més de mostrar informació i advertiments durant el procés de creació, la informació de la finestra de sortida queda enregistrada als arxius següents: - WINCEROOT\Build.log . És un arxiu molt llarg, que registra totes les activitats realitzades durant la creació.
Metodologia de desenvolupament d’aplicacions PC embedded 89 - WINCEROOT\Build.wrn. Aquest arxiu anota tots els missatges d’advertència (warning messages), que també són inclosos a l’arxiu Build.log. - WINCEROOT\Build.err Aquest arxiu registra tots els missatges d’error (error messages). Quan la creació té èxit, aquest arxiu no arriba a crear-se. Ara s’ha de realitzar els mateixos passos per a generar la imatge de CEPC x86 Release. Selecciona la opció Propiedades de OSDesign1 del menú Proyecto. Seguidament escull la opció CEPC x86 Release i cliqueja Close. Ara veure’m un exemple de com agregar drivers a la imatge executable de SO generada per aquest BSP. Afegirem els drivers de les targetes Ethernet següents: - NE2000 - compatible ISA card - NE2000 - compatible PCI card - NE2000 - compatible PCMCIA card - Realtek RTL8139 Cliqueja sobre Environment per accedir a la configuració de les variables d’entorn i realitzar les següents accions: [1] Cliqueja sobre New per agregar una nova entrada a la pantalla Environment Variables. [2] A la casella de nom de la variable, introdueix BSP_NIC_RTL8139. [3] A la casella de valor de la variable, introdueix 1. [4] Cliqueja OK per a completar el procés. [5] Repeteix els anteriors passos per a les variables d’entorn BSP_NIC_NE2000_PCI i BSP_NIC_NE2000_ISA. [6] Cliqueja Aplicar seguit de Aceptar per a continuar.
90 Marc de desenvolupament La finestra de variables d’entorn de la pàgina de propietats del disseny mostrarà finalment l’aspecte que ens mostra la figura 4.28. Figura 4.28. Finestra de variables d’entorn. Figura 4.29. Menú Generar de VS2005.
Metodologia de desenvolupament d’aplicacions PC embedded 91 Per a crear finalment la imatge executable de SO del BSP CEPC x86, selecciona del menú Generar la opció Generar solución (figura 4.28) i la imatge resultant quedarà guardada a la carpeta: OSDesign1\RelDir\CEPC_x86_Release. 4.2.8. Connexió amb el dispositiu Target A l’apartat 4.2.7 hem vist el procés de creació de les imatges de SO de Windows Embedded CE. En concret, per als BSPs DeviceEmulator_ARMV4I i CEPC_x86. Per a carregar aquestes imatges als dispositius target, necessitem establir connexions entre la workstation i aquests. En aquest apartat veure’m el procés de connexió i descàrrega de les imatges als dispositius target. Per a la connexió de l’estació de desenvolupament amb els dispositius target existeixen tres alternatives: - Ethernet - USB - Sèrie També hi ha disponible un emulador de dispositius, inclòs al VS2005. Aquest ofereix la possibilitat de simular el comportament dels SO dissenyats, sense la necessitat de transferir-los al target. És una eina molt útil per al test i depuració dels dissenys, durant el procés de desenvolupament. L’emulador és instal·lat, com a una part més de Windows Embedded CE 6.0, juntament amb el Platform Builder quan es selecciona el suport a processadors ARM a les opcions d’instal·lació del programa. Per a utilitzar l’emulador com a dispositiu target per a la depuració d’un programa, la imatge ha de ser creada per a donar suport al BSP DeviceEmulator, emprant l’eina d’emulador de dispositius (DMA). Tot seguit veure’m un exemple del procés de connexió amb l’emulador mitjançant les eines de connectivitat que ofereix Microsoft Visual Studio 2005.
98 Marc de desenvolupament - Vesatest.exe. Utilitat de test útil per les pantalles PC que no suporten el mode VESA - Config.sys. Arxiu de configuració de DOS, responsable de llançar el driver del dispositiu altres llibreries del sistema durant l’inici del DOS. - Autoexec.bat. Arxiu DOS que s’executa durant l’arrencada. Comprova els arxius que conté el disquet. Una opció és entrar a la línia de comandaments de Windows i fer un dir per a fer aquesta comprovació (tal com mostra la figura 4.37). Figura 4.37. Línia de comandaments de Windows XP. Ara ja s’ha creat el disquet d’arrencada per a preparar el dispositiu per a la càrrega de la imatge de Windows Embedded CE. Tal com ja s’ha explicat, existeixen diferents alternatives per a la descàrrega de la imatge al dispositiu. Seguidament realitzarem un exercici d’exemple per la transferència de la imatge a un dispositiu x86 via Ethernet, mitjançant el protocol de xarxa DHCP.
Metodologia de desenvolupament d’aplicacions PC embedded 99 El DHCP (Dynamic Host Configuration Protocol) és un protocol de xarxa que permet als nodes d’una xarxa IP obtenir els seus paràmetres de configuració automàticament. Es tracta d’un protocol de tipus client/servidor en el qual generalment un servidor posseeix una llista d’adreces IP dinàmiques i les va assignant als clients conforme aquestes van estant lliures, sabent en tot moment qui ha estat en possessió d’aquesta IP, quant temps l’ha tingut i a qui ha estat assignada després. Per a realitzar la transferència és necessari un router de xarxa i dos cables TIA/EIA 568- B.2. El router i el tipus de cable especificat és l’habitualment subministrat per a les connexions domèstiques d’ADSL. Figura 4.38. Esquema de connexió física amb el dispositiu target via Ethernet. També es pot realitzar una comunicació amb un sol cable crossover Ethernet establint manualment una IP estàtica. Per a més informació sobre aquest sistema consulta el llibre “Microsoft Embedded CE 6.0” de edicions Wrox, escrit per Samuel Phung; d’on s’ha estret gran part de la informació continguda en aquest apartat
100 Marc de desenvolupament Treballant amb el mateix projecte creat als exercicis anteriors, has de seleccionar la configuració activa BSP_CEPC_Release a l’administrador de configuracions. Per a crear un perfil de dispositiu target per a la connexió amb el dispositiu seguiex els següents passos: 1. Al menú Target, cliqueja el submenú Connectivity Options. 2. Dins de la finestra Connectivity Options fes clic sobre Add Device. 3. Introdueix un nom per al perfil del dispositiu, per exemple el model del dispositiu target. En el cas d’aquest projecte, la connexió es realitza amb un PC industrial Advantech PCM-9575. Cliqueja Add per a continuar. 4. Dins de la finestra Connectivity Options selecciona la opció Ethernet a les pestanyes Download i Transport, tal com mostra la figura 4.39. Figura 4.39. Finestra d’opcions de connectivitat de VS2005.
Metodologia de desenvolupament d’aplicacions PC embedded 101 5. Cliqueja el botó Settings situat a la dreta de la pestanya Download. En aquest moment s’obre la finestra Ethernet Download Settings (figura 4.41). En aquest punt, el dispositiu target no està associat encara a cap perfil. En els següents passos es connectarà el dispositiu target amb l’estació de desenvolupament per a identificar-lo i assignar-li un perfil de dispositiu. 6. Encén el dispositiu target x86 amb el disquet d’arrencada anteriorment creat introduït a la disquetera. Nota: És possible que hagis d’accedir al BIOS del dispositiu per a establir la disquetera com a primer dispositiu d’arrencada del sistema. Un cop arrencat l’equip, accedeix als arxius d’arrencada del disquet i els executa. En aquest punt apareix una pantalla amb diferents opcions. 7. Selecciona la opció 2: Load OS image from development station with DHCP service. En aquest punt, el processador executa la línia de codi de l’arxiu autoexec.bat: Loadcepc /L:1024x768x32 /C:0 /e:0:0:0 eboot.bin El dispositiu target comença a enviar dades pel cable sèrie i apareix un nom assignat al dispositiu a la finestra Active target devices de la pantalla Ethernet Download Settings (figura 4.40). Figura 4.40. Ethernet Download Settings.
102 Marc de desenvolupament En el cas del PC Advantech PCM-9575 utilitzat en aquest projecte apareix el nom de dispositiu: CEPC5411. 8. Selecciona el dispositiu detectat de la finestra Active target devices i cliqueja OK. Finalment fes clic a Apply, seguit de Close per finalitzar l’assistent. 9. Ara anem a connectar el dispositiu. Selecciona al menú Target la opció Attach Device . En aquest moment s’estableix la comunicació i s’efectúa la transferència de la imatge executable de SO al dispositiu target. Pots utilitzar les eines remotes de depuració, que es mostren a continuació, per a comprobar el correcte funcionament del dispositiu target, mentre es mantinguin conectats l’estació de desenvolupament i el dispositiu target. 4.2.9. Eines i entorns de depuració A la majoria dels casos, en el desenvolupament de sistemes embedded hi ha diferents opcions i mètodes per assolir els objectius fixats per al disseny. Durant el procés de desenvolupament, es prenen decisions basades en criteris diversos: rendiment del hardware, consum de recursos, compatibilitat amb altres plataformes, etc. Aquest procés pot ser llarg i complex i un bon entorn de depuració d’errors i testejat del software pot ajudar molt. Windows Embedded CE Platform Builder i Visual Studio 2005 proporcionen un entorn de desenvolupament eficient, amb eines per a la depuració, que ajuda a minimitzar el temps emprat en la resolució d’errors i el testejat dels dissenys. A més dels recursos per a la depuració que facilita Microsoft, existeixen eines de depuració facilitades per alguns fabricants de hardware embedded. Aquestes, no obstant, requereixen de la instal·lació d’un software addicional, que no està integrat dins de l’entorn de desenvolupament de Windows Embedded CE.
Metodologia de desenvolupament d’aplicacions PC embedded 103 Depuració d’un disseny de SO Un disseny de SO de Windows Embedded CE pot ser configurat per a generar una imatge executable en mode depuració (debugging-mode) o mode llançament (release-mode). A la majoria dels casos, una configuració en release-mode pot ser suficient per a disposar de la majoria de funcions per a la depuració. Això és important, ja que una imatge de SO generada en mode depuració pot ocupar el doble d’espai que la imatge del mateix projecte generada en mode llançament. A més, requereix de més recursos computacionals, i triga més a generar-se. Això és degut a que una imatge generada en mode depuració crea molts més missatges de depuració que si és generada en mode llançament. Com has pogut observar als apartats anteriors del tema 2.2; les imatges dels dissenys de SO realitzats als exercicis d’exemple, s’han generat en mode realease amb KITL (Kernel Independent Transport Layer). Els missatges de depuració addicionals proporcionen més detalls sobre els components i mòduls de la imatge; però probablement només siguin necessaris quan es dissenya amb un llenguatge de baix nivell, molt proper al hardware del dispositiu. Per a la resta de casos, la imatge generada en mode release, amb KITL, aporta el missatges de depuració necessaris per al dissenyador. Errors del disseny Un dels problemes més habituals en el desenvolupament amb Windows Embedded CE és que no es completi el procés de generació de la imatge. Aquest problema pot ser causat per: una entrada incorrecta a l’arxiu de configuració (de la imatge, subprojecte o plataforma), un arxiu no trobat, o una referència de directori incorrecta d’un arxiu necessari. Si la creació de la imatge no s’ha pogut completar degut a errors durant el procés, hauràs de trobar la causa dels mateixos als arxius: - Build.err. Conté la informació dels errors i només es genera si el procés no es completa amb éxit.
104 Marc de desenvolupament - Build.log. Anota totes les activitats realitzades durant el procés de creació de la imatge. - Build.wrn. Conté informació sobre els advertiments. Si un procés no genera cap warning, aquest arxiu no es crea. Aquests arxius es troben al directori WINCEROOT\ i contenen informació sobre la última imatge creada. Un nou procés de creació eliminarà els arxius build.err, build.log i build.wrn del procés anterior. És important tenir en compte aquest detall, donat que en un projecte gran és recomanable fer una còpia de seguretat dels tres arxius, en cada procés de creació de la imatge. Això permet comparar els arxius build.err, build.log i build.wrn de diferents sessions de creació i detectar problemes. També es poden extreure conclusions a partir dels missatges generats a la finestra de sortida de VS2005. Aquesta ens va mostrant, durant el procés de creació de la imatge, les accions que s’estan portant a terme i els missatges d’error i advertència (en cas de que hi hagi). Però quan es tracta de problemes complexes, és necessari conèixer el procés de creació de la imatge, per saber on i quan es generen els errors. Procés de creació de la imatge El procés de creació de la imatge està format per cinc fases: [1] Pre-SYSGEN. El sistema de creació de la imatge compila el codi proporcionat per Microsoft i el diposita al directori Public.
Metodologia de desenvolupament d’aplicacions PC embedded 105 [2] SYSGEN (System Generation). La fase de generació del sistema filtra els components seleccionats per al disseny d’una llista de components disponibles i enllaça les llibreries de components amb mòduls DLL o EXE. [3] Post-SYSGEN. Es compila el codi de BSPs ,drivers de dispositius, i codi d’arrencada del sistema. [4] Build Release. Durant aquesta fase, els arxius creats a les dues fases anteriors es copien en un únic directori, el directori de llançament. [5] Creació de la imatge executable. Es genera la imatge executable Windows Embedded CE. Durant el procés de creació de la imatge, el Platform Builder genera els següents arxius: - DIRS. L’arxiu DIRS identifica els subdirectoris del projecte que contenen codi font. - Sources. Conté les macros requerides per a construir el codi font. - Makefile. Conté les variables requerides per a per a compilar i enllaçar el codi font. - BIB. L’arxiu BIB (Binary Image Builder) conté informació sobre la configuració del sistema de memòria i entrades de control en que eles fitxers. Eines de depuració remotes El Platform Builder de Windows Embedded CE proporciona una sèrie d’eines remotes per ajudar al dissenyador a la depuració dels projectes. Aquestes eines poden accedir a la imatge de SO que s’està executant al dispositiu target, de forma remota desde l’estació de desenvolupament. Aquestes eines es descriuen a continuació:
106 Marc de desenvolupament - File Viewer. Permet veure, de forma remota, els arxius del dispositiu target; d’igual manera que ho permet l’explorador de Windows de forma local. - Heap Walker. S’utilitza per a examinar la disposició i continguts a la memòria de cada procés funcionant al dispositiu target. - Zoom. Captura la imatge de la pantalla del dispositiu target, en format bitmap (.bmp). La imatge capturada es pot emmagatzemar a la workstation; facilitant així la documentació dels projectes. - Process Viewer. Mostra tots els processos en execució del dispositiu target, i els seus mòduls associats. - Registry Editor. Mostra el registre del dispositiu target i possibilita l’addició, eliminació i modificació de les entrades del registre. És similar a l’editor del registre d’un Windows desktop. - System Information. Mostra informació del sistema, configuracions i propietats del dispositiu target. - Performance Monitor. Eina gràfica per a la mesura del rendiment del sistema. Rastreja l’activitat del sistema i crea un arxiu d’informació de la mateixa. - Spy. Permet veure els missatges entregats a processos en execució del dispositiu target. - Kernel Tracker. Proporciona una representació gràfica dels esdeveniments de les aplicacions i la imatge executable que estan succeint al dispositiu target. - Call Profiler. És una eina de configuració del perfil d’aplicacions del dispositiu target. Les eines remotes de depuració de VS2005 es poden executar seleccionant dins el menú Target, el submenú Remote Tools.
Metodologia de desenvolupament d’aplicacions PC embedded 107 Figura 4.41. Pantalla principal de Kernel Tracker. Windows Embedded CE 6.0 Test Kit També és pot depurar un projecte mitjançant el CETK (CE Test Kit), que proporciona Windows Embedded CE 6.0. Aquesta utilitat proporciona un entorn de depuració independent, que ens permet testejar els BSPs i drivers de dispositius. Per a obrir el CETK desde Windows selecciona al menú Inicio Todos los Programas Windows Embedded CE 6.0 Windows Embedded CE 6.0 Test Kit. Depuració sèrie El port sèrie és un altre mitjà disponible per al suport a la depuració. Això es fa possible connectant un cable sèrie null modem RS-232 entre el port sèrie del dispositiu target i el port sèrie de la workstation. Mitjançant l’eina Hyperterminal del teu Windows desktop, pots rebre a la teva workstation missatges de depuració provinents del dispositiu target.
114 Marc de desenvolupament 4. Reinicia el CEPC i descarrega la imatge executable de l’estació de desenvolupament al CEPC. 5. Un cop completada la descàrrega, copia l’arxiu Nk.bin al directori de llançament del disc dur. Per a simplificar la recerca de l’arxiu de la imatge executable al CEPC, si la imatge inclou interfície d’usuari, a l’explorador d’arxius (File Explorer) de Windows Embedded CE, dins el menú View, escull Folder Options, i elimina la opció Hide File Extensions. 6. Reinicia de nou el CEPC amb el disquet creat dins la disquetera. 7. Canvia els directoris al disc dur del CEPC, especificant <lletra_de_la unitat>:. 8. Executa el comandament de DOS dir i verifica que l’arxiu NK.bin està present al disc dur. 9. Si el nom de l’arxiu ha estat canviat o està utilitzant un nom curt, com NK~1.bin, renombra l’arxiu com a NK.bin escrivint ren NK~1.bin NK.bin. Finalment la imatge executable de sistema operatiu queda instal·lada al disc dur primari del PCM-9575 i ja té funcionalitat com a sistema operatiu; podent-se agregar addicionalment aplicacions amb una funcionalitat concreta. Si desitges ampliar coneixements respecte a Windows Embedded CE 6.0 pots consultar el llibre “Professional Microsoft Windows Embedded CE 6.0” de edicions Wrox, escrit per Samuel Phung; d’on s’ha estret gran part de la informació continguda al capítol 4.2. També pots extreure informació útil a la pàgina web http://msdn.microsoft.com/ on s’expliquen metodologies i passos a donar per a la creació i transferència d’imatges.
Metodologia de desenvolupament d’aplicacions PC embedded 115 5 CONCLUSIONS El principal objectiu que perseguia d’aquest projecte era la introducció al coneixement dels sistemes embedded; donada la seva creixent importància al món industrial. La gran quantitat de matèries que s’ha d’impartir a la carrera d’Enginyeria Tècnica Industrial, en un volum d’hores determinat, no han permès un estudi complet d’aquests dispositius. No obstant, el fet de destinar el Projecte Final de Carrera a aquesta temàtica ha permès una introducció al món embedded. Es tracta d’una filosofia d’aplicació tecnològica àmpliament estesa a l’àmbit industrial, amb desenes de pàgines web i llibres destinats a aquesta matèria. A més, els sistemes embedded estan en continu creixement dins el mercat. Durant el desenvolupament d’aquest projecte s’han pogut adquirir una gran quantitat de coneixements que es poden resumir en els següents punts: - Plataformes hardware de sistemes embedded, formats utilitzats i arquitectures de plaques bases i processadors; així com de les principals interfícies de comunicacions. - Principals sistemes operatius i eines software disponibles al mercat per aplicacions embedded. - Estat de l’art del mercat embedded, amb els principals fabricants, tant de software com de hardware. - Metodologies i criteris en l’elecció dels components que han d’integrar un sistema embedded, per a una aplicació concreta; com l’elecció del format de la placa base, el processador i el sistema operatiu. - Metodologia de creació d’imatges executables de sistema operatiu amb el constructor de plataformes de Windows Embedded CE 6.0.
116 Conclusions L’objectiu d’aquest projecte és oferir les bases de coneixement necessàries, coma punt de partida, per a desenvolupar complexes aplicacions embedded. Per tant, aquest és un projecte obert a ser ampliat posteriorment per alumnes d’enginyeria, amb interès per la matèria. Les possibilitats de continuació i ampliació del projecte són molt àmplies. Les meves propostes d’ampliació i millora del projecte són: - Ampliació de funcionalitats del sistema operatiu Windows CE com connectivitat USB o Wireless LAN i suport a multisessió. - Programació d’aplicacions mitjançant Visual Studio 2005 per al seu funcionament sobre un sistema operatiu Windows CE personalitzat. Un exemple d’aplicació podria ser la captació de senyals digitals o analògiques d’un mòdul d’E/S o la comunicació en xarxa de diversos dispositius embedded. - Personalització de la interfície d’usuari del sistema operatiu, programació del llançament d’aplicacions durant l’arrencada i configuració del registre. - Elaboració d’un informe exhaustiu dels PC embedded comercialitzats a l’estat espanyol, amb les característiques principals dels equips i els seus fabricants i proveïdors. Això permetria fer una actualització de l’ informe de l’article “PC embedded”, del nº 316 de la revista “Automática e Instrumentación”, del Març de 2001, escrit per Julián Horrillo.
Metodologia de desenvolupament d’aplicacions PC embedded 117 6 GLOSSARI ADC: Un ADC (Analog-to-Digital Converter) o convertidor analògic-digital és un dispositiu electrònic que converteix senyals analògics en senyals digitals. API: Una API (Application Programming Interface) és el conjunt de funcions i procediments (o mètodes, si es refereix a programació orientada a objectes) que ofereix certa biblioteca per a ser utilitzats per un altre software com una capa d’abstracció. ARM: Es denomina ARM (Advanced RISC Machines) a una família de microprocessadors RISC de 32 bits, emprats especialment a sistemes embedded. Tenen un gran rendiment, un baix consum; i estan suportats per una gran quantitat de fabricants. Backplane: Un backplane és una placa de circuit imprès que connecta diversos connectors en paral·lel, de tal manera que cada pin d’un connector estigui connectat al mateix pin relatiu de la resta de connectors, formant un bus informàtic. S’utilitza com a columna vertebral per a connectar diverses targetes, que juntes formen una computadora. CEPC: Abreviació de “PC amb sistema operatiu Windows CE” que s’utilitza als manuals i el software de Microsoft Windows Embedded CE. DAC: Un DAC (Digital-to-Analog Converter) o convertidor digital-analògic és un dispositiu electrònic que converteix senyals digitals en senyals analògics. Desktop PC: El terme desktop, escriptori en anglès, s’empra en informàtica per a definir aquells computadors i perifèrics PC dissenyats com equips de sobretaula i orientats a aplicacions d’ús ofimàtic o domèstic. DLL: Les biblioteques d’enllaç dinàmic DLL (Dynamic Link Library) són arxius amb codi executable que es carreguen sota demanda del programa per part del sistema operatiu.
118 Glossari Embedded: Terme anglès que significa integrat, encastat. En informàtica industrial un sistema embedded és un sistema que desenvolupa una aplicació concreta i està subordinat a un sistema superior. GRAFCET: El GRAFCET (Gràfica de Control d’Etapes de Transició) és un diagrama funcional normalitzat, que permet fer un model del procés a automatitzar, contemplant entrades, accions a realitzar, i els processos intermedis que provoquen aquestes accions. LAN: Una xarxa d’àrea local o LAN (Local Area Network) és la interconnexió de diversos ordinadors i perifèrics amb una extensió limitada. La seva aplicació més estesa és la interconnexió d’ordinadors personals i estacions de treball en oficines, fàbriques, etc., per a compartir recursos i intercanviar dades i aplicacions. Motherboard: La motherboard o placa mare, anomenada també en anglès mainboard o system board, és una placa de circuit imprès PCB, que conté complexes sistemes electrònics; i s’utilitza generalment com a interfície lògica en els computadors moderns, com els PC. MMU: La unitat de gestió de la memòria o MMU (Memory Management Unit) és un dispositiu hardware format per un grup de circuits integrats, responsable de la gestió dels accessos a la memòria per part de la unitat de processament central (CPU). OEM: Abreviatura de l’anglès Original Equipment Manufacturer, fabricant d’equips originals. Empreses o persones que adquireixen dispositius a l’engròs per a implementar en computadores o equips de forma personalitzada que presenten amb el seu propi nom. OSI: El model de referència d'Interconnexió de Sistemes Oberts OSI (Open System Interconnection) és un model de xarxa descriptiu per a la definició d’arquitectures d’interconnexió de sistemes de comunicacions. PCB: Un placa de circuit imprès o PCB (Printed Circuit Board), és un mitjà per a sostenir mecànicament i connectar elèctricament components electrònics, a través de rutes o pistes de material conductor, gravats des de fulles de coure laminades sobre un substrat no conductor.
Metodologia de desenvolupament d’aplicacions PC embedded 119 PCI: El PCI (Peripheral Component Interconnect) és un bus estàndard per a connectar dispositius perifèrics directament a la placa base. PC/104: Estàndard que defineix un format de plaques electròniques, amb els seus respectius busos, utilitzat principalment a sistemes PC embedded. PLC: Un PLC (Pragrammable Logic Controller) és un dispositiu electrònic utilitzat principalment en l’automatització industrial que controlen la lògica de funcionament de màquines, plantes i processos industrials. Rack: Un rack és un bastidor destinat a allotjar equipament electrònic, informàtic i de comunicacions. Les seves mesures estan normalitzades perquè sigui compatible amb equipament de qualsevol fabricant. RISC: L’anomenada RISC (Reduced Instruction Set Computer) és una arquitectura computacional de processadors que té com a principals característiques: - Instruccions de grandària fixa i presentades en un reduït número de formats. - Només les instruccions de càrrega i emmagatzematge accedeixen a la memòria per a dades. L’objectiu de dissenyar màquines amb aquesta arquitectura és possibilitar la segmentació i el paral·lelisme en l’execució d’instruccions i reduir els accessos a memòria. Les màquines RISC protagonitzen la tendència actual de construcció de microprocessadors. PowerPC, DEC Alpha, MIPS i ARM són exemples d’alguns d’ells. RTOS: Un sistema operatiu de temps real o Real Time Operating System és aquell té un comportament temporal determinista a l’hora de completar les instruccions. Pot respondre de forma previsible davant una petició d’interrupció, i ofereix una major estabilitat al sistema. SBC: Un SBC (Single Board Computer) és un computador complet integrat en una sola targeta de circuit imprès, que incorpora el processador, la memòria, les E/S i tots els dispositius necessaris per al seu funcionament.
120 Glossari System-on-chip (SOC): Integració de tots els components d’un computador o de qualsevol sistema electrònic en un sol xip. Aquest xip conté funcions digitals, analògiques i, en molts casos, de radiofreqüència, totes integrades en el mateix circuit integrat IC (Integrated Circuit). La principal aplicació d’aquesta tecnologia és en el camp dels sistemes embedded. Target: S’anomena target o dispositiu embedded aquell composat per una placa base amb un hardware determinat, destinat a realitzar unes aplicacions concretes. Workstation: S’anomena workstation o estació de treball al computador emprat per al desenvolupament d’aplicacions. En el desenvolupament de sistemes embedded, l’estació de desenvolupament o development workstation s’utilitza per a la creació d’imatges personalitzades de SO o d’aplicacions, i a la transferència d’aquestes als dispositius target.
Metodologia de desenvolupament d’aplicacions PC embedded 121 7 BIBLIOGRAFIA 7.1- Llibres [1] “Real-Time Concepts for Embedded Systems”, Qing Li, ed. CMP Books, 2006. [2] “Embedded hardware, know it all”, J. Labrosse, ed. Newnes, 2008. [3] “Embedded software, know it all”, Jack Ganssle, ed. Newnes, 2008. [4] “Serial port complete: programming and circuits for RS-232 and RS-485 links and networks”, Jan Axelson, ed. Ilustrated, 1998. [5] “Instrumentación virtual: Adquisición, procesado y análisis de señales”, Antoni Mànuel, Edicions UPC, 2002. [6] “Designing Embedded Hardware”, John Catsoulis, ed. O’Reilly, 2003. [7] “Introduction to Real-Time Operating Systems”, Robert Betz, 2001. [8] “Professional Microsoft Windows Embedded CE 6.0”, Samuel Phung, ed. Wrox, 2009. [9] “Windows Embedded Ce 6.0 Fundamentals”, Stanislav Pavlov i Pavel Belevsky, Microsoft, 2008. 7.2- Revistes i catàlegs [1] Revista Automática e Instrumentación nº 316 (Març 2001). Article “PC embedded”, Julián Horrillo. [2] Catàleg Arrow Ibèrica 2009.
122 Bibliografia 7.3- Pàgines web [1] Embedded System Design. Comunitat de desenvolupament embedded. http://www.embedded.com/ . [2] Embedded Computing. Portal amb notícies, productes i eines de desenvolupament de sistemes embedded. http://www.embedded-computing.com/ . [3] Embedded devices. Enginyeria dedicada al disseny de sistemes embedded. http://www.embeddeddevices.com.au/ . [4] Consorci PC/104. Informació sobre les especificacions PC/104 i llistat de fabricants. http://www.pc104.org/ . [5] The Infrared Data Association. Consorci de comunicacions IrDA amb informació sobre els estàndards, comunitat de desenvolupament i fabricants. http://www.irda.org/ . [6] Ampro Computers. Empresa líder en la fabricació de SBC i productes embedded. http://www.ampro.com/ . [7] Diamond Systems Corporation. Empresa proveïdora de SBC, especialment dels estàndards PC/104. http://www.diamondsystems.com/ . [8] ASUSTeC Computer Inc. Fabricant mundial de components electrònics i informàtics, especialment plaques base i targetes gràfiques per a PC. http://www.asus.com/ .
Metodologia de desenvolupament d’aplicacions PC embedded 123 [9] iEi Technology Corp. Inc. Fabricant mundial de components informàtics industrials. http://www.ieiworld.com/ . [10] Microsoft Windows Embedded. Secció de la pàgina web de Microsoft dedicada als productes Windows Embedded. http://www.microsoft.com/windowsembedded/ . [11] Linux Online! . Portal del popular sistema operatiu amb documentació, descàrregues, distribuïdors, etc. http://www.linux.org/ . [12] El Rincón de Linux para hispanohablantes. Tal com el seu nom indica, un portal amb tota la informació i suports de Linux en espanyol. http://www.linux-es.org/ . [13] Monta Vista Linux. Pàgina del distribuïdor d’una de les versions real-time de Linux. http://www.hardhatlinux.com/ . [14] Wind River. Espai web de l’empresa productora de software, amb el RTOS VxWorks com a producte estrella. http://www.windriver.com/ . [15] QNX. Pàgina web de la competència directa de Windriver en RTOS. www.qnx.com . [16] MSDN. Portal de suport de Microsoft. En aquesta web es pot obtenir informació sobre el software de Microsoft, com Windows Embedded CE. http://msdn.microsoft.com/ . [17] Datasheet Catalog. Portal buscador de documentació tècnica en format pdf. http://www.datasheetcatalog.org/ .