Bilbus. P4 projekt, AAU, Elektronik og elektroteknik

Bilbus P4 projekt, AAU, Elektronik og elektroteknik Gruppe 415 Mads Yde Jensen Jes Toft Kristensen Jan Sundvall Christian Thomsen Rasmus Nielsen Hans-Henning Terp-Hansen

Elektronik og Elektroteknik Fredrik Bajers Vej 7B Telefon 96 35 98 36 Fax 98 15 36 62 http://www.esn.aau.dk Synopsis: Titel: Tema: Bilbus Mikrodatamatsystemer Projektperiode: P4, forårssemesteret 2005 Projektgruppe: 415 Deltagere: Mads Yde Jensen Jes Toft Kristensen Jan Sundvall Christian Thomsen Rasmus Nielsen Hans-Henning Terp-Hansen Vejleder: Stefan Sörensen Oplagstal: 9 Sidetal: 125 Appendiksantal: 19 Afsluttet den 26.05.05 Denne P4 rapport fra foråret 2005 omhandler udviklingen af et serielt bussystem til en personbil. I prototypen af dette bussystem indgår en masterenhed samt tre slaveenheder. Udviklingen af prototypen tager udgangspunkt i SPU-modellen, der benyttes til kravspecifikation, accepttest og i softwaredesignet. Rapporten er opdelt i fem dele, hvor del I indeholder baggrund efterfulgt af kravspecifikation og accepttestspecifikation. Herefter konstrueres hardware til masterenheden i systemet gennem del II. Systemets tre slaveenheder konstrueres hardwaremæssigt i del III. Igennem del IV designes software til såvel master- som slaveenheder og der programmeres her i både C og assembler. Sidste del i rapporten indeholder en afrunding, hvor systemets accepttest og konklusion forefindes. Masterenheden i systemet opbygges omkring en Motorola 68000 processor, hvor tilhørende hardware i form af RAM, ROM, display, UARTs og interrupthandler behandles. De tre konstruerede slaveenheder opbygges med færdige mikrocontrollere af typen AT90S2313 og AT90S8535 fra Atmel. De tre udviklede slaveenheders funktionalitet er olietryksmåling, lygteenhed samt en lygtekontrolenhed, der indeholder kontakter til aktivering af lygteenheden. Den færdige prototype af systemet fungerer tilfredsstillende og lever op til projektstillers forventninger. Accepttesten af systemet viser, at den udviklede prototype overholder kravsspecifikationens funktionelle krav i 15 ud af 15 tilfælde. Der er i forbindelse med accepttesten udført en brugerundersøgelse af begrænset omfang - og denne viser stor tilfredshed blandt brugerne på områderne informationsomfang, informationstilgængelighed og informationsvisning.

Forord Denne P4-rapport er udarbejdet på den teknisk-naturvidenskabelige overbygning ved Aalborg Universitet. Den er skrevet af gruppe 415 under elektronik og elektroteknik faggruppen i perioden fra d. 2. februar til d. 26. maj 2005. Projektitlen Bilbus er valgt på baggrund af et projektforslag stillet af Hans-Henning Terp-Hansen. Dette projektforslag falder ind under det overordnede semestertema Mikrodatamatsystemer. Rapporten henvender sig til folk med et grundlæggende kendskab til elektronik, samt folk med interesse for design og konstruktion af mikrodatamatsystemer. Læsevejledning Kildehenvisninger er i teksten angivet i firkantede paranteser efter Harvard-metoden, som eksempelvis [Biering-Sørensen, 2000]. Hvis et større afsnit er baseret på en enkelt kilde, vil kildeangivelsen stå i slutningen af det pågældende afsnit. Litteraturlisten er at finde på side 121. Appendiks organiseres i alfabetisk rækkefølge og findes sidst i rapporten. Figurer nummereres fortløbende efter kapitlet, som de placeres i. Eksempelvis optræder figur 4.1 som første figur i kapitel 4. Ligninger er nummereret på samme måde som figurer, dog er de sat i parantes. Eksempelvis optræder første ligning i kapitel 5 som (5.1). Hver blok har tildelt et nummer, som alle komponentværdier i denne blok navngives efter. Dette betyder, at første tal i benævnelsen af komponenter ligger fast for de enkelte blokke. Eksempelvis hedder første modstand i lygteenheden R 61, den anden R 62 osv. Internetkilder er sammen med bilag vedlagt på CD-ROM. Der findes separate udfoldelige kredsløbsdiagrammer for de enkelte blokke sidst i rapporten. Aktiv-lave signaler angives i rapporten med symbolet *, eksempelvis DTACK. Inverterede signaler angives med overstregning, eksempelvis DTACK. Hexadecimale tal skrives med undersænket h efter tallet, eksempelvis 0FE3 h. Binære tal skrives med undersænket b efter tallet, eksempelvis 01001000 b. Binære angivelser har MSB til venstre.

Forkortelser og termer Der gøres i rapporten brug af følgende forkortelser og termer: ACIA Motorola betegnelse for en UART. Når der i systemet henvises til ACIA232, menes der ACIA en til kommunikation via RS232 til PC en. Når der henvises til ACIA485, menes der ACIA en til kommunikation via RS485 til de perifere enheder over den serielle bus. Buscycle Når en buscycle nævnes i dette system menes tiden, der går mellem to master-forspørgsler kan foretages. Der indgår altså både en busforespørgsel, et bussvar samt en eventuel buspause i denne tid. EEPROM Engelsk forkortelse for Electrical Erasable Programmable Read Only Memory. Frame Når en frame nævnes i dette system, menes en byte med et tilhørende antal start-, stop- og paritetsbit. Minimumsystemet Betegnelse for masterenheden i systemet indeholdende RAM, ROM, UART, og mikroprocessor samt diverse andre perifere kredsløb til drift af denne mikroprocessor. MSB / LSB Engelsk forkortelse for henholdsvis most- og least significant bit. På dansk henholdsvis mest- og mindst betydende bit. Norm Teknisk bestemmelse, der skal overholdes ved projektering og konstruktion af projekter. Den har til formål at sikre kvalitet og sikkerhed [Gyldendal, 2005]. Pakke Når en pakke nævnes i dette system, menes et antal frames, der tilsammen udgør en forespørgsel eller et svar for en given protokol. Parallel bus Når den parallelle bus nævnes i dette system, menes der den interne bus mellem processor, RAM, ROM og display i minimumsystemet. Perifere enheder Betegnelse for slaveenhederne på den serielle bus i systemet. Polling Engelsk for forespørgsel. Med polling menes der, at der spørges igen og igen om en tilstand, typisk indtil den ændrer sig. Står i modsætning til interrupt, der bryder ind i afviklingen af et program, når en tilstand ændrer sig. Protokol Et sæt standardiserede regler og procedurer for overførsel af data mellem en afsender og en modtager i et datanet eller over en bus [Gyldendal, 2005]. RISC Engelsk forkortelse for Reduced Instruction Set Computer. En mikrocomputer, der benytter et reduceret instruktionssæt. Antonymet til RISC er CISC, Complex Instruction Set Computer. Seriel bus Når den serielle bus nævnes i dette system, menes der bussen mellem minimumsystemet og de perifere enheder.

SMT Engelsk forkortelse for Surface Mounted Technology. Fælles betegnelse for overflade monterede komponenter af forskellig art. UART Engelsk forkortelse for Universal Asynchronous Receiver-Transmitter. Denne enhed kan sende og modtage seriel data, og konvertere dem til/fra parallel data. UML Engelsk forkortelse for Unified Modelling Language. UML er et sprog til specifikation, visualisering, konstruktion og dokumentation af edb-systemer såvel som forretningsmodeller og andre ikke-edb-relaterede systemer. Rapporten er udarbejdet af: Rasmus Nielsen Hans-Henning Terp-Hansen Mads Yde Jensen Jes Toft Kristensen Christian Thomsen Jan Sundvall

INDHOLDSFORTEGNELSE Indholdsfortegnelse Del I: Indledning 1 1 Indledning 3 1.1 Historisk perspektiv......................................... 3 1.2 Elektronisk kommunikation..................................... 4 2 Kravspecifikation 9 2.1 Indledning............................................... 9 2.2 Generel beskrivelse.......................................... 9 2.3 Specifikke funktionskrav....................................... 11 2.4 Eksterne grænsefladekrav...................................... 12 2.5 Krav til systemets ydelse....................................... 12 2.6 Kvalitetsfaktorer........................................... 12 2.7 Grænseflader............................................. 13 3 Problemformulering 15 3.1 Problemafgrænsning......................................... 15 4 Accepttestspecifikation 17 4.1 Indledning............................................... 17 4.2 Testemner............................................... 18 4.3 Testdesign............................................... 18 4.4 Testimplementation......................................... 18 4.5 Bilag.................................................. 19 Del II: Minimumsystem 21 5 Motorola 68000 processor 23 5.1 Intern opbygning........................................... 23 5.2 Benforbindelser............................................ 24 5.3 Clock-kredsløb............................................ 26 5.4 Reset-kredsløb............................................ 27 5.5 Delkonklusion............................................. 28 6 Memory 29 6.1 RAM- og ROM-kredse........................................ 29 6.2 Timing for valgte kredse....................................... 29 6.3 Delkonklusion............................................. 33 i

INDHOLDSFORTEGNELSE 7 Interrupt handler 35 7.1 Krav.................................................. 35 7.2 Konstruktion............................................. 35 7.3 Delkonklusion............................................. 37 8 ACIA 39 8.1 RS232................................................. 39 8.2 RS485................................................. 40 8.3 Delkonklusion............................................. 43 9 Display 45 9.1 Funktionalitet............................................. 45 9.2 Timing................................................. 46 9.3 Delkonklusion............................................. 48 10 Memory mapping 49 10.1 Krav.................................................. 49 10.2 Adressedekoder............................................ 50 10.3 DTACK -generator........................................... 52 10.4 Delkonklusion............................................. 53 11 Belastning af M68k 55 11.1 Belastningsberegning for adressebus................................ 55 11.2 Belastningsberegning for databus.................................. 56 11.3 Belastningsberegning for kontrolbus................................ 57 11.4 Delkonklusion............................................. 57 Del III: Perifere enheder 59 12 Hardware til perifere enheder 61 12.1 Kravspecifikation........................................... 61 12.2 Fælles hardware........................................... 64 12.3 Individuel hardware......................................... 66 12.4 Test.................................................. 67 12.5 Resultater............................................... 67 12.6 Delkonklusion............................................. 67 Del IV: Software 69 13 Protokol 71 13.1 Indledning............................................... 71 13.2 Opbygning.............................................. 71 13.3 Fejlhåndtering............................................ 74 14 Introduktion til softwareudvikling og metodevalg 77 14.1 Introduktion til software....................................... 77 14.2 Metode................................................ 78 15 Software til minimumsystem 81 15.1 Programdesign............................................ 81 15.2 Procesdesign............................................. 83 15.3 Moduldesign............................................. 85 15.4 Delkonklusion............................................. 97 ii

INDHOLDSFORTEGNELSE 16 Software til perifere enheder 99 16.1 Programdesign............................................ 99 16.2 Procesdesign............................................. 100 16.3 Moduldesign............................................. 102 16.4 Delkonklusion............................................. 110 Del V: Afrunding 113 17 Accepttest 115 17.1 Resultater............................................... 115 17.2 Evaluering............................................... 115 18 Konklusion 117 19 Perspektivering 119 Litteraturliste 121 Del VI: Appendiks 127 A Oversigt over elektriske funktioner i moderne biler 129 B UseCases 133 B.1 Identifikation af UseCases...................................... 133 B.2 UseCase: Styr display........................................ 133 B.3 UseCase: Styr lys........................................... 134 B.4 UseCase: Udlæs data......................................... 134 B.5 UseCase: Omprogrammér master.................................. 135 C M68k read og write timing 137 C.1 Read cycle............................................... 137 C.2 Write cycle.............................................. 139 D Beskrivelse af ACIA 141 D.1 Registre................................................ 141 D.2 Kommunikation............................................ 143 D.3 Benforbindelser............................................ 143 E Kildekode til PEEL-programmer 145 E.1 Kildekode til PEEL01........................................ 145 E.2 Kildekode til PEEL02........................................ 146 F Kildekode til initialiseringsproces 147 F.1 Assembler-kode til initialisering af hardware modul........................ 147 G Kildekode til løkkeproces 149 G.1 Header-fil til lygtekontrolmodul................................... 149 G.2 C-kode til lygtekontrolmodul.................................... 149 G.3 Header-fil til oliekontrolmodul.................................... 150 G.4 C-kode til oliekontrolmodul..................................... 150 G.5 Header-fil til løkkestyringsmodul.................................. 151 G.6 C-kode til løkkestyringsmodul.................................... 151 iii

INDHOLDSFORTEGNELSE H Kildekode til displayproces 153 H.1 Header-fil til displaymodul...................................... 153 H.2 C-kode til displaymodul....................................... 153 H.3 Assembler-kode til displaymodul.................................. 155 H.4 Beregning af tidsforbrug ved afvikling af interrupt........................ 156 I Kildekode til bus- og tabelmodulerne 159 I.1 Header-fil til tabelmodulerne.................................... 159 I.2 C-kode til tabelmodulerne...................................... 159 I.3 Assembler-kode til busmodul.................................... 160 J Kildekode til perifere enheder 163 J.1 Header-fil til lygtekontrolenhed................................... 163 J.2 C-kode til lygtekontrolenhed..................................... 164 J.3 C-kode til lygteenhed......................................... 165 J.4 C-kode til olieenhed......................................... 166 K Kildekode til testsoftware 169 K.1 C-kode til test af software i minimumsystemet........................... 169 K.2 C-kode til test af A/D converter i olieenhed............................ 170 K.3 C-kode til test af RS485 i de perifere enheder........................... 171 L Målejournal for clock-generatorer 173 M Målejournal for reset-kredsløb 177 N Målejournal for DTACK -generator 179 O Målejournal for responstid på perifere enheder 181 P Målejournal for ACIA485 185 Q Målerapport for accepttest 187 Q.1 Formål................................................. 187 Q.2 Test af Kommunikationstid..................................... 187 Q.3 Test af brugerinterface........................................ 189 Q.4 Spørgeskema til interface test.................................... 190 R Folduddiagrammer over perifere enheder 193 S Folduddiagram over minimumsystemet 195 iv

FIGURER Figurer 1.1 Parallelt ledningsnet fra Ford Sierra................................. 3 1.2 En frame indeholdende start-, data-, stop- og paritetsbit..................... 4 1.3 En pakke med 4 frames........................................ 6 2.1 Systemblokdiagram over minimumsystemet med display tilkoblet................. 10 2.2 Systemblokdiagram over hele systemet................................ 10 2.3 Grænseflader for det totale bilbussystem.............................. 13 5.1 Bitoversigt over statusregistret i M68k................................ 24 5.2 Funktionsopdeling af M68k ens ind- og udgange.......................... 24 5.3 Kredsløbsdiagram over clock-kredsløb til M68k........................... 27 5.4 Timingsdiagram for reset-kredsløb til M68k............................. 27 5.5 Kredsløbsdiagram over reset-kredsløb til M68k........................... 28 6.1 Timingsdiagram for read cycle af RAM............................... 30 6.2 Timingsdiagram for write cycle af RAM............................... 31 6.3 Timingsdiagram for read cycle af ROM............................... 32 7.1 Opkobling af tasterne til interrupt 1 og 2.............................. 37 7.2 Kredsløbsdiagram for interrupt handler............................... 38 8.1 Logiske niveauer for RS232 og RS485................................ 40 8.2 Kredsløbsdiagram for opkobling af RS232.............................. 41 8.3 Kredsløbsdiagram for opkobling af RS485.............................. 42 8.4 Princip for terminering af transmissionsledninger på RS485 forbindelse............. 43 9.1 Skitse af displaylayout og eksempel på karakter.......................... 45 9.2 Timingsdiagram for write cycle af display.............................. 47 9.3 Timingsdiagram for read cycle af display.............................. 48 10.1 Kredsløbsdiagram for adressedekoder og DTACK -generator..................... 53 12.1 Blokdiagram over AVR mikrocontrollere.............................. 62 12.2 Kernen i AVR mikrocontrollere.................................... 63 12.3 Flowdiagram for A/D-konvertering efter successiv approximationsprincippet.......... 68 13.1 Oversigt over de enheder, der benytter den udviklede protokol.................. 71 13.2 Opbygningen af en buscycle for den udviklede protokol...................... 72 14.1 Betydning af flowdiagrammer i softwareudviklingen........................ 77 v

FIGURER 14.2 V-modellen for softwareudvikling................................... 79 15.1 Proces- og moduloversigt for minimumsystemet.......................... 81 15.2 Grænseflader for program i minimumsystem............................ 82 15.3 Procesforløb i minimumsystem.................................... 82 15.4 Moduloversigt for initialiseringsprocessen.............................. 83 15.5 Moduloversigt for løkkeprocessen................................... 84 15.6 Flowdiagram for funktionen til initialisering af hardware..................... 85 15.7 Flowdiagram for entry-funktionen bus i busmodulet........................ 88 15.8 Flowdiagram for subrutinen bus w i busmodulet.......................... 88 15.9 Flowdiagram for subrutinen bus r i busmodulet.......................... 89 15.10Flowdiagram for funktionen til oprettelse af tabel......................... 91 15.11Flowdiagram for funktionen til opdatering af tabel for specifik adresse.............. 92 15.12Flowdiagram for funktionen til opdatering af hele tabellen.................... 93 15.13Flowdiagram for funktionen til behandling af lygteenhed..................... 94 15.14Flowdiagram for funktionen til behandling af olieenhed...................... 95 15.15Principdiagram for displaystyring.................................. 96 15.16Flowdiagram for funktionen dispup()................................ 97 15.17Flowdiagram for funktionen dispdown()............................... 97 16.1 Flowdiagram for software til lygtekontrolenhed........................... 100 16.2 Proces- og moduloversigt for software til perifere enheder..................... 100 16.3 Flowdiagram for funktionen send data()............................... 109 16.4 Flowdiagram for software til perifere enheder............................ 111 B.1 Aktør kontekstdiagram til UseCase analyse af systemet...................... 133 C.1 Flowdiagram for M68k read cycle.................................. 137 C.2 Timingsdiagram for M68k read cycle................................. 138 C.3 Flowdiagram for M68k write cycle.................................. 139 C.4 Timingsdiagram for M68k write cycle................................ 140 D.1 Blokdiagram for ACIA MC6850................................... 141 D.2 Blokdiagram for synkron kommunikation mellem M68k og ACIA................. 143 L.1 Måleopstilling for måling på clock-generatorer........................... 174 M.1 Måleopstilling for måling på reset-kredsløb............................. 178 N.1 Måleopstilling for måling på DTACK -generator........................... 180 N.2 Målinger på DTACK -generator.................................... 180 O.1 Måleopstilling for måling på responstider for perifere enheder................... 182 O.2 Responstid for olienhed........................................ 183 P.1 Måleopstilling for målejournal af ACIA485............................. 185 P.2 Grafer for RTS og TxD på ACIA485 ved afsendelse af bogstavet A............... 186 Q.1 Måleopstilling til måling af kommunikationstid........................... 188 Q.2 Måleopstilling til brugerinterface undersøgelse........................... 190 vi

TABELLER Tabeller 1.1 Eksempel på protokol......................................... 6 1.2 Eksempel på kommandoliste tilknyttet en protokol......................... 6 4.1 Funktionskrav fra kravspecifikationen................................ 19 5.1 Oversigt over registre og adresseben for benyttede enheder i minimumsystemet......... 25 6.1 Timingstider for read cycle af RAM................................. 30 6.2 Timingstider for write cycle af RAM................................. 31 6.3 Timingstider for write cycle af RAM................................. 31 6.4 Timingstider for read cycle af ROM................................. 32 7.1 Uddrag af sandhedstabel for 8-3 konverter i interrupt handler................... 36 9.1 Oversigt og beskrivelse af udvalgte displayfunktioner....................... 46 9.2 Timingstider for write cycle af display................................ 47 9.3 Timingstider for read cycle af display................................ 48 10.1 Krav til adressering ved benyttelse af TS2-MON.......................... 49 10.2 Adresseoversigt for enheder på databus............................... 50 10.3 Adresseoversigt på bitniveau..................................... 50 10.4 Komplet adresseoversigt........................................ 51 10.5 Sandhedstabel for DTACK -generator................................. 52 11.1 Maksimal belastning for M68k.................................... 55 11.2 Enheder på adressebus og disses strøm- og kapacitetsbelastninger................ 55 11.3 Enheder på databus og disses strøm og kapacitetsbelastninger.................. 56 11.4 Belastninger på kontrolbussen.................................... 57 12.1 Testresultater for de perifere enheder................................ 67 13.1 Den udviklede protokols kommandoer................................ 73 13.2 Den udviklede protokols fejlkoder.................................. 74 15.1 Instruktionerne til optælling af timeout på perifere enheder.................... 88 16.1 Registre, der udgør grænseflader for moduler............................ 101 16.2 Variabler, der udgør grænseflader for moduler........................... 102 16.3 Grænseflader for modul g....................................... 105 16.4 Grænseflader for modul j....................................... 107 16.5 Grænseflader for modul m...................................... 109 vii

TABELLER 17.1 Resultater fra accepttesten...................................... 115 17.2 Resultater for brugerinterfacetest................................... 116 C.1 Timingstider for M68k read cycle.................................. 138 C.2 Timingstider for M68k write cycle.................................. 139 D.1 Adgang til registre i ACIA...................................... 142 D.2 Bitoversigt over kontrolregisteret i ACIA.............................. 142 D.3 Bitoversigt over statusregisteret i ACIA............................... 142 H.1 Beregning af tidsforbrug for dispup-interrupt............................ 156 L.1 Apparaturliste for målinger på clock-generatorer.......................... 174 L.2 Måleresultater for clock-generator til ACIA232........................... 174 L.3 Måleresultater for clock-generator til ACIA485........................... 175 L.4 Måleresultater for clock-generator til M68k............................. 175 M.1 Apparaturliste for målinger på reset-kredsløb............................ 177 M.2 Måleresultater for reset-kredsløb til M68k.............................. 178 N.1 Apparaturliste for målejournal for DTACK -generator........................ 180 O.1 Apparaturliste for måling på perifere enheder............................ 182 O.2 Måleresultater for responstid for perifere enheder.......................... 182 P.1 Apparaturliste for målejournal af ACIA485............................. 185 Q.1 Apparaturliste for måling af kommunikationstid.......................... 187 Q.2 Måleresultater for måling af kommunikationstid.......................... 188 Q.3 Måleresultater for brugerinterface måling.............................. 190 R.1 Komponentliste til kredsløbsdiagram for lygtekontrolenhed.................... 193 R.2 Komponentliste til kredsløbsdiagram for lygteenhed........................ 193 R.3 Komponentliste til kredsløbsdiagram for olieenhed......................... 193 S.1 Komponentliste til kredsløbsdiagram for minimumsystem..................... 195 viii

Del I: Indledning Denne del indeholder en indledning, hvor forskellen på serielle og parallelle systemer beskrives. Indledningen beskriver desuden virkemåden af bussystemer, og i et afsluttende afsnit beskrives projektforslagets problematik. Efter indledningen følger en kravspecifikation skrevet efter SPU-modellen [Biering-Sørensen, 2000], hvor UseCase analyse desuden inddrages til bestemmelse af de funktionelle krav til prototypen. Denne del afsluttes med en problemformulering, hvor nogle af kravene opstillet i kravspecifikationen efterfølgende afgrænses. Del I: Indledning 1 1 Indledning 3 1.1 Historisk perspektiv......................................... 3 1.2 Elektronisk kommunikation..................................... 4 2 Kravspecifikation 9 2.1 Indledning............................................... 9 2.2 Generel beskrivelse.......................................... 9 2.3 Specifikke funktionskrav....................................... 11 2.4 Eksterne grænsefladekrav...................................... 12 2.5 Krav til systemets ydelse....................................... 12 2.6 Kvalitetsfaktorer........................................... 12 2.7 Grænseflader............................................. 13 3 Problemformulering 15 3.1 Problemafgrænsning......................................... 15 4 Accepttestspecifikation 17 4.1 Indledning............................................... 17 4.2 Testemner............................................... 18 4.3 Testdesign............................................... 18 4.4 Testimplementation......................................... 18 4.5 Bilag.................................................. 19

KAPITEL 1. INDLEDNING Kapitel 1 Indledning 1.1 Historisk perspektiv Automobilets historie er ca. 150 år gammel. I sine unge dage var dets vigtigste funktion at transportere personer og gods fra ét sted til et andet. Automobil er i dag forkortet til bil, og bilens vigtigste egenskab er stadig at fragte personer og gods. Imidlertid har forbrugerne vænnet sig til en stadig stigende mængde sikkerhed, komfort og underholdning i bilen. Sammen med denne tilsyneladende evigt stigende mængde elektronik stiger mængden af ledninger i bilen. En ufuldstændig men omfattende liste over funktioner kan ses i appendiks A på side 129. Som det ses af listen og på fotoet herunder, antager ledningsnettet en betydelig mængde og har en høj kompleksitet. Figur 1.1: Parallelt ledningsnet fra Ford Sierra 88-93. Vægten er ca. 15 kg. Som det er vist, fylder det ca. 4 m 2. 3

1.2. ELEKTRONISK KOMMUNIKATION 1.2 Elektronisk kommunikation 1.2.1 Parallelle systemer Et parallelt digitalt system er et system, hvor forbindelser, der føres imellem to eller flere enheder, kun kan bære én information, i form af et logisk niveau: logisk 1 eller logisk 0. Således kan en enkelt leder ikke overføre information til f.eks. både nærlys og blinklys samtidigt, og således er det største heltal i titalssystemet, der kan overføres på en leder lig med én. Er der flere parallelle ledere, kan disse sammensættes med udgangspunkt i det binære talsystem, og deraf kan dannes heltal (d maks ), hvis størrelse er bestemt af antallet af ledere (n): d maks = 2 n [ ] (1.1) Mængden af data, der kan overføres pr. tidsenhed er i princippet uendelig, men er i praksis begrænset - dels af de komponenter, der kommunikerer og dels af de forbindelser, der er imellem dem. Et parallelt system, som det der er vist i afsnit 1.1 på foregående side forekommer, i biler, at være omstændigt og klodset. 1.2.2 Serielle systemer Et serielt system består principielt af én forbindelse, hvor igennem der sendes et pulstog af logiske niveauer. Således kan f.eks. tallet 179 omsættes til et binært tal 10110011 b, og disse digitallogiske niveauer sendes afsted efter hinanden som en datapakke kaldet en byte. For at modtageren kan skelne flere bytes fra hinanden, sendes der et startbit inden hver byte. Der sendes også evt. paritetsbit samt et eller flere stopbit efter hver byte. En byte med tilhørende start-, paritets- og stopbit kaldes en frame. Startbit Data 8 bit Paritets bit Stopbit Figur 1.2: En frame indeholdende start-, data-, stop- og paritetsbit. Ligesom for parallelle systemer, er datamængden, der kan overføres pr. tidsenhed begrænset af komponenter og forbindelsen imellem dem. Overførselshastigheden måles i bit pr. sekund [ bps]. Serielle data kan sendes synkront eller asynkront. Synkron seriel transmission kræver, udover mindst én forbindelse til data, en forbindelse til overførsel af et taktsignal, der bruges til at synkronisere modtager med sender. Typisk anvendes asynkron seriel transmission. 1.2.3 Dataformat Formatet hvormed data sendes, kan principielt bestemmes frit, men der findes standarder indenfor området. Benyttes en standard vil andet udstyr, der benytter samme standard, kunne kommunikere på det serielle system. RS232 standarden beskriver det fysiske lag, der inkluderer de fysiske stik, benbenævnelser, spændingsnivauer, tidsbetingelser for signalerne, formatet der anvendes, at LSB sendes først, samt at det er asynkron kommunikation [Davis, 2005]. Formatet angiver følgende egenskaber: Hastighed, f.eks. 9600 bps Antal databit: 7, 8 eller 9 Paritet: ingen, lige (Even) eller ulige (Odd) Antal stopbit: 1 eller 2 4

KAPITEL 1. INDLEDNING En angivelse af formatet kan f.eks. være 57600, 8, E, 1. Med udgangspunkt i dette eksempel kan paritetsbit udregnes på basis af databit. Antallet af bit, der er logisk høj tælles, og er dette antal ulige, sættes paritetsbit til 1. Hvis antallet i forvejen er lige, sættes paritetsbit til 0. Dermed er det samlede antal bit, der er logisk høj lige. Bemærk, at start og stopbit ikke regnes med. Framen sendes afsted, og ved modtageren kontrolleres, om antallet af bit stadig er lige. Hvis en fejl har indfundet sig undervejs, ignoreres pakken, og det kan på modtageren indikeres, at en fejl har fundet sted. Det er vigtigt at bemærke, at selvom et antal apparater overholder RS232 standarden, og dermed kan sende og modtage data i henhold til denne standard, så er det ikke sikkert, at deres indbyrdes kommunikation resulterer i noget brugbart. Det skyldes, at de ikke nødvendigvis overholder den samme protokol, og at RS232 kun definerer den fysiske forbindelse. 1.2.4 Bussystemer Et RS232 serielt system tillader kun, at der tilsluttes to enheder, der kan kommunikere med hinanden ad gangen. Imidlertid kan det være praktisk at tilslutte flere enheder til det samme system. Dette kaldes for en bus. Et bussystem har typisk et antal slaveenheder samt en eller flere masterenheder. Kendetegnet for slaveenheder er, at de som udgangspunkt ikke sender data på bussen, medmindre de bliver bedt om det fra en master. Mastere udsender typisk data til slaver, i nogle tilfælde for at opnå et svar fra slaverne. Flere enheder, der er tilsluttet den samme bus, kan dermed få tildelt opgaver samtidigt og kommunikere med hinanden. Som med serielle systemer findes der forskellige standarder, der kan anvendes til bussystemer. Nogle enkelte er anført her: P-NET CAN-BUS Profi-bus I 2 C VME BUS Flere af ovennævnte protokoller bygger på serielle standarder. F.eks. bygger P-NET og Profi-bus på RS485 standarden. RS485 tillader, modsat f.eks. RS232, flere master- og slaveenheder tilsluttet det samme ledningsnet, og kaldes derfor for en busstandard. RS485 busstandarden indeholder ingen protokol specifikationer [Strangio, 2005]. Når flere enheder deles om en bus, er det nødvendigt at sikre, at kun én enhed sender ad gangen. Et bussystem kan indeholde flere mastere, men der kræves så et system, der sikrer, at de skiftes til at varetage kontrollen over bussen. 1.2.5 Protokoller En protokol, og herunder såkaldt softwarehandshaking, er en aftale imellem kommunikerende parter. Når to parter kommunikerer, uanset om det er mennesker eller maskiner, er de nødt til at tale samme sprog. Ellers er der ingen sikkerhed for at information når frem, og/eller bliver forstået af parterne. Et eksempel på en sådan handshaking ser ud som følger: 1.2.6 Protokoleksempel 1. Masterenhed spørger efter slaveenhed #n. 2. Slaveenhed #n svarer, at den er til stede. 3. Masterenhed afsender kommando til slaveenheden. 4. Slaveenheden modtager kommando, udfører den og svarer tilbage om, hvorvidt denne lykkedes. 5

1.2. ELEKTRONISK KOMMUNIKATION Byte nr. Indhold Beskrivelse 1 Adresse Enhedsnummer på enheden, der tales til 2 Kommando Tal, der angiver en given kommando i henhold til en kommandoliste 3 Værdi #1 Databyte 4 Værdi #2 Databyte Tabel 1.1: Eksempel på protokol. Når masterenheden konstaterer, at den efterspurgte slaveenhed er tilstede og svarer, afsender masterenheden datapakken. Denne datapakke består af en række bytes i en given rækkefølge i henhold til den anvendte protokol. Et eksempel ser ud som i tabel 1.1. De 4 bytes sendes afsted hver med deres respektive start-, stop- og paritetsbit. Det resulterer i 4 frames - tilsammen kaldet en pakke som vist i figur 1.3. Frame 1 Frame 2 Start bit Data byte nr. 1 Adresse 8 bit Paritets bit Stop bit Start bit Data byte nr. 2 Kommando 8 bit Paritets bit Stop bit Start bit Data byte nr. 3 Værdi #1 8 bit Paritets bit Stop bit Start bit Data byte nr. 4 Værdi #2 8 bit Paritets bit Stop bit Frame 3 Frame 4 Figur 1.3: En pakke med 4 frames, hvori de 4 databytes findes. Byte nr. 2, indeholdende kommandoen, refererer til en kommandoliste, som kan se ud som i tabel 1.2. Kommandolisten kan i dette tilfælde antage maksimalt 256 forskellige kommandoer, men kan udvides ved at tilføje flere bytes til adressen. Både master- og slaveenhed skal kende protokollen for at der kan komme brugbare resultater ud af kommunikationen. Kommando nr. Beskrivelse 0 Læs værdi og send data retur 1 Indstil udgang nr. Værdi #1 til indholdet af Værdi #2 2 Åbn ventil 3-255 etc. Tabel 1.2: Eksempel på kommandoliste tilknyttet en protokol. 1.2.7 Bilers elektriske system Det omfattende ledningsnet til en bil, vist i afsnit 1.1 på side 3, er et parallelt system. Tages der udgangspunkt i en forlygte, skal der fra forskellige lygtekontakter i kabinen forbindes fem ledninger til lygtehuset. Ledningerne bærer information om nær, fjern, tåge, positions og blinklys. Anvendes et serielt system, kan de fem ledningers signaler konverteres, sendes via en enkelt ledning, og ved lygtehuset konverteres tilbage til parallelle ledninger, der så kan tilsluttes de fem pærer anført ovenfor. Hvis der anvendes et bussystem, kan denne enkelte ledning deles af flere enheder. Dermed kan en enkelt ledning bære informationer til mange enheder. Disse enheder kaldes i denne rapport for perifere enheder. Ved hjælp af et serielt bussystem antages det, at det er muligt at reducere bilens elektriske ledningsnet betragteligt. Det medfører umiddelbart følgende fordele: 6

KAPITEL 1. INDLEDNING Lavere vægt - formodentlig bedre brændstoføkonomi. Mere simpelt ledningsnet - muligvis billigere fremstillingspris samt evt. færre muligheder for fejl ved samling. Modulært system. Principielt er der ingen begrænsninger på mængden af perifere enheder, der kan deles om et bussystem. Imidlertid er der nogle tekniske/praktiske begrænsninger på, hvor mange perifere enheder, der reelt kan deles om den samme bus. I næste afsnit opstilles formål, afgrænsning og kravspecifikation, der danner rammen om konstruktionen af systemet. 7

KAPITEL 2. KRAVSPECIFIKATION Kapitel 2 Kravspecifikation 2.1 Indledning I dette kapitel opstilles de specifikke krav til konstruktionen af prototypen på et bussystem til en bil. Udfærdigelsen tager udgangspunkt i SPU-modellen [Biering-Sørensen, 2000, side 71]. Punkterne fra denne model vil med få undtagelser blive gennemgået kronologisk. 2.1.1 Formål Formålet er at konstruere et mikrodatamatsystem til styring af perifere enheder i en personbil. Desuden konstrueres 3 af disse perifere enheder. Systemets navn er bilbus. 2.1.2 Læsevejledning I det følgende afsnit findes en generel beskrivelse af systemet. Heri beskrives blandt andet systemets funktion, begrænsninger, fremtid, brugerprofil samt forudsætningerne for brugernes anvendelse af systemet. Herefter følger de specifikke krav til prototypen og i tredje afsnit beskrives de perifere grænsefladekrav til konstruktionen. Den endelige afgrænsning ud fra kravspecifikationen finder sted i problemformuleringen i afsnit 3.1 på side 15. 2.2 Generel beskrivelse Dette afsnit har til formål at beskrive det samlede system og herudfra bestemme en række parametre til prototypen - blandt andet dennes begrænsninger, samt en identifikation af brugerne. 2.2.1 Systembeskrivelse Systemets opgave er, ved hjælp af et mikrodatamatsystem, at kontrollere de perifere enheder i en personbil. Den centrale mikrocomputer opbygges som på figur 2.1 og består grundlæggende af mikroprocessor, RAM, ROM og en eller flere UART - kaldet minimumsystemet. Til dette minimumsystem er tilsluttet et display, hvor de indsamlede data fra de perifere enheder kan udlæses. 9

2.2. GENEREL BESKRIVELSE RAM ROM UART RS232 Display Mikroprocessor Figur 2.1: Systemblokdiagram over minimumsystemet med display tilkoblet. Minimumsystemet skal kunne kommunikere med de perifere enheder vha. et bussystem, og de perifere enheder skal være i stand til at dekode den afsendte information fra minimumsystemet og eventuelt sende et svar tilbage. Et samlet blokdiagram ses på figur 2.2. Der udvikles tre af de perifere enheder fra figur 2.2; lygteenhed, lygtekontrolenhed og olieenhed. Systemet udvikles, så der senere er mulighed for tilkobling af flere perifere enheder. PC Perifer enhed #1 Perifer enhed #2 Perifer enhed #3 Perifer enhed #n Minimumsystem UART RS485 Figur 2.2: Systemblokdiagram over hele systemet. 2.2.2 Systemets funktion Funktionerne af de forskellige blokke på figur 2.2 er: Minimumsystemet Denne blok har til opgave at indhente de relevante data fra de perifere enheder og herefter bearbejde disse. Brugeren gives mulighed for via et LCD-display at vælge, hvilke af disse bearbejdede data, der ønskes udlæst på displayet i bilens førerkabine. Minimumsystemet får således status af at være master på den serielle bus. Perifer enhed #1 - lygteenhed Denne enhed kan tænde eller slukke de fire forskellige pærer, der sidder i hvert lygtehus på en almindelig personbil. Disse er blinklys, positionslys, nærlys og fjernlys. Aktiveringen af disse funktioner foregår gennem bussen og kommer fra den perifere enhed beskrevet herunder. Status af enheden sendes via bussen til minimumsystemet. Denne og de to efterfølgende perifere enheder får status af at være slaver på den serielle bus. Perifer enhed #2 - lygtekontrolenhed Denne enhed giver brugeren mulighed for at aktivere funktionerne tænd eller sluk i den perifere lygteenhed. Status af enheden sendes via bussen til minimumsystemet. Perifer enhed #3 - olieenhed Denne enhed kan aflæse olietrykket i motoren. Status af enheden sendes via bussen til minimumsystemet. 2.2.3 Systemets begrænsninger Systemet udvikles til ikke-tidskritiske funktioner i bilen. Der udvikles altså ikke imod et system, der kan kontrollere f.eks. bremser i en personbil. Systemet har et endeligt antal perifere enheder, der kan tilsluttes - dette antal fastlægges i afsnit 2.3. 10

KAPITEL 2. KRAVSPECIFIKATION 2.2.4 Systemets fremtid Det skal være muligt at opdatere programkoden, der eksekveres i minimumsystemets mikroprocessor via seriel overførsel med RS232 standarden. Derved bliver det muligt, at afvikle nye funktioner fra eventuelle nye perifere enheder. Der kan senere tilsluttes et større antal perifere enheder på systemet. Det kan i fremtiden forventes, at systemet skal udvides til også at kunne håndtere tidskritiske informationer fra de perifere enheder. 2.2.5 Brugerprofil Målgruppen for dette system er den almindelige bilejer. Det kan således ikke forventes, at den gennemsnitlige bruger har forhåndsviden omkring benyttelsen af systemet. Opdateringen af masterenheden gennem RS232 standarden skal foretages af en automekaniker, der forventes at have et grundlæggende kendskab til opdatering af mikrodatamatsystemer i en personbil. Derfor skal PC-programmet udvikles efter lignende programmer på markedet, så den almindelige automekaniker problemfrit kan opdatere minimumsystemet. 2.2.6 Omfang af kundeleverance Der leveres et eksemplar af systemet, og dette skal foreligge d. 26-05-05. Med systemet skal følge en kravspecifikation og den efterfølgende accepttest. 2.3 Specifikke funktionskrav I dette afsnit er de forskellige krav sorteret efter de fire blokke beskrevet tidligere i afsnit 2.2.2. Der henvises til appendiks B på side 133, hvor UseCases for de forskellige perifere enheder findes. Disse er medvirkende til opstillingen af de specifikke funktionskrav i dette afsnit. 2.3.1 Generelt Det er i projektforslaget et krav, at det færdige system maksimalt må koste 10.000.- DKK. Der skal i systemet kunne tilsluttes op til 128 perifere enheder. Dette krav fastsættes på baggrund af appendiks A på side 129, hvor der efterfølgende tages hensyn til eventuelle mangler i listen, samt nye enheder. 2.3.2 Minimumsystemet Generelt Monitor- og debuggerprogrammet TS2-MON benyttes til interface med PC. Hardware Opbygges med en Motorola 68000 processor, hvor clock-frekvensen vælges til 8 MHz [MC68000UM.pdf, 2005]. Valget af processor bygger på, at undervisningen på semestret er rettet mod denne processor. Opbygges med 2 x 128 kbit ROM. Dette krav fastlægges af TS2-MON. Opbygges med 2 x 512 kbit RAM. Dette vælges, idet komponentudleveringen på universitetet udleverer denne RAM-størrelse som standard for semestret. Skal indeholde et LCD-display, hvor bearbejdet data fra minimumsystemet kan udlæses. Dataoverførsel Skal kunne tilkobles en PC via en RS232 forbindelse. Kommunikationen over den serielle bus skal foregå via en protokol, der udvikles specifikt til systemet. 11

2.4. EKSTERNE GRÆNSEFLADEKRAV 2.3.3 Lygteenhed Denne enhed skal efter signal fra minimumsystemet kunne tænde eller slukke de fire lygter i lygtehuset uafhængig af hinanden. Der opereres altså kun med logiske tænd/sluk funktioner i denne enhed. 2.3.4 Lygtekontrolenhed Skal opbygges med fire kontaktgreb til aktivering af funktionerne nærlys, langlys, blinklys og positionslys. Der opereres også i denne enhed kun med logiske tænd/sluk funktioner. 2.3.5 Olieenhed Enheden skal kunne omdanne en analog værdi fra en tryk-transducer til en digital værdi og afsende denne over den serielle bus. 2.4 Eksterne grænsefladekrav 2.4.1 Brugergrænseflade Systemets udvikling har fokus på opbygning og programmering af et mikrodatamatsystem, og derfor er kravene til brugergrænsefladen begrænset. Grænsefladen består af LCD-displayet, hvor brugeren via to kontakter får adgang til informationer indsamlet fra minimumsystemet samt de fire kontaktgreb i lygtekontrolenheden. Mere om de specifikke UseCases kan læses i appendiks B på side 133. 2.4.2 Hardwaregrænseflade Hardwaregrænsefladen mellem systemet og den tilsluttede PC udgøres af en RS232 forbindelse. Grænsefladen mellem minimumsystemet og de perifere enheder opbygges over RS485 standarden. 2.5 Krav til systemets ydelse Instruktioner fra brugeren skal være udført indenfor 0.5 s. Dette forholdsvis slappe tidskrav er valgt ud fra den betragtning, at der som beskrevet i afsnit 2.2.3 på side 10 ikke arbejdes med tidskritiske funktioner i dette system. 2.6 Kvalitetsfaktorer Nedenstående liste er en prioritering over systemets kvalitetsfaktorer. Førstnævnte har højeste prioritet: 1. Pålidelighed Pålideligheden af systemet skal være høj, idet der varetages funktioner, som omhandler bilistens færdselssikkerhed - ét manglende signal til et lygtehus på bilen kan få voldsomme konsekvenser for bilisten. Det er derfor vigtigt, at der ikke forekommer datatab i kommunikationen mellem de forskellige enheder i systemet. 2. Udvidelsesmulighed Systemet skal konstrueres, så der senere kan tilkobles flere perifere enheder. Denne kvalitetsfaktor er vigtig, fordi hele argumentationen om besparelse i plads og vægt ved indførelsen af systemet først for alvor bliver valid ved et større antal perifere enheder. Herudover vil det være ønskværdigt at konstruere systemet, så det nemt kan udvides til også at omfatte de tidskritiske funktioner i en personbil. Denne funktionalitet vil øge systemets konkurrenceevne. 12

KAPITEL 2. KRAVSPECIFIKATION 3. Brugervenlighed Det er nødvendigt, at betjeningen af displayet er simpel og effektiv. Det er derimod ikke en avanceret funktionalitet, der tilbydes brugeren, så selvom brugervenlighed er nødvendig i denne grænseflade, vil det ikke kræve meget udvikling at opnå denne. Den mere avancerede opdatering af systemet skal som nævnt i afsnit 2.2.5 foretages af en automekaniker. Da denne aktør antages at have kendskab til lignende systemer, lægges der ikke vægt på brugervenligheden i denne grænseflade mellem system og aktør. For mere information omkring brugergrænseflader henvises til appendiks B på side 133. 4. Vedligeholdelsesmuligheder Vedligeholdelsesmulighederne skal være middelgode i systemet. Som tidligere nævnt vil vedligeholdelsen blive foretaget af en automekaniker, der har mulighed for at tilslutte nye perifere enheder samt at opdatere programkoden i systemet. Produktet bør konstrueres, så en opdatering af systemets programkode kan foretages på under 15 minutter efter tilslutningen af en ny perifer enhed. 5. Design Da der udvikles en prototype, vil kvalitetskravet til design blive vægtet lavt. Hvis systemet skal anvendes i nutidens personbiler, vil det formodentligt være op til den enkelte personbilsproducent selv at designe displaypanelet til førerkabinen. 2.7 Grænseflader På figur 2.3 herunder ses et blokdiagram over systemet, hvor de overordnede grænseflader mellem de forskellige blokke er opridset. De specifikke timingsdiagrammer og grænseflader vil være at finde i de efterfølgende kapitler for de respektive blokke. PC R S 2 3 2 Minimumsystem RS485 Perifere enheder P arallel B us LCD display Figur 2.3: Grænseflader for det totale bilbussystem. 13

KAPITEL 3. PROBLEMFORMULERING Kapitel 3 Problemformulering I indledningen på side 3 blev den grundlæggende problemstilling for systemet beskrevet. Herefter blev der i kapitel 2 opstillet en kravspecifikation efter SPU-modellen. Mange af kravene i denne kravspecifikation er fastsat af projektgruppen, og har derfor ingen direkte parallel til markedets nuværende efterspørgsel indenfor Bilbus området - de er udelukkende valgt på baggrund af antagelser omkring realistiske mål for systemet. Afsnit 2.3 beskriver alle disse funktionskrav til det færdige system, og problemformuleringen lyder heraf: Hvordan konstrueres et bilbus system efter de specificerede krav? 3.1 Problemafgrænsning Der afgrænses fra følgende områder af problemstillingen: PC-program udvikles efter eksisterende programmer på markedet Dette punkt afgrænses væk, idet en undersøgelse af nuværende produkter på markedet ville være tidskrævende og udenfor fokus af projektet. Systemets maksimale pris på 10.000.- DKK. Der tages i udviklingen ingen særlige prishensyn ved valg af hardware. Dette skyldes, at der i projektet kun udvikles 3 perifere enheder. Der fremstilles også kun en prototype, så forudsætninger for at forudsige enhedsprisen ved eventuel masseproduktion er mangelfulde. Strømforsyning Der konstrueres ingen strømforsyning til systemet. Alle blokke udvikles til at anvende eksisterende forsyningsspændinger på ±5 V eller 12 V. Brugsanvisning Som beskrevet afsnit 2.2.5 er målgruppen for produktet den almindelige bilejer, og der skal skrives en vejledning til anvendelse af produktet. Dette afgrænses væk. 15

KAPITEL 4. ACCEPTTESTSPECIFIKATION Kapitel 4 Accepttestspecifikation 4.1 Indledning Bilbussystemet testes i flere omgange under de forskellige udviklingsfaser. Således testes hardwareopbygningen af minimumsystemet og de perifere enheder enkeltvis vha. softwaretests, hvor et simpelt stykke software programmeres til at benytte enhver hardwarefunktion. Den endelige software til minimumsystemet og de perifere enheder testes vha. simuleringsprogrammer og/eller prototyper, der begge har til formål at fungere som fejlfrie udgaver af den endelige hardware. Den endelige funktionstest af det samlede system udføres vha. accepttesten. 4.1.1 Formål Accepttesten beskrevet i dette kapitel har til formål at teste det endelige bilbussystem, hvori software og hardware er integreret for både minimumsystemet og de perifere enheder. Accepttesten udfærdiges ud fra SPU-modellen [Biering-Sørensen, 2000, 171-212], og der testes op imod kravspecifikationens funktionelle krav beskrevet i kapitel 2 på side 9. 4.1.2 Referencer Accepttesten tester funktionaliteten af minimumsystemet udviklet i del II på side 21 i samspil med lygteenheden, lygtekontrolenheden og olieenheden udviklet i kapitel 12 på side 61. 4.1.3 Testens omfang og begrænsninger Accepttestens omfang er at teste bilbussystemets funktionalitet. Følgende tests udføres ikke: 1. Brugertest af softwareopdatering af minimumsystemet. 2. Kompatibilitetstest for minimumsystemet ved tilføjelse af nye perifere enheder. 3. Volumentest af antal perifere enheder. 4. Generel pålidelighedstest og sikkerhedstest af kommunikationen. Softwareopdatering af minimumsystemet testes ikke, idet softwaren på dette tidspunkt ikke tilbyder denne funktionalitet. Kompatibilitetstesten testes ikke, idet der kun konstrueres 3 perifere enheder integreret i bilbussystemet. Der er således ikke nogen aktuelle testemner til rådighed, idet der ikke er fremstillet perifere enheder fra andre producenter. Volumentesten udføres ikke idet der kun konstrueres tre perifere enheder, hvorved det ikke kan testes om systemet understøtter de specificerede 128 enheder. 17

4.2. TESTEMNER Pålideligheds- og sikkerhedstesten udføres ikke, idet der konstrueres en prototype. Omgivelserne og opbygningen af det endelig system, der skal implementeres i en bil, vil være væsentlig anderledes. Denne test kan derfor først udføres med brugbare resultater, når systemet er færdigudviklet. Udførelsen af disse fravalgte tests kunne med fordel ske i en senere fase, hvor en eller flere perifere enheder udvikles uafhængigt af prototypen. 4.1.4 Godkendelse Kravet for godkendelse af denne accepttest er fuldstændig opfyldelse af alle de opsatte funktionelle krav i kravspecifikationen, dog med undtagelse af de bortafgrænsede krav fra afsnit 3.1 på side 15. Desuden kræver godkendelsen af gode grunde ikke overholdelsen af krav, hvis testemne er uden for accepttestens omfang, som angivet i afsnit 4.1.3. 4.2 Testemner Der er til accepttesten opstillet følgende testemner: 1. Kommunikationstid. Herunder testes det, om bilbussystemet overholder kravet om maksimalt 0.5 s tidsforsinkelse ved udførelse af opgave, som angivet i kravspecifikationen i afsnit 2.5. 2. Interfacetest. Herunder testes brugergrænsefladen som angivet i kravspecifikationen i afsnit 2.4.1. 3. Gennemgang af øvrige krav. Herunder gennemgås resterende krav fra kravspecifikationen. 4.3 Testdesign I dette afsnit designes specifikke test, hvori de opstillede testemner implementeres. Disse stiller ingen krav indbyrdes og kan således udføres i vilkårlig rækkefølge. 4.3.1 Kommunikationstid Formålet med denne test er at undersøge, om tidskravet på maksimalt 0.5 s i udførelsen af en opgave overholdes. Dette udføres ved at assertere en kontakt på lygtekontrolenheden, og måle tidsforsinkelsen til opgaven påbegyndes i lygteenheden. Testen udføres som en blackboxtest, som er specifikt beskrevet i appendiks Q.2 på side 187. 4.3.2 Brugerinterfacetest Brugerinterface testes vha. et spørgeskema, hvor respondenten får mulighed for at anvende bilbussystemet, imens denne udfylder spørgeskemaet. Respondenter udvælges til at være bilejere således, at disse har en baggrund for bedømmelse af bilbussystemet. Brugerinterfacetesten samt spørgeskema er nærmere specificeret i appendiks Q.3 på side 189. 4.3.3 Gennemgang af øvrige krav Denne test udføres ved opstilling af skema med udsagn fra kravspecifikationen, hvori det indføres, om kravet er overholdt. Dette gøres ud fra viden om systemets implementation. Efter gennemgang af kravspecifikationen er tabel 4.1 på næste side fremkommet. 4.4 Testimplementation Testimplementationen angiver, hvilke resultater, der forventes at komme ud af de opstillede tests. 18

KAPITEL 4. ACCEPTTESTSPECIFIKATION Udsagn Resultat Afsnit Eksekverende programkode kan udskiftes fra PC vha. RS232 2.2.4 TS2-MON anvendes 2.3.2 Opbygges med M68k processor 2.3.2 Opbygges med 2 x 128 kbit ROM 2.3.2 Opbygges med 2 x 512 kbit RAM 2.3.2 Indeholder LCD-display, der viser data fra bilbussystemet 2.3.2 Kobles til PC via RS232 2.3.2 Kommunikerer på den serielle bus med selvvalgt protokol 2.3.2 Lygteenhed kan tænde og slukke fire lygter 2.3.3 Lygtekontrolenhed kan styre 4 lygter i lygteenheden 2.3.4 Olieenhed kan lave A/D-konvertering 2.3.5 Brugeren kan vælge mellem vist information på LCD-displayet 2.4.1 Den serielle bus opbygges over RS485 standarden 2.4.2 En instruktion fra brugeren skal være påbegyndt inden 0.5 s 2.5 Tabel 4.1: Funktionskrav fra kravspecifikationen. 4.4.1 Kommunikationstid Heri forventes et decimaltal for den gennemsnitlige kommunikationstid. Denne må ifølge kravet ikke overstige 0.5 s. 4.4.2 Interfacetest Heri forventes en tabel med antallet af vægtede svar vist i forbindelse med de stillede spørgsmål. 4.4.3 Gennemgang af øvrige krav Heri forventes en tabel over funktionelle krav fra kravspecifikationen, samt en angivelse af, om kravet er overholdt eller ej. 4.5 Bilag Målerapporten for de udførte tests kan findes i appendiks Q på side 187, mens en vurdering af resultaterne kan læses i kapitel 17 på side 115. 19

Del II: Minimumsystem Denne del indeholder en dybdegående beskrivelse af de forskellige dele i minimumsystemet. Der startes med en gennemgang af Motorola 68000 processoren, hvor benforbindelser, registre, reset-kredsløb og clock-generator beskrives. Herefter følger en beskrivelse af RAM og ROM for minimumsystemet, hvor timingen af writeog read cycles undersøges. Interrupthandleren til processoren konstrueres i følgende kapitel, og efterfølgende beskrives de to ACIA er, der benyttes i systemet. Kapitel 9 indeholder en beskrivelse af det anvendte display, hvor blandt andet funktionalitet og timing beskrives. Der opskrives en memory map for systemet i kapitel 10, hvorefter en adressedekoder konstrueres. Sidste kapitel i denne del indeholder en undersøgelse af strøm- og kapacitetsbelastningerne af M68k processoren. Del II: Minimumsystem 21 5 Motorola 68000 processor 23 5.1 Intern opbygning........................................... 23 5.2 Benforbindelser............................................ 24 5.3 Clock-kredsløb............................................ 26 5.4 Reset-kredsløb............................................ 27 5.5 Delkonklusion............................................. 28 6 Memory 29 6.1 RAM- og ROM-kredse........................................ 29 6.2 Timing for valgte kredse....................................... 29 6.3 Delkonklusion............................................. 33 7 Interrupt handler 35 7.1 Krav.................................................. 35 7.2 Konstruktion............................................. 35 7.3 Delkonklusion............................................. 37 8 ACIA 39 8.1 RS232................................................. 39 8.2 RS485................................................. 40 8.3 Delkonklusion............................................. 43 9 Display 45 9.1 Funktionalitet............................................. 45 9.2 Timing................................................. 46 9.3 Delkonklusion............................................. 48

10 Memory mapping 49 10.1 Krav.................................................. 49 10.2 Adressedekoder............................................ 50 10.3 DTACK -generator........................................... 52 10.4 Delkonklusion............................................. 53 11 Belastning af M68k 55 11.1 Belastningsberegning for adressebus................................ 55 11.2 Belastningsberegning for databus.................................. 56 11.3 Belastningsberegning for kontrolbus................................ 57 11.4 Delkonklusion............................................. 57

KAPITEL 5. MOTOROLA 68000 PROCESSOR Kapitel 5 Motorola 68000 processor Som nævnt i kravspecifikationen opbygges minimumsystemet med Motorolas 68000 mikroprocessor (M68k) som central processeringsenhed (CPU). I dette kapitel gennemgås processorens overordnede specifikationer i form af opbygning og arbejdsmetode. Desuden konstrueres en clock-generator til generering af processorens clock-frekvens og et reset-kredsløb til opstart og genstart af minimumsystemet. 5.1 Intern opbygning M68k indeholder, udover beregningsmodulet ALU (aritmetisk logisk enhed), også intern hukommelse, der i forhold til ekstern hukommelse er hurtigere at læse fra og skrive til. Hukommelsen består af 4 typer registre; 8 stk. 32 bit dataregistre, 8 stk. 32 bit adresseregistre, en 32 bit programcounter og et 16 bit statusregister. Registrene vil i de følgende afsnit blive beskrevet enkeltvis. 5.1.1 Dataregister I dataregistrene D07 til D00 kan udføres byte, word, longword og quadword operationer. Byte- og word data gemmes i de laveste bit, mens et longword optager et helt register. Quadword kan gemmes i to registre uden hensyntagen til placering [M68KPM.pdf, 1992, s. 1-2, 1-25, 1-29]. 5.1.2 Adresseregister Adresseregistrene A07 til A00 anvendes til software stackpointere eller basale adresseregistre. De basale adresseregistre kan anvendes til word og longword operationer [M68KPM.pdf, 1992, s. 1-2]. 5.1.3 Programcounter Programcounter peger på adressen for den igangværende instruktion. Processoren sørger selv for at flytte programcounteren til adressen for næste instruktion [M68KPM.pdf, 1992, s. 1-3]. 5.1.4 Statusregister Statusregistret kan ses i figur 5.1 og anvendes af mange instruktioner til indikation af resultatet. Størrelsen af registret afhænger af det brugerniveau, der arbejdes på. En M68k er opbygget med to niveauer, hvor brugere med forskellige rettigheder kan eksekvere forskellige instruktioner. Under usermode kan kun de 8 mindst betydende bit benyttes, hvilke også benævnes CCR (Condition Code Register). C anvendes til overførsel af menter fra beregninger, V angiver, at et resultat ikke kan være i datastørrelsen, Z angiver, at resultatet er nul, N angiver, at resultatet er negativt og X anvendes som en udvidelse af C. Alle registre er aktivt høje. Supervisormode har højest privilegium, og derfor er statusregistret udvidet til 16 bit, hvor den øverste byte indeholder interruptmaske (I2-I0), om det er master eller interrupt mode (M), om det er user- eller 23

5.2. BENFORBINDELSER SYSTEM BYTE USER BYTE (Condition Code Register) 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1 0 T1 T0 S M 0 I2 I1 I0 0 0 0 X N Z V C TRACE ENABLE SUPERVISOR/USER STATE MASTER/INTERRUPT STATE INTERRUPT PRIORITY MASK CARRY OVERFLOW ZERO NEGATIVE EXTEND Figur 5.1: Bitoversigt over statusregistret i M68k. supervisor mode (S), og der kan vælges trace. M68k indeholder en trace funktion, der i stil med trap og NMI kan bruges til fejlfinding. Ved at sætte tracebit logisk høj, stoppes programafviklingen efter hver instruktion, hvorefter statusregistret og programcounterens værdi gemmes til en trace-vektor [M68KPM.pdf, 1992, s. 1-3 - 1-4,1-10 - 1-11]. 5.1.5 Stackpointer Når der generelt refereres til stackpointeren, menes der M68k ens hardware stackpointer, der gemmes i adresseregister A7. En stackpointer peger på adressen på det næste element på stacken [M68KPM.pdf, 1992, s. 1-2]. 5.2 Benforbindelser På figur 5.2 ses mikroprocessorens ind- og udgange funktionsopdelt. I de følgende afsnit vil funktionerne samt de benyttede ben blive beskrevet. V CC(2) GND(4) CLK Adresse bus Data bus A23 - A10 D15 D00 AS* Processor status FC0 FC1 FC2 M68k R/W* UDS* LDS* DTACK* Asynkron buskontrol Synkron buskontrol E VMA* VPA* BR* BG* BGACK* Busarbitration kontrol System kontrol BERR* RESET* HALT* IPL0* IPL1* IPL2* Interrupt kontrol Figur 5.2: Funktionsopdeling af M68k ens ind- og udgangssignaler [Clements, 1997, s. 3-1]. 24

KAPITEL 5. MOTOROLA 68000 PROCESSOR 5.2.1 Adressebus M68k bruger en speciel 24 bit adressebus til adressering af den op til 16 MB store hukommelse. Den er speciel, idet ben A00 er erstattet af de to ben UDS (Upper DataStrobe) og LDS (Lower DataStrobe) fra den asynkrone buskontrol. Denne opbygning gør det muligt at adressere data både i byte og word registre. Sagt med andre ord bruges UDS og LDS til at aktivere enheder tilsluttet hhv. den øverste og den nederste halvdel af databussen [MC68000UM.pdf, 2005, s. 3-3 - 3-4]. 5.2.2 Databus M68k arbejder med 16 bit på den eksterne databus, men er konstrueret til også at kunne benytte enheder, der kun har 8 bit databredde. Derfor kan to 8 bit enheder ligge indenfor samme adresseområde, hvis de er tilsluttet hver deres halvdel af databussen. Processoren kan behandle den øverste halvdel af databussen (bit 8-15) som en lige adresse og den nederste halvdel (bit 0-7) som en ulige, eller den kan behandle databussen i sin fulde bredde som en lige adresse. Enhed Registre Bredde [bit] Adresseben Kommentar ROM 128k 8 17 Hukommelse RAM 512k 8 19 Hukommelse ACIA 2 8 1 Data + Status DISPLAY 2 8 1 Data + Kommando Tabel 5.1: Oversigt over registre og adresseben for benyttede enheder i minimumsystemet. For at få en databredde i hukommelsen på 16 bit, er det, som det kan ses af tabel 5.1, nødvendigt med to af hver af de benyttede hukommelsestyper, RAM og ROM. Selv ved operation med 8 bit, vil det, som beskrevet, være nødvendigt at tilslutte hukommelse til begge halvdele af databussen for at kunne bruge både lige og ulige adresser [MC68000UM.pdf, 2005, s. 3-4 - 3-5]. 5.2.3 Asynkron buskontrol Til brug ved asynkron buskontrol findes der udover over de to allerede nævnte ben, LDS og UDS, også AS (Adress Strobe), R/W (Read/Write) og DTACK (Data Transfer Acknowledge). AS benyttes til indikation af adressebussens gyldighed. R/W fortæller, om processoren ønsker at bruge bussen til en read- eller write cycle. DTACK angiver, hvorvidt mikroprocessorens data er overført via bussen. DTACK skal således først asserteres, når enheder tilknyttet bussen har modtaget dens data, da M68k fjerner bussens data ved dennes assertering. En sådan asserteringsenhed, der tager højde for hastigheden på databussens enheder kaldes en DTACK -generator [MC68000UM.pdf, 2005, s. 3-4 - 3-5]. 5.2.4 Busarbitration kontrol Busarbitration kontrollen anvendes i systemer med perifere enheder, der kan overtage masterstatus og dermed retten til dataoverførsel via bussen. I sådanne systemer anvendes BR (Bus Request) af perifere enheder til at bede om masterkontrollen af mikroprocessoren. BG (Bus Grant) fortæller perifere enheder, at processoren giver masterkontrollen til en anden enhed, mens BGACK (Bus Grant Acknowledge) anvendes til at bekræfte masterovertagelsen. Da der i dette system opbygges et såkaldt singlemaster-system med kun én M68k, bruges ingen ben i busarbitration kontrollen [MC68000UM.pdf, 2005, s. 3-5 - 3-6]. 5.2.5 Interrupt kontrol Interrupt kontrollen styrer indkommende interruptforespørgsler i prioriteret rækkefølge i 7 forskellige niveauer. Niveau 7 er højest og kan som den eneste ikke udmaskes, idet den anvendes til fejlsøgning i programkoden. For at udnytte denne mulighed kan en NMI-tast (Non-Maskable Interrupt) konstrueres. De 7 niveauer gengives på de tre ben IPL0 -IPL2 (Interrupt Priority Level), hvor IPL2 er MSB [MC68000UM.pdf, 2005, s. 3-6]. 25

5.3. CLOCK-KREDSLØB 5.2.6 Systemkontrol Til systemkontrol benyttes benet BERR (Bus Error) til at indikere, at der under den nuværende clock cycle er sket en fejl på bussen. HALT stopper al busaktivitet efter den igangværende clock cycle. RESET kan bruges til reset af perifere enheder, men kan ved samtidig assertering af HALT også bruges til reset af processoren selv. Den sidste funktion anvendes af reset-kredsløbet, der konstrueres i afsnit 5.4 på næste side [MC68000UM.pdf, 2005, s. 3-7]. 5.2.7 Synkron buskontrol Benene under synkron buskontrol anvendes som navnet antyder ved synkron overførsel af data. Ben E (Enable) laver en ti-deling af processorens clock-frekvens samt en duty cycle på 40% og anvendes til synkronisering af dataoverførslen med perifere enheder. Dette signal passer præcis til Motorolas 6800 enheder. VPA (Valid Peripheral Address) angiver, at data på bussen er klar til at blive overført synkront fra en perifer enhed, mens VMA (Valid Memory Address) angiver dette den modsatte vej [MC68000UM.pdf, 2005, s. 3-8]. 5.2.8 Processorstatus Processoren bruger de tre ben FC0-FC2 til at indikere status med et binært mønster. Der indikeres bl.a., om der køres i user- eller supervisormode [MC68000UM.pdf, 2005, s. 3-8 - 3-9, 6-2]. 5.3 Clock-kredsløb For at det er muligt for M68k at udføre programkode, skal den have en takt at operere efter. På den måde kan f.eks. en ny instruktion hentes ind fra programhukommelsen præcist, når den igangværende er udført. Takten, der kan opereres ved, er maksimalt en frekvens på 12.5 MHz, men her er valgt 8 MHz. Ifølge databladet kan en M68k arbejde ved denne clock-frekvens, hvis den får tilført et pulstog på clock-benet (CLK), hvor perioden er mellem 125 ns og 250 ns og pulsbredden mellem 55 ns og 125 ns. Desuden må pulstogets stige- og faldtid maksimalt være på 10 ns mellem de to logiske niveauer V IH på 2 V og V IL på 0.8 V [MC68000UM.pdf, 2005, s. 10-8]. Som pulsgenerator kan der med fordel benyttes en integreret krystaloscillator, idet den som integreret kreds er langt mere stabil overfor temperaturændringer end et quartz-krystal. TTL-kredsen MCO 1425B benyttes i opbygningen af kredsløbet, da den ved en frekvens på 8 MHz vil have en periode på 125 ns og en pulsbredde mellem 50 ns og 75 ns. Pulsbredden kan i værste tilfælde være under kravet. Hvis dette bliver et problem, er det derfor nødvendigt at forlænge bredden. Dens to logiske udgangsniveauer er V OH på 2.4 V og V OL på 0.4 V. Stige- og faldtiden kan være på op til 15 ns, men typisk vil også denne tid overholde kravet på 10 ns fra processoren [MCO1425B.pdf, 1993]. Processorens clock-indgang trækker 2.5 µa [MC68000UM.pdf, 2005, s. 10-8], mens krystaloscillatorens udgang har en fan out 10 specifikation [MCO1425B.pdf, 1993]. Fan out angiver det antal standard indgange, der kan tilsluttes en udgang og er i dette tilfælde 10. Omregnet til en strøm svarer det til 400µA, hvilket er nok til drift af M68k [Holten, 1982]. Ifølge databladet skal krystaloscillatoren have en stabiliseringskondensator C 01 på 15 pf til opretholdelse af dens egenfrekvens på 8 MHz. Derudover indsættes modstanden R 13 på 390 Ω og 1N4148 dioderne D 03 D 06, der skal sørge for at krystaloscillatoren overholder TTL-kredses udgangsspændinger. Da det i databladet ikke er specificeret, at der skal bruges 1N4148 dioder, undersøges det, hvorvidt de andre komponenter er dimensioneret efter disse [MCO1425B.pdf, 1993]. Dioderne har en maksimal strømgrænse på 200 ma. Med R 11 på den pågældende værdi vil grænsen ikke blive overskredet, da der løber en strøm på ca. 13 ma. Ved den valgte V CC på 5 V har dioderne en kapacitiv virkning på 0.85 pf og ændrer derfor ikke meget på den samlede kapacitive belastning [1N4148.pdf, 2004]. Det samlede clock-kredsløb ses på figur 5.3. 26

KAPITEL 5. MOTOROLA 68000 PROCESSOR Clock VCC R13 VCC 14 08 VCC OUT IC01 MCO 1425 B 8 MHz NC GND 01 07 D03 D04 D05 D06 C01 Figur 5.3: Kredsløbsdiagram over clock-kredsløb til M68k. 5.4 Reset-kredsløb Ifølge databladet kræver M68k, at den resettes ved at assertere RESET og HALT i mindst 100 ms under opstart. I denne fase stabiliseres bl.a. forsyning og clock-kredsløbet således, at processoren under drift kan udføre programkoden regelmæssigt. Af samme grund er det nødvendigt, at der resettes i 10 clock cycles, hvis forsyningen bliver genoprettet efter at have været ustabil [MC68000UM.pdf, 2005, s. 5-29]. Til udførelse af disse to operationer anvendes en TL7705A, der er en supply-voltage supervisor i en integreret kreds. Kredsen er specielt udviklet til at resette mikroprocessorsystemer vha. overvågning af spændingsforsyningen, og dens funktion kan forklares ud fra figur 5.4 og det samlede kredsløb på figur 5.5. V CC og SENSE Tærskel spænding V CC 3.6V V CC 2V RESET t d t d Udgang udefineret Udgang udefineret Figur 5.4: Timingsdiagram for reset-kredsløb [TL7705A.pdf, 2003, s. 3]. Under opstart af mikroprocessoren er RESET først defineret for SENSE omkring 3.6 V, hvorfra RESET asserteres. For at sikre en bestemt reset-tid, holdes asserteringen i en tid t d, fra når en tærskelspænding V reset på typisk 4.55 V nås. Efter denne tid negeres RESET. Hvis SENSE-niveauet under driften skulle falde til under tærskelspændingen, asserteres RESET. Når spændingsniveauet på SENSE igen stiger til over tærskelspændingen, tæller t d igen ned til en assertering af RESET. Ved afbrydelse af kredsen falder spændingen på SENSE og RESET holdes asserteret til omkring 2 V, hvorefter udgangen er udefineret [TL7705A.pdf, 2003, s. 2]. Den valgte TL7705A-kreds implementeres ud fra eksemplet i [TL7705A.pdf, 2003, s. 7], der er til en Texas Instruments processor, og derfor skal omdimensioneres ud fra specifikationerne på M68k. Både RESET og HALT på mikroprocessoren skal kontrolleres, og derfor deles RESET på TL7705A ud til begge. Der indsættes dioder D 01 og D 02 i de to signalveje, da RESET og HALT på M68k både er ind- og udgange og derfor uden dioder vil kunne påvirke hinanden. Ifølge [MC68000UM.pdf, 2005, s. 10-8] må både RESET og 27

5.5. DELKONKLUSION HALT maksimalt have en indgangsspænding V IL på 0.8 V for at kunne resette. Det er derfor nødvendigt at benytte schottky dioder, da disse har et mindre spændingsfald over sig. Disse vælges til at være af typen BAT85. RESET på TL7705A har en udgangsspænding V OL på maksimalt 0.4 V, hvilket betyder, at det med diodernes spændingsfald på ca. 0.4 V, er muligt at holde sig under grænsen [TL7705A.pdf, 2003, s. 4]. I den tid, hvor mikroprocessoren ikke resettes, holdes indgangene høje af to pullup-modstande R 02 og R 03. Mikroprocessoren har en lækstrøm på 20 µa [MC68000UM.pdf, 2005, s. 10-7] og reset-kredsen en lækstrøm på 50 µa [TL7705A.pdf, 2003, s. 4]. Modstandenes maksimale størrelse kan nu beregnes ud fra denne strøm og ud fra, at RESET og HALT skal have en spænding V IH på minimum 2 V [MC68000UM.pdf, 2005, s. 10-7] ud af forsyningens 5 V. R 02 = R 03 = 5 V 2 V = 43 kω (5.1) 20 µa + 50 µa Standardværdien 10 kω vælges for at garantere et højt niveau, idet spændingen på indgangene herved er 4.3 V. For at give mulighed for manuelt reset, indsættes en kontakt S 01 der trækker RESIN til stel, hvilket vil sætte en reset-periode t d igang, når tasten slippes. Der indsættes i den forbindelse en pullup-modstand R 01 på 10kΩ mellem V CC og RESIN. For at fjerne transienter i forsyningsspændingen indsættes en afkoblingskondensator C 03 på 0.1 µf til REF. Den mindste reset-tid t d bestemmes af C 02 ud fra følgende ligning [TL7705A.pdf, 2003, s. 2]. t d = 1.3 10 4 C 02 [s] (5.2) Da de 10 clock cycles ved 8 MHz ikke overstiger de 100 ms, sættes t d til denne tid, når kondensatorværdien udregnes. t d C 02 = 1.3 10 4 = 0.1s = 7.69 µf (5.3) 1.3 104 Standardværdien 10 µf vælges, hvilket giver en tid på t d = 130ms. Det samlede kredsløb kan ses i figur 5.5. VCC 08 R01 VCC R02 R03 07 S01 02 03 SENSE RESIN* RESET* IC02 TL7705A RESET CT RESET C02 GND 04 REF 05 06 01 C03 D01 D02 RESET* HALT* Figur 5.5: Kredsløbsdiagram over reset-kredsløb til M68k. 5.5 Delkonklusion I dette kapitel er opbygning og arbejdsmetode for M68k kort blevet gennemgået. Det værende af to omgange i form af den interne opbygning med registrene og den udefra sete opbygning med benforbindelser inddelt i forskellige funktioner. Der er i kapitlet desuden blevet konstrueret et clock-kredsløb til generering af processorens clock-frekvens. Kredsløbet blev bygget op om en 8 MHz MCO 1425 B krystaloscillator. Yderligere er et reset-kredsløb konstrueret, hvis formål er, gennem overvågning af forsyningsspændingen, først at sætte processoren i drift ved stabil forsyning. Desuden er en reset-tast indsat til manuelt reset. Kredsløbet er bygget op om en TL7705A supply-voltage supervisor. 28

KAPITEL 6. MEMORY Kapitel 6 Memory I dette kapitel beskrives memory-elementerne i minimumsystemet. De valgte RAM- og ROM-kredse vil blive kort beskrevet, hvorefter timingsdiagrammer vil blive gennemgået. For generel information om timingen ved adressering af memory-kredse med M68k processoren henvises til appendiks C på side 137. 6.1 RAM- og ROM-kredse Der er fra komponentudleveringen på universitetet udleveret RAM af typen HM628512 og ROM af typen AM29F010B. Begge kredse har en hukommelse på 8bit pr. adresse, hvorfor der må indsættes to éns kredse til henholdsvis øvre og nedre del af databussen for at udnytte M68k ens mulighed for at adressere 16 bit words. Den udleverede RAM type har 512k adresser pr. kreds, hvorved den samlede RAM kapacitet for systemet bliver på 1MB. Den udleverede ROM type har 128k adresser pr. kreds, hvorved den samlede ROM kapacitet for systemet bliver 256kB. 6.2 Timing for valgte kredse I dette afsnit beskrives timingen for RAM- og ROM-kredse. Dette gøres for at undersøge, om en DTACK - generator er nødvendig i kredsløbet. Fra appendiks C på side 137 fremgår det, at adressen fra processoren er klar på adressebussen ca. 3 clock cycles før overgangen mellem state S6 og S7 i processoren [Clements, 1997, side 306]. Ved denne overgang skal data jvf. appendikset have været klar på databussen i tiden t DICL. Tiden fra S0 til adresserne er stabile på adressebussen benævnes t CLAV. Tiden t P D angiver propagation delay gennem chipselectkredsløbet designet i kapitel 10.2 på side 50. Endelig angiver tiden t CHSL, hvor længe adressen skal være tilgængelig på adressebussen, før AS, LDS og UDS asserteres. Disse størrelser vil i det efterfølgende blive anvendt til beregning af minimumskravene til hastigheden af memorykredsene. 6.2.1 Read cycle for RAM Den valgte RAM-kreds styres af de tre signaler CS RAM, OE RAM og WE RAM. CS RAM aktiverer kredsen og trigger på faldende flanke. Dette ben kontrolleres ligesom output-enable OE RAM af chipselect fra adressedekoderen beskrevet i afsnit 10.2 på side 50. WE RAM asserteres, når der skrives til RAM-kredsen og negeres, når der læses fra denne. Hvis OE RAM er negeret, udviser benet en tristate tilstand og er dermed afkoblet fra bussen. Benet asserteres, når der skal læses fra RAM. Ovenstående beskrivelse fremgår ligeledes af timingsdiagrammet i figur 6.1 for RAM-kredsen. 29

6.2. TIMING FOR VALGTE KREDSE t RC A 00 A 16 Adresser stabile CS* RAM t ACC t ACS OE* RAM t CLZ t CHZ D 00-D 07 Data gyldig Figur 6.1: Timingsdiagram for read cycle af RAM [HM628512.pdf, 1994]. De på figur 6.1 angivne tider kan aflæses i tabel 6.1. Det ses udfra dette, at adresserne skal være stabile på adressebussen i minimum tiden t RC - der kan altså minimum gå denne tid mellem hver læsning fra RAMkredsen. Det ses desuden af figur 6.1, at data bliver klar på databussen maksimalt tiden t CLZ efter CS RAM er blevet asserteret. Der går imidlertid tiden t ACC, før disse data bliver gyldige, hvilket på figuren er illustreret med en skravering. Maksimalt tiden t CHZ efter CS RAM atter er negeret, er data taget af databussen igen. Dette giver følgende krav til tiden t ACC for RAM-kredsen: t ACC < 3.0 t cyc t CLAV t DICL t P D (6.1) t ACC < 3.0 125 ns 62 ns 15 ns 25 ns (6.2) t ACC < 273.0 ns (6.3) I tabel 6.1 aflæses den maksimale t ACC for RAM-kredsene til 70 ns, hvorfor indsættelse af wait states ikke bliver nødvendig. Hermed kræver RAM-kredsene ingen DTACK -generator - deres data leveres hurtigt nok til processoren. Symbol Betegnelse min. [ns] maks. [ns] t RC Read cycle time 70 - t ACC = t AA Address access time - 70 t ACS = t CO CS access time - 70 t CLZ = t LZ CS output set time 10 - t CHZ = t HZ CS output floating - 25 Tabel 6.1: Timingstider for read cycle af RAM [HM628512.pdf, 1994]. Der stilles desuden krav til RAM-kredsens t ACS, som angiver tiden fra AS, LDS og UDS asserteres til data bliver tilgængelige. Denne tid kan beregnes til: t ACS < 3.0 t cyc t CHSL t DICL t P D (6.4) t ACS < 3.0 125 ns 60 ns 15 ns 25 ns (6.5) t ACS < 275.0 ns (6.6) Tiden t ACS kan i tabel 6.1 aflæses til 70 ns, hvorfor kravet er overholdt. 6.2.2 Write cycle for RAM Write cycle timingsdiagrammet for den valgte RAM-kreds ses på figur 6.2. 30

KAPITEL 6. MEMORY t WC A 00 A 16 Adresser stabile CS* RAM t AW t WR t AS WE* RAM t WC D 00-D 07 fra M68k t DW t WC D 00 -D 07 skrives Figur 6.2: Timingsdiagram for write cycle af RAM [HM628512.pdf, 1994]. De på figur 6.2 angivne tider kan aflæses i tabel 6.2. Udfra disse ses det, at adresserne skal være gyldige i minimum t AS før WE RAM asserteres. Yderligere skal data være gyldige i tiden t W R efter WE RAM er blevet negeret. Symbol Betegnelse min. [ns] t W C Write cycle time 70 t W R Address-hold time 5 t AW Address-valid to end of write 60 t AS Address-setup time 0 t W P Write pulse-width 50 t DW Input data set-time 30 t DH Input data hold-time 0 Tabel 6.2: Timingstider for write cycle af RAM [HM628512.pdf, 1994]. For at undersøge muligheden for tidsmæssige problemer mellem M68k og de tilsluttede RAM-kredse ved en write cycle, opstilles tabel 6.3. Tiderne opstillet i kolonnen for M68k stammer fra appendiks C på side 137. RAM symbol M68k symbol(er) RAM min. krav [ns] Værdi [ns] t W C t AV SL + t SL + t SHAZ 70 340 t W R t SHAZ 5 40 t AW t AV SL + t SL 60 300 t AS t AV SL 0 20 t W P t SL + t ASRV 50 260 t DW t DOSL + t SLw 30 180 t DH t SHDOI 0 40 Tabel 6.3: Timingstider for read cycle af RAM [HM628512.pdf, 1994] [Clements, 1997]. Som det ses af tabel 6.3, er alle timingskrav overholdt i en write cycle for RAM-kredsene - det er altså ikke nødvendigt at indsætte wait states. 31

6.2. TIMING FOR VALGTE KREDSE 6.2.3 Read cycle for ROM Den valgte ROM-kreds styres af de tre signaler CE ROM, OE ROM og WE ROM. CE ROM aktiverer kredsen og trigger på faldende flanke. Dette ben kontrolleres ligesom output enable OE ROM af chipselect fra adressedekoderen beskrevet i afsnit 10.2 på side 50. Når der læses fra ROM, skal WE ROM være negeret. I systemets tilfælde skal der kun læses data fra de tilsluttede ROM-kredse, hvorfor WE ROM holdes permanent høj. Ovenstående beskrivelse fremgår ligeledes af timingsdiagrammet i figur 6.3 for ROM-kredsen. t RC A 00 A 16 Adresser stabile t ACC CE* ROM OE* ROM t OE t DF t OEH t CE WE* ROM t OH D 00-D 07 Data gyldig Figur 6.3: Timingsdiagram for read cycle af ROM [AM29F010B.pdf, 2002]. De på figur 6.3 angivne tider kan aflæses i tabel 6.4. Det ses af timingsdiagrammet, at ROM efter chipselect via CE ROM har data klar på databussen efter tiden t CE. Når CE ROM negeres, holdes data på databussen i tiden t OH. Dette giver følgende krav til tiden t CE for ROM-kredsen: t CE < 3.0 t cyc t CHSL t DICL t P D (6.7) t CE < 3.0 125 ns 60 ns 15 ns 25 ns (6.8) t CE < 275.0 ns (6.9) I tabel 6.4 aflæses den maksimale t CE for ROM kredsene til 90 ns, hvorfor indsættelse af wait states ikke bliver nødvendig. Hermed kræver ROM-kredsene ingen DTACK -generator - deres data leveres hurtigt nok til processoren. Symbol Betegnelse min. [ns] maks. [ns] t RC Read cycle time 90 - t ACC Address access-time - 90 t CE CE to output delay - 90 t OE Output enable to output delay - 35 t DF CE/OE to output high Z - 20 t OEH OE hold-time 0 - t OH Output hold-time 0 - Tabel 6.4: Timingstider for read cycle af ROM [AM29F010B.pdf, 2002]. 32

KAPITEL 6. MEMORY 6.3 Delkonklusion Der blev i dette kapitel regnet på 512kB RAM af typen HM628512 og 128kB ROM af typen AM29F010B til minimumsystemet. Disse kredse har kun mulighed for lagring af 8 bit pr. adresse, hvorfor det er nødvendigt med to af hver for at udnytte M68k processorens mulighed for word adressering. Timingsberegninger mellem processor og de tilsluttede memory-kredse viste, at det i ingen tilfælde var nødvendigt at indsætte wait states vha. en DTACK -generator. 33

KAPITEL 7. INTERRUPT HANDLER Kapitel 7 Interrupt handler Interrupts anvendes i bilbussystemet bl.a. i forbindelse med TS2-MON. Her anvendes interrupt niveau 7 til at stoppe M68k ens løbende eksekvering og overdrage kontrollen til TS2-MON. Desuden anvendes to taster til styring af displayet. Disse placeres på interrupt niveau 1 og 2. Formålet er at opbygge en enhed, der kan tilsluttes M68k-processoren og omsætte interrupt forespørgsler til en signalform der passer til M68k specifikationer. 7.1 Krav Der stilles følgende krav til interrupthandleren: Håndtere 8 forskellige interrupt niveauer. Hvert interrupt niveau skal kunne kaldes uafhængigt. Der skal tilkobles en NMI kontakt på interrupt niveau 7 Der skal tilkobles to kontakter, på interrupt 1 og 2 7.1.1 Afgrænsning Til minimumsystemet anvendes kun interrupt niveau 7, 2,1 og 0, hvorfor der kun implementeres en opkobling til disse. Systemet kan senere udvides til at håndtere de resterende fire niveauer. 7.2 Konstruktion M68k processoren har tre indgange hvorpå interrupts kan angives. Dette er IPL0, IPL1 og IPL2. Herpå sættes interrupt niveauet efter ligningen IRQ = 7 n, hvor n er et tal dannet binært ud fra IPL-benene, med IPL0 som LSB. M68k processoren tilbyder 2 interrupt håndterings muligheder, vector interrupts og autovector interrupts. Vector interrupts fungerer ved at M68k processoren bekræfter modtagelsen af et interrupt request vha. assertering af FC0 - FC2, kaldt et IACK signal (Interrupt ACKnowledge). Herefter afventer M68k processoren en interrupt vektor på databussens D00 - D07. Denne vektor angiver hvilken kode der skal afvikles i interruptet. Dette giver mulighed for mange interrupts, men stiller også det krav at kaldende enheder skal kunne angive en vektor på databussen. Autovector interrupts fungerer ved at M68k processoren bekræfter modtagelsen af et interrupt forespørgsel, hvorpå de kaldende enheder asserterer VPA, hvilket medfører at M68k anvender en internt defineret vektor til udførelsen af interrupt. Dette giver en begrænsning, idet der maksimalt kan udføres 7 forskellige interrupts, men enheder i minimumsystemet kan holdes simple, idet disse ikke skal angive 35

7.2. KONSTRUKTION en vektor på databussen. I systemet skal der anvendes fire interrupt niveauer, hvorfor autovector interrupts vælges, idet at de specificerede krav kan overholdes med denne metode, og at autovector interrupts er simplere at implementere end vector interrupts. Til placering af interrupt niveau på IPL anvendes en 8 til 3 konverter, således at tilkoblede enheder ikke skal fremstille et binært tal på tre bit, men blot assertere en bestemt indgang på 8 til 3 konverteren. Til formålet anvendes en 74HC148, der er en prioriteret 8 til 3 konverter. Fordelen i prioriteringen er, at kun den højeste interrupt forespørgsel sendes videre til M68k. Af datablad for 74HC148 [74HC148.pdf, 1984, s. 2] ses det, at dennes indgange er aktive lave. Derfor monteres pullup-modstande på hvert indgangsben så der skal sættes stel til en indgang, før denne bliver aktiveret. Benene E0 og GS anvendes hvis 74HC148 skal kaskadekobles, hvilket ikke er tilfældet her. Derfor sættes disse til ikke at have nogen forbindelse. Af tabel 7.1 ses et uddrag af sandhedstabellen for 74HC148. Benene IRQx skal opfattes som indgange på 74HC148. M68k ens IPLx ben forbindes til udgangene A0 - A2 på 74HC148. For anvendelse af autovector interrupts Niveau IRQ1 IRQ2 IRQ3 IRQ4 IRQ5 IRQ6 IRQ7 IPL2 IPL1 IPL0 7 X X X X X X 0 0 0 0 6 X X X X X 0 1 0 0 1 5 X X X X 0 1 1 0 1 0 4 X X X 0 1 1 1 0 1 1 3 X X 0 1 1 1 1 1 0 0 2 X 0 1 1 1 1 1 1 0 1 1 0 1 1 1 1 1 1 1 1 0 0 1 1 1 1 1 1 1 1 1 1 0 = logisk lav, 1 = logisk høj, X = don t care. Tabel 7.1: Uddrag af sandhedstabel for 74HC148 [74HC148.pdf, 1984, s. 2]. skal VPA asserteres efter M68k ens IACK-signal. Derfor føres FC0 - FC2 til PEEL02, der udfører en logisk AND-operation og sender signalet videre som VPA. Signalet overføres gennem PEEL01, idet denne i forvejen er koblet til VPA på M68k pga. adresse-dekodning. Kildekoden til PEEL-koden ses i appendiks E på side 145. Interrupt niveau 7 er defineret som non-maskable interrupt. Denne anvendes til at give TS2-MON kontrollen over processoren. Denne indføres som debugging-værktøj, og implementeres i en kontakt. For at undgå prelproblemer og udefinerede states, indsættes en SR-latch før 8 til 3 converteren. Denne latch implementeres i PEEL02. Interrupt-niveau 1 og 2 implementeres vha. kontakter. For at undgå prelproblemer indsættes en inverter med Schmitt trigger indgang, således at udgangsniveauet altid er defineret [Wakerly, 2001, s. 124]. Disse signaler føres igennem en SR-latch til 8-3 konverteren. Fra PEEL02 føres VPA tilbage til SR-latchen, og anvendes til at nulstille interrupt-niveauet på 8-3 converteren. For at undgå gentaget assertering af SRlatchens indgangsben, indsættes et RC-led før inverteren, således at et tryk på kontakterne kun medfører en kort impuls på inverterens indgang. Opkoblingen til interrupt 1 og 2 ses i figur 7.1 på modstående side. Til højre på figuren ses op- og afladetider. Den prikkede linje angiver spændingen over C 38. Kontakten S 03 sluttes til t = 0. Denne brydes igen til tiden T. Lige efter t = 0 vil kondensatorens impedans være meget lille. Herefter, under opladningen igennem R 39, stiger dens impedans, og dermed spændingen over den. Efter tiden T brydes kontakten igen, hvorefter kondensatoren aflades gennem R 38. Tidskonstanten for kondensatorens opladning (τ 1 ), kondensatorens afladning (τ 2 ) samt den mindste spænding med kontakten sluttet beregnes til: 36 τ 1 = 100 kω 100 nf = 0.1 s (7.1) τ 2 = 10 kω 100 nf = 0.01 s (7.2) V 1min = 10 kω 5 V 0.45 V 100 kω + 10 kω (7.3)

KAPITEL 7. INTERRUPT HANDLER Her ses bort fra kondensatorens afladning gennem R 38 ved opladningen (t < T ). Den minimale spænding opnås efter 5τ 1. Ifølge databladet for inverteren [74hc14.pdf, 2003, s. 10], er minimum niveauet for en lavt gående spænding på 0.9 V, hvorved opstillingen vil udføre sin opgave korrekt. Vcc Vcc [V] V2 R38 C38 V1 V2 V1 0.45V S03 R39 Til SR-latch reset 0 [t] Komponent R 38 R 39 C 38 0 Værdi 100 kω 10 kω 10 nf 5τ1 T T+5τ2 Figur 7.1: Opkobling af tasterne til interrupt 1 og 2. Tast sluttet til t = 0. Non-maskable interrupt 7 samt interrupt 1 og 2 er implementeret på forskellige tidspunkter i projektforløbet. Dette er begrundelsen for at implementeringen ikke er ens. 7.2.1 Layout Det endelig layout af interrupt handleren ses af figur 7.2 på næste side. 7.3 Delkonklusion I dette afsnit er fremstillet et system til håndtering af interrupts. Den konstruerede interrupt handler kan omsætte interrupt forespørgsler fra andre dele af minimumsystemet, til et format som M68k kan bearbejde. Ydermere håndteres M68k s svar og det dertil hørende krav om assertering af VPA. Interrupt handleren opbygges af en 74HC148, en 74HC14 inverter, tre kontakter, RC-led, SR-latche samt en PEEL-kreds. Interrupt systemet er konstrueret og fungerer med minimumsystemet. 37

7.3. DELKONKLUSION Vcc R04 - R10 R11 R12 02 I0 23 IO0 06 I4 PEEL02 11 I1 12 I2 10 0 16 Vcc E0 GS A0 09 A1 07 27 IPL0* 26 IPL1* S02 I3 05 I2 04 I1 IO1 03 22 13 I3 01 I4 74HC148 A2 06 25 IPL2* M68k 02 I0 PEEL 01 IO7 16 02 I5 03 I6 04 I7 05 08 23 VPA* FC0 FC1 FC2 30 29 28 IC21c 13 12 Vcc Vcc Vcc R38 R40 Vcc C38 C39 R39 IC21d 09 08 IC21e 11 10 02 S 01 R 06 S 05 R 74HC279 SR-latch Q1 04 Q2 07 R39 Komponent R 38 R 39 C 38 R 40 R 41 C 39 Værdi 100 kω 10 kω 10 nf 100 kω 10 kω 10 nf Figur 7.2: Kredsløbsdiagram for minimumsystemets interrupt handler. 38

KAPITEL 8. ACIA Kapitel 8 ACIA Formålet med dette afsnit er at designe to kredsløb, hvori der bliver foretaget parallel-til-seriel konvertering fra databus til serielbus. Det er her ACIA232 og ACIA485 indgår. Der ønskes en forbindelse til en PC over seriel RS232 samt en seriel RS485-forbindelse, hvortil de perifere enheder tilsluttes. De to kredsløb skal jvf. standarderne [EIA, 2005a] [EIA, 2005b] og kravspecifikationen i kapitel 2 på side 9 arbejde ved to forskellige hastigheder og signalniveauer. Dertil bruger RS232 en separat leder til trafik i hver retning samt stel, hvor RS485 bruger de samme ledere i begge retninger uden stel. Dette stiller forskellige krav til designet, hvilket vil blive gennemgået i det følgende. 8.1 RS232 8.1.1 Clock-generator Her designes clock-generatoren til RS232-forbindelsen. Det er et krav fra TS2-MON, at overførslen skal ske ved 9600 bps. En clock-generator til realisering af dette er vist i diagrammet på figur 8.2 på side 41. Her anvendes en CMOS krystaloscillator med standardværdien 2.4576 MHz - se beregning for denne i ligning (8.1). Oscillatoren betegnes IC11. Det er her fordelagtigt at vælge en frekvens, der er meget højere end den ønskede, og derefter dividere den. Gevinsten er, at eventuelle afvigelser i oscillatoren også divideres tilsvarende. En divisionen med 16 foretages i en 74HC4060 divider [74HC4060.pdf, 1990]. Denne bygger på 14 seriekoblede D-latches og kan således dele indgangs-clock en med 2 n, hvor n 14. Den mindst mulige deling er 2 4 = 16, og denne ses på udgangen O03, som er udgangen på den fjerde D-latch. For et opnå den korrekte bitrate, deles clock en yderligere med 16 i ACIA en således, at den endelige frekvens bliver f = 2.4576 MHz 16 16 Pulsvidden t puls på indgangen af ACIA en, med en duty cycle på 50%, bliver da = 9600 Hz (8.1) t puls = T 2 = 1 2 f = 1 2 2.4576 MHz 16 = 3.26 µs (8.2) Kravet jvf. databladet er min. 0.6 µs, så kravet overholdes. Divideren betegnes IC13. Der er koblet en kondensator C 26 på 15 pf på clock-udgangen på oscillatoren. Dette gøres alene for at genskabe forholdene fra målejournalen i appendiks L på side 173, hvor måleproben belaster oscillatoren med 15 pf. Udgangene RTS (Request To Send) og IRQ benyttes ikke. Førstenævnte af den grund, at signaler ud på RS232-forbindelsen kan sendes til enhver tid uden forudgående godkendelse, idet der kun er to enheder på samme forbindelse (PC og minimumsystem). IRQ benyttes ikke, idet ACIA en tilgås vha. polling og ikke vha. interrupt. 39

8.2. RS485 Indgangene CTS (Clear To Send) og DCD (Data Carrier Detect) er begge asserteret, idet ACIA en skal afsende data med det samme, når disse er klar - den skal ikke afvente CTS fra den perifere enhed. DCD funktionen benyttes kun i systemer, hvor modems indgår og er derfor asserteret her. 8.1.2 Transceiverkredsløb til RS232 En RS232 forbindelse anvender jvf. standarden [EIA, 2005a] spændingsniveauer mellem leder og stel på mellem -3 og -25 V for et logisk højt og mellem +3 og +25 V for et logisk lavt signal, hvorimod ACIA en blot anvender 0 V for lav og 5 V for høj - se venstre del af figur 8.1. For at konvertere signalniveauerne fra ACIA en til niveauer, der overholder RS232 standarden, benyttes IC14, som er en RS232 transceiver [MAX232.pdf, 2004]. Transceiveren kan ses i sammen med ACIA en på figur 8.2. ACIA en betegnes IC12. Spændingsforskel V mellem leder og stel +25 RS-232C Spændingsforskel V mellem A og B Output RS-485 Input Logisk lav Udefineret Logisk høj +3-3 Logisk lav Udefineret Logisk høj +6 +2-2 -6 +6 +0.2-0.2-6 tid t -25 Figur 8.1: Niveauer for logisk lav og høj for RS232 og RS485. På figuren ses det, at transceiveren kan drive to RS232-forbindelser, hvoraf kun den ene anvendes. Kondensatorerne C 21 til C 25 supplerer interne stepup og inverter funktioner, der genererer ±10V. Således er der ikke behov for en separat forsyningsspænding forskellig fra +5 V. Værdien på kondensatorerne er anbefalet fra producenten til 0.1 µf. Det ses, at transceiveren ikke har en enable-indgang, og derfor passerer signaler uhindret til enhver tid. Det ses også, at transceiveren inverterer ind- og udgangssignaler, så de opfylder standarden. 8.2 RS485 8.2.1 Clock-kredsløb Den anden ACIA i kredsløbet skal varetage en seriel forbindelse til bussen efter RS485-standarden [EIA, 2005b]. Hastigheden på denne bus er valgt til 115.2 kbps, idet denne hastighed er den øvre begrænsning sat af UART en i mikrocontrollerne på de perifere enheder [AT90S2313.pdf, 2005], [AT90S8535.pdf, 2005] - se kapitel 12 på side 61. En clock-generator til realisering af dette er skitseret på figur 8.3. Her anvendes IC15, som er en standard CMOS krystaloscillator med standardværdien 1.8432 MHz. Der er også her koblet en kondensator C 30 på 15 pf på clock-udgangen på oscillatoren - se afsnit 8.1.1. Frekvensen deles herefter med 16 i en divider 74HC4060 (IC17) som i RS232-kredsløbet. Frekvensen bliver da f = 1.8432 MHz 16 = 115.2 khz (8.3) Med denne deling bliver pulsvidden t puls, ved 50% duty cycle, på indgangen af ACIA en t puls = T 2 = 1 2 f = 1 2 1.8432 MHz 16 Kravet hertil er jvf. databladet min. 0.900 µs på indgangen, og er dermed opfyldt. = 4.34 µs (8.4) 40

KAPITEL 8. ACIA Vcc 14 01 Vcc NC IC11 2.4576MHz CMOS OSC. 08 CLK 07 GND C26 11 12 07 05 04 06 CLK RST O03 O04 O05 O06 IC13 74HC4060 DIVIDER O13 O12 O11 O09 O08 O07 03 02 01 15 13 14 CS D00 D01 D02 D03 D04 D05 D06 D07 E A01 R/W* 12 VCC 08 CS0 10 CS1 09 CS2* 22 D00 21 D01 20 D02 19 D03 18 D04 17 D05 16 D06 15 D07 14 E 11 RS IC12 - M6850 ACIA232 / LDS 03 RxCLK 04 TxCLK 02 RxD 06 TxD 05 RTS* 07 IRQ 24 CTS* 23 DCD* 13 01 R/W* VSS C23 C21 C22 12 09 11 10 01 03 04 05 02 06 R1 OUT* R2 OUT* T1 IN T2 IN C1+ C1- C2+ C2- V+ V- IC14 - MAX232 DRIVER R1 IN R2 IN T1 OUT* T2 OUT* VCC C25 13 08 14 07 +5V 16 C24 RS232 Input / output 03 02 05 9-leder SUB-D hun Figur 8.2: Kredsløbsdiagram for opkobling af RS232 med ACIA, MAX232 transceiver og clock. En anden mulighed ville være at lade ACIA en selv varetage 16-deling internt med clock-frekvensen på 1.8432 MHz direkte på indgangen. I dette tilfælde vil pulsvidden blive følgende: t puls = T 2 = 1 2 f = 1 2 1.8432 MHz = 270 ns (8.5) hvilket er for kort. 8.2.2 Transceiverkredsløb til RS485 RS485 standarden dikterer en halfduplex bidirektionel balanceret signalvej [EIA, 2005b]. Spændingsforskellen mellem terminalerne A og B skal ligge mellem -2 og -6 V for logisk højt signal og mellem +2 og +6 V for logisk lavt signal - se højredel af figur 8.1 på modstående side. Der er altså ligesom ved RS232 byttet om på det, der normalt vil opfattes som høj og lav. Forbindelsen til RS485 etableres med IC18, som er en MAX487 transceiver [MAX487.pdf, 2003]. Kredsen er afbildet på figur 8.3. Kredsen indeholder en receiver og en driver, der hver især enables med benene RE og DE. Grunden til, at der er en enable til hver del er, at det skal være muligt at kontrollere ind- og udgang hver for sig. Dertil skal udgangen kunne tristates, idet mange perifere enheder skal kunne være koblet på den samme forbindelse. RO er receiveroutput og DI er driverinput. A og B udgør den balancerede ind/udgang. RE og DE er i dette tilfælde koblet sammen, idet ACIA en kontrollerer MAX487 eren med én udgang (RTS ). Når DE asserteres, så tristates RO, og dette betyder, at RxD på ACIA en bliver udefineret uden pullupmodstand. Derfor er modstanden R 33 = 4.7k Ω indsat på RO. 8.2.2.1 Terminering af RS485-forbindelse Når der arbejdes med lange ledninger mellem perifere enheder, er det vigtigt at gøre sig overvejelser omkring terminering af ledningernes ender for at undgå refleksioner. Reflekterede signaler kan give anledning til, at 41

8.2. RS485 Vcc 14 01 Vcc NC IC15 1.8432MHz CMOS OSC. 08 CLK 07 GND C30 CLK RST O03 O04 O05 IC17 74HC4060 DIVIDER O13 O12 O11 O09 O08 O06 O07 CS 12 08 10 09 VCC CS0 CS1 CS2* RxCLK TxCLK 03 04 Vcc Vcc RS-485 Balanceret Input / output D00 D01 D02 D03 D04 D05 D06 D07 22 21 20 19 18 17 16 15 D00 D01 D02 D03 D04 D05 D06 D07 IC16 - M6850 ACIA01 / UDS RxD TxD RTS* IRQ 02 06 05 07 R33 01 04 03 02 RO DI DE RE* IC18 MAX487 DRIVER A B 06 07 R35 R34 R36 +12V 01 08 07 05 9-leder SUB-D han E A01 R/W* 14 11 13 E RS R/W* 24 CTS* 23 DCD* 01 VSS Figur 8.3: Kredsløbsdiagram for opkobling af RS485 med ACIA, MAX487 driver og clock. data på linjen læses forkert, idet signalerne enten blander sig med eksisterende signaler eller optræder som signaler på tidspunkter, hvor der burde være ro på linjen. Refleksioner kan opstå, når de anvendte ledninger er længere end den halve bølgelængde på den signaler, der transmitteres. Dette gælder både signaler, som er transmitteret bevidst og støj induceret fra omgivelserne. Bølgelængden i kablet afhænger af frekvensen, ved hvilken trafikken bliver afviklet og dertil af udbredelseshastigheden i kablet. Hastigheden v er givet ved [Ebert, 1998, s. 118] v = c k [ m s ] (8.6) hvor k er forkortningsfaktoren for kablet (enhedsløs) og c er lysets fart i vakuum. I dette tilfælde anvendes et parsnoet UTP Patch CAT5+ kabel. I databladet for dette er faktoren opgivet til k = 0.67 [Superior- Cables.pdf, 1998, s. 6]. Hastigheden i kablet bliver da jvf. (8.6) v = 300000 km s Bølgelængden λ i kablet kan nu beregnes som 0.67 = 201000 km s (8.7) λ = v T = v 1 f = 201000 km s 8.68 10 6 s = 1.74 km (8.8) hvor T er periodetiden. Den halve bølgelængde er dermed 872 m. Det betyder, at det ikke er grundfrekvensen i signalet, der vil være årsag til evt. refleksioner, idet kablet ført rundt i en normal personbil kun vil være få meter lang. Derimod vil refleksioner opstå som følge af overtoner, som det transmitterede firkantsignal er en sammensætning af. Refleksionerne kan undgås ved at terminere enderne af kablet med en impedans, der er dimensioneret, så den samlede belastningsimpedans Z L bliver identisk med kablets karakteristiske impedans Z 0. I dette tilfælde fås den ønskede refleksionskoefficient K L lig 0, hvor K L er givet ved 42

KAPITEL 8. ACIA K L = Z L Z 0 Z L + Z 0 [ ] (8.9) Z L vil i dette tilfælde være en parallelforbindelse af terminering og indgangsimpedans på MAX487-driveren - se figur 8.4. Indgangsimpedansen Z in målt mellem A og B, når MAX487 eren fungerer som modtager er jvf. databladet [MAX487.pdf, 2003] Z in = 48 kω, og det anvendte kabel har Z 0 = 100 Ω [Superior-Cables.pdf, 1998, s. 7, VP]. Det betyder, at termineringsimpedansen Z T skal have størrelsen ( 1 Z L = Z T Z in Z T = 1 ) 1 = Z L Z i ( 1 100Ω 1 ) 1 = 100.21Ω (8.10) 48kΩ Her anvendes en modstand på 100 Ω. Den er på figur 8.3 benævnt R 34. Ligeledes skal der kobles en terminering på bussen i den modsatte ende ved den sidste perifere enhed. Denne skal have samme værdi som R 34 for at opnå en refleksionskoefficient på 0. RS485 bus Master-enhed Dataretning, når master sender Perifer enhed a) MAX487 Z t Z 0 Z 0 Z t Z 0 Z in MAX487 K L = 0 Master-enhed Dataretning, når perifer enhed sender Perifer enhed b) MAX487 Z in Z 0 Z t Z 0 Z t Z 0 MAX487 K L = 0 Figur 8.4: Princip for terminering af transmissionsledninger på RS485 forbindelse. Når bussen ikke er forbundet med én eller flere perifere enheder, og masteren lytter på linjen, så er der mulighed for at indgangen bliver udefineret. Derfor er modstandene R 35 og R 36 forbundet direkte til terminalerne A og B. R 35 trækker A mod V cc = 5 V og R 36 trækker B mod stel for at sikre et konstant spændingsforskel fra A til B på 400 mv, når der ikke modtages data. Jvf. standarden og datablad for MAX487 kræves hertil min. 200 mv for at opretholde et højt signal. Dermed vil der på RO afspejles et logisk højt niveau, som kendetegner en bus i tomgang. Databladet oplyser ingen værdi for udgangsimpedansen Z out, når MAX487 eren fungerer som sender, men denne antages at være meget tættere på 0 Ω, end Z in er. For at der kan ligge 400 mv over R 34, skal der ligge V cc 0.4 V = 4.6 V over R 35 og R 36 tilsammen. Størrelsen på R 34 er kendt, så de to øvrige kan beregnes ud fra spændingsdelerprincippet. Størrelserne bliver da R 35 + R 36 R 35 + R 36 V R35,R 36 = V cc 4.6 V = 5 V (8.11) R 34 + R 35 + R 36 100 Ω + R 35 + R 36 R 35 + R 36 = 1.15 kω R 35 = R 36 = 575 Ω (8.12) Her benyttes en modstand med standardværdien 576 Ω. 8.3 Delkonklusion Der er i dette afsnit designet to kredsløb til varetagelse af RS232- og RS485-forbindelsen ind og ud af masterenheden. Designet bygger på færdigudviklede komponenter til oscillator, driver og frekvensdivider, hvilket 43

8.3. DELKONKLUSION simplificerer kredsløbet betydeligt. Det er ikke nødvendigt at forsyne hverken RS232- eller RS485-forbindelsen med ekstra spændingsforsyning forskellig fra +5 V, idet MAX232- og MAX487-kredsen indeholder stepupog inverterkredsløb. Det er konstateret, at det er nødvendigt at terminere enderne af transmissionsledningen på RS485 forbindelsen med en modstand identisk med kablets karakteristiske impedans for at eliminere refleksioner. Det har ved praktiske forsøg med ACIA en tilknyttet RS485 kommunikationen vist sig, at TDRE bittet (Transmit Data Register Empty) ACIA ens statusregister ikke asserteres som forventet. Det var forventet, at når denne bit blev sat, ville transmit-data registret være tomt, hvilket ville betyde at forrige byte var afsendt over RS485 forbindelsen. Derved ville det være muligt at anvende status af denne bit til at bestemme, hvornår RTS skulle asserteres igen - altså hvornår transmissionen af sidste byte i en pakke var gennemført. Dette anvendes af masteren, når den 3. byte er afsendt. I de praktiske forsøg viste det sig imidlertid, at andet bit i ACIA ens statusregister blev sat allerede 83.6 µs før afsendelsen af transmitdata registerets indhold var færdiggjort. Behandlingen af dette problem ses i appendiks P på side 185, og bliver løst ved indsættelse af en pauseløkke i software, der forsinker asserteringen af RTS. 44

KAPITEL 9. DISPLAY Kapitel 9 Display Som det fremgår af kravspecifikationens afsnit 2.3 på side 11, skal systemets eksterne grænseflader bl.a. bestå af et display. I dette kapitel beskrives det valgte display, Winstar 2004, mht. funktionalitet og timing. Informationer om displayet kommer fra databladene [wh2004a.pdf] og [ks0066.pdf]. 9.1 Funktionalitet Som det er skitseret på figur 9.1, er der tale om et display med 4 linjer á 20 karakterer, hvor hver karakter består af 5x8 punkter. Displayet aktiveres ved at assertere E og styres med otte datalinjer DB0-DB7 samt linjerne RS og R/W. 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 0 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 40 41 42 43 44 45 46 47 48 49 50 51 52 53 54 55 56 57 58 59 20 21 22 23 24 25 26 27 28 29 30 31 32 33 34 35 36 37 38 39 60 61 62 63 64 65 66 67 68 69 70 71 72 73 74 75 76 77 78 79 Figur 9.1: Skitse af displaylayout og eksempel på karakter. Tallene i displayet angiver karakterens register. Selvom displayet internt har mange adresser, er der kun RS til at vælge register udefra. Som det ses af tabel 9.1 på den følgende side er det ene register (RS=1) dedikeret til overførsel af data, mens det andet bruges til en række forskellige funktioner, herunder intern adressering. Selve displayet forsynes via Vdd og GND, mens baggrundsbelysningen forsynes selvstændigt via A/Vee og K, begge forsyninger tilsluttes 5 V. Displayets kontrastforhold styres af Vo, der skal have en negativ spænding. For at kunne justere kontrasten forbindes Vo til en variabel spændingsdeler mellem 0 V og en negativ forsyningsspænding. 45

9.2. TIMING Funktion RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB0 Slet alt 0 0 0 0 0 0 0 0 0 1 Hjem 0 0 0 0 0 0 0 0 1 - Tilgang 0 0 0 0 0 0 0 1 I/D SH Tænd/sluk 0 0 0 0 0 0 1 D C B Flyt/forskyd 0 0 0 0 0 1 S/C L/R - - Opsætning 0 0 0 0 1 DL N F - - Sæt position 0 0 1 A6 A5 A4 A3 A2 A1 A0 Læs position 0 1 BF A6 A5 A4 A3 A2 A1 A0 Skriv karakter 1 0 D7 D6 D5 D4 D3 D2 D1 D0 Læs karakter 1 1 D7 D6 D5 D4 D3 D2 D1 D0 Funktion Slet alt Hjem Tilgang I/D SH Tænd/sluk D C B Flyt/forskyd S/C L/R Opsætning DL N F Sæt position Læs position BF Skriv karakter Læs karakter Beskrivelse Skriver mellemrum ( ) på alle positioner. Hopper til position 0 og nulstiller evt. forskydning. Bestemmer om den aktive position flytter frem eller tilbage efter hver tilgang. Bestemmer om alle positioner forskydes som alternativ til, at den aktive positionen flyttes. Bestemmer om displayet skal være tændt. Bestemmer om cursoren ( ) skal være tændt. Bestemmer om det aktive felt skal blinke. Bestemmer om den aktive position flyttes eller om alle positioner forskydes. Bestemmer retningen. L for venstre og R for højre. Angiver om databredden er 8 eller 4bit. Angiver om der er en eller to linjer. Angiver om skriften er 8x5 eller 11x5 punkter. Flytter den aktive position til adressen angivet på DB0-DB6. Retunerer adressen på den aktive position. Angiver om displayet er ved at udføre en funktion. Skriver karakteren angivet med DB0-DB7 på den aktive position. De fleste tegn følger ASCII. Retunerer karakteren på den aktive position. Tabel 9.1: Oversigt og beskrivelse af udvalgte displayfunktioner. Displayets interne controller er designet til at fungere med en lang række forskellige displays, hvorfor der under opsætning er mulighed for at angive antal linjer og skriftstørrelse. Der er imidlertid ikke en indstilling til 4 linjer, men kontrolleren kan håndtere 2 linjer med op til 40 tegn og displayet, der har 4 linjer af 20 tegn, vil opføre sig som 2 linjer af 40 tegn, hvor linjerne er ombrudt på midten. Som det kan ses af figur 9.1 på foregående side hænger hhv. linjerne 1 og 3 og linjerne 2 og 4 sammen. 9.2 Timing I det følgende undersøges, hvorvidt displayets timing er kompatibel med processorens. Figurerne 9.2 og 9.3 skitserer hhv. skrivning til og læsning fra display, mens tabellerne 9.2 og 9.3 angiver de forskellige tider markeret på de pågældende figurer. Timing for processoren fremgår af appendiks C på side 137. 46

KAPITEL 9. DISPLAY 9.2.1 Skrivning til display RS R/W* t su1 t w t H1 E DB0- DB7 t su2 Gyldig data t H2 Figur 9.2: Timingsdiagram for write cycle af display. Symbol Min. [ns] Maks. [ns] Beskrivelse t su1 40 - Tid RS og R/W skal være stabile inden E asserteres t w 230 - Bredde af aktiveringssignal t su2 80 - Tid D0-D7 skal være stabil inden E negeres t H1 10 - Tid RS og R/W skal være stabil efter E negeres t H2 10 - Tid D0-D7 skal være stabil efter E negeres t c 500 - Tid fra én skrivning starter til næste kan begyndes Tabel 9.2: Timingstider for write cycle af display. Displayet skal først aktiveres, når det er sikkert, at der er data til det, og da displayet kun har 8bit databredde er det når processoren, efter at have sat adressen op, har tilkendegivet hvilken del af databussen der tilgås, dvs. når UDS asserteres. Som det ses af figur C.4 i appendiks C er R/W den del af adressen der bliver sat op sidst. Tiden herfra til UDS asserteres hedder t RLSL og er mindst 80 ns. Displayets setup-tid t su1 på mindst 40 ns er altså overholdt. Displayet er aktiveret så længe UDS er asserteret, dvs. processorens t SL(W ), der er mindst 140 ns. Displayet kræver imidlertid at aktiveringssignalet er mindst 230 ns (t w ). For at sikre at aktiveringssignalet bliver mindst 230ns er det nødvendigt at udskyde DTACK signalet til processoren i mindst 90 ns, herved indsættes tomme states mellem S4 og S5. Når E negeres skal D0-D7 have været stabile i tiden t su2, mindst 80 ns. Processoren er allerede klar med data mindst t DOSL, 40 ns før UDS og dermed E asserteres. Endelig skal RS, R/W og D0-D7 være stabile t H1 / t H2, mindst 10 ns efter E negeres. Det fremgår at de pågældende tider, t SHAZ, t SHRH og t SHDOI alle er mindst 40 ns. 47

9.3. DELKONKLUSION 9.2.2 Læsning fra display RS R/W* t su t w t H E DB0- DB7 t D Gyldig data t DH Figur 9.3: Timingsdiagram for read cycle af display. Symbol Min. [ns] Maks. [ns] Beskrivelse t su 40 - Tid RS og R/W skal være stabile inden E asserteres t w 230 - Bredde af aktiveringssignal t D - 120 Tid inden DB0-DB7 er stabil efter E asserteres t H 10 - Tid RS og R/W skal være stabil efter E negeres t DH 5 - Tid DB0-DB7 er stabil efter E negeres t c 500 - Tid fra én læsning starter til næste kan begyndes Tabel 9.3: Timingstider for read cycle af display. Igen tages der udgangspunkt i, at displayet aktiveres når adressen er sat op og UDS asserteres. Ved læsning bliver adressen, modsat ved skrivning, stabil senere end R/W. Tiden fra adressen er stabil til UDS asserteres hedder t AV SL og er mindst 30 ns. Displayet kræver en tid, t su, på mindst 40 ns. Idet AS og UDS følges ad ved læsning, vil displayet være aktiveret i tiden t SL, der er mindst 270 ns. Dette er nok til at aktivere displayet i de krævede 230 ns (t w ). Processoren forventer, at data er klar t DICL, mindst 15 ns, før skiftet mellem S6 og S7. I forhold til, hvornår displayet aktiveres, svarer det i værste fald til: 2.5 t CY C t CHSL t DICL (9.1) 2.5 125 ns 60 ns 15 ns = 237.5 ns (9.2) Displayet er i stand til at levere data efter t D, maks. 120 ns. Ved læsning er det derfor ikke nødvendigt at indsætte ekstra states mellem S4 og S5 i processorens write cycle. Displayet holder sine data t DH, mindst 5 ns, efter ophørt aktiveringssignal. Dette er ikke påkrævet af processoren, da t SHDI kan være ned til 0 ns. 9.3 Delkonklusion Displayets funktionalitet er beskrevet og det er undersøgt i hvilken grad displayets timing matcher processoren. Det har vist sig, at displayets krav til timing, som udgangspunkt, ikke bliver overholdt af processoren. Det drejer sig om at E ikke er asserteret længe nok under skrivning, samt at R/W og RS ikke er defineret skal være stabile før displayet aktiveres for læsning. Disse uoverensstemmelser vil blive kompenseret i kapitel 10, hvor der designes en DTACK -generator. 48

KAPITEL 10. MEMORY MAPPING Kapitel 10 Memory mapping Idet der skal tilsluttes flere forskellige enheder til processorens databus, er det nødvendigt at sikre, at flere enheder ikke forsøger at benytte de samme datalinjer på samme tid. Dette gøres ved at tildele de enkelte enheder forskellige adresseområder, som de hver især vil være aktive indenfor. I dette kapitel bliver alle enheder tildelt et adresseområde og der tages hensyn til, at nogle enheder skal have en bestemt placering. Desuden kompenseres der for uoverensstemmelser i timingen mellem processor og display. 10.1 Krav De fleste enheder indeholder flere registre, og for at kunne tilgå dem alle, skal enhedens adresseområde mindst være lige så stort som antallet af enhedens interne registre. For at lette udviklingen af systemet benyttes TS2-MON. Dette program ligger i en ROM, der skal have en bestemt placering og forventer en vis mængde RAM og en ACIA på bestemte adresser, hvilke fremgår af tabel 10.1. Enhed Type Fra Til ROM 2x128k 000000 h 001200 h RAM 2x512k 040000 h 040FFF h ACIA M6850 800001 h 800003 h Tabel 10.1: Krav til adressering ved benyttelse af TS2-MON [Nielsen, 2003, s. 2]. For at kunne benytte TS2-MON skal ROM en, som det kan ses af tabel 10.1, starte i adresse 0 h og med 2x128k registre kan den udfylde et adresseområde frem til 3FFFF h. Dette passer med at RAM en skal starte i 40000 h. RAM en kan med 2x512k udfylde et adresseområde fra 40000 h frem til 13FFFF h. Bemærk at både ROM og RAM har flere registre end det kræves af TS2-MON, men får tildelt adresseområder så alle registre kan tilgås. For at møde kravene fra TS2-MON skal ACIA en til kommunikation med en PC (ACIA232) ligge på adresserne 800001 h og 800003 h. Da ACIA en er en 8bit enhed, optager den kun halvdelen af databussen, hvilket også er grunden til springet i adresserne på dens registre. Der skal yderligere anvendes en ACIA til den serielle bus (ACIA485). Denne bliver placeret i samme adresseområde som den første, men på den anden halvdel af databussen, hvilket betyder, at den får to lige adresser, 800000 h og 800002 h. Displayet placeres efter ACIA485, på den øverste halvdel af databussen. Tabel 10.2 viser enhedernes adresseområder. 49

10.2. ADRESSEDEKODER Lige (UDS) Ulige (LDS) 000000 h ROM01 ROM02 000001 h... 128k 128k... 03FFFE h 03FFFF h 040000 h RAM02 RAM02 040001 h... 512k 512k... 13FFFE h 13FFFF h 800000 h ACIA485 ACIA232 800001 h 800002 h 800003 h 840000 h DISPLAY 840002 h Tabel 10.2: Adresseoversigt for enheder på databus. 10.2 Adressedekoder De enheder, der tilsluttes adresse- og databussen er ikke klar over, hvor de er placeret i adressetabellen. Der er derfor behov for et logisk kredsløb, en adressedekoder, der kan omsætte forskellige bitmønstre på adressebussen til aktiveringssignaler (CS) for de enkelte enheder. For at simplificere adressedekoderen benyttes partiel adressering, dvs. at dekodningen af adressen sker udfra udvalgte adressebit i modsætning til fuldstændig adressering, hvor alle adressebit indgår. Enhederne har fået adresser, så det kan bestemmes alene ud fra de øverste seks adressebit (A23-A18), hvilken enhed der skal være aktiv. Dette medfører, at adressedekoderen kun kan skelne spring på minimum 128k adresser. De enheder, der kun behøver et mindre adresseområde, vil derfor kunne præsentere det samme register på flere forskellige adresser, herved opstår såkaldte spejle. I tabel 10.3 ses en oversigt over, hvilke adresselinjer de enkelte enheder bruger til intern adressering, samt hvilke niveauer A23-A18 skal have, før en enhed aktiveres. Adresseben 2 2 2 2 1 1 1 1 1 1 1 1 1 1 0 0 0 0 0 0 0 0 0 Enhed 3 2 1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 Lige (UDS) ROM01 128k 0 0 0 0 0 0 A A A A A A A A A A A A A A A A A 0 0 0 0 A 1 A A A A A A A A A A A A A A A A A RAM01 512k 0 0 0 0 1 A A A A A A A A A A A A A A A A A A 0 0 0 1 A A A A A A A A A A A A A A A A A A A ACIA485 1 0 0 0 0 0 - - - - - - - - - - - - - - - - A DISPLAY 1 0 0 0 0 1 - - - - - - - - - - - - - - - - A Ulige (LDS) ROM02 128k 0 0 0 0 0 0 A A A A A A A A A A A A A A A A A 0 0 0 0 A 1 A A A A A A A A A A A A A A A A A RAM02 512k 0 0 0 0 1 A A A A A A A A A A A A A A A A A A 0 0 0 1 A A A A A A A A A A A A A A A A A A A ACIA232 1 0 0 0 0 0 - - - - - - - - - - - - - - - - A Tabel 10.3: Bitmønstret på A18-A23 afgør, hvilken enhed der er aktiv. Enheder på lige adresser forbindes til D08-D15 på databussen, enheder på ulige adresser forbindes til D00-D07. A angiver forbindelser, der bruges til adressering internt i en enhed, - angiver forbindelser, der ikke har indflydelse på den pågældende enhed. Udover de seks øverste adressebit skal adressedekoderen have input fra UDS og LDS for at kunne afgøre, om det er den lige, ulige eller begge enheder i et adresseområde, der skal aktiveres. I forbindelse med A- CIA erne, der i minimumsystemet kører synkron dataoverførsel, skal der genereres et VPA signal, og de skal ikke aktiveres, før processoren svarer med et VMA. Som det bl.a. fremgår af kapitel 6 på side 29, kræver flere af de benyttede enheder separate signaler for write enable (WE ) og output enable (OE ), hvilket skal genereres ud fra processorens kombinerede read/write-signal (R/W ). 50

KAPITEL 10. MEMORY MAPPING Det logiske kredsløb, der udgør adressedekoderen, opbygges ikke af standard IC er med logiske gates. I stedet anvendes en PEEL-kreds, hvori der findes et netværk af gates, der kan programmeres til at opfylde forskellige behov. Herunder ses de logiske udtryk for aktivering af de forskellige enheder. Disse er opstillet udfra bitmønstrene i tabel 10.3 på modstående side. CS ROM01 = A23 A22 A21 A20 A19 A18 UDS AS (10.1) CS ROM02 = A23 A22 A21 A20 A19 A18 LDS AS (10.2) CS RAM01 = A23 A22 A21 (A20 A18 + A20 A19 + A20 A19 A18) UDS AS (10.3) CS RAM02 = A23 A22 A21 (A20 A18 + A20 A19 + A20 A19 A18) LDS AS (10.4) CS ACIA485 = A23 A22 A21 A20 A19 A18 UDS VMA AS (10.5) CS ACIA232 = A23 A22 A21 A20 A19 A18 LDS VMA AS (10.6) CS DISPLAY = A23 A22 A21 A20 A19 A18 UDS AS (10.7) Herunder ses de logiske udtryk for kontrolsignalerne OE og VPA, bemærk at VPA også skal bruges ved autovektoriseret interrupt og derfor kan asserteres af et eksternt kredsløb forbundet til INT. OE = R/W AS (10.8) VPA = A23 A22 A21 A20 A19 A18 (UDS + LDS ) + INT (10.9) I tabel 10.4 fremgår de faktiske adresseområder, inkl. dem, der ikke benyttes og dem, der er spejle af andre. Lige (UDS) Ulige (LDS) 000000 h ROM01 ROM02 000001 h... 128k 128k... 03FFFE h 03FFFF h 040000 h RAM01 RAM02 040001 h... 512k 512k... 13FFFE h 13FFFF h 140000 h Ikke Ikke 140001 h... allokeret allokeret... 7FFFFE h 7FFFFF h 800000 h ACIA485 ACIA232 800001 h 800002 h 800003 h............ 83FFFE h SPEJL SPEJL 83FFFF h 840000 h DISPLAY Ikke 840001 h 840002 h allokeret...... 87FFFE h SPEJL...... 880000 h Ikke... allokeret 8FFFFE h 8FFFFF h Tabel 10.4: Komplet adresseoversigt. Der er umiddelbart to parametre, der har betydning for valget af PEEL-kreds. Først og fremmest skal den minimum have det antal ind og udgange, der er påkrævet til opgaven. I dette tilfælde skal der bruges 6 indgange fra adressebussen, samt en indgang til AS, LDS, UDS, VMA, R/W samt INT. Der skal bruges en udgang til hver af de otte enheder, der skal kunne aktiveres, samt to udgange til hhv. OE og VPA. Dette giver i alt 12 indgange og 10 udgange. Den anden parameter, der har betydning er propagation delay et. 51

10.3. DTACK -GENERATOR Hvis PEEL-kredsen er for langsom til at aktivere den adresserede enhed, vil det være nødvendigt at gøre processoren opmærksom på dette, ved at indsætte wait states. I forbindelse med displayet er det imidlertid ønskeligt, at der er en vis forsinkelse af aktiveringen. Som det fremgår af kapitel 9 på side 45 skal displayets RS og R/W være stabile mindst 40 ns før displayet aktiveres. Ved læsning går der imidlertid kun mindst 30 ns fra de pågældende ben er stabile til displayet kan aktiveres (idet UDS asserteres). Med en forsinkelse på mindst 10 ns gennem PEEL-kredsen vil denne del af displayets timing være overholdt. Som det fremgår af kapitel 6 på side 29 og 9 på side 45 forventer processoren typisk data indenfor ca. 210ns og den langsomste hukommelse, displayet, vil levere maks. 120 ns efter at være aktiveret. Dette stiller et krav om, at PEEL-kredsen skal aktivere den korrekte enhed indenfor ca. 90 ns. Komponentlageret har udleveret PEEL-kredse af typen 22CV10-25 - kredse der har 12 dedikerede indgange, 10 valgfrie ind-/udgange og et propagation delay på maksimalt 25 ns. Disse kredse opfylder således de nævnte krav. I figur 10.1 ses den endelige opkobling af adressedekoderen. 10.3 DTACK -generator Konklusionerne fra kapitel 6 på side 29 og kapitel 9 på side 45 er, at de benyttede ROM- og RAM-kredses timing passer direkte med processorens, mens det er nødvendigt at indsætte wait states i forbindelse med skrivning til displayet. Da hovedparten af datatrafikken vil ske mellem processor og ROM/RAM, der ikke behøver wait states, ønskes en løsning hvor der kun indsættes wait states ved kommunikation med displayet. Det vurderes ligeledes, at der hovedsageligt vil blive skrevet til displayet, hvorfor det er acceptabelt at indsætte wait states i forbindelse med al kommunikation med displayet, selvom det ikke er nødvendigt ved læsning. Wait states indsættes ved forsinkelse af DTACK signalet til processoren - se evt. appendiks C på side 137. For de enheder, der ikke behøver wait states er det tilstrækkeligt, at DTACK følger AS. Når displayet adresseres er det nødvendigt, at DTACK er negeret idet processoren når S5 og først asserteres, når displayet har været aktiveret i mindst 230 ns. Hvis der tages udgangspunkt i, at der genereres et signal, DISP OK, når displayet er klar, skal DTACK følge tabel 10.5. CS DISP DISP OK AS DTACK - - 1 1 0-0 0 1 0-1 1 1 0 0 Tabel 10.5: Sandhedstabel for DTACK -generator. 0 er logisk lav, 1 er logisk høj og - er uden betydning. Tabel 10.5 kan udtrykkes som: DTACK = CS DISP DISP OK + AS (10.10) Dette udtryk implementeres i PEEL02, der blev introduceret i kapitel 7 på side 35. Signalet DISP OK genereres ved at lade CS DISP oplade et RC-led. Opladningskurven omsættes til logisk høj/lav vha. to Schmitt trigger invertere. Da displayet som udgangspunkt aktiveres i mindst 140 ns, skal DISP OK asserteres mindst 90 ns efter CS DISP og med et typisk propagation delay på 12 ns igennem hver inverter [74hc14.pdf, 2003, s. 2], skal RC-leddet være mindst 66 ns om at oplades til inverterens positive trig niveau. Trigger niveauet, V T +, kan med 4.5 V forsyning ligge allerede ved 1.7 V [74hc14.pdf, 2003, s. 10] og det antages at PEEL-kredsens udgangsspænding, V OH, svarer til forsyningsspændingen 5 V. ) V T + = V OH (1 e t RC [V] (10.11) t RC = ( ) [s] (10.12) ln 1 V T + V OH 52

KAPITEL 10. MEMORY MAPPING RC = 66 10 9 s ln ( ) 1 1.7 V = 159 ns (10.13) 5 V Der må maksimalt løbe 25 ma i PEEL-kredsens udgange, så modstanden i RC-leddet skal, ifølge Ohms lov, være minimum 200 Ω. Med R 37 valgt til 1 kω skal kondensatoren C 31 være 159 pf. Der benyttes en kondensator på 150 pf. Ved målinger beskrevet i appendiks N på side 179 verificeres det, at DTACK -generatoren forlænger tiden displayet aktiveres, så den er over 230 ns. Målingerne viser, at displayet er aktiveret i 550 ns. At tiden er betydeligt længere end påkrævet tilskrives, at der er regnet med at PEEL-kredsen lader på RC-leddet med fuld forsyningsspænding, 5 V, og at der til inverterens positive trig-niveau, V T +, er taget udgangspunkt i den laveste værdi angivet for en forsyningsspænding på 4.5 V, 0.5 V under den faktiske forsyningsspænding. 10 21 DTACK* AS* A18 A19 A20 A21 IC05 A22 M68HC000 CPU A23 LDS* UDS* R/W* VPA* VMA* 6 49 50 51 53 54 55 8 7 9 23 1 3 4 5 6 7 8 9 10 11 16 2 AS* A18 A19 A20 A21 A22 A23 LDS* UDS* R/W* VMA* INT IC06 22CV10-25 PEEL01 CS ROM1* CS ROM2* CS RAM1* CS RAM2* 21 20 23 22 CS DISP 17 CS RS232* CS RS485* OE* VPA* 18 19 15 13 R33 C31 3 4 5 IC021 74HC14 Inverter, Schmitt Trigged 6 7 8 9 AS* DTACK* IC04 22CV10-25 PEEL02 CS DISP DISP OK INT 20 3 Figur 10.1: Kredsløbsdiagram for adressedekoder og DTACK -generator. De stiplede linjer markerer forbindelser til komponenter, der ikke er afbilledet i dette diagram. 10.4 Delkonklusion Da udviklingen af software til systemet vil ske vha. TS2-MON, er adresserne på alle de enheder dette værktøj skal kommunikere med bestemt på forhånd. Tilbage har været at vælge adresser til de enheder, der udelukkende skal benyttes af applikationen - display til interaktion med brugeren, samt ACIA485 til den serielle bus. Adressedekodningen sker partielt udfra de seks øverste adressebit, hvilket resulterer i, at der opstår spejle af ACIA er og display, til gengæld spares der indgange på adressedekoderen. Selve adressedekoderen implementeres vha. et programmerbart logisk kredsløb, PEEL-kredsen 22CV10-25, der har det nødvendige antal ind- og udgange og er tilstrækkelig hurtig til ikke at ødelægge timingen mellem processor og tilsluttede enheder. Det er nødvendigt at indføre en DTACK -generator for at sikre, at displayet bliver aktiveret i mindst de 230 ns som [ks0066.pdf, s. 31] forskriver. Generatoren bevirker at displayet er aktiveret i 550 ns og er implementeret så den ikke påvirker timingen af de øvrige enheder. PEEL-koden, der udgør adressedekoderen, er implementeret i PEEL01 og kan ses i appendiks E.1 på side 145. Koden til DTACK -generatoren er implementeret i PEEL02 og kan ses i appendiks E på side 145. 53

KAPITEL 11. BELASTNING AF M68K Kapitel 11 Belastning af M68k I dette kapitel undersøges det om M68k ens specifikationer overskrides mht. til strømmen der optages fra adresse-, data- og kontrolbus, samt disses kapacitive belastninger af processoren. I tabel 11.1 er de maksimalt tilladte strøm- og kapacitive belastninger for M68k ens ben angivet [M68KUM.pdf, 1993]. Ben I IH I IL Maksimal belastningskapacitet (C L ) E, AS, LDS, UDS, VMA, R/W, D00 - D15 400 µa 5.3 ma 130 pf A01 - A23, FC0, FC1, FC2 400 µa 3.2 ma 130 pf Tabel 11.1: Maksimal belastning for M68k [M68KUM.pdf, 1993]. 11.1 Belastningsberegning for adressebus For at bestemme strøm- og kapacitetsbelastningen på adressebussen undersøges det herunder, hvor meget de enkelte kredse belaster med. Data for de til adressebussen tilsluttede enheder er indført i tabel 11.2. Enhed Antal I IH I IL Indgangs kapacitet (C in ) Kilde ROM 2 1 µa 1 µa 6 pf [AM29F010B.pdf, 2002] RAM 2 1 µa 1 µa 8 pf [HM628512.pdf, 1994] PEEL01 1 10 µa 10 µa 6 pf [22CV10.pdf, 2002] ACIA 1 2.5 µa 10 µa 7.5 pf [MC6850.pdf, 2004] Tabel 11.2: Enheder på adressebus og disses strøm- og kapacitetsbelastninger. Som beskrevet i kapitel 10 på side 49 er det kun adressebenene A18 - A23, der er tilsluttet PEEL-kredsen til adressedekodning. Belastningen på disse ben behøver derfor separate udregninger. Desuden er adressebenet A01 forbundet til begge ACIA er, hvorfor denne også må have separat udregning. Strømbelastningen ved høj ( I IH ) på adresseben A01 kan beregnes som: I IH,A01 = 2 I IH,ROM + 2 I IH,RAM + 2 I IH,ACIA (11.1) = 2 1 µa + 2 1 µa + 2 2.5 µa (11.2) = 9 µa (11.3) Strømbelastningen ved høj ( I IH ) på adresseben A02 - A17 kan beregnes som: I IH,A02 A17 = 2 I IH,ROM + 2 I IH,RAM (11.4) = 2 1 µa + 2 1 µa (11.5) = 4 µa (11.6) 55

11.2. BELASTNINGSBEREGNING FOR DATABUS Strømbelastningen ved høj ( I IH ) på adresseben A18 - A23 kan beregnes som: I IH,A18 A23 = I IH,P EEL01 (11.7) = 10 µa (11.8) På tilsvarende måde kan strømbelastningen ved lav ( I IL ) på adressebenene A01, A02 - A17 og A18 - A23 beregnes til henholdsvis 24 µa, 4 µa og 10 µa. Den kapacitive belastning på adresseben A01 kan beregnes som: C L,A01 = 2 C in,rom + 2 C in,ram + 2 C in,acia (11.9) Den kapacitive belastning på adresseben A02 - A17 kan beregnes som: = 2 6 pf + 2 8 pf + 2 7.5 pf (11.10) = 43 pf (11.11) C L,A01 A17 = 2 C in,rom + 2 C in,ram (11.12) Den kapacitive belastning på adresseben A18 - A23 kan beregnes som: = 2 6 pf + 2 8 pf (11.13) = 28 pf (11.14) C L,A18 A23 = C in,p EEL01 (11.15) = 6 pf (11.16) 11.2 Belastningsberegning for databus For at bestemme strøm- og kapacitetsbelastningen på databussen undersøges det herunder, hvor meget de enkelte kredse belaster med. Data for de til databussen tilsluttede enheder er indført i tabel 11.3. Da der er forskellige enheder tilsluttet databenene D00 - D07 og D08 - D15 må belastningerne udregnes separat for disse. Enhedernes forbindelse til databussen kan ses af appendiks S på side 195. Enhed Antal I IH I IL C out C in kilde ROM 2 1 µa 1 µa 12 pf 6 pf [AM29F010B.pdf, 2002] RAM 2 1 µa 1 µa 10 pf 8 pf [HM628512.pdf, 1994] ACIA 2 2.5 µa 10 µa 10 pf 7.5 pf [MC6850.pdf, 2004] DISPLAY 1 205 µa 1.20 ma NA NA [HD44780.pdf, 1999] Tabel 11.3: Enheder på databus og disses strøm og kapacitetsbelastninger. Strømbelastningen ved høj ( I IH ) på databen D00 - D07 kan beregnes som: I IH,D00 D07 = I IH,ROM + I IH,RAM + I IH,DISP LAY + I IH,ACIA (11.17) = 1 µa + 1 µa + 2.5 µa + 205 µa (11.18) = 209.5 µa (11.19) Strømbelastningen ved lav ( I IL ) på databen D00 - D07 kan beregnes som: I IL,D00 D07 = I IL,ROM + I IL,RAM + I IL,DISP LAY + I IL,ACIA (11.20) = 1 µa + 1 µa + 10 µa + 1200 µa (11.21) = 1212 µa (11.22) Den kapacitive belastning på databen D00 - D07 kan beregnes som: C L,D00 D07 = C out,rom + C out,ram + C out,acia + C out,disp LAY (11.23) = 12 pf + 10 pf + 10 pf (11.24) = 32 pf (11.25) 56

KAPITEL 11. BELASTNING AF M68K På tilsvarende måde kan belastningerne beregnes for databenene D08 - D15 beregnes til: I IH,D08 D15 = 4.5 µa I IL,D08 D15 = 12 µa C L,D08 D15 = 32 pf. 11.3 Belastningsberegning for kontrolbus Med samme beregninger som fra afsnit 11.1 kan belastningerne beregnes for alle benene på processoren, der benyttes til kontrol af tilsluttede enheder - den såkaldte kontrolbus. Disse belastninger er listet i tabel 11.4. Ben I IH I IL belastningskapacitet (C L ) E 5 µa 20 µa 15 pf AS 22.5 µa 22.5 µa 32 pf LDS 10 µa 10 µa 6 pf UDS 10 µa 10 µa 6 pf VMA 10 µa 10 µa 6 pf R/W 222 µa 1232 µa 37 pf FC0-FC2 10 µa 10 µa 6 pf Tabel 11.4: Belastninger på kontrolbussen. Sammenlignes tallene fra tabel 11.4 med tallene for processorens maksimale belastninger i tabel 11.1 ses det, at ingen af kontrolbussens forbindelser belaster processoren over det tilladte. 11.4 Delkonklusion Det kan konkluderes, at ingen af de udførte beregninger på strøm- og kapacitetsbelastningerne af processoren overskrider de anførte maksimum specifikationer angivet i tabel 11.1. Det har ikke været muligt at finde data på de kapacitive belastninger fra displayet, men med den store margin op til maks. specifikationerne for processoren, vurderes det ikke at kunne give anledning til problemer. 57

Del III: Perifere enheder Denne del indeholder hardwarekonstruktionen af de perifere enheder til systemet. Dette inkluderer lygteenheden, lygtekontrolenheden samt olieenheden. De perifere enheder opbygges af samme type mikrocontroller, hvorfor disse designes meget ens. Kravene til disse vil først blive specificeret, hvorefter det fælles design udføres. Dernæst gennemgås de forskellige krav til de perifere enheder og disse implementeres. Til slut testes enhederne og resultaterne sammendrages. Del III: Perifere enheder 59 12 Hardware til perifere enheder 61 12.1 Kravspecifikation........................................... 61 12.2 Fælles hardware........................................... 64 12.3 Individuel hardware......................................... 66 12.4 Test.................................................. 67 12.5 Resultater............................................... 67 12.6 Delkonklusion............................................. 67

KAPITEL 12. HARDWARE TIL PERIFERE ENHEDER Kapitel 12 Hardware til perifere enheder De perifere enheders hardware i bilbussystemet konstrueres i dette kapitel. Krav der er fælles for de perifere enheder opstilles og analyseres, hvorefter en række valg om konstruktionen træffes. Herefter opstilles individuelle krav for de enkelte perifere enheder, og de relevante valg træffes før hardwaren konstrueres. Folduddiagrammet, der refereres til i dette kapitel, forefindes i appendiks R på side 193. 12.1 Kravspecifikation Fælles for de 3 perifere enheder er følgende krav: RS485 snitflade til buskommunikation, 115.200 bps, 8 databit, 1 startbit, 1 stopbit og lige paritet. Responstid på maksimalt 0.5 s. Indbygget timer, der anvendes ved detektion af ugyldig adresse i datapakke. Skal kunne omsætte digitale og analoge signaler på I/O-porte til data på RS485-bussen ved forespørgsel. Skal overholde protokollen specificeret kapitel 13. Da der skal foretages analog til digital konvertering, parallel til seriel og seriel til parallel konvertering, samt en lang række betingelsestests og beregninger af paritet, er den mest effektive løsning at basere de perifere enheders hardware på en mikrocontroller. 12.1.1 Valg af mikrocontroller Der findes et stort antal tilgængelige mikrocontrollere, hvoraf mange kan udføre de opgaver der kræves. Derfor er valget af fabrikat og type ikke udpræget vigtig. En parameter, der kan anvendes i forbindelse med valget, er prisen. Atmel fremstiller mikrocontrollere, der kan udføre de nødvendige opgaver, og kan tilbyde dem til en lav pris. Set i relation til f.eks. Microchips PIC16/PIC18 serie, koster Atmels tilsvarende AVR serie i runde tal en tiendedel. På basis af ovenstående krav vælges Atmels AVR serie. 12.1.2 Atmel AVR mikrocontroller AVR 8 bit mikrocontroller arkitekturen består af en RISC CPU og en række indbyggede enheder, der varierer i antal og type i de forskellige modeller. Blokdiagram over AVR kan ses på figur 12.1 på den følgende side. AVR-serien understøtter statisk drift, dvs. at mikrocontrolleren virker ved alle clock-frekvenser op til deres påtrykte øvre clock-frekvens. De forskellige modeller findes i flere typer, hvor typen bestemmer den maksimale hastighed. Prisen stiger sammen med clock-frekvensen [AT90S8535.pdf, 2005]. 61

12.1. KRAVSPECIFIKATION 62 Figur 12.1: Blokdiagram over AVR mikrocontrollere

KAPITEL 12. HARDWARE TIL PERIFERE ENHEDER Figur 12.2: Kernen i AVR mikrocontrollere. 12.1.3 AVR-kernen Kernen i CPU en består af en ALU med 32 stk. 8 bit arbejdsregistre. Alle 32 registre er forbundet direkte til ALU en. Det er muligt at anvende 6 af registrene som 3 stk. 16 bit registre, hvilket er velegnet, når der foretages adresseberegninger. Der anvendes Harvard arkitektur, dvs. at der er en bus til data og en anden bus til instruktioner. Dermed opnås en bedre ydelse end i f.eks. M68k, der anvender Von Neumann arkitekturen. Instruktionsbussen har en pipeline med et niveau, hvilket muliggør, at en instruktion udføres i ALU en imens den næste instruktion hentes ind og gøres klar. Det er ad denne vej muligt at konstruere kernen, så en instruktion udføres på en clock cycle. Se evt. figur 12.2. 12.1.4 Hukommelse Kernen kan tilgå flere typer hukommelse der er indbygget i controlleren, og har forskellig størrelse fra model til model. Fælles for alle modeller er at de har tre typer af hukommelse. Den indbyggede statiske RAM er et arbejdslager for processoren. Programhukommelsen er af FLASH RAM typen, og det er i denne del at software kan gemmes, og ændres. FLASH-RAM er ikke-flygtig hukommelse, dvs. data gemt i denne hukommelse ikke forsvinder, når forsyningsspændingen ikke er tilsluttet mikrocontrolleren. Endelig findes en EEPROM, hvori data kan gemmes af softwaren, der kører i mikrocontrolleren. EEPROM er ligesom FLASH-RAM ikke-flygtig. EEPROM en anvendes ikke i de perifere enheder. 63

12.2. FÆLLES HARDWARE 12.1.5 UART Indbygget i AVR-serien findes UARTs, der er konfigurerbare. UDR (UART Data Register) anvendes til data, der sendes og modtages. USR (UART Status Register) indeholder bit, der afdækker hvilken status UART en er i. UCR (UART Control Register) anvendes til opsætning af UART en. Endelig findes UBRR (UART Baud Rate Register), hvori UART ens hastighed kan sættes. Det gennemgås i afsnit 12.2.3 på modstående side hvordan UBRR beregnes. 12.1.6 Porte Afhængig af model findes et antal porte på mikrocontrolleren. Portene er 8 bit bidirektionelle og med indbyggede pullup-modstande. Deres dataretning kan sættes via DDRx (Data Direction Register), hvor x angiver port A, B, C osv. Hvis et bit er sat til udgang, kan dets respektive ben, ved høj levere 3 ma og ved lav trække 20 ma. PORTx registret anvendes til at sætte bit på port x. PINx anvendes til at læse fra porten. 12.1.7 Timere De indbyggede timere kan både anvendes vha. polling og vha. interrupts. En række registre styrer timerne, og de vigtigste nævnes her. TCCRx (Timer Counter Control Register) bruges til opsætning af timeren. På x s plads indsættes 0, 1, 2 osv. afhængig af, hvilken timer der ønskes styret. Timer clock-frekvens sættes i dette register, og er en neddeling af mikrocontrollerens clock-frekvens. TCNTx (Timer/CouNTer) er et tælleregister, hvor timerens tæller avancerer med én, for hver timer clock cycle. Timeren kan skaleres ved at skrive en værdi i registret og derefter vente på, at timeren når sin grænse. Dermed er det muligt at opnå et ønsket tidsinterval. 12.1.8 ISP En praktisk egenskab ved AVR mikrocontrollere er den såkaldte ISP, In System Programming. Via en 6 pins IDC-header er det muligt at skrive en ny programkode og/eller ændre indholdet af EEPROM en uden at mikrocontrolleren skal tages ud af kredsløbet. F.eks. kan Atmels AVR-STK500 kit, eller en simpel dongle til parallelporten på en PC anvendes til at læse software ind i mikrocontrolleren ad denne vej. 12.2 Fælles hardware 12.2.1 Reset-kredsløb RESET på mikrocontrolleren er tilsluttet et RC-led. Ved opstart skal RESET asserteres i mindst 50 ns. [AT90S2313.pdf, 2005] For at sikre, at reset-pulsen er rigeligt lang til at opnå et veldefineret reset, vælges at dimensionere RC-ledet så reset-pulsen bliver 5 ms. Dette gøres ud fra opladningsformlen for et RC-led. ( ) V th = V cc 1 e ( t RC ) [V] (12.1) C = ( t R ln 1 V th Vcc ) [F] (12.2) 5 10 C = 3 s = 264 nf (12.3) 10kΩ ln(1 4.25 V 5.00 V ) Hvor V th = 4.25 V er threshold spændingen for indgang i reset-kredsløbet. Nærmeste standardværdi for C er 330 nf, der resulterer i en reset-puls med en varighed på 6.26 ms. Et RC-led er ikke den ideelle løsning idet opladningskurven for en kondensator ikke er at betegne som et logisk skift fra 0 til 1. Den korrekte løsning er et reset-kredsløb som anført i diagrammet i kapitel 5.5 på side 28. Udover en veldefineret reset-puls, opnås også reset ved for lav forsyningsspænding. Imidlertid er 64

KAPITEL 12. HARDWARE TIL PERIFERE ENHEDER der af tids- og pladshensyn valgt en RC-løsning til de perifere enheder, og praksis viser, at det kan fungere. En kontakt er monteret parallelt over kondensatoren for give muligheden for at kunne kortslutte denne og dermed starte et reset. 12.2.2 RS485 Transceiver For at opnå interface til den serielle bus er UART en i mikrocontrolleren tilsluttet en MAX487 RS485 transceiver. I afsnit 8.2 på side 40 er MAX487 beskrevet. RXD og TXD på mikrocontrolleren er forbundet til hhv. RO og DI på RS485-transceiveren. På RO (Receiver Out) udgangen findes det serielle signal, som transceiveren modtager på bussen. Dette ben har kun data på sig, når RE (Receive Enable) er asserteret, ellers er det i tristate. For at sikre, at RXD på mikrocontrolleren ikke opfanger tilfældige data i denne tilstand er en 4.7 kω modstand monteret til V cc. DE og RE er begge forbundet til PD2. PD2 er asserteret når mikrocontrolleren sender data, og sikrer dermed at RS485 transceiveren skifter til sendemodus. Når PD2 er negeret, er transceiveren i modtagemodus. Dermed kan software i mikrocontrolleren bestemme, om der sendes eller modtages på RS485 bussen. MAX487 kan fungere op til 250 kbps, og lever derfor op til kravet på 115.2 kbps. 12.2.3 Valg af krystal AVR-serien har indbygget 16-deler, der kan dele mikrocontrollerens clock-frekvens således, at den ønskede UART-hastighed opnås. UBRR registret bestemmer, hvor mange gange mikrocontrollerens clock-frekvens skal deles med 16. Ganges 115200 med 32 fås 3 686 400. Altså kan krystalfrekvensen med standardværdi 3.6864 MHz anvendes, og UBRR beregnes ud fra (12.4) opgivet i datablad [AT90S2313.pdf, 2005, s. 47]: bps = UBRR = UBRR = f CLK 16 (UBRR + 1) [bps] (12.4) ( ) fclk 1 [ ] (12.5) bps 16 ( 3.6864 10 6 ) Hz 115.2 10 3 1 = 1 [ ] (12.6) bps 16 UBRR registret sættes til 1 under initialiseringen af mikrocontrolleren. Dermed opnås den ønskede hastighed i UART en. 12.2.4 Strømforsyning Mikrocontrolleren kræver en forsyningsspænding på 2.7 V til 5 V. Til formålet er indsat en 78L05 spændingsregulator. I henhold til regulatorens datablad [LM78L05.pdf, 2005] er den afkoblet på ind- og udgang for at hindre selvsving. Kredsløbet kan køre på alle spændinger imellem 6 V og 30 V. Strømforbruget i de perifere enheder er så lavt, at effektafsættelsen i spændingsregulatoren ikke antager en problematisk størrelse. Der er indsat afkoblingskondensatorer på de integrerede kredse for at filtrere evt. støj væk. 12.2.5 Transmissionsindikation Der er via to BC547B transistorer tilsluttet to lysdioder, den ene på PD2, den anden på PD3. De udgør ikke en for de perifere enheder nødvendig funktion, men tjener til indikation af, om der hhv. sendes eller modtages data via RS485 transceiveren. Med udgangspunkt i, at lysdioderne trækker I D = 10 ma og at strømforstærkningen i transistorerne er h F E = 150, kan basismodstande R b og formodstande R D til lysdioder beregnes: I c = I D = 10 ma (12.7) 65

12.3. INDIVIDUEL HARDWARE I b = I c 10 ma = = 66.6 µa h F E 150 (12.8) V Rb = 5 V V be = 5 V 0.6 V = 4.4 V (12.9) R b = V R b 4.4 V = I b 66.6 10 6 = 66 kω A (12.10) Her er spændingen mellem collector-emitter V CE sat til 0.2 V i mætning. V RD = 5 V V ce V D = 5 V 0.2 V 2 V = 2.8 V (12.11) R D = V R D = 2.8 V = 280 Ω (12.12) I D 10 ma De fundne modstandsværdier findes i E96 standardrækken. 12.3 Individuel hardware Følgende individuelle krav stilles til de perifere enheder: Lygtekontrolenhed: Digitale indgange til kontakter. Lygteenhed: Digitale udgange til relæer. Olieenhed: Analog indgang til olietryktransducer. 12.3.1 Hardware til lygteenhed og lygtekontrolenhed Atmel AT90S2313 har i alt 15 konfigurerbare ind- og udgange, indbygget UART og timer [AT90S2313.pdf, 2005]. Den beregnede clock-frekvens på 3.6864 MHz gør, at 4 MHz typen kan anvendes. Med denne mikrocontroller som central komponent konstrueres det tilhørende elektriske kredsløb. Til lygteenheden tilsluttes 4 relæer (RL 61 - RL 64 ) som anført på folduddiagrammet, der findes i appendiks R på side 193. Da udgangene på en AT90S2313 kan levere maksimalt 3 ma, og derfor ikke kan give de 50 ma et relæ kræver, er der indsat transistorer T 61 - T 64. Udgangene PB0-PB3 er via modstandene R 61 R 64 forbundet til basis på de 4 transistorer T 61 T 64. Modstandene beregnes herunder. Der tages udgangspunkt i at relæerne trækker 50 ma: I b = Ic 50 ma = = 0.33 ma h F E 150 (12.13) V Rb = V CC V be = 5 V 0.6 V = 4.4 V (12.14) Rb = V Rb = 4.4 V = 13.2 kω I b 0.33 ma (12.15) For at sikre at transistorerne er helt mættede, sættes R 61 R 64 til 10 kω. Dette resulterer i en basisstrøm på 0.44 ma. En diode er sat i antiparallel over relæspolen på hvert relæ for at sikre at den strøm, der pga. selvinduktion opstår, når der slukkes for relæerne, ikke ødelægger deres respektive transistorer. Relæernes kontaktsæt er tilsluttet pærer placeret i forlygtehuset og blinklyshuset. Pærerne har fælles stel. Til lygtekontrolenheden er der monteret 4 kontakter i form af et ratstamme kontaktgreb, hvorfra lyset betjenes. Kontakterne er tilsluttet PORTB. Se diagrammet for lygteenhed og lygtekontrolenhed i appendiks R på side 193. 12.3.2 Hardware til olieenhed I modsætning til lygteenhed og lygtekontrolenhed, der kun har brug for digitale ind- og udgange, kræver olieenheden en analog indgang. Derfor kan AT90S2313 ikke anvendes. Istedet vælges AT90S8535, der har en analog til digital converter (ADC) indbygget. ADC-kredsløbet inde i mikrocontrolleren er støjfølsomt, hvorfor særlige hensyn skal tages hertil. L 71 og C 78 udgør et LC-filter til strømfors-yningen af ADC-kredsløbet i mikrocontrolleren. Kredsløbet er udført efter anvisninger fra databladet for mikrocontrolleren [AT90S8535.pdf, 66

KAPITEL 12. HARDWARE TIL PERIFERE ENHEDER 2005, side 74]. P 71 er et potentiometer, der emulerer olietryk. Potentiometeret tilfører en analog DC-spænding til benet ADC0. Mikrocontrolleren har en analog reference indgang AREF. Fuld udstyring af konverteren opnås, når en analog indgang har samme spænding som referenceindgangen. AREF er forbundet til 5 V. 12.3.3 Succesiv approximation Den indbyggede ADC i AT90S8535 bygger på princippet om successiv approximation. Den har en opløsning på 10 bit. Successiv appoximation består af dels en digital til analog converter (DAC), en analog komparator samt et output dataregister. På figur 12.3.3 på næste side ses et flowdiagram for processen. Det analoge indgangssignal føres til det ene input på komparatoren, og DAC ens udgang til det andet input. Først sættes det mest betydende bit (MSB) i DAC en (c), og er dennes spænding lavere end indgangsspændingen (d), bliver komparatoren høj på udgangen. Denne binære værdi overføres til ADC ens dataregister på den mest betydende bit s plads (e). Dermed er en cycle overstået. Processen gentages med det næst-mest betydende bit, og fortsætter indtil LSB er nået (b). Er det en 10 bit ADC, tager processen 10 clock cycles [Clements, 2000, side 661]. 12.4 Test De perifere enheders test opdeles i en kommunikationstest og en test af de tilsluttede enheder. Der fremstilles et stykke testsoftware, der svarer det samme tilbage som der modtages via RS485-transceiveren. Desuden udvikles et stykke software, der er i stand til at styre og læse relæer, kontakter og analogt input. Testsoftware er anført i appendiks K.2 på side 170. 12.5 Resultater Med den anførte testsoftware er de perifere enheder testet. Resultatet af testen ses i tabel 12.1. Enhed RS485 test Input test Output test Analog til digital test Lygtekontrolenhed Ok Ok - - Lygteenhed Ok - Ok - Olieenhed Ok - - Ok Tabel 12.1: Testresultater for de perifere enheder. 12.6 Delkonklusion Hardware til de perifere enheder er konstrueret, samlet og afprøvet og fungerer i henhold til både den fælles kravspecifikation og de individuelle krav. Enhederne er, set fra et hardwaremæssigt perspektiv, simple og kan fremstilles med f.eks. SMT, hvorved der opnås en lille fysisk størrelse, der gør den egnet til indbygning i f.eks. et lygtehus. 67

12.6. DELKONKLUSION Start på konvertering Sæt x lig antallet af bit (AD converterens opløsning) a Slut på konvertering [Ja] Er x=0? b [Nej] Tænd bit #x i DAC c Tæl x én ned g [Nej] Er DACspænding større end indgangsspænding? d [Ja] Indsæt logisk 1 på bit #x s plads i ADC register e Indsæt logisk 0 på bit #x s plads i ADC register f Figur 12.3: Flowdiagram for A/D-konvertering efter successiv approximationsprincippet. 68

Del IV: Software Første kapitel i denne del omhandler udviklingen af en protokol til kommunikationen på den serielle bus. Kapitel 14 virker som en introduktion til den videre softwareudvikling, og den valgte udviklingsmodel beskrives. Software til minimumsystemet nedbrydes i mindre delprocesser gennem kapitel 15 og til sidst programmeres de enkelte funktioner. Det sidste kapitel i denne del omhandler softwareudviklingen til de tre perifere enheder. Del IV: Software 69 13 Protokol 71 13.1 Indledning............................................... 71 13.2 Opbygning.............................................. 71 13.3 Fejlhåndtering............................................ 74 14 Introduktion til softwareudvikling og metodevalg 77 14.1 Introduktion til software....................................... 77 14.2 Metode................................................ 78 15 Software til minimumsystem 81 15.1 Programdesign............................................ 81 15.2 Procesdesign............................................. 83 15.3 Moduldesign............................................. 85 15.4 Delkonklusion............................................. 97 16 Software til perifere enheder 99 16.1 Programdesign............................................ 99 16.2 Procesdesign............................................. 100 16.3 Moduldesign............................................. 102 16.4 Delkonklusion............................................. 110

KAPITEL 13. PROTOKOL Kapitel 13 Protokol 13.1 Indledning I dette afsnit skal der udvikles en protokol til kommunikationen på den serielle bus mellem masteren og de forskellige slaveenheder. Protokollen bygger ovenpå det fysiske lag, der for dette system følger foreskrivelserne fra RS485 standarden. En oversigt over benyttelsen af protokollen ses af figur 13.1. Da mængden af information, der skal flyttes i dette system er lav, sammenlignet med andre bussystemer som eksempelvis TCP/IP, benyttes der kun én databyte. Mange nutidige protokoller benytter i starten af hver pakke en byte til angivelse af størrelsen på et variabelt antal efterfølgende databytes [P-NET, 2005]. Protokollens korte pakker af ensartet længde giver en nemmere dekodning, hvorimod protokollens udvidelsesmuligheder, og kompleksiteten af informationen der kan overføres, er begrænset [Tanenbaum, 1999]. Lygtekontrolenhed Lygteenhed Olieenhed Minimumsystem Protokol bygget ovenpå RS485 standarden Figur 13.1: Oversigt over de enheder, der benytter den udviklede protokol. 13.2 Opbygning Den valgte protokolopbygning til systemet kan ses på figur 13.2. På tegningen er ikke anført start-, stop- og paritetsbit, men disse indgår i hver frame. Masterens forespørgsler er opbygget af 3 frames til henholdsvis adressering, kommando/id og data. Herefter følger slavens svar på to frames. Dette svar indeholder i første frame en kopi af den modtagne forespørgsels anden frame. Gennem en sammenligning i masteren mellem disse, kan det efterfølgende evalueres, om slaven udførte den rigtige kommando - eller om kommandoen blev fejltransmitteret. Denne form for kommunikation kaldes en connection-less forbindelse med brug af acknowledgement. Connection-less, fordi alt information til en instruktion afsendes i én pakke - i modsætning til connection-oriented forbindelse, hvor flere pakker transmitteres og sammensættes i modtagerenheden. Acknowledgement fortæller, at der fra slaveenhederne svares tilbage på en given forespørgsel [Tanenbaum, 1999]. Da slaveenhederne i dette system ikke selv kan tage initiativet til at starte kommunikation, og da disse enheder derfor heller ikke kan kommunikere indbyrdes, er det ikke nødvendigt med en adresseringsframe i slave svaret. Dette skyldes, at kommunikation på bussen umiddelbart efter afsendelsen af den tredje frame i en masterforespørgsel kun kan være den adresserede slaves svar herpå - og svaret kan kun være tiltænkt 71

13.2. OPBYGNING masteren. Systemet opbygges, så en buscycle svarer til tiden det varer at sende 10 frames. Dette betyder, at alle slaveenheder skal indeholde en timer, der ved detektering af påbegyndt kommunikation på bussen skal vente tiden t delay før de igen forventer en adresseframes ankomst. Ved at anvende denne timerfunktion, undgås det at bruge en startbyte i hver pakke. En sådan startbyte giver problemer, hvis der senere i en pakke afsendes et bitmønster svarende til startframens [Tanenbaum, 1999]. t delay er beregnet i appendiks O. Med en buscycle på 10 bytes og en bushastighed jvf. afsnit 8.2 på side 40 på 115.2 kbps kan cycle-tiden t cycle beregnes til: t cycle = 10 frames 11 bit 115200 bps = 955 µs (13.1) Dette svarer til 1047 buscycles i sekundet, hvis det antages, at ingen fejltransmissioner forekommer. Mere om fejlhåndtering i afsnit 13.3. 1. byte adr. adr. adr. adr. adr. adr. adr. adr. 2. byte cmd cmd cmd cmd ID ID ID ID Master forespørgsel 3. byte data data data data data data data data 4. byte Ingen trafik på bus 5. byte Ingen trafik på bus 6. byte Ingen trafik på bus Slave udfører beregninger 7. byte Ingen trafik på bus 8. byte Ingen trafik på bus 9. byte cmd cmd cmd Ingen cmd trafik ID på bus ID ID ID 10. byte Ingen trafik på bus data data data data data data data data Slave svar Figur 13.2: Opbygningen af en buscycle for den udviklede protokol. Betegnelsen af de forskellige bit på figur 13.2 angiver: 1. frame: Adressering (adr.) Den første frame afsættes til adressering. Denne adressering benyttes af masteren til at indikere, hvilken slaveenhed, der ønskes kontakt med. Det er i kravspecifikationens afsnit 2.3 på side 11 beskrevet, at systemet skal kunne tilsluttes op til 128 enheder. Dette krav imødekommes, idet der med protokollens 8 adresseringsbit kan adresseres op til 256 enheder. 2. frame: Kommando (cmd) De første 4 bit i anden frame benyttes til at angive, hvilken kommando masteren ønsker, at slaven skal 72

KAPITEL 13. PROTOKOL udføre. I tabel 13.1 er alle kommandoer for protokollen angivet, og disse vil senere blive gennemgået enkeltvis. De 4 bit til dette formål giver mulighed for op til 16 forskellige kommandoer. 2. frame: ID (ID) De sidste 4 bit i anden frame benyttes til at angive, hvilket ID på den adresserede enhed, der ønskes manipuleret eller aflæst. Et ID kan f.eks. henvise til: -En I/O-port, hvor dataframens 8bit hver repræsenterer et I/O-ben. -En A/D converter, hvor den målte analoge spænding kan aflæses. -En vilkårlig adresse i hukommelsen, der ønskes aflæst/manipuleret af masteren. 3. frame: Data (data) Tredje frame indeholder de data der sendes. De transmitterede data kan fortolkes på to forskellige måder; enten som en binær værdi mellem 0 og 255 - eller som en benstatus til/fra en slaveenhed. Benstatus formatet refererer direkte til benene på den slaveenhed, eksempelvis henviser bit 4 direkte til ben 4. Formatet benyttes ved on/off status på benene, hvor 1 angiver et tændt ben og 0 angiver et slukket ben. Dette benyttes senere af de forskellige kommandoer angivet i tabel 13.1. Kommandoerne der kan anvendes i frame 2 er angivet i tabel 13.1 og har følgende betydning: Kommando (cmd) Sæt værdi 0-255 Indhent værdi 0-255 Start funktion AND OR XOR Stop funktion Fejl Bitmønster 0001 b 0010 b 0100 b 0101 b 0110 b 0111 b 1000 b 1111 b Tabel 13.1: De definerede kommandoer i protokollen. Sæt værdi 0-255 Når denne kommando bruges i masterens forespørgsel, følger en værdi fra 0 til 255 i dataframen. Denne værdi skal overføres til det ID, der angives i frame 2, hvilket kunne være en eller flere porte. Indhent værdi 0-255 Med denne kommando angives, at der ønskes afsendt en værdi mellem 0 og 255 fra den adresserede slaveenhed. Denne værdi skal aflæses fra det afsendte ID angivet i frame 2 på figur 13.2. Start funktion Når denne kommando bruges i masterens forespørgsel, følger en værdi fra 0 til 255 i dataframen. Denne værdi refererer til en intern funktion i den adresserede slaveenhed. AND Når denne kommando bruges i masterens forespørgsel, følger et bitmønster i dataframen. Der skal herefter udføres en logisk AND operation mellem det aktuelle bitmønster og det modtagne bitmønster i slaveenheden. Denne kommando vil bl.a. kunne benyttes til at sætte alle udgange på en slaveenhed lave ved afsendelse af 00000000 i dataframen fra masteren. OR Når denne kommando bruges i masterens forespørgsel, følger et bitmønster i dataframen. Der skal herefter i slaveenheden udføres en logisk OR operation mellem det aktuelle bitmønster og det modtagede bitmønster. Denne kommando vil bl.a. kunne benyttes til at sætte udgange på en slaveenhed høje uanset nuværende bitmønster. Eksempelvis vil afsendelse af 00010100 i dataframen fra masteren sætte udgangene 3 og 5 på slaveenheden høje, og hvis disse i forvejen er høje vil de forblive høje. 73

13.3. FEJLHÅNDTERING XOR Når denne kommando bruges i masterens forespørgsel, følger en benstatus i dataframen. Der skal herefter udføres en logisk XOR operation mellem det aktuelle bitmønster og det modtagne bitmønster i slaveenheden. Denne kommando vil kunne benyttes til at invertere udgange på en slaveenhed uanset nuværende bitmønster. Eksempelvis vil afsendelse af 00010100 i databyten fra masteren invertere udgang 3 og 5 på slaveenheden. Fejl Denne kommando er forbeholdt slaven, og er det eneste tilfælde, hvor slaven ændrer kommandofeltet i dennes svar til masteren. Fejlens type angives efterfølgende i dataframen fra slaven. Herved spares på antallet af brugte kommandoer - der benyttes kun én kombination af de 16 mulige på at fortælle, at der er opstået en fejl. Herefter kan masteren aflæse i dataframen fra slaven, hvilken fejltype der er tale om. Det er også en mulighed at definere et helt nyt kommandosæt for kommunikation mellem slave og master, men dette vil afskære masteren fra at bruge den afsendte frame 2 og den modtagne frame 4 som sammenligningsgrundlag for fejltransmission. De forskellige fejlmuligheder er beskrevet i afsnit 13.3 og kan findes i tabel 13.2. 13.3 Fejlhåndtering Der anvendes i protokollen 1 paritetsbit pr. frame, og pariteten er valgt til lige. Dette giver en Hamming distance på 2, hvilket betyder, at der ikke er mulighed for fejlkorrektion ved modtagelse af en frame indeholdende bitfejl. Denne mulighed er fravalgt, idet det vurderes at protokollens pakker er så korte, at det ved detektering af en paritetsfejl i en frame, bedre kan betale sig at sende en ny pakke istedet for at foretage korrektion. Skulle der være mulighed for at korrigere èn bit fejl pr. frame, ville dette kræve 4 paritetsbit pr. frame [Tanenbaum, 1999]. Hvis antallet af modtagne frames uden én bitfejl angives n, og antallet af modtagne frames med præcis én bitfejl angives k kan det beregnes, hvornår det rent datamæssigt ville være rentabelt at indføre korrektion i stedet for at afsende en ny pakke ved detektion af fejl: 11 n + 11 2 k = 14 n + 14 k (13.2) k (11 2 14) = n (14 11) (13.3) k = 3 8 n (13.4) Dette betyder, at hvis der forventes én bitfejl i mindst 37.5% af alle transmitterede frames, så ville en korrektion virke trafikbesparende på bussen i denne protokols tilfælde. Dette tal er ifølge [Tanenbaum, 1999] urealistisk højt, hvorfor protokollens håndtering af fejltransmitterede pakker synes rentabel. Fejlkode (data) Paritetsfejl Fejl i udførelse af kommando Fejl i enhed Bitmønster 00000001 b 00000010 b 00000011 b Tabel 13.2: De definerede fejlkoder i protokollen. Det blev i afsnit 13.2 beskrevet, hvordan fejlkoderne fra slaveenhederne skulle afsendes i disses databyte. I tabel 13.2 ses de definerede fejlkoder for protokollen og deres betydning er: Paritetsfejl Denne fejl sendes retur fra slaveenheden, hvis der detekteres en paritetsfejl i en af de 3 modtagne bytes fra masteren. Masterens reaktion på denne fejl er at sende den pågældende frame igen. 74

KAPITEL 13. PROTOKOL Fejl i udførelse af kommando Denne fejl sendes retur fra slaveenheden, hvis den modtagne kommando ikke kan udføres af enheden. Dette kunne f.eks. blive aktuelt, hvis udgange tilgås som indgange eller omvendt. Masterens reaktion på denne fejl er, at sende samme kommando igen, da fejlen kan skyldes en dobbelt bitfejl i frame 2 ved slavens aflæsning. Fejl i enhed Denne fejl sendes retur fra slaveenheden, hvis enheden har en intern fejl, der forhindrer udførslen af den modtagne kommando. 75

KAPITEL 14. INTRODUKTION TIL SOFTWAREUDVIKLING OG METODEVALG Kapitel 14 Introduktion til softwareudvikling og metodevalg Dette kapitel har til formål at give en introduktion til softwareudviklingen til det konstruerede hardwaresystem. Det er valgt at benytte SPU-modellen til dele af softwareudviklingen, og denne metodes anvendelse på problemstillingen vil blive beskrevet. 14.1 Introduktion til software Dette afsnit indeholder en beskrivelse af opbygningen af de flowdiagrammer, der benyttes i denne del af rapporten. Herefter nævnes de anvendte programmeringssprog og den anvendte kompiler. Sidste afsnit beskriver hovedidéen bag den efterfølgende softwareudvikling. 14.1.1 Flowdiagrammer Der benyttes i softwareudviklingen flowdiagrammer til at overskueliggøre strukturen af de enkelte moduler. En oversigt over betydningen af de benyttede blokke ses på figur 14.1. Pile mellem de enkelte blokke vil Start / Slut Spørgsmål Summering Resultat / Udførelse Figur 14.1: Betydning af flowdiagrammer i softwareudviklingen. indikere vejen der kommunikeres, og blokkene navngives fortløbende alfabetisk fra højre mod venstre, oppefra og nedefter. 14.1.2 Sprog og kompilere Der benyttes i programmeringen af masterenheden både C og assembler, hvorimod programmeringen af de perifere enheder foretages udelukkende i C. Kompileren, der benyttes til krydskompileringen af filerne til masterenheden, hedder GNU m68k Embedded Development Environment og er udviklet af MotoRobots Software Libraries [Libraries, 2003]. 77

14.2. METODE 14.1.3 Softwareidé for master Hovedparten af kodningen til dette system ligger i masterenheden. Denne enhed skal indsamle information fra de forskellige perifere enheder, behandle disse informationer og udsende resultatet til de perifere enhederne igen. Grundtanken i den udviklede software til masterenheden er at indsamle al data fra de perifere enheder, der er tilstede på bussen, før behandling af data foretages. Disse data placeres i en tabel, hvorfra den senere efterbehandling tager sit udgangspunkt. Alternativt kunne det vælges at indhente data fra perifere enheder efterhånden som disse blev nødvendige for afviklingen af programmet. Dette ville give nyere data at bearbejde, men det argument vægter lavt, idet tidskritiske funktioner jvf. afsnit 2.3 på side 11 ikke behandles i dette system. Fordelen ved at benytte en tabel indeholdende al data er, at den indbyrdes kommunikation mellem de forskellige moduler og funktioner i programmet mindskes - denne kommunikation flyttes til at indebære læsning og skrivning til tabellen. Herved bliver rækkefølgen de forskellige perifere enheder behandles i også ligegyldig - idet ingen perifere enheder er afhængig af tidligere enheders data. Selve behandlingen af data fra de perifere enheder sker kronologisk, hvor hele behandlingen for en enhed færdiggøres inden næste påbegyndes. Efter behandling af sidste enhed opdateres hele tabellen med ny information fra de perifere enheder og der begyndes forfra med behandlingen af disse. Behandlingen af en perifer enhed vil overordnet blive: 1. Behandling af data. 2. Evaluering af behandlingen. 3. Eventuel udsendelse af resultater til de involverede perifere enheder. 4. Eventuel ny data tilsendt de involverede perifere enheder skrives til tabel. 5. Display-status for den behandlede perifere enhed opdateres. Det er valgt at udsende de behandlede data efterhånden som de behandles. Herved vil data altid være opdateret i tabellen når behandlingen af en perifer enhed påbegyndes. Dette ville ikke have været tilfældet, hvis der var anvendt en samlet udsendelse af data fra alle celler i tabellen efter endt behandling af alle enheder. 14.1.4 Softwareidé for perifere enheder De perifere enheder i dette system kan ikke selv tage initiativet til udsendelse af data på bussen, hvilket betyder at softwaren i disse enheder kan skrives forholdsvis simpel. Opbygningen er grundlæggende ens for alle konstruerede enheder: 1. Modtagelse af forespørgsel fra master. 2. Behandling af data. 3. Afsendelse af svar til master. Punkt 2 indeholder først et paritetscheck, hvorefter den egentlige behandling af data foretages udfra den modtagne kommando (se figur 13.1 på side 73). 14.2 Metode Det er for softwareudviklingen til denne prototype valgt at benytte SPU-modellen. Det vigtige ved denne model er, at den opdeler udviklingsforløbet i et stort antal aktiviteter, der testes individuelt inden de samles. Modellen indeholder således mange checkpunkter, hvor udviklingens status og kvalitet kan vurderes. De tre aktiviteter, modellen nedbryder udviklingen til, er programdesign, procesdesign og moduldesign. I programdesign opdeles programmet i et antal parallelle processer og deres indbyrdes og eksterne grænseflader fastlægges. I det efterfølgende procesdesign designes hver proces som et sekventielt selvstændigt program. Processerne nedbrydes herefter i et antal moduler og for hvert modul udarbejdes en modulspecifikation 78

KAPITEL 14. INTRODUKTION TIL SOFTWAREUDVIKLING OG METODEVALG med samtlige krav og grænseflader for modulet. Herefter følger selve implementationen med modulkodningen. Hvert modul testes individuelt og herefter i samspil med de andre moduler i den enkelte proces. Til sidst sammenkobles de forskellige processer og den endelige accepttest udføres [Biering-Sørensen, 2000]. Ovenstående nedbrydning af udviklingen ved benyttelse af SPU-modellen ses på figur 14.2. Kravspecifikation Accepttest Program design Proces integration Proces design Modul integration Modul design Modul test Modul kodning Figur 14.2: V-modellen for softwareudvikling [Biering-Sørensen, 2000]. I softwareudviklingen til dette system er der benyttet prototyping til punktet modultest i figur 14.2. Ved prototyping udarbejdes et primitivt skeletprogram, der kan simulere endnu ikke færdigkodede funktioner. Prototyping er nemt at anvende sammen med SPU-modellen, fordi modulspecifikationerne direkte kan fortælle programmøren, hvordan funktionerne i prototypeprogrammet skal udformes. Prototype funktioner anvendt til modultest for systemet ses i appendiks K.1 på side 169. Selve softwareudviklingen til masteren, der opbygges efter SPU-modellen, findes i det efterfølgende kapitel 15 på side 81. 79

KAPITEL 15. SOFTWARE TIL MINIMUMSYSTEM Kapitel 15 Software til minimumsystem I dette kapitel designes software til minimumsystemet. Designet indledes med programdesign, hvor opgaver inddeles i processer, for derefter at opdele disse processer i moduler. Til slut designes modulerne hver for sig. Resultatet af hele designprocessen ses på figur 15.1, hvor de nederste enkeltstående moduler indikerer, at disse er fælles moduler, som andre moduler løbende benytter. Proces Initialisering a Løkke b Display c Initialiser hardware Opret tabel Opdater tabel Løkke styring d e f g Lygte kontrol Olie Display kontrol interface h i j Modul Fælles moduler Bus k Ændre tabel l Figur 15.1: Proces- og moduloversigt for minimumsystemet. 15.1 Programdesign 15.1.1 Valg af designmetode Der er valgt en top-down fremgangsmåde til designet. Top-down metoden passer på beskrivelsen af denne software, idet formålet med softwaren er kendt og de eksterne grænseflader er veldefinerede. Derfor kan softwaren nemt opdeles i et antal processer for videre design. 81

15.1. PROGRAMDESIGN 15.1.2 Eksterne grænseflader Software til minimumsystemet grænser op til bussystemet, PC en samt et interface til brugeren vha. taster og display. Disse er vist i figur 15.2. Minimumsystem ACIA485 a RS485 Perifere enheder b ACIA232 RS232 PC c d 2 taster og display e Fysisk Bruger f Figur 15.2: Grænseflader for program i minimumsystem. Grænsefladen til den serielle bus udgøres af ACIA485. På denne bus kobles de perifere enheder, der styres fra minimumsystemet. Interfacet til bussen er registre i ACIA485, der kan manipuleres fra minimumsystemet. Grænsefladen til PC udgøres af ACIA232. Det er muligt at anvende ACIA232 til direkte kommunikation med PC en, eller gennem TS2-MON. Kontrollen kan overdrages fra TS2-MON til programafvikling igennem kontrolterminalen på PC en. Kontrollen tilbageføres til TS2-MON vha. interrupt 7 (NMI), der betjenes manuelt. Grænsefladen til brugeren udgøres af et display samt 2 taster. Denne grænseflade er beskrevet som UseCase i afsnit B.2 på side 133. 15.1.3 Opdeling i processer Den overordnede struktur i programmet med opdelingen af processer kan ses af figur 15.3. Initialiseringsprocessen gennemføres en gang ved systemopstart, hvorefter kontrollen overgives til løkkeprocessen. Denne proces er derefter rammen om resten af softwareafviklingen. Fra løkkeprocessen kaldes moduler, der skal styre de perifere enheder og displayet. Displayet har tildelt sin egen proces, idet denne også kaldes fra interrupts. Initialisering Løkke Display a b c Figur 15.3: Procesforløb i minimumsystem. 82

KAPITEL 15. SOFTWARE TIL MINIMUMSYSTEM 15.1.4 Grænseflader mellem processer Grænsefladen mellem initialiseringsprocessen og løkkeprocessen består i løkkeprocessens udnyttelse af tabellen oprettet i initialiseringsprocessen. Displayprocessen indeholder en tabel over tekst, der kan vises på displayet. Denne tabel kan moduler under løkkeprocessen tilgå vha. displayfunktioner i displayprocessen. 15.1.4.1 Specifikation af datatabel Tabellen defineres i initialiseringsprocessen. Denne skal indeholde 16 byte data pr. perifer enhed, en charværdi for hvert ID fra 0 til 15. ID er beskrevet under protokollen, afsnit 13 på side 71. Med 128 enheder bliver dette 2048 bytes. Tabellens placering i hukommelse styres dynamisk under programkompilering. Ligeledes sørger kompileren for, at intet andet data placeres i dette område. 15.1.4.2 Specifikation af displaytabel Tabellen defineres til at indeholde 128 pointers til strenge af 20 karakterer. Tabellens placering i hukommelse styres dynamisk under programkompilering. 15.2 Procesdesign Herunder beskrives hver enkelt proces i minimumsystemets software. 15.2.1 Initialisering Formålet med initialiseringen er at behandle systemopstart korrekt. Processen gennemføres en gang ved opstart, hvorefter kontrollen overgives til løkke processen. 15.2.1.1 Eksterne grænseflader Initialiseringen har de to ACIA-enheder samt displayet som grænseflader. Datatabellen oprettes også i denne proces, hvor efter initialiseringsprocessen tilbyder denne til andre moduler. 15.2.1.2 Opdeling i moduler Initialiseringsprocessen er opdelt i to moduler, som er vist på figur 15.4. Initialisering af hardware modulet skal sørge for, at ACIA er og display initialiseres korrekt, og der foretages desuden en opsætning af interruptrutinerne. Opret tabel modulet opretter den førnævnte tabel. Proces Initialisering a Moduler Initialisering af hardware b Opret tabel c Figur 15.4: Moduloversigt for initialiseringsprocessen. 15.2.1.3 Grænseflader mellem moduler Der er ingen grænseflader imellem modulerne. Disse kaldes sekventielt. 83

15.2. PROCESDESIGN 15.2.2 Løkke Formålet med løkkeprocessen er at agere ramme for den videre afvikling af softwaren. I starten af hver løkkesekvens opdateres tabellen med de perifere enheders status, hvorefter moduler til styring af perifere enheder kaldes efter tur. Hvert indsat modul styrer selv kommunikation til perifere enheder og tabel. 15.2.2.1 Eksterne grænseflader Løkkeprocessens grænseflader består af de fælles ændre tabel og bus moduler. Desuden henter og sender løkkeprocessens moduler data ind fra de perifere enheder, hvorved disse også udgør en grænseflade via ACIA485. 15.2.2.2 Opdeling i moduler Løkkeprocessen opdeles herefter i moduler som vist i figur 15.5. Løkkestyring udfører den egentlige løkke funktion og kalder i starten af hver løkke sekvens Opdater tabel modulet, der opdaterer informationerne i tabellen fra de perifere enheder. Herefter kaldes modulerne lygtekontrol og oliekontrol. Proces Løkke a Moduler Opdater tabel Løkkestyrinkontrol Lygte- Oliekontrol b c d e Figur 15.5: Moduloversigt for løkkeprocessen. 15.2.2.3 Grænseflader mellem moduler Løkkestyring kalder de pågældende processer, hvorved disse udgør en grænseflade. Samspillet mellem modulerne udgøres af den oprettede tabel. 15.2.3 Display Formålet med displayprocessen er at styre displayet efter de specificerede krav fra UseCases i appendiks B på side 133. Samtidig ønskes fejlbeskeder vist på displayet. Displayprocessen indgår ikke i løkkeprocessen, men anvendes af de forskellige moduler heri til at skrive til displayet. Implementeringen udføres vha. et array af pointers, der peger på tekststrenge placeret i hukommelsen. Modulerne, der behandler de perifere enheder, har hver mulighed for at indsætte en pointer til en streng af 20 karakterers længde i dette array. Brugeren kan via tasterne bevæge sig i dette array, og dermed vælge hvilken information der vises. 15.2.3.1 Eksterne grænseflader Displayets grænseflade til brugeren består af to taster. Disse to tasterer aktiverer to interrupt-rutiner, således at brugeren altid har mulighed for at vælge hvad displayet skal vise. 15.2.3.2 Opdeling i moduler Displayprocessen vælges opdelt i et enkelt modul, der tilbyder funktioner til andre processer eller moduler. 84

KAPITEL 15. SOFTWARE TIL MINIMUMSYSTEM 15.2.3.3 Grænseflader mellem moduler Displayprocessen udnytter ikke nogen funktioner i andre moduler, men tilbyder selv funktioner til styring af displayet. Disse gennemgås senere i moduldesignet for displaymodulet. 15.3 Moduldesign I dette afsnit designes modulerne enkeltvis. Disse designafsnit vil først indeholde en kort beskrivelse af modulet. Herefter følger grænsefladerne for modulet efterfulgt af den valgte opbygning af modulet. Der afsluttes med et testafsnit. 15.3.1 Moduldesign for initialisering af hardware modulet 15.3.1.1 Beskrivelse Dette modul indgår som det ses af figur 15.1 på side 81 under initialiseringsprocessen. Kildekoden til funktionerne beskrevet i dette afsnit kan ses i appendiks F på side 147. Modulet har til opgave at initialisere alt hardware ved opstart af systemet. Dette indebærer følgende: Opsætning af globale variable. Korrekt placering af stack. Opsætning af interrupts. Opsætning af ACIA485 til RS485 forbindelse. Opsætning af ACIA232 til RS232 forbindelse. Opsætning af display. Modulets entry-funktion er funktionen mbr (master boot record), der er placeret i addresse 60000 h. 15.3.1.2 Grænseflader Modulet har hardwaregrænseflader som beskrevet i afsnit 15.1.2 på side 82. Der benyttes funktioner fra displaymodulet. Modulet kaldes med via funktionen mbr, som ikke tager nogen argumenter og intet returnerer. 15.3.1.3 Opbygning Et flowdiagram over funktionen mbr ses på figur 15.6. Den overordnede virkemåde er: Start Opsætning af globale variable Placering af stack Opsætning af interrupts a b c Opsætning af ACIA485 Opsætning af ACIA232 Opsætning af display d e f Slut Figur 15.6: Flowdiagram for funktionen til initialisering af hardware. 1. I blok a opsættes de globale variabler. Herunder opsættes variable anvendt gennem hele initialiseringsmodulet. Dette gøres for at samle konfigurationsparametre et enkelt sted. Hvert modul definerer selv sine variable. 85

15.3. MODULDESIGN 2. I blok b placeres stacken. Stack pointeren placeres i 120000 h, hvilket er i slutningen af RAM området (se memory map i tabel 10.4 på side 51). 3. I blok c opsættes interrupts. Interrupt 1 og 2 opsættes til at pege på hhv. dispdown() og dispup(), beskrevet i afsnit 15.3.8 på side 95. TS2-MON remapper interrupttabellen til at starte i 40000 h. Den endelige adresse for interrupt niveau 1 beregnes som 40000 h + vektor 8 bytes, hvor vektor er interruptniveauets interne vektor nummer. Interruptniveau 1 er vektor nr. 25 og interruptniveau 2 er nr. 26. Dette giver adresserne 400CA h og 400D2 h. [Nielsen, 2003, s. 24], [Clements, 2000, s. 448]. 4. I blok d opsættes ACIA485. ACIA en til RS485-bussen opsættes ved at sende et reset-signal til dennes status ben. Herefter opsættes paritet og ACIA en sættes i sendemodus. 5. I blok e opsættes ACIA232. Denne opsættes vha. TS2-MON, men er medtaget her for helhedens skyld. 6. I blok f opsættes displayet. Denne opsætning foregår ved at sende 3 reset-signaler til displayets adresse. Herefter sættes displayets bevægelsespolitik (entry mode) og cursor type. Til sidst cleares displayet og der skrives strengen Welcome. 15.3.1.4 Test Initialiseringsmodulet er testet på minimumsystemet, hvor initialiseringen af alle enheder forløb tilfredsstillende og efter hensigten. 15.3.2 Moduldesign for busmodulet 15.3.2.1 Beskrivelse Dette modul indgår som det ses af figur 15.1 på side 81 ikke under nogen proces. Modulet er et fællesmodul, der kan benyttes af andre moduler i programmet. Kildekoden til funktionerne beskrevet i dette afsnit kan ses i appendiks I.3 på side 160. Busmodulets opgave er at kontrollere kommunikationen på bilbussen. Modulet programmeres i assembler, der som lavniveau sprog ofte er en fordel til tidskritiske processer. Selvom der ikke er et tidskrav til dette modul, vælges assembler-sproget alligevel for at gøre buskommunikationen en mindre flaskehals. Flaskehals idet kommunikationen på den serielle bus har den helt centrale rolle i systemet og derfor bliver eksekveret flest gange i processoren. Modulet bygges op med en subrutine kaldet bus, der er eneste entry-funktion. Den sørger først for at sikkerhedskopiere registrene i M68k til stacken, hvorefter parametrene til subrutinen hentes fra stacken til registrene. Den egentlige programkode for kommunikationen udføres og til slut i subrutinen videresendes de indhentede data til modulkalderen og registrene genetableres fra stacken. 15.3.2.2 Grænseflader Grænsefladen til dette modul består, som beskrevet i forbindelse med figur 15.1 på side 81, af alle moduler der ønsker at benytte sig af RS485-bussen. Modulets entry-funktion bus tager fem argumenter og returnerer to værdier. De fem argumenter er: En adresse, adr, på den perifere enhed, der ønskes kommunikation med. En kommando, cmd, der skal sendes til enheden. Et identifikationsnummer, ID, i den perifere enhed, som kommandoen skal udføres på. De data, data, der ønskes sendt til enheden. En pointer, rtn ptr, til returnering af de modtagne data eller en fejlkode. Den eksterne grænseflade består desuden af to output-parametre i form af returneringspointeren fra inputtet og funktionen selv, der returnerer 0 ved korrekt moduludførelse. I tilfælde af, at en fejl finder sted under moduludførelsen, placeres en fejlkode i pointeren og der returneres 1 fra funktionen. Fejlkoderne, der kan returneres i pointeren rtn ptr er: 86

KAPITEL 15. SOFTWARE TIL MINIMUMSYSTEM Fejlkode 4: Der blev ikke modtaget svar fra den perifere enhed indenfor tidsgrænsen. Fejlkode 5: De modtagne data stemmer ikke overens med de afsendte. Fejlkode 6: Svaret indeholdte paritetsfejl. Fejlkode x: Alle andre fejlkoder stammer fra den perifere enhed. Desuden kommunikerer funktionen eksternt på RS458-bussen vha. den konstruerede protokol fra kapitel 13 på side 71. Internt kommunikerer entry-funktionen med de to subrutiner bus r (læser en byte) og bus w (skriver en byte) vha. processorens interne dataregistre - D0-D6. Registrene bliver brugt til følgende: D0: Angivelse af fejl. D1: Adresse på perifer enhed. D2: Kommando til perifer enhed. D3: ID i perifer enhed. D4: Data til perifer enhed og antal gennemkørsler af subrutinen. D5: Tæller til timeout på svarmodtagelse. D6: Fejlkode eller data indhentet via ACIA485 fra perifere enhed. 15.3.2.3 Opbygning Modulets opbygning er vist på flowdiagrammet på figur 15.7, mens flowdiagrammerne til de to brugte subrutiner heri, er vist på figur 15.9 og 15.8. Modulet er opbygget således, at der efter hver afsendt byte (blok b og c) ventes på, at ACIA485 igen er klar vha. subrutinen bus w (blok a og m). Når alle tre bytes i forespørgslen er sendt, sættes ACIA485 til at modtage og der ventes på, at data modtages vha. subrutinen bus r (blok g, i og k). I subrutinen polles ACIA485 i blok n, mens der undersøges om en timeout-tid er nået i blok o. Hele modulet afsluttes, hvis en timeout på svartiden er nået i blok p eller der opstår en paritetsfejl i blok s. Er den først modtagne byte ikke korrekt i blok e og indeholder byten en kommandofejl i blok f, så modtages den næste byte som en fejlkode i blok i. Ved andet end fejlkommandoen modtages den næste byte og modulet afsluttes med fejl i blok h. Er første byte korrekt i blok e, modtages næste byte som data i blok l og modulet afsluttes uden fejl Timeout skal fastsættes ud fra protokollen, hvor de perifere enheder har 7 frames til at svare. Med en bushastighed jvf. afsnit 8.2 på side 40 på 115.2 kbps kan tiden for timeoutet på dette svar beregnes. t timeout = 7 bytes 11 bit 115.2 kbps = 668 µs (15.1) På denne tid kan en M68k ved 8 MHz udføre programkode i følgende antal clock cycles: Clock cycles pr. timeout = 668 µs 8MHz = 5347 clock cycles (15.2) Disse clock cycles benyttes i flere omgange primært af instruktionerne i første kolonne i tabel 15.1. Antallet af clock cycles til deres afvikling kan slås op i [MC68000UM.pdf, 2005, section 8]. 87

15.3. MODULDESIGN Busmodulet kaldes [Nej] Subrutinen bus_w kaldes [Ja] a Er alle tre bytes i spørgsmålet sendt? Send byte til perifer enhed c b [Ja] Subrutinen bus_r kaldes d Er svarets 1. byte korrekt? [Nej] Består byten af en fejlkommando? [Nej] Subrutinen bus_r kaldes g Sæt fejlkode 1 h e f [Ja] [Ja] Subrutinen bus_r kaldes i Sæt fejlkoden fra den perifere enhed j Afslut modul med fejl Subrutinen bus_r kaldes Returner byten som data Afslut modul k l Figur 15.7: Flowdiagram for entry-funktionen bus i busmodulet. Bus_w kaldes Har ACIA485 sendt sine data? [Nej] m [Ja] Returner til subrutine kalder Figur 15.8: Flowdiagram for subrutinen bus w i busmodulet. Instruktion Antal clock cycles ADD.B #1, %D5 4 CMP.B #timeout, %D5 4 BGE < lbl > 10 BTST #rs485 r, #rs485 sr 10 BEQ < lbl > 10 I alt 38 Tabel 15.1: Instruktionerne til optælling af timeout på perifere enheders svartid samt antal clock cycles. 88

KAPITEL 15. SOFTWARE TIL MINIMUMSYSTEM Bus_r kaldes [Nej] Modtager ACIA485 data? [Nej] Er svartiden udløbet? [Ja] Sæt fejlkode 0 p n o [Ja] Modtag byte Er der paritetsfejl? [Ja] Sæt fejlkode 2 Afslut modul med fejl q s r [Nej] Returner til subrutine kalder Figur 15.9: Flowdiagram for subrutinen bus r i busmodulet. Timeout-grænsen, der skal tælles op til, kan nu udregnes til: timeout = 5347 clock cycles = 141 (15.3) 38 clock cycles/optælling Hvis et svar enten ikke modtages eller hvis det er forkert, så afsluttes modulet med en intern fejl (fejlkode 4-6). Der afsluttes derimod med en ekstern fejl fra den perifere enhed, hvis den første byte i svaret er en fejlkommando. Opstår der ingen fejl, afsluttes modulet og returnerer de modtagne data fra 2. byte i svaret. Ved en intern fejl køres subrutinen to gange forfra for at forespørge den perifere enhed om svar endnu engang. 15.3.2.4 Test Modulet er programmeret og kompileret uden fejl i programmet 68000 - Integrated Development Environment og herefter simuleret i programmet 68000 - Visual Simulator. I simuleringsprogrammet er en virtuel udgave af M68k opbygget, hvor det er muligt at følge programkodens eksekvering linje for linje samt kodens interaktion med registre og hukommelse [Fondse, 2004]. Da programkoden er afhængig af input fra ACIA485, simuleres denne manuelt i programmet. Simuleringen foregik vha. modulkald med flere forskellige argumenter. Disse argumenter blev valgt, så en test af normal modulkørsel samt modulkørsel med hver af de forskellige fejl kunne simuleres. Alle simuleringerne forløb tilfredsstillende og overholdte kravene til funktionaliteten. 15.3.3 Moduldesign for opret tabel modulet 15.3.3.1 Beskrivelse Dette modul indgår som det ses af figur 15.1 på side 81 under initialiseringsprocessen. Kildekoden til funktionerne beskrevet i dette afsnit kan ses i appendiks I.2 på side 159. Modulet har til opgave at oprette en tabel indeholdende data fra alle perifere enheder tilstede på bussen. Dette implementeres ved at oprette en tabel af fast størrelse. Denne løsning er valgt af bekvemmelighedsårsager, idet data fra bestemte enhedsadresser altid vil ligge i samme tabelcelle, hvorved det bliver nemt at hente og skrive data til disse tabelceller uden hensyntagen til antallet af tilkoblede enheder. Protokollen beskrevet i kapitel 13 på side 71 angiver, at hver adresse kan indeholde 16 forskellige ID, og kravspecifikationens afsnit 2.3 på side 11 fortæller, at der kan tilsluttes op til 128 enheder. Der hentes 1 databyte fra hvert ID på hver adresse, hvilket betyder at tabellens størrelse skal være 16 ID 128 adresser 1 byte = 2048 bytes. 89

15.3. MODULDESIGN 15.3.3.2 Grænseflader Grænsefladen til dette modul udgøres af initialiseringsprocessen beskrevet i afsnit 15.2.1 på side 83. Modulet medtager ingen parametre når det kaldes, og der returneres ingen værdier. Der oprettes til modulet tre globale variabler. Disse indeholder: SlaveCheck[128] Dette array indeholder information omkring de 128 adresser i systemet. Hver celle i dette array henviser til den respektive adresse på bussen. Der gemmes 0 og 1 i cellerne, hvor 0 angiver en adresse, der svarer på en forespørgsel, og 1 angiver en adresse, der ikke svarer på en forespørgsel. SlaveAlive[128] Dette array indeholder de adresser, der svarer på bussen. Første celle indeholder den laveste adresse, der svarer. SlaveNumber Denne variable indeholder antallet af adresser, der svarer på bussen. Dette tal angiver antallet af anvendte celler i array SlaveAlive. 15.3.3.3 Opbygning Som tidligere beskrevet skal tabellen, der oprettes, indeholde 2048 bytes, hvorved der med den konstruerede protokol skal foretages 2048 forespørgsler på bussen, idet der kun sendes/modtages 1 databyte pr. forespørgsel. Med maksimalt 1047 buscycles pr. sekund jvf. kapitel 13 ville det minimum tage 2 s at oprette denne tabel. Denne forholdsvis høje oprettelsestid for tabellen kan sænkes ved at checke, hvilke adresser der svarer, og herefter kun spørge alle ID fra disse adresser efter data. Alle adresser, der ikke svarer, fyldes til sidst med 0 i deres respektive tabelceller. Funktionen CheckAdr virker som hjælpefunktion i dette modul og har til opgave at checke, om en specifik adresse svarer på bussen. Busmodulet beskrevet i afsnit 15.3.2 på side 86 returnerer 1, hvis en forespørgsel på bussen ikke fik noget svar. Dette udnyttes i CheckAdr funktionen, som spørger ID 0 på den adresse, der medsendes som argument. Hvis der modtages et svar fra ID 0 på denne adresse, returnerer funktionen med 0 - er det modsatte tilfældet returneres 1. Hovedfunktionen TableInit opretter selve tabellen og fylder denne med data. Et flowdiagram for denne funktion kan ses på figur 15.10, og den overordnede virkemåde er: 1. Blokkene d og e udgør en løkke, der gennemløbes 128 gange svarende til hver adresse på bussen. 2. Funktionen CheckAdr udgøres af blokkene g, j, k og n. Denne spørger ID 0 på en given adresse og sætter variablen SlaveCheck til 0 eller 1, når adressen henholdsvis svarer eller ikke svarer. 3. Herefter evalueres det i blokkene m, o og l om slaven svarede - er dette tilfældet, gemmes adressen i SlaveAlive arrayet og variablen SlaveNumber tælles op. 4. I blok c oprettes tabellen med 2048 bytes. 5. I løkken med blokkene j, i, f, b og a fyldes tabellen med data. Adresser der svarer (SlaveCheck = 0) spørges efter data fra alle ID. Adresser der ikke svarer (SlaveCheck = 1) spørges ikke yderligere - der skrives 0 i alle tabelceller for disses ID. 15.3.3.4 Test Dette modul er testet vha. de designede prototyper fra appendiks K.1 på side 169. Funktionernes forventede reaktion på alle tænkelige argumenter er opskrevet, hvorefter de konstruerede funktioners faktiske reaktion er testet gennem prototyperne. Disse tests gav det forventede resultat i alle tilfælde. 90

KAPITEL 15. SOFTWARE TIL MINIMUMSYSTEM [Nej] x = 128? [Ja] Slut Start. Sæt x=0, SlaveNumber=0 a Inc. x b Opret tabel med 2048 bytes Sæt x= 0 c [Ja] x=128? d [Nej] Inc. x e Indhent data fra alle 16 ID på adresse x og skriv i tabel f [Ja] Funktionen CheckAdr Spørg ID 0 på adresse x g Skriv 0 for alle 16 ID for adresse x i tabel h [Nej] SlaveCheck[x] =0? i SlaveCheck[x] = 1 [Nej] Noget svar? Inc. SlaveNumber j l [Nej] k [Ja] SlaveCheck[x]= 0? m [Ja] SlaveCheck[x] = 0 n Gem x i SlaveAlive[Slave- Number] o Figur 15.10: Flowdiagram for funktionen til oprettelse af tabel. 15.3.4 Moduldesign for opdater tabel modulet 15.3.4.1 Beskrivelse Dette modul indgår som det ses af figur 15.1 på side 81 under løkkeprocessen. Modulet vil desuden kunne finde anvendelse i mange andre processer, der eventuelt indsættes i forbindelse med udvidelse af antallet af perifere enheder. Kildekoden til funktionerne beskrevet i dette afsnit kan ses i appendiks I.2 på side 159. Modulet har til opgave at opdatere tabellen med nye data fra de perifere enheder på bussen. Denne opgave implementeres gennem to forskellige funktioner. Funktionen UpdateTableAdr kan opdatere alle ID på en specifik adresse, hvorimod funktionen UpdateEntireTable kan opdatere hele tabellen. 15.3.4.2 Grænseflader Grænsefladen til dette modul udgøres af løkkeprocessen beskrevet i afsnit 15.2.2 på side 84. Funktionen UpdateTableAdr kræver et argument i form af en adresse adr, mens funktionen UpdateEntireTable ingen argumenter kræver. Ingen af funktionerne returnerer noget. Der læses i modulet fra de globale variabler SlaveNumber og SlaveAlive, der indeholder data som beskrevet i afsnit 15.3.3.2. 91

15.3. MODULDESIGN 15.3.4.3 Opbygning Funktionen UpdateTableAdr opdaterer alle 16 ID for den adresse, der medsendes som argument. Denne funktion kan kaldes udenfor modulet, men fungerer samtidigt som hjælpefunktion for funktionen UpdateEntireTable. Et flowdiagram for UpdateTableAdr kan ses på figur 15.11 og den overordnede virkemåde er: I løkken med blokkene a, b, c, d og g undersøges det om adressen, som funktionen får medsendt i argumentet, er indeholdt i arrayet SlaveAlive. Hvis dette er tilfældet vil et checkflag blive sat. I blok f evalueres det om checkflaget er sat. Et sat flag vil betyde, at den adresse der forsøges opdateres faktisk også svarer på bussen. Herefter vil data fra de 16 ID på denne adresse blive hentet fra den perifere enhed og gemt i tabellen, som det ses på blok e. Forsøges en adresse opdateret som ikke har svaret under initialiseringsprocessen vil en fejlbesked blive udskrevet. Dette er vist i blok h. Inc. x a Start x = 0 check = 0 x over SlaveNumber? [Nej] SlaveAlive[x] = adr? [Nej] b c d [Ja] [Ja] Indhent data fra alle 16 ID på adresse adr og skriv i tabel e [Nej] check = 0? check = 1 g f [Ja] Slut Fejl h Figur 15.11: Flowdiagram for funktionen til opdatering af tabel for specifik adresse. Funktionen UpdateEntireTable opdaterer alle ID i tabellen for alle de adresser der svarer. Et flowdiagram for denne funktion kan ses på figur 15.12 og den overordnede virkemåde er: 1. I løkken med blokkene a, b og c opdateres tabellen ved at benytte funktionen UpdateTableAdr med argumentet SlaveAlive, der netop indeholder alle de svarende adresser på bussen. Længden af dette array findes i den globale variabel SlaveNumber, som derfor bestemmer antallet af gange løkken gennemløbes. 15.3.4.4 Test Dette modul er testet vha. de designede prototyper fra appendiks K.1 på side 169. Funktionernes forventede reaktion på alle tænkelige argumenter er opskrevet, hvorefter de konstruerede funktioners faktiske reaktion er testet gennem prototyperne. Disse tests gav det forventede resultat i alle tilfælde. 92

KAPITEL 15. SOFTWARE TIL MINIMUMSYSTEM Inc. x a Start x = 0 x over SlaveNumber? [Nej] UpdateTableAdr (SlaveAlive[x]) c b [Ja] Slut Figur 15.12: Flowdiagram for funktionen til opdatering af hele tabellen. 15.3.5 Moduldesign for ændre tabel modulet 15.3.5.1 Beskrivelse Dette modul indgår som det ses af figur 15.1 på side 81 ikke under nogen proces. Modulet er et fællesmodul, der kan benyttes af andre moduler i programmet. Kildekoden til funktionerne beskrevet i dette afsnit kan ses i appendiks I.2 på side 159. Modulet har til opgave at skrive og læse fra den oprettede tabel. Dette implementeres gennem to forskellige funktioner - ReadTable læser fra tabellen, mens WriteTable skriver til denne. 15.3.5.2 Grænseflader Grænsefladen til dette modul udgøres af de processer, der behandler data fra de perifere enheder - se figur 15.1 på side 81. Funktionen ReadTable kræver to argumenter i form af et ID og en adresse, hvorefter der returneres data. Funktionen WriteTable kræver tre argumenter i form af et ID, en adresse samt data. 15.3.5.3 Opbygning Funktionen ReadTable bruger de to medsendte argumenter til at beregne hvor i tabellen, der skal læses en byte. Herefter returneres denne byte. Funktionen WriteTable bruger de to første medsendte argumenter til at beregne hvor i tabellen det sidste medsendte argument skal skrives. Der er ikke tegnet flowdiagrammer over disse funktioner, idet deres virkemåde er simpel. 15.3.5.4 Test Dette modul er testet vha. de designede prototyper fra appendiks K.1 på side 169. Funktionernes forventede reaktion på alle tænkelige argumenter er opskrevet, hvorefter de konstruerede funktioners faktiske reaktion er testet gennem prototyperne. Disse tests gav det forventede resultat i alle tilfælde. 15.3.6 Moduldesign for lygtekontrol modulet 15.3.6.1 Beskrivelse Dette modul indgår som det ses af figur 15.1 på side 81 under løkkeprocessen. Kildekoden til modulet kan ses i afsnit G.2 på side 149. Modulet har til opgave at varetage styringen af lygteenheden udfra tasternes position i lygtekontrolenheden. Dette implementeres ved at indhente tasternes position fra tabellen og herefter afsende denne aflæsning til lygteenheden. Til sidst overskrives lygteenhedens data i tabellen med den nye status af enheden - altså den værdi der i tabellen blev aflæst for lygtekontrolenheden. 93

15.3. MODULDESIGN 15.3.6.2 Grænseflader Grænsefladen til dette modul udgøres af løkkeprocessen beskrevet i afsnit 15.2.2 på side 84. Modulet medtager ingen argumenter når det kaldes, og der returneres ingen værdier. Modulet benytter sig af funktionerne fra tre øvrige moduler. Der læses og skrives fra tabellen vha. modulet til ændring af tabel, og der kommunikeres over bussen vha. busmodulet. Endvidere skrives der til displayet vha. displaymodulet. 15.3.6.3 Opbygning Funktionen navngives LightControlUnit og et flowdiagram over denne ses på figur 15.13. Den overordnede virkemåde er: I blok a indlæses den nuværende status af tasterne i lygtekontrolenheden fra tabellen. I blok b sendes den indlæste status af tasterne videre til lygteenheden, så udgangene i denne enhed opdateres til at stemme overens med tasterne. I blokkene c, d og e evalueres det, om der var fejl i transmissionen og der udskrives en fejlmeddelelse på displayet, hvis dette er tilfældet. Er der ingen fejl i transmissionen, overskrives lygteenhedens data i tabellen til at passe overens med de afsendte data fra blok b. Start Indlæs lygtekontrol-status fra tabel a Send denne værdi til lygteenhed b Fejl i transmission? [Ja] Fejl på display e c [Nej] Opdater lygteenhed-status i tabel e Slut Figur 15.13: Flowdiagram for funktionen til behandling af lygteenhed. 15.3.6.4 Test Dette modul er testet vha. de designede prototyper fra appendiks K.1 på side 169. Funktionens forventede reaktion på alle tænkelige argumenter er opskrevet, hvorefter den konstruerede funktions faktiske reaktion er testet gennem prototyperne. Disse tests gav det forventede resultat i alle tilfælde. 15.3.7 Moduldesign for olie modulet 15.3.7.1 Beskrivelse Dette modul indgår som det ses af figur 15.1 på side 81 under løkke processen. Kildekoden til modulet kan ses i afsnit G.4 på side 150. Modulet har til opgave at indhente den nuværende værdi af olietrykket fra tabellen og herefter evaluere denne og udskrive resultatet på displayet. 15.3.7.2 Grænseflader Grænsefladen til dette modul udgøres af løkkeprocessen beskrevet i afsnit 15.2.2 på side 84. Modulet medtager ingen argumenter når det kaldes, og der returneres ingen værdier. Der gøres brug af to moduler - ændre tabel modulet benyttes til at læse værdien af olietrykket fra tabellen og displaymodulet benyttes til at skrive resultatet af evalueringen ud på displayet. 94

KAPITEL 15. SOFTWARE TIL MINIMUMSYSTEM 15.3.7.3 Opbygning Funktionen navngives OilUnit og et flowdiagram over denne ses på figur 15.14. Den overordnede virkemåde er: I blok a indlæses værdien af olietrykket fra tabellen. I blokkene b, c, d, e og f evalueres det, hvilken værdi olietrykket har, og der udskrives en passende meddelelse på displayet. Start Indlæs olieenheds-status fra tabel a Lavt olietryk? [Nej] Højt olietryk? [Nej] Skriv Normal pressure på display d b c [Ja] [Ja] Skriv Low pressure på display e Skriv High pressure på display f Slut Figur 15.14: Flowdiagram for funktionen til behandling af olieenhed. 15.3.7.4 Test Dette modul er testet vha. de designede prototyper fra appendiks K.1 på side 169. Funktionens forventede reaktion på alle tænkelige argumenter er opskrevet, hvorefter den konstruerede funktions faktiske reaktion er testet gennem prototyperne. Disse tests gav det forventede resultat i alle tilfælde. 15.3.8 Moduldesign for display interface modulet Dette modul indgår som det ses af figur 15.1 på side 81 under displayprocessen. Kildekoden til funktionerne beskrevet i dette afsnit kan ses i appendiks H på side 153. Modulet har til formål at styre displayet. Herpå skal vises fejlbeskeder og brugervalgt information fra systemet jvf. UseCases beskrevet i appendiks 133. 15.3.8.1 Beskrivelse Funktionaliteten implementeres med udgangspunkt i funktionen void printdisplay(int line, char *toprint). Denne printer 20 karakterer, der peges på via pointeren toprint. Disse karakterer printes på den angivne linje line på displayet. Brugerinterfacet består af 2 taster. Disse 2 taster er tilknyttet interrupt 1 og interrupt 2 således, at brugeren kan vælge mellem information på tasterne. Funktionerne kaldt gennem disse interrupts er void dispup(void) og void dispdown(void). Modulet tilbyder desuden en funktion void dispstatusupdate(void), der gentegner displayet, med nyere information. Denne skal kaldes fra løkkeprocessen. Som værktøjer til de kaldende moduler tilbydes funktionerne char *strncpy(char *s, char *ct, int n) og void intinsert(unsigned char data, char *target). strncpy fungerer som en standard strncpy fra C-biblioteket. Denne kopierer n karakterer fra ct til s og returnerer adressen på s. Funktionen intinsert opdeler data i hundreder, tiere og enere, hvilket den indsætter som 3 karakterer (tal) i target. Med denne kan kaldende moduler indsætte eksempelvis måledata i slutningen af strenge, som derefter indsættes til visning på displayet med dispset, eller opdateres med dispstatusupdate. 95

15.3. MODULDESIGN Displaymodulet anvender følgende interne variable: char *dispbase[128] er et array af char-pointers. Heri kan kaldende moduler gemme pointere til den tekst disse vil have vist. int dispplacement er et heltal, der angiver hvor i dispbase brugeren er nået til. Denne løber ud fra 0, 1, 2, 3... (SlaveNumber-1). 15.3.8.2 Grænseflader Display-modulet anvender følgende eksterne variable: char *SlaveAlive[128] fra tabelmodulet. Med dette array sørges for, at det kun er aktive perifere enheder, der vises data fra. int SlaveNumber fra tabelmodulet. Denne anvendes af dispset til at sørge for, at kun aktive perifere enheder får vist data. 15.3.8.3 Opbygning Det styres gennem et array af pointers kaldt dispbase, hvad der vises på displayet. En principtegning over denne styring ses af figur 15.15. Brugeren kalder dispup og dispdown vha. tasterne på minimumsystemet. Herved flyttes pointeren dispplacement hhv. op og ned, og ny information fra en anden perifer enhed vises i displayets linje 1. Idet det ikke er garanteret, at alle 128 enheder er tilsluttet minimumsystemet, anvendes dispset() Vinduet er lukket Olietryk 5kpa dispup() Lyset er slukket dispplacement Farten er 5km/t dispdown() char * dispbase[128] Velkommen Figur 15.15: Principdiagram for displaystyring. et opslag i arrayet SlaveAlive[dispPlacement], hvorfra den næste aktive enhed gives. Dette anvendes så til et opslag i dispbase, hvorved adressen på den ønskede streng fremkommer. Dette vil blive nærmere specificeret senere i dette afsnit. De to taster til brugeren er vha. interrupts (IRQ 1 og IRQ 2) sammenkoblet med funktionerne dispup() og dispdown(), der in- og dekrementerer dispplacement og kalder funktionen printdisplay(1, dispbase[dispplacement]). Flowdiagrammer for dispup() og dispdown er vist på figur 15.16 på næste side og 15.17 på modstående side. Følgende beskrives de to funktioner samlet, idet disse er meget ens. I blok a gemmes de nuværende data fra processorens interne registre, idet funktionen kaldes som interrupt. Disse genskabes i blok f efter rutinens udførelse. I blok c tjekkes for grænseværdiproblemer. Heri indgår SlaveNumber og SlaveAlive[]. Med dette ønskes at undgå, at DispPlacement overstiger SlaveNumber eller falder under 0. Alt efter resultatet bevæges der videre til blok e. Blok e foretager et opslag i SlaveAlive hvorved kun aktive enheder kan få printet data. Den returnerede offset-værdi anvendes i blok f. 96

KAPITEL 15. SOFTWARE TIL MINIMUMSYSTEM Start Gem nuværende data a Inkrementer dispplacement b dispplacement >= SlaveNumber - 1? [Ja] c [Nej] Displacement = SlaveNumber -1 d offset = SlaveAlive[dispPla cement] e Vis I display 20 karakterer fra dispbas[offset] f Genskab gemt data g Slut Figur 15.16: Flowdiagram for funktionen dispup(). Start Gem nuværende data, idet der kaldes som interrupt a Dekrementer dispplacement c Er dispplacement <= 0? Ja b dispplacement = 0 Nej g offset=slavealive[ dispplacement] d Vis I display 20 karakterer fra dispbas[offset] e Genskab gemt data f Slut Figur 15.17: Flowdiagram for funktionen dispdown(). I blok f anvendes offset fra blok e til at få pointeren toprint fra dispbase[]. Denne pointer angiver hvilke 20 karakterer, der skal printes til display vha. printdisplay. I blok g genskabes den gemte data og der returneres fra exceptionen. 15.3.8.4 Test Idet modulet er skrevet i en kombination af assembler og C, er dette testet på minimumsystemet. Modulets funktionalitet er verificeret i at fungere tilfredsstillende. 15.4 Delkonklusion Der er gennem dette kapitel blevet udviklet software til masterenheden i systemet. Udviklingen foregik som en blokvis top-down nedbrydning efter SPU-modellen. Den valgte softwareløsning undersøger først, hvilke perifere enheder, der er tilstede på bussen, for derefter at indsamle al data fra disse i en tabel. De perifere 97

15.4. DELKONKLUSION enheder behandles herefter sekventielt, hvor tabellen opdateres ved begyndelsen af hver sekvens. Der er i kapitlet udviklet softwaremoduler til: Initialisering af hardware i masterenheden. Håndtering af bus efter protokol beskrevet i kapitel 13. Håndtering af tabel indeholdende data fra alle perifere enheder tilstede på bus. Håndtering af displayet, der benyttes som brugerinterface jvf. UseCases i appendiks B. Håndtering af data fra tabel vedrørende de udviklede perifere enheder beskrevet i kapitel 12. Der er i implementeringen af displayet benyttet interrupts til at håndtere tasterne, der anvendes i denne forbindelse. De udviklede softwaremoduler er testet med simuleringsværktøjer, prototyper samt ved praktiske tests af masterenheden. Alle disse tests er gennemført med tilfredsstillende resultat. 98

KAPITEL 16. SOFTWARE TIL PERIFERE ENHEDER Kapitel 16 Software til perifere enheder I dette kapitel designes softwaren til de tre perifere enheder. Der indledes med programdesign, hvor programmet for enhederne inddeles i processer, som derefter opdeles i moduler, der designes hver for sig. Det samlede program opdelt i processer og moduler fremgår af figur 16.2, og den skrevne kildekode til enhederne kan læses i appendiks J på side 163. Der er i al softwareudvikling anvendt C som programmeringssprog. Koden til alle tre perifere enheder er næsten identisk. Forskellene ligger primært i, at enhederne har forskellige adresser, og at der i lygteenheden skal sættes en værdi på en udgang, hvor der både i lygtekontrolenheden og olieenheden skal indhentes en værdi fra en indgang. Hertil anvender olieenheden som den eneste enhed en A/D converter (herefter benævnt ADC), som skal håndteres særskilt. Disse forskelle er samlet i moduler, som kan anvendes der, hvor der er behov for dem. Alle disse forskelle er også forklaret i dokumentationen til kildekoden i appendiks J. Under gennemgangen af hvert modul er der beskrevet en modultest. Her er der generelt anvendt en simpel testmetode, hvor én af de ledige udgange på controlleren anvendes som testudgang. Denne udgang kan sættes eller resettes i softwaren til det pågældende modul, og ved at måle på udgangen kan det konstateres, om bestemte trin i et modul fungerer eller ej. Rent praktisk er der til modultests anvendt et udviklingsværktøj designet til Atmels AVR RISC controllere. Værktøjtet hedder AVR STK-500 [STK-500.pdf, 2003] og udmærker sig ved, at der er oprettet en RS232-port med en MAX232-transceiver til controlleren. Vha. denne er det let at udføre tests sammen med en terminal på en PC. Controlleren kan under test med fordel kodes til at sende en karakter til PC en, hvis nogle bestemte betingelser er opfyldt, og om dette lykkes kan så betragtes som succeskriterium. 16.1 Programdesign 16.1.1 Valg af designmetode Designmetoden er valgt til en top-down fremgangsmåde. Top-down passer på beskrivelsen af denne software, idet formålet med softwaren er kendt og de eksterne grænseflader er veldefinerede. Derfor kan softwaren nemt opdeles i et antal processer for videre design. 16.1.2 Eksterne grænseflader For de perifere enheder findes to eksterne grænseflader. Den ene er RS485-bussen, den anden er enten digitalt input fra kontaktgreb, input fra analog transducer via ADC eller udgange til relæer. 16.1.3 Opdeling i processer Programmet til mikrocontrollerne kan overordnet deles op i to processer jvf. figur 16.1 - en initialisering ved opstart og derefter en løkkestruktur, hvori den samme kode afvikles for hver buscycle, indtil der slukkes for systemet. Flowdiagram for hele programmet kan ses i figur 16.4 på side 111. 99

16.2. PROCESDESIGN Start Initialisering Løkke a b Figur 16.1: Flowdiagram for software til lygtekontrolenhed. Proces Initialisering a Løkke b Modul Initialisering af controller a Initialisering af UART b Initialisering af Timer c Nulstil alle variabler Kopier datapakke fra UART Kontroller adresse-byte Delay UART f g h i Initialisering af I/O-porte d Initialisering af ADC e Kontroller paritet Hent værdier på I/O-port Sæt værdier på I/O-port Send data til master j k l m Figur 16.2: Proces- og moduloversigt for software til perifere enheder. 16.1.4 Grænseflader mellem processer Grænsefladen mellem de to processer ligger i, at løkkeprocessen anvender samtlige af de interne funktioner, der er initialiseret i initialiseringsprocessen. 16.2 Procesdesign 16.2.1 Proces a: Initialisering Formålet med initialiseringen er at opsætte interne funktioner i controlleren. Dette sker kun én gang, og herefter køres løkkeprocessen jvf. figur 16.1. 16.2.1.1 Eksterne grænseflader Initialiseringen har UART, timer, I/O-porte og ADC som grænseflader. 16.2.1.2 Opdeling i moduler Initialiseringen deles op i fem moduler, hvori initialisering af henholdsvis controller, UART, timer, I/O-porte og ADC finder sted. 16.2.1.3 Grænseflader for moduler Der er ingen grænseflade mellem de fem moduler, idet de er fuldstændigt uafhængige af hinanden. 16.2.2 Proces b: Løkke Løkkeprocessen kører som en uendelig løkke efter initialiseringsprocessen. Formålet er at modtage instruktioner fra masterenheden og derefter svare tilbage til masteren, såfremt de rette betingelser har været til 100

KAPITEL 16. SOFTWARE TIL PERIFERE ENHEDER stede. 16.2.2.1 Eksterne grænseflader Løkkeprocessen har UART, ADC og I/O-porte som grænseflader, idet processen både henter og sender data til og fra disse interne funktioner. 16.2.2.2 Opdeling i moduler Løkkeprocessen er opdelt i følgende 8 moduler, som vil blive gennemgået i det følgende: 1. Nulstil alle variabler. 2. Kopier datapakke fra UART. 3. Kontrollér adressebyte. 4. Delay UART. 5. Kontrollér paritet. 6. Hent værdier på I/O-port. 7. Sæt værdier på I/O-port. 8. Send data til master. 16.2.2.3 Grænseflader for moduler Grænsefladerne for modulerne udgøres af de globale variabler, der er deklareret i programmet, samt de registre, der refererer til I/O-porte, UART, ADC og timer internt i controlleren. I tabel 16.1 er alle anvendte registre i controlleren beskrevet. Registrene er benævnt med navn, men dette navn refererer blot til en placering i adresserummet for controlleren. Disse navne kontra adresser er defineret i header-filen til controlleren. For AT90S2313 hedder den io2313v.h og for AT90S8535 hedder den io8535v.h. Disse er vedlagt sammen med kildekoden på CD-ROM en under [bilag/kildekode/c-kode]. Register Refererer til Anvendes i modul i figur 16.2 PORTB Udgange på port B l PINB Indgange på port B k DDRB Dataretning på port B d PORTD Udgange på port D f, g, m DDRD Dataretning på port D d TCNT0 Timer / Counter 0 Register i TCCR0 Timer / Counter 0 Control Register c, i USR UART Status Register g, m UCR UART Control Register b UDR UART Data Register g, m UBRR UART Baud Rate Register b ADCSR ADC Status Register k ADMUX ADC Multiplexer Select Register e MCUCR MCU Control Register a GIMSK General Interrupt Mask Register a TIMSK Timer Interrupt Mask Register a Tabel 16.1: Oversigt over registre, der udgør grænseflader for moduler. I tabel 16.2 er tillige alle anvendte variabler beskrevet. 101

16.3. MODULDESIGN Variabel Anvendes til Anvendes i modul i fig. 16.2 RXC Receive Complete - bit 7 i USR g TXC Transmit Complete - bit 6 i USR m UDRE UART Data Register Empty - bit 5 i USR m ADC Returværdi fra ADC k ADSC ADC Start Conversion - bit 6 i ADCSR k adr Adressebyte fra datapakke f, g, h, j cmd id in Cmd/id-byte fra datapakke f, g, j, m data in Databyte fra datapakke f, g, j, l, m id Id-værdi fra cmd/id-byte f, g, j cmd in Cmd-værdi fra cmd/id-byte f, g, cmd id out Cmd/id-byte, som sendes retur f, j, m adr parity Paritet fra adressebyte f, g, j cmd parity Paritet fra cmd id-byte f, g, j data parity Paritet fra databyte f, g, j Tabel 16.2: Oversigt over variabler, der udgør grænseflader for moduler. 16.3 Moduldesign 16.3.1 Modul a: Initialisering af controller 16.3.1.1 Beskrivelse I dette modul initialiseres selve controlleren. Dette gøres for at fortælle controlleren, om funktioner som sleep mode, timer interrupt og interrupt generelt skal være aktiveret. 16.3.1.2 Grænseflader Modulet har registrene MCUCR, GIMSK og TIMSK som grænseflader, se tabel 16.1. 16.3.1.3 Opbygning Ved initialiseringen skrives der til registrene MCUCR, GIMSK og TIMSK. I MCUCR defineres, hvorvidt controlleren skal kunne gå i sleep mode for at spare energi, om den skal håndtere interrupts og om disse skal trigges på højt- eller lavtgående flanker. I GIMSK defineres, om controlleren skal kunne håndtere 1, 2 eller ingen eksterne interrupts. I TIMSK registeret defineres, hvorledes den interne timer skal kunne generere en interrupt. Dette kan ske ved timer match eller timer overflow. I dette setup anvendes sleep mode og interrupt ikke. 16.3.2 Modul b: Initialisering af UART 16.3.2.1 Beskrivelse I dette modul initialiseres UART en i controlleren. Dette gøres for at fortælle UART en ved hvilken hastighed data skal transmitteres samt modtages ved, og hvor mange bit data, der anvendes pr. frame ud over startog stopbit. UART en kan ikke selv beregne paritet - se i afsnit 16.3.13, hvordan det håndteres i softwaren. 16.3.2.2 Grænseflader Modulet har registrene UCR og UBRR som grænseflader, se tabel 16.1. 102

KAPITEL 16. SOFTWARE TIL PERIFERE ENHEDER 16.3.2.3 Opbygning Ved initialiseringen skrives der til to 8 bit registre i UART en. Det første er UCR. Heri sættes RX og TXenable til aktiv, så der både kan sendes og modtages med UART en. Dertil aktiveres det 9. bit, så det er muligt at sende og modtage en paritetsbit. Det andet register er UBRR. Heri defineres hastigheden på datatransmissionen vha. en deling af clock-frekvensen på 3.6864 MHz - se afsnit 12.2.3 på side 65. 16.3.2.4 Test UART en testes vha. et simpelt program, hvori funktionerne ReceiveByte() og TransmitByte() anvendes. Her sættes UART en op til at modtage en enkelt karakter over RS232-forbindelsen og returnere den straks efter over RS232-forbindelsen til en PC-terminal. Hvis den korrekte returkarakter kan aflæses på terminalen, fungerer UART en korrekt. 16.3.3 Modul c: Initialisering af timer 16.3.3.1 Beskrivelse I dette modul initialiseres timeren i controlleren. Dette gøres for først at starte timeren og derefter sætte den korrekte tællehastighed. 16.3.3.2 Grænseflader Modulet har registrene TCCR0 og TCNT0 som grænseflader, se tabel 16.1. Disse tilgås ved at kalde funktionen timer0 init(). 16.3.3.3 Opbygning Ved initialiseringen skrives der til registret TCCR0 ved at kalde funktionen uart0 init(). I dette register defineres i bit 0 til 2, om timeren er aktiveret, og hvor hurtigt dette skal gå ift. clock-frekvensen. I dette tilfælde er valgt en skalering på 64, som fås ved at sætte bit 0 og 1 til logisk høj og bit 2 lav. Argumentation for denne skalering læses på side 106 i afsnittet Delay UART. 16.3.3.4 Test Initialiseringen af timeren testes ved at læse indholdet i registret TCCR0. Hvis bitmønsteret er identisk med initialiseringen, så må timeren forventes at fungere med den valgte skalering. 16.3.4 Modul d: Initialisering af I/O porte 16.3.4.1 Beskrivelse I dette modul initialiseres I/O-porte i controlleren. Dette gøres for at fortælle controlleren, hvilke porte, der skal anvendes, og om portene skal fungere som input eller udgang samt, om der ønskes anvendt interne pullup-modstande. Disse modstande har kun indflydelse på ben sat op som indgange. 16.3.4.2 Grænseflader Modulet har registrene PORTB, DDRB, PORTD og DDRD som grænseflader, se tabel 16.1. 16.3.4.3 Opbygning Ved initialiseringen kaldes funktionen port init(). Hermed skrives der til 8bit registrene PORTB, DDRB, PORTD og DDRD. I DDRB defineres, hvorvidt benene på porten hver især skal være indgang eller udgang. Logisk høj sætter en port til udgang og omvendt med et 0. I PORTB aktiverer logisk høj en pullup-modstand og med et 0 vil porten være udefineret. 103

16.3. MODULDESIGN For lygtekontrolenheden og olieenhedens vedkommende skal der skrives 0 i alle bit i PORTB, DDRB og PORTD - dvs., at det ikke anvendes pullup og alle porte på PORTB er inputs. På DDRD skal der skrives 01111100 b - dvs., at bit 2 til 6 er udgang. Bit 7 er 0, idet denne ikke er tilgængelig på denne controller, bit 0 og 1 er sat til 0, idet disse er under UART ens kontrol og anvendes til RXD og TXD. For lygteenheden vedkommende er den eneste forskel, at DDRB sættes til 1 i alle bit, de disse skal være udgange. 16.3.4.4 Test I/O-portene testes vha. en simpel kode, hvor en given udgang sættes til at være lig en given indgang på controlleren. Hvis status på en indgang ændres, så skal den tilhørende udgang ændre status tilsvarende. Således testes alle I/O-porte. 16.3.5 Modul e: Initialisering af ADC 16.3.5.1 Beskrivelse Dette modul anvendes kun i olieenheden. I modulet initialiseres ADC en i controlleren for først at aktivere ADC en og dernæst at angive, hvilket regelsæt den skal fungere under. 16.3.5.2 Grænseflader Modulet har registrene ADCSR og ADMUX som grænseflader, se tabel 16.1. 16.3.5.3 Opbygning Ved initialiseringen skrives der til 8bit registret ADCSR og 3bit registret ADMUX. I ADCSR sker følgende: Med bit 7 sat aktiveres ADC en. Herefter kan den kaldes til enhver tid. Med bit 6 sat (ADC Start Conversion) sættes ADC en til at iværksætte konvertering. Den sættes til 0 ved initialisering. Med bit 5 sat foretager ADC en Single Conversion - dvs., at den kun laver én konvertering pr. kald - modsat freerunning, hvor den kører uafbrudt. Bit 3 og 4 anvendes til aktivering af interrupt sammen med ADC en. Dette anvendes ikke i dette tilfælde, så de er sat til 0. I bit 0 til 2 vælges skalering for ADC en. skalering fortæller, hvor hurtigt ADC en skal arbejde ift. clock-frekvensen. Den hurtigst mulige indstilling er faktor 2, hvorved ADC en arbejder med den halve clock, og denne vælges ved sætte bit 0. ADC en i denne controller kan gennem en multiplexer håndtere 8 analoge indgang ved at læse én indgang ad gangen. I ADMUX registret kan der på bit 0 til 2 sættes den binære værdi på den indgang, der skal læses fra. I dette tilfælde vælges kun indgang 0, idet der kun er behov for én indgang. 16.3.5.4 Test Initialisering af ADC en testes vha. testsoftwaren beskrevet i appendiks K.2. Softwaren initialiserer ADC en og kører en while-løkke, hvori ADC ens returværdiregister læses og kopieres ud på 8 udgange på controlleren som et 8bit bitmønster. Hvis ADC en fungerer, vil udgangene ændres, hvis den analoge værdi på ADC ens indgang ændres. 16.3.6 Modul f: Nulstil alle variabler 16.3.6.1 Beskrivelse I dette modul nulstilles alle variabler samt alle udgange på PORTD. Dette gøres hver gang løkkeprocessen starter forfra, idet løkken er uafhængig af tidligere værdier i variablerne. 104

KAPITEL 16. SOFTWARE TIL PERIFERE ENHEDER 16.3.7 Modul g: Kopiér datapakke fra UART 16.3.7.1 Beskrivelse I dette modul kopieres de tre bytes samt tilhørende paritetsbit fra datapakken, som i hver buscycle modtages fra masteren, via UART en. 16.3.7.2 Grænseflader Modulet har grænseflader jvf. tabel 16.3. Variabel adr cmd id in data in id cmd in adr parity cmd parity data parity Anvendes til Adressebyte fra datapakke Cmd/ID-byte fra datapakke Databyte fra datapakke ID-værdi fra cmd/id-byte Cmd-værdi fra cmd/id-byte Paritet fra adressebyte Paritet fra cmd/id-byte Paritet fra databyte Tabel 16.3: Variabler der udgør grænseflader for modul g. 16.3.7.3 Opbygning Datapakken med de tre bytes indeholdende adresse, cmd/id og data kopieres én ad gangen. Dette sker ved at kalde funktionen ReceiveByte() 3 gange. Denne starter med at læse RXC-bit i USR. Så længe denne er logisk lav, venter programmet her. Når denne bit går logisk høj betyder det, at UART en har modtaget en ny byte, som er kopieret over i UDR. Indholdet kopieres derefter over i variablerne adr, cmd id in eller data in. Dette sker uanset, hvilken perifer enhed data er tiltænkt, idet kontrol af adressen først sker senere. Grunden til denne metode er, at controlleren ikke kan nå at fortage kontrollen mellem modtagelse af hver byte. Dertil har det ingen praktisk betydning, om hele datapakken kopieres ind hver gang. I dette modul kopieres også de tre paritetsbit, som bliver sendt i datapakken. Det gøres ved at kalde funktionen get paritybit() efter hver byte. Funktionen kopierer indholdet af bit 1 i UCR, som indeholder det 9. bit fra hver frame. Returværdien for funktionskaldene gemmes i variablerne adr parity, cmd parity og data parity. 16.3.7.4 Test Modulet testes på samme måde som initialiseringen af UART en. I dette modul skal controlleren modtage 3 bytes fra UART en istedet for blot en, før den sender dem retur igen. Testen på, om de respektive paritetsbit er korrekte, udføres ved at kopiere værdien af pariteten ud på en ledig udgang på controlleren. Hvis der er sendt en karakter med et ulige antal satte bit, skal paritetsbit være højt og omvendt. Således kan alle tre paritetsbit testes. 16.3.8 Modul h: Kontroller adressebyte 16.3.8.1 Beskrivelse I dette modul kontrolleres det, om den modtagne adressebyte indeholder den korrekte adresse. 16.3.8.2 Grænseflader Modulet har konstanten DEVICE ADR og variablen adr som grænseflader. 105

16.3. MODULDESIGN 16.3.8.3 Opbygning Hvis bitmønsteret i variablen adr er lig med værdien defineret i DEVICE ADR, bliver informationerne i cmd og id kopieret ud af cmd id in-byten. Dette gøres ved at rotere cmd id in fire gange til højre, idet informationen står på de fire øverste bit. Herefter gemmes resultatet i variablen cmd in. id kopieres ved logisk AND cmd id in med 15 (00001111 b ) og gemme resultatet i variablen id. 16.3.8.4 Test Modulet testes ved at sende en datapakke til controlleren. Herefter sammenlignes variablen adr (indeholdende en kopi af adressebyten) med konstanten DEVICE ADR. Hvis disse er identiske, sættes bit 5 på PORTD. 16.3.9 Modul i: Delay UART 16.3.9.1 Beskrivelse I dette modul genereres en forsinkelse, når en datapakke har været tiltænkt en anden perifer enhed. Uden denne pause vil UART en lytte og kopiere data, når én af de øvrige perifere enheder sender data retur til masterenheden. Dette vil medføre fejl i den perifere enhed, idet en datapakke sendt til masteren kun indeholder to frames, samt at disse data ikke er tiltænkt den perifere enhed. 16.3.9.2 Grænseflader Modulet har registrene TCNT0, TCCR0 og PORTB samt konstanten DELAY COUNTER som grænseflader, se tabel 16.1. 16.3.9.3 Opbygning I modulet kaldes funktionen delay uart(). Dette sker kun, når indholdet i adr er forskellig fra DEVICE ADR. Funktionen fungerer ved at først at sætte tælleregisteret TCNT0 til 0. Tælleren kører hele tiden - også selvom delay uart() ikke kaldes. Herefter sættes bit 5 på PORTB. Denne anvendes til at måle længden af delay under test af funktionen. Varigheden af forsinkelsen styres i en while-løkke, som gentager sig selv, indtil TCNT0 svarer til DELAY COUNTER. Længden af forsinkelsen er i appendiks O beregnet til at være t delay = 700 µs. Den anvendte timer er en 8bit timer, dvs., at den tæller fra 0 til 255 og starter forfra. For at ét gennemløb af delay uart() ikke overskrider grænsen på 255, anvendes skalering til at sænke tællefrekvensen. Denne skalering skal vælges så lav som muligt for at opnå størst mulig nøjagtighed, når timeren kører. Skalering er valgt til 64, og dette giver en tællefrekvens f 64 på f 64 = 3.6864 MHz 64 = 57.6 khz (16.1) Ved denne indstilling svarer en periode på t delay = 700 µs til antal clock cycles N cycles, som er givet ved følgende N cycles = f 64 t delay = 57.6 khz 700 µs = 40.3 40 (16.2) Således sættes DELAY COUNTER til 40 = 101000 b. De øvrige muligheder for skalering er 1, 8, 256 og 1024. Hvis den sættes til 8, bliver N cycles vha. ovenstående udregning N cycles = 320, hvilket er for højt, idet det overskrider 255. Når kontrollen returneres fra while-løkken, sættes bit 5 på PORTD igen til 0. Det sidste, der sker i delay uart() er, at indholdet i UDR læses ind i en dummyvariabel for at resette RXC. Dette er nødvendigt, idet UDR muligvis har modtaget en byte fra en anden perifer enhed, mens delay uart()-funktionen har kørt. Uden denne reset vil der allerede ligge en byte klar i UDR, når ReceiveData() kaldes første gang, men denne byte vil være en kopi af den sidste byte afsendt af én af de øvrige perifere enheder. Herved vil en fejl opstå. 106

KAPITEL 16. SOFTWARE TIL PERIFERE ENHEDER 16.3.9.4 Test Funktionen testes ved at sende en forkert adresse til den perifere enhed. Herved kaldes delay uart()-funktionen, og det kan måles, hvor lang tid bit 5 på PORTD er høj. 16.3.10 Modul j: Kontroller paritet 16.3.10.1 Beskrivelse I dette modul kontrolleres, om pariteten er lige for alle tre bytes i den modtagne datapakke. Hvis ikke dette er tilfældet, genereres en datapakke med en fejlmeddelelse, som returneres til masteren. 16.3.10.2 Grænseflader Modulet har grænseflader jvf. tabel 16.4. Variabel adr cmd id in data in id cmd id out adr parity cmd parity data parity Anvendes til Adressebyte fra datapakke Cmd/ID-byte fra datapakke Databyte fra datapakke ID-værdi fra cmd/id-byte Cmd/ID-byte, som sendes retur Paritet fra adressebyte Paritet fra cmd/id-byte Paritet fra databyte Tabel 16.4: Variabler der udgør grænseflader for modul j. 16.3.10.3 Opbygning Kontrollen sker ved at kalde funktionen check parity(). Denne tager en byte og den tilhørende paritet som argumenter og returnerer et 1-tal, hvis pariteten er forkert. check parity() kaldes tre gange og de tre returværdier OR es sammen. Hvis resultatet er et 1-tal, så er der paritetsfejl i mindst én af de tre frames. Der skelnes ikke mellem, hvilken frame fejlen ligger i, blot at der er en fejl. Hvis der er fejl i pariteten, så kopieres værdien ERROR CMD ind på de fire øverste bit i cmd id out ved at rotere fire gange til venstre. id kopieres også ind i cmd id out ved at OR e id ind på de fire nederste bit. cmd id out er nu klar til at blive sendt til masteren sammen med en databyte indeholdende fejlbeskeden PARITY WRONG. 16.3.10.4 Test Modulet testes ved at sætte bit 6 på PORTD til 1, såfremt der registreres én eller flere paritetsfejl. Herefter sendes data til controlleren fra en PC-terminal, ved at sætte PC en op til at bruge ulige paritet, kan der fremtvinges fremtvinge paritetsfejl. 16.3.11 Modul k: Hent værdi på I/O-port 16.3.11.1 Beskrivelse I dette modul kopieres en værdi fra en I/O-port på controlleren. Denne anvendes enten til at indhente logisk information om kontakterne i lygtekontrolenheden eller en analog værdi via ADC en i olieenheden. 16.3.11.2 Grænseflader Modulet har registret PINB og variablerne ADC og ADSC som grænseflader. 107

16.3. MODULDESIGN 16.3.11.3 Opbygning Modulet afvikles kun, hvis der i variablen cmd in er gemt en værdi svarende til GET VALUE CMD. Herefter er der forskel på, om det er olieenheden og lygtekontrolenheden, der afvikler modulet. For lygtekontrolenheden vedkommende kopieres værdien på indgangene PINB over i variablen data out. Det er på PINB, at stillingen på kontakterne til lyset afspejles. For olieenhedens tilfælde kaldes funktionen get adc value(). I denne funktion sker der følgende: 1. Først sættes ADSC (ADC Start Conversion) i ADSCR til 1 for at starte konverteringen. Den er normalt inaktiv. Konverteringen kører herefter én gang. 2. Herefter køres en while-løkke, hvor ADSC testes løbende. ADSC går automatisk lav straks, når konverteringen er gennemført. 3. Værdien af konverteringen er herefter tilgængelig i registret ADC som 10bit værdi (1024 trins opløsning). Denne kopieres over i int-variablen ad. 4. Idet der kun kan sendes 8bit data i én frame til masteren, deles ad med 4 ned til 256 trins opløsning og kopieres over i unsigned char-variablen pressure. 5. Funktionen returnerer pressure. Det er herefter returværdien fra get adc value(), der sendes tilbage til masteren. Dette er således en 8bit værdi konverteret fra 10bit registeret ADC. Det betyder også, at det kun er hver 4. trin i ADC en, der kopieres til pressure. 16.3.11.4 Test For lygtekontrolenheden vedkommende testes modulet vha. en kode, hvor bit 6 på PORTD sættes til at være lig én af indgangene på PORTB ad gangen. Hvis status på indgangene ændres, så skal status på udgangene ændres tilsvarende. Således testes portens 8 indgange. For olieenhedens tilfælde testes ADC en testes vha. testprogrammet beskrevet i appendiks K.2. Softwaren initialiserer ADC en og kører en while-løkke, hvori ADC ens returværdiregister læses og kopieres ud på PORTB på controlleren som et 8bit bitmønster. Hvis ADC en fungerer, vil udgangene ændres, hvis den analoge værdi på ADC ens indgang ændres. 16.3.12 Modul l: Sæt værdi på I/O-port 16.3.12.1 Beskrivelse I dette modul sættes en værdi på en I/O-port på controlleren. Denne anvendes til at sætte de udgange på lygteenheden, som trækker relæerne til lygterne. Disse sættes jvf. værdien indhentet fra kontakterne på lygtekontrolenheden. 16.3.12.2 Grænseflader Modulet har registret PORTB og variablen data in som grænseflader. 16.3.12.3 Opbygning Modulet afvikles kun, hvis der i variablen cmd in er gemt en værdi svarende til SET VALUE CMD. I modulet bliver indholdet af data in kopieret over i registret PORTB, som afspejles på udgangene på PORTB på controlleren. 16.3.12.4 Test Modulet testes ved at sende tre karakterer fra en PC-terminal til controlleren, som herefter skal kopiere den 3. karakter til variablen data in. Indholdet af denne variabel kopieres herefter til PORTB på controlleren. Hvis bitmønsteret på porten er lig den 3. karakter, fungerer modulet. 108

KAPITEL 16. SOFTWARE TIL PERIFERE ENHEDER 16.3.13 Modul m: Send data til master 16.3.13.1 Beskrivelse Dette modul anvendes til at sende en datapakke retur til masterenheden efter, at den perifere enhed har udført en given opgave eller, hvis der er registreret en fejl i datapakken. 16.3.13.2 Grænseflader Modulet har grænseflader jvf. tabel 16.5. Variabel PORTD USR UDR UCR PARITY WRONG CMD WRONG cmd id in data in cmd id out Anvendes til Udgange på port D UART Status Register UART Data Register UART Control Register Konstant med fejlkode Konstant med fejlkode Cmd/id-byte fra datapakke Databyte fra datapakke Cmd/id-byte, som sendes retur Tabel 16.5: Grænseflader for modul m. 16.3.13.3 Opbygning I modulet kaldes funktionen send data(). Denne tager to bytes som argumenter og returnerer ingen værdi. Et flowdiagram for send data() kan ses i figur 16.3. Hver blok i figuren beskrives herunder. Start Generer paritet til byte 1 Sæt MAX487 til at sende Send byte 1 a b c Generer paritet til byte 2 Send byte 2 Sæt MAX487 til at modtage d e f Slut Figur 16.3: Flowdiagram for funktionen send data(). I blok a og d genereres paritet til en byte ved at kalde funktionen make parity(). Denne tager en byte som argument og sætter et 1 eller 0 i UCR bit 0, så pariteten bliver lige. UCR bit 0 anvendes til udgående paritet. I blok b sættes MAX487 eren til at sende ved at kalde funktionen enable MAX487(). Denne tager ikke noget argument, men sætter bit 2 på PORTD. Denne udgang er koblet til DE (Drive Enable) på MAX487-kredsen. I blok c og e sendes en byte ved at kalde funktionen TransmitByte(). Denne tager en byte som argument og kopierer byten til UDR, når UDRE (UART Data Register Empty) er logisk høj. I blok f sættes MAX487 eren til at modtage igen ved at kalde funktionen disable MAX487(). Denne tager ikke noget argument, men sætter bit 2 på PORTD til 0 straks, når TXC går høj. Herefter skal TXC manuelt sættes til 0 igen. Dette gøres ved at skrive et 1 til TXC. 109

16.4. DELKONKLUSION 16.3.13.4 Test Dette modul testes sammen med en PC-terminal. Testen udføres ved at kalde funktionen send data() med to karakterer som argumenter. Funktionen skal herved sende de to bytes sammen med paritet til terminalen. Den anvendte Windows Hyper Terminal skelner ikke mellem korrekt eller forkert paritet. Kontrollen af pariteten gennemføres ved at læse bit 0 i registret UCR umiddelbart før afsendelse og kopiere de to paritetsbit ud på udgangene bit 5 og 6 på PORTB. Ved at kende bitmønsteret i de to afsendte karakterer kan det kontrolleres på udgangene om pariteten er korrekt. 16.4 Delkonklusion I dette kapitel er softwaren til de perifere enheder designet. For at gavne overblikket er softwaren designet, så den næsten er ens for alle tre perifere enheder, idet hardwaren også næsten er identisk. De enkelte små forskelle er samlet i moduler, som kan anvendes der, hvor der er behov for dem. Dette gælder håndtering af en analog værdi fra en ADC, kopiering af en logisk værdi ud på en udgang eller kopiering af en logisk indgang til en variabel. På den måde er det efterfølgende let at vedligeholde softwaren til alle tre perifere enheder, hvis behovet må opstå. De anvendte og beskrevne tests har vist de forventede resultater, så software til de perifere enheder kan konkluderes at fungere korrekt. 110

KAPITEL 16. SOFTWARE TIL PERIFERE ENHEDER Start Initialisering af porte, ADC, UART og timer a Kopier datapakke fra UART b Vent på næste datapakke d [Ja] Kan adressen genkendes? [Nej] c Adskil cmd og id fra byte 2 e Er der paritetsfejl? f [Nej] [Ja] Generer fejlbesked om paritetsfejl g [Ja] Er det en korrekt kommando? [Nej] h Hent eller sæt værdi på I/O-port i Nulstil alle variabler l Send data til master k Generer fejlbesked om forkert cmd j Figur 16.4: Flowdiagram for software til perifere enheder. 111

Del V: Afrunding Denne afslutning af rapporten indeholder først et accepttestkapitel, hvor den udførte accepttest sammenlignes med den opstillede kravspecifikation. Herefter følger konklusionen, hvor der samles op på resultaterne fra de tidligere dele. I næste kapitel følger en perspektivering, hvor fremtidsperspektiverne for systemet diskuteres. Sidste kapitel indeholder litteraturlisten. Del V: Afrunding 113 17 Accepttest 115 17.1 Resultater............................................... 115 17.2 Evaluering............................................... 115 18 Konklusion 117 19 Perspektivering 119 Litteraturliste 121

KAPITEL 17. ACCEPTTEST Kapitel 17 Accepttest Det fremstillede bilbussystem er blevet evalueret gennem en accepttest. Resultaterne fra denne test vil blive opsummeret i dette kapitel og sammenholdt med kravspecifikationen fra kapitel 2. 17.1 Resultater Resultaterne fra accepttesten er placeret i tabel 17.1 og i tabel 17.2 på næste side. Udsagn Krav Resultat Afsnit Eksekverende programkode kan udskiftes vha. RS232 Ja Ja 2.2.4 TS2-MON anvendes Ja Ja 2.3.2 Opbygges med M68k processor Ja Ja 2.3.2 Opbygges med 2 x 128Kbit ROM Ja Ja 2.3.2 Opbygges med 2 x 512Kbit RAM Ja Ja 2.3.2 Indeholder LCD-display, der viser data fra bilbussystemet Ja Ja 2.3.2 Kobles til PC via RS232 Ja Ja 2.3.2 Kommunikerer på bus med selvvalgt protokol Ja Ja 2.3.2 Lygteenhed kan tænde og slukke fire lygter Ja Ja 2.3.3 Lygtekontrolenhed kan styre 4 lygter i lygteenheden Ja Ja 2.3.4 Olieenhed laver A/D-konvertering Ja Ja 2.3.5 Brugeren kan vælge mellem vist information på LCD-displayet Ja Ja 2.4.1 Den serielle bus opbygges over RS485 standarden Ja Ja 2.4.2 Instruktion fra brugeren skal være påbegyndt inden 0.5 s Ja Ja 2.5 Tabel 17.1: Resultater fra accepttesten. 17.2 Evaluering Kravene om minimumsystemets indhold overholdes i implementationen, og der kan kommunikeres med en PC over RS232 interfacet vha. TS2-MON. Lygteenheden og lygtekontrolenheden fungerer i samspil - de fire lygter i lygteenheden styres korrekt fra lygtekontrolenheden. Olieenheden foretager en A/D-konvertering, og resultatet vises i minimumsystemets display. Brugeren kan vælge, om der skal vises informationer fra lygtekontrolenheden eller olieenheden. Tests af timingen viser at kommandoer, afsendt fra lygtekontrolenheden til lygteenheden, i gennemsnit påbegyndes 73.8 ms efter afsendelsen fra lygtekontrolenheden. Dette kunne forskydes af interrupts. Et enkelt interrupt er vha. overslagsberegninger i appendiks H.4 bestemt til at tage 1.13 ms, hvorved kravet om 0.5 s stadig kan overholdes ved afvikling af et interrupt under en kommunikation 115

17.2. EVALUERING Point: 1 2 3 4 5 Brugergrænsefladen virker ved første indtryk enkel og let at betjene 1 2 1 4 Alle fire lygtekontakter fungerer som forventet 5 3 Olietrykket vises på en fornuftig måde 5 2 1 Systemet er meget resistent overfor fremprovokerede fejl 4 4 LCD-displayet anvendes informativt 1 6 1 Navigering på displayet er nem og logisk 1 3 4 Brugergrænsefladen som helhed er enkel og let at betjene 1 5 2 Tabel 17.2: Resultater fra brugerinterface test. Tabellen angiver hyppigheden af hvert pointtal. Ved en besvarelser på 5 er respondenterne meget enige i udsagnet. Ved en besvarelser på 1 er respondenterne meget uenige i udsagnet. mellem to perifere enheder. Resultaterne fra brugerinterfacetesten, vist i tabel 17.2, viser i overvejende grad, at brugerinterfacet er anvendeligt. Kontaktgreb til styring af lygteenhed stammer fra en bil, hvorfor de umiddelbart forekommer bekendte for almindelige brugere. Betjeningen af lyset er ligefrem og fungerer som forventet, med undtagelse af blinklyset. Imidlertid er blink ikke implementeret og blinklyset lyser blot, hvorfor der er taget højde for det i brugerinterface undersøgelsen. Olietryk vises normalt blot med en rød lampe i en alm. bil. Derfor har bilbus systemet en fordel, idet en mere sigende tekst vises på displayet. Navnlig herfor ses god vurdering af olietryksvisningen. Brugerne forsøgte at provokere systemet ved at betjene mange kontakter på samme tid og hurtigt. Det lykkedes ikke at gøre systemet ustabilt ved denne påvirkning. Potentialet i displayet bliver ikke udnyttet optimalt, da kun den øverste tekstlinie anvendes ud af fire. Af samme grund opnås ikke den bedste vurdering heraf. Navigering på displayet er logisk og får en udmærket vurdering. Dette skyldes dels, at der kun er to knapper til betjening, og dels at kun to menupunkter kan vælges i prototypen. 116

KAPITEL 18. KONKLUSION Kapitel 18 Konklusion Denne P4 rapport er skrevet ud fra studieordningens tema Mikrodatamatsystemer. Projektforslagets opgave var at udvikle et bilbussystem - et serielt bussystem til erstatning af det eksisterende parallelle ledningsnet i en personbil. I overensstemmelse med SPU-modellen blev der udarbejdet en kravspecifikation, som fastlagde de specifikke krav til prototypesystemet, blandt andet gennem benyttelse af UML metodens UseCase beskrivelse. Der blev ligeledes efter SPU-modellen opstillet en accepttestspecifikation. Systemet blev udviklet som et singlemaster system, og masterenheden blev opbygget omkring Motorola 68000 processoren, hvor tilhørende hardware i form af RAM, ROM, display, UARTs og interrupthandler blev beskrevet og designet. Til debugging af masterenheden blev TS2-MON programmet anvendt. En protokol blev designet over RS485 standarden, med mulighed for og op til 128 tilsluttede slaveenheder - hver med op til 16 tilsluttede I/O enheder. I den udviklede prototype af systemet blev der konstrueret tre af disse slaveenheder, hvis funktionalitet var olietryksmåling, lygteenhed samt en lygtekontrolenhed indeholdende taster til aktivering af lygteenheden. En verificering af slaveenhedernes funktionalitet er udført ved hjælp af softwaretests, og disse tests gav alle forventelige og tilfredsstillende resultater. Softwareudviklingen blev også udført efter SPU-modellen, hvor software til master- og slaveenheder blev opbrudt i to separate dele. Til programmeringen af masterenheden blev der benyttet C- og assemblerprogrammering, mens programmeringen af slaveenhederne foregik udelukkende i C. Det udviklede software blev dels testet med simuleringsværktøjer designet specifikt til Motorola 68000 processoren, dels med prototyper og dels ved hjælp af tests på det samlede hardwaresystem. Alle disse tests gav forventelige og tilfredsstillende resultater. Accepttesten udført efter acceptspecifikationen viste, at den overordnede funktionalitet af systemet var som kravspecifikationen foreskrev det; masterenheden i systemet var i stand til at indsamle data fra de tilsluttede perifere enheder, behandle disse data, og udsende det behandlede resultat på displayet. Det var desuden muligt for brugeren at skifte mellem de behandlede resultaters visning på displayet som angivet i UseCase beskrivelsen. Der er udført en brugerundersøgelse af begrænset omfang, og resultatet af denne viser, at de adspurgte brugere generelt er tilfredse med det udviklede brugerinterface - det være sig både i informationsomfang, informationstilgængelighed og informationsvisning. Herved er det vist, at det er muligt at konstruere et bussystem, der kan erstatte det parallelle ledningsnet i en personbil, hvorved problemformuleringen er opfyldt. 117

KAPITEL 19. PERSPEKTIVERING Kapitel 19 Perspektivering Der vil i dette kapitel være en kort omtale af de emner, som ville kunne forbedre den opbyggede prototype af bilbussystemet, hvis udviklingen fortsatte over en længere periode. Dette skal ikke læses således, at de opnåede resultater ikke er brugbare, men blot at der kan foretages forbedringer. De opnåede resultater kan læses af konklusionen i kapitel 18 på side 117. Der er i det nuværende system ikke taget højde for tidskritiske funktioner. Tilsluttes f.eks. en perifer enhed til styring af bremser, så vil denne blive behandlet med samme prioritet som alle andre enheder. Med det maksimale antal perifere enheder tilsluttet, kan den længste tid, der cirka går fra en forespørgsel gives til den modtages, udregnes. Dette gøres vha. (13.1) på side 72 og bushastigheden på 115.2 kbps jvf. afsnit 8.2 på side 40: t = tid mellem to forespørgsler + tid for modtagelse af en forespørgsel (19.1) = 128 adresser 16 ID er/adresse 955 µs/id + 3 bytes 11 bit 115200 bps = 1.96 s (19.2) Hvis der igen er tale om eksemplet med bremserne, så kan denne tid sammenlignes med menneskets gennemsnitlige reaktionstid på 1.5 s [reaktionstid.pdf, 2005]. I det tilfælde mere end fordobler systemet tiden, der går før der bremses, hvilket er en alvorlig sikkerhedsrisiko. En mulig måde at nedbringe tiden på, er ved kun at spørge de ID er, som er tilstede på en adresse, hvilket kan gøres efter samme princip som med adresserne. Derved er det kun i værste fald, at tiden er gældende. En smartere løsning ville være at prioritere de enkelte enheder, således at kritiske processer som bremser serviceres oftere end ikke kritiske processer. Dette kræver naturligvis en velovervejet prioriteringsliste. Der er til det nuværende system benyttet en M68k processor med dertilhørende ekstern hardware. Processoren er udviklet i 1979 og er derfor efterhånden blevet erstattet fuldstændig med mikrocontrollere, der har den fordel, at bl.a. hukommelse er integreret. Sådanne controllere er desuden ofte hurtigere og har flere funktioner. Der kunne derfor med fordel skiftes processortype i masterenheden. Dette skal selvfølgelig vurderes i forhold til, hvor regnekraften i fremtiden vælges lagt. En vurdering af denne problemstilling kunne f.eks. ske med udgangspunkt i blinklysfunktionen. Vælges hvert blink kommanderet af masteren, er det et krav til masteren, at denne er hurtig nok til at kunne håndtere et interrupt for hvert blink uden, at dette går væsentligt ud over serviceringen af de andre perifere enheder. Vælges blinkfunktionen udført i hver lygteenhed, får disse en opgave at udføre, mens der lyttes. Begge metoder har fordele og ulemper. Flyttes blinkfunktionen til lygteenheden, fordeles regnekraften, men dette giver også større risiko for, at de forskellige lygter kommer ud af takt med hinanden. Hvis masteren skal have kontrollen, kræves mere regnekraft af denne, men derved kan perifere enheder holdes mere ens i opbygningen, idet der ikke skal udvikles blinkenheder. En sidste mulighed kunne derfor være at kombinere de to således, at hver lygteenhed styrer blinkfunktionen, men synkroniseres af masteren med et givent interval. 119

Brugerinterfacet er nedprioriteret i prototypen og derfor er f.eks. brugergrænsefladen til opdateringen af systemet ikke udviklet, ligesom en brugermanual ikke er skrevet. Skal denne prototype af bilbussystemet produceres til det kommercielle marked, skal brugerinterfacet forbedres. Dette skal ske gennem en større brugertest samt en undersøgelse af nuværende produkter, hvilket munder ud i et brugerinterface på højde med nuværende systemers. På den måde nås der ud til et bredt marked. Den nuværende software kan optimeres og forbedres. Således kan funktioner i minimumsystemet, der benytter displayet, udvides til at benytte alle dets fire linjer og ikke kun den øverste, som det er tilfældet nu. En fælles softwareændring for hele systemet kan være at omskrive protokollen til at køre en slags multitasking. Som systemet fungerer nu, venter masteren på, at beregninger i en perifer enhed færdiggøres. Denne ventetid kunne erstattes med forespørgslen til den næste enhed. Således vil svaret fra en perifer enhed først nå frem til masteren en forespørgsel senere, hvilket vil give de perifere enheder en længere periode at udføre beregninger i - disse beregninger af databyte og paritet vil blive udført, imens master forespørger den næste perifere enhed. På denne måde vil afvikling af en enkelt forespørgsel tage lidt længere tid end nu, men forespørgsel samt svar fra samtlige enheder vil blive afviklet hurtigere end nu, idet beregninger ikke optager tid på databussen. 120

LITTERATURLISTE Litteraturliste 1N4148.pdf (2004). 1N4148, 1N4448 - High-speed diodes (Philps Semiconductors, 2004), URL http://www.semiconductors.philips.com/pip/1n4148.html. Datablad vedlagt som bilag på CD. 22CV10.pdf (2002). 22CV10A - CMOS programmable Electrically Erasable Logic Device (ICT, 2002). Datablad vedlagt som bilag på CD. 74HC148.pdf (1984). 74HC148-8-line to 3-line priority encoders, 2. edition (Texas Instruments, 1984), URL http://komponenten.ies.aau.dk/fileadmin/komponenten/data Sheet/MOS-TTL/hc/74HC148. pdf. Datablad vedlagt som bilag på CD. 74hc14.pdf (2003). 74HC14 hex inverting Schmitt trigger, 2nd edition (Phillips, 2003). Datablad vedlagt som bilag på CD. 74HC4060.pdf (1990). 74HC4060-14-stage ripple-carry binary, 1. edition (PHILLIPS, 1990), URL http://komponenten.ies.aau.dk/fileadmin/komponenten/data Sheet/MOS-TTL/hc/74HC4060. pdf.pdf. Datablad vedlagt som bilag på CD. AM29F010B.pdf (2002). AM29F010B - 128k x 8-bit (AMD, 2002). Datablad vedlagt som bilag på CD. AT90S2313.pdf, Atmel (2005). Datasheets Mature Products (www.atmel.com, 2005), URL http://www.atmel.com/dyn/products/devices.asp?status=mature&family id=607&family name=avr8-bitrisc. Hjemmesiden besøgt den 18.04.05. AT90S8535.pdf, Atmel (2005). Datasheets Mature Products (www.atmel.com, 2005), URL http://www.atmel.com/dyn/products/devices.asp?status=mature&family id=607&family name=avr8-bitrisc. Hjemmesiden besøgt den 04.05.05. 121

LITTERATURLISTE Biering-Sørensen, Stephen (2000). Håndbog i Struktureret Program Udvikling. ISBN 87-571-1046-8 (Teknisk Forlag, 2000). Clements, Alan (1997). Microprocessor Systems Design, third edition. ISBN 0-534-94822-7 (PWS Publishing Company, 1997). Clements, Alan (2000). The Principles of Computer Hardware, third edition. ISBN 0-19-856453-8 (Oxford, 2000). Davis, Leroy (2005). EIA232 (www.camiresearch.com, 2005), URL http://www.camiresearch.com/data Com Basics/RS232 standard.html#anchor1154232. Hjemmesiden besøgt den 15.03.05. Ebert, Hans (1998). Grundlæggende Transmitionsledningsteori, 3 edition (Afdeling for Kommunikationsteknologi, IES, Aalborg Universitet, 1998). EIA (2005a). EIA-232 standard (EIA, 2005a), URL www.camiresearch.com/data Com Basics/RS232 standard.html. Datablad vedlagt som bilag på CD. EIA (2005b). EIA-485 standard (EIA, 2005b), URL http://www.interfacebus.com/design Connector RS422.html. Datablad vedlagt som bilag på CD. Fondse, Peter J. (2004). Integrated Development Environment for the 68000 microcomputer (Peter J. Fondse, 2004), URL http://www.hzeeland.nl/ pfondse/ide68k/. Hjemmesiden besøgt den 17.05.05. Gyldendal (2005). Protokol (www.leksikon.nu, 2005), URL http://www.leksikon.nu/soegning/xmlresultat.asp?objart=/artikler/309449822. xml&objid=309449822&searchstring=protokol. Hjemmesiden besøgt den 14.03.05. HD44780.pdf (1999). Sharp - DOT matrix LCD units (Sharp, 1999). Datablad vedlagt som bilag på CD. HM628512.pdf (1994). HM628512-524288-word x 8-bit High Speed CMOS Static RAM (Hitachi, 1994). Datablad vedlagt som bilag på CD. 122

LITTERATURLISTE Holten, Karsten (1982). Digital Elektronik 1, second edition. ISBN 87-571-0750-5 (Teknisk Forlag, 1982). ks0066.pdf (). Driver & controller for DOT MATRIX LCD (Samsung, ). Datablad vedlagt som bilag på CD. Libraries, MotoRobots Software (2003). GNU m68k Embedded Development Environment (MotoRobots Software Libraries, 2003), URL http://www.motorobots.org/downloads.php. Hjemmesiden besøgt den 03.05.05. LM78L05.pdf (2005). LM78LXX Series 3-Terminal Positive Regulators (National Semiconductor, 2005), URL http://www.national.com/ds/lm/lm78l05.pdf. Datablad vedlagt som bilag på CD. M68KPM.pdf (1992). MOTOROLA M68000 FAMILY Programmer s Reference Manual (www.freescale.com, 1992), URL http://www.freescale.com/files/archives/doc/ref manual/m68000prm.pdf. Datablad vedlagt som bilag på CD. M68KUM.pdf (1993). MOTOROLA M68000 8-/16-/32-Bit Microprocessors User s Manual (Mororola, 1993), URL m68kum (mikroprocessor).pdf. Datablad vedlagt som bilag på CD. MAX232.pdf (2004). MAX-232 - RS232 driver/receiver, 13 edition (MAXIM, 2004), URL http://komponenten.ies.aau.dk/fileadmin/komponenten/data Sheet/Interface/MAX238. pdf. Datablad vedlagt som bilag på CD. MAX487.pdf (2003). MAX-487 - RS485 transceivers, 8 edition (MAXIM, 2003), URL http://komponenten.ies.aau.dk/fileadmin/komponenten/data Sheet/Interface/MAX487. pdf. Datablad vedlagt som bilag på CD. MC68000UM.pdf (2005). M68000 8-/16-/32-Bit Microprocessors User s Manual (www.freescale.com, 2005), URL http://www.freescale.com/files/archives/doc/ref manual/mc68000um.pdf. besøgt den 03.03.05. Hjemmesiden MC6850.pdf (2004). MC6850 - Asunchronous communications interface adapter (PHILLIPS, 2004), URL http://komponenten.ies.aau.dk/fileadmin/komponenten/data Sheet/Microprossor/MC6850. pdf. Datablad vedlagt som bilag på CD. 123

LITTERATURLISTE MCO1425B.pdf (1993). MCO 1425 B TTL Quartz Crystal Oscillator (Tele Quarz Group, 1993). Datablad vedlagt som bilag på CD. Nielsen, Sofus Birkedal (2003). TS2-MON manual, 1.2 edition. ISSN 09081224 (AAU, 2003), URL http://acoustics.aau.dk/ fc/tsmon 1.2.pdf. Hentet fra kursushjemmesiden d. 050517, vedlagt som bilag på CD. P-NET (2005). P-NET (www.p-net.dk, 2005), URL www.p-net.dk. Hjemmesiden besøgt den 03.03.05. reaktionstid.pdf (2005). Sikkerhed for indsatspersonale og følgeuheld (www.fyns-amt.dk, 2005), URL http://www.fyns-amt.dk/wm142591. Hjemmesiden besøgt den 25.05.05. STK-500.pdf (2003). AVR STK500 User Guide, 1. edition (Atmel, 2003), URL http://www.atmel.com/dyn/resources/prod documents/doc1925.pdf. Datablad vedlagt som bilag på CD. Strangio, Christopher E. (2005). EIA485 (www.interfacebus.com, 2005), URL http://www.interfacebus.com/design Connector RS422.html. Hjemmesiden besøgt den 21.03.05. Superior-Cables.pdf (1998). UTP Patch Cables, 4 edition (Superior Cables, 1998), URL http://www.superior-cables.com/pdf/data.pdf. Tanenbaum, Andrew S. (1999). Structured Computer Organization, fourth edition. ISBN 0-13-020435-8 (Alan APT, 1999). TL7705A.pdf (2003). TL7705A Supply Voltage Supervisor (Texas Instruments, 2003), URL http://focus.ti.com/docs/prod/folders/print/tl7705a.html. Hjemmesiden besøgt den 17.03.05. Wakerly, John F. (2001). Digital design - principles and practice, 3rd edition. ISBN 0-13-090772-3 (Prentice Hall, 2001). 124

LITTERATURLISTE wh2004a.pdf (). 20x4dots character LCD (Winstar, ). Datablad vedlagt som bilag på CD. 125

Del VI: Appendiks I denne del forefindes alle appendiks. I det første appendiks analyseres bilbussystemet for at fastlægge de indeholdende UseCases i dette. Herefter følger en oversigt over de elektriske funktioner i moderne biler. Appendiks C omhandler M68k processorens read- og write cycle og efterfølges af appendiks D indeholdende en beskrivelse af registre, kommunikation og benforbindelser for den valgte ACIA. Fra appendiks E til I findes alt kildekode anvendt i masterenheden. I appendiks J findes kildekode anvendt i de perifere enheder. Diverse målejournaler følger fra appendiks L og fremefter. Endelig findes folduddiagrammer over den konstruerede hardware i appendiks R og S. Del VI: Appendiks 127 A Oversigt over elektriske funktioner i moderne biler 129 B UseCases 133 B.1 Identifikation af UseCases...................................... 133 B.2 UseCase: Styr display........................................ 133 B.3 UseCase: Styr lys........................................... 134 B.4 UseCase: Udlæs data......................................... 134 B.5 UseCase: Omprogrammér master.................................. 135 C M68k read og write timing 137 C.1 Read cycle............................................... 137 C.2 Write cycle.............................................. 139 D Beskrivelse af ACIA 141 D.1 Registre................................................ 141 D.2 Kommunikation............................................ 143 D.3 Benforbindelser............................................ 143 E Kildekode til PEEL-programmer 145 E.1 Kildekode til PEEL01........................................ 145 E.2 Kildekode til PEEL02........................................ 146 F Kildekode til initialiseringsproces 147 F.1 Assembler-kode til initialisering af hardware modul........................ 147 G Kildekode til løkkeproces 149 G.1 Header-fil til lygtekontrolmodul................................... 149 G.2 C-kode til lygtekontrolmodul.................................... 149

G.3 Header-fil til oliekontrolmodul.................................... 150 G.4 C-kode til oliekontrolmodul..................................... 150 G.5 Header-fil til løkkestyringsmodul.................................. 151 G.6 C-kode til løkkestyringsmodul.................................... 151 H Kildekode til displayproces 153 H.1 Header-fil til displaymodul...................................... 153 H.2 C-kode til displaymodul....................................... 153 H.3 Assembler-kode til displaymodul.................................. 155 H.4 Beregning af tidsforbrug ved afvikling af interrupt........................ 156 I Kildekode til bus- og tabelmodulerne 159 I.1 Header-fil til tabelmodulerne.................................... 159 I.2 C-kode til tabelmodulerne...................................... 159 I.3 Assembler-kode til busmodul.................................... 160 J Kildekode til perifere enheder 163 J.1 Header-fil til lygtekontrolenhed................................... 163 J.2 C-kode til lygtekontrolenhed..................................... 164 J.3 C-kode til lygteenhed......................................... 165 J.4 C-kode til olieenhed......................................... 166 K Kildekode til testsoftware 169 K.1 C-kode til test af software i minimumsystemet........................... 169 K.2 C-kode til test af A/D converter i olieenhed............................ 170 K.3 C-kode til test af RS485 i de perifere enheder........................... 171 L Målejournal for clock-generatorer 173 M Målejournal for reset-kredsløb 177 N Målejournal for DTACK -generator 179 O Målejournal for responstid på perifere enheder 181 P Målejournal for ACIA485 185 Q Målerapport for accepttest 187 Q.1 Formål................................................. 187 Q.2 Test af Kommunikationstid..................................... 187 Q.3 Test af brugerinterface........................................ 189 Q.4 Spørgeskema til interface test.................................... 190 R Folduddiagrammer over perifere enheder 193 S Folduddiagram over minimumsystemet 195

APPENDIKS A. OVERSIGT OVER ELEKTRISKE FUNKTIONER I MODERNE BILER Appendiks A Oversigt over elektriske funktioner i moderne biler Nedenstående er en ufuldstændig, og historisk set evigt voksende liste over funktioner/egenskaber, som biler kan være udstyret med. Listen medtager kun elementer, som på en eller flere måder er tilsluttet bilens elektriske system. AAR Automatic Air Recirculation - system, der sikrer, bilens friskluftindtag lukkes, hvis der detekteres luft uden for bilen med et forureningsindhold, der ligger over et givet niveau. Kan detektere f.eks. CO og NO x. ABS Antilock Brake System - idag standard i de fleste biler. Sikrer hjulrotation selvom der bremses hårdt, og medvirker dermed til, at der kan styres samtidig med at der bremses. ACC Active Cruise Control - system, der opretholder en given afstand til forankørende når fartpilot er slået til. Sæde ventilation Tvunget luftcirkulation indbygget i sæde og ryglæn på forsæder. Aktive sæder Sæder, der langsomt ændrer ryghældning og lændestøtte under kørsel. Drejelige lygter Detekterer bilens rotation om egen akse, og via servomotorer drejer lygteparaboler, så nær og fjernlys lyser i den retning man drejer bilen. ASC+T Automatic Stability Control + Traction - system, hvor kraftoverførsel fra hjul til vej søges optimeret. Griber ind i motor- og bremsesystem. Har til hensigt at modvirke udskridninger og andre sværtkontrollable egenskaber. Selv-nivellering Elektropneumatisk system, der udligner forskel i undervognshøjde ved forskellige lastsituationer. Således vil bilen have samme højde, og dermed samme hjulvinkler uanset, om bilen er lastet med f.eks. 50 kg eller 500 kg. 129

Sikkerheds-batteriterminal Strøm til starter og benzinpumpe afbrydes vha. en sprængladning, der initieres af bilens AirBagcomputer. I fald af sammenstød sprænges plus-ledningen væk fra starter/motor/benzinpumpe kredsløb, og mindsker hermed risikoen for brand. Strøm til bilens nødbelysnings-anlæg herunder katastrofeblink bibeholdes. Xenon-fjernlys Xenon-lygter med elektronisk ballast anvendes flittigt i moderne biler. Nyt er, at også fjernlys kan fremstilles vha. xenon. Dette implementeres ved, at en servomotor fjerner en nærlys blænde. HiFi Lyd i biograf-klasse finder vej til biler. 7 højtalere med individuelle forstærkere, DSP-anlæg mv. er tilgængeligt udstyr i flere bil-modeller. EDC Electronic Damper Control - system, der via sensorer, en mikrocontroller og elektromagnetventiler søger at hindre kraftige tilt under sving, og samtidig øger sikkerheden via øget vejkontakt. Hertil kommer øget komfort. EDL Electronic Differential Lock - elektronisk låsning af differentiale. Særligt nyttigt i 4-hjulstrukne biler. EPB Electronic Parking Brake - parkeringsbremse, der styres elektronisk, så det sikres at igangsætning, efter parkering på bakker ikke resulterer i at bilen ruller ned i bagvedholdende biler. Elektronisk gasspjæld Servostyret luftspjæld, der bestemmer luftmængden tilført motoren. GPS General Positioning System - anlæg, der kan oplyse, hvor man befinder sig i længde og breddegrader. Sammenholdt med et elektronisk kort kan systemet bruges som interaktiv vejviser. Parkeringssensor System, der fortæller bilens fører, hvor tæt bilen er på andre objekter, f.eks. andre biler, lygtepæle osv. Hjælper til at undgå buler, ridser mv. SSG Semiautomatic Sequentiel Gearbox - elektromekanisk gearskifte. Kan lave f.eks. meget hurtige eller brændstof-økonomiske gearskift. TDI Tyre Defect Indicator - indikerer defekte hjul, f.eks. for lavt dæktryk. Videokrydsfelt Elektronisk styring af video til LCD-skærme i nakkestøtter og i passagerside. Hastighed og omdrejningstal Elektronisk præsentation af hastighed og motor-omdrejninger. Herunder også beregning af gennemsnitshastighed, tid til destination, triptæller mv. Motordata Elektronisk opsamling af motordata, f.eks. olietryk, olietemperatur, tændingsbanken, ladespænding, gasspjældsstilling, aktiv-kulbeholder ventil mv. Tyverialarm Mere eller mindre avanceret system, der hindrer uretmæssig overtagelse af køretøjet. 130

APPENDIKS A. OVERSIGT OVER ELEKTRISKE FUNKTIONER I MODERNE BILER Lys Alle bilens lygter styres elektrisk, og kan evt. moniteres mht. defekte pærer. Herunder også automatisk nedblænding af langlys ved detektion af modkørende. El-betjent bagagerum og benzinklap Elektrisk styret solenoide, der kan åbne bezinklap og bagklap. Vinduesviskere, lygteviskere og sprinkleranlæg System, der kan detektere regn, og som følge heraf køre med viskere i passende interval. Endvidere kan systemet detektere koldt vejr og varme sprinklervæsken op for at sikre, at det ikke fryser til is, når det rammer forrude og lygteglas. Elruder og el-soltag Udover almindelig kontaktstyring, stopper elruder og soltag, hvis uventet modstand detekteres. Hermed sikres, at fingre, der kommer i klemme ikke bliver mast. Central lås Elektromekanisk system, der i samarbejde med alarm-systemet kan låse køretøjet. Fjernstart af motor Detektion af, om bil er i frigear og derefter opstart af motor. Kabine-luft Individuel styring af, hvilke pladser i køretøjet der ønsker luft, hvilken mængde, og hvilen temperatur. 131

APPENDIKS B. USECASES Appendiks B UseCases I dette appendiks analyseres systemet efter UseCase teknikken fra UML udviklingsmetoden. Disse UseCases skal benyttes i kravspecifikationen kapitel 2 på side 9 under afsnittet om de funktionelle krav til systemet. De enkelte UseCases vil blive beskrevet af punkterne målbeskrivelse, normal scenario og eventuelle undtagelser. I målbeskrivelsen belyses funktionen af en UseCase, hvorefter punktet normal scenario fortæller, hvilke trin UseCasen forventes at gennemløbe for at opfylde denne målbeskrivelse. Eventuelle undtagelser fra den normale afvikling af UseCasen beskrives til sidst. B.1 Identifikation af UseCases På figur B.1 er de identificerede aktører og UseCases optegnet med disses indbyrdes interaktioner. Med en aktør forstås enten en person eller en hardwareenhed, der er udenfor det system, der skal udvikles, men som er i samspil med systemet. En UseCase beskriver en funktionalitet, der udføres af systemet for en given aktør. Styr display Automekaniker Styr lys Bruger Udlæs data PC Omprogrammér master Figur B.1: Aktør kontekstdiagram til UseCase analyse af systemet. B.2 UseCase: Styr display B.2.1 Målbeskrivelse Denne UseCase giver brugeren mulighed for at vælge, hvilke data der skal vises på displayet i førerkabinen. Dette gøres vha. to taster til visning af henholdsvis forrige eller næste information. 133

B.3. USECASE: STYR LYS B.2.2 Normal scenario Ved opstart af systemet vises en velkomst-meddelelse på displayet. Herefter foregår det normale scenario i en løkke med trinene: 1. Brugeren vælger næste eller forrige information. 2. Næste eller forrige funktion vises på display. B.2.3 Undtagelser Følgende undtagelser fra det normale scenario kan finde sted: 1. Der vælges forrige information som første indtast Fejlbesked på display, og der vises atter velkomst meddelelse. 2. Data kan ikke modtages fra perifer enhed. Fejlbesked på display, og der vises forrige information eller velkomstbesked, hvis systemet lige er startet op. B.3 UseCase: Styr lys B.3.1 Målbeskrivelse Denne UseCase giver brugeren mulighed for at styre lygteenheden gennem lygtekontrolenheden. Dette gøres vha. fire kontakter til kontrol af funktionerne fjern, nær, blink og position. B.3.2 Normal scenario Det normale scenario for denne UseCase er: 1. Tast aktiveres. 2. Information sendes via den serielle bus til masterenhed. 3. Masterenhed modtager information og sender denne videre til lygteenhed. 4. Perifer enhed modtager og reagerer på information. B.3.3 Undtagelser Følgende undtagelser fra det normale scenario kan finde sted: 1. Perifer enhed reagerer ikke Fejlbesked på display. 2. Pære sprunget i lygtehus Fejlbesked på display. 3. Tab af data ved kommunikation mellem enheder Fejlbesked på display. B.4 UseCase: Udlæs data B.4.1 Målbeskrivelse Denne UseCase giver brugeren mulighed for at udlæse data fra masterenheden til PC via RS232 kommunikation. 134

APPENDIKS B. USECASES B.4.2 Normal scenario Det normale scenario for denne UseCase er: 1. PC beder masterenhed om data. 2. Masterenhed overfører data til PC. B.4.3 Undtagelser Følgende undtagelser fra det normale scenario kan finde sted: 1. Ingen data tilgængelig fra masterenhed Fejlbesked vises på PC. B.5 UseCase: Omprogrammér master B.5.1 Målbeskrivelse Denne UseCase giver den kompetente bruger, i form af en automekaniker, mulighed for at ændre i den programkode, der afvikles i masterenheden. Dette gøres via RS232 kommunikation til en PC. B.5.2 Normal scenario Det normale scenario for denne UseCase er: 1. PC kontakter masterenhed. 2. Masterenhed sætter al kommunikation på den serielle bus i bero. 3. Masterenhed sender dens nuværende kode til PC. 4. En ny kode sendes fra PC til masterenhed. 5. Masterenhed genstartes. B.5.3 Undtagelser Følgende undtagelser fra det normale scenario kan finde sted: 1. Ingen kontakt mellem PC og masterenhed Fejlbesked på PC. 135

APPENDIKS C. M68K READ OG WRITE TIMING Appendiks C M68k read og write timing I dette appendiks beskrives M68k processorens read og write cycles. Dette gøres vha. protokol flowdiagrammer og timingsdiagrammer [MC68000UM.pdf, 2005]. C.1 Read cycle På figur C.1 er rækkefølgen af hændelserne i en read cycle for M68k processoren vist med et flowdiagram. Hver buscycle på en M68k består af minimum 4 clock cycles inddelt i 8 states kaldet S0-S7. En buscycle Bus master (M68k) Adressere slave Bus slave (memory) 1. Sætter R/W* høj 2. Placerer funktion kode på FC 0 -FC 2 3. Placerer adresse på A 01 til A 23 4. Asserterer AS* 5. Asserterer UDS* og LDS* Output fra data 1. Dekoder adresser på A 01-A 23 2. Placerer data på D 00-D 15 3. Asserterer DTACK* Modtagelse af data 1. Latch data fra D 00-D 15 2. Negerer UDS* og LDS* 3. Negerer AS* Afslutte cycle 1. Fjerner data fra D 00-D 15 2. Negerer DTACK* Starter den næste cycle Figur C.1: Flowdiagram for M68k read cycle. kan udvides til at omfatte flere clock cycles mellem S4 og S5, hvis den tilsluttede RAM/ROM-kreds ikke kan levere data på bussen tilstrækkeligt hurtigt. Denne egenskab ved processoren gør, at det er muligt at tilslutte hukommelseskredse med forskellige hastigheder. 137

C.1. READ CYCLE På figur C.2 ses et timingsdiagram for en read cycle med M68k. Read cyclen starter med at R/W høj, hvorefter processoren placerer den ønskede adresse på A1-A23. Efterfølgende asserteres LDS og/eller UDS samt AS, hvilket giver signal til busslaven om, at der nu kan afkodes en stabil adresse på adressebussen. Busslaven placerer herefter sine data på D00-D07 og/eller D08-15 og fortæller processoren, at disse data er gyldige ved at assertere DTACK. Processoren latcher nu data og negerer UDS, LDS og AS, hvilket giver signal til busslaven om at fjerne data fra bussen igen og herefter negere DTACK. Processoren er nu klar til at påbegynde en ny buscycle. t cyc S0 S1 S2 S3 S4 S5 S6 S7 S0 CLK t CLAV t ACC A 01 A 23 Adresser stabile t CHSL AS* UDS*, LDS* R/W* t ASI DTACK* t DALDI t DICL D 00 -D 07 Data gyldige Figur C.2: Timingsdiagram for M68k read cycle. På figur C.2 ses det, at den nye adresse bliver placeret på adressebussen i løbet af maksimum t CLAV. Herefter asserteres AS på første opadgående flanke inden t CHSL. Tiden t DALDI angiver tiden fra DTACK asserteres til data bliver gyldige. Disse data skal herefter være gyldige i mindst t DICL inden begyndelsen af S7. De ovennævnte tider er for M68k processoren angivet i tabel C.1. Symbol Betegnelse min.[ns] maks.[ns] t cyc Clock period 125 250 t CLAV Clock low to adress valid - 62 t AV SL Address valid to AS low 30 - t CHSL Clock high to AS, DS low 0 60 t ASI Asynchronous input DTACK setup time 10 - t DALDI DTACK low to data in setup time - 90 t DICL Data in to clock low setup time 15 - t SHDI DS high to data invalid 0 - t ACC Address to output delay - 50 Tabel C.1: Timingstider for M68k read cycle. 138

APPENDIKS C. M68K READ OG WRITE TIMING C.2 Write cycle På figur C.3 er rækkefølgen af hændelserne i en write cycle for M68k processoren vist med et flowdiagram. De to flowdiagrammer for henholdsvis read- og write cycle med M68k processoren er som det ses af figur Bus master (M68k) Adressere slave Bus slave (memory) 1. Placerer funktion kode på FC 0 -FC 2 2. Placerer adresse på A 01 til A 23 3. Asserterer AS* 4. Sætter R/W* lav 5. Placerer data på D 00 -D 15 6. Asserterer UDS* og LDS* Input fra data 1. Dekoder adresser på A 01-A 23 2. Latch data ind fra D 00 -D 15 3. Asserterer DTACK* Afslutte write cycle 1. Negerer UDS* og LDS* 2. Negerer AS* 3. Fjerner data fra D 00 -D 15 4. Sætter R/W* høj 1. Negerer DTACK* Afslutte cycle Starter den næste cycle Figur C.3: Flowdiagram for M68k write cycle. C.1 og C.3 meget ens. Den afgørende forskel er, at M68k processoren i write tilfældet sætter data på bussen, hvorefter memory-kredsen indlæser disse. I read tilfældet var det omvendt. Det er vigtigt, at DTACK asserteres før den nedadgående flanke af S4, ellers vil der indsættes wait states mellem S4 og S5 indtil DTACK asserteres inden en nedadgående flanke i processorens clock. Det ses af figur C.4, at dette vil medføre negering af AS inden tiden t SL(W ). Desuden vil R/W blive negeret og databussen vil svæve. På tabel C.2 ses de angivne tider fra figur C.4 for M68k processoren. Symbol Betegnelse min.[ns] maks.[ns] t AV SL Address valid to AS asserted 30 - t SL AS asserted 270 - t SHAZ AS, DS negated to address bus high impedance 40 - t SL(W ) DS asserted in write cycle 140 - t ASRV AS asserted to R/W low - 10 t AV RL Address valid to R/W low 20 - t RLSL R/W low to DS asserted 20 - t SHRH AS, DS negated to R/W high 20 - t DOSL Data out valid to DS asserted 40 - t SHDOI AS, DS negated to data out invalid 40 - Tabel C.2: Timingstider for M68k write cycle. 139

C.2. WRITE CYCLE S0 S1 S2 S3 S4 S5 S6 S7 S0 CLK A 01 A 23 Adresser stabile t AVSL t SL t SHAZ AS* t SL(W) UDS*, LDS* t ASRV t AVRL t RLSL t SHRH R/W* t DOSL t SHDIO D 00 -D 07 Data gyldige DTACK* Figur C.4: Timingsdiagram for M68k write cycle. 140

APPENDIKS D. BESKRIVELSE AF ACIA Appendiks D Beskrivelse af ACIA I dette afsnit gives en gennemgang af UART-blokkene fra figur 2.1 på side 10. UART ens opgave er at fungere som parallel / seriel konverter mellem M68k eren og de perifere enheder eller omvendt. I dette tilfælde gælder det en forbindelse til en PC samt en seriel forbindelse til de perifere enheder på bussen. Det er valgt at benytte en Motorola MC6850 ACIA, idet denne er direkte kompatibel med M68k processoren, samt at TS2-MON er designet til denne enhed. ACIA står for Asyncronous Communications Interface Adaptor og er vist som blokdiagram på figur D.1 [Clements, 1997]. Parallel E CS0 CS1 CS2* RS R/W* D00 D01 D02 D03 D04 D05 D06 D07 Chip- Select Read / Write control Databus buffer MC6850 ACIA Tx data register + control Status register Control register Rx data register + control TxCLK RTS* CTS* TxD RxD DCD* RxCLK Serial Serial Figur D.1: Blokdiagram for ACIA MC6850. D.1 Registre En ACIA indeholder i alt 4 registre, hvoraf to er kontrol/statusregistre. De to øvrige udgør transmit- og receive dataregistrene. Adgangen til disse registre kontrolleres med benene RS og R/W som beskrevet i tabel D.1 [MC6850.pdf, 2004]. På de efterfølgende sider er en gennemgang af registrene startende med kontrolregistret. D.1.1 Kontrolregister Kontrolregistret er et programmerbart write-only register og indeholder 8 bit med funktioner beskrevet herunder. Normalt skrives der kun til dette register ved powerup, idet registret definerer selve ACIA ens 141

D.1. REGISTRE RS R/W Tilgang til 0 0 Kontrol register 0 1 Status register 1 0 Transmit data register 1 1 Receive data register Tabel D.1: Adgang til registre i ACIA. funktionalitet. De 8 bit i registret er vist i tabel D.2 efterfulgt af en beskrivelse. CR7 CR6 CR5 CR4 CR3 CR2 CR1 CR0 IRQ enable Transmitter control Word select Division ratio Tabel D.2: Bit i kontrolregisteret. CR0 og CR1 - Counter Divide Select Bits. Med disse to bit kan clock en på RxCLK eller TxCLK deles med 1, 16 eller 64. Dertil Anvendes disse bit til Master reset af ACIA en, hvorved statusregistret nulstilles samt at sender- og modtagerdelen initialiseres. CR2, CR3 og CR4 - Word Select Bits. Disse tre bit anvendes til at angive word-længde, paritet og antal stopbit. CR5 og CR6 - Transmitter Control Bits. Bestemmer, om RTS og IRQ udgangene skal anvendes. CR7 - Receive Interrupt Bits. Når C7 er sat, vil et fyldt recieve-data register medføre, at IRQ asserteres. D.1.2 Statusregister Statusregistret er et read-only register og benyttes til læse den aktuelle status på ACIA en. De 8 bit i registret er vist i tabel D.3 efterfulgt af en beskrivelse. SR7 SR6 SR5 SR4 SR3 SR2 SR1 SR0 IRQ Parity error Receiver overrun Frame error CTS* DCD* Transmit reg. empty Receiver reg. full Tabel D.3: Bit i statusregisteret. SR0 - Receiver Data Register Full. Går høj, hvis recieve data registret er fyldt op og er klar til at afgive data. SR1 - Transmitter Data Register Empty. Går høj, såfremt transmit data registret er tømt efter en transmission, og er klar til at blive fyldt op igen. SR2 - Data Carrier Detect. SR2 afspejler indgangsbenet DCD og bliver sat af en høj værdi på DCD. Denne anvendes til at markere, om en datastrøm er fejlbehæftet. SR3 - Clear To Send. Indgang på transmit-siden, som med et lavt niveau indikerer, at en ekstern enhed er klar til at modtage data fra ACIA en. SR4 - Framing error. Denne bit bliver sat, såfremt en modtaget karakter er forkert indrammet mht. startbit og stopbit. 142

APPENDIKS D. BESKRIVELSE AF ACIA SR5 - Reciever Overrun. Denne bit bliver sat, når en modtaget karakter ikke bliver læst af M68k eren før en efterfølgende karakter bliver modtages og overskriver den forhenværende. Dvs. hver gang data går tabt, bliver denne bit sat. SR6 - Parity Error. Hvis pariteten i det modtagede data ikke svarer til pariteten defineret med CR2, CR3 og CR4. SR7 - Interrupt Request. Bliver sat sammen med udgangen IRQ, når ACIA en ønsker at afbryde M68k eren. D.1.3 Transmit/Receive data register Disse to registre fungerer som buffere og anvendes til midlertidigt at lagre data, der skal henholdsvis sendes videre eller er modtaget. D.2 Kommunikation Kommunikationen mellem M68k og ACIA foregår synkront, hvilket betyder, at de deler en fælles clock. Årsagen til at vælge synkron kommunikation ligger i, at enhederne er designet til dette. Herunder er vist blokdiagram med protokol for synkron kommunikation. Undervejs asserteres VPA, hvilket er signal til M68k om, at trafik vil foregå synkront. M68k Initiér cycle 1. Placer function code på FC0 FC2 2. Placer adressen på A01 til A23 3. Assertér AS* 4. Assertér UDS* / LDS* ACIA Anmod om synkron cycle 1. Detekter valid tilgang til slavens adresserum 2. Assertér VPA* Synkronisér med enable 1. Vent på at E negeres 2. Assertér VMA* Overfør data 1. Vent på at E asserteres 2. Send / hent data Terminér cycle 1. Vent på at E negeres 2. Negér VMA* 3. Negér AS*, ULD* / LDS* Figur D.2: Blokdiagram for synkron kommunikation mellem M68k og ACIA [Clements, 1997]. D.3 Benforbindelser D.3.1 Mellem M68k og ACIA Til kommunikationen mellem M68k og ACIA benyttes følgende benforbindelser: 143

D.3. BENFORBINDELSER D0-D7 - Disse udgør databenene og tilsluttes den parallelle databus på M68k. RS og R/W - Disse to ben benyttes til at vælge, hvilket register, der ønskes adgang til. Se evt. tabel D.1 E - Input-ben til den clock, hvormed ACIA en synkroniseres med M68k. CS0, CS1 og CS2 - Disse ben anvendes til chip-select af ACIA en. Alle tre ben skal være asserteret for at vælge kredsen. D.3.2 Modtagerdel De benforbindelser, der danner grænsefladen for modtagerdelen af ACIA en, er følgende: RxD - Receiver Data Input. Modtager data serielt fra omverdenen. RxCLK - Receiver Clock. Til dette ben forsynes clock-signal. Frekvensen herfra skal være delelig med 1, 16 eller 32 ift. den bitrate, datastrømmen forventes modtaget med. DCD - Data Carrier Detect. Dette ben anvendes til at angive, om indkommende data er korrupt. Normalt benyttes indgangen kun ifm. modems, og hvis den er høj, kan det være ensbetydende med, at der er fejl i datastrømmen. D.3.3 Senderdel De benforbindelser, der danner grænsefladen for senderdelen af ACIA en, er følgende: TxD - Transmitter Data Input. Sender data serielt til omverdenen. TxCLK - Transmitter Clock. På dette ben modtages clock til senderdelen. Denne skal være 1, 16 eller 32 gange den bitrate, datastrømmen ønskes afsendt ved. RTS - Request To Send. ACIA en anvender dette til at signalere, at den er klar til at sende data. CTS - Clear To Send. Dette ben er et input, der anvendes til at lade en anden enhed fortælle, at den er klar til at modtage data fra ACIA en. 144

APPENDIKS E. KILDEKODE TIL PEEL-PROGRAMMER Appendiks E Kildekode til PEEL-programmer Dette appendiks indeholder WinPLACE-koden anvendt i PEEL01 og PEEL02. E.1 Kildekode til PEEL01 I dette afsnit ses PEEL01.PSF, der indeholder koden til adressedekoderen i minimumsystemet. Koden er skrevet med udgangspunkt i kapitel 10 på side 49. 1 TITLE A d r e s s e d e k o d e r 2 DESIGNER GR 415 3 DATE 14 0 42 0 05 4 5 PEEL22CV10A 6 7 I /O CONFIGURATION DECLARATION 8 IOC ( PIN NO PIN NAME POLARITY OUTPUT TYPE FEEDBACK TYPE ) 9 AS Pin 1 10 INT Pin 2 11 A18 Pin 3 12 A19 Pin 4 13 A20 Pin 5 14 A21 Pin 6 15 A22 Pin 7 16 A23 Pin 8 17 LDS Pin 9 18 UDS Pin 10 19 RW Pin 11 20 VMA Pin 13 21 22 IOC ( 14 CS IO Neg OutCom Feed Pin ) 23 IOC ( 15 OE Neg OutCom Feed Pin ) 24 IOC ( 16 VPA Neg OutCom Feed Pin ) 25 IOC ( 17 CS DISP Pos OutCom Feed Pin ) 26 IOC ( 18 CS ACIA485 Neg OutCom Feed Pin ) 27 IOC ( 19 CS ACIA232 Neg OutCom Feed Pin ) 28 IOC ( 20 CS ROM1 Neg OutCom Feed Pin ) 29 IOC ( 21 CS ROM2 Neg OutCom Feed Pin ) 30 IOC ( 22 CS RAM1 Neg OutCom Feed Pin ) 31 IOC ( 23 CS RAM2 Neg OutCom Feed Pin ) 32 33 A NODE 25 34 SP NODE 26 G l o b a l S y n c h r o n o u s P r e s e t 35 36 EQUATIONS 37 38 A = 0 ; 39 40 SP = 0 ; 41 42 CS IO.And = 0 ; 43 CS IO.Com = A23 &! A22 &! A21 &! A20 &! A19 & A18 &! LDS &! AS ; 44 45 OE.And = 0 ; 46 OE.Com = RW &! AS ; 47 48 VPA.And = 0 ; 49 VPA.Com = ( ( A23 &! A22 &! A21 &! A20 &! A19 &! A18 &! ( UDS & LDS) ) &! AS) # INT ; 50 51 CS DISP.And = 0 ; 52 CS DISP.Com = A23 &! A22 &! A21 &! A20 &! A19 & A18 &! UDS &! AS ; 53 54 CS ACIA232.And = 0 ; 55 CS ACIA232.Com = A23 &! A22 &! A21 &! A20 &! A19 &! A18 &! LDS &! AS &!VMA; 56 57 CS ACIA485.And = 0 ; 58 CS ACIA485.Com = A23 &! A22 &! A21 &! A20 &! A19 &! A18 &! UDS &! AS &!VMA; 145

E.2. KILDEKODE TIL PEEL02 59 60 CS ROM2.And = 0 ; 61 CS ROM2.Com =! A23 &! A22 &! A21 &! A20 &! A19 &! A18 &! LDS &! AS ; 62 63 CS ROM1.And = 0 ; 64 CS ROM1.Com =! A23 &! A22 &! A21 &! A20 &! A19 &! A18 &! UDS &! AS ; 65 66 CS RAM2.And = 0 ; 67 CS RAM2.Com =! A23 &! A22 &! A21 & ( (! A20 & A18 ) # (! A20 & A19 ) # ( A20 &! A19 &! A18 ) ) &! LDS &! AS ; 68 69 CS RAM1.And = 0 ; 70 CS RAM1.Com =! A23 &! A22 &! A21 & ( (! A20 & A18 ) # (! A20 & A19 ) # ( A20 &! A19 &! A18 ) ) &! UDS &! AS ; E.2 Kildekode til PEEL02 I dette afsnit ses PEEL02.PSF, der indeholder kode til interrupthåndtering og DTACK generering i minimumsystemet. Koden er skrevet med udgangspunkt i kapitel 7 på side 35. 1 TITLE PEEL 0 2 2 DESIGNER GR 415 3 DATE 2 6 0 4 2 0 0 5 4 5 PEEL22CV10A 6 7 I /O CONFIGURATION DECLARATION 8 IOC ( PIN NO PIN NAME POLARITY OUTPUT TYPE FEEDBACK TYPE ) 9 CLK pin 1 10 IRQ7IN pin 2 11 IRQ7NIN pin 6 12 FC0 pin 3 13 FC1 pin 4 14 FC2 pin 5 15 AS pin 7 16 CS DISP pin 8 17 DISP OK pin 9 18 19 IOC ( 14 Pos Com Feed Pin ) 20 IOC ( 15 Pos Com Feed Pin ) 21 IOC ( 16 Pos Com Feed Pin ) 22 IOC ( 17 Pos Com Feed Pin ) 23 IOC ( 18 Pos Com Feed Pin ) 24 IOC ( 19 Pos Com Feed Pin ) 25 IOC ( 20 DTACK Pos OutCom Feed Pin ) 26 IOC ( 21 TESTOUT Neg OutCom Feed Pin ) 27 IOC ( 22 VPA Pos OutCom Feed Pin ) 28 IOC ( 23 IRQ7OUT Neg OutCom Feed Pin ) 29 30 AR NODE 25 G l o b a l A s y n c h r o n o u s R e s e t 31 SP NODE 26 G l o b a l S y n c h r o n o u s P r e s e t 32 33 EQUATIONS 34 35 AR = 0 ; 36 37 SP = 0 ; 38 39 IRQ7OUT.And=0; 40 IRQ7OUT.Com=IRQ7NIN & IRQ7IN ; 41 42 TESTOUT.And=0; 43 TESTOUT.Com=IRQ7NIN & IRQ7OUT ; 44 45 VPA.And=0; 46 VPA.Com=FC0 & FC1 & FC2 ; 47 48 DTACK.And=0; 49 DTACK.Com=AS # ( CS DISP &! DISP OK ) ; 146

APPENDIKS F. KILDEKODE TIL INITIALISERINGSPROCES Appendiks F Kildekode til initialiseringsproces Dette appendiks indeholder kildekode fra moduler under initialiseringsprocessen for masteren (se eventuelt figur 15.1 på side 81). F.1 Assembler-kode til initialisering af hardware modul I dette afsnit ses assembler-koden fra boot.asm indeholdende initialiseringen af hardware. 1 DISPLAY ki lde : ks0066. pdf Bitmønster for : 2. equ DISP RESET, 0b00111000 Reset 3. equ DISP ENTRY, 0b00000110 Skrivning mod højre 4. equ DISP ON, 0 b00001100 D i s p l a y tændt, uden c u r s o r e l l e r b l i n k 5. equ DISP CURSOR, 0 b00001110 Display tændt, med cursor 6. equ DISP BLINK, 0 b00001101 D i s p l a y tændt, med b l i n k e n d e f e l t 7. equ DISP OFF, 0b00001000 Display slukket 8. equ DISP CLEAR, 0b00000001 9 10 ACIA kilde : MC6850. pdf Bitmønster for : 11. equ ACIA RESET, 0b00000011 Reset 12 13. equ ACIA DIV16, 0 b00000001 I n t e r n 16 d e l i n g a f c l o c k 14 15. equ ACIA 8N1, 0 b00010100 8 b i t data, i n g e n p a r i t e t, 1 s t o p b i t 16. equ ACIA 8E1, 0b00011000 8 bit data, l i g e paritet, 1 stopbit 17 18. equ ACIA RTS, 0b01000000 Kontrol af ACIA ens RTS udgang 19 20. g l o b a l ACIA RX BUFFER 21. equ ACIA RX BUFFER, 0 b00000001 B i t d e r a n g i v e r, a t ACIA en har modtaget en b y t e s e r i e l t 22 23. g l o b a l ACIA TX BUFFER 24. equ ACIA TX BUFFER, 0 b00000010 B i t der a n g i v e r, at ACIA en e r k l a r t i l at modtage en byte 25 p a r a l l e l t 26 27 RS485 xx b r u g e s t i l s æ t t e ACIA en op t i l om RS485 d r i v e r e n s k a l s e n d e e l l e r modtage 28 RS485 d r i v e r e n s t y r e s v i a ACIA e n s RTS ben 29. g l o b a l RS485 TX 30. equ RS485 TX, 0 b01011000 ACIA 8E1 # ACIA RTS 31 32. g l o b a l RS485 RX 33. equ RS485 RX, 0 b00011000 ACIA 8E1 34 35. t e x t 36. g l o b a l mbr 37. type mbr, @function 38. even 39 40 mbr : 41 move. l #0x120000,% sp Starter stack en i 0x120000 42 bsr i n t e r r u p t i n i t K a l d e r i n i t i a l i s e r i n g a f i n t e r r u p t f u n k t i o n e r n e 43 bsr i n i t r s 2 3 2 K a l d e r i n i t i a l i s e r i n g a f ACIA232, b l i v e r u d f ø r t a t TS2 MON 44 bsr i n i t r s 4 8 5 K a l d e r i n i t i a l i s e r i n g a f ACIA485 45 46 bsr i n i t d i s p l a y K a l d e r i n i t i a l i s e r i n g a f d i s p l a y 47 48 nop I n g e n t i n g 49 50 bsr T a b l e I n i t K a l d e r i n i t i a l i s e r i n g a f t a b e l l e r n e o v e r de p e r i f e r e e n h e d e r 51 bsr mainloop S t a r t e r hovedprogrammet 52 53 testloop : Gamle testfunktioner, b l i v e r ikke kaldt. 54 D e t t e e r e t e k s e m p e l på k a l d a f bus f u n k t i o n e n 55 move. l #0x130000, (%sp ) tempdata 56 move. w #70, (%sp ) data 57 move. w #1, (%sp ) i d 58 move. w #3, (%sp ) cmd 59 move. w #1, (%sp ) adr 60 bsr bus Når a l l e parametre er på stakken kaldes bus funktionen 147

F.1. ASSEMBLER-KODE TIL INITIALISERING AF HARDWARE MODUL 61 add. l #12,%sp Når den r e t u n e r e r g e n s k a b e s s t a k k e n 62 jmp t e s t L o o p 63 mbr1 : 64 trap #14 Gammelt Arne, s i k r e r at programmet ikke kører videre 65 jmp mbr1 66 67 i n i t r s 2 3 2 : 68 move. b #ACIA RESET, RS232 STATUS Resetter ACIA232 69 bsr mbrdelay Pause 70 move. b #ACIA DIV16+ACIA 8N1, RS232 STATUS S æ t t e r ACIA232 op t i l 16 d e l i n g a f c l o c k og 71 bsr mbrdelay Pause 72 move. b RS232 DATA,%d0 Henter a f f f a l d s data fra ACIA232, smides væk 73 r t s R e t u n e r e r 74 75 i n i t r s 4 8 5 : 76 move. b #ACIA RESET, RS485 STATUS Resetter ACIA485 77 bsr mbrdelay Pause 78 move. b #RS485 TX, RS485 STATUS Sætter ACIA485 op t i l at sende 79 bsr mbrdelay Pause 80 move. b RS485 DATA,%d0 Henter a f f f a l d s data fra ACIA485, smides væk 81 r t s R e t u n e r e r 82 83 i n i t d i s p l a y : 84 move. b #DISP RESET, DISP ADR Resetter display 85 bsr mbrdelay Pause 86 move. b #DISP RESET, DISP ADR Nogle display modeller skal r e s e t t e s tre gange 87 bsr mbrdelay Pause 88 move. b #DISP RESET, DISP ADR Resetter display 89 bsr mbrdelay Pause 90 move. b #DISP RESET, DISP ADR Sætter displayet op t i l 2 l i n j e r ( a 40 tegn ) og fonten t i l 5 x7dots 91 e r i d e n t i s k med r e s e t 92 bsr mbrdelay Pause 93 move. b #DISP ENTRY, DISP ADR Sætter d i s p l a y e t t i l at s k r i v e mod h ø j r e 94 bsr mbrdelay Pause 95 move. b #DISP ON, DISP ADR Tænder displayet, uden cursor 96 bsr mbrdelay Pause 97 move. b #DISP CLEAR, DISP ADR Overskriver displayet med ( mellemrum ), og hopper t i l 98 ø v e r s t e v e n s t r e h j ø r n e 99 bsr mbrdelay Pause 100 101 S k r i v welcome t i l d i s p l a y e t 102 l e a w e l c o m e s t r i n g,% a0 Får A0 t i l at pege på s t r e n g e n med t e k s t e n 103 move. l %a0, (%sp ) Kopierer pointeren t i l stakken, argument t i l funktionen p r i n t D i s p l a y 104 move. w #1, (%sp ) Kopierer linjenummer t i l stakken, argument t i l funktionen p r i n t D i s p l a y 105 j s r p r i n t D i s p l a y Kalder p r i n t D i s p l a y med p o i n t e r e n t i l w e l c o m e s t r i n g og 106 l i n j e n u m m e r 1 som argumenter 107 add. l #6,%sp F j e r n e r p a r a m e t r e n e f r a s t a k k e n 108 r t s 109 110 welcome string : 111. a s c i i Welcome D e f i n e r e r velkomstskærmen 112 113 114 mbrdelay : Funktion der l a v e r pause 115 move. l #0xFFFF,%d0 Loopet k ø r e s FFFF gange 116 loop : 117 tst. l %d0 118 dbeq %d0, l o o p Hvis D0 i k k e e r nul trækkes en f r a D0 og der s p r i n g e s t i l loop, 119 e l l e r s g å e s t i l næste l i n j e 120 r t s 121 122 123 i n t e r r u p t i n i t : Funktion t i l o p s æ t n i n g a f i n t e r r u p t t a b e l l e n 124 Den r i g t i g e i n t e r r u p t t a b e l l i g g e r på a d r e s s e r i ROM en 125 TS2 MON, der er brændt i ROM en, er l a v e t så der ved i n t e r r u p t s 126 s p r i n g e s t i l en t a b e l d e r l i g g e r f r a adr. 0 x40000 127 Den nye interrupt tabel l i g g e r i RAM og kan ændres i software 128 V e k t o r e r n e s nye a d r e s s e r kan b e r e g n e s ved : 129 ( vektor 8 bytes ) + 0x40000 130 I n t e r r u p t 1 har v e k t o r nummer 25 131 T a b e l l e n s æ t t e s a f TS2 MON op t i l at s p r i n g e t i l... 132 A d r e s s e r n e i d i s s e i n s t r u k t i o n e r o v e r s k r i v e s med de ø n s k e d e a d r e s s e r 133 134 move. l #dispdown, 0 x400ca Placerer adressen t i l dispdown, så der springes h e r t i l ved i n t e r r u p t 1 135 move. l #dispup, 0x400D2 Placerer adressen t i l dispup, så der springes h e r t i l ved interrupt 2 136 and.w #0b1111100011111111,% sr Fjerner interruptmasken, så a l l e interrupts kan udføres 137 138 r t s 148

APPENDIKS G. KILDEKODE TIL LØKKEPROCES Appendiks G Kildekode til løkkeproces Dette appendiks indeholder kildekoden for modulerne i masterens løkkeproces (se eventuelt figur 15.1 på side 81). G.1 Header-fil til lygtekontrolmodul I dette afsnit ses koden fra LightControlUnit.h indeholdende prototyperne til lygtekontrolmodulet. 1 void L i g h t C o n t r o l U n i t ( void ) ; G.2 C-kode til lygtekontrolmodul I dette afsnit ses C-koden fra LightControlUnit.c indeholdende styringen af den perifere enhed lygteenhed udfra lygtekontrollen. 1 #include Loop. h 2 #include T a b l e i n i t. h 3 #include bus. h 4 #include moduldisplay. h 5 / 1 1 s t a n d a r d s t r e n g e d e r k a n s k r i v e s f r a 6 d e t t e m o d u l / 7 char lightcontrolstring1 [ 2 0 ] = RespondError : Light ; 8 char lightcontrolstring2 [ 2 0 ] = Light stat. updated ; 9 char lightcontrolright [ 2 0 ] = Blinking : Right ; 10 char lightcontrolleft [ 2 0 ] = Blinking : Left ; 11 char lightcontroldip [ 2 0 ] = Dippedlight : ON ; 12 char lightcontrolhead [ 2 0 ] = Headlight : ON ; 13 char l i g h t C o n t r o l P o s [ 2 0 ] = P o s i t i o n l i g h t : ON ; 14 char lightcontrolwip1 [ 2 0 ] = Wiper : Slow ; 15 char lightcontrolwip2 [ 2 0 ] = Wiper : Fast ; 16 char lightcontrolbtn [ 2 0 ] = Dyt! Dyt! ; 17 char lightcontrolsos [ 2 0 ] = Red Alert! ; 18 19 void L i g h t C o n t r o l U n i t ( void ) { 20 extern char D i s p l a y L i g h t [ 2 1 ] ; / A r r a y med s t r i n g, d e r k a n s k r i v e s p å 21 d i s p l a y / 22 extern char D i s p l a y S t r i n g P o i n t e r ; / P o i n t e r d e r s e n d e s v i d e r e t i l d i s p S e t f u n k / 23 char L i g h t C o n t r o l S t a t u s ; / Var : T a b e l d a t a om l y g t e k o n t r o l / 24 char DummyVar ; / Var : Dummy v a r i a b e l / 25 i n t CheckData ; / Var : Er t r a n s m i s s i o n v e l l y k k e t? / 26 L i g h t C o n t r o l S t a t u s = ReadTable ( 1, 1 ) ; / I n d l æ s s t a t u s a f t a s t e r n e f r a t a b e l / 27 CheckData = bus ( 2, 1, 1, L i g h t C o n t r o l S t a t u s, DummyVar) ; / S e n d t a s t e r n e s s t a t u s t i l l y g t e r n e / 28 29 D i s p l a y S t r i n g P o i n t e r = s t r n c p y ( D i s p l a y L i g h t, l i g h t C o n t r o l S t r i n g 2, 2 0 ) ; 30 31 i f ( L i g h t C o n t r o l S t a t u s & 3 2 ) { / S p r i n k l e r a k t i v e r e t => s æ t d i s p l a y p o i n t e r / 32 D i s p l a y S t r i n g P o i n t e r = s t r n c p y ( D i s p l a y L i g h t, l i g h t C o n t r o l B t n, 2 0 ) ; 33 } 34 35 i f ( L i g h t C o n t r o l S t a t u s & 6 4 ) { / V i s k e r 1 a k t i v e r e t => s æ t d i s p l a y p o i n t e r / 36 D i s p l a y S t r i n g P o i n t e r = s t r n c p y ( D i s p l a y L i g h t, lightcontrolwip1, 2 0 ) ; 37 } 38 149

G.3. HEADER-FIL TIL OLIEKONTROLMODUL 39 i f ( L i g h t C o n t r o l S t a t u s & 1 ) { / P o s i t i o n l y s a k t i v e r e t => s æ t d i s p l a y p o i n t e r / 40 D i s p l a y S t r i n g P o i n t e r = s t r n c p y ( D i s p l a y L i g h t, l i g h t C o n t r o l P o s, 2 0 ) ; 41 } 42 43 i f ( L i g h t C o n t r o l S t a t u s & 2 ) { / N æ r l y s a k t i v e r e t => s æ t d i s p l a y p o i n t e r / 44 D i s p l a y S t r i n g P o i n t e r = s t r n c p y ( D i s p l a y L i g h t, l i g h t C o n t r o l D i p, 2 0 ) ; 45 } 46 47 i f ( L i g h t C o n t r o l S t a t u s & 1 2 8 ) { / V i s k e r 2 a k t i v e r e t => s æ t d i s p l a y p o i n t e r / 48 D i s p l a y S t r i n g P o i n t e r = s t r n c p y ( D i s p l a y L i g h t, lightcontrolwip2, 2 0 ) ; 49 } 50 51 i f ( L i g h t C o n t r o l S t a t u s & 4 ) { / F j e r n l y s a k t i v e r e t => s æ t d i s p l a y p o i n t e r / 52 D i s p l a y S t r i n g P o i n t e r = s t r n c p y ( D i s p l a y L i g h t, l i g h t C o n t r o l H e a d, 2 0 ) ; 53 } 54 55 i f ( L i g h t C o n t r o l S t a t u s & 8 ) { / H ø j r e B l i n k a k t i v e r e t => s æ t d i s p l a y p o i n t e r / 56 D i s p l a y S t r i n g P o i n t e r = s t r n c p y ( D i s p l a y L i g h t, l i g h t C o n t r o l R i g h t, 2 0 ) ; 57 } 58 59 i f ( L i g h t C o n t r o l S t a t u s & 1 6 ) { / V e n s t r e B l i n k a k t i v e r e t => s æ t d i s p l a y 60 p o i n t e r / 61 D i s p l a y S t r i n g P o i n t e r = s t r n c p y ( D i s p l a y L i g h t, l i g h t C o n t r o l L e f t, 2 0 ) ; 62 } 63 64 65 i f ( CheckData == 1 ) { / H v i s t r a n s m i s s i o n s f e j l i a f s e n d e l s e a f 66 t a s t e r n e s s t a t u s s e n d f e j l t i l d i s p l a y / 67 D i s p l a y S t r i n g P o i n t e r = s t r n c p y ( D i s p l a y L i g h t, l i g h t C o n t r o l S t r i n g 1, 2 0 ) ; 68 } 69 70 d i s p S e t ( 1, D i s p l a y S t r i n g P o i n t e r ) ; / S k r i v D i s p l a y S t r i n g P o i n t e r i e n t r y 1. 71 1 t a l l e t s k y l d e s a t o l i e e n h e d e n d e n n e a d r. / 72 } G.3 Header-fil til oliekontrolmodul I dette afsnit ses koden fra OilUnit.h indeholdende prototyperne til oliekontrolmodulet. 1 void O i l U n i t ( void ) ; G.4 C-kode til oliekontrolmodul I dette afsnit ses C-koden fra OilUnit.c indeholdende styringen af den perifere olieenhed. 1 #include Loop. h 2 #include T a b l e i n i t. h 3 #include moduldisplay. h 4 / 3 s t a n d a r d s t r e n g e d e r k a n s k r i v e s f r a 5 d e t t e m o d u l / 6 char l o w O i l [ 2 0 ] = LOW o i l p r e s s u r e : ; 7 char h i g h O i l [ 2 0 ] = HIGH o i l p r e s s u r e : ; 8 char n o r m a l O i l [ 2 0 ] = O i l p r e s s u r e : ; 9 10 11 void O i l U n i t ( void ) { 12 extern char D i s p l a y O i l [ 2 1 ] ; / A r r a y med s t r i n g, d e r k a n s k r i v e s p å 13 d i s p l a y a f o l i e k o n t r o l / 14 extern char DisplayStringPointer ; 15 unsigned char O i l S t a t u s ; / Var : T a b e l d a t a om o l i e e n h e d / 16 char DummyVar ; / Var : Dummy v a r i a b e l / 17 O i l S t a t u s = ReadTable ( 3, 1 ) ; / I n d l æ s s t a t u s a f o l i e t r y k k e t f r a t a b e l / 18 19 i f ( O i l S t a t u s < 50 ) { / O l i e t r y k k e t e r l a v t? s k r i v t i l d i s p. / 20 D i s p l a y S t r i n g P o i n t e r = s t r n c p y ( D i s p l a y O i l, l o w O i l, 2 0 ) ; / K o p i e r 2 0 k a r a k t e r e r f r a l o w o i l t i l 21 D i s p l a y O i l / 22 i n t I n s e r t ( O i l S t a t u s, D i s p l a y S t r i n g P o i n t e r +17) ; / C h a r T o I n t o g l i g v æ r d i e n i p o i n t e r +17 / 23 d i s p S e t ( 3, D i s p l a y S t r i n g P o i n t e r ) ; / S k r i v D i s p l a y S t r i n g P o i n t e r i e n t r y 3. 24 3 t a l l e t s k y l d e s a t o l i e e n h e d e n d e n n e a d r. / 25 } 26 e l s e i f ( O i l S t a t u s > 1 5 0 ) { / O l i e t r y k k e t e r h ø j t? s k r i v t i l d i s p. / 27 D i s p l a y S t r i n g P o i n t e r = s t r n c p y ( D i s p l a y O i l, highoil, 2 0 ) ; 28 i n t I n s e r t ( O i l S t a t u s, D i s p l a y S t r i n g P o i n t e r +17) ; 29 d i s p S e t (3, D i s p l a y S t r i n g P o i n t e r ) ; 30 } 31 e l s e { / O l i e t r y k n o r m a l t s k r i v t i l d i s p. / 32 D i s p l a y S t r i n g P o i n t e r = s t r n c p y ( D i s p l a y O i l, normaloil, 2 0 ) ; 33 i n t I n s e r t ( O i l S t a t u s, D i s p l a y S t r i n g P o i n t e r +17) ; 34 d i s p S e t (3, D i s p l a y S t r i n g P o i n t e r ) ; 35 } 36 } 150

APPENDIKS G. KILDEKODE TIL LØKKEPROCES G.5 Header-fil til løkkestyringsmodul I dette afsnit ses koden fra loop.h indeholdende prototyperne til løkkestyringsmodulet. 1 i n t l o o p ( void ) ; G.6 C-kode til løkkestyringsmodul I dette afsnit ses C-koden fra loop.c, hvor de perifere enheder evalueres efter tur. 1 #include Loop. h 2 #include T a b l e i n i t. h 3 #include lygtekontrolmodul. h 4 #include oliemodul. h 5 #include moduldisplay. h 6 7 char D i s p l a y L i g h t [ 2 1 ] = a a a a a a a a a a a a a a a a a a a a ; / A r r a y med s t r i n g, d e r k a n s k r i v e s p å 8 d i s p l a y a f l y g t e k o n t r o l / 9 char D i s p l a y O i l [ 2 1 ] = a a a a a a a a a a a a a a a a a a a a ; / A r r a y med s t r i n g, d e r k a n s k r i v e s p å 10 d i s p l a y a f o l i e k o n t r o l / 11 char D i s p l a y S t r i n g P o i n t e r ; / P o i n t e r d e r s e n d e s v i d e r e t i l d i s p S e t f u n k / 12 13 14 i n t mainloop ( void ) { 15 while ( 1 ) { 16 U p d a t e E n t i r e T a b l e ( ) ; / O p d a t e r h e l e t a b e l l e n / 17 L i g h t C o n t r o l U n i t ( ) ; / b e h a n d l i n g a f l y g t e k o n t r o l e n h e d o g 18 l y g t e e n h e d / 19 O i l U n i t ( ) ; / b e h a n d l i n g a f o l i e e n h e d / 20 } 21 } 151

APPENDIKS H. KILDEKODE TIL DISPLAYPROCES Appendiks H Kildekode til displayproces Dette appendiks indeholder kildekoden for modulerne i masterens displayproces (se eventuelt figur 15.1 på side 81). H.1 Header-fil til displaymodul I dette afsnit ses koden fra moduldisplay.h indeholdende prototyperne til displaymodulet. 1 void dispup ( void ) ; / P r o t o t y p e r f r a m o d u l D i s p l a y. c / 2 void dispdown ( void ) ; 3 void d i s p S e t ( i n t address, char t o P r i n t ) ; 4 char s t r n c p y ( char s, char ct, i n t n ) ; 5 void i n t I n s e r t ( unsigned char data, char t a r g e t ) ; 6 void d i s p S t a t u s U p d a t e ( void ) ; 7 8 void p r i n t D i s p l a y ( char l i n e, char t e x t ) ; / P r o t o t y p e r f r a m o d u l D i s p l a y A S M. asm / H.2 C-kode til displaymodul I dette afsnit ses C-koden fra moduldisplay.c. 1 #include moduldisplay. h 2 3 #d e f i n e n u m b e r O f f s e t 48 / D e t a n t a l som ASCI v æ r d i e n a f t a l l e n e l i g g e r o v e r d e t r e e l l e 4 10 s y s t e m s t a l / 5 6 / G l o b a l e v a r i a b l e / 7 i n t d i s p P l a c e m e n t = 1 ; / P l a c e r i n g e n a f d i s p l a y p o i n t e r e n / 8 char d i s p B a s e [ 1 2 8 ] ; / A r r a y a f p o i n t e r s t i l t e k s t s t r e n g e n e / 9 10 extern char S l a v e A l i v e [ ] ; / E x t e r n e g l o b a l e v a r i a b l e d e r b e n y t t e s / 11 extern char SlaveNumber ; 12 13 void dispup ( ) { / D e n n e f u n k t i o n k a l d e s v i a i n t e r r u p t 1. Da d e r b e n y t t e s 14 i n t e r r u p t, e r d e t n ø d v e n d i g t a t l a v e b a c k u p a f a l l e r e g i s t r e 15 i p r o c e s s o r e n i n d e n i n t e r r u p t a f v i k l e s o g g e n s t a b e d i s s e 16 e f t e r a f v i k l i g e n g e n a f i n t e r r u p t / 17 i n t b u f f e r [ 1 5 ] ; 18 short i n t o f f s e t ; 19 / A l l e r e g i s t r e i p r o c e s s o r f l y t t e s p å s t a c k e n i n d e n i n t e r r u p t 20 a f v i k l e s / 21 asm ( move. l %A0, 4(% a6 ) ) ; 22 asm ( move. l %A1, 8(% a6 ) ) ; 23 asm ( move. l %A2, 12(% a6 ) ) ; 24 asm ( move. l %A3, 16(% a6 ) ) ; 25 asm ( move. l %A4, 20(% a6 ) ) ; 26 asm ( move. l %A5, 24(% a6 ) ) ; 27 asm ( move. l %d0, 28(% a6 ) ) ; 28 asm ( move. l %d1, 32(% a6 ) ) ; 29 asm ( move. l %d2, 36(% a6 ) ) ; 30 asm ( move. l %d3, 40(% a6 ) ) ; 31 asm ( move. l %d4, 44(% a6 ) ) ; 32 asm ( move. l %d5, 48(% a6 ) ) ; 33 asm ( move. l %d6, 52(% a6 ) ) ; 34 asm ( move. l %d7, 56(% a6 ) ) ; 153

H.2. C-KODE TIL DISPLAYMODUL 35 36 d i s p P l a c e m e n t ++; 37 i f ( d i s p P l a c e m e n t >= SlaveNumber ) { / F o r s ø g e s d e r e r æ n d r e p å v i s n i n g e n i d i s p l a y o v e r d e t 38 a n t a l e n h e d e r d e r f a k t i s k s v a r e r p å b u s s e n? / 39 d i s p P l a c e m e n t = SlaveNumber 1; / C e l l e n i S l a v e A l i v e med h ø j e s t e a d r e s s e d e r s v a r e r p å b u s / 40 } 41 o f f s e t = S l a v e A l i v e [ d i s p P l a c e m e n t ] ; 42 p r i n t D i s p l a y ( 1, d i s p B a s e [ o f f s e t ] ) ; / P r i n t p å f ø r s t e l i n j e d e n s t r e n g som p o i n t e r e n i 43 d i s p B a s e [ o f f s e t ] p e g e r p å / 44 45 46 / A f v i k l i n g e n a f i n t e r r u p t f æ r d i g g e n s k a b d a t a i r e g i s t r e 47 f r a s t a c k / 48 asm ( move. l 4(%a6 ),%A0 ) ; 49 asm ( move. l 8(%a6 ),%A1 ) ; 50 asm ( move. l 12(%a6 ),%A2 ) ; 51 asm ( move. l 16(%a6 ),%A3 ) ; 52 asm ( move. l 20(%a6 ),%A4 ) ; 53 asm ( move. l 24(%a6 ),%A5 ) ; 54 asm ( move. l 28(%a6 ),%d0 ) ; 55 asm ( move. l 32(%a6 ),%d1 ) ; 56 asm ( move. l 36(%a6 ),%d2 ) ; 57 asm ( move. l 40(%a6 ),%d3 ) ; 58 asm ( move. l 44(%a6 ),%d4 ) ; 59 asm ( move. l 48(%a6 ),%d5 ) ; 60 asm ( move. l 52(%a6 ),%d6 ) ; 61 asm ( move. l 56(%a6 ),%d7 ) ; 62 asm ( u n l k %a6 ) ; 63 asm ( r t e ) ; / r t e = r e t u r n f r o m e x c e p t i o n b r u g e s n å r d e r r e t u r n e s 64 f r a i n t e r r u p t r o u t i n e r / 65 } 66 67 void dispdown ( ) { 68 char b u f f e r [ 1 5 ] ; 69 i n t o f f s e t ; 70 asm ( move. l %A0, 4(% a6 ) ) ; 71 asm ( move. l %A1, 8(% a6 ) ) ; 72 asm ( move. l %A2, 12(% a6 ) ) ; 73 asm ( move. l %A3, 16(% a6 ) ) ; 74 asm ( move. l %A4, 20(% a6 ) ) ; 75 asm ( move. l %A5, 24(% a6 ) ) ; 76 asm ( move. l %d0, 28(% a6 ) ) ; 77 asm ( move. l %d1, 32(% a6 ) ) ; 78 asm ( move. l %d2, 36(% a6 ) ) ; 79 asm ( move. l %d3, 40(% a6 ) ) ; 80 asm ( move. l %d4, 44(% a6 ) ) ; 81 asm ( move. l %d5, 48(% a6 ) ) ; 82 asm ( move. l %d6, 52(% a6 ) ) ; 83 asm ( move. l %d7, 56(% a6 ) ) ; 84 85 dispplacement ; 86 i f ( d i s p P l a c e m e n t <= 0 ) { / F o r s ø g e s d e r e r æ n d r e p å v i s n i n g e n i d i s p l a y u n d e r d e t 87 a n t a l e n h e d e r d e r f a k t i s k s v a r e r p å b u s s e n? / 88 d i s p P l a c e m e n t = 0 ; / C e l l e n i S l a v e A l i v e med m i n d s t e a d r e s s e d e r s v a r e r p å b u s / 89 } 90 o f f s e t = S l a v e A l i v e [ d i s p P l a c e m e n t ] ; 91 p r i n t D i s p l a y ( 1, d i s p B a s e [ o f f s e t ] ) ; 92 93 asm ( move. l 4(%a6 ),%A0 ) ; 94 asm ( move. l 8(%a6 ),%A1 ) ; 95 asm ( move. l 12(%a6 ),%A2 ) ; 96 asm ( move. l 16(%a6 ),%A3 ) ; 97 asm ( move. l 20(%a6 ),%A4 ) ; 98 asm ( move. l 24(%a6 ),%A5 ) ; 99 asm ( move. l 28(%a6 ),%d0 ) ; 100 asm ( move. l 32(%a6 ),%d1 ) ; 101 asm ( move. l 36(%a6 ),%d2 ) ; 102 asm ( move. l 40(%a6 ),%d3 ) ; 103 asm ( move. l 44(%a6 ),%d4 ) ; 104 asm ( move. l 48(%a6 ),%d5 ) ; 105 asm ( move. l 52(%a6 ),%d6 ) ; 106 asm ( move. l 56(%a6 ),%d7 ) ; 107 asm ( u n l k %a6 ) ; 108 asm ( r t e ) ; / r t e = r e t u r n f r o m e x c e p t i o n b r u g e s n å r d e r r e t u r n e s 109 f r a i n t e r r u p t r o u t i n e r / 110 } 111 112 113 114 void d i s p S e t ( i n t a d d r e s s, char t o P r i n t ) { / F u n k t i o n t i l a t o p r e t t e p o i n t e r e t i l s t r e n g e n e d e r s k a l 115 v i s e s p å d i s p l a y. D e n n e f u n k t i o n b e n y t t e s a f m o d u l e r n e i 116 h o v e d l ø k k e n a f p r o g r a m m e t / 117 118 dispbase [ address ] = toprint ; 119 } 120 121 void d i s p S t a t u s U p d a t e ( ) { / F u n k t i o n t i l a t o p d a t e r e l i n j e 1 i d i s l a y / 122 i n t o f f s e t ; 123 o f f s e t = S l a v e A l i v e [ d i s p P l a c e m e n t ] ; 124 p r i n t D i s p l a y ( 1, d i s p B a s e [ o f f s e t ] ) ; 125 126 } 127 128 129 char s t r n c p y ( char s, char ct, i n t n ) { / F u n k t i o n d e r k o p i e r e r n k a r a k t e r e r f r a s t r e n g c t o v e r i 130 s t r e n g s / 131 i n t i = 0 ; 132 while ( i < n ) { 133 ( s + i ) = ( c t + i ) ; 134 i ++; 135 } 136 return s ; 137 } 138 139 void i n t I n s e r t ( unsigned char data, char t a r g e t ) { / F u n k t i o n d e r o m d a n n e r e n c h a r t i l i n t e g e r o g h e r e f t e r 140 l a v e r dem t i l ASCI v æ r d i e r d e r k a n u d s k r i v e s t i l d i s p l a y / 141 i n t i = 0, j = 0, k =0; 154

APPENDIKS H. KILDEKODE TIL DISPLAYPROCES 142 143 i n t temp = ( i n t ) data ; / I n t e g e r t y p e c a s t f o r d i d e n s k a l k u n n e v æ r e n e g a t i v / 144 145 while ( temp >= 0 ) { / Tæl i o p f o r a t f i n d e h v o r m a n g e 1 0 0 d e r e r / 146 i ++; 147 temp = temp 1 0 0 ; 148 } 149 i ; 150 temp = data i 100; 151 152 while ( temp >= 0 ) { / Tæl j o p f o r a t f i n d e h v o r m a n g e 1 0 d e r e r / 153 j ++; 154 temp = temp 1 0 ; 155 } 156 j ; 157 temp = data i 100 j 1 0 ; 158 159 while ( temp >= 0 ) { / Tæl k o p f o r a t f i n d e h v o r m a n g e 1 d e r e r / 160 k++; 161 temp = temp 1 ; 162 } 163 k ; 164 165 166 t a r g e t = i + n u m b e r O f f s e t ; / D e r l æ g g e s 4 8 t i l v æ r d i e r n e t a l t o p o g p o i n t e r e n 167 m e d s e n d t s æ t t e s t i l d i s s e v æ r d i e r. Nu e r t a l l e n e 168 p o i n t e r e n p e g e r p å k l a r t i l a t b l i v e s k r e v e t t i l 169 d i s p l a y. / 170 ( t a r g e t + 1 ) = j + numberoffset ; 171 ( t a r g e t + 2 ) = k + numberoffset ; 172 } H.3 Assembler-kode til displaymodul I dette afsnit ses assembler-koden fra moduldisplayasm.asm. Denne kode indeholder funktionen printdisplay, der benyttes ved skrivning til displayet. 1 Denne f u n k t i o n p r i n t e r t i l d i s p l a y e t 2 C pr o t ot y p e : void p r i n t D i s p l a y ( char linenumber, char t o P r i n t ) ; 3 P r o t o t y p e n e r d e f i n e r e t i moduldisplay. h 4 5. t e x t 6. t y p e p r i n t D i s p l a y, @function 7. g l o b l p r i n t D i s p l a y 8 9 printdisplay : Funktionen der kaldes, hvis der skal s k r i v e s t i l display 10 l i n k %a6, #0 F ø r s t f l y t t e s a r g u m e n t e r n e t i l r e g i s t r e n e 11 move. b 9(%a6 ), %d0 linenumber l i g g e s i d0 12 move. l 10(% a6 ), %a1 P o i n t e r t o P r i n t l i g g e s i a1 13 c l r. b %d2 C l e a r d2, da denne s e n e r e b r u g e s t i l t æ l l e r e g i s t r e 14 d3 b e n y t t e s s e n e r e som temp r e g i s t r e 15 16 Nedenstående kode f i n d e r ud a f h v i l k e n l i n j e d e r ø n s k e s 17 skrevet t i l på display ( bruger linenumber argumentet i d0 ) 18 cmp. b #1,%d0 S k r i v e s d e r t i l l i n j e 1? 19 beq l i n e 1 20 cmp. b #2,%d0 S k r i v e s d e r t i l l i n j e 2? 21 beq l i n e 2 22 cmp. b #3,%d0 S k r i v e s d e r t i l l i n j e 3? 23 beq l i n e 3 24 move. b %d0, RS232 DATA 25 cmp. b #4,%d0 S k r i v e s d e r t i l l i n j e 4? 26 beq l i n e 4 27 28 p r i n t L o o p : Denne r u t i n e s k r i v e r t i l d i s p l a y e t 29 Det t e s t e s f ø r s t om d i s p l a y e t e r k l a r t i l a t modtage data 30 move. w DISP ADR,%d3 F l y t data f r a s t a t u s r e g i s t r e t a f d i s p l a y o v e r i d3 31 and. b #0b10000000,%d3 32 t s t. b %d3 Hvis MSB e r s a t i s t a t u s r e g i s t r e t v i l Z i c o n d i t i o n c o d e s 33 b l i v e c l e a r e d. Hivs MSB i k k e e r s a t i s t a t u s r e g i s t r e t v i l 34 Z i c o n d i t i o n c o d e s være 0. 35 bne printloop Hop t i l printloop, hvis Z = 0 i conditioncodes a l t s å 36 h v i s d i s p l a y i k k e e r k l a r t i l at modtage data. 37 38 39 move. b (%a1 ),DISP DATA Overfør den char a1 peger på t i l DISP DATA 40 add. l #1, %a1 41 add. b #1, %d2 T æ l l e s op t i l 20 42 cmp. b #20,%d2 Er a l l e 20 chars skrevet? 43 bne printloop Hvis ikke a l l e 20 chars er skrevet så hop t i l printloop 44 45 unlk %a6 46 r t s 47 48 49 50 Herunder s æ t t e s c u r s o r t i l den r i g t i g e l i n j e på d i s p l a y 51 a l t e f t e r hvad det medsendte argument linenumber var 52 s e d i s p l a y d a t a b l a d ( ks0066u. pdf ) s i d e 18 t a b l e 7 under 53 s e t DDRAM Address 54 l i n e 1 : 55 move. b #128,DISP ADR 56 jmp p r i n t L o o p 57 58 l i n e 2 : 59 move. b #168,DISP ADR 155

H.4. BEREGNING AF TIDSFORBRUG VED AFVIKLING AF INTERRUPT 60 jmp p r i n t L o o p 61 62 l i n e 3 : 63 move. b #148,DISP ADR 64 jmp p r i n t L o o p 65 66 l i n e 4 : 67 move. b #188,DISP ADR 68 jmp p r i n t L o o p H.4 Beregning af tidsforbrug ved afvikling af interrupt Herunder laves en overslagsberegning af tiden det tager at udføre et dispup-interrupt. Tidsforbruget skulle være det samme for dispdown, og inkluderer den tid det tager at opdatere displayet vha. printdisplay. Beregningerne er foretaget ud fra tabeller i [MC68000UM.pdf, 2005, s. 8.1]. Der tages udgangspunkt i et fast antal clock cycles for en instruktion, selvom antallet kan varierre en anelse afhængigt af de parametre instruktionens køres med. Optællingen af antal instruktioner og deres tidsvarighed er vist i tabel H.1. Heri er ikke medregnet den tid, hvor displayet ikke kan modtage data, og printdisplay derfor kører i en løkke. I optællingen er medtaget et gennemløb af al koden i dispup samt en udførelse af den tilhørende printdisplay. Instruktion dispup printdisplay 20 loop Total clock cycles clocks pr. Totalt antal n instruk. n instruk. n instruk. instruktion clock cycles add.b 1 20 8 160 add.l 1 20 12 240 addq.w 1 1 8 8 addq.l 1 1 8 8 and.b 1 20 8 160 beq* 1 1 10 10 bne* 2 40 10 400 clr.b 1 1 4 4 cmp.b 1 1 6 6 cmp.w 1 1 21 6 126 ext.w 3 3 4 12 jmp 1 1 21 6 126 jsr 1 1 16 16 lea 2 2 8 16 link 1 1 2 16 32 lsl 1 1 21 8 126 move.b 3 2 1 25 12 300 move.w 6 1 26 12 312 move.l 31 1 32 16 512 rte 1 1 20 20 rts 1 1 12 12 subq.w 1 1 4 4 tst.b 1 20 4 80 unlk 1 1 2 13 26 SUM: 2716 Tabel H.1: Beregning af tidsforbrug for dispup-interrupt. Markering med stjerne (*) betyder at tiden er taget fra BRA instruktionen. Søjlen benævnt 20 loop er fra printdisplay funktionen, hvori der skrives 20 bogstaver vha. en løkke. 156 Ud fra antallet af clock cycles kan den minimale tid for udførelsen af et dispup-interrupt beregnes: t interrupt = 2716 1 = 340 µs (H.1) 8 MHz

APPENDIKS H. KILDEKODE TIL DISPLAYPROCES Selve displayet har også en forsinkelse, idet denne tager 370 ns + 39 µs = 39.4 µs pr. karakter. De 380 ns er fra den ekstra forsinkelse indsat i DTACK -generatoren, se ligning (N.1) på side 179. De 39 µs stammer fra displayets write Data to RAM, hvilket findes i [ks0066.pdf, s. 18]. Der skal skrives i alt 20 karakterer, hvilket giver en forsinkelse på 20 39.4 µs = 788 µs. I alt vil et dispup-interrupt tage 340 µs + 788 µs = 1.13 ms. 157

APPENDIKS I. KILDEKODE TIL BUS- OG TABELMODULERNE Appendiks I Kildekode til bus- og tabelmodulerne Dette appendiks indeholder kildekode til bus- og tabelmodulerne i masteren (se eventuelt figur 15.1 på side 81). I.1 Header-fil til tabelmodulerne I dette afsnit ses koden fra table.h indeholdende prototyperne til tabelmodulerne. 1 i n t CheckAdr ( char adr ) ; 2 i n t T a b l e I n i t ( void ) ; 3 i n t UpdateTableAdr ( char adr ) ; 4 int UpdateEntireTable ( void ) ; 5 i n t WriteTable ( char adr, char id, char data ) ; 6 char ReadTable ( char adr, char id ) ; I.2 C-kode til tabelmodulerne I dette afsnit ses C-koden fra table.c indeholdende alle tabelrelaterede funktioner. 1 #include T a b l e i n i t. h 2 #include bus. h 3 4 char d a t a P o i n t e r [ 2 0 4 8 ] ; / G l o b a l v a r. : A r r a y t i l t a b e l / 5 char S l a v e A l i v e [ 1 2 9 ] ; / G l o b a l v a r. : A r r a y med a d r e s s e r d e r s v a r e r p å b u s / 6 char SlaveNumber =0; / G l o b a l v a r. : A n t a l l e t a f a d r e s s e r d e r s v a r e r p å b u s / 7 char SlaveCheck [ 1 2 9 ] ; / G l o b a l v a r. : T i l i n d i k a t i o n a f a d r e s s e r n e s s t a t u s : / 8 / A d r e s s e s v a r e r => S l a v e C h e c k [ a d r e s s e ] = 1 / 9 / A d r e s s e s v a r e r i k k e => S l a v e c h e c k [ a d r e s s e ] = 0 / 10 11 char ReadTable ( char adr, char i d ) { / F u n k. : Læs f r a t a b e l / 12 char data ; 13 data = datapointer [ adr 16 + id ] ; 14 return data ; 15 } 16 17 i n t WriteTable ( char adr, char id, char data ) { / F u n k. : S k r i v t i l t a b e l / 18 datapointer [ adr 16 + id ] = data ; 19 return 0 ; 20 } 21 22 i n t UpdateTableAdr ( char adr ) { / F u n k. : O p d a t e r e n a d r e s s e i t a b e l / 23 i n t id, i, CheckAdrValid ; / A d r e s s e f i n d e s i S l a v e A l i v e => C h e c k A d r V a l i d = 1 / 24 / A d r e s s e f i n d e s i k k e i S l a v e A l i v e => C h e c k A d r V a l i d = 0 / 25 char tempdata ; 26 CheckAdrValid = 0 ; 27 f o r ( i =0; i <SlaveNumber ; i ++){ / C h e c k om m e d s e n d t e a d r e s s e e r t i l s t e d e p å b u s s e n / 28 / om d e n f i n d e s i a r r a y S l a v e A l i v e [ ] / 29 i f ( S l a v e A l i v e [ i ] == adr ) 30 CheckAdrValid = 1 ; 31 } 32 i f ( CheckAdrValid == 1 ) { / H v i s m e d s e n d t e a d r e s s e e r t i l s t e d e p å b u s s e n s å / 33 / o p d a t e r a l l e i d p å d e n n e a d r e s s e / 34 f o r ( id =0; id <=15; id++){ 35 bus ( adr, 2, id, 0, &tempdata ) ; 36 datapointer [ adr 16 + id ] = tempdata ; 159

I.3. ASSEMBLER-KODE TIL BUSMODUL 37 } 38 } 39 40 return 0 ; 41 } 42 43 i n t U p d a t e E n t i r e T a b l e ( void ) { / F u n k. : O p d a t e r h e l e t a b e l l e n / 44 i n t i ; 45 f o r ( i =0; i < SlaveNumber ; i ++){ / G e n n e m l ø b S l a v e A l i v e a r r a y o g o p d a t e r a d r e s s e r h e r i / 46 UpdateTableAdr ( S l a v e A l i v e [ i ] ) ; 47 } 48 return 0 ; 49 } 50 51 52 i n t CheckAdr ( char adr ) { / F u n k. : C h e c k om e n a d r e s s e s v a r e r p å b u s s e n / 53 i n t ErrorCheck ; / I n t e t s v a r f r a a f s p u r g t a d r e s s e => E r r o r C h e c k = 1 / 54 char tempdata ; / S v a r f r a a d s p u r g t a d r e s s e => E r r o r C h e c k = 0 / 55 ErrorCheck = bus ( adr, 2, 0, 0, &tempdata ) ; 56 i f ( ErrorCheck!= 0 ) { 57 return 1 ; 58 } 59 e l s e { 60 return 0 ; 61 } 62 } 63 64 65 i n t T a b l e I n i t ( void ) { / F u n k. : O p r e t t a b e l / 66 i n t i ; 67 i n t address ; 68 i n t id ; 69 char tempdata ; 70 / I d e n n e d e l u n d e r s ø g e s h v i l k e a d r e s s e r d e r s v a r e r / 71 SlaveNumber =0; 72 f o r ( i =0; i <127; i ++){ / F i n d a d r e s s e r d e r s v a r e r o g a n t a l l e t a f d i s s e / 73 SlaveCheck [ i ] = CheckAdr ( i ) ; / Gem i S l a v e C h e c k om a d r e s s e i s v a r e r / 74 i f ( SlaveCheck [ i ] == 0 ) { / H v i s a d r e s s e i s v a r e r : / 75 S l a v e A l i v e [ SlaveNumber ]= i ; / S k r i v a d r e s s e i i c e l l e i a f S l a v e A l i v e / 76 SlaveNumber++; / F o r ø g S l a v e N u m b e r med 1 / 77 } 78 } 79 / I d e n n e d e l o p r e t t e s s e l v e t a b e l l e n / 80 a d d r e s s = 0 ; 81 while ( address <128){ 82 i f ( SlaveCheck [ a d d r e s s ] == 1 ) { / H v i s a d r e s s e n i k k e s v a r e r / 83 i d = 0 ; 84 while ( id <=15){ / O p d a t e r a l l e i d / 85 d a t a P o i n t e r [ a d d r e s s 16 + i d ] = 0 ; / S k r i v 0 i a l l e c e l l e r f o r i d p å d e n n e a d r e s s e / 86 i d ++; 87 } 88 } 89 i f ( SlaveCheck [ a d d r e s s ] == 0 ) { / H v i s a d r e s s e n s v a r e r / 90 i d = 0 ; 91 while ( id <=15){ / O p d a t e r a l l e i d / 92 bus ( a d d r e s s, 2, id, 0, &tempdata ) ; / H e n t d a t a f r a i d / 93 d a t a P o i n t e r [ a d d r e s s 16 + i d ] = tempdata ; / S k r i v d a t a t i l t a b e l / 94 i d ++; 95 } 96 } 97 a d d r e s s ++; 98 } 99 return 0 ; 100 } I.3 Assembler-kode til busmodul I dette afsnit ses assembler-koden fra busmodulet, indeholdende funktionen til kommunikation over bussen. 1 DEFINITIONER 2.EQU timeout, 141 Tiden der skal ventes på at modtage data 3.EQU nmb retry, 2 A n t a l l e t a f gange s u b r u t i n e n s k a l g e n t a g e s, h v i s i n t e r n e f e j l o p s t å r 4.EQU read delay, 0 x2f Tiden der ventes mellem der sendes og læses 5.EQU err cmd, 0 b1111 P e r i f e r e e n h e d e r s fejlkommando 6 7.EQU r s 4 8 5 s r, 0 x800000 A d r e s s e t i l RS485 a c i a e n s s t a t u s r e g i s t e r 8.EQU r s 4 8 5 d a t a, 0 x800002 A d r e s s e t i l RS485 a c i a e n s d a t a r e g i s t e r 9 10.EQU rs485 w, 1 Aciaens skrive bit 11.EQU r s 4 8 5 r, 0 A c i a e n s l æse b i t 12.EQU r s 4 8 5 p, 6 ACIAens p a r i t e t s f e j l b i t 13 14.EQU r s 4 8 5 t x, 0 b01011000 B i t m ø n s t r e t på ACIAens s t a t u s r e g i s t e r når d e t e r s a t op t i l a t s e n d e 15.EQU r s 4 8 5 r x, 0 b00011000 B i t m ø n s t r e t på ACIAens s t a t u s r e g i s t e r når d e t e r s a t op t i l a t modtage 16 17 18 FUNKTIONER 19 20. t e x t 21. even 22. g l o b a l bus 23. type bus, @function 24 bus : Denne s u b r u t i n e s æ t t e r parametrene samme t i l p r o t o k o l l e n s frame, s e n d e r den 25 modtager s v a r e t og f o r t o l k e r d e t 26 OR.W #0b0000011100000000,%SR Deaktiver interrupts ved at ændre supervisorens s t a t u s r e g i s t e r 27 LINK %A6,# 28 Da s t a c k p o i n t e r e n m u l i g v i s s k a l b e n y t t e s gennem r e s t e n a f s u b r u t i n e n, l a v e s 160

APPENDIKS I. KILDEKODE TIL BUS- OG TABELMODULERNE 28 en loka l stack t i l de backup af registrene, som input parametrene kan f i n d e s ud f r a 29 30 De l o k a l e r e g i s t r e s i k k e r h e d s k o p i e r e s t i l l o k a l s t a c k e n 31 MOVE. L %A0, 4(%A6 ) A d r e s s e r e g i s t e r 1 s i k k e r h e d s k o p i e r e s t i l l o k a l s t a c k e n 32 MOVE. L %D1, 8(%A6 ) D a t a r e g i s t e r 1 s i k k e r h e d s k o p i e r e s t i l l o k a l s t a c k e n 33 MOVE. L %D2, 12(%A6 ) D a t a r e g i s t e r 2 s k a l s i k k e r h e d s k o p i e r e s t i l l o k a l s t a c k e n 34 MOVE. L %D3, 16(%A6 ) D a t a r e g i s t e r 3 s k a l s i k k e r h e d s k o p i e r e s t i l l o k a l s t a c k e n 35 MOVE. L %D4, 20(%A6 ) D a t a r e g i s t e r 4 s k a l s i k k e r h e d s k o p i e r e s t i l l o k a l s t a c k e n 36 MOVE. L %D5, 24(%A6 ) D a t a r e g i s t e r 5 s k a l s i k k e r h e d s k o p i e r e s t i l l o k a l s t a c k e n 37 MOVE. L %D6, 28(%A6 ) D a t a r e g i s t e r 6 s k a l s i k k e r h e d s k o p i e r e s t i l l o k a l s t a c k e n 38 39 Input p a r a m e t r e n e h e n t e s i n d t i l de l o k a l e r e g i s t r e 40 MOVE.W 8(%A6 ),%D1 A d r e s s e n h e n t e s f r a s t a c k e n t i l d a t a r e g i s t e r 1 41 MOVE.W 10(%A6 ),%D2 Kommandoen h e n t e s f r a s t a c k e n t i l d a t a r e g i s t e r 2 42 MOVE.W 12(%A6 ),%D3 ID e t h e n t e s f r a s t a c k e n t i l d a t a r e g i s t e r 3 43 MOVE.W 14(%A6 ),%D4 Dataene h e n t e s f r a s t a c k e n t i l d a t a r e g i s t e r 4 44 MOVE. L 16(%A6 ),%A0 Return p o i n t e r e n h e n t e s f r a s t a c k e n t i l a d r e s s e r e g i s t e r 0 45 46 De tre bytes i framen gøres klar t i l at s k u l l e sendes 47 MOVE.B %D2,%D5 En a r b e j d s k o p i a f d a t a r e g i s t e r 2 f l y t t e s t i l 5 48 MULS #0x10,%D5 F l y t t e r de s i d s t e 4 b i t hen f o r r e s t i byten 49 ADD.B %D3,%D5 S æ t t e r de s i d s t e 4 b y t e i n d f r a d a t a r e g i s t e r 3 i d 50 MOVE.B %D5,%D2 Byte 2 i framen gemmes i d a t a r e g i s t e r 2 51 MOVE.B %D4,%D3 Byte 3 i framen f l y t t e s t i l d a t a r e g i s t e r 3 52 53 54 CLR.B %D4 S l e t d a t a r e g i s t e r 4, da d e t s k a l b r u g e s t i l a n t a l l e t a f g e n n e m k ø r s l e r 55 CLR.W %D5 Dataregister 5 s l e t t e s, da den fremover skal benyttes som t æ l l e r 56 ( Hvis t æ l l e r e n s k a l o v e r 2 5 5, s l e t t e s e t word ) 57 b u s l b l : ADD.B #1,%D4 Der l æ g g e s en t i l a n t a l l e t a f g e n n e m k ø r s l e r 58 MOVE.B %D1, r s 4 8 5 d a t a Den 1. b y t e i framen a d r e s s e n a f s e n d e s 59 BSR bus w Der u n d e r s ø g e s om bussen e r k l a r t i l kommunikation 60 MOVE.B %D2, r s 4 8 5 d a t a Den 2. b y t e i framen kommando og i d a f s e n d e s 61 BSR bus w Der u n d e r s ø g e s om bussen e r k l a r t i l kommunikation 62 MOVE.B %D3, r s 4 8 5 d a t a Den 3. b y t e i framen data a f s e n d e s 63 64 BSR bus w Der v e n t e s t i l byten e r a f s e n d t 65 MOVE.W #r e a d d e l a y,%d5 Indsæt t i d e n, der s k a l v e n t e s f ø r ACIAen s æ t t e s t i l at modtage 66 bus delay : TST.W %D5 Test hvad der s t å r i CCR 67 DBEQ %D5, b u s d e l a y Hvis d a t a r e g i s t e r 5 i k k e e r 0, s k a l d e r t r æ k k e s en f r a r e g i s t r e t og hoppe 68 op og t e s t e i g e n 69 MOVE.B #rs485 rx, r s 4 8 5 s r ACIAen sættes op t i l at modtage 70 71 Der s k a l nu v e n t e s på e t s v a r f r a den p e r i f e r e enhed 72 CLR.B %D0 Dataregister 4 s l e t t e s, da den fremover skal benyttes t i l at angive 73 h v o r v i d t en f e j l e r o p s t å e t ( 0 a n g i v e r k o r r e k t p r o g r a m k ø r s e l ) 74 BSR b u s r Den 1. b y t e i framen kommando og i d modtages 75 CMP.B %D2,%D6 Det u n d e r s ø g e s om den 1. modtagne b y t e e r l i g den 2. a f s e n d t e 76 BNE e r r d a t a Er de t o b y t e s i k k e l i g hinanden, hoppes t i l d a t a f e j l e r r d a t a 77 unit data : BSR bus r Den 2. byte i framen data / f e j l k o d e modtages 78 79 MOVE.B #nmb retry,%d4 Er subrutinen nået her t i l, skal den ikke gentages 80 JMP e x i t s r S u b r u t i n e n hopper t i l a f s l u t n i n g a f s u b r u t i n e n 81 82 83 err con : ADD. L #4,%A7 Da subrutine t i l datamodtagelse ( bus r ) blev afbrudt med timeout, f j e r n e s 84 s u b r u t i n e n s r e t u r a d r e s s e f r a s t a c k e n 85 MOVE.B #1,%D0 D a t a r e g i s t e r 4 s æ t t e s t i l 1, da en f e j l e r o p s t å e t 86 MOVE.B #4,%D6 Der blev ikke modtaget et svar indenfor den f a s t s a t t e tid hvilket angives 87 med f e j l k o d e 4 i d a t a r e g i s t e r 6 88 JMP e x i t s r S u b r u t i n e n hopper t i l a f s l u t n i n g a f s u b r u t i n e n 89 90 91 e r r d a t a : MOVE.B #1,%D0 D a t a r e g i s t e r 0 s æ t t e s t i l 1, da en f e j l e r o p s t å e t 92 DIVS #0x10,%D6 At de to bytes ikke er ens, kan skyldes, at enheden melder f e j l, hvilket er 93 a n g i v e t med en fejlkommando 94 CMP.B #err cmd,%d6 Der sammenlignes med fejlkommandoen i d a t a r e g i s t e r 6 95 BEQ unit data Hvis de er ens skal fejlkoden fra enheden hentes ind som normalt, hvorfor 96 der hoppes t i l normal s u b r u t i n e a f h a n d l i n g 97 BSR bus r Den 2. byte i framen modtages, men benyttes ikke 98 MOVE.B #5,%D6 De modtagne data s v a r e r i k k e o v e r e n s med de a f s e n d t e, h v i l k e t a n g i v e s med 99 f e j l k o d e 5 i d a t a r e g i s t e r 6 100 JMP e x i t s r S u b r u t i n e n hopper t i l a f s l u t n i n g a f s u b r u t i n e n 101 102 103 e r r p a r : ADD. L #4,%A7 Da s u b r u t i n e t i l d a t a m o d t a g e l s e ( b u s r ) b l e v a f b r u d t med p a r i t e t s f e j l, 104 f j e r n e s subrutinens returadresse fra stacken 105 CMP.B #1,%D0 Undersøg om der e r meldt f e j l 106 BEQ err par2 Hvis dette er t i l f æ l d e t er der t a l e om 2. byte i svaret og der hoppes over 107 b y t e m o d t a g e l s e n 108 MOVE.B #1,%D0 D a t a r e g i s t e r 0 s æ t t e s t i l 1, da en f e j l e r o p s t å e t 109 BSR bus r Den 2. byte i framen modtages, men benyttes ikke 110 e r r p a r 2 : MOVE.B #6,%D6 En b y t e i s v a r e t i n d e h o l d t e p a r i t e s f e j l, h v i l k e t a n g i v e s med f e j l k o d e 6 i 111 d a t a r e g i s t e r 6 112 JMP e x i t s r S u b r u t i n e n hopper t i l a f s l u t n i n g a f s u b r u t i n e n 113 114 115 e x i t s r : MOVE.B #r s 4 8 5 t x, r s 4 8 5 s r ACIAen s æ t t e s op t i l a t s e n d e 116 CMP.B #nmb retry,%d4 Sammenlign kørselsnummeret med grænsen 117 BLT b u s l b l Gentag subrutinen, hvis grænsen ikke er nået 118 119 MOVE.B %D6,(%A0 ) F l y t de modtagne data o v e r i a d r e s s e n som r e t u r n p o i n t e r e n i 120 a d r e s s e r e g i s t e r 1 p e g e r på 121 122 MOVE.L 4(%A6 ),%A0 A d r e s s e r e g i s t e r 1 s i k k e r h e d s k o p i e r e s t i l s t a k k e n 123 MOVE.L 8(%A6 ),%D1 D a t a r e g i s t e r 1 s i k k e r h e d s k o p i e r e s t i l s t a k k e n 124 MOVE.L 12(%A6 ),%D2 D a t a r e g i s t e r 2 s k a l s i k k e r h e d s k o p i e r e s t i l s t a k k e n 125 MOVE.L 16(%A6 ),%D3 D a t a r e g i s t e r 3 s k a l s i k k e r h e d s k o p i e r e s t i l s t a k k e n 126 MOVE.L 20(%A6 ),%D4 D a t a r e g i s t e r 4 s k a l s i k k e r h e d s k o p i e r e s t i l s t a k k e n 127 MOVE.L 24(%A6 ),%D5 D a t a r e g i s t e r 5 s k a l s i k k e r h e d s k o p i e r e s t i l s t a k k e n 128 MOVE.L 28(%A6 ),%D6 D a t a r e g i s t e r 6 s k a l s i k k e r h e d s k o p i e r e s t i l s t a k k e n 129 130 UNLK %A6 Den l o k a l e s t a c k p o i n t e r f j e r n e s 131 132 AND.W #0b1111100011111111,%SR Aktiver interrupts ved at ændre supervisorens s t a t u s r e g i s t e r 133 RTS Der v e n d e s t i l b a g e t i l s u b r u t i n e k a l d e r e n 161

I.3. ASSEMBLER-KODE TIL BUSMODUL 134 135 136 bus w : Denne s u b r u t i n e v e n t e r på at a c i a e n t i l RS485 e r f æ r d i g med at s k r i v e 137 b u s r e a d : BTST #rs485 w, r s 4 8 5 s r Aciaen e r f æ r d i g med a t s k r i v e, h v i s 2. b i t i dens s t a t u s r e g i s t e r i k k e e r 138 s a t, d e r f o r b i t t e s t e s d e t t e b i t. CCR a f s p e j l e r r e s u l t a t e t 139 BEQ bus read Hvis Z ikke er sat, skal rutinen prøves igen 140 RTS Der v e n d e s t i l b a g e t i l s u b r u t i n e k a l d e r e n 141 142 143 b u s r : Denne s u b r u t i n e v e n t e r på a t ACIA485 e r f æ r d i g med a t l æ s e f r a b u s s e n 144 b u s l i s t e n : ADD.W #1,%D5 Der t æ l l e s én op 145 CMP.W #timeout,%d5 Hvis der er t a l t t i l timeout, udløber svartiden 146 BGE e r r c o n S v a r t i d e n e r u d l ø b e t og d e r a f s l u t t e s med f e j l 147 BTST #r s 4 8 5 r, r s 4 8 5 s r Aciaen e r f æ r d i g med a t læse, h v i s 1. b i t i dens s t a t u s r e g i s t e r i k k e e r s a t 148 d e r f o r b i t t e s t e s d e t t e b i t. CCR a f s p e j l e r r e s u l t a t e t 149 BEQ b u s l i s t e n Hvis Z ikke er sat, skal rutinen prøves igen 150 MOVE.B rs485 data,%d6 Den 1. byte i framen kommando og id er modtaget og gemmes i 151 d a t a r e g i s t e r 6 152 BTST #r s 4 8 5 p, r s 4 8 5 s r Den modtagne b y t e i n d e h o l d e r en p a r i t e t s f e j l, h v i s 7. b i t i ACIAens 153 s t a t u s r e g i s t e r e r s a t, d e r f o r b i t t e s t e s d e t t e b i t. CCR a f s p e j l e r r e s u l t a t e t 154 BNE e r r p a r Hvis d e r e r o p s t å e t p a r i t e t s f e j l, hoppes d e r t i l a f s l u t n i n g 155 RTS Der v e n d e s t i l b a g e t i l s u b r u t i n e k a l d e r e n 162

APPENDIKS J. KILDEKODE TIL PERIFERE ENHEDER Appendiks J Kildekode til perifere enheder I dette appendiks ses kildekoden til de perifere enheder. I den første del er koden til lygtekontrolenheden vist i sin fulde længde sammen med den tilhørende header-fil. Disse to er næsten identiske med de tilsvarende filer til lygteenheden og olieenheden. Forskellen mellem lygtekontrolenheden og disse to er vist herefter som små programstykker, der skal erstatte koden til lygtekontrolenheden i linjerne nævnt i teksten dertil. For lygteenhedens vedkommende er det blot nogle få linjer i både C-filen og header-filen. For olieenheden vedkommende er der lidt mere kode til initialiseringen samt en ekstra funktion, der skal tilføjes i C-filen. I alle tilfælde er det beskrevet, hvilke linjer, der skal erstattes. J.1 Header-fil til lygtekontrolenhed Herunder ses header-filen lygtekontrolenhed.h. 1 2 3 / / ICC AVR a p p l i c a t i o n b u i l d e r : 19 04 2005 1 8 : 2 0 : 4 8 / / T a r g e t : 9 0 S 2 3 1 3 / / C r y s t a l : 3. 6 8 6 4 Mhz 4 5 / / HEADERS : 6 7 #include <io2313v. h> 8 #include <macros. h> 9 10 / / CONSTANTS : 11 12 / / I n d k o m m e n d e b y t e s 13 #d e f i n e DEVICE ADR 0b00000001 / / = 1 14 #d e f i n e GET VALUE CMD 0 b00000010 / / = 2 15 16 / / O u t g å e n d e b y t e s 17 #d e f i n e ERROR CMD 0 b00001111 / / = 1 5 18 #d e f i n e PARITY WRONG 0 b00000001 / / = 1 19 #d e f i n e CMD WRONG 0 b00000010 / / = 2 20 21 / / T i m e r s e t t i n g s : 22 #d e f i n e DELAY COUNTER 0 b00101000 / / t i m e r e n s k a l t æ l l e t i l 4 0. 23 24 / / S m a r t e f u n k t i o n e r t i l b i t m a n i p u l a t i o n. 25 #d e f i n e S e t B i t ( x, y ) ( x =(1<<y ) ) / / S æ t t e r e n e n k e l t b i t i e n b y t e. 26 #d e f i n e C l r B i t ( x, y ) ( x&= (1<<y ) ) / / R e s e t t e r e n e n k e l t b i t i e n b y t e. 27 #d e f i n e T o g g l e B i t ( x, y ) ( xˆ=(1<<y ) ) / / S k i f t e r e n b i t s v æ r d i t i l d e t m o d s a t t e. 28 #d e f i n e F l i p B i t ( x, y ) ( xˆ=(1<<y ) ) / / Samme som t o g g l e b i t. 29 #d e f i n e T e s t B i t ( x, y ) ( x&(1<<y ) ) / / R e t u r n e r e r 1, h v i s b i t e r s a t e l l e r s 0. 30 31 / / FUNCTION PROTOTYPES: 32 33 void p o r t i n i t ( void ) ; 34 void u a r t 0 i n i t ( void ) ; 35 void i n i t d e v i c e s ( void ) ; 36 unsigned char Rece iv eby te ( void ) ; 37 void TransmitByte ( unsigned char data ) ; 38 void t i m e r 0 i n i t ( void ) ; 39 40 unsigned char g e t p a r i t y b i t ( void ) ; 41 unsigned char c h e c k p a r i t y ( unsigned char, unsigned char ) ; 42 void m a k e p a r i t y ( unsigned char ) ; 43 unsigned char g e t a d c v a l u e ( void ) ; 44 void s e n d d a t a ( unsigned char, unsigned char ) ; 45 void enable MAX487 ( void ) ; 46 void disable MAX487 ( void ) ; 47 void delay UART ( void ) ; 163

J.2. C-KODE TIL LYGTEKONTROLENHED J.2 C-kode til lygtekontrolenhed Herunder ses filen lygtekontrolenhed.c. 1 2 3 #include l y g t e k o n t r o l e n h e d. h 4 5 unsigned char adr, a d r p a r i t y, c m d p a r i t y, d a t a p a r i t y ; / / A l l e e r u n s i g n e d c h a r, i d e t a l l e t a l 6 unsigned char cmd in, cmd id in, cmd id out ; / / e r 0 25 5. 7 unsigned char id, data in ; 8 9 void main ( void ) { 10 i n i t d e v i c e s ( ) ; / / I n i t i a l i s e r e r p o r t e, t i m e r o g UART... 11 12 / / H e r k ø r e r d e n s t o r e h o v e d l ø k k e 13 14 while ( 1 ) { 15 adr = 0 ; / / N u l s t i l a l l e v a r i a b e l e r h v e r g a n g 16 c m d i d i n = 0 ; / / l ø k k e n k ø r e s i g e n... 17 d a t a i n = 0 ; 18 c m d i d o u t = 0 ; 19 cmd in = 0 ; 20 i d = 0 ; 21 22 PORTD &= 0 b01111100 ; / / Sæt a l l e udgange på PORTD t i l 0! 23 / / H e r s t a r t e r d e t h e l e s å!! 24 adr = R e c e i v e B y t e ( ) ; / / M o d t a g d e t r e b y t e s u a n s e t hvem d e 25 a d r p a r i t y = g e t p a r i t y b i t ( ) ; / / e r t i l o g k o p i e r p a r i t e t s b i t s t i l 26 c m d i d i n = R e c e i v e B y t e ( ) ; / / s e n e r e k o n t r o l. 27 c m d p a r i t y = g e t p a r i t y b i t ( ) ; 28 d a t a i n = ReceiveByte ( ) ; 29 d a t a p a r i t y = g e t p a r i t y b i t ( ) ; 30 31 i f ( adr == DEVICE ADR) { / / H v i s a f d r e s s e n e r k o r r e k t, s å... 32 cmd in = ( c m d i d i n >> 4 ) ; / / cmd t a g e s u d a f c m d i d i n. 33 i d = ( c m d i d i n & 1 5 ) ; / / i d AND e s u d a f c m d i d i n. 34 35 i f ( c h e c k p a r i t y ( adr, a d r p a r i t y ) && c h e c k p a r i t y ( c m d i d i n, c m d p a r i t y ) && c h e c k p a r i t y ( d a t a i n, d a t a p a r i t y ) ) { 36 c m d i d o u t = (ERROR CMD << 4 ) ; / / ERROR CMD f l y t t e s p å p l a d s v e d 4 37 c m d i d o u t = ( c m d i d o u t i d ) ; / / l e f t s h i f t o g i d OR e s i n d. 38 s e n d d a t a ( c m d i d o u t, PARITY WRONG) ; / / S e n d d e t o b y t e s... 39 } 40 41 else i f ( cmd in == GET VALUE CMD) { 42 s e n d d a t a ( c m d i d i n, PINB ) ; / / S e n d d e t o b y t e s.. 43 C l r B i t (PORTD, 6 ) ; / / S l u k f o r PORTD6, h v i s d e n h a r v æ r e t 44 } / / t æ n d t t i d l i g e r e. 45 46 e l s e { 47 c m d i d o u t = (ERROR CMD << 4 ) ; / / ERROR CMD f l y t t e s p å p l a d s v e d 4 48 c m d i d o u t = ( c m d i d o u t i d ) ; / / l e f t s h i f t o g i d OR e s i n d.. 49 s e n d d a t a ( c m d i d o u t, CMD WRONG) ; / / o g s e n d d e t o b y t e s, o g.. 50 S e t B i t (PORTD, 6 ) ; / / tænd f o r PORTD6. 51 } 52 } 53 54 e l s e { 55 d e l a y u a r t ( ) ; / / H v i s i k k e a d r e s s e b y t e e r k o r r e k t, 56 } / / s å i n d s æ t d e l a y. 57 } 58 } 59 60 / / FUNCTIONS 61 62 void p o r t i n i t ( void ) { 63 PORTB = 0 b00000000 ; / / 0 = i n g e n p u l l u p / 1 = p u l l u p. 64 DDRB = 0 b00000000 ; / / 0 = i n p u t / 1 = o u t p u t. 65 PORTD = 0 b00000000 ; / / 0 = i n g e n p u l l u p / 1 = p u l l u p. 66 DDRD = 0 b01111100 ; / / 0 = i n p u t / 1 = o u t p u t. PD0 = RXD, PD1 = TXD, PD7 e k s i s t e r e r 67 } / / i k k e! 68 69 void u a r t 0 i n i t ( void ) { 70 UCR = 0 b00000000 ; / / d i s a b l e mens b a u d r a t e s æ t t e s. 71 UBRR = 0 b00000001 ; / / sæt baud r a t e t i l 115200 kb. 72 UCR = 0 b00011100 ; / / e n a b l e Tx + Rx 9 b i t. 73 } 74 75 void i n i t d e v i c e s ( void ) { 76 CLI ( ) ; / / d i s a b l e a l l e i n t e r r u p t s, mens d e r 77 p o r t i n i t ( ) ; / / i n i t i a l i s e r e s. 78 t i m e r 0 i n i t ( ) ; 79 u a r t 0 i n i t ( ) ; 80 81 MCUCR = 0 b00000000 ; / / MCU G e n e r a l C o n t r o l R e g i s t e r. I k k e s l e e p m o d e e l l e r IRQ s e n s e. 82 GIMSK = 0 b00000000 ; / / G e n e r a l I n t e r r u p t Mask R e g i s t e r. I n g e n IRQ. 83 TIMSK = 0 b00000000 ; / / T i m e r / C o u n t e r I n t e r r u p t Mask R e g i s t e r. I n g e n IRQ. 84 SEI ( ) ; / / r e e n a b l e i n t e r r u p t s. 85 } 86 87 void t i m e r 0 i n i t ( void ) { 88 TCCR0 = 0 b00000011 ; / / s t a r t t i m e r med p r e s c a l e 6 4. 89 TCNT0 = 0 b00000000 ; / / s e t c o u n t e r t i l n u l. 90 } 91 92 unsigned char Rece iv eby te ( void ) { 93 C l r B i t (PORTD, 3 ) ; / / S l u k f o r PORTD3 f r a d e n f o r r i g e r e c e i v e. 94 while (! ( USR & ( 1 << RXC) ) ) ; / / s å l æ n g e d a t a r e g i s t e r e t e r t o m t, s å v e n t h e r! 95 S e t B i t (PORTD, 3 ) ; / / Tænd f o r PORTD3 d e n s l u k k e s i g e n v e d n æ s t e r e c e i v e. 96 return UDR; / / r e t u r n e r d a t a f r a UART D a t a R e g i s t e r. 97 } 98 99 void TransmitByte ( unsigned char data ) { 100 while (! ( USR & ( 1 << UDRE) ) ) ; / / v e n t med a t s e n d e i n d t i l d e n f o r r i g e b y t e e r s e n d t! 164

APPENDIKS J. KILDEKODE TIL PERIFERE ENHEDER 101 UDR = data ; / / s t a r t t r a n s m i t i o n f r a UDR. 102 } 103 104 / / OTHER FUNCTIONS : ) 105 106 void s e n d d a t a ( unsigned char byte01, unsigned char byte02 ) { 107 108 m a k e p a r i t y ( b y t e 0 1 ) ; / / B e r e g n e r p a r i t e t e n t i l b y t e 0 1. 109 enable MAX487 ( ) ; / / E n a b l e r MAX487 k r e d s e n t i l a t s e n d e. 110 TransmitByte ( b y t e 0 1 ) ; / / S e n d e r f ø r s t e b y t e. 111 while (! ( USR & ( 1 << TXC) ) ) ; / / V e n t, i n d t i l T r a n s m i t C o m p l e t e ( TXC ) g å r h ø j. 112 S e t B i t (USR, TXC) ; / / R e s e t TXC i g e n d e n g ø r d e t i k k e s e l v! : ( 113 m a k e p a r i t y ( b y t e 0 2 ) ; / / B e r e g n e r p a r i t e t e n t i l b y t e 0 2. 114 TransmitByte ( b y t e 0 2 ) ; / / S e n d e r a n d e n b y t e. 115 disable MAX487 ( ) ; / / D i s a b l e r MAX487 i g e n. 116 } 117 118 unsigned char g e t p a r i t y b i t ( ) { 119 i f ( (UCR & 0 b00000010 ) == 0 ) { / / UCR b i t 1 e r i n d g å e n d e p a r i t e t s b i t... 120 return 0 ; / / r e t u r n e r e r d e n p å g æ l d e n d e v æ r d i. 121 } 122 e l s e { return 1 ; } 123 } 124 125 unsigned char check parity ( unsigned char byte value, unsigned char p a r i t y b i t v a l u e ) { 126 / / R e t u r n e r e r e t 1, h v i s d e r e r p a r i t e t s f e j l. 127 unsigned char tmp = 1, bitcount = 0, n = 0, b i t s = 0 ; 128 129 f o r ( n = 0 ; n < 8 ; n++){ / / B i t v i s k o n t r o l a f a l l e 8 b i t o g t æ l l e r 130 / / sammen i b i t c o u n t. 131 i f ( b y t e v a l u e & ( tmp << n ) ) { / / L a v e r l e f t s h i f t p å tmp, o g t æ l l e r 1 t a l l e r 132 b i t c o u n t ++; / / i b y t e v a l u e. 133 } 134 } 135 136 b i t s = b i t c o u n t + p a r i t y b i t v a l u e ; 137 138 i f ( T e s t B i t ( b i t s, 0 ) == 0 ) { / / T e s t e r b i t 0 p å d e t s a m l e d e a n t a l b i t s. H v i s 139 return 0 ; / / d e t e r h ø j t ( u l i g e t a l ), s å e r d e r p a r i t e t s f e j l. 140 } 141 e l s e { return 1 ; } 142 } 143 144 void m a k e p a r i t y ( unsigned char b y t e v a l u e ) { / / O p r e t t e r l i g e p a r i t e t t i l b y t e s, d e r s k a l 145 / / s e n d e s. 146 unsigned char tmp = 1, b i t c o u n t = 0, n = 0 ; 147 148 f o r ( n = 0 ; n < 8 ; n++){ / / B i t v i s k o n t r o l a f a l l e 8 b i t o g t æ l l e r 149 / / sammen i b i t c o u n t. 150 i f ( b y t e v a l u e & ( tmp << n ) ) { / / L a v e r l e f t s h i f t p å tmp, o g t æ l l e r 1 t a l l e r i 151 b i t c o u n t ++; / / b y t e v a l u e. 152 } 153 } 154 155 i f ( ( T e s t B i t ( b i t c o u n t, 0 ) ) == 0 ) { / / H v i s b i t c o u n t e r l i g e, r e t u r n e r 1 e l l e r s 0. 156 C l r B i t (UCR, 0 ) ; / / UCR b i t 0 e r u d g å e n d e p a r i t e t s b i t ( UCR b i t 1 e r 157 } / / t i l i n d g å e n d e ). 158 e l s e { S e t B i t (UCR, 0 ) ; } 159 } 160 161 void enable MAX487 ( void ) { 162 S e t B i t (PORTD, 2 ) ; / / Tænd f o r PORTD2 her er DE på MAX487 k o b l e t på. 163 } 164 165 void disable MAX487 ( void ) { 166 while (! ( USR & ( 1 << TXC) ) ) ; / / V e n t med a t d i s a b l e, i n d t i l T r a n s m i t C o m p l e t e 167 C l r B i t (PORTD, 2 ) ; / / ( TXC ) g å r h ø j, o g s l u k f o r PORTD2 i g e n. 168 S e t B i t (USR, TXC) ; / / TXC s k a l r e s e t t e s i g e n d e n g ø r d e t i k k e 169 } / / s e l v! : ( 170 171 void d e l a y u a r t ( void ) { / / L a v e r e f o r s i n k e l s e p å e f t e r f o r k e r t a d r. 172 unsigned char a ; / / Dummy v a r i a b l e. 173 TCNT0 = 0 b00000000 ; / / N u l s t i l t i m e r. 174 S e t B i t (PORTD, 5 ) ; / / Tænd f o r PORTD5. 175 while (TCNT0!= DELAY COUNTER) ; / / Tæl t i l DELAY COUNTER, o g d e r e f t e r... 176 C l r B i t (PORTD, 5 ) ; / / s l u k f o r PORTD5. 177 a = UDR; / / K o p i e r e r UDR b l o t f o r a t r e s e t t e RXC, e l l e r s 178 } / / m o d t a g e s e n f o r k e r t b y t e som a d r e s s e i n æ s t e 179 / / l ø k k e... J.3 C-kode til lygteenhed Til lygteenheden skal nedenstående programstykke erstatte linjerne 13 og 14 i lygtekontrolenhed.h. 14 #d e f i n e SET PORT CMD 0b00000001 / / = 1 15 #d e f i n e GET VALUE CMD 0 b00000010 / / = 2 Nedenstående programstykke erstatter linjerne 41 til 44 i lygtekontrolenhed.c. 41 e l s e i f ( cmd in == GET VALUE CMD) { / / D e n n e b r u g e s k u n é n g a n g v e d 165

J.4. C-KODE TIL OLIEENHED 42 / / o p r e t t e l s e a f t a b e l i m a s t e r. 43 s e n d d a t a ( c m d i d i n, d a t a i n ) ; / / S e n d d e t o b y t e s r e t u r, o g.. 44 C l r B i t (PORTD, 6 ) ; / / S l u k f o r PORTD6, h v i s d e n h a r v æ r e t 45 } / / t æ n d t t i d l i g e r e. 46 47 else i f ( cmd in == SET PORT CMD) { 48 PORTB = d a t a i n ; / / S æ t PORTB t i l v æ r d i e r n e i d a t a b y t e, 49 s e n d d a t a ( c m d i d i n, d a t a i n ) ; / / o g s e n d d e t o b y t e s r e t u r.. 50 C l r B i t (PORTD, 6 ) ; / / S l u k f o r PORTD6, h v i s d e n h a r v æ r e t 51 } / / t æ n d t t i d l i g e r e. J.4 C-kode til olieenhed Til olieenheden skal nedenstående programstykker erstatte linjerne 7 og 13 i lygtekontrolenhed.h. 7 #include <i o 8 5 3 5 v. h> / / I n k l u d e r e r d e f i n i t i o n e r f o r A T 9 0 S 8 5 3 5 13 #d e f i n e DEVICE ADR 0b00000011 / / 3 Nedenstående programstykke erstatter linje 42 i lygtekontrolenhed.c. 43 s e n d d a t a ( c m d i d i n, g e t a d c v a l u e ( ) ) ; / / H e n t v æ r d i f r a ADC o g s e n d d e t o b y t e s. Nedenstående programstykke erstatter linjerne 62 til 85 i lygtekontrolenhed.c. 63 void p o r t i n i t ( void ) { / / I n i t a l i s é r p o r t e 64 PORTA = 0 b00000000 ; / / Port A er s a t t i l a t være 0 65 DDRA = 0 b00000000 ; / / P o r t A s d a t a r e t n i n g e r s a t t i l i n d g a n g e 66 PORTB = 0 b00000000 ; / / Port B er s a t t i l a t være 0 67 DDRB = 0 b00000000 ; / / P o r t B s d a t a r e t n i n g e r s a t t i l i n d g a n g e 68 PORTC = 0 b11111111 ; / / P o r t C s s a t t i l a t v æ r e 2 5 5. Dvs, a t a l l e LEDS e r s l u k k e d e. 69 DDRC = 0 b11111111 ; / / P o r t C s d a t a r e t n i n g e r s a t t i l u d g a n g e 70 PORTD = 0 b00000000 ; / / Port D er s a t t i l a t være 0 71 DDRD = 0 b00000000 ; / / P o r t D s d a t a r e t n i n g e r s a t t i l i n d g a n g e 72 } 73 74 void a d c i n i t ( void ) { / / I n i t a l i s e r i n g a f AD c o n v e r t e r 75 ADCSR = 0 b00000000 ; / / D i s a b l e f o r ADC 76 ADMUX = 0 b00000000 ; / / V æ l g i n d g a n g 0 ( ADC0 ) 77 ADCSR = 0 b10000001 ; / / E n a b l e ADC, s a t t i l e n k e l t k o n v e r t e r i n g, i n t e r r u p t s l å e t f r a. 78 } 79 80 void i n i t d e v i c e s ( void ) / / I n i t a l i s e r i n g a f a l l e e n h e d e r. 81 { 82 CLI ( ) ; / / d i s a b l e a l l e i n t e r r u p t s. 83 p o r t i n i t ( ) ; / / K a l d p o r t i n i t. 84 a d c i n i t ( ) ; / / k a l d ADC i n i t. 85 u a r t 0 i n i t ( ) ; / / K a l d UART i n i t. 86 t i m e r 0 i n i t ( ) ; / / K a l d t i m e r i n i t. 87 88 MCUCR = 0 b00000000 ; / / MCU C o n t r o l R e g i s t e r. D i s a b l e r S l e e p o g a l l e i n t e r r u p t f u n k t i o n e r 89 GIMSK = 0 b00000000 ; / / G e n e r a l I n t e r r u p t Mask R e g i s t e r. A l l e e k s t e r n e i n t e r r u p t s s l å e t f r a. 90 TIMSK = 0 b00000000 ; / / T i m e r c o u n t e r I n t e r r u p t Mask R e g i s t e r. A l l e t i m e r i n t e r r u p t s s l å e t f r a. 91 } 92 void u a r t 0 i n i t ( void ) { 93 UCR = 0 b00000000 ; / / d i s a b l e mens b a u d r a t e s æ t t e s. 94 UBRR = 0 b00000001 ; / / sæt baud r a t e t i l 115200 kb. 95 UCR = 0 b00011100 ; / / e n a b l e Tx + Rx 9 b i t. 96 } Nedenstående programstykke tilføjes efter linje 105 i lygtekontrolenhed.c. 117 unsigned char g e t a d c v a l u e ( void ) { 118 unsigned i n t ad ; 119 unsigned char pressure ; 120 unsigned char l e d ; / / S æ t b i t t e t ADSC ( ADC S t a r t C o n v e r s i o n ) i ADCSR 121 S e t B i t (ADCSR, ADSC) ; / / ( ADC S t a t u s R e g i s t e r ) r e s g i s t r e t. 166

APPENDIKS J. KILDEKODE TIL PERIFERE ENHEDER 122 while (! ( T e s t B i t (ADCSR, ADSC) ) ) ; / / V e n t på, a t ADSC g å r l a v, n å r k o n v e r t e r i n g e r s l u t. 123 ad = ADC; / / K o p i é r r e s u l t a t e t t i l a d. nu e r 0 < a d < 1 0 2 4. 124 p r e s s u r e = ( ad >> 2 ) ; / / p r e s s u r e = a d / 4. 125 l e d = ( p r e s s u r e >> 5 ) ; / / l e d = p r e s s u r e / 3 2 (= a d / 1 2 8 ). 126 PORTC = 2 5 5 ; / / s l u k a l l e LEDS p å PORTC. 127 C l r B i t (PORTC, l e d ) ; / / t æ n d d e n LED som a d r e p r æ s e n t e r e r ( 0... 7 ) 128 return pressure ; 129 } 167

APPENDIKS K. KILDEKODE TIL TESTSOFTWARE Appendiks K Kildekode til testsoftware Dette appendiks indeholder kildekoden til det benyttede testsoftware. K.1 C-kode til test af software i minimumsystemet I dette afsnit ses C-koden til prototype funktionerne fra prototypes.c. Disse er benyttet til modultests i minimumsystemet efter SPU-modellens foreskrifter. 1 #include < s t d l i b. h> 2 #include <stdio. h> 3 4 char r e t u r n D a t a ( char adr, char i d ) { / F u n k. : O p s l a g i t a b e l / 5 char data ; 6 char d a t a P o i n t e r ; / P o i n t e r t i l t a b e l / 7 d a t a P o i n t e r = ( char ) m a l l o c ( 2 0 4 8 s i z e o f ( char ) ) ; / O p r e t t e l s e a f t a b e l / 8 i n t i = 0 9 i n t j = 0 ; 10 i n t sum = 2 0 4 8 ; 11 12 13 i f ( ( adr >= 1 2 6 ) ( i d > 1 6 ) ) { / C h e c k om g y l d i g a d r e s s e som i n p u t / 14 p r i n t f ( ERROR in returndata call, 0 < adr < 128, 0 < id < 16\n ) ; 15 e x i t ( 1 ) ; 16 } 17 18 while ( i <128){ / F y l d t a b e l med t a l / 19 j = 0 ; / I t a b e l c e l l e r f o r e n a d r e s s e s t å r 20 v æ r d i e n f o r a l l e i d s t i l a t v æ r e 21 n u m m e r e t a f a d r e s s e n / 22 while ( j < 1 6 ) { 23 d a t a P o i n t e r [ i 16 + j ] = i ; 24 j ++; 25 } 26 i ++; 27 } 28 sum = (16 adr + i d ) ; / H v o r s k a l d e r s l å s o p i t a b e l / 29 data = &d a t a P o i n t e r [ sum ] ; / S l å r o p i t a b e l / 30 return data ; 31 } 32 33 char w r i t e T a b l e ( char adr, char id, char data ) { / F u n k. : S k r i v n i n g t i l t a b e l / 34 i f ( ( adr >= 1 2 6 ) ( i d > 1 6 ) ) { / C h e c k om g y l d i g a d r e s s e som i n p u t / 35 p r i n t f ( ERROR in writetable call, 0 < adr < 128, 0 < id < 16\n ) ; 36 return 1 ; 37 } / L a d som om d e r e r s k r e v e t t i l t a b e l / 38 p r i n t f ( Wrote to table address %d, ID : %d and data %d\n, adr, id, data ) ; 39 return 0 ; 40 } 41 42 char bus ( char adr, char id, char cmd, char data, char rtn data ) { / Funk. : Send d a t a o v e r bus / 43 char d a t a P o i n t e r ; / P o i n t e r t i l t a b e l / 44 d a t a P o i n t e r = ( char ) m a l l o c ( 2 0 4 8 s i z e o f ( char ) ) ; / O p r e t t e l s e a f t a b e l / 45 46 i f ( ( adr > 1 2 6 ) ( i d > 1 6 ) ) { / C h e c k om g y l d i g a d r e s s e som i n p u t / 47 p r i n t f ( ERROR in bussend call, 0 < adr < 128, 0 < id < 16\n ) ; 48 return 1 ; 49 } 50 51 while ( i <128){ / F y l d t a b e l med t a l / 52 j = 0 ; / I t a b e l c e l l e r f o r e n a d r e s s e s t å r 53 v æ r d i e n f o r a l l e i d s t i l a t v æ r e 54 n u m m e r e t a f a d r e s s e n / 55 while ( j < 1 6 ) { 56 d a t a P o i n t e r [ i 16 + j ] = i ; 57 j ++; 58 } 169

K.2. C-KODE TIL TEST AF A/D CONVERTER I OLIEENHED 59 i ++; 60 } 61 switch ( cmd ) { / S w i t c h e f t e r m o d t a g n e cmd i n p u t / 62 case 1 : / S e p r o t o k o l f o r k o m m a n d o e r / 63 p r i n t f ( S e t t i n g b i n a r y v a l u e %d, a t adr : %d ID : %d\n, data, adr, i d ) ; 64 break ; 65 66 case 2 : 67 p r i n t f ( G e t t i n g b i n a r y v a l u e %d, a t adr : %d ID : %d\n, d a t a P o i n t e r [ adr 16+ i d ], adr, i d ) ; 68 p r i n t f ( h e r t i l \n ) ; 69 rtn data = datapointer [ adr 16+ id ] ; 70 break ; 71 case 3 : 72 data = datapointer [ adr 16+ id ] ; 73 p r i n t f ( G e t t i n g pin s t a t u s a t adr : %d, ID : %d\n, adr, i d ) ; 74 rtn data = datapointer [ adr 16+ id ] ; 75 break ; 76 case 4 : 77 p r i n t f ( Running f u n c t i o n a t adr : %d, ID : %d\n, adr, i d ) ; 78 break ; 79 case 5 : 80 p r i n t f ( Making AND f u n c t i o n a t adr : %d, ID : %d\n, adr, i d ) ; 81 break ; 82 case 6 : 83 p r i n t f ( Making OR f u n c t i o n a t adr : %d, ID : %d\n, adr, i d ) ; 84 break ; 85 case 7 : 86 p r i n t f ( Making XOR f u n c t i o n a t adr : %d, ID : %d\n, adr, i d ) ; 87 break ; 88 case 1 5 : 89 p r i n t f ( E r r o r! \ n ) ; 90 break ; 91 default : 92 p r i n t f ( No such f u n c t i o n i n bus cmds ) ; 93 return 1 ; 94 break ; 95 } 96 return 0 ; 97 } 98 99 char e r r o r M e s s a g e ( char s t r i n g ) { / F u n k. : S k r i v e r r o r m s g t i l d i s p l a y / 100 p r i n t f ( P r i n t i n g e r r o r message t o d i s p l a y : \ n %s \n, s t r i n g ) ; 101 return 0 ; 102 } 103 104 void d i s p S e t ( char adr, char s t r i n g ) { / F u n k. : S k r i v t i l d i s p l a y / 105 p r i n t f ( \n P r i n t e d t o d i s p l a y : \n %s \n, s t r i n g ) ; 106 } K.2 C-kode til test af A/D converter i olieenhed I dette afsnit ses C-koden fra olieenhedtst.c til test af A/D converteren i olieenheden. 1 #include <i o 8 5 3 5 v. h> / / I n k l u d e r e r d e f i n i t i o n e r f o r A T 9 0 S 8 5 3 5 2 #include <macros. h> / / I n k l u d e r e r d i v e r s e p r a k t i s k e r e d s k a b e r. 3 4 #d e f i n e S e t B i t ( x, y ) ( x =(1<<y ) ) / / S æ t t e r e n e n k e l t b i t i e n b y t e. 5 #d e f i n e C l r B i t ( x, y ) ( x&= (1<<y ) ) / / R e s e t t e r e n e n k e l t b i t i e n b y t e. 6 #d e f i n e T o g g l e B i t ( x, y ) ( xˆ=(1<<y ) ) / / S k i f t e r e n b i t s v æ r d i t i l d e t m o d s a t t e. 7 #d e f i n e F l i p B i t ( x, y ) ( xˆ=(1<<y ) ) / / Samme som t o g g l e b i t. 8 #d e f i n e T e s t B i t ( x, y ) ( x&(1<<y ) ) / / R e t u r n e r e r 1, h v i s b i t e r s a t e l l e r o m v e n d t. 9 10 void p o r t i n i t ( void ) { / / I n i t a l i s é r p o r t e 11 PORTA = 0 x00 ; / / P o r t A e r s a t t i l a t v æ r e 0 12 DDRA = 0 x00 ; / / P o r t A s d a t a r e t n i n g e r s a t t i l i n d g a n g e 13 PORTB = 0 x00 ; / / P o r t B e r s a t t i l a t v æ r e 0 14 DDRB = 0 x00 ; / / P o r t B s d a t a r e t n i n g e r s a t t i l i n d g a n g e 15 PORTC = 0xFF ; / / P o r t C s s a t t i l a t v æ r e 2 5 5. 16 DDRC = 0xFF ; / / P o r t C s d a t a r e t n i n g e r s a t t i l u d g a n g e 17 PORTD = 0 x00 ; / / P o r t D e r s a t t i l a t v æ r e 0 18 DDRD = 0 x00 ; / / P o r t D s d a t a r e t n i n g e r s a t t i l i n d g a n g e 19 } 20 21 void a d c i n i t ( void ) { / / ADC i n i t i a l i z e I n i t a l i s e r i n g a f AD c o n v e r t e r. 22 ADCSR = 0 x00 ; / / D i s a b l e f o r ADC 23 ADMUX = 0 x00 ; / / V æ l g i n d g a n g 0 ( ADC0 ) 24 ADCSR = 0 x81 ; / / E n a b l e ADC, s a t t i l e n k e l t k o n v e r t e r i n g, 25 } / / o g i n t e r r u p t s l å e t f r a. 26 27 void i n i t d e v i c e s ( void ) { / / I n i t a l i s e r i n g a f a l l e e n h e d e r. 28 CLI ( ) ; / / D i s a b l e a l l e i n t e r r u p t s. 29 p o r t i n i t ( ) ; / / K a l d p o r t i n i t. 30 a d c i n i t ( ) ; / / K a l d ADC i n i t. 31 32 MCUCR = 0 x00 ; / / MCU C o n t r o l R e g i s t e r. D i s a b l e r S l e e p o g a l l e i n t e r r u p t f u n k t i o n e r 33 GIMSK = 0 x00 ; / / G e n e r a l I n t e r r u p t Mask R e g i s t e r. A l l e e k s t e r n e i n t e r r u p t s s l å e t f r a. 34 TIMSK = 0 x00 ; / / T i m e r c o u n t e r I n t e r r u p t Mask R e g i s t e r. A l l e t i m e r i n t e r r u p t s 35 / / s l å e t f r a. 36 } 37 38 void main ( void ) { 39 40 unsigned i n t ad ; / / a d v a r i a b e l b r u g e s t i l v æ r d i h e n t e t f r a AD c o n v e r t e r. 41 i n i t d e v i c e s ( ) ; / / k a l d a l l e i n i t a l i s e r i n g s r u t i n e r. 42 43 while ( 1 ) { / / k ø r a l t i d. 44 S e t B i t (ADCSR, ADSC) ; / / S æ t b i t t e t ADSC ( ADC S t a r t C o n v e r s i o n ) i ADCSR 45 / / ( ADC S t a t u s R e g i s t e r ) r e s g i s t r e t. 46 while (! ( T e s t B i t (ADCSR, ADSC) ) ) ; / / ADSC g å r l a v n å r k o n v e r t e r i n g e r s l u t. V e n t p å d e t. 47 ad = ADC; / / K o p i é r r e s u l t a t e t o v e r i v a r i a b l e n a d. 48 / / a d i n d e h o l d e r nu e t t a l i m e l l e m 0 o g 1 0 2 4. 170

APPENDIKS K. KILDEKODE TIL TESTSOFTWARE 49 ad = ad / 1 2 8 ; / / 1 0 2 4 / 1 2 8 = 8 50 PORTC = 2 5 5 ; / / s l u k a l l e LEDS. 51 C l r B i t (PORTC, ad ) ; / / t æ n d d e n LED som a d r e p r æ s e n t e r e r ( 0.. 7 ) 52 } / / s t a r t f o r f r a. 53 } K.3 C-kode til test af RS485 i de perifere enheder I dette afsnit ses C-koden fra olieenhedtst.c til test af RS485 i de perifere enhed. 1 2 #include <io8535v. h> 3 #include <macros. h> 4 5 #d e f i n e S e t B i t ( x, y ) ( x =(1<<y ) ) 6 #d e f i n e C l r B i t ( x, y ) ( x&= (1<<y ) ) 7 #d e f i n e T o g g l e B i t ( x, y ) ( xˆ=(1<<y ) ) 8 #d e f i n e F l i p B i t ( x, y ) ( xˆ=(1<<y ) ) 9 #d e f i n e T e s t B i t ( x, y ) ( x&(1<<y ) ) 10 11 unsigned char byte ; 12 unsigned char t ; 13 14 unsigned char Rece iv eby te ( void ) 15 { 16 while (! ( USR & ( 1 << RXC) ) ) ; / / s å l æ n g e d a t a r e g i s t e r e t e r t o m t, s å v e n t h e r! 17 return UDR; / / r e t u r n e r d a t a f r a UART D a t a R e g i s t e r. 18 } 19 20 void TransmitByte ( unsigned char data ) 21 { 22 while (! ( USR & ( 1 << UDRE) ) ) ; / / v e n t med a t s e n d e i n d t i l d e n f o r r i g e b y t e e r s e n d t! 23 UDR = data ; / / s t a r t t r a n s m i t i o n f r a UDR. 24 } 25 26 27 void p o r t i n i t ( void ) 28 { 29 PORTB = 0 b00000000 ; / / 0 = i n g e n p u l l u p / 1 = p u l l u p. 30 DDRB = 0 b00000000 ; / / 0 = i n p u t / 1 = o u t p u t 31 PORTD = 0 b00000000 ; / / 0 = i n g e n p u l l u p / 1 = p u l l u p. 32 DDRD = 0 b01111100 ; / / 0 = i n p u t / 1 = o u t p u t. PD0 = RXD, PD1 = TXD, PD7 e k s i s t e r e r i k k e! 33 } 34 35 void u a r t 0 i n i t ( void ) { 36 UCR = 0 b00000000 ; / / d i s a b l e UARTmens b a u d r a t e s æ t t e s. 37 UBRR = 0 b00000001 ; / / s æ t b a u d r a t e t i l 1 1 5 2 0 0 b p s. 38 UCR = 0 b00011000 ; / / e n a b l e UART med Tx, Rx o g 8 b i t. 39 } 40 void i n i t d e v i c e s ( void ) { 41 CLI ( ) ; / / d i s a b l e a l l e i n t e r r u p t s, mens d e r i n i t i a l i s e r e s. 42 p o r t i n i t ( ) ; 43 u a r t 0 i n i t ( ) ; 44 45 MCUCR = 0 x00 ; / / MCU G e n e r a l C o n t r o l R e g i s t e r. I k k e s l e e p m o d e e l l e r IRQ s e n s e. 46 GIMSK = 0 x00 ; / / G e n e r a l I n t e r r u p t Mask R e g i s t e r. I n g e n IRQ. 47 TIMSK = 0 x00 ; / / T i m e r / C o u n t e r I n t e r r u p t Mask R e g i s t e r. I n g e n IRQ. 48 SEI ( ) ; / / r e e n a b l e i n t e r r u p t s. 49 } 50 51 52 53 void main ( void ) { 54 i n i t d e v i c e s ( ) ; / / I n i t i a l i s e r e r p o r t e, t i m e r o g UART... 55 56 while ( 1 ) / / Kør a l t i d 57 { 58 b y t e=r e c e i v e B y t e ( ) ; / / M o d t a g e n b y t e, p u t d e n i n d i ADR 59 60 S e t B i t (PORTD, 2 ) ; / / S k i f t t i l s e n d e m o d u s p å R S 4 8 5 t r a n s c e i v e r 61 PORTC=0; / / Tænd LEDS s å d e t s e s a t d e r s e n d e s 62 f o r ( t =1; t ; t++) ; 63 TransmitByte ( b y t e +1) ; / / S e n d e n b y t e med v æ r d i e n b y t e +1 a s c i i! 64 65 while (! ( T e s t B i t (USR,TXC) ) ) ; / / V e n t p å d e n b l i v e r f æ r d i g med a t s e n d e 66 67 S e t B i t (USR,TXC) ; / / R e s e t T r a n s m i t C o m p l e t e f l a g 68 f o r ( t =1; t ; t++) ; 69 C l r B i t (PORTD, 2 ) ; / / S k i f t t i l m o d t a g e m o d u s p å R S 4 8 5 t r a n s c e i v e r 70 PORTC=255; / / S l u k LEDS s å d e s e s a t d e r m o d t a g e s 71 } 72 } 171

APPENDIKS L. MÅLEJOURNAL FOR CLOCK-GENERATORER Appendiks L Målejournal for clock-generatorer Formål Formålet med denne målejournal er at verificere, om clock-generatorerne til ACIA485, ACIA232 og M68k lever op til de krav, der stilles til dem jvf. de respektive datablade. Der måles på frekvens f, rise time t rise og fall time t fall og pulsvidde t pulse. De tre sidste stilles der krav til for, at enhederne vil opfatte flanker og signaler korrekt. Screenshots af samtlige målinger findes på CD-ROM en i [bilag/målinger/oscillatorer]. Apparaturliste Der er i målingerne benyttet apparatur jvf. tabel L.1. Måleopstilling Der er anvendt samme måleopstilling til måling på alle tre clock-kredsløb. Opstillingen fremgår af figur L.1. Her figurerer tre oscilloskoper, men det er det samme oscilloskop, der er anvendt til alle tre målinger. Målebeskrivelse Til måling på clock-generatorerne til ACIA485 og ACIA232 anvendes følgende procedure: Strømforsyningen stilles til 5 V DC. Oscilloskopet tilsluttes oscillatorernes CLK-ben (ben 08) og til stel. På oscilloskopet aflæses frekvens, rise- og fall-times samt pulsvidde. Der måles også efter deling gennem 74HC4060-kredsen på ben O03 - se figur L.1. Til måling på clock-generatoren til M68k anvendes følgende procedure: Oscilloskopet tilsluttes oscillatorens CLK-ben (ben 08) og til stel. På oscilloskopet aflæses frekvens, rise og fall times samt pulsvidde. Herudover måles frekvensen på processorens ben E for at kontrollere, at der sker en 10-deling af frekvensen ned til 800 khz samt, at duty cycle her er 40 % som databladet beskriver. Måleresultater Måleresultaterne for de tre kredsløb ses i tabel L.2, L.3 og L.4. Evaluering af målinger De målte værdier for rise- og fall time på M68k clock er fire gange længere end den højest tilladte jvf. databladet. Kravet er, at de skal være mindre end 10 ns, og de målte værdier er henholdsvis 39 ns og 40 ns. Agilent oscilloskopet har jvf. instruktionsbogen en måleusikkerhed på tiden t, der er givet ved følgende: t = ±0.01% af pulsevidde ± 0.1% af skærmvidde ± 40 ps (L.1) 173

Her er et eksempel på udregning af usikkerhed for måling på frekvensen af M68k clock en. Pulsvidden er målt til 62.5 ns, og skærmdivisionen på oscilloskopet er indstillet til 20 ns pr. felt. Den samlede skærmvidde er altså 200 ns, idet der er 10 felter. Herved fås en afvigelse tid på: 62.5 ns 200 ns t = ± ± ± 40 ps = ± 0.246 ns (L.2) 10000 1000 Dette giver en procentvis usikkerhed dif f på denne måling på: diff = 0.246 ns 62.5 ns 100 = 0.39 % (L.3) Denne usikkerhed er meget lille, og selv med den medregnet kan måleresultaterne ikke komme i nærheden af kravene til rise og fall time for processoren. Praktisk arbejde med systemet har dog vist, at afvigelserne ingen betydning har for processorens virke. Det må betyde, at processoren i dette tilfælde ikke er særligt restriktiv mht. til data fra databladet. En evt. løsning på problemet kunne være at lede clock-signalet gennem en Schmitt trigger med tilfredsstillende rise- og fall times. Det ses af målingerne på frekvens f for ACIA232 og ACIA485, at deling gennem 74HC4060 divideren sænker afvigelsen som beskrevet i kapitel 8.1.1 på side 39 om clock-generatorer til ACIA. Frekvenserne målt både før og efter deling ligger meget tæt på de ønskede værdier, men på trods af dette vil måleusikkerheden fra oscilloskopet stadig være til stede i disse målinger som beregnet i (L.2) og (L.3). Denne usikkerhed vil falde, når frekvensen sænkes, så disse målinger kan siges at være tilfredsstillende. Betegnelse Apparat Producent Model AAU nr. Strømforsyning Strømforsyning Hameg HM7042 33878 Oscilloskop Oscilloskop Agilent 54621D 33854 Tabel L.1: Apparaturliste for målinger på clock-generatorer. Strømforsyning Oscilloskop Oscilloskop Oscilloskop V A GND 1 2 GND 1 2 GND 1 2 GND GND Vcc Clock-generatorer Clock ACIA485: 1.8432MHz Clock ACIA232: 2.4576MHz Clock M68k: 8MHz E-Clock M68k: 800kHz Figur L.1: Måleopstilling for måling på clock-generatorer. Betegnelse Krav Målt Afvigelse/bemærkning Frekvens f før deling 2.4576 MHz 2.457 MHz 0.2 % Frekvens efter deling 153.6 khz 153.6 khz 0 % Rise time t rise efter deling < 1 µs 35 ns ok Fall time t fall efter deling < 1 µs 60 ns ok Pulsvidde t pulse efter deling > 600 ns 3.26 µs ok Tabel L.2: Måleresultater for clock-generator til ACIA232. 174

APPENDIKS L. MÅLEJOURNAL FOR CLOCK-GENERATORER Betegnelse Krav Målt Afvigelse/bemærkning Frekvens f før deling 1.8432 MHz 1.842 MHZ 0.065 % Frekvens efter deling 115.2 khz 115.2 khz 0 % Rise time t rise efter deling < 1 µs 7.5 ns ok Fall time t fall efter deling < 1 µs 7.5 ns ok Pulsvidde t pulse efter deling > 600 ns 4.34 µs ok Tabel L.3: Måleresultater for clock-generator til ACIA485. Betegnelse Krav Målt Afvigelse/bemærkning Frekvens f på oscillator 8.000 MHz 7.994 MHz 0.075 % Pulsvidde t pulse 55-125 ns 62.5 ns ok Rise time t rise < 10 ns 40 ns 400% Fall time t fall < 10 ns 39 ns 390% Frekvens f på ben E 800.0 khz 800.0 khz 0 % Duty cycle på ben E 40 % 40 % 0 % Tabel L.4: Måleresultater for clock-generator til M68k. 175

APPENDIKS M. MÅLEJOURNAL FOR RESET-KREDSLØB Appendiks M Målejournal for reset-kredsløb Formål Formålet med denne målejournal er at verificere, om reset-kredsløbet til M68k lever op til de krav, der stilles jvf. databladet. Kredsløbets opgave er at sikre en reset-puls på mindst t d = 100 ms, hvis der trykkes på reset-tasten eller hvis forsyningsspændingen genoprettes efter at være faldet under V reset = 4.55 ms ± 0.05 ms. Screenshots af målingerne findes på CD-ROM en i [bilag/målinger/resetkredsløb]. Apparaturliste Der er i målingerne benyttet apparatur jvf. tabel M.1. Måleopstilling Måleopstillingen for målingerne fremgår af figur M.1. Målebeskrivelse Kredsløbet tilsluttes 5 V DC fra strømforsyningen. Oscilloskopet forbindes til TL7705A-kredsens ben RST og til stel. Et multimeter forbindes til udgangen på strømforsyningen til at måle forsyningsspændingen. Herefter sænkes forsyningsspændingen, indtil RST asserteres, og forsyningsspændingen aflæses. Således kan det bestemmes, om overvågningen af forsyningsspændingen fungerer efter hensigten. Herefter hæves forsyningsspænindingen igen til 5 V. Det måles med oscilloskopet, om RST er asserteret i 100 ms eller derover. Til sidst sluttes reset-tasten kortvarigt, og det måles, om RST er asserteret i 100 ms eller derover. Måleresultater Måleresultaterne fremgår af tabel M.2. Evaluering af målinger Resultaterne for målingerne er generelt tilfredsstillende. Kravet til reset-pulsen t d er min. 100 ms, og denne tid overholdes fint. Den målte afvigelse på 8.3 % mellem den beregnede og målte værdi skyldes nok hovedsageligt, at den anvendte kondensator C 02 kan have en afvigelse på mellem -20 og +50 %. Dertil kommer også måleusikkerheder fra oscilloskop og multimeter som beskrevet i appendiks L. Betegnelse Apparat Producent Model AAU nr. Strømforsyning Strømforsyning Hameg HM7042 33878 Oscilloskop Oscilloskop Agilent 54621D 33854 Multimeter Multimeter Fluke 37 08517 Tabel M.1: Apparaturliste for målinger på reset-kredsløb. 177

Strømforsyning V A Multimeter V A R R Oscilloskop GND Input GND 1 2 GND GND Vcc Reset-kredsløb RST* Figur M.1: Måleopstilling for måling på reset-kredsløb. Betegnelse Krav Målt Beregnet Afvigelse Automatisk t d > 100 ms 120 ms 130 ms 8.3 % Manuel t d > 100 ms 120 ms 130 ms 8.3 % Spænding V reset 4.55 V ± 0.05 V 4.6 V ikke beregnet ok Tabel M.2: Måleresultater for reset-kredsløb til M68k. 178

APPENDIKS N. MÅLEJOURNAL FOR DTACK -GENERATOR Appendiks N Målejournal for DTACK -generator Formål Formålet med denne målejournal er at verificere, om CS DISP diskuteret i kapitel 10.3 er længere, end 230 ns, som er kravet jvf. datablad for displayet. Apparaturliste Der er i målingerne benyttet apparatur jvf. tabel N.1. Måleopstilling Måleopstillingen for målingerne fremgår af figur N.1. Her er vist et lille udsnit af det samlede kredsløbsdiagram for minimumsystemet, hvorpå målepunkter er tilsluttet oscilloskopet. Målebeskrivelse Før målingen kan gennemføres skal minimumsystemet være aktivt. Herefter kaldes en funktion, som tilgår displayet, og herved kan der måles på de ønskede tider og spændinger nævnt herunder. Oscilloskopets logiske del tilsluttes AS, CS DISP og DTACK, mens en analog kanal måler spændingen over C 31. Tiden på AS, CS DISP og DTACK måles herefter. Måleresultater Det ses tydeligt af figur N.2 på den følgende side, at AS er asserteret længere tid ved aktivering af displayet end ellers. Aktiveringspulsen på CS DISP er målt til 550 ns, og herved overholdes kravet om, at displayet skal være aktiveret i mindst 230 ns. For displayet er AS asserteret i 690 ns. For de øvrige enheder er denne tid kun 320 ns. Derfor må instruktioner, der tilgår displayet være t = 690 ns 320 ns = 370 ns (N.1) længere tid om eksekvering end instruktioner, der tilgår RAM eller ROM. Evaluering af målinger Målingen viser, at displayet får en CS DISP i tilstrækkelig lang tid. Tiden er betydeligt længere end påkrævet, men dette skyldes, at der er beregnet med, at PEEL-kredsen lader på RC-ledet med fuld forsyningsspænding, 5 V, og at der til inverterens positive trig-niveau, V T +, er taget udgangspunkt i den laveste værdi angivet for en forsyningsspænding på 4.5 V, 0.5 V under den faktiske forsyningsspænding. Dette har ingen betydning for displayets praktiske virke. 179

Betegnelse Apparat Producent Type AAU nummer Oscilloskop Oscilloskop Agilent 54621D Mixed Signal 33841 Strømforsyning Strømforsyning Hameg HM7042 33878 Tabel N.1: Apparaturliste for målejournal for DTACK -generator. Strømforsyning Oscilloskop Vcc V A GND Vcc R11 IC21a 06 IC04 22CV10A PEEL02 23 IRQ07* 06 I00 02 I04 09 DISP OK 03 FC0 04 FC1 05 FC2 20 DTACK* 07 AS* INT 22 CS DISP 08 1 2 3 4 GND NMI-TAST R12 S02 IC21b 05 04 03 R37 C31 Figur N.1: Måleopstilling for måling på DTACK -generator. Logisk niveau Spænding [V] 3 2 1 0 A B C D 1.5e 06 1e 06 5e 07 0 5e 07 1e 06 Tid [S] Figur N.2: Målinger på DTACK -generator. A viser spændingen over C 31, B viser AS, C viser DTACK og D viser CS DISP. 180

APPENDIKS O. MÅLEJOURNAL FOR RESPONSTID PÅ PERIFERE ENHEDER Appendiks O Målejournal for responstid på perifere enheder Formål Formålet med denne målerapport at fastsætte responstiden for de perifere enheder. Dette gøres af tre årsager: At undersøge, om responstiden er forskellig for hver enhed. At fastsætte, hvor lang tiden t timeout i subrutinen bus r i minimumsystemet mindst skal være. t timeout er den tid, som minimumsystemet skal afvente svar fra en perifer enhed. At fastsætte, hvor lang tids forsinkelse funktionen delay UART() i de perifere enheder skal generere. Denne forsinkelse bestemmer, hvor længe en perifer enhed skal vente med at lytte efter ny data efter, at data har været tiltænkt en anden enhed. Apparaturliste Der er i målingerne benyttet apparatur jvf. tabel O.1. Måleopstilling Til målingerne er der anvendt måleopstilling jvf. figur O.1. Målebeskrivelse Til måling på responstiden for enhederne anvendes følgende procedure: Strømforsyningen stilles til 5 V DC. Oscilloskopet tilsluttes minimumsystemet på IC18 (MAX487) på RO (Receive Out), DI (Drive In) og RTS på IC16 (ACIA485) og til stel. Fra minimumsystemet sendes en datapakke med en korrekt adresse samt kommando- og databyte til hver af de perifere enheder. Enheden svarer tilbage, og dette svar registreres på oscilloskopet med single shot funktionen. Heraf kan responstiden aflæses som tiden, det tager fra første startbit, som masteren sender til sidste stopbit, om den perifere enhed sender. ved at anvende cursor-funktionen. Måleresultater Måleresultaterne for de tre perifere enheder ses i tabel O.2. På figur O.2 er vist måling for olieenheden, som er den langsomste af enhederne. Evaluering af målinger Det ses af måleresultaterne, at olieenheden er den langsomste af de tre enheder til at svare tilbage med hele datapakken. Dette skyldes, at enheden foretager en A/D-konvertering, og dette tager længere tid end de to andre enheder bruger på enten at sætte eller hente værdier på ind- eller udgangene på controlleren. Olieenheden er 624 µs om at sende data retur, hvilket omregnet til antal frames N med 11bit hver svarer til N = 624 µs 115.2 kbps 72 bit 6.5 frames (O.1) 181

Af disse resultater kan t timeout og forsinkelse i delay UART() bestemmes. t timeout, hvor i masteren skal afvente svar skal dimensioneres, så den er lidt længere end den længste svartid. Den er her sat til syv frames svarende til 668 µs, således er der en margin på en halv frame. Forsinkelse i delay UART() skal være længere end svartiden for langsomste enhed. Den må dog ikke være så lang, at masteren kan nå at påbegynde afsendelse af en ny datapakke, før forsinkelsen er slut. Således er forsinkelsen sat til t delay = 700 µs, så den slutter midt i det, der på figur O.2 er beskrevet som master request setup time. Betegnelse Apparat Producent Model AAU nr. Strømforsyning Strømforsyning Hameg HM7042 33894 Oscilloskop Oscilloskop Agilent 54621D 33842 Tabel O.1: Apparaturliste for måling på perifere enheder. Strømforsyning Oscilloskop V A GND 1 2 3 GND GND Vcc Minimumsystem DI RO RTS* RS485-forbindelse Perifer enhed Figur O.1: Måleopstilling for måling på responstider for perifere enheder. Enhed Responstid for komplet datapakke Lygtekontrolenhed 592 µs Lygteenhed 592 µs Olieenhed 624 µs Tabel O.2: Måleresultater for responstid for perifere enheder. 182

APPENDIKS O. MÅLEJOURNAL FOR RESPONSTID PÅ PERIFERE ENHEDER RTS Responstid 624us 176us Slave 258us Master request setup tid Slave respons 2 bytes Master Master request 3 bytes Master request 3 bytes 2.5 3 3.5 4 4.5 5 tid [s] x 10 3 Figur O.2: Responstid for olienhed. 183

APPENDIKS P. MÅLEJOURNAL FOR ACIA485 Appendiks P Målejournal for ACIA485 Formål Formålet med denne målejournal er at bestemme tiden t RT S, der angiver tiden fra benet RTS sættes lav af ACIA485 til hele transmitdataregistret i denne er afsendt. Apparaturliste Betegnelse Apparat Producent Type AAU nummer Oscilloskop Oscilloskop Agilent 54621D Mixed Signal 33841 Tabel P.1: Apparaturliste for målejournal af ACIA485. Måleopstilling Den benyttede måleopstilling ses på figur P.1. Minimumsystem RS232 PC Oscilloskop CS 12 VCC 08 CS0 10 CS1 09 CS2* RxCLK TxCLK 03 04 Vcc 1 2 GND D00 D01 D02 D03 D04 D05 D06 D07 22 D00 21 D01 20 D02 19 D03 18 D04 17 D05 16 D06 15 D07 IC16 - M6850 ACIA485 / UDS 02 RxD 06 TxD 05 RTS* 07 IRQ R33 01 RO 04 DI 03 DE 02 RE* IC18 MAX487 DRIVER A 06 B 07 14 E 11 RS 13 R/W* 24 CTS* DCD* 23 01 VSS Figur P.1: Måleopstilling for målejournal af ACIA485. 185

Målebeskrivelse Nedenstående kode kompileres sammen med initialiseringsmodulet fra appendiks F på side 147 og linkerscriptet, hvor de globale genveje og adresserne for display og ACIA485 findes [bilag/kildekode/linkerscript.txt]. Herefter overføres dette til minimumsystemet med TS2-MON via RS232 forbindelsen. 1 F ø l g e n d e g e n v e j e e r d e f i n e r e t i f i l e n l i n k e r s c r i p t. t x t og b e n y t t e s i d e t t e program uddrag 2 RS485 STATUS = 0 x800000 3 RS485 DATA = 0x800002 4 RS232 STATUS = 0 x800001 5 RS232 DATA = 0x800003 6 DISP ADR = 0x840000 7 DISP DATA = 0x840002 8 9. t e x t 10. g l o b a l h w t e s t 11. type hw test, @function 12 13 hw test : 14 15 De to nedenstående skal indikere påbegyndelse af a f s e n d e l s e på bus 16 move. b #RS485 RX, RS485 STATUS A k t i v e r RS485 RX ( gå l a v ) 17 move. b #RS485 TX, RS485 STATUS A k t i v e r RS485 TX ( gå h ø j ) 18 move. b # A, RS485 DATA Skriv A t i l RS485. Der afsendes a l t s å 1 byte for at se hvor h u r t i g t 19 RTS a s s e r t e r e s a f ACIA h e r e f t e r. 20 hw loop5 : 21 move. w RS485 STATUS,%d0 Læs s t a t u s f r a RS485 og gem denne værdi i D0 22 and. b #ACIA TX BUFFER,%d0 AND 0b00000010 med D0 for at se om anden bit er sat 23 beq h w l o o p 5 Hop h v i s s i d s t e i n s t r u k t i o n gav Z=0 i s t a t u s r e g i s t e r f o r CPU 24 25 move. b #RS485 RX, RS485 STATUS A k t i v e r RS485 RX ( gå l a v ) 26 27 trap #14 28 r t s Oscilloskopet sættes til single shot, og koden eksekveres vha. TS2-MON. Herefter kan tiden t RT S aflæses som tiden fra RTS asserteres anden gang til transmissionen af framen indeholdende ASCII værdien af A er afsendt på TxD benet. Måleresultater Måledata opsamlet fra oscilloskop er vedlagt på CD-ROM [bilag/maalinger/acia]. De behandlede data ses af figur P.2. 1.5 RTS* Logisk niveau 1 0.5 0 0.5 1 0.5 0 0.5 1 1.5 2 x 10 4 1.5 t RTS TxD Logisk niveau 1 0.5 0 0.5 1 0.5 0 0.5 1 1.5 2 tid [s] x 10 4 Figur P.2: Grafer for RTS og TxD på ACIA485 ved afsendelse af bogstavet A. Evaluering af målinger Tiden t RT S er aflæst på oscilloskopet til 83.6 µs. Der skal altså indsættes en software-løkke der forsinker asserteringen af RTS med denne tid - for at sikre afsendelsen af en frame er afsluttet inden ACIA en herefter opsættes til at modtage data. 186

APPENDIKS Q. MÅLERAPPORT FOR ACCEPTTEST Appendiks Q Målerapport for accepttest Q.1 Formål Denne målerapport indeholder den endelige accepttest for det konstruerede bilbussystem. Accepttesten udføres i henhold til accepttestspecifikationen i kapitel 4 på side 17. Der udføres i alt 2 tests; kommunikationstid og brugerinterface. Q.2 Test af Kommunikationstid Q.2.1 Formål Formålet med denne måling er at bestemme den tid det tager, fra brugeren har bedt om en handling, til handlingen er udført. Dette udføres med lygtekontrolenhed som afsender af kommando, imens lygteenheden udfører kommandoen. Olieenheden skal i denne test sidde på bussen som passiv enhed. Q.2.2 Apparaturliste Til målingen skal anvendes apparatur som vist i tabel Q.1. Betegnelse Apparat Producent Model AAU nr. Strømforsyning Strømforsyning Hameg HM7042 33878 Oscilloskop Oscilloskop Agilent 54621D 33841 2 x Probe Probe Agilent 10074C - Tabel Q.1: Apparaturliste for måling af kommunikationstid. Q.2.3 Måleopstilling Måleopstillingen er som vist på figur Q.1 på den følgende side. Q.2.4 Målebeskrivelse Testen udføres ud fra følgende fremgangsmåde: 1. Placer måleprobe 1 på den anvendte kontakt i lygtekontrolenheden. Placer måleprobe 2 på den tilsvarende udgang på lygteenheden. 2. Indstil oscilloskopet til single shot mode. 187

Q.2. TEST AF KOMMUNIKATIONSTID Strømforsyning PC RS232 Minimumsystem V A GND Oscilloskop 1 2 GND RS485 Olieenhed Lygteenhed Lygtekontrolenhed Figur Q.1: Måleopstilling til måling af kommunikationstid. 3. Start minimumsystemet, så dette kører i normal drift. 4. Asserter den valgte kontakt på lygtekontrolenheden. 5. Aflæs tiden mellem kanal 1 s ændring på oscilloskopet, til kanal 2 s ændring. Dette er en måling for aktivering af kontakt. 6. Gentag forsøget 12 gange fra punkt 4. Q.2.5 Måleresultater Resultaterne af målingen er vist i tabel Q.2. Måling nr. Aktivering [ms] 1 75.2 2 82.4 3 82.8 4 81.2 5 79.6 6 55.4 7 48.2 8 66.6 9 76.2 10 89.6 11 99.6 12 48.1 Sum 884.9 Tabel Q.2: Måleresultater for måling af kommunikationstid. 188

APPENDIKS Q. MÅLERAPPORT FOR ACCEPTTEST Q.2.6 Beregninger Gennemsnitstiden for en kommunikation beregnes til: Q.2.7 Fejlkilder t avg = 884.9 ms 12 = 73.8 ms (Q.1) Oscilloskopet har en afvigelse. Denne kan beregnes på samme måde som i (L.1) på side 173. diff = 73.8 ms 10000 + 100 ms 1000 + 40 ps = 17.4 µs (Q.2) Kommunikationstiden vil variere med antallet af tilkoblede enheder, samt i hvilken rækkefølge de forskellige moduler kaldes i løkkeprocessen (se kildekode til løkkeprocessen s. 151). Q.2.8 Evaluering af målinger I denne måling er det vist at den gennemsnitlige kommunikationstid fra lygtekontrolenhed til lygteenhed ligger på 73.8 ms. Q.3 Test af brugerinterface Q.3.1 Formål Formålet med denne måling er at undersøge brugerens indtryk af det konstruerede interface. Dette undersøges ved, at lade flere brugere anvende systemet en ad gangen, for derefter at udfylde et spørgeskema omkring indtrykket. Q.3.2 Apparaturliste Til denne måling skal prototypen af systemet benyttes. Der anvendes desuden blyant og spørgeskemaet som er vist på side 191. Q.3.3 Måleopstilling Opstillingen til denne måling er vist i figur Q.2 på den følgende side. Q.3.4 Målebeskrivelse Brugerne evaluerer systemet efter tur, og under deres test af brugerinterface udfylder de det udleverede spørgeskema. I alt 8 brugere har testet systemet. Q.3.5 Måleresultater I tabel Q.3 på næste side vises fordelingen af svar fra respondentgruppen. Q.3.6 Fejlkilder Pointsystemet der anvendes til vurdering giver ikke brugeren mulighed for at komme med yderligere kommentarer, hvilket ofte er den stærke side i sådanne undersøgelser. Herved er det ikke sikkert at respondenten har opfattet spørgsmålet på samme måde som det blev ment. Dette kunne afhjælpes med et kommentarfelt. Antallet af respondenter kunne forøges for at opnå en større generalitet i testene. 189

Q.4. SPØRGESKEMA TIL INTERFACE TEST Testperson Olieenhed Spørgeskema Minimumsystem display Lygtekontrolenhed Lygteenhed Figur Q.2: Måleopstilling til brugerinterface undersøgelse. Point 1 2 3 4 5 Spørgsmål 1 1 2 1 4 Spørgsmål 2 5 3 Spørgsmål 3 5 2 1 Spørgsmål 4 4 4 Spørgsmål 5 1 6 1 Spørgsmål 6 1 3 4 Spørgsmål 7 1 5 2 Tabel Q.3: Måleresultater fra brugerinterface måling. Tabellen viser antal vægtede besvarelser vandret og spørgsmål lodret. Ved en besvarelse på 5 er respondenten meget enig i udsagnet. Ved en besvarelse på 1 er respondenten meget uenig i udsagnet. Q.3.7 Evaluering af målinger Målingen viser en overvejende enighed med de stillede spørgsmål, med den gennemsnitlige vurdering til 4. Q.4 Spørgeskema til interface test På næste side ses en tro kopi af det udleverede spørgeskema. 190

Spørgeskema til interface test Dette spørgeskema er del af en brugerinterfacetest på gruppe 415 s prototype af et bilbussystem. Et medlem fra gruppen vil guide Dem igennem fremgangsmåden i denne test. Kort introduktion til systemet Systemet skal erstatte det parallelle ledningsnet i en personbil, med et serielt ledningsnet. Til venstre for Dem er placeret et wrapboard med et LCD-display og 2 taster. Herpå kan De få vist informationer fra systemet. Den viste information kan vælges med tasterne. Der er i øjeblikket 2 informationer at få vist: information om bilens oliestatus og information om lygternes status. Direkte foran Dem er placeret en enhed til lygtekontrol, denne styrer venstre forlygtes nærlys, fjernlys, positionslys og blinklys. Lygten er placeret ved Deres venstre fod. Til højre for Dem er placeret en enhed til simulering af olietryk. Med potentiometret på dette kan De justere det simulerede olietryk i bilen. Spørgsmål Nedenfor er de spørgsmål vi vil bede Dem besvare i tabellen. En værdi på 5 er et meget enig i udsagnet. En værdi på 1 er et meget uenig i udsagnet. Besvarelser bedes udfyldt med et entydigt kryds. Spørgsmålene er nummereret vertikalt, med vægtningen horisontalt ud for hvert spørgsmål. 1. Brugergrænsefladen virker ved første indtryk enkel og let at betjene. 2. Alle fire lygtekontakter fungerer som forventet. 3. Olietrykket vises på en fornuftig måde. 4. Systemet er meget resistent overfor fremprovokerede fejl. 5. LCD-displayet anvendes informativt. 6. Navigering på displayet er nem og logisk. 7. Brugergrænsefladen som helhed er enkel og let at betjene. Vi takker for Deres tid. Point 1 2 3 4 5 Spørgsmål 1 Spørgsmål 2 Spørgsmål 3 Spørgsmål 4 Spørgsmål 5 Spørgsmål 6 Spørgsmål 7 gruppe 415, 4. semester EE AAU

APPENDIKS R. FOLDUDDIAGRAMMER OVER PERIFERE ENHEDER Appendiks R Folduddiagrammer over perifere enheder Komponent Værdi Komponent Værdi Komponent Værdi R 50,51 280 Ω C 52,53 100 nf IC51 Atmel AT90S2313 R 52,53 66 kω C 55,56 15 pf IC50 Maxim MAX487 R 54 10 kω D 50,51 Rød LED 3mm IC52 78L05 R 55,56,57,58,59 4.7 kω T 50,51 BC547 C 50,54 330 nf XTAL 50 3.6864 MHz C 51 10 nf S 50 Sluttekontakt Tabel R.1: Komponentliste til kredsløbsdiagram for lygtekontrolenhed. Komponent Værdi Komponent Værdi Komponent Værdi R 60,61,62,63,64,65 10 kω R 66,68 280 Ω IC61 Atmel AT90S2313 R 67,69 66 kω D 61,62,63,64 1N4148 IC62 Maxim MAX487 C 61,62 15 pf D 65,66 Rød LED 3mm IC63 78L05 C 63,64 330 nf T 61,62,63,64,65,66 BC547 C 65 10 nf XTAL 61 3.6864 MHz C 66,67 100 nf S 60 Sluttekontakt Tabel R.2: Komponentliste til kredsløbsdiagram for lygteenhed. Komponent Værdi Komponent Værdi Komponent Værdi R 70 4.7 kω C 73,74 330 nf XTAL 71 3.6864 MHz R 71 10 kω C 75 10 nf S 70 Sluttekontakt R 72,73 66 kω C 76,77,78 100 nf IC71 Atmel AT90S8535 R 74,75 280 Ω D 71,72 Rød LED 5mm IC72 Maxim MAX487 P 71 10 kω T 71,72 BC547 IC73 78L05 C 71,72 15 pf L 71 10 µh Tabel R.3: Komponentliste til kredsløbsdiagram for olieenhed. 193

APPENDIKS S. FOLDUDDIAGRAM OVER MINIMUMSYSTEMET Appendiks S Folduddiagram over minimumsystemet Komponent Værdi Komponent Navn Beskrivelse R 04 -R 12, R 20,21,22,23, R 33 4.7 kω IC01 MCO 1425B 8 MHz Oscillator R 01,02,03, R 32, R 39,41 10 kω IC02 TL7705A Reset R 13 390 Ω IC03 74HCT148 Decoder R 34 100 Ω IC04 22CV10A PEEL02 R 35,36 576 Ω IC05 M68HC000 CPU R 37 1 kω IC06 22CV10A PEEL01 R 38,40 100 kω IC07 AM29F010 ROM IC08 AM29F010 ROM C 01,26,30 15 pf IC09 HM628512 RAM C 02 10 µf IC10 HM628512 RAM C 03,38,39, C 21,22,23,24,25 100 nf IC11 CMOS OSC 2.4576 MHz Oscillator C 31 150 pf IC12 M6850 ACIA232 IC13 74HC4060 Divider D 01,02 BAT85 IC14 MAX232 RS232-driver D 03,04,05,06 1N4148 IC15 CMOS OSC 1.8432 MHz Oscillator IC16 M6850 ACIA485 IC17 74HC4060 Divider IC18 MAX487 RS485-driver IC19 HD44780 Display IC20 74HC279 SR-latch IC21 74HC14 Inverter Tabel S.1: Komponentliste til kredsløbsdiagram for minimumsystem. 195