BlueBoard Blåtandstangentbord till PalmV

Transkript

1 BlueBoard Blåtandstangentbord till PalmV Tobias Vesterlund Pedagoggränd 1A-110, SE Umeå, Sweden Phone: +46 (0) (0) Sammanfattning I och med att handdatorers prestanda ökar, blir behovet av att kunna skriva in mycket text också större, mer än vad som är möjligt med ett virtuellt tangentbord eller textigenkänning. För att inte begränsa mobiliteten med kablar, så är ett trådlöst tangentbord att föredra. Detta projekt är inriktat på att utveckla en tangentbordsprototyp för en PalmV handhållen dator genom att använda Blåtandsteknologin. Blåtand är en standard för korthållskommunikation med mobila och/eller fasta enheter. Denna uppsats introducerar läsaren till Blåtand och Palms operativsystem. Lösningar till problem som till exempel att nå Blåtandsenheten från alla applikationer, presenteras. Arbetet fokuserades på att programmera en drivrutin på Palm och på Blåtandskommunikationen. Resultatet är en fungerande, icke fristående tangentbordsprototyp. Klientprogramvara kan lätt överföras till andra enheter.

2 Abstract The increase of process power in handheld computers implies a greater need to input text. The available input methods are slow and requires learning time. To increase mobility, a wireless keyboard is to prefer. This project aims to develop a keyboard prototype for the PalmV handheld computer using the Bluetooth technology. Bluetooth is a standard for short range wireless communication between mobile and/or stationary devices. This paper introduces the reader to Bluetooth and the Palm operating system, it also solves problems such as accessing the Bluetooth module from all applications. The main focus is coding the driver on the Palm and the Bluetooth communication. The result is a functional, nonstandalone keyboard prototype. The client driver is easily ported to other devices. 2

3 1. Inledning Bakgrund Problembeskrivning Metodbeskrivning Blåtand Nätverkstopologi Lager Radiogränssnittet Basbandsgränssnittet LMP "Link Manager Protocol" HCI - "Host Controller Interface" L2CAP "Logical Link Control and Adaption Protocol" Säkerhet SDP - "Service Discovery Protocol" Blåtand, ett praktiskt exempel Palm Bakgrund Skillnader mot PC Viktiga delar Minnesarkitektur Händelser Seriekommunikation Grafiskt användargränssnitt Genomförandebeskrivning Seriekommunikation Palm PC Blåtand Palm OS Portning PC till Palm

4 Diverse Musfjärrkontroll PC Programmeringstekniska detaljer Körning av funktion oavsett applikation Teckenpaket Data Manager Resultat Diskussion Blåtand Undervisningsmöjligheter Tangentbord redo för uppkoppling? Skall tangentbordet vara ständigt uppkopplat? Hur skall pairing av enheter ske? Palm OS Problem vid patchning av operativsystemet Kommunikation med användaren utanför den egna applikationen Utökad uppgift: Fristående tangentbord Slutsatser Tack

5 1. Inledning Det här examensarbetet utfördes under hösten 2000 på företaget Tritech Mobile Applications (tidigare Tritech Wireless) i Solna, Stockholm. Uppgiften går ut på att konstruera ett trådlöst tangentbord till en handdator, i det här fallet en PalmV Bakgrund Till många av dagens handdatorer har man på grund av krav på vikt, storlek och batteritid valt bort möjligheten att mata in text med hjälp av ett vanligt tangentbord. I stället sker textinmatning med ett virtuellt tangentbord eller med hjälp av teckentolkning på datorns tryckkänsliga skärm. Detta fungerar tillfredsställande i många lägen, till exempel vid inmatning av adressuppgifter och bokning av möten. I och med att prestanda och lagringskapacitet på handdatorer ökar skulle de också kunna användas till tyngre uppgifter och i vissa lägen kunna ersätta en bärbar dator. Om det är stora mängder text som skall matas in skulle detta underlättas mycket med ett riktigt tangentbord. Samtidigt som man önskar använda ett vanligt tangentbord vill man inte begränsa mobiliteten med fysiska anslutningar. Detta leder till behovet av en trådlös förbindelse, det är här Blåtand kommer in i bilden. Blåtand är en ny teknik för radiobaserad trådlös kommunikation mellan mobila och/eller fasta enheter inom små avstånd, 0-10 meter. Teknologin använder sig av det olicensierade 2.45GHz bandet, målet är att Blåtand skall bli en global standard. Bland grundarna finner man Ericsson, IBM, Intel, Nokia och Toshiba [EBDK99]. Framtiden för Blåtand ser ljus ut, marknadsundersökningar visar att vid år 2006 kommer 60% av alla nyckelelektronik-produkter vara mobila. Blåtand förutsägs inbringa mellan miljarder dollar (ca miljarder kronor) år 2004 [TCBT00]. Detta gör att Tritech vill lära sig mer om Blåtand och dess möjligheter. Denna rapport inleds med en problembeskrivning och metodbeskrivning i kapitel 2 och 3. Därefter följer i kapitel 4 en grundläggande genomgång av hur Blåtand fungerar. Kapitel 5 tar upp skillnader mellan Palm och PC och några andra viktiga detaljer för detta projekt. Därefter följer en genomförandebeskrivning på ganska hög nivå. I det avsnittet tas några av de problem som uppstod under projektets gång upp. Kapitel 7 behandlar lösningen till dessa problem mer detaljerat. Kapitel 8 beskriver resultatet. Efter det följer ett diskussionskapitel där några speciella frågeställningar tas upp. Därefter följer slutligen 5

6 slutsatser av utfört arbete, lite mer om vad som återstår att göra samt rekommendationer för framtiden. 6

7 2. Problembeskrivning Uppgiften består i att ta fram en prototyp på ett system som omvandlar tangenttryckningar från ett vanligt tangentbord till Blåtandspaket, som skickas trådlös till mottagarsidan, en PalmV. Palmen omvandlar paketet till vanliga tangenttryckningar och skickar dessa till sitt operativsystem. PC Serie palm Tangentbord Blåtand Blåtand Serie Figur 2.0: Prototypuppsättning Arbetet delas med fördel upp i två deluppgifter, som i sin tur kan delas upp i mindre delar. I grunduppgiften, den första deluppgiften, är det lämpligast att använda en vanlig persondator för att ta emot tangenttryckningar från tangentbordet (se Figur 2.0). Förutom att ta emot tecken från tangentbordet ansvarar programmet i persondatorn även för att starta en Blåtandsuppkoppling mot mottagarsidan, paketera tecknen och skicka iväg dem. Kommunikationen mellan dator och Blåtandsenheten sker seriellt. På den andra sidan kommunicerar Palmen via Blåtandsenheten, även den seriellt. Programmet i Palmen initierar Blåtandsuppkopplingen och tar emot paket som den andra sidan skickat, tar fram tecknen som skickats och skriver ut dem i textfältet i programmet som är aktivt. 7

