Konceptuell modell av dataomvandling till USB

(1)

School of Mathematics and Systems Engineering Reports from MSI - Rapporter från MSI

Jonas Winsth och Christian Clemmensen

(2)

Organisation / Organization

VÄXJÖ UNIVERSITET

Matematiska och systemtekniska institutionen Växjö University

School of Mathematics ans System Engineering

Författare / Authors

Christian Clemmensen Jonas Winsth

Dokumenttyp / Type of document Examensarbete / Diplomawork

Titel / Title

Konceptuell modell av dataomvandling till USB / Conceptual model of data conversion for USB

Sammanfattning

Alstom Power i Växjö arbetar med utveckling och försäljning av bland annat elektrofilter till rökgasreningssystem vid olika typer av miljövårdsanläggningar för t.ex. kraftverksindustrin.

Dessa elektrofilter kontrolleras och regleras med hjälp av styrutrustning uppbyggd av ett antal styrenheter som idag kommunicerar via en egentillverkad standard kallad ”Fläktbuss”. För att övervaka detta system vill man använda handburna PDA och kommunicera med Fläktbussen via USB. För att få kommunikationen mellan USB och Fläktbuss att fungera krävs någon form av aktiv konvertering.

Detta examensarbete kommer att ta upp så väl problematik och lösningar kring det problem som finns i samband med denna konvertering.

Nyckelord

ARM7, Aktiv konvertering, USB, Inbyggda System

Abstract

Alstom Power in Växjö develop and sell equipment like electro filters for enviromental purposes for the power industry.

Those filters are controlled and regulated by controlunits, communicating via an Alstoms own standrad called “Fläktbuss”. To supervise and maintain this system, a solution of PDA and USB communication is intresting. To make this USB – Fläktbuss adaption an active conversion of data is required.

This diplomawork will contain and discuss problems and solutions about this conversion.

Key words

ARM7, Active conversion, USB, Embedded Systems

Utgivningsår / Year of issue 2006

Språk / Language Svenska / Swedish

Antal sidor / Number of pages 71

Internet / www http://www.vxu.se/msi

(3)

FÖRORD

Att studera vid universitet eller högskola är en mycket intressant period i ens liv. Man får se mycket, uppleva mycket och framförallt lära sig väldigt mycket.

Examensarbetet är ett sätt att sätta alla sina kunskaper på prov, att genom egna försök och eget tänkande omsätta teori till verklighet och komma fram till någon konkret slutsats. Examensarbetet är även sättet att knyta ihop säcken av de 3 års studier som förhoppningsvis skall resultera i att man på ett effektivt sätt slussas ut i näringslivet.

Genom att själv få planera och genomföra examensarbetet med bistånd från skola och företag gör att man lär sig se skillnader och likheter mellan dessa två olika världar. Man lär sig jobba självständigt och ta ansvar för sina åtaganden och sitt resultat.

För att kunna genomföra de tester av teorier vi haft kring USB och teknologin bakom har Alstom Power köpt in och försett oss med ett utvecklingskort från företaget IAR Systems.

Med detta vill vi tacka alla som hjälp oss så gott de har kunnat med vårt examensarbete, personal på Alstom Power, vår handledare Per Ranstad och på skolans sida Anders Haggren, MSI.

Växjö, torsdag den 25 maj 2006

Christian Clemmensen Jonas Winsth

(4)

(5)

1 INLEDNING 6 1.1 BAKGRUND 6

1.2 SYFTE 6 1.3 UPPGIFTER OCH AKTIVITETER 7

1.4 MÅL 7 2 FUNKTION 9

2.1 ÖVERSIKT AV FUNKTIONSBLOCK 9

2.2 USB LÄNKEN 10 2.3 ARM7 MIKROPROCESSOR 10

2.4 FLÄKTBUSSENS STYRCHIP 10 3 ANALYS AV HÅRDVARA 11

3.1. ANALYS AV USB 11 3.1.1 Vad är USB? 11 3.1.2 Standardisering 11 3.1.3 Tekniken bakom USB 11 3.2 BESKRIVNING AV ARM7‐PROCESSORER 13

3.2.1 ARM7TDMI och ARM7TDMI‐S 13

3.2.2 ARM7EJ‐S 13 3.2.3 ARM720T 13 4. ANALYS AV NUVARANDE FLÄKTBUSS 14

4.1 DEFINITION AV FLÄKTBUSS OCH DESS FUNKTION 14

4.2 TOKEN RING 14 4.3 PROTOKOLL 14 4.4 PORTNING AV BEFINTLIG FLÄKTBUSS IMPLEMENTATION 15

5 KONSTRUKTION 17 5.1 UTVECKLINGSMILJÖN 17

5.2 UPPSÄTTNING AV TESTKORT 17

5.2.1 Timers 17 5.2.2 USB port 18 5.2.3 Display 22 5.2.4 Avbrottshanterare 23

5.2.5 Serieport 23 5.2.6 Systemet i teorin 23

5.3 KOD OCH STRUKTUR 24 5.3.1 Mål: Läsning och tolkning av inkommande data från USB 24

5.3.2 Mål: Komponering och skrivning av utgående data till RS‐232 24 5.3.3 Mål: Läsning och tolkning av inkommande data från RS‐232 25 5.3.4 Mål: Komponering och skrivning av utgående data till USB 25

6 SLUTSATS 25 6.1 ALLMÄNT OM PROJEKTETS GENOMFÖRANDE 25

(6)

6.3 EGET OMDÖME 27

7 REFERENSER 28 Appendix A – Generell USB kod 29

LPC_USB.c 29 usb_9.c 41 Appendix B – FBAdaptor specifik kod 58

fba_device.c 58 main.c 60 user_func.c 65 usb_desc.c 68

(7)

1 INLEDNING 1.1 BAKGRUND

Alstom Power i Växjö arbetar med utveckling och försäljning av bland annat elektrofilter till rökgasreningssystem vid olika typer av miljövårdsanläggningar för t.ex. kraftverksindustrin.

Dessa elektrofilter kontrolleras och regleras med hjälp av styrutrustning uppbyggd av ett antal styrenheter som idag kommunicerar via en egentillverkad standard kallad ”Fläktbuss”. För att övervaka detta system har man fram till idag använt en enhet som kallats RTU. Då denna enhet börjar bli gammal och service nu för tiden är svår att erbjuda då komponenter blir ovanligare och ovanligare, har man tittat på nyare tekniker. En teknik är att med hjälp av handburna PDA och ny mjukvara i dessa enheter kunna göra motsvarande uppgifter som RTU:n haft.

Då USB idag är den dominerande standarden för kommunikation med yttre enheter är detta en intressant form att kunna kommunicera med den redan existerande Fläktbussen. Fläktbussen bygger på en äldre teknik i form av traditionell seriell kommunikation¹. För att få kommunikationen mellan USB och Fläktbuss att fungera krävs någon form av aktiv konvertering. Detta är anledningen till att en mikroprocessor av någon typ skulle vara aktuell.

Detta examensarbete kommer att ta upp så väl problematik och lösningar kring det problem som finns i samband med denna konvertering. De tre huvudproblemen som kommer att behandlas i detta arbete är:

• Val av processor – Processorn skall ha stöd för USB, samt vara tillräckligt snabb för att kunna tolka trafik från Fläktbussen samt paketera om den till passande USB trafik.

• Portning av befintlig kod – Möjligheterna att portera befintlig kod från nuvarande Fläktbuss-implementation i RTU:n till ny processor kan variera beroende på strukturen hos de olika processorkärnorna och hur väl dokumenterad och strukturerad koden är.

• Uppsättning av USB-länk – En USB-enhet kan sättas upp på en rad olika sätt och konfigureras enligt en hel del olika modeller. En fördjupning i svårigheter och möjligheter med USB kommer att göras.

1.2 SYFTE

Syftet med detta arbete är att hitta en eller flera lämpliga metoder att sätta upp en kommunikationslänk mellan USB och Fläktbuss. Lösningen skall vara ekonomiskt försvarbar och innebära att nuvarande RTU system successivt kan tas ur drift och därmed ersättas av PDA eller annan lämplig utrustning.

(8)

Fig. 1.1 – Illustration av inkopplat system 1.3 UPPGIFTER OCH AKTIVITETER

Genom ingående studier och diverse försök skall idéer på lösningar av de ovan beskrivna problemen presenteras. För att genomföra detta har vi fördelat problemen på en del olika aktiviteter samt en planering för hur dessa skall fortlöpa. Dessa aktiviteter är:

• Analys av hårdvara – En ingående studie av hårdvara anpassad för USB.

Analysen skall ge svar på de frågor angående ny utrustning till produkten.

• Analys av befintlig kod – Den existerande kod som idag driver Fläktbussen körs på en processor av typ 8051. En portning av denna kod kan vara enkel eller väldigt besvärlig beroende på en del olika faktorer. Bland annat kodens struktur.

En analytisk bedömning av denna kod skall leverera ett svar på huruvida koden är användbar eller ej.

• Labbtester och konstruktion – Att utifrån de teorier och idéer vi samlats på oss under analyserna kunna konstruera ett konceptuellt förslag på hur den nya processorn skall sättas upp och kommunicera via USB med en vanlig standard PC eller PDA.

• Testa och verifiera konstruktionen – Tester utförs med hjälp av laborationskort och vanliga Windows XP datorer.

1.4 MÅL

Att få en konstruktion färdig för användning är en för stor uppgift och kan ej innefattas av detta examensarbete. Därför kan man dela upp uppgiften i 3 delmål. Och man kan sedan utifrån detta försöka uppfylla så många som möjligt.

Delmål nummer ett är att få till stånd en USB kommunikation med PDA/PC.

Detta kan ske på en hel del olika vis. Då USB enheter av olika typer delas in i olika generiska eller egendefinierade klasser. Den eller de klasser som för denna typ av kommunikation kan anses vara intressanta är två stycken:

• USB Communication device class – Denna klass definierar hur kommunikation med olika typer av modem och nätverksutrustning kan ske via USB, samt tillhandahåller en generisk modell för hur detta skall fungera.

• Custom device class – Denna klass definierar enheter som inte stöds av färdiga generiska klasser. Här definierar man istället själv helt och hållet drivrutiner och modeller för hur kommunikationen skall sättas upp.

Att med hjälp av någon utav dessa två modeller och en processor från processorfamiljen ARM7 upprätta en kommunikation mellan PC eller PDA och ARM7 processorn är ett av projektets delmål.

Delmål nummer två är att upprätta en kommunikation mellan den befintliga Fläktbussen och den nya processorn. Denna kommunikation skall undersökas och en

(9)

portning av nuvarande programvara kan bli aktuell. Tidsåtgången för detta mål är svårt att uppskatta och därför ligger inte detta mål som första prioritet. Fläktbussen har ett nuvarande styrchip vars enda uppgift är att omvandla signalerna från Fläktbuss till signaler som kan tolkas av nuvarande RTU's processor 8051. Huruvida detta styrchip i framtiden skall användas eller om det eventuellt kan implementeras direkt i ARM7 processorn är en fråga som också bör undersökas.

Delmål nummer tre handlar om att då dessa två kommunikationer är upprättade konstruera ett styrprogram som jobbar direkt i ARM7 processorn. Detta styrprogram kommer helt och hållet att bygga på de egenskaper som processorn har samt de förhållande vad gäller kommunikation som ovanstående studier har givit oss, och blir därmed det slutliga steget för att länka samman hela systemet.

Fig. 1.2 – Alternativ kommunikationsmodell med externt styrchip för Fläktbussen

(10)

2 FUNKTION

2.1 ÖVERSIKT AV FUNKTIONSBLOCK

Den produkt vars konstruktion, denna avhandling baseras på är en typ av konverteringsadapter. Denna adapter skall konvertera befintlig data från Fläktbussen till att kunna tolkas av programvara i en PC eller PDA via en USB-länk. Till detta krävs en aktiv konvertering med hjälp av en mikroprocessor. Till denna processor kommer sedan programvara för styrning att krävas.

De delar som kommer att ingå i konstruktionen i sitt kompletta utförande är alltså följande: PDA eller PC ansluten till en mikroprocessor av typen ARM7, denna processor kommer sedan att vara antingen direkt ansluten till Fläktbussen eller via ett redan befintligt styrchip till Fläktbussen. Det två alternativen illustreras med bilder nedan.

Fig. 2.1 – Komplett system med integrerat FB-styrchip.

Fig. 2.2 – Komplett system med separat FB-styrchip.

Det första alternativet är en tillsynes komplett produkt. Här agerar ARM7-processorn både som styrchip mot Fläktbuss-sidan samt styrchip jämt emot USB sidan.

Bitströmmen som då kommer att tas emot på Fläktbuss-sidan är av typen FSK (Bi- phase).

Det sista alternativet innebär att man alltså till en början upprättar en USB förbindelse med ARM7 processorn och sedan tolkar den information som kommer från FB- styrchipet. Denna information levereras i NRZ-kodat bitformat. Och bör därmed kunna tolkas i processorn och sedan förmedlas vidare till PC eller PDA för vidare hantering med installerad programvara.

(11)

2.2 USB LÄNKEN

Att upprätta en USB kommunikationslänk mellan en PC eller PDA och ARM7 processorn innebär en seriell kommunikationslänk som upprättas enligt vissa standarder. Den processor vi väljer att använda kommer att ha stöd för USB kommunikation. En USB länk kan sättas upp på en hel del olika sätt, eller i s.k. olika klasser. Dessa klasser gör att enheten kommer att uppfattas olika av värddatorn. Den klass som finner sig lämplig för ändamålet är en s.k. ”custom class”, en egendefinierad klass. Hastigheten för denna länk är fullt tillräcklig då USB 2.0 är kompatibel att köra upp till 480 Mbit/s. Hastigheten på nuvarande Fläktbuss är 62,5 kbit/s vilket ger goda marginaler även om man kör på lägsta hastigheten för USB, 1,5 Mbit/s. Genom att med hjälp av processorn tolka information från Fläktbussen och sedan konstruera kompatibla USB-paket som sedan kan läggas ut på ett USB interface skall man kunna ta emot tillfredställande data på PC/PDA sidan.

2.3 ARM7 MIKROPROCESSOR

Processorn kommer att agera som själva motorn i hela systemet. Inkommande information i form av NRZ eller FSK formad bitström kommer att agera som indata till processorns styrprogram. Styrprogrammet kan skrivas i C/C++ och skall utgöra grundfunktionaliteterna för hur data ska tolkas samt hur Fläktbuss ska styras och även hur information från Fläktbussen skall paketeras för att sedan kunna levereras på korrekt sätt ut på USB länken. Strömförsörjning av processorn kommer att ske via USB² som har direkt stöd för den ström och den spänning som processorn kräver.

2.4 FLÄKTBUSSENS STYRCHIP

Fläktbussens styrchip utgörs av en programmerbar krets. Denna krets består huvudsakligen av tre delar. En extern oscillator som genererar en 12 eller 4 MHz signal samt en intern klocka på 1 MHz. Kretsen består i övrigt av sändardel och en mottagardel. Sändaren kodar bi-phase signaler av NRZ signalerna och sänder ut detta på bussen. Mottagardelen har motsatt funktion och omvandlar den inkommande bi- phase signalen till NRZ signal.

(12)

3 ANALYS AV HÅRDVARA

Detta kapitel syftar till att med hjälp av ingående studier och efterforskningar i tidskrifter och Internet, identifiera svagheter i nuvarande system samt vad ny processor och teknik kan erbjuda för att åstadkomma samma sak. Kompatibilitet med redan existerande Fläktbuss ute i industrin är något som vi tagit hänsyn till då vi valt fokus på komponenter och tekniker.

3.1. ANALYS AV USB 3.1.1 Vad är USB?

USB är den i dag dominerande standarden för kommunikation mellan yttre enheter och datorn. USB har under de senaste åren även slagit sig in på andra marknader utanför just datorer, och man har nu möjlighet till att koppla in USB på olika former av spelkonsoler, PDA och annan hemelektronik.

Generellt sett kan man säga att USB består av en host eller senare kallad controller, denna kontrollerar de anslutna enheterna. I ett USB system kan man sedan via hubbar och vidarekopplingar koppla på 127 stycken enheter i max 5 splitnivåer.

En modern dator idag har dock oftast mer än 1 USB controller vilket möjliggör inkoppling av ett mycket stort antal enheter.

USB designades för att slippa en massa konfigurationsproblem samt behovet av en massa kontrollerkort i datorn t.ex. PCI, ISA etc. För att förenkla hela systemet har man även utvecklat starkt stöd för plug and play och denna enkelhet är förmodligen en utav de största anledningarna till att USB slagit igenom. Idag kan man sedan USB 2.0 introducerades i princip använda USB tekniken till all form av yttre kommunikation med datorn. Det enda som fortfarande har begränsningar är monitorer då de kräver en väldigt hög data överföring.

3.1.2 Standardisering

USB är en standard för kommunikation fastställd av USB-IF³. Här ingår några utav marknadens ledande datortillverkare så som, Apple Computer, Hewlett-Packard, NEC, Microsoft, Intel och Agere.

Den specifikation som nu gäller är USB 2.0⁴. Denna standard skiljer sig speciellt på en punkt från USB 1.1, den högre överföringshastigheten. USB 2.0 standardiserades år 2000 och är den i särklass bästa. Utrustning konstruerad för USB 2.0 är bakåtkompatibel och fungerar således även med USB 0.9, 1.0, 1.1 försedda datorer.

3.1.3 Tekniken bakom USB

Som det beskrivits kortfattat tidigare så ansluter man alltså enheter till en controller.

Dessa enheter kan på USB språk kallas för enheter eller funktioner. Detta för att en enhet ofta har fler än en funktion. Varje funktion tilldelas sedan vid anslutning varsin egen logisk kanal kallad pipe. Detta är en kanal mellan enheten/funktionen och USB controllern. Dessa pipes är sedan numrerade 0-15 i varje riktning. Vilket innebär att en enhet kan ha upp till 32 olika funktioner kopplade till sig.

3 USB Implementers Forum

4 Mars 2006

(13)

Dessa pipes kan delas in i 4 olika kategorier beroende av vilken typ av trafik som skall skickas på dessa. De 4 olika kategorierna är:

1. Control transfers – Används för kort enkelkommando trafik för att styra och få respons från enheten.

2. Isochronous transfers – Används för att garantera en viss överföringshastighet oftast den snabbaste. Denna metod innebär ibland en del dataförlust, men används dock ofta ändå i sammanhang som realtids ljud och bild strömmar.

3. Interupt transfers – Används för enheter som kräver snabb respons, avbrotts styrd kommunikation som ofta används för möss och tangentbord etc.

4. Bulk transfers – Används för intensiva tillfälliga överföringar som tar all data och bandbredd. Dessa överföringar garanterar ingen speciell hastighet eller liknande, och används främst vid filöverföring av olika slag.

Identifieringen av varje enhet är ganska lik den teknik som används vid TCP/IP nät med DHCP. Varje enhet tilldelas en unik 7 bitars adress från controllern, som sedan använder sig av en form av Round-Robin teknik för att ge varje enhet sin specifika uppmärksamhet.

Det finns olika klasser av standard enheter för USB som kan användas för att t.ex. använda generiska drivrutiner för exempelvis minneskort. Här efter följer en kort beskrivning av de vanligaste klasser som finns med i USB 2.0 specifikationen:

• USB Audio device class – Ljudkortsliknande enheter.

• USB Human interface device class – Inputenheter så som möss, tangentbord, joysticks.

• USB Printer device class – Skrivarenheter och dylikt.

• USB Mass storage device class – Används till flash-minnen, portabla hårddiskar minneskort, digitalkameror och mp3-spelare.

• USB Hubs – Egentligen inte en klass utan en replikator och multiplikator i ett USB system.

• USB Communication device class – Används till modem, nätverkskort och andra möjliga externa kommunikationsformer

• USB video device class – Används till enheter som t.ex. webbkameror och andra enheter för hantering av rörlig bild.

• USB wireless controller class – Används av enheter för t.ex. trådlösa närverkskort, bluetooth adaptrar eller IR adaptrar.

• Custom device class – Används för enheter som inte stödjer någon utav ovan nämnda standarder och kräver därmed egna drivrutiner.

(14)

3.2 BESKRIVNING AV ARM7‐PROCESSORER

ARM7-familjen av mikroprocessorer är 32 bitars processorer, dessa processorer kan erbjuda 32 bitars prestanda till samma ström och resurs kostnad som brukliga 8 eller 16 bitars system, vilket gör ARM7 familjen till en konkurrenskraftig typ av processor.

Serien mikroprocessorer har utvecklats för att möta marknadens allt högre krav, de genomgående krav som ställts och som sedan har stått som grund vid konstruktionen av dessa processorer är:

Processorn skall ha stöd för JAVA och även stöd för en hel del olika operativsystem, så som Windows CE, Linux, Palm OS, Symbian OS. ARM7 familjen innehåller 3 olika modeller. Dessa är anpassade för olika typer av slutprodukter och kan sammanfattas på följande vis.

3.2.1 ARM7TDMI och ARM7TDMI‐S

Denna processor är grundstenen i hela ARM7 familjen och är en vanligt förekommande 32-bitars RISC processor. Dessa processorer har stöd för två olika instruktionsset, Thumb 16 bitars set och ARM 32 bitars set. Detta underlättar för de som väljer att programmera processorerna på instruktionsnivå⁵ istället för språk på högre nivå t.ex. C eller C++.

Processorns generiska konstruktion gör att den är kompatibel med andra processor familjer så som ARM9 och ARM10. AMR7TDMI-S är lite annorlunda i sin konstruktion och är vad man skulle kunna kalla formbar (synthesizeable) och kan därmed portas till en hel del andra tekniker, hastigheter, storlekar och språk. Detta gör alltså ARM7TDMI-S till en ännu mer flexibel processor än den vanliga ARM7TDMI.

3.2.2 ARM7EJ‐S

Till skillnad från ARM7TDMI processorerna innehar denna processor stöd för JAVA.

Detta innebär att implementering kan ske objektorienterat på en utav de högsta programmeringsnivåerna. Utöver detta motsvarar processorn i prestanda det ovan nämnda. Även denna processor är försedd med liknande formbarhet som ARM7TDMI-S

3.2.3 ARM720T

ARM720T är en makrocells processor. Den innehåller förutom processorkärna även yttre komponenter så som 8 KB cache och en så kallad MMU (Memory Management Unit). Detta kan användas för att adressera virtuellt minne eller användas för att försäkra sig om en säker exekvering. Denna processor är även byggd för att kunna köras på olika typer av mer sofistikerade operativsystem så som de ovan nämnda, Linux, Windows CE, Palm OS och Symbian OS.

5 ASM - assambler

(15)

4. ANALYS AV NUVARANDE FLÄKTBUSS

4.1 DEFINITION AV FLÄKTBUSS OCH DESS FUNKTION

Fläktbussens syfte är att verka som kommunikationslänk mellan de, ibland 100 talet, systemdatorer som skall ombesörja övervakning och kontroll av de stora elektrofilter som Alstom tillverkar. Denna buss är en mer eller mindre kundspecifik version av en äldre konventionell standard kallad RS-485.

Bussen kan ansluta upp till 127 enheter i antingen master/slave förhållande eller s.k. multimaster system. Överföringshastigheten är 62.5 kbits/s, vilket med dagens mått inte är någon svårighet att hantera och borde således innebära att förutsättningarna för portning av befintlig kod mot en ny AMR7 processor är ganska stora. Systemet kopplas samman med partvinnad kabel av typen CAT-1⁶. Nätet är av typen token ring, som följer vissa principer.

4.2 TOKEN RING

Fläktbussen bygger alltså på ett token ring nät. Detta innebär att man låter endast den enhet som har ”token” eller talan att kommunicera. Sedan skickas ”token” vidare enligt ett visst schema som styrs av en s.k. ”supervisor”. Token kan beskrivas som en sorts kontroll som tillåter innehavaren att kommunicera på valfritt sätt till dess att rättigheten skickas vidare.

Nätet byggs upp av enheter som sätts antingen som master eller slave. Ett nät kan bestå av flertalet masters och slaves. Dock specifikt är att det alltid är en och endast en supervisor men om en supervisor försvinner kommer en annan master att bli supervisor.

4.3 PROTOKOLL

Fläktbussen har som så många andra nätverkskonfigurationer en uppsättning protokoll eller en protokollstack som man ofta kallar det. Fläktbussen bygger på ungefär samma protokollmodell som Ethernet som jobbar enligt OSI-modellen.

Detta är en modell för hur datorer kommunicerar genom olika lager och i lagren används olika typer av protokoll. För fläktbussen ser lagren ut så här:

Fig. 4.1

(16)

• Physical layer – På denna nivå hanteras mediet. D.v.s. kabeln. Det är en partvinnad kabel med c:a 80-120 ohms impedans, detta motsvarar den kabel som används för telefoner. Utdata från detta lager är rådata kodad enligt en s.k. ”Bi- phase”-princip, en bitsekvens kan t.ex. se ut så här:

Fig. 4.2

• Data Link layer – Här gör sig det s.k. ”token ring” nätet påmint. En supervisor kommer att skicka runt ”token” enligt en viss ordning och där med får varje enhet chansen att kommunicera. Det man skickar är precis som i Ethernet ramar. En nod som inte har ”token” kan bara verka som passiv mottagare av information.

Fig. 4.3

• Application layer – Fläktbussens programpaket består av 3 olika typer av applikationer:

o General application interface – Använda för att styra och hantera sändar- och mottagarbuffrar.

o Token passing application interface – Används för att styra och övervaka

”token passing” logiken.

o Node status logging application – Innehåller rutiner och funktioner för att erhålla information om nodens status och diagnostiska värden.

4.4 PORTNING AV BEFINTLIG FLÄKTBUSS IMPLEMENTATION

Den befintliga implementation av Fläkbussen i RTU bygger på en gammal processormodell av typen 8051. Vid ett eventuellt byte av processor till ARM7 är det intressant att studera den befintliga kod som finns för 8051 processorn och se hurvida den är användbar och hur mycket jobb det är att porta den.

Både ARM7 och 8051 är programmerbara med språket C, detta gör att möjligheten till direkt portning finns. Det som skiljer processorerna åt är dess kompilatorer. Även fast båda stöjder C så har de även en hel del kompilatorspecifika kommandon och datatyper. Hur dessa skillnader yttrar sig kan vara svårt att säga, men ändringar kommer att behöva göras.

Den första aspekten av det hela som bör beaktas är det faktum att 8051 är en 8- bitars processor och ARM7 har en 32-bitars arkitektur. Dock har ARM löst dessa kompabilitets problem genom att man har möjlighet att deklarera variabler av olika storlekar så som 8, 16 eller 32 bitar stora. Att denna möjligheten finns gör portning avsevärt mycket lättare. Dock återstår att ändra datatyper på variabler, dessutom skiljer sig 8051’ans interuptnotation så denna måste också omkonstrueras.

Filen som analysen är baserad på (commun.c) beskriver Fläktbussens datalänk- skikt och kan anses innehålla den logik som är intressant för detta projekt. Filen innehåller en uppsättning definitioner och hundratalet variabeldeklarationer där

(17)

datatypen inte är kompatibel. Detta kan ändras genom att antingen ändra på alla ställen eller skiva en .h fil som omdefinerar de fyra typerna.

Commun.c innehåller även hel del funktioner och logik. Logiken sakll ju vara den samma och kommer troligvis att fungera efter att variabler och definitioner är modifierade. Däremot finns en hel del funktioner för bland annat initiering processor och hårdvara som måste byggas om för att passa ARM7’s kompilator. Hur kompatibelt detta egentligen är, är svårt att avgöra utan att praktiskt genomföra portningen, och detta är något som vårt examensarbete ej innefattar. Ytterliggare aspekter utifrån vår analys är att koden innehåller en hel del timerstyrda funktioner.

Processorerna jobbar med olika hastighet och det kommer att leda till att man måste räkna om all timerstyrning, detta är dock något som också kommer att uppdagas specifikt på vilka ställen detta är, då en portning sker.

En generell slutsats av portningsanalysen är att koden är väl skriven och strukturerad, och större delar av den, över 90 % bör kunan anävndas utan några modifikationer, så länge man vill ha en likvärdig funktion och logik på Fläktbussens datalänk nivå. Tar denna portning lång tid i anspråk då? Detta är också en bedömningsfråga som helt och hållet baseras på programmerarens kunskaper. Vad som dock krävs är att personen eller personerna har omfattande kunskaper i de båda processorernas arkitektur.

(18)

5 KONSTRUKTION 5.1 UTVECKLINGSMILJÖN

För att på enklaste sätt kunna jobba med processorn valde vi att innan den fanns tillgänglig ladda ner och prova utvecklingsmiljön eller IDE (Integrated development environment). Den version vi använde var en 30 dagars fullversion av IAR Embedded Workbench for ARM7 v 4.10. Programmet körs i Windows miljö och liknar i stort sett väldigt många andra IDE’s. Detta gjorde det hela ganska enkelt. Vad vi däremot upplevt som lite problematisk har varit att lyckas starta egna projekt. Att inkludera de C-bibliotek och filer som skulle visa sig vara nödvändiga var svårt och detta gjorde att allt blev ganska mycket mer omständligt och svårt.

Programmet innehåller förutom en strukturerad ”workspace”, en C/C++

kompilator anpassad för rätt processor modell, samt en inbyggd debugger och simulator där man kan analysera och kontrollera värden på register, variabler, minnesplatser.

5.2 UPPSÄTTNING AV TESTKORT

För att kunna programmera mot processorn och testkortet krävs att miljön sätts upp korrekt. Här krävs bland annat en hel del inställningar av hårdvaran som görs direkt när man programmerar flashminnet och via jumpers. Bland annat måste man köra strömförsörjningen på J-LINK när man programmerar processorn, detta har att göra med strömförsörjning av vissa perifera enheter och att denna kan gå förlorad då man flashar om processorn. Efter färdig programmering finns det givetvis möjlighet att ställa om denna jumper att antingen gå på extern spänningskälla eller via USB.

Olika funktioner identifierar och initierar de olika delarna på testkortet samt kopplar processorns interna register till de olika periferienheterna. För detta ändamål fanns färdig specificerade filer, drivrutiner och funktioner som kan väljas att inkludera vid programstart. Ett problem som dock uppstod då vi började jobba med detta var att dessa filer var dåligt dokumenterade och svåra att förstå vad dom egentligen gjorde. Genom att studera ett existerande exempel av en USB-mus lyckades vi till slut sätta upp lämplig miljö. De komponenter som vi då initierade var:

• 2 Timers

• USB port

• Display

• Avbrottshanterare

• 1 Serieport

5.2.1 Timers

För at kunna använda de inbyggda funktionerna som initieras för övriga periferienheter och intern hantering av data, krävs att timers initieras. Våra lösning använder ej timers, men det används indirekt via funktioner i lösningen.

(19)

5.2.2 USB port

USB porten är en periferienhet som består av en USB-port av typ B. Denna styrs och kommunicerar med ett separat USB styrchip inkluderat i processorn. Det är alltså detta styrchip som initieras vid uppstart av vårt program. Den initiering som är gjord baseras på ett tillgängligt exempel bestående av en USB mus. Till testkortet och utvecklingsmiljön medföljer en uppsättning .c och .h filer som innehåller specifikationer och funktioner för hur USB initieras. Det filer som vi utnyttjat anpassat för vårt ändamål är:

LPC_USB.c / LPC_USB.h usb_9.c / usb_9.h

usb_desc.c / usb_9.h LPC_USB.c / LPC_USB.h

Denna fil innehåller de definitioner och adresseringar som används för att initiera och sätta upp den periferin som nämndes ovan, bland annat USB interfacets egna styrchip.

För att förstå innehållet i denna fil krävs ingående studier och kunskaper kring ARM7’s arkitektur samt hur testkortet till processorn LPC2148 är konstruerat. De slutsatser man kan dra av våra studier kring ämnet är att först och främst för att aktivera och kunna nytta USB-periferin är att köra funktionen UsbHwInit()

usb_9.c / usb_9.h

I denna fil finns det en hel del intressanta funktioner som kan ses som en API för USB kommunikationen. Dessa funktioner utnyttjar det som finns tillgängligt i LPC- USB.c och verkar därmed som en länk mellan LPC-USB.c och programmeraren.

Detta är till stor nytta då funktionerna genom namn ofta beskriver vad de gör och själva programmeringen bli mer lik traditionell C-programmering. Vad som dock krävs av programmeraren är att denna har kännedom i hur USB fungerar och dess principer. T.ex. att man har ett visst antal ”pipes” och att varje pipe ses som en egen

”endpoint”. Dessa måste dock sättas upp manuellt.

Det som nyttjas i denna filen är i princip den funktion som heter USBCoreInit(), denna funktion tar en funktionspekare som argument. Denna funktion är alltså den som initierar de ovan nämnda ”endpoints”.

usb_desc.c / usb_decp.h

För att få USB-hosten att känna igen enheten och dess typ, samt en hel del andra viktiga parametrar som beskriver enheten, använder man sig av en s.k. ”descriptor”.

Denna är definierad i usb_desc.c. Här finns t.ex. möjlighet att sätta vilken typ av klass enheten är av, enhetens namn, version tillverkare samt specifikationer av storlek på paket och överföringshastighet. Allt finns beskrivet i denna fil.

Vad är en descriptor?

Alla USB enheter har en uppsättning av descriptors. Dessa fungerar som en beskrivning av enheten och är arrangerade i en hierarkisk ordning (Fig. 5.1). Alla USB enheter har enbart en Device descriptor som sedan kan utnyttja olika uppsättningar av konfigurationer bestående av olika kombinationer av andra descriptorer.

(20)

Fig. 5.1

Device descriptorn är alltså själva stommen i hur en enhet tolkas av hosten. Den innehåller information om t.ex. vilken USB version enheten följer och även tillverkarens ID och produktens ID. Även en klass specificering talar om för hosten vilken typ av drivrutin som bör användas och hur många olika konfigurationer som enheten kan ha. De olika parametrarna som man kan sätta är dessa:

bLength Descriptorns storlek i bytes

bDescriptorType Konstant värde som beskriver descriptorns typ.

bcdUSB Konstant värde som beskriver vilken

USB standard som efterföljs (0x0200 = 2.0)

bDeviceClass Specificerar vilken klass enheten tillhör.

(0x00 betyder att varje interface specificerar sin egna klass).

bDeviceSubClass Motsvarande funktion som ovan.

bDeviceProtocol Definierar vilken typ av protokoll som skall användas när host talar till enheten.

bMaxPacketSize Maximal storlek för paket på ”control pipe”. EP0 (8,16,32,64 bytes).

idVendor ID som beskriver tillverkaren av enheten.

idProduct ID som beskriver produkten.

bcdDevice Deklarerar vilken version det är på produkten.

iManufacturer Tillverkarens namn

iProduct Produktnamn

iSerialNumber Enhetens serienummer.

bNumConfigurations Antal möjliga konfigurationer.

Configuration descriptor är nästa steg i den hierarkiska modell som bygger upp descriptorerna för en USB enhet. De flesta enheterna har endast en configurations descriptor med, men det finns alltså möjlighet att ha flera descriptorer för detta ändamål om man nu önskar att kunna göra flera olika konfigurationer av enheten.

Configurations descriptorn innehåller information om antal olika ”interface” och hur enheten strömförsörjs samt hur mycket ström enheten förbrukar:

bLength Descriptorns storlek i bytes

(21)

wTotalLength Descriptordatans totalt längd (inkl. alla descriptorer i bytes)

bNumInterfaces Antal interface för enheten.

bConfigurationValue Specifikt värde för att välja just denna konfigurationen om flera finns möjliga.

iConfiguration Configurations beskrivning.

bmAttributes Inställningsmöjligheter för

strömförsörjning via USB.

bMaxPower Max strömförbrukning från enheten.

(22)

Interface descriptor kan man se som en gruppbeskrivning av de olika endpoints som en enhet innehåller. Dessa endpoints har en speciell funktion hos enheten gemensamt.

En Interface descriptor innehåller följande information:

bLength Descriptorns storlek i bytes.

bInterfaceNumber Anger vilket Interface som denna descriptorn avser.

bAlternateSetting Värde som används om flera olika inställningar finns att tillgå.

bNumEndPoints Anger antalet ”endpoints” som detta interfacet har tillgång till.

bInterfaceClass Klass kod.

bInterfaceSubClass Subklass kod.

bInterfaceProtocol Protokoll kod, används för att identifiera vilket protokoll.

iInterface Descriptor beskrivning för interfacet

Endpoint descriptor. Denna descriptor syftar till att beskriva alla endpoints, bortsett från Ep0 (Endpoint zero). Ep0 är nämligen initierad långt innan någon utav descriptorerna överhuvudet taget är skickade. En endpoint descriptor innehåller följande parametrar:

bEndpointAddress Unik adress till varje endpoint bmAttributes Beskriver endpointen och hur den

skickar och tar emot data. Se USB specification 2.0

bNumEndPoints Anger antalet ”endpoints” som detta interfacet har tillgång till.

wMaxPacketSize Max storlek på paket som endpointen kan ta emot och sända.

bInterval Intervall för styrning av polling-funktion på endpoint. Används ej vid

Bulk&Control endpoints.

bInterfaceProtocol Protokoll kod, används för att identifiera vilket protokoll.

iInterface Descriptor beskrivning för interfacet

(23)

String descriptor. Dessa används för att kunna överföra läslig text. T.ex. för namnet på tillverkare eller produktnamn. Stringdescriptorns format är Unicode, detta gör att det kan skrivas på många olika språk och ha tillgång till många tecken. Deklarationen av en stringdescriptor blir dock lite mer komplicerad tack vare detta och p.g.a. att varje tecken representeras av 2 byte krävs det att man före varje tecken deklarerar en nolla. En stringdescriptor kommer då att se ut som följer:

const Int8U ProductStrLan1 [] = {

98, //length

UsbDescriptorString, // Descriptor

'U',0,'S',0,'B',0,' ',0,'A',0,'d',0,'a',0,'p',0,'t',0,'o',0,'r',0, ' ',0,'p',0,'r',0,'o',0,'f',0,'e',0,'s',0,'s',0,'i',0,'o',0,'n',0, 'a',0,'l',0

};

Som man kan se är denna deklaration något komplicerad men dock nödvändig för kompabilitetens skull. En stringdescriptor består av:

wLANGID[x] Supported Language ID

5.2.3 Display

LCD-displayen på testkortet kan visa 2*16 tecken. För vårt exempelprogram används den endast för demonstration och debugging. Men för andra applikationer skulle denna skärm kunna vara till stor nytta, då den både har belysning och möjlighet att visa ganska mycket text. Att använda och initiera displayen är en relativt enkel operation, då det finns en färdigskriven drivrutin som egentligen bara behöver inkluderas och initieras. Drivrutinsfilen ”drv_hd44780.c” innehåller sedan en hel uppsättning funktioner för att kunna skriva till displayen, rensa displayen och en hel del andra nyttiga funktioner för att kunna jobba med displayen. Kodningen som den tolkar är null-terminerade char-pekare. D.v.s. strängar bestående av vanliga ASCII – tecken.

(24)

5.2.4 Avbrottshanterare

Avbrottshanteringen i ARM7 processorn sköts genom s.k. VIC (Vectored Interrupt Controller). Alla avbrott lagras i en vektor och vektorn bestämmer sedan vilken typ av avbrott det är frågan om t.ex. fiq (fast interupt request), irq (vectored interupt request) eller non vectored irq. Allt detta för at avbrotten skall kunna hanteras med olika prioritet, fiq har den högsta prioriteten och non-vectored irq har den lägsta.

Avbrotten för att kontrollera och styra USB sidan är av typen vectored-irq. För att kunna använda VIC så krävs en initiering. Denna görs i funktionen SysInit(), här initieras timers och avbrottsvektorn. Funktionerna till dessa filer periferikretsar finns fördefinierade i de filer som heter LPC_Timer.c och LPC_Vic. Dessa filer innehåller en hel del funktioner för att hantera Timers och avbrott.

5.2.5 Serieport

En utav förutsättningarna för en lyckad produkt i slutänden är att man med hjälp av processorn skall kunna ta emot information från Fläktbussen och tolka om den för att passa USB trafik. Dock kräver detta vidare utredning, bland annat hur Fläktbuss skall anslutas. Ska Fläktbussens styrchip implementeras eller ska det kosntrueras vid sidan om. Denna anslutning fanns det ej tid för under vår tid på Alstom och vi har därför ej haft möjlighet att prova våra teorier praktiskt på ett äkta Fläktbussnät. Så därför bestämde vi oss för att bygga ett demonstrationsexempel som slussar trafik från vanlig klassisk RS-232 interface mot USB. Detta beslut grudades på två enkla anledningar, utrustning fanns tillgänglig för detta hemma och på skolan, samt att RS232 är ett gammalt och beprövat kommunikations sätt som är relativt enkelt att hantera. RS232 har även mycket gemensamt med RS485.

Testkortet har två stycken interface av typen UART (UART0 och UART1) för seriell kommunikation med externa och perifera enheter. Den vi valt att nyttja är UART1 och initieras i samband med VIC och USB i SysInit()-funktionen. Här härleds funktioner som UART_Init() för att initiera denna komponent på testkortet.

Funktionen återfinns enligt samma mönster som ovan, i filen LPC_Uart.c. Efter detta sätts även en avbrotts-kanal upp i avbrottsvektorn. Denna kommer att verka enligt samma typ som avbrottshanteringen för USB. Nämligen som Vectored IRQ.

5.2.6 Systemet i teorin

Systemet som nu är uppsatt ska alltså i princip med hjälp av styrande kod kunna ta emot data i form av byte-strömmar på den seriella sidan och sedan paketera om denna datan i paket konstruerade för att kunna skickas via USB och sedan tolkas korrekt på PC/PDA sidan. För att detta skall fungera finns alltså Timers och avbrottsvektorer för hantering av avbrott.

Den seriella porten kontrolleras alltså med jämna täta mellanrum efter trafik.

Denna trafik skall sedan presenteras på displayen samtidigt som den skickas ut på den avbrottsstyrda USB länken. Kraven som kommer att ställas på hela systemet är att datan tolkas korrekt och skickas i den form av paket som logiken i det skrivna protokollet definierar. Visar detta examensarbetes fortsatta försök att processorn eller någon utav ovan nämna komponenter ej klarar uppfylla detta krav, bör man leta efter en annan lösning, kanske med hjälp av andra komponenter eller en annan implementeringsmetod.

(25)

5.3 KOD OCH STRUKTUR

Koden är som vi redan nämnt skriven i programspråket C. Den kompilator vi har tar en del extra special kommandon framtagna och anpassade både för att optimera koden och göra programmeringen enklare för programmeraren. Kompilatorn är designad för just ARM7-processorer och kan hantera båda de olika instruktionsuppsättningarna som processorn har stöd för (Thumb och ARM).

Kärnan i programmet ligger i main.c, här anropas all initiering d.v.s. timers, IRQ periferienheter etc. Men som man snabbt förstår sköter dessa enheter sig inte själva, det krävs även logik. En del utav denna logik finns färdigskriven och kan användas med hjälp av en del anpassning. Men en del har vi även fått skriva själva.

Som redan nämnts i detta kapitel krävs att USB enheten känns igen, detta görs med hjälp av en uppsättning descriptors, dessa är implementerade i listor (arrays) vars innehåll är kopplade till en så kallade enums (se usb_desc.h). Detta är endast hjälpmedel för programmeraren som slipper koda hexadecimala koder för varje enskild inställning.

5.3.1 Mål: Läsning och tolkning av inkommande data från USB

I debugnings och demonstrations syfte har vi valt att även initiera den LCD display som finns tillgänglig på testkortet. Denna saknar direkt stöd för utskrivning av hexadecimala värden. Detta är löst genom implementering av en vektor bestående av 255 strängar (”00”-”FF”) som indexerats av de hexkoder som skall visas (0x00 – 0xFF). Denna vektor kallas ”HexVector” och är belägen i user_func.c och för att kunna nå den varifrån som helst i programstrukturen skapades en funktion som heter getHex() som returnerar korrekt sträng.

En utav det störst svagheterna som upptäckts genom vår implementation och våra tester uppdagades ganska omgående då det var dags att läsa data från USB och skriva till LCD. Problemet grundar sig i att läsfunktionen för USB stödet returnerar en lista av 32-bitars heltal (Int32U) och getHex()-funktionen vill ha 8-bitars heltal (Int8U) som in parameter. Detta innebär att om man vill skriva till LCD:en så måste dessa 32-bitars block omvandlas till mindre 8-bitars block, detta är löst genom en union som är deklarerad både som en 32-bitars och fyra 8-bitars variabler. Då kan ett 32-bitars block tolkas som om det vore fyra 8-bitars block och därmed nyttjas i gexHex()-funktionen. Resultatet blev alltså en USB-länk där det nu finns möjlighet att läsa data från USB och skriva till LCD.

5.3.2 Mål: Komponering och skrivning av utgående data till RS‐232

Data som tagits emot genom USB kommer i binärform och är inte kompatibel med RS-232’s teckenstyrda kommunikation, därför måste datan konverteras till en form som RS-232 kan förstå. Även här används getHex() för att skapa tecken som skickas ut på serieporten genom UART_PutString()-funktionen och därmed har en kommunikations kanal för RS-232 skapats.

(26)

5.3.3 Mål: Läsning och tolkning av inkommande data från RS‐232

Läsning från RS-232 är gaska simpelt i teorin, nämligen att läsa en byte i taget genom polling och sedan sammanstråla till en 32-bitars variabel för tolkning av innehåll.

Själva sammanstrålningen sker genom en egendefinierad funktion MakeByte() som tar 2 chars som in parametrar och skapar en byte enligt metoden: ’A’ och ’4’ blir 0xA4. Detta för att kunna påvisa funktionen RS-232 till USB.

5.3.4 Mål: Komponering och skrivning av utgående data till USB

När ett helt FB-paket har lästs in genom RS-232 och identifierats så skrivs det på USB’s utkanal med hjälp utav funktionen Ep_write(), som sedan lägger till paketet i utbufferten på vald endpoint..

6 SLUTSATS

6.1 ALLMÄNT OM PROJEKTETS GENOMFÖRANDE

En generell princip eller modell för hur man jobbar med projekt går ut på att man först och främst identifierar problemet eller uppgiften och sedan sätter upp ett lämpligt och rimligt mål som man kan nå under den tid projektet pågår. Efter detta görs en tidsplan för att kunna hålla reda på var i projektet man befinner sig och var som återstår. I tidsplanen planeras olika aktiviteter in som projektet omfattar samt hur lång tid dessa tar.

Hur väl passade denna metod för vårt projekt? Man kan säga att metoden är ganska enkel att tillämpa. Vad som dock krävs är att man har en viss vana att jobba med den, samt att man vet hur lång tid vissa moment tar. Som det beskrevs i början av denna avhandling bestod vårt projekt av 5 aktiviteter samt tidsplanering och presentation. Dessa var fördelade på följande sätt i vår planering:

Tidplanering

13 14 15 16 17 18 19 20 21 22

Vecka

Tidsplanering Analys av hårdvara Analys av befintlig kod Labbtester

Konstruktion Tester

Sammanställnade

Projektet gick ut på att jobba fram en exemplifierad eller principiell lösning för hur man på ett fungerande sätt skulle kunna ersätta RTU med PDA eller PC via USB.

Just momentet USB gjorde arbetet svårt att planera då varken vi som jobbat med det, vår handledare på Alstom eller på skolan hade någon direkt uppfattning om hur omfattande USB programmering är. Därför blev själva konstruktionsfasen svår att uppskatta i tid. Utöver detta har arbetet flutit och motgångar har vägts upp med medgångar. Det vi har kunnat konstatera av arbetet är att just programmering och lösning av logiska problem ofta tar längre tid än man förväntat sig. Något mer vi har

(27)

insett under arbetets gång är att dokumentation bör göras över allt man gör parallellt med själva arbetet. Små minnesanteckningar och tankegångar har räddat arbetet och gjort det enklare under arbetets gång. Dessa anteckningar, tankar och genomgående studier ligger som grund för denna rapport.

6.2 RESULTAT

Inledningsvis under detta examensarbete satte vi 3 delmål med prioritet att uppnå första målet nämligen sätta upp en fungerande USB-länk mellan processor och PC.

Detta är löst genom en s.k. ”vendor-specific” USB-enhet som dock kräver att man konstruerar en egen drivrutin då Windows 9x/2000/XP/CE ej har direkt stöd för dessa enheter och dess funktion i standard utförande. För att kunna testa den nyligen uppsatta kommunikationen ställdes ett krav på en enkel drivrutin som dels kunde svara mot den descriptor och en endpoints vi definierat för USB-länken och dels krävdes det ett enkelt men funktionellt program som gav oss möjlighet att skriva till och lyssna på enheten.

Detta löste vi med hjälp av ett program som vi fann på Internet. Programmet heter Windriver och var en 30 dagars version. Detta program hjälpte oss att generera en .inf fil och ett väldigt grundläggande program skrivet i C# med vars hjälp vi kunde testa funktionen.

Det resultat som kom ut av våra tester och teorier var kan anses stämma överens med delmål ett som sattes upp. En fungerande USB-kommunikation som kan läsa och skriva till och från PC/PDA. I demonstrationsyfte är även ett RS-232 gränssnitt konfigurerat för att kunna påvisa funktionen hos USB-länken och processorns arbetssätt och kapacitet. Lösningen är en konceptuell modell av hur en Fläktbuss till USB lösning skulle kunna gå till.

6.2.1 Lösningens svagheter

Den lösning som vi kan presentera är en konceptuell modell av hur man kan kommunicera med USB och seriellt inteface. Dock har denna lösning en svaghet som vi inte hunnit behandla. Det handlar om ett realtidsproblem som uppenbarar sig genom att bytes i paketen byter ordning, annars är detta en tillsynes felfri modell.

Ett överföringstest av större datamängder visar att efter åtskilliga bytes data som skickas uppstår en förskjutning i ordningen på dessa bytes. D.v.s. paketen som skapas för USB, kommer alltså inte att innehålla korrekt information utan innehålla data från två olika Fläktbuss-paket.

Det troliga problemet är att sändarbufferten på testbordet blir ”överbelastad”

eller full och det blir ”buffer overflow”. Detta kommer att innebära att den sista byten kommer att skrivas över av första byten i nästkommande ram. Det paket som sedan skickas ut på USB blir därmed felaktigt. Detta förstör inte själva Fläktbuss kommunikationen eftersom Fläktbuss nätet är konstruerat så att om en ram inte kommer fram så sänds den automatiskt om på Fläktbuss nätet.

Själva problemet kvarstår ju ändå även om det i teorin inte borde påverka funktionen i vår lösning. En möjlig lösning bör kunna vara att modifiera storleken på de buffertar som behandlar datan samt att modifiera timer-funktionerna som styr själva programmet.

Båda dessa lösningar kräver djupare och mer ingående analys och förståelse för processorn och dess struktur, vilket ej har hunnits med att erhålla under detta examensarbete. Djupare förståelse bör kunna resultera i att fortsättningen på detta

(28)

6.3 EGET OMDÖME

Uppgiften som vi tilldelades av Alstom såg vi från början som något avlägset och komplicerat som krävde en stor insats. Och en stor insats inte minst med research och förberedande jobb har krävts. Vad man däremot upplevde efterhand var att lösningen och teknikerna som har nyttjas har krupit allt närmare vår utbildning. Detta har gjort att uppgiften blivit mer och mer intressant ju längre och djupare vi tagit oss. Vår uppfattning från början var att USB var ett komplicerat och tekniskt svårt sätt att kommunicera. Men tekniken har mycket gemensamt med både dagens Ethernet och gammal teknik som RS-232. Vilket gör att man kunde nyttja mycket utav den kunskap vi tagit till oss under vår utbildning.

Att däremot lämna uppgiften och inte direkt få fram, ett för ändamålet konkret exempel med tillhörande Fläktbuss implementering, känns lite vemodigt. Men i det stora hela att jobba med projektet och dess utformning och upplägg har givit oss nya erfarenheter och en ny syn på oss själva och vad vi faktiskt lärt oss på universitetet.

(29)

7 REFERENSER

Internet – www.xat.nl/en/riscos/sw/usb/class.htm

Internet – www.usb.org/developers/

Site sponsored by USB Implementers Forum, Inc., creators of USB technology.

Internet – en.wikipedia.org/wiki/USB

Internet – www.smallformfactors.com – USB fundamentals 101 Joel Huebner, Jacyl Technology, Inc.

Whitepaper – USB specification 2.0 2000-04-21

(30)

Appendix A – Generell USB kod LPC_USB.c

/*************************************************************************

*

* Used with ICCARM and AARM.

*

* File name : lpc_usb.c

* Description : usb module (HAL) *

* History :

* 1. Data : June 13, 2005 * Author : Stanimir Bonev * Description : Create

* 2. Data : August 4, 2005 * Author : Stanimir Bonev * Description : Modify

* Modify some functions

* 3. Data : November 18, 2005 * Author : Stanimir Bonev * Description : Modify

* Add DMA support

* 4. Data : December 9, 2005 * Author : Stanimir Bonev * Description : Modify

* Fix DMA restart problem for IN EPs * 5. Data : December 20, 2005 * Author : Stanimir Bonev * Description : Modify

* Change user function prototype * $Revision: 1.2.4.1 $

**************************************************************************/

#define LPC_USB_GLOBAL

#include "lpc_usb.h"

UsbDevStat_t USB_DevStatus;

UserFunc_t UsbUserFun [UsbLastEvent] = {

// Ep 0 Out NULL, // Ep 0 In NULL, // Ep 1 Out NULL, // Ep 1 In NULL, // Ep 2 Out NULL, // Ep 2 Int NULL, // Ep 3 Out NULL, // Ep 3 In NULL, // Ep 4 Out NULL, // Ep 4 In NULL, // Ep 5 Out NULL, // Ep 5 In NULL, // Ep 6 Out NULL, // Ep 6 In NULL, // Ep 7 Out NULL, // Ep 7 In NULL, // Ep 8 Out NULL, // Ep 8 In NULL, // Ep 9 Out NULL, // Ep 9 In NULL,

// Ep 10 Out NULL,