8 Tangentbord Blåtand Blåtand Palm Serie Anpassad hårdvara Serie Figur 2.1: Utökad uppgift I den utökade uppgiften införskaffas anpassad hårdvara med tangentbordsingång samt RS232 gränssnitt (se Figur 2.1). I den utökade version av uppgiften tillkommer att skriva tangentbordsdrivrutiner. Största kraften i detta projekt kommer att läggas på första deluppgiften, eftersom tiden antagligen inte räcker till för den utökade uppgiften. Den inledande versionen kan delas in i olika mindre steg: 1. Skicka tecken seriellt från PCn till Palm, så att de skrivs ut i mottagarprogrammet. 2. Skriva ut tecknen som tas emot på Palmen i det program som körs för närvarande, istället för det egenhändigt skriva mottagarprogrammet. 3. Få igång en blåtandsuppkoppling mellan två persondatorer. 4. Få igång en blåtandsuppkoppling mellan en persondator och Palmen. 5. Färdigställa det kompletta programmet. Förutom detta tillkommer steg såsom rapportskrivning. För att genomföra uppgiften kommer jag att återanvända vissa delar av mjukvaran från ett tidigare examensarbete skrivet av Rebenius och Andersson [KA00]. De har implementerat HCI (4.2.4 HCI - "Host Controller Interface ) i C, samt delar av L2CAP (4.2.5 L2CAP "Logical Link Control and Adaption Protocol ). 8

9 3. Metodbeskrivning För att lösa uppgiften så smidigt som möjligt valdes att dela upp den i mindre delar som tidigare nämnts. Inledningsvis så behövdes en stor del inläsning, svårigheten låg mest i att veta vilka delar av den 1082 sidor tjocka Blåtandsspecifikationen som skulle läsas. Det visade sig att det mest intressanta för detta projekt var basbands- och HCI-lagren (Se 4 Blåtand). Val av programmeringsspråk visade sig inte vara speciellt svårt. Två teknologer på Tritech hade tidigare skrivit en egen Blåtandsstack i C. C finns även för Palm OS och det underlättar mycket då koden skulle portas från PC till Palm, därför föll valet av programmeringsspråk på C. Det finns kommersiella Blåtandsstackar att köpa, fast de är mycket dyra och passar ej ett examensarbete av den här storleken. Under projektets gång visade det sig att bland annat företaget Axis utvecklar en open source - kodsblåtandsstack under GPL-avtalet ( GNU Public Lisence ). Detta betyder att källkoden är öppen och fri för vem som helst att använda. En nackdel är att om man portar den till Palm måste den ändrade källkoden släppas fri till alla, vilket kan medföra konkurrensnackdelar. En annan nackdel är att Axis Blåtandsstack omfattar hela stacken, inkluderat de övre lagren. Stacken som teknologerna på Tritech gjort innefattar enbart de viktigaste och nödvändigaste funktionerna, vilket gör det lättare att porta till Palm OS eftersom det kräver mindre arbete. För större (kommersiella) projekt måste man dock diskutera vilken typ av Blåtandsstack som lämpar sig bäst för just det projektet. Som utvecklingsmiljö på Palmen valdes CodeWarrior, detta eftersom den har en inbyggd debugger, en emulator och en dra-och-släpp avdelning för att bygga användargränssnitt. Vidare fanns redan kunskap om CodeWarrior inom Tritech vilket underlättade projektets genomförande. Innan programmeringen påbörjades fanns relativt klara planer om vad som skulle utföras rent praktiskt vid användandet av tangentbordet. Tanken var att användaren skulle starta en Palmapplikation, som kopplar upp sig mot tangentbordet, och sedan bara använda tangentbordet som vanligt. Eftersom det var känt att bara en applikation åt gången kan köras i Palmen måste läsningen från serieporten lösas med interrupt eller pollning. Interrupt är att föredra eftersom det kräver mindre kapacitet av processorn. Tanken till 9

10 en lösning var att så fort något kommer in på serieporten, anropas den egna funktionen som packar upp Blåtandspaketet, och skriver ut det i aktivt fält i aktivt applikation. Under projektets gång visade det sig att ett flertal problem måste överkommas, och vissa kompromisser måste göras för att få allt att fungera tillfredsställande. Mer om detta efter en genomgång av Blåtand och Palm OS. 10

11 4. Blåtand När mobila enheter blir mindre, smartare och kan utföra fler saker, ökar behovet av att på ett enkelt sätt kommunicera med andra enheter. Som det varit hittills har en mängd olika sätt att överföra information funnits. När man väl funnit det rätta sättet, måste mjukvarorna i de två enheterna kommunicera. Det har kort och gott varit ganska omständigt. I många fall har det varit i stort sett omöjligt att koppla upp sin PDA (Personlig Digital Assistent) mot till exempel nätverket på jobbet. Seriell överföring (RS232) har funnits länge, men är långt ifrån en standard och kräver kablar. IrDA, som använder sig av infraröd teknik, klarar hög överföringshastighet och är trådfritt, men kräver fri sikt och klarar bara punkt-till-punkt uppkopplingar. Det är här Blåtand kommer in. Blåtand arbetar med radio på en våglängd av GHz som finns tillgängligt över hela världen. Den har konstruerats med robusthet, låg komplexitet, låg effekt och låg kostnad i tanke. Till en början ligger priset på ungefär 20 dollar, men beräknas minskas till ungefär 5 dollar per enhet. Enheten i sig är liten och kommer att kunna byggas in i de flesta enheter som kommer att använda sig av den. På grund av den låga uteffekten och höga våglängden är avståndet begränsat till 10 meter (100 meter med högre uteffekt). Radiovågorna stoppas även av väggar och tak. Idén med Blåtand är att man på kort håll skall få en hög, säker överföring. Exempel på användningsområden är att man med sin laptop kan komma ut på Internet utan att behöva plocka upp telefonen ur väskan. Hörlurar, digitala kameror, skrivare, PDAer och faxar hör till andra givna användsområden. Binär FM-modulation används för att minska komplexiteten i radiodelarna. Standarden använder sig av frekvenshoppning, vilket betyder att ett paket data sänds, sedan byts frekvens varvid nästa paket skickas, frekvensen byts, ytterligare ett paket skickas, och så vidare (mer om detta i Fysisk kanal). Blåtandsprotokollet använder sig av en kombination av kretskopplad och paketväxlad kommunikation. Upp till tre synkrona röstkanaler kan köras samtidigt, alternativt en kanal som samtidigt stöder en asynkron datakanal och en synkron röstkanal. Varje röstkanal stödjer 64Kbit/s synkron överföring i vardera riktning. Den asynkrona kanalen stödjer upp till 723.2Kbit/s asymmetriskt (åt ett håll, trots detta går det att köra 57.6Kbit/s åt andra hållet), eller Kbit/s symmetriskt. 11

12 Följande avsnitt kommer att ta upp hur kommunikationen mellan Blåtandsenheter fungerar. Andra saker som kommer att tas upp är vissa viktiga paketstrukturer, och vissa arkitektuella delar. Röstöverföring är utanför denna rapports täckning och kommer därför bara att tas upp översiktligt Nätverkstopologi Blåtandssystemet tillhandahåller punkt-till-punkt uppkoppling (bara två enheter inblandade), eller multi-punkt uppkoppling, se Figur 4.0. I en uppkoppling med bara två enheter agerar den ena enheten master, och den andra slav. Normalt är det enheten som tar initiativ till uppkopplingen som blir master. I multi-punkt uppkopplingen är kanalen delad mellan ett flertal Blåtandsenheter. Två eller flera Blåtandsenheter bildar ett Piconät. I ett Pico-nät kan upp till sju slavar vara aktiva samtidigt. Förutom detta kan dock många fler slavar vara låsta mot mastern i ett så kallat Parkläge ( Parkläge). Om flera Pico-nät överlappar varandra formas något som kallas ett scatternet. Varje Pico-nät kan bara ha en master, men en slav kan vara delaktig i flera Pico-nät samtidigt med hjälp av tidsdelning, det vill säga att lika stor del av tiden reserveras till vardera nät. En logisk följd vid denna tidsdelning är en något sämre prestanda i vardera näten. Förutom att en slav kan vara med i flera nät, kan varje master även vara slav i ett annat nät samtidigt. Varje Pico-nät har sin egen hoppkanal. I den nuvarande specifikationen finns det bara stöd för punkt-till-punktuppkopplingar. Figur 4.0: Pico-nät med enkel-slav (a), multi-slav (b) och scatternet (c) 12

13 4.2. Lager Blåtand är uppdelad i olika lager, där nedersta lagret motsvarar radiokommunikationen och det översta mer applikationsnära lager, till exempel TCP/IP, Se Figur 4.1. Vissa lager är av mer intresse för denna uppgifts skull än andra, så basbandslagret och Host Controller Interface (HCI) tas här nedan upp mer i detalj. Figur 4.1: Lager och referenser till Blåtandsspecifikationen [SBS99] Radiogränssnittet Eftersom modulation av radiovågor med mera inte av direkt intresse i detta arbete utelämnas denna del helt. Se [SBS99] sid 15 för mer information Basbandsgränssnittet Basbandet är den digitala delen av Blåtandsmodulen. Den kontrollerar en mängd saker såsom: radio, klocka, radio frekvenser, frekvenshopp och hoppsekvens. En genomgång av basbandet följer nedan. 13

14 Fysisk kanal Som tidigare nämnts opererar Blåtand i 2.4 GHz bandet. Trots att frekvensen finns tillgänglig globalt i hela världen skiljer det sig hur mycket bandbredd som finns tillgängligt och exakt var i frekvensområdet den befinner sig. I Europa och USA finns ett band som är 83.5 MHz brett tillgängligt, detta ger 79 stycken kanaler som är separerade med 1 MHz. I andra länder såsom Japan och Spanien är ett smalare band tillgänglig; så att det räcker till 23 radiokanaler 1 MHz separerade. En kanal representeras av en pseudo-slumpad hoppsekvens mellan de 79 (eller 23) radiokanalerna. Hoppsekvensen är som sagt unikt för varje Piconät, och bestäms av adressen som mastern i nätet har. Var i hoppsekvensen man befinner sig bestäms av klockan i mastern. Frekvenshoppen sker med upp till och med 1600 hopp/sekund. Varje kanal är indelade i tidsluckor som är 625µs långa. Varje lucka är numrerade enligt piconetmasterns klocka. Det är i tidsluckorna som mastern och slaven kan överföra paket. Ett Time-Division Multiplex (TDD), tidsmultiplexat system används där mastern och slaven överför i tur och ordning (Figur 4.2). Mastern startar överföringen endast i jämna luckor, och slaven endast i ojämna luckor. Paketet överförs direkt i början av luckan. Figur 4.2: Time Division Multiplex och timing När ett paket överförs måste frekvensen vara densamma under hela paketets längd. Frekvensen som används fås från masterns klocka. Om man har ett längre paket kan det vara nödvändigt att använda flera tidsluckor efter varandra, frekvensen för de upp till fem 14

15 tidsluckorna (max antal luckor enligt specifikationen), bestäms av masterns klocka i den första tidsluckan. Se Figur 4.3 för en illustration av hur paketöverföringen sker och hur det ser ut med multitidsluckepaket. Figur 4.3: Singel och multitidsluckspaket Fysiska länktyper Det finns två typer av länkar (det vill säga typer av uppkopplingar): Synchronous Connection-Oriented (SCO) link Asynchronous Connection-Less (ACL) link Den förstnämnda är en synkron kopplingsorienterad uppkoppling, och den andra är asynkron ickekopplad uppkoppling. Man skulle kunna jämföra SCO med ett telefonsamtal, man ringer upp en person, och linjen är helt reserverad för samtalet. ACL kan jämföras med pakettrafiken över Internet; man har ingen ständig uppkoppling utan överföring sker med hjälp av paket som sätts ihop på mottagarsidan. Många kan dela på samma linje med hjälp av tidsdelning. Synchronous Connection-Oriented link SCO länken är symmetrisk mellan en master och en slave och den reserverar tidsluckor för överföringen. Detta garanterar att paket kommer fram vid rätt tidpunkt, vilket är viktigt i realtidsapplikationer, som till exempel talöverföring. SCO paket blir dock aldrig omsända, så det finns ingen garanti att de kommer fram korrekta. 15

16 En slave kan samtidigt ha tre stycken SCO länkar till samma master, alternativt två SCO länkar om de kommer från två olika masters (Figur 4.4). Figur 4.4: Max antal SCO(audio)-uppkopplingar Eftersom SCO länkar inte används i det här projektet kommer de inte närmare diskuteras. Se [SBS99] kapitel 3.2 sid för mer detaljerad information. Asynchronous Connection-Less link I tidsluckor som inte är reserverade av SCO länkar kan mastern utväxla paket med slaven. Det kan bara finnas en ACL länk mellan en master och en slave åt gången. För de flesta typer av ACL paket används återsändningar för att garantera en felfri överföring. En slav kan bara skicka paket till mastern i slav-till-master tidluckorna, och enbart om den har blivit adresserad i föregående master-till-slav tidlucka. Om slaven misslyckas med att avkoda slavadressen i pakethuvudet i paketet från mastern (till exempel på grund av fel i överföringen), så får den inte skicka. Om mastern i ACL länken inte behöver skicka några paket, så skickar den emellanåt POLL paket, detta bland annat för att kolla om slaven har något att sända. ACL paket som inte är adresserade till en specifik slav är så kallade broadcast paket, det vill säga att de är adresserade till samtliga slavar som är uppkopplade. Slavar får inte returnera något paket om mastern skickar ut ett broadcast meddelande (Ett undantag finns, se [SBS99] kapitel , sid 115) Basbandspaketen All data i Blåtand skickas i paket. För att förstå Blåtand i stort är det inte absolut nödvändigt att förstå hur paketen är uppbyggda, men för de som är intresserade går det att läsa om detta i Bilaga B: Basbandspaketen ACL pakettyper För att klara av olika förhållanden och Quality of Service (QoS) har sju olika ACL-paket definierats. Dessa kan användas för att bära data eller kontrollinformation. Sex av de 16

17 olika pakettyperna inkluderar CRC 1 kod för felkontroll, enbart AUX1 paketet har inte det och är därmed det enda paket som inte skickas om vid fel. Pakettyp Antal tids- Nyttolast FEC 2 Symmetrisk Max. Asymmetrisk Max. hastighet Overhead 3 I (%) luckor (bytes) hastighet (Kb/s) (Kb/s) Framåt Bakåt DM / DH No DM / DH No DM / DH No AUX No Tabell 4.0: ACL paket DM står för Data - Medium rate. DM1-paketet överför enbart data. Den innehåller upp till 18 byte användardata (inklusive en byte för nyttolast-huvudet) plus en 16 bitars CRC kod. Informationen (användardatat) och CRC-koden är kodad med 2/3 FEC ( Felkorrigering), och det blir därmed lite mer overhead (ej nyttig information). Fördelen är att om någon information skulle försvinna i överföringen på grund av någon störning, så finns det möjlighet att få tillbaka den genom FEC kodningen. DH står för Data High rate, och skillnaden gentemot ett DM paket är att nyttolasten inte är FEC kodad och den kan därmed överföra mer nyttig data. Siffran efter DM och DH anger hur många tidsluckor som paketet tar upp. Hur mycket nyttig data varje pakettyp kan överföra kan man se i Tabell 4.0. Förutom ovanstående paket finns det även SCO paket, se [SBS99] kapitel 4.4.2, sid Observation Feltoleransen i Blåtand (Bit Error Rate, BER) är viktig att ha i åtanke då man designar ett Blåtandssystem. Enligt specifikationen ska BER vara <= 0.1% ([SBS99] kapitel 4.2, sid 24) på högsta avståndet (Naturligtvis kan BER vara mindre än 0.1% trots att det är maximivärdet i specifikationen). Som tidigare nämnts finns det olika typer av paket, till exempel DH3 eller DH5, som innehåller ca 1500 respektive 2700 bitar. Med en BER på 1 Cyclic-Redundancy-Check, metod för att upptäcka fel 2 FEC: "Forward Error Correction", Felkorrigering 3 Antalet extra bitar delat med det totala antalet bitar för paketet. 17

18 0.1%, det vill säga att en av tusen bitar är felaktigt överförd; konsekvensen blir att dessa paket kommer att skickas om i all oändlighet. Botemedlet mot detta problem är givetvis att använda sig av mindre paket, eller ha mycket goda radioförhållanden Gemensamma pakettyper Fyra pakettyper är gemensamma för både ACL och SCO: ID, NULL, POLL och FHS. ID NULL POLL FHS ID paketet används till exempel vid paging, inquiry och svarsrutiner NULL paketet har ingen nyttolast, det används till att överföra information om flödeskontroll (FLOW) och felhantering (ARQN). Om en slav får ett POLL paket måste den svara i nästföljande tidslucka. Detta paket blir en implicit bekräftning av POLL paketet. Paketet kan används av masters i ett piconät för att polla slavarna även om de inte har någon information att sända. FHS paketet är ett speciellt paket som överför bland annat Blåtandsadressen och klockan på sändaren. Det används vid uppstart för att mastern och slaven skall få igång en kommunikation på samma frekvenser. Tabell 4.1: Gemensamma pakettyper Felkorrigering Det finns tre olika typer av felkorrigering i Blåtand: 1/3 FEC (Forward-Error-Correction) 2/3 FEC ARQ för data FEC Syftet med FEC kodningen är att minska antalet omsändningar. Om förhållandena är goda är FEC ibland inte nödvändigt, därför finns DH-paketen som inte har FEC kodning. Pakethuvudet är dock alltid skyddat med en 1/3 FEC kodning, detta på grund av att den innehåller viktig länkinformation och därför behöver extra skydd. Den enklaste FEC kodningen är 1/3, den fungerar helt enkelt så att varje bit repeteras 3 gånger. Bit 0 tre gånger, Bit 1 tre gånger, och så vidare. 18

19 2/3 FEC är lite mer komplicerad, det är en (15,10) förkortat Hammering kod. Se [SBS99] kapitel 5.2 sid för mer information om den. ARQ ARQ står för Automatic Repeat Request scheme. DM, DH och DV (SCO paket) har automatisk omsändning genom att använda ARQ. Det fungerar så att alla paket är omsända tills de fått en positiv bekräftelse på att överföringen lyckades, CRC används för att kontrollera om den överförda informationen är korrekt. ARQ schemat fungerar enbart på nyttolasten i paketen Felupptäckt För att undersöka om paket är felaktiga eller fellevererade används Channel Access - koden som finns i basbandspaketet, Header-Error Correction (HEC) (se Bilaga B: Basbandspaketet) i huvudet, eller CRC på nyttolasten. Vid mottagning av ett paket undersöks först accesskoden så att inte paketet är skickat till något annat piconät än det nät enheten befinner sig i. Sedan kollas både HEC och CRC för fel. För mer detaljerad information om HEC och CRC se [SBS99] kapitel 5.4, sid Uppkoppling av Blåtand Stegen för att skapa en Blåtandsuppkoppling kan sammanfattas såhär: 1. Initiering av Blåtandsenheter 2. Inquiryfas upptäckt av enheter inom radioavstånd 3. Uppkoppling, inkluderat Page fas 4. Data och/eller röstöverföring 5. Nedkoppling Av ovanstående steg är det steg 2 och 3 som närmare behöver förklaras. Inquiryfasen Det första steget efter att ha initierat enheterna är att skapa en uppkoppling. Detta sker i inquiryfasen. En enhet som väntar på att bli upptäckt går periodiskt in i något som kallas inquiry scan state, där den lyssnar efter ett inquirymeddelande från någon master. Enheten skannar över 32 olika hoppfrekvenser och när den upptäcker en IAC ( Inquiry Access Code ) kan den svara till mastern som skickat ut förfrågan. Som svar skickar slaven ett FHS-paket som innehåller dess adress och värde på klockan. Mastern skickar ID-paket kontinuerligt över ett antal hoppfrekvenser och skannar efter svar efter varje överföring. Den behöver inte bekräfta de svar den får från slavar (FHS-paketen), utan 19

20 fortsätter skanna efter andra enheter tills dess att det avslutas av Link Managern (tillräckligt många svar inkomna) eller att det blir en timeout. Pagefasen Efter att mastern fått ett Frequency Hop Sequence -paket (FHS) från en slav i inquiryfasen kan en uppkoppling ske. Pagingproceduren är väldigt lik inquiryproceduren. I den här fasen försöker mastern approximera slavens klocka, och använder den för att börja skicka ID-paket som innehåller slavens adress. För att vara säker på att hitta slaven använder mastern en 10 ms långt tåg som består av 16 tidsluckor på olika frekvenser. Tåget innehåller uppskattningen, åtta föregående frekvenser och sju efterföljande frekvenser. Om inte detta skulle räcka läggs ännu ett tåg till, med 16 nya frekvenser, 8 på varje sida av det första tåget för att täcka ett större frekvensomfång än tidigare. Slaven är i sitt Page Scan läge, och lyssnar efter sin Device Access Code (DAC), det vill säga efter en pageförfrågan från mastern. Slaven stannar på en hoppfrekvens i minst 18 på varandra följande tidsluckor när den lyssnar efter sin DAC. Frekvensen den lyssnar på får den fram från sin adress (BD_ADDR) och den lokala klockan. Var 1.28 sekund byter den frekvens. Så fort slaven känner igen sitt eget ID-paket svarar den. Då den svarat skickar mastern ett FHS-paket där slaven får masterns klocka och Blåtandsadress. Efter detta tilldelar mastern en aktiv medlemsadress till slaven, denna adress används i återstoden av kommunikationen. Efter allt detta har skett kan slaven börja hoppa tillsammans med mastern. För mer information se [SBS99] kapitel 10.6, Steg Meddelande Riktning Hoppsekvens DAC och klocka 1 Slave ID Master till Slave Page Slav 2 Slave ID Slave t. Master Page svar Slav 3 FHS Master t. Slave Page Slav 4 Slave ID Slave t. Master Page svar Slav 5 1a paket master Master t. Slave Kanal Master 6 1a paket slave Slave t. Master Kanal Master Tabell 4.2 : Meddelanden under uppstart LMP "Link Manager Protocol" Länkunderhållaren är ansvarig får att sätta upp länkar, samt för säkerhet och kontroll. Link Manager -meddelanden har högre prioritet än användardata och skickas i 20

21 nyttolasten istället för det vanliga datat. Meddelanden mellan länklagren i två enheter filtreras ut i mottagarsidan och skickas inte upp till högre lager. Då Blåtandsenheter är uppkopplade kan de gå in i olika lägen: "activeläge, "holdläge, "sniffläge och "parkläge. Nedan följer en kort förklaring vad de olika lägena innebär, för mer information om dessa se [SBS99] med start sid 113. Mer information om LMP förutom nedanstående finns i [SBS99] kapitel C, sid Activeläge I det aktiva läget deltar Blåtandsenheten aktivt på kanalen. Mastern schemalägger all överföring till slavarna. Aktiva slavar lyssnar i master-till-slave luckorna för att se om de får några paket. Om de inte får något paket kan de vila tills mastern skickar igen. Periodiska överföringar från mastern behövs dock för att behålla synkronisationen på kanalen. Detta går lätt att ordna eftersom det görs på CAC som skickas med i alla paket som är skickade av mastern Holdläge En ACL-länk mellan två Blåtandsenheter kan bli ställda i viloläge för en specificerad tid, mastern skickar då inga ACL-paket under denna tid. Holdläget är bra då enheten vet att den inte kommer att överföra några paket på en relativt lång tidsperiod. Radiomottagaren kan då stängas av för att spara energi. Både master och slav kan tvinga den andra att gå in i holdläge, de kan även begära att den andra enheten skall gå in i läget Sniffläge Om en länk är i sniffläge kan mastern enbart överföra information i snifftidsluckorna. Intervallen mellan sniffluckorna kommer mastern och slaven överens om. Båda enheterna måste komma överens om att gå in i sniffläge, och kan även begära att gå in i det. Detta görs genom att ett speciellt paket skickas mellan enheterna Parkläge Om en enhet inte vill delta i kanalen, men fortfarande vill vara synkroniserad frekvensmässigt (hoppmässigt), kan den placeras i parkläge. Slaven återlämnar sin aktiva medlemsadress men kan åter börja delta i kommunikationen vid speciella fördefinierade tillfällen. Då kommunikationen återupptas får enheten en ny medlemsadress. 21

22 HCI - "Host Controller Interface" HCI-lagret är till för att ge ett gemensamt gränssnitt mot Blåtands hårdvarumöjligheter. I detta projekts fall är Blåtandsvärden en PalmV, transportlagret är RS232 och Blåtandsmodulen är själva Blåtandsenheten innehållande firmware (kod för att styra hårdvaran) samt hårdvara. Se Figur 4.5 Andra högre lager Blåtandsvärd Blåtandsmodul (värdkontroller) L2CAP HCI HCI Link Manager Basband Radio Transportlager (USB, RS232..) Figur 4.5: Blåtands mjukvarustack HCI är ett kommandogränssnitt till basbandets funktioner, link managern och till olika värdkontrollregister. 22

23 Figur 4.6: Bild på de lägre lagren för överföring av data HCI är uppdelad i kommandon och händelser. Normalt skickar värden (övre delen Figur 4.5) ett kommando till värdkontrollern (nedre delen i Figur 4.5), när denne utfört kommandot svarar den med en kommandot utförd -händelse eller motsvarande. HCIdrivrutinen konverterar HCI-kommandona till paket som skickas via underliggande lager till Blåtandsmodulen. HCI-paketen gör att lagret blir oberoende av hur kommandona överförs fysiskt, Blåtandsspecifikationen nämner transportlager för USB, UART och RS När paketen väl anlänt till Blåtandsmodulen konverteras paketet tillbaka till HCIpaket. Dessa paket skickas till HCI Firmware, där kommandona tolkas och utförs. Anledningen till att man har definierat händelser beror delvis på att olika HCIkommandon tar olika lång tid. Om inte en händelse skickas tillbaka blir det timeout, i specifikationen står det att den skall vara en sekund som standard Kommandopaket Som bekant skickas kommandon och händelser mellan värden och värdkontrollern (se Figur 4.7). Kommandopaketet som skickas från Palmen till Blåtandsmodulen har ett visst format, se Figur

24 Figur 4.7: Kommunikationen mellan värd och värdkontroller Figur 4.8: HCI kommandopaket Varje kommando påbörjas med en opkod som är två bytes stor. Denna opkod identifierar varje kommando. Opkoden består av två komponenter, först OpCode Group Field (OGF), denna del specificerar vilken grupp av kommandon som det gäller (till exempel Länkkontroll-kommandon, basbands-kommandon etc.). Nästa del, OpCode Command Field (OCF) specificerar exakt vilket kommando i gruppen det gäller. OGF tar upp sex bitar och resterande tio bitar av opkoden tas upp av OCF. Efter opkoden kommer alla parametrar till kommandot. Till att börja med talar den första byten om hur många bytes totalt som följer i parametrarna, alltså inte totalt antal parametrar, utan hur många bytes dessa tar upp. Blåtandsmodulen måste kunna ta emot kommandon med 255 bytes parametrar, plus det tre byte stora huvudet. Som tidigare nämnts svarar Blåtandsmodulen med en "Command Complete Event" då den utfört ett kommando. Till vissa kommandon som tar lite längre tid att utföra görs dock ej detta, utan istället skickas ett "Command Status Event" tillbaka då utförandet av 24

25 kommandot påbörjats. Detta sker till exempel vid inquiry. Så småningom, då kommandot är utfört, skickas en Command Complete Event för att indikera detta. Varje kommando i HCI finns specificerat i [SBS99] sid med kommandoparametrar, returvärden och tillhörande händelser Händelsepaket Utseendet på ett händelsepaket kan ses i Figur 4.9. Varje händelse identifieras med en händelsekod som är en byte stor och kommer i första segmentet av paketet. Parametrarna i paket är individuellt för varje händelse, alla händelser definieras i [SBS99] sidan Figur 4.9: HCI händelsepaket ACL Datapaket Datapaketet används för att skicka data mellan värden och värdkontrollern, i det här fallet Palmen och Blåtandsmodulen. Hur paketen ser ut kan beskådas i Figur Figur 4.10: HCI ACL Datapaket 25

26 Paketen för att utväxla ljud (till exempel tal), SCO-paket, tas inte upp här, se [SBS99] sid för detta. De första tolv bitarna i paketet används för att unikt identifiera en uppkoppling mellan två Blåtandsenheter. PB-flaggan (Packet Boundary) är till för att indikera om paketet är fortsättningsfragment på tidigare paket, eller om det är det första paketet av ett meddelande från högre lager. Broadcast flaggan (BC) sätts till 00 för att indikera en punkt-till-punkt överföring, 01 betyder att meddelandet kommer att skickas till alla slavar (så kallad "active broadcast"), 10 indikerar att paketet kommer att skickas till samtliga slavar, inklusive de som är i parkläge för närvarande ("Piconet broadcast"). Sista delen av pakethuvudet är två bytes som talar om det totala antalet byte i resterande delen av paketet L2CAP "Logical Link Control and Adaption Protocol" Ett designkrav som fanns då man designade L2CAP var att det skulle medföra lite overhead och vara enkelt. Detta på grund av att enheter med små beräkningsmöjligheter skall kunna använda Blåtand. Man kan identifiera fyra huvuduppgifter för L2CAP: 1. Protokoll multiplexering. L2CAP måste kunna skilja mellan övre lagers protokoll som till exempel Service Discovery Protocol, RFCOMM och telefonikontroll. 2. Segmentering och hopsättning. Eftersom storleken på HCI paketen är begränsade behövs det någon som kan ta isär stora paket till hanterbara enheter vilket är en av L2CAPs uppgifter. 3. Quality of Service. L2CAP har hand om att se till att enheterna får den bandbredd med mera som den begär. 4. Grupper. Basbandet har hand om grupper i form av piconät (flera enheter som synkroniserat hoppar efter samma klocka). L2CAPs grupper ger möjligheten att mappa protokollgrupper till piconät. Utan den abstraktionen skulle högre lager behöva tillgång till basbandet och andra lager för att effektivt kunna implementera grupper. Värdkontrollern specificerar den maximala storleken på hur mycket ett HCI-paket kan transportera. I Ericssons nuvarande mjukvara är gränsen på 800 byte, och basbandet kan hantera upp till tio sådana paket. 26

27 Ett exempel på hur segmentering och hopsättning fungerar följer här ett exempel [KA00]: Den lokala värden 1 vill överföra 26 byte med information till värd 2. En uppkoppling mellan de två skapas, och paketvalet för sessionen blir DM1-paket. De 26 byten representerar L2CAP meddelandet och ryms inte i ett DM1-paket. Därför måste det bli skickat i två stycken paket. Detta kan ses i Figur L2CAP Lenght CID L2CAP Payload HCI Connection_handle PB-flag = 10 Lenght HCI data payload Connection_handle PB-flag = 01 Lenght HCI data payload Figur 4.11: Segmentering av L2CAP-paket (ej skalenlig) Det första HCI-paketet inkluderar L2CAP huvudet; längd och CID (kanalidentifierare, 4 byte) och 13 byte data i HCI-paketets nyttolast. Flagga PB (Packet Boundary) sätts till första paketet av ett högre lagers meddelande. Det andra HCI-paketet inkluderar de resterande 13 byten data i HCIs nyttolast. PB-flaggan sätts den här gången till Fortsättning av högre lagers meddelande. På den mottagande sidan (värd 2) kommer mjukvaran att sätta ihop de två HCI-paketen i rätt ordning så att de 26 bytes som ursprungligen skickades fås fram Säkerhet Blåtandsstandarden tillhandahåller två typer av säkerhetsåtgärder: autentisering och kryptering. Autentisering används för att verifiera att motparten i en uppkoppling verkligen är den den utger sig för att vara och inte en inkräktare. Kryptering är processen där data kodas så att ingen annan än den adresserade mottagarenheten kan avkoda det. Andra enheter ska inte kunna förstå informationen som sänds. Enligt Blåtandsspecifikationen [SBS99] anses säkerheten vara tillräckligt god för de flesta applikationer. Det finns dock vissa kritiker av säkerheten i Blåtand, att den inte är 27

28 testad tillräcklig. Kritikerna menar att eftersom Blåtandsenheterna med jämna mellanrum skickar ett unikt id kanske någon kunna spåra hur en person rör sig. Om krypteringen och/eller autentiseringen knäcktes skulle det bli enkelt att avlyssna Blåtandstrafiken. Säkerheten är justerbar med hjälp av en variabel nyckel för krypteringen. Nyckeln kan varieras mellan 1 och 16 oktetter (8-128 bitar). Denna hemliga nyckel genereras då två enheter kommunicerar för första gången. Om ytterligare säkerhet behövs så skall detta implementeras i applikationslagret. Autentiseringen uppnås genom den sparade linknyckeln eller genom att skriva in en PIN-kod. Indirekt ger metoden med hoppfrekvens ytterligare säkerhet, eftersom en avlyssnare måste hoppa exakt likadant som de enheter den vill avlyssna, detta kan vara svårt om inte paketen som skickas i paging-proceduren i början av en uppkoppling också avlyssnats så att avlyssnaren vet hur den ska hoppa. Eftersom säkerhetsaspekten inte berörs i någon större grad i detta projekt utelämnas en noggrann beskrivning, se [SBS99] sidan , för mer information SDP - "Service Discovery Protocol" I Blåtandsstandarden finns det något som kallas Service Discovery Protocol, det protokollet är till för att applikationer ska kunna upptäcka vilka tjänster som finns på enheter i närheten, och karakteristiken på dessa tjänster. En tjänst kan vara många saker, till exempel en skrivartjänst. Karakteristiken på en skrivartjänst kan vara att den klarar av färgutskrifter, postscript eller liknande. Ta som exempel att en affärsresenär på väg till USA kommer på att han behöver skriva ut ett papper. När han vid en övergång då befinner sig i en VIP-lounge så kan han där söka efter en skrivare som klarar färg. Om han hittar en så kopplar han enkelt upp sig och skriver ut sitt papper. För ett personligt tangentbord skulle implementationen av SDP kanske vara lite överflödig, men man skulle kunna tänka sig att tangentbord till PDAer med Blåtandsmöjligheter fanns utplacerade på strategiska ställen, till exempel i vänthallar på flygplatser och liknande. Vem som helst med en sådan PDA/mobiltelefon eller liknande skulle kunna sätta sig vid tangentbordet, söka efter en tangentbordstjänst, hitta tangentbordet och sedan börja använda det. Läs mer om SDP i [SBS99] sid

29 4.5. Blåtand, ett praktiskt exempel Blåtand har beskrivits ganska ingående i tidigare kapitel, men en liten genomgång med mer praktisk inriktning kan vara av intresse, om inte minst för förståelsens skull. För att initiera Blåtandsmodulen skickar man ett antal HCI-kommandon (se Host Controller Interface) från värden (PC/Palm) via seriekabeln till modulen. Initieringen görs på både master och slav-enheten. Kommandona som skickas redovisas i tur och ordning i tabell nedan. Till varje kommando skickas en svarshändelse av något slag, i en del av dessa svarshändelser medföljer även information, som till exempel för kommandot HCI_Read_BD_ADDR returneras den egna Blåtandsmodulens adress i svarshändelsen. HCI_Reset Nollställer Blåtandskontrollern, länk managern och radiomodulen. Enheten går in i väntläge och ursprungsvärden återställs. HCI_Read_BD_ADDR Läs den egna Blåtandsadressen HCI_Read_Buffer_Size Returnerar maximal storlek och maximalt antal paket som kan lagras i HCI buffertarna. HCI_Set_Event_Filter Ställer in vilken typ av enheter som skall komma upp vid inquiry (Alla i närheten, Alla enligt viss klass ( Skrivare ), Någon med viss adress). Går även att ställa in Auto-accept för inkommande uppkopplingsförfrågningar. HCI_Write_Scan_Enable Gör så att Blåtandsradion periodiskt kan gå in i page scan eller inquiry-läge. Om på, så används HCI_Write_PageScan_Activity och HCI_Write_InquiryScan_Activity. HCI_Write_Authentication_Enable Välj om autentisering skall vara på eller av. Påverkar inte nuvarande uppkopplingar. HCI_Write_Connection_Accept_Timeout Det kommer att bli möjligt för Blåtandshårdvaran att neka en uppkoppling efter ett visst specificerat 29

30 HCI_Write_Page_Timeout tidsintervall. Den längsta tid som länk managern kommer att vänta på ett basbandssvar från en annan enhet vid uppkoppling. Tabell 4.3 HCI-kommandon för initiering av Blåtandsmodul Mycket av inställningarna som görs i början är alltså för att ställa in olika timeout-värden, och ställa in filter och liknande. Då initieringen är gjord är nästa steg i uppkopplingen att för den enhet som vill koppla upp sig att söka efter andra enheter. HCI_Inquiry Tala om för Blåtandsmodulen att den ska söka efter andra enheter Tabell 4.4 HCI-kommando för Inquiry Kommandot i tabell 4.4 svarar med två stycken händelser: först svarar den direkt med en händelse som talar om att den har påbörjat inquiry (HCI_Command_Status_Event). När den är klar svarar den med ett HCI_Inquiry_Result_Event event som returnerar information om de enheter den hittat. Vid det här laget känner vi till vilka enheter som finns i närheten, och kan koppla upp oss mot en av dess, detta görs med kommandot i tabell 4.5. HCI_Create_Connection Tala om för Blåtandsmodulen att den ska koppla upp sig mot en viss enhet. Tabell 4.5 HCI-kommando för att skapa en uppkoppling Samma förfarande som i fallet med inquiry sker vid uppkoppling. En svarshändelse skickas direkt då en uppkoppling har påbörjats, så fort detta är klart returneras ett HCI_Connection_Complete_Event som ger information om den andra enheten. När uppkopplingen är gjord skickar man respektive tar emot data med funktioner i L2CAP-lagret. 30

31 5. Palm 5.1. Bakgrund Palm betyder handflata på svenska, och namnet syftar på storleken på denna handdator. Den främsta tanken med en Palm är att den skall användas som en personlig planerare; en avancerad elektronisk filofax. I Palmen finns det program som till exempel almanacka, att-göra-listor och mycket mera. Det finns också möjlighet att installera egna program efter behov. Figur 5.0: PalmV, utvecklingsplattformen i detta projekt Det hela började i Mars 1996 då Pilot 1000 och Pilot 5000 introducerades. Sedan dess har många olika modeller kommit, däribland PalmIII och PalmV. De nyare versionerna som finns för närvarande är Palm m100 och PalmIIIc, där den sistnämnda är med färgskärm. I detta projekt användes en PalmV med Palm OS version 3.3 (Se Figur 5.0). Programmet som utvecklats går även bra att köra i nyare Palm med Palm OS v3.5. Mycket av Palms framgångar beror på att det finns en stor mängd programvara utvecklad, programvara som är utvecklad av fristående programmerare. I Mars 1997 hade Palm ca 2000 registrerade utvecklare, i september år 2000 passerade de stycken. Denna stora mängd programmerare gör att det finns program för de flesta ändamål på Palmen Skillnader mot PC Att programmera för en liten handdator som Palm skiljer sig i många avseenden från att programmera för en stationär dator. Här kommer en redovisning av viktiga skillnader [PalmC]. 31

32 Skärmstorlek En Palms skärm är enbart 160x160 punkter stor, mängden information man kan visa samtidigt är alltså begränsad. Detta är dock inget som det behövs tas någon hänsyn i detta fall eftersom tangentbordet som utvecklas skall användas i befintliga applikationer. Generellt sett är en handdator i Palmens storlek mindre lämpad för redigering av stora textdokument och liknande, eftersom det bara ryms ungefär 5-7 ord/rad. Svarstid På en PC har användaren inte så mycket emot att vänta ett par sekunder på att något skall utföras, eftersom användaren planerar att använda applikationen under en relativt lång tidsperiod. I kontrast till detta använder den genomsnittlige Palmanvändaren en applikation 15 till 20 gånger per dag, endast någon enstaka sekund per tillfälle. Svarstiden är därför av väldigt stor vikt. För att ett tangentbord skall vara användbart även för den som skriver snabbt måste svarstiden hållas nere så mycket som möjligt. Inmatningsmetoder På grund av Palmens begränsade möjligheter till inmatning av text som sker med hjälp av textigenkänning eller med det virtuella tangentbordet är de flesta applikationer utvecklade på ett sådant sätt att stora mängder information inte behöver skrivas in. Med ett externt tangentbord ändras dock detta. Batteri Palm OS plattformen drivs med batteri och har därmed inte samma beräkningskapacitet som en stationär dator. Palmens syfte är inte att utföra stora beräkningar, utan istället bör man utföra beräkningar på den stationära datorn, och eventuellt använda Palmen för att visa resultatet. Det krävs dock inte speciellt mycket beräkningskapacitet för att hantera Blåtandsstacken. Blåtandsmodulen drivs av ett extern batteri. Minne Palm OS har större begränsningar än en vanlig persondator då det gäller heapminne och lagringsmöjligheter. Det finns olika versioner av enheten med mellan 512Kbyte och 8Mbyte minne. Vidare finns ingen hårddisk eller stöd för PCMCIA. Programmen brukar dock oftast bli väldigt små och därmed kräver PalmOS inte lika mycket minne som till exempel en PDA med Pocket PC som operativsystem. 32

33 Filsystem På grund av de begränsade lagringsmöjligheterna och för att göra synkroniseringen med PC så effektiv som möjligt har inte Palm OS något traditionellt filsystem. Man sparar istället data i records, vilka är grupperade i databases. En databas är analogt med en fil. Skillnaden ligger i att datat delas upp i mindre delar och lagras som records, istället för i en stor sammanhängande bit. För att spara utrymme ändrar man databasen direkt i minnet istället för att först lagra den i RAM för att sedan skriva ner den i lagringsutrymmet (som är en annan del av RAM, se Minnesarkitektur) Viktiga delar För att skapa en förståelse för svårigheter under projektets gång kommer här en lite mer detaljerad beskrivning av vissa intressanta delar av Palm OS Minnesarkitektur Palm OS programvaran är designad runt en 32-bitars arkitektur. Processorn som används är en Motorola Systemet använder sig av 32 bitar stora adresser och de normala datatyperna är 8, 16 eller 32 bitar stora. Med 32 bitar stora adresser kan man totalt adressera 4GB, vilket är mer än tillräckligt även i framtida utbyggnader av operativsystemet; minnesarkitekturen ska inte behövas göras om. Palm OS delar upp minnet i två delar: dynamiskt RAM och lagrings-ram. Dynamiskt RAM används som arbetsyta för temporära variabler, och är analogt med RAM-minnet på vanliga persondatorer. Resten av RAMet på minneskortet går till lagrings RAM. Detta är analogt med hårddisk eller liknande på en stationär dator. Eftersom strömmen alltid är påslagen till minnessystemet förblir de båda delarna av RAM-minnet precis likadant även om man slår av sin Palm. All lagrings-ram förblir intakt även vid en reset av Palmen. Som en del av startupsekvensen av Palmen återinitieras det dynamiska RAMet och lagringsramet förblir intakt. All dynamisk RAM implementerar en enda stor heap som gör det möjligt för program att använda sig av dynamiska allokeringar av minne. En risk som följer med detta, är att det kan uppstå minnesläckor. Det vill säga att programmeraren glömmer eller missar att återlämna, allt använt minne till operativsystemet då programmet avslutas. Konsekvensen av detta kan vara att minnet helt tar slut efter en tids användande. 33

34 Händelser Generellt sett är PalmOS-applikationer enkeltrådiga, händelsedrivna ( event-driven ) program. Enbart ett program körs åt gången. En händelse kan vara många olika saker, till exempel då ett program startas skickas en speciell händelse, då pennan trycks ned på den tryckkänsliga skärmen skickas en pendown händelse, med mera. I stort sett allt som händer i en Palm generar också en händelse. Eftersom Palm OS är ett händelsestyrt operativsystem innehåller alla Palm OS applikationer en händelseloop. I händelseloopen plockar applikationen fram händelser från händelsekön, och skickar iväg dem, för omhändertagande. Applikationen använder sig av systemets funktionalitet om det behövs. do { EvtGetEvent(&event, evtwaitforever); if (! SysHandleEvent(&event)) if (! MenuHandleEvent(0, &event, &error)) if (! AppHandleEvent(&event)) FrmDispatchEvent(&event); } while (event.etype!= appstopevent); Figur 5.1: Exempelkod, händelseloop I denna loop kollar funktionen EvtGetEvent om det finns några händelser i händelsekön. Händelsen är en struktur som innehåller all information som behövs för att på ett korrekt sätt ta hand om händelsen. Detta görs i händelseloopen som innehåller olika funktioner. Den första som körs brukar vara SysHandleEvent som tar hand om systemspecifika händelser, sådana händelser är till exempel då man klickar på grafiska objekt på skärmen. SysHandleEvent i sig kan också generera nya händelser som läggs i händelsekön. Dessa tas sedan om hand vid senare tillfälle i loopen. SysHandleEvent returnerar SANT om den helt har tagit hand om händelsen, och att inget mer i händelseloopen behöver köras, om något senare i händelseloopen behöver köras returnerar den istället FALSK. Efter detta följer MenuHandleEvent, AppHandleEvent och FrmDispatchEvent. Dessa tar i tur och ordning hand om menyer, program som startas upp samt skickar vidare händelsen till händelsehanteraren för det aktiva formuläret (ett Palmprogram består av flera vyer, varje vy är ett formulär och har en egen händelsehanterare. I en aktiv vy finns alla knappar och andra objekt man för närvarande ser). Händelseloopen körs till dess att ett appstopevent genereras, då denna händelse tas emot avslutas programmet. 34