Styring af ubåd. Mikrodatamatsystemer

Transkript

1 Styring af ubåd Mikrodatamatsystemer 4. semester projekt School of Information and Communication Technology Elektronik & IT Aalborg Universitet Forår 2011

2 2

3 Titel: Styring af ubåd Tema: Mikrodatamatsystemer Projektperiode: EIT4, forår 2011 Projektgruppe: 411 Gruppemedlemmer: André Sekunda Benjamin Krebs Frederik Juul Jacob Hansen Jesper Knudsen Jonas Hansen Vejleder: Jens Frederik Dalsgaard Nielsen Sidetal: 148 Oplagstal: 8 School of Information and Communication Technology Elektronik & IT Adresse: Fredrik Bajers Vej 7 Telefon: URL: esn.aau.dk Synopsis: Der er i dette projekt arbejdet med et styringssystem til en ubåd. Projektet tager udgangspunkt i et forslag fra Rhode & Schwarz, som præsenterede et ønske om en testplatform til sensorer. En ubåd, som fungerer som et sådant testsystem, skal kunne sejle frem og tilbage, dykke og stige samt kunne ændre sin retning. Der fremstilles et mikrodatamatsystem, som har til opgave at kommunikere med ADC-, DAC- og PWM-moduler, som benyttes til at måle på og regulere ubåden. Derudover kan systemet kommunikere med en computer. Desuden fremstilles en controller og et program til en computer, som kan formidle kommunikationen mellem controlleren og mikrodatamatsystemet. Computeren sender desuden målings-requests til microdatamatsystemet, og bruger denne information til at udregne data angående ubådens situation. Det kan konkluderes, at det lykkedes at skabe et system som kan styre ubåden tilfredsstillende, og som har mulighed for at foretage målinger. Bilagsantal og art: 1 bilags-cd Afsluttet den: 27/ Rapportens indhold er frit tilgængeligt, men offentliggørelse (med kildeangivelse) må kun ske efter aftale med forfatterne.

4 4

5 Title: Controlling a submarine Theme: Microcomputersystems Project Period: EIT4, spring 2011 Project Group: 411 Group Members: André Sekunda Benjamin Krebs Frederik Juul Jacob Hansen Jesper Knudsen Jonas Hansen Supervisor: Jens Frederik Dalsgaard Nielsen Number of pages: 148 Printed Copies: 8 School of Information and Communication Technology Electronics & IT Adress: Fredrik Bajers Vej 7 Telephone: URL: esn.aau.dk Synopsis: This project concerns designing and manufacturing a system for controlling a submarine. The project is based on a proposal by Rhode & Schwarz, who presented a desire for a test platform for sensors. A submarine which serves as such a test system must be able to sail back and forth, diving and rising, and changing its direction. A microcomputersystem is manufactured, with the purpose of communicating with a computer, as well as ADC-, DAC- and PWMmodules, required for measuring and regulating the submarine. Pink fluffy unicorns dancing on rainbows. Further, a controller and a computer program were created, with the purpose of facilitating communication between controller and microcomputersystem, requesting measurements from the microcomputersystem and using these measurements for calculations. In conclusion, a system was created with the ability to control the submarine satisfactory, with the possibility of measurements. Appendix Media: 1 appendix-cd Finished: 27/ The content of this paper is freely available, but publication (with references) is only allowed with permission from the author.

6 6

7 Læsevejledning I denne rapport benyttes forskellige former for notation. Disse er som følger: Henvisninger til litteratur er markeret med [1] hvor nummeret svarer til et nummer i litteraturlisten. Disse henvisninger er, i den elektroniske version af rapporten, links, så de kan klikkes på. Henvisninger som er brugt til en enkelt information er markeret umiddelbart efter denne information og henvisninger brugt til et helt afsnit er markeret umiddelbart efter afsnittet. Henvisninger til figur eller afsnit er markeret med se figur/afsnit x.x.x hvor nummeret svarer til afsnitsnummeret i indholdsfortegnelsen eller figurnummeret under en figur. Disse henvisninger er, i den elektroniske version af rapporten, links. Binære tal markeres med et undersænket b. F.eks b Hexadecimale tal makeres med et undersænket h. F.eks 1000 h Accepttestafsnit sluttes alle med en tabel, der opsummerer de opstillede krav i forhold til deres status. Der vil ikke blive henvist til denne tabel, udover her. Et bestået krav er markeret med mens et ikke bestået krav markeres med X. Aktivt lave signaler markeres, i tekst, med overline. Boolsk algebra opstilles med navnene på de forskellige indgange, markeret med * hvis signalet er aktivt lavt. Boolsk invertering er markeret med overline. Ordliste ACIA - Asynchronous Communication Interface Adapter ADC - Analog-til-digital konverter (Analog-to-Digital Converter) AS - Adressestrobe CSx - Chip Select x DAC - Digital-til-analog konverter (Digital-to-Analog Converter) DTACK - Data Acknowledge DUT - Device Under Test EEPROM - Electrically Erasable Programmable Read Only Memory IACK - Interrupt acknowledge LDS - Lower Data Strobe M68k - Motorola NMI - Non-Maskable Interrupt NOP - No operation OE - Output Enable PWM - Pulse-width Modulation RAM - Random Access Memory RD - Read ROM - Read Only Memory UDS - Upper Data Strobe WE - Write Enable WR - Write 7

8

9 Forord Denne rapport dokumenterer et 4. semester projekt, udarbejdet i perioden fra 1. februar 2011 til 27. maj Projektet er udført af gruppe 411 på Elektronik og IT-ingeniør uddannelsen på Aalborg Universitet. Temaet for dette semester er Mikrodatamatsystemer og gruppen valgte Styring af ubåd som undertema. I løbet af semesteret modtager gruppen undervisning i form af PE- og SE-kurser, som bliver holdt af Institut for Elektroniske Systemer. Gruppen tilegner sig desuden viden gennem en fri studieaktivitet. Omtalte kurser er: PE-kurser: SE-kurser: Mikrocomputer hardware Beregningsteknik indenfor elektronikområdet 2 Mikrocomputer software Algoritmer og datastrukturer Struktureret systemudvikling Transmissionsledningsteori EMC rigtigt design Maxwellsk feltteori Fri studieaktivitet: NumPy course Gruppe 411 består af: André Sekunda Benjamin Krebs Frederik Juul Jacob Hansen Jesper Knudsen Jonas Hansen

10 10

11 Indholdsfortegnelse 1 Indledning 15 2 Funktionalitetsanalyse Anvendelsesområde Manuel sejlads Automatiseret sejlads Kommunikation Fejlscenarier Ubådsmodel Afgrænsning af funktionalitet Kravspecifikation 25 4 Minimumssystem Debugger Microprocessor Hukommelse Kommunikation i minimumssystemet Power-on-reset Interrupt ADC DAC Adressedekoder Forsyning Implementering Accepttest Modulopbygning Computer Kommunikation Sensorer Aktuatorer Kommunikationsmodul Implementering Initialisering Accepttest

12 7 Sensormodul Ballasttankmodul Accelerometer Sampling af sensorer Accepttest Motormodul Fremdrift Ballastpumpe Ror PWM, H-bro og komparatorkredsløb Acceptest motormodul Adressedekodning, interrupt og DTACK Adressedekodning DTACK-håndtering Interrupt-håndtering Controllermodul Software - Computer Måling af sensorer Kalibrering og omregning Software - Motorola 68k Tekststrenge Interne funktioner Eksterne funktioner Implementering Accepttest Konklusion 107 Litteratur 109 Appendiks A Målejournal - FNOP-operation 111 Appendiks B Målejournal - ADC 115 Appendiks C Målejournal - DAC 119 Appendiks D Målejournal - tryksensor 123 Appendiks E Målejournal - sensor-accepttest 127 Appendiks F Målejournal - Motorer 131 Appendiks G Målejournal - kommunikationsmodul-accepttest

13 Appendiks H Målejournal - Motor accepttest 139 Appendiks I Eldiagrammer

14

15 Indledning 1 Dette projekt tager udgangspunkt i en ide fremstillet af Rohde & Schwarz s Aalborg afdeling og går ud på at designe et undervandsfartøj, som skal agere testplatform for nye sensorer under udvikling. Projektet tager udgangspunkt i de kurser projektgruppen modtager på 4. semester og læringsmålene for semestret bliver prioriteret frem for produkt, hvilket får betydning for opbygningen. Projektet omhandler dermed design af et mikrodatamatsystem, som skal kunne kontrollere ubåden og dens funktioner. Da projektet blot er med udgangspunkt i at ubåden skal fungere som testplatform, vil projektgruppen i flere tilfælde fastsætte krav til systemet, ud fra hvad der vurderes til at være relevant for en testplatform af denne slags. Systemet består overordnet af en ubåd samt en fjernstyringsenhed. Ubåden skal have forskellige funktioner, blandt andet skal det både være muligt at styre ubåden via fjernstyringsenheden manuelt samt at indstille ubåden til en automatiseret styring. Begge funktioner stiller en række krav til ubådens udstyr, i form af sensorer og aktuatorer og ligger desuden op til at brugeren skal modtage information om ubådens status. Systemet vil, under udviklingsprocessen blive opdelt i funktionelle blokke, moduler. Disse moduler vil blive individuelt testet hvorefter de vil blive implementeret til det samlede system. Under udviklingen af systemet tages der desuden hensyn til en række tænkelige fejl der eventuelt måtte opstå under brug. Disse fejlscenarier gennemgåes med henblik på udvikling af responsplaner til de forskellige former for fejl. 15

16

17 Funktionalitetsanalyse 2 Formålet med dette kapitel er at klargøre hvilken funktionalitet ubåden skal udrustes med. Dette vil blive gjort på baggrund af cases, som beskriver en situation som kan opstå under sejlads, samt en analyse af hvordan ubåden skal reagere i den givne situation og hvilke krav det stiller til motorer, sensorer og andet hardware. De forskellige situationer vil blive listet med henblik på en afgrænsning til hvad der vurderes som værende sandsynligt at opnå indenfor projektperioden. 2.1 Anvendelsesområde Ubåden udvikles med udgangspunkt i at skulle benyttes som testplatform, i Limfjorden i Aalborg. Vanddybden varierer med flere meter igennem Aalborg, men det dybeste sted blev pejlet til 15,5 m den 7. marts 2011 [1]. Ubåden skal derfor mindst kunne klare en dybde på 16 m og den skal være i stand til at måle dybden med en præcision på 10 cm, da det er denne præcision dybden kendes med. For at ubåden, under normale forhold, altid kan være i stand til at sejle modstrøms skal den kunne sejle hurtigere end de værste strømforhold der forekommer. Ifølge tallene fra DHI, som har bidraget med plottet vist på figur 2.1, kan strømmen i Limfjorden ved Aalborg nå op over 0, 56 m s, hvilket er ca. 1,1 knob, på grund af tidevandet. Derfor skal ubåden kunne sejle mindst 1,5 knob, da den dermed vil være i stand til at sejle imod strømmen selv under de værste normale forhold. Præcisionen på hastighedsmålingerne er besluttet at skulle være 0,1 knob. Strømforholdene kan blive værre end det normale maksimum, som er beskrevet på figur 2.1. Ved storm kan strømmene blive op til tre gange så kraftige, hvilket dog ikke ses som forhold ubåden skal anvendes under [2]. 17

18 Figur 2.1: Maksimale strømforhold i Limfjorden foresaget af tidevand [3]. 2.2 Manuel sejlads Når ubåden er søsat, skal det være muligt at styre den fra overfladen, hvad enten det måtte være i en båd eller på landjorden. Dermed er der behov for overføring af en række informationer både mellem ubåden og brugeren og internt i ubåden. Orientering For at brugeren kan være orienteret om bådens position og orientering under et dyk, er det nødvendigt med en række informationer. Dybde, hastighed samt retning fastlægges som et minimum af information, hvortil der gerne skal være en visuel orienteringsmulighed i form af billeder fra et videokamera. Dybden og hastigheden skal som nævnt i afsnit 2.1 måles, og dermed også vises, med en præcision på henholdsvis 10 cm og 0,1 knob. Retningen skal måles i grader og præcisionen er bestemt ud fra kravene til den automatiserede sejlads som opstilles i afsnit 2.3. Navigation Brugeren skal også være i stand til at styre ubåden, hvilket vil sige at det skal være muligt at styre ubådens bevægelser frem og tilbage, op og ned og fra side til side. Der findes principielt to måder en ubåd kan dykke på: Dynamisk- og statisk dykning. Hvis ubåden benytter sig af dynamisk dykning vil trinløs kontrol af dybden være optimal, da dybden vil være afhængig af ubådens fremdrift. Det vil derfor kræve fremdrift, at holde den på et specificeret niveau. Hvis ubåden derimod benytter sig af statisk dykning vil det være muligt at definere et niveau, som den skal holde sig på, som den vil dykke ned til. Ved hjælp af regulering er det muligt at holde dette niveau. I dette tilfælde vil kontrol og styring af dybde være optimalt. I forbindelse med styringen af fremdrift ønskes trinvis kontrol, fremfor trinløs kontrol. Dette betyder, at der skal være et antal trykknapper, hvorpå der kan vælges, hvilket 18

19 hastighedstrin der ønskes at sejle med, både frem og tilbage. Til at dreje ønskes trinløs kontrol. Der ønskes et controller med et lille hjul som styrepind, i stil med controlleren vist på figur 2.2. Figur 2.2: Controller med trinløs styring. 2.3 Automatiseret sejlads Ubåden skal agere testplatform og derfor er der valgt at den skal kunne sejle en automatiseret sejlrute, da en specifik test dermed kan gentages uden variationer fra ubåden. Når ubåden sættes i vandet skal den kunne sejle en længde ud fra startpunktet, hvorefter den skal finde tilbage til udgangspunktet. Undervejs skal ubåden sende information om hvor langt den er nået med sit gennemløb. Den foruddefinerede afstand er valgt til maksimalt 100 meter. Orientering For at kunne løse opgaven kræves det at ubåden kan bestemme hvor langt den har sejlet, samt holde kursen med en bestemt præcision. Der tolereres en afvigelse på 1 m per 100 m sejlet, hvorfor der må være en afvigelse fra ruten på ± 0,57, hvilket afrundes til ± 1 fremover for at verificere om kravet overholdes. På figur 2.3 er der vist en skitse med den maksimalt tolererede afvigelse. Befinder ubåden sig ved P, 100 meter fra punktet A, der er det ønskede mål, er kravet opfyldt, hvis ubåden kan ramme inden for en meter af punktet når der er tilbagelagt 100 m. Navigation For at kunne udføre en automatiseret sejlads skal ubåden, udover de i afsnit 2.2 nævnte funktioner, kunne tage højde for strømmen i vandet. Det er derfor nødvendigt med sensorer 19

20 Figur 2.3: Skitse af sejlrute ved upræcis styring der kan bestemme kraften ubåden påvirkes med så det kan modvirkes for en lige bevægelse gennem vandet. 2.4 Kommunikation Grundlæggende findes der to forskellige metoder til at kommunikere informationerne mellem bruger og ubåd. Der kan enten kommunikeres trådløst eller trådet ved et kabel. Trådløs kommunikation bliver dæmpet i højere grad, når det er i vand end i luft [4], hvilket gør det svært at kommunikere. Derfor er der til dette projekt valgt løsningen med trådet kommunikation. Med i denne løsning er trådet spændingsforsyning, hvilket fjerner tidsbegrænsningen et batteridrevet system ville arbejde under. Desuden kan videotransmissionen være uafhængig af minimumsystemet og derfor have eget kabel. 2.5 Fejlscenarier Dette afsnit omhandler, hvilke typer fejl der kan opstå under både manuel og automatiseret sejlads. Et fejlscenarie er defineret som værende en situation ubåden kan komme i, hvor den afviger fra den normale gang, og et automatisk system skal tage over. Projektgruppen fastsætter, at reaktionstiden fra en fejl sker, til systemet reagerer skal være under ét sekund. Opgaver der skal løses er prioriteret efter følgende rækkefølge: 1. Redde materiel 2. Få ubåden op til overfladen 3. Indsamle brugbart sensordata Fejl på minimumssystem I systemet kan der opstå fejl på minimumssystemet. Disse fejl kan både være softwareeller hardware-problemer, hvilket gør, at det i dette fejlscenarie ikke er muligt at bruge 20

21 minimumssystemet til at agere på fejlen. Der skal derfor konstrueres et form for system, der kan reagere, hvis der sker fejl på minimumssystemet. Efter at fejlen er detekteret skal ubåden søge mod overfladen, så brugeren har mulighed for at reparere fejlen. Kommunikationsvejen afbrydes Den kablede kommunikation mellem ubåden og fjernstyringen, altså dermed brugeren, er potentielt i fare for at blive beskadiget under sejlads. Mistes kommunikationen med ubåden har brugeren ingen kontrol over ubåden og der vides ikke hvordan den vil reagere. Derfor skal der være en måde hvorpå et brud på kommunikationsvejen kan detekteres, så både ubåden og brugeren ved, at det er sket. Efter at fejlen er detekteret skal ubåden søge mod overfladen, så brugeren har mulighed for at reparere fejlen. Kablet spændingsforsyning afbrydes Spændingsforsyningen skal være kablet, ligesom kommunikationsvejen. Dermed er kablet til spændingsforsyningen, ligesom kommunikationskablet, i fare for at sætte sig fast og/eller blive afbrudt under sejlads. Afbrydes forsyningen midt i en automatisk eller manuel sejlads vil ubåden slukke og brugeren vil miste kontrollen over den. For at undgå det skal ubåden udstyres med et batteri, så den er i stand til selv at komme til overfladen hvis den kablede forsyning afbrydes. Batteriet skal have tilstrækkelig kapacitet til at ubåden kan transportere sig selv til overfladen fra maksimal dykkedybde samt udsende et nødsignal, så ubåden hurtigt kan findes og repareres. Kablet sidder fast Den kablede kommunikation mellem ubåden og fjernstyringen, kan potentielt komme til at sidde fast så det ikke er muligt at navigere med ubåden, og at kablet kan blive beskadiget. Der skal være en måde hvorpå ubåden kan detektere at kablet siddet fast og dermed undgå at der sker skade på det. Ubåden skal i dette scenarie kommunikere en fejlmeddelelse til brugeren. Ubåd sidder fast Under dykning i Limfjorden er der fare for, at ubåden sætter sig fast i tang, fiskenet eller lignende. Specielt ubådens ror, skrue og kommunikations-/spændingskabel er i fare for at vikle sig ind. Sætter ubåden sig fast under automatisk sejlads, uden at systemet har mulighed for at opdage det, kan ubåden forvolde skade på sig selv. Derfor skal ubåden melde fejl, hvis den registrerer at den sidder fast. Da ubåden sandsynligvis vil sætte sig fast i noget under vand og derfor behøver at blive bjerget af en dykker, skal der kommunikeres en fejlmeddelelse med lokation af ubåden til brugeren. 21

22 Fejl på sensorer Ubåden indeholder sensorer, som skal hjælpe brugeren med at navigere ubåden samt at få data om f.eks. dybde og hastighed. Hvis systemet oplever en fejl på en af sensorerne, skal det automatisk reagere ved at sende en fejlmeddelse til brugeren om, hvilken sensor der er fejl på. Fejl på aktuatorer Ubådens fremdrift, ror og dykkemekanisme er alle funktioner, som er drevet af mekaniske aktuatorer. Hvis systemet oplever en fejl på en af aktuatorerne skal det automatisk reagere. En fejlsituation er opstået, hvis ikke ubåden reagerer som forventet. Hvis der sker en fejl på en af aktuatorerne, vil brugeren potentielt miste den fulde kontrol over ubåden eller systemet vil være ude af stand til at styre ubåden korrekt under automatisk sejlads. Hvis systemet oplever en fejl skal den advare brugeren ved at sende en fejlmeddelelse om, hvilken aktuator der er fejl på. 2.6 Ubådsmodel Til dette projekt ønskes en ubåd, som i forvejen er sødygtig, da projektet omhandler udvikling af elektronik. På baggrund af kapitel 2 er den ønskede funktionalitet fundet. De krav som har relation til ubåden og dens aktuatorer, altså ikke sensorer og software, er at den skal kunne sejle mindst 1,5 knob og dykke til en dybde på 16 m. Yderligere vurderinger med hensyn til valget af ubåd er hvorvidt der internt er plads til den hardware der ønskes udviklet. Da der ikke på nuværende tidspunkt vides hvor meget hardwaren kommer til at fylde bliver valget baseret på et skøn. Af ubådene der er økonomisk tilgængelige, er ubåden, som kommer nærmest at opfylde kravene, en Thunder Tiger Neptune. Dens specifikationer samt et billede af den er vist på henholdsvis tabel 2.1 og figur 2.4. Specifikation Maks. hastighed under vand Maks. hastighed over vand Dykkemekanisme Anbefalet maks. dykdybde Absolut maks. dykdybde 1, knob 1,5 knob Statisk 5 m 10 m Tabel 2.1: Ubådsmodellens specifikationer. Modellen kommer monteret med aktuatorer til fremdrift, ror og dykning. Ubåden er, med den transparente halvkugle i fronten, gjort klar til montage af kamera. Der vurderes at pladsen indeni ubåden vil være tilstrækkelig, da det interne 12 V batteri kan tages ud. Der benyttes én motor til fremdrift, én motor til at drive balasttankens pumpe samt en servo til 22

23 Figur 2.4: Billede af ubådsmodellen at kontrollere roret og en til at kontrollere dykkevingerne. Disse aktuatorer kontrolleres af brugeren med en fjernstyring. I modellen er der allerede implementeret sikkerhedssystemer i form af sensorer, som skal sikre at ubåden ikke forliser under en dykning. Når ubåden registrerer en lækage, at det indbyggede batteri er tæt ved afladt eller at signalet mellem ubåden og controlleren er for lavt tømmer den ballasttanken så den flyder til overfladen. Det indbyggede sikkerhedssystem vil ikke blive brugt i dette projekt, da der ikke vide hvorledes der interageres med det eksisterende system. Den valgte ubåd opfylder, som det kan ses på tabel 2.1, hverken kravet om hastighed eller om dybde og det vil derfor være denne der begrænser listen af krav til de endelige krav i kravspecifikationen. Ubåden er dog stadig set som egnet til udvikling af en prototype. 2.7 Afgrænsning af funktionalitet At opnå alle funktionaliteterne, beskrevet i dette kapitel, vurderes som urealistisk for dette projekt. Derfor afgrænses projektet fra at: Håndtere fejlscenarier Have automatiseret sejlads Indeholde kamera Dette betyder, at der ikke er behov for batteriet i ubåden, hvormed der er mere plads til hardware. Desuden benytter den valgte ubåd sig af statisk dykning, hvilket, ifølge afsnit 2.2, vil sige, at styringen af dybden skal være trinvis. Dette skal fungere med to trykknapper og et display. 23

24

25 Kravspecifikation 3 I løbet af kapitel 2 er der fundet krav til den ideelle løsning, i forhold til at være testplatform med virkeområde i Limfjorden. I afsnit 2.7 afgrænses disse krav til hvilke der, i dette projekt, ønskes opnået med hensyntagen til den udleverede ubåds egenskaber, som beskrevet i afsnit 2.6. De resterende krav er opstillet i tabel 3.1 og danner grundlag for den videre udvikling. Kravene, som den udleverede ubåd bestemmer, er ikke taget med i dette. Område Krav Ubåd: Dybde Målepræcision ± 0,1 m Fremdrift Målepræcision ± 0,1 knob Retning Målepræcision 1 Styring: Dybde Trinvis Fremdrift Trinvis Retning Trinløs Display: Dybde Opløsning 0,1 m Fremdrift Opløsning 0,1 knob Retning Opløsning 1 Tabel 3.1: Kravspecifikation 25

26

27 Minimumssystem 4 For at have en base at udvikle ubådens styring ud fra designes et minimumssystem. Et minimumssystem er, i denne sammenhæng, at forstå som det mindste antal elementer der skal til for at få et fungerende mikrodatamatsystem til at køre. Ud fra minimumssystemet kan tilføjes forskellige perifere elementer for at udvide funktionaliteten. Det er nødvendigt at udvide med sensorer, aktuatorer og kommunikationsmodul, for at kunne interagere med ubåden i henhold til kravene. I dette kapitel gennemgåes opbygningen af det simpleste system, som er nødvendigt for at køre en TS2MON debugger. I dette projekt består minimumssystemet af: Processor ROM RAM Clock generator Adressedekoder Interrupt controller For at sikre at processoren starter rigtigt op og ikke arbejder ved for lave spændinger benyttes en watchdog, hvilket dog ikke er en essentiel del af minimumssystemet. For at kunne interagere med processoren på en analog snitflade skal der benyttes både ADCog DAC-komponenter. Disse er som watchdog en ikke essentielle, men en vigtig del af et system hvis formål er at agere testplatform for sensorer. For at muliggøre programmering af systemet fra en anden enhed benyttes et kommunikationsinterface. Ydermere lettes fejlfinding af koden ved at implementere en debugger. Da denne sætter flere krav til minimumssystemet, er den inkluderet i dette afsnit. Som processor til minimumssystemet er valgt en Motorola M68k, da undervisningen tager udgangspunkt i denne type. 27

28 4.1 Debugger For at kunne fejlfinde på software under udviklingen af ubådsstyringen, implementeres en debugger, TS2MON, i minimumssystemet. Argumentet for netop at vælge denne debugger er, at den er blevet gennemgået i undervisningen. Via TS2MON og det, af denne, påkrævede RS232 kommunikationsinterface er der mulighed for at overføre softwaren under udvikling til RAM, og derved undgå at skulle brænde nye ROM, hver gang en ny version skal testes. TS2MON giver mulighed for at indsætte breakpoints samt single step e i koden direkte på minimumssystemet, hvilket er et nyttigt værktøj til debugging. Debuggeren sætter nogle krav til minimumssystemets opbygning. Det påkrævede kommunikationsinterface skal bestå af en MC6850 ACIA [13] som skal ligge på specifikke adresser, som vist i figur 4.1. Da debuggeren ligger i ROM og benytter RAM under afvikling stiller den krav til hvilke adresser der er ROM og RAM på, samt hvilke adresser brugerprogrammet ikke må benytte. De omtalte adresser er vist på tabel 4.1. Adresse Navn h. Debugger ROM FF h h. Debugger RAM FFF h h ACIA status- og kontrolregister h ACIA Rx- og Tx-register Tabel 4.1: Hukommelseskrav sat af debuggeren. Da RAM ene starter i h sætter det en begrænsning på ROM en, da den derfor maksimalt kan gå til 0003 FFFF h. Dermed er ROM ens størrelse begrænset til 256 KiB, hvoraf debuggeren bruger 6 KiB. 4.2 Microprocessor Kernen i systemet er microprocessoren, som i dette projekt er valgt til at være en Motorola MC68HC000FN16, herefter kaldet M68k. M68k kan ikke fungere uden eksterne enheder, da den udelukkende er en processeringsenhed. Det er microprocessoren som sætter krav til hvilke perifere enheder der skal tilsluttes, for at minimumssystemet kan køre. For at afgøre hvorledes de perifere enheder skal implementeres i minimumsystemet skal der undersøges hvordan de skal interface med microprocessoren. Processoren interfacer med perifere enheder med inputs og outputs vist på figur

29 Figur 4.1: Inputs og outputs på M68k [5] Clock generator M68k kan operere med en ekstern clock generator med en frekvens mellem 8 og 20 MHz. I forbindelse med undervisningen modtaget på dette semester er der blevet foreslået 8 MHz, hvilket derfor er blevet valgt. Til dette benyttes en AQO 14 på 8 MHz, som skal have en 5V forsyning [6]. M68k stiller krav om en maksimal rise- og fall-tid på 10 ns, hvilket er garanteret af AQ0 14 ifølge databladet Read/Write operationer M68k har en 23 bit bred adressebus (A1-A23) og de to signaler LDS og UDS, som tilsammen gør det muligt at adressere 16 MiB. Selve adresseringsprocessen tager et stykke tid, da adressebussens bits skal være stabile før den perifere enhed skal aflæse dem. Når adressen på adressebussen er stabil sættes AS af M68k lav. Derfor kan AS bruges i adresselogikken til at sikre at den perifere enhed først aktiveres når adressen er stabil. På timingsdiagrammet for Read/Write-cycles, vist på figur 4.2, ses tiden, der går fra at adressen bliver lagt på bussen til den anses for at være stabil. Tiden findes i databladet til 20 ns [5]. Når adressen er stabil vil LDS, UDS eller begge blive sat lav. Disse er data-strobes, som bruges af M68k til at angive hvorvidt der arbejdes med de nederste 8 bit, de øverste 8 bit eller et helt 16 bit ord. I denne forklaring vil der blive taget udgangspunkt i en Read/Write operation med de nederste 8 bit. En generel 8 bit Read operation gennemgår nogle faste trin hvor bestemte pins sættes: 1. R/W sættes højt, for at signalere en Read operation og funktionskoden for den igangværende funktion sættes på FC0-FC2 2. Den ønskede adresse lægges ud på adressebussen 3. Når adressen er stabil sætter M68k AS og LDS lav 29

30 Figur 4.2: Timingdiagram for Read/Write-cycles på M68k [5]. 4. Processoren venter på at den adresserede enhed signalerer at data på databussen er stabil ved at sætte DTACK lav 5. Dataen læses af processoren hvorefter den sætter AS og LDS høj 6. Den adresserede enhed sætter DTACK høj hvormed operation afsluttes Denne operation tager, uden wait states, 4 clock cycles, hvilket også er gældende for en Write operation. Wait states opstår hvis den adresserede ikke sætter DTACK før eller præcis når processoren er klar til at tjekke tilstanden af DTACK. Derfor er der kun behov for at implementere logik til styring af DTACK hvis der, i systemet, er adresserbare enheder, som er langsommere end 2 clock cycles, som er den tid det tager fra at AS går lav til at processoren er klar til at tjekke DTACK. For en Write operation skal dataen, som processoren lægger på databussen, være læst af den adresserede enhed før 2 clock cycles, 250 ns. I forhold til timing og Read/Write operationer er der ét specialtilfælde for M68k. Hvis en perifer enhed i M6800 serien adresseres kan processorens M6800 Peripheral Controls tages i brug. Disse er vist på figur 4.1. Dette interface kan synkronisere den tilsluttede enhed med processoren så der ikke er behov for DTACK eller at tage timing i betragtning i det hele taget. Selve synkroniseringen med den perifere enhed sker med E, som er en clock der startes når VPA sættes lav. VPA sættes lav i forbindelse med at en M6800 enhed adresseres. Det vil sige at der skal tages hensyn til dette i adressedekoderen. Når VPA er sat lav og processoren og enheden er synkroniseret via E, sætter processoren VMA lav for at signalere at synkroniseringen er sket og at adressen på adressebussen er stabil. Også VMA skal med i adresselogikken da M6800 enheden ikke skal chip selectes før adressen er stabil Timingskrav M68k processoren stiller krav til dens perifere enheders timing, som er forklaret i tidligere afsnit. De situationer hvor timingskrav skal tages i betragtning er ved almindelige 30

31 Read/Write operationer, både med 8 bit og 16 bit data. For en M6800 enhed behøves ingen overvejelser om timing da denne er designet til specifikt at arbejde sammen med M68k. Det mest kritiske timingskrav er accesstime på enheder under en Read operation. Ud fra timingsdiagrammet på figur 4.3 kan kravene for en enhed der skal læses fra afgøres. Figur 4.3: Detaljeret Read cycle timingsdiagram. Når AS går lav chip selectes den læsbare enhed. Dataen fra enheden skal ligge på databussen før DATA IN vinduet lukkes. Den tid processoren minimum skal bruge på at tilgå data fra en læsbar enhed er 3 clock cycles. På denne tid skal adressen sættes valid, blive tilgået og data skal blive valid. For M68k er der givet en t CLAV på 70 ns, og en t DICL på 15 ns, og der kan ved brug af disse oplysninger bestemmes den maksimale tid den kan bruge på at tilgå adressen. 3 clock cycles = t CLAV + t acc + t DICL (4.1) 31

32 375 ns = 70 ns + t acc + 15 ns t acc = 290 ns (4.2) En perifer enhed, med en mindre access time til adresserne end 290 ns, vil, som vist i formel (4.1) og (4.2), ikke skabe behov for wait states på processoren når den skal tilgåes. 4.3 Hukommelse Hukommelse skal bruges til at gemme data der skal kunne hentes af mikrocomputersystemet. Til design af minimumssystemet, er der set på forskellige typer random access memory (RAM) og read-only memory (ROM). Den væsentligste forskel mellem RAM og ROM, er at det er muligt at skrive til enkelte bytes i RAM. Ved ROM er dette ikke tilfældet, nogle typer ROM kan ikke genskrives, og hvis det er muligt bliver man nødt til at skrive til hele blokke. Dataen i RAM mistes desuden så snart systemet slukkes, hvor ROM gemmer sin data. Derfor bruges ROM til at gemme software, hvor RAM bruges som midlertidigt datalager Random Access Memories Der findes to hovedtyper af RAM: Static og dynamic. Dynamic RAM virker ved brug af en transistor og en kondensator, hvor spændingen over kondensatoren repræsentere en binær værdi. Fordelen ved dynamic RAM er at, designet giver større kapacitet på samme areal, dog med ulempen at de skal oplades med kort mellemrum for at holde sin værdi, også kaldet RAM refresh. Den anden type RAM er static RAM, der bruger flere komponenter per bit, men holder tildelte værdier så længe systemet er tændt. Der er i dette projekt valgt at bruge to 8-bit static RAM af typen SRM20100LC. RAM- IC en kræver 17 adresseben for at tilgå alle 128 KiB plads. Desuden findes der nogle inputs, der er nødvendige for at styre RAM: CS1 (Chip Select 1), OE (Output Enable) og WE (Write Enable). I tabel 4.2 er der vist hvilke input der er krævet for at tilgå de forskellige funktioner. På figur 4.4 kan det ses hvordan SRM20100LC eren er tilsluttet. Mode CS1 OE WE Read Write 0 X 0 Outputs Disable Standby 1 X X Tabel 4.2: Sandhedstabel for forskellige pins på SRM20100LC for ønskede funktioner. Der er ikke brug for wait states hvis t acc vist på figur 4.5 er mindre end de 290 ns der blev beregnet i afsnit som mindste tid processoren kan nå at tilgå adressen på. Tiden 32

33 Figur 4.4: Tilslutning af RAM [7]. t acc er aflæst i databladet til maksimalt 70 ns, hvorfor der ikke er brug for at indføre wait states, når skal læses fra RAM. Figur 4.5: Read timingsdiagram for RAM [7]. Ved skrivning til RAM skal der undersøges om t AW, vist på figur 4.6, er mindre end 290 ns, for at sikre sig der ikke er brug for wait states. Der er fundet at t AW maksimalt er 60 ns, hvilket gør, at der ikke viser sig nogle timingsproblemer når der skal skrives til og læses fra RAM. For at kunne arbejde med 16 bit er CS1 styret ved et signal fra adressedekoderen, forbundet ved brug af en AND-gate, med LDS for den nederste halvdel af adresserne til RAM L, og med UDS for den øverste halvdel af adresserne til RAM U. Til implementering af ROM er der brugt samme metode med ROM L for de nederste og ROM U for de øverste adresser. 33

34 Figur 4.6: Write timingsdiagram for RAM [7] Read-Only Memories Der findes flere forskellige typer read-only memories, hvor den mest simple type blot benævnes ROM, der ikke kan modificeres og derfor skal bygges af producenten til den specifikke opgave. Der er derfor fordele ved brug af ROM når der skal produceres mange enheder der ikke skal kunne ændres på et senere tidspunkt. En mere relevant type er EEPROM, Electrically Erasable Programmable Read-Only-Memory, der kan slettes ved brug af en puls og har mulighed for at blive modificeret af microcomputeren. EEPROM er en bestemt type PROM. PROM har tilfælles at de kan skrives til en eller flere gange af brugeren, hvor forskellen fra type til type er hvor mange gange der kan skrives til dem, og hvordan data slettes fra enheden. Standard EEPROM er en relativt langsom form for hukommelse, set i forhold til eksempelvis RAM. Hurtigere versioner findes dog, såsom flash-hukommelse [8]. Flashhukommelse har til gengæld den ulempe, at de kun kan modtage ca tilskrivninger. Dette ses ikke som et problem for dette projekt, da systemets ROM udelukkende benyttes til at læse fra. Der er valgt at bruge flash-hukommelse af typen Am29F010B, hvorpå debugger lægges. Am29F010B kræver 17 adresseben da den indeholder 128 KiB hukommelse. Opsætning af ROM blokken er udført ved at sætte WE til forsyningen, da den i systemet kun skal kunne læses fra. OE sættes til RD der er koblet til adressedekoderen. På figur 4.7 er opsætningen af ROM vist. For ROM er det kun nødvendigt at undersøge timingsproblemer med at læse fra dem, da de ikke skal skrives til under programafvikling. Figur 4.8 viser timingskravene givet af systemets ROM. Der er samme krav til ROM som der er til RAM, og der er derfor undersøgt den maksimale tid det tager at tilgå adressen, t acc. Den maksimale tid ROM en skal bruge på at tilgå adressen er 90 ns, hvilket betyder det ikke vil være nødvendigt med indsatte wait states. 34

35 Figur 4.7: Tilslutning af ROM [9]. Figur 4.8: Timingsdiagram for ROM [9]. 4.4 Kommunikation i minimumssystemet For at kunne modtage og sende kommandoer mellem minimumssystemets debugger og en computer skal der designes et kommunikationsinterface. Der er valgt at bruge seriel kommunikation ved brug af RS232 standarden, hvilken er kompatibel med en computers 9-pins serielle interface. Da der i vejledningen til debuggeren [10] benyttes en MC6850 ACIA, Asynchronous Communication Interface Adapter, sammen med en MAX232A, en RS232 driver, er dette valgt. ACIA en laver en parallelt overført byte om til en seriel byte, hvorefter RS232 driveren laver spændingsniveauerne om til hvad RS232 foreskriver. I debuggerens vejledning er der beskrevet at MC6850 mappes til adresserne: h og h, som henholdsvis adresseres for at tilgå kontrol- og statusregistrene og for at tilgå, sende og modtage registrene. Kravene til det serielle kommunikationsinterface er vist i tabel

36 Område Kommunikationsstandard Adressering RS232 driver type ACIA type Krav RS232 Status- og kontrolregister: h Rx- og Tx-register: h MAX232A MC6850 Tabel 4.3: Krav til minimumsystemets serielle kommunikationsinterface. RS232 standarden RS232 er en standard for seriel kommunikation som definerer elektriske karakteristika for signaler på ind/udgange, kommunikationsinterfacet samt connectoren. RS232 definerer at en høj bit svarer til et spændingsniveau mellem -3 og -15 V og en lav svarer til mellem 3 og 15 V. Desuden definerer standarden en række handshakes mellem de to kommunikerende enheder, som blandt andet kan signalere om en enhed er klar til at modtage eller sende data. RS232 connectorerne er vist på figur 4.9, hvor der til venstre er vist en 25-pin connector og til højre en 9-pin. På figuren er også noteret de forskellige pins funktion. Connectoren anvendt i dette projekt er en 9-pin da det er hvad der er monteret på det udleverede udviklingsboard. Figur 4.9: RS232 connectorer [11]. MC6850 Fordelen ved at vælge MC6850 fremfor en anden ACIA er at den er lavet til M68k. Det betyder at den benytter sig af Motorolaens MC6800 Peripheral Controls, som er lavet til MC6800-serie perifere enheder, såsom MC6850. Når MC6800 Peripheral Control benene kan benyttes, synkroniseres MC6850 automatisk, via E, til processoren, hvilket overflødiggører brugen af DTACK. MC6850 har brug for en Rx-/Tx-clock for at have samme symbolrate, baudrate, som enheden der kommunikeres med, som i dette tilfælde 36

37 er en computer. MC6850 har desuden også brug for at blive initialiseret via dens control register. Interne registre i MC6850 MC6850 stiller fire interne registre til rådighed: Transmit Data Register (TDR), Recieve Data Register (RDR), Control Register (CR) og Status Register (SR). I TDR skrives den byte der ønskes sendt og i RDR læses den byte som er blevet modtaget. Når en byte ønskes sendt ligges den ud på databussens første 8 bit. TDR er det register som dataen fra bussen latches til når MC6850 eren er i skrive-tilstand. RDR er, modsat TDR, et register hvor der kun er læseadgang. I dette register lagres den indkommende serielle byte som computeren har sendt. SR bruges af MC6850 eren til at angive dens status. Dens status kan løbende hentes af softwaren på systemet for at kontrollere at intet er gået galt. Det 8 bit lange registers betydning er angivet i tabel 4.4. Bit nr. Funktion 0 Recieve Data Register Full (RDRF) 1 Transmit Data Register Empty (TDRE) 2 Data Carrier Detect (DCD) 3 Clear To Send (CTS) 4 Framing Error (FE) 5 Receiver Overrun (OVRN) 6 Parity Error (PE) 7 Interrupt Request (IRQ) Tabel 4.4: MC6850 Status Register [13]. Hver enkelt bits funktion vil blive yderligere forklaret i forbindelse med at det bliver brugt, da det ikke er alle statusbits, som er nødvendige at benytte. Der er udelukkende læseadgang til SR, da det er MC6850 eren, som sætter bit ene. CR kan der kun skrives til. Registret benyttes typisk kun i initialiseringen af systemet, som foretages når det startes. Hver enkelt bit s funktion er vist i tabel 4.5. Initialiseringen er integreret i debuggeren, hvormed der ikke skal tages hensyn til det i softwaren, som skrives i forbindelse med projektet. Debuggeren indstiller ACIA en til 8 bit, ingen paritetsbit, én stopbit og en clock division på 16. En seriel byte inkl. kontrolbittene er grafisk vist på figur Figur 4.10: Grafisk repræsentation af en seriel byte inkl. paritets- og stopbit. 37

38 Bit nr. Funktion 0 Counter Divide Select 1 (CR0) 1 Counter Divide Select 2 (CR1) 2 Word Select 1 (CR2) 3 Word select 2 (CR3) 4 Word select 3 (CR4) 5 Transmit Control 1 (CR5) 6 Transmit Control 2 (CR6) 7 Receive Interrupt Enable (CR7) Tabel 4.5: MC6850 Control Register [13] En paritetsbit sendes med hvis der ønskes mulighed for fejlkorrektion. Paritetsbitten er bestemt ved at lægge de tilhørende 8 databit sammen. Dette resulterer i en paritet, som er enten odd eller even. Hvis ACIA en er indstillet til odd paritet vil paritetsbitten være høj hvis pariteten er odd, og omvendt hvis ACIA en er sat til even paritet. Der kan på denne måde undersøges om der har været en fejl i dataoverførslen. Stopbitten optræder som den sidste bit efter en byte plus paritetsbit, hvormed den modtagende ende ved at datastrømmen er slut. Clock For at de enkelte bits, der sendes modtages korrekt i den modtagende ende, skal de kommunikerende enheder være synkroniserede. I debuggerens manual er defineret at systemet skal køre med en baudrate på 9600 og at MC6850 initialiseres til at have en clock division på 16. Det vil sige at clock en der tilsluttes Tx-/Rx-clock pin s skal være 16 gange hurtigere end den ønskede clock. Derfor skal den tilsluttede clock have en frekvens på 9600Hz 16 = 153, 6 khz. Da en krystal med denne frekvens ikke er tilgængelig implementeres en ekstern clock divider, HEF4020B [12]. Da en krystal med en frekvens på 4,9152 MHz er tilgængelig benyttes clock dividerens pin Q5, som giver en frekvens 32 gange mindre end hovedclock en. Dermed opnåes den korrekte frekvens: 4,9152MHz = 9600 Hz. Koblingen af clock og clockdivider kan ses på figur Implementering af kommunikation Da ACIA en ikke leverer spændingsniveauer, som er i overensstemmelse med RS232, tilsluttes en MAX232A RS232 driver, hvis funktion både er at lave ACIA ens niveauer om til RS232 og lave RS232 niveauerne fra computeren om til ACIA ens. ACIA en benytter spændingerne 0 V for logisk lav og 5 V for logisk høj, hvor RS232 bruger 12 V for logisk lav og -12 for logisk høj. Kommunikationsmodulet, bestående af ACIA, MAX232A og clock, kobles op som vist på figur

39 Figur 4.11: Kommunikationsmodulets tilslutninger. Kondensatorerne C5 til C8 er valgt ud fra en typical application i databladet for MAX232A. Handshakes fra ACIA en, CTS og DCD, er sluttet til stel da de ikke ønskes benyttet. Desuden er udgangen RTS ikke tilsluttet af samme grund. 4.5 Power-on-reset For at sikre at mikroprocessoren starter rigtig op skal benene HALT og RESET holdes lave i minimum 100 ms [5]. Til at udfører denne opgave skal der designes et timingskredsløb. Dette kunne f.eks. laves af logiske blokke, men for at gøre det mere kompakt og simpelt er der valgt at bruge en IC til at udføre opgaven. Der er valgt at bruge en TL7705 watchdog [14], og benspecifikationer er vist i tabel 4.6. Ben Navn Funktion 1 REF Reference 2 RESIN Input 3 CT Threshold kondensator 4 GND Stel 5 Vcc Forsyningsspænding 6 SENSE Overvågning af Forsyningsspænding 7 RESET Inverteret output 8 RESET Output Tabel 4.6: Benspecifikation af TL7705 [14]. Tl7705 har to operationer den skal udføre. Den skal sørge for at hvis forsyningsspændingen på SENSE benet kommer under 4,6 V vil den på output, RESET og RESET genere en reset puls. TL7705 giver også en puls på RESET og RESET når RESIN trækkes lav. Timingsdiagrammet for TL7505 er vist på figur 4.12 Idet RESET er aktiv lav, monteres der en pull-up modstand til forsyning, samt en kontakt der er forbundet til stel. Dette gør at det er muligt ved hjælp af kontakten at generer en reset puls. 39

40 Figur 4.12: Timingdiagram fra datablad af TL7705 [14]. Fordi HALT og RESET på M68k begge er aktiv lave forbindes de også ved hjælp af to pull-up modstande til forsyning, derudover kan HALT og RESET også anvendes som output. Dette gør at de ikke må forbindes direkte til hinanden, men dette løses ved at implementere to dioder. CT er threshold kondensatoren der justerer længden af den puls der genereres på RESET og RESET benene. I databladet er opgivet formlen, vist i ligning 4.3, for at udregne den. CT = t d 100 ms 1, = Ω 1, = 7, 69 µf (4.3) Ω Hvor: CT er threshold kondensatoren [F] t d er pulsbredden [s] I ligning (4.3) er CT beregnet til minimum at være 7,69 µf, og derfor vælges denne til at være 10 µf. Den færdige opkobling er vist på figur Interrupt Et interrupt er, i denne sammenhæng, en begivenhed som afbryder det planlagte program for at afvikle noget alternativ kode. Interrupts benyttes ofte til tidskritiske tilfælde, hvor det er vigtigt at koden afvikles med det samme. Dette kan eksempelvis være ved kommunikation eller hvis en sensor giver et specielt output, som kan være kritisk for den videre operation. Efter et stykke interruptkode er eksekveret returneres CPUen til dens 40

41 Figur 4.13: Kredløbdiagram af, hvordan TL7705 skal opkobles. tidligere stadie. Ved at benytte flere, prioriterede interruptindgange er det muligt at have prioriterede inputs, således at interrupts med højere prioritet afvikles før interrupts med lavere prioritet, også selvom det lavt prioriterede interrupt er i gang. Den eneste afvigelse fra denne regel er ved interrupt 7, den højest prioriterede interrupt. Denne kan interrupte en anden interrupt 7, hvilket vil sige at processoren altid arbejder med den nye interrupt, i sådan et tilfælde. Interrupts håndteres ved at give et active-low input på IPL0, IPL1 og IPL2, afhængigt af interruptets prioritet. Når et interrupt behandles sættes funktionspins, FC0, FC1 og FC2, høje. Dette kaldes IACK, Interrupt ACKnowledge, som indikerer at et interrupt skal behandles. IACK benyttes, sammen med adresseringspins, til at generere et VPA-signal. VPA-signalet signalerer til M68k at en autovektorinterruptrutine køres. En typisk interrupt-proces vil altså forløbe således, at den perifere enhed sender et interrupt signal til en interrupt controller, som angiver den korrekte værdi på IPL0, IPL1 og IPL2. Hvis processoren allerede er i gang med en interruptrutine, på højere eller samme niveau, sættes interruptet i kø. Når processoren er klar til at håndtere interruptet sendes et IACK til interrupt controlleren, som genererer VPA. Derefter eksekveres den ønskede interruptrutine. Til minimumssystemet benyttes ét interrupt til NMI. NMI-switchen, Non-Maskable Interrupt Switchen, tilsluttes til IRQ7. Det, at den er Non-Maskable, vil sige, at den ikke kan afbrydes af noget. NMI-switchen tillader, at man kan stoppe et program hvor det er, hvilket gør det muligt at aflæse de forskellige registre den benytter sig af. Dette letter debugging, da det gør det muligt at se hvor et program fejler og på den måde vide hvor i programmet det vil være nødvendigt at rette en fejl. På tabel 4.14 ses hvilket input det er nødvendigt at generere for at igangsætte en interruptsekvens. Dette leder an til en række boolske udtryk, som opstilles i equation (4.4) og (4.5). Disse implementeres ved hjælp af en PEEL-kreds. Af PEEL-kredsen kræves det, at der er 4 outputs og 9 41

42 inputs. Da overskydende pins ikke er et problem, men nærmere ønskværdigt, da dette giver mulighed for at udvide, benyttes den samme slags PEEL-kreds vi allerede benytter til adressedekoderen: 22CV10A. V P A = F C0 F C1 F C2 A3 AS A1 A2 NMI (4.4) IP L2 = IP L1 = IP L0 = NMI (4.5) 4.7 ADC Mikrocomputersystemet har, for at kunne bruge perifere sensores analoge output, en analog-til-digital konverter (ADC). Med udgangspunkt i Komponentens [15] udvalg af analog-til-digital konverter IC er, samt det faktum at Komponenten anbefaler én bestemt, benyttes en ADC0820 [16] i dette system. En ADC0820 er en 8-bit ADC, som konverterer med half-flash teknik, hvilket vil sige at den indeholder to 4-bit flash ADC er. Én 4-bit flash ADC til den mest betydende og én til den mindst betydende del af signalet. I tabel 4.7 ses ADC0820 ens pins med nummer, navn og dertilhørende funktion, når den er i RD Mode. Pin 18 indikerer som det ses i tabel 4.7 overflow. Dette betyder at den går lav når en konvertering er fuldført, hvis V IN er større end V REF(+), hvilket kan bruges til at meddele om fejl eller til at udvide opløsningen til 9-bit ved at koble den sammen med endnu en ADC. Denne pin er dermed ikke nødvendig til en 8-bit opløsning. I databladet er opstillet et diagram for en 8-bit opløsningsopkobling i RD Mode. Da der ikke kan findes noget argument for at WR-RD Mode skulle være nødvendigt er der valgt at benytte denne opkobling, der på figur 4.15 kan ses. Niveau Inputs IPL0 IPL1 IPL Figur 4.14: På denne tabel ses hvilke pins der skal sættes lave, for at generere et interrupt. 42

43 Pin Navn Funktion 1 V IN Analog inputspænding 2 DB0 Databit 0 (LSB)... 5 DB3 Databit 3 6 RDY Indikerer konverteringsstatus 7 MODE Valg mellem WR-RD Mode og RD Mode 8 RD Read 9 INT Indikerer konverteringsstatus 10 GND Stel 11 V REF( ) Nederste referencespænding 12 V REF(+) Øverste referencespænding 13 CS Chip Select 14 DB4 Databit DB7 Databit 7 (MSB) 18 OFL Indikerer overflow 19 NC Not connect 20 V CC Forsyningsspænding Tabel 4.7: ADC0820 pinnummer, -navn og -funktion. Figur 4.15: 8-bit opløsningsopkobling af ADC0820 [16]. 4.8 DAC Mikrocomputersystemet har, for at kunne styre perifere analoge aktuatorer, en digitaltil-analog konverter (DAC). Med udgangspunkt i Komponetens [15] udvalg af digital-tilanalog konverter IC er, samt det faktum at Komponenten anbefaler én bestemt, benyttes en AD7524 [17] i dette system. En AD7524 er en 8-bit DAC, som benytter sig af R-2R 43

44 ladder princippet. Den er desuden TTL-kompatibel ved +5 V forsyning. I tabel 4.8 ses AD7524 ens pins med nummer, navn og dertilhørende funktion. Pin Navn Funktion 1 OUT1 Udgangsspænding 2 OUT2 Udgangsspænding 3 GND Stel 4 DB7 Databit 7 (MSB) DB0 Databit 0 (LSB) 12 CS Chip select 13 WR Write 14 V DD Forsyningsspænding 15 V REF Referencespænding 16 R Feedback Feedback Tabel 4.8: AD7524 pinnummer, -navn og -funktion. Den har to tilstande den kan være i, afhængigt af hvordan CS og WR er sat, som vist i tabel 4.9. Under Write Mode føres det digitale input på DB0 til DB7 ud som analogt output. I Hold Mode holdes det analoge output svarende til det sidste digitale input modtaget i Write-mode. Mode CS WR Write 0 0 Hold 1 X Hold X 1 Tabel 4.9: Valg af tilstand for AD7524. Fra databladet er valgt en unipolær opkobling, der giver en sammenhæng mellem input og output, som beskrevet i tabel Af tabel 4.10 fremgår det ydermere at opløsningen af det analoge output er 2 8 V REF. Diagrammet for den unipolære opkobling, som er valgt, er vist på figur Modstandene, R1 og R2, samt kondensatoren, C1, er ikke implementeret. Som operationsforstærker er valgt en OPA27 [18]. V REF er 10 V, hviket giver en opløsning på det analoge output på 0,04 V. 44

45 Digital input Analogt output V REF (255/256) V REF (129/256) V REF (128/256) V REF (127/256) V REF (1/256) V REF (0/256) Tabel 4.10: Unipolær input-til-output beskrivelse. (MSB LSB) Figur 4.16: Diagram for unipolær DAC opkobling [17]. 45

46 4.9 Adressedekoder For at kunne sørge for at den rigtige enhed benytter databussen, på det rigtige tidspunkt, er det nødvendigt at chip selecte de rigtige chips, når det er nødvendigt. Ved at opstille et memory-map er det muligt at finde de adresseben som er unikt konstante for en given chip. Udfra disse er det muligt at opstille et logisk kredsløb, som kan chip selecte efter behov. Et virtuelt A0 kan skabes ud fra LDS og UDS. Hvis man går ud fra at LDS og UDS aldrig er det samme, findes der kun 2 tilstande de kan være i: UDS eller LDS. På denne måde har A0 ikke værdierne 0 eller 1, men derimod værdien LDS eller UDS. LDS og UDS kan dog begge være aktive samtidigt, hvilket giver A0 en tredje tilstand, den kan være i. Denne tilstand tillader at man kører både den nedre og den øvre del af databussen samtidigt, hvilket tillader 16-bits kommunikation. Ud fra memorymappet, i tabel 4.11, findes de binære værdier for start- og slutadresse på RAM og ROM, samt adresserne for ACIA, ADC og DAC. Disse kan ses i tabel Ud fra denne kan der ses at A19 og A18 konstant vil være 0, så længe ROM tilgåes. For RAM vil A19 være 0 mens A18 vil være 1. Desuden bruges UDS og LDS til at selecte henholdsvis upper og lower RAM og ROM. Ud over disse bruges AS til at sikre at adressen er stabil. Når alle parametrene er opfyldt kommer der et true signal på chip select på den pågældende chip, hvilket tillader kommunikation på databussen. Dette leder an til en række boolske ligninger, der kan benyttes til at chip selecte de forskellige IC er. RAM U = A19 A18 UDS AS RAM L = A19 A18 LDS AS ROM U = A19 A18 UDS AS ROM L = A19 A18 LDS AS Ud fra disse ligninger er det muligt at opstille et logisk kredsløb, som vist på figur Desuden er det nødvendig at afgøre om der ønskes at læse eller skrive. Dette gøres ved hjælp af en READ/WRITE-pin. På RAM og ROM findes der både en READ- og en WRITE-pin, hvilket nødvendiggør at signalet splittes op i to. Dette gøres ved hjælp af følgende boolske ligninger: READ = R/(W ) AS W RIT E = R/(W ) AS Disse er afhængige af AS, da det også er nødvendigt at disse er konstante, før de kan benyttes. Ved ROM er det dog kun nødvendigt med READ, da der aldrig skal skrives til den. Det logiske kredsløb, opstillet for READ/WRITE, kan ses på figur Endeligt vil A19 og A18 være 1 og 0, når ACIA, ADC og DAC skal tilgåes. Her varierer 46

47 Figur 4.17: Chip select-logik til ROM og RAM. Figur 4.18: Logiske kredsløb for READ/WRITE. A1 til A0 i stedet, for at kunne chip selecte det rigtige. ACIA = A19 V MA LDS AS V P A = A19 LDS AS + V P A_INT Ud fra de opstillede ligninger for ACIA en kan det logiske kredsløb på figur 4.19 opstilles. 47

48 Figur 4.19: Chip select-logik til ACIA. ADC = A19 A1 UDS AS DAC = A19 A1 UDS AS For ADC og DAC opstilles endnu et logisk kredsløb, som kan ses på figur Figur 4.20: Chip select-logik til ADC og DAC. De fire ovenstående logiske kredsløb implementeres i en PEEL. PEEL-koden kan findes i bilag [19]. 48

49 Adresse Navn h. Debugger ROM FF h h. Bruger ROM 0003 FFFF h h. Debugger RAM FFF h h. Bruger RAM 0007 FFFF h h. Ikke allokeret h h DAC h Ikke allokeret h ADC h. Ikke allokeret h h ACIA status- og kontrolregister h ACIA Rx- og Tx-register Tabel 4.11: Memorymap. 49

50 Adresse A23-A20 A19-A16 A15-A12 A11-A8 A7-A4 A3-A Navn ROM RAM LDS DAC LDS ADC LDS RegSelect LDS Rx/Tx Tabel 4.12: Memorymap binært. 50

51 4.10 Forsyning Systemet er forsynet med 5 V. Gennem undervisningen er der blevet tilrådet at koble to kondensatorer på forsyningen, for at holde spændingen stabil. Dette er krævet da delkomponenterne har et strømforbrug der varierer. Der er vist på figur 4.21, hvordan forsyningen er koblet op. Transzorp dioden er indsat for at sikre systemet mod forkert polaritet og for at fjerne transienter. Figur 4.21: Opbygning af 5 volt forsyning Implementering Implementeringen af minimumssystemet gav erfaringer, som dannede grundlag for en række ændringer i designet. Disse oplevelser og ændringer er beskrevet i dette afsnit. Board layout Minimumssystemets delsystemer forbindes med wire wrap. Denne metode til at koble komponenterne sammen og det faktum at det er et digitalt system introducerer nogle udfordringer i form af elektrisk støj. Årsagen til dette er at digitale signaler er firkantede pulser, som dermed består af sinustoner med potentielt uendeligt høje frekvenser. Signalerne sammenlagt med at forbindelserne i wire wrappet er krydset kan være med til at systemet ikke er funktionsdygtigt. For at fjerne støj på forsyningen er der inde på samtlige sokler til IC er monteret afkoblingskondensatorer på 100 nf mellem V CC og GND. For så vidt muligt at undgå støj er der designet et board layout, som vist på figur 4.22, hvor komponenter med relation til hinanden placeres tættest muligt. Desuden er forsyningen trukket så der er både GND og V CC ved siden af hver enkelt komponent. På den måde vil forbindelsen mellem forsyningen og en komponent blive med mindst mulig wrappe ledning, som der potentielt kunne indstråles støj på. 51

52 Figur 4.22: Minimumssystemets boardlayout. På figur 4.22 kan der også ses at komponentdækkene, hvorpå pull up/down-modstande og kondensatorer er monteret, er placeret så tæt på den IC den er forbundet til som muligt. Wrapning Systemet er wrappet efter første revision af eldiagrammet vist i bilag [20]. For at komme udvidelse af systemet i forkøbet valgtes det wrappe interrupt- og adressedekoder-peels til sidst, så forbindelserne ville være let tilgængelige hvis der skulle laves ændringer. Wrapningen blev udført i fem etaper: Forsyning og komponenter, databus, adressebus, interrupt-peel og adressedekoder-peel. Imellem hver etape blev alle nye forbindelser målt ud for at sikre at wrapningen var god nok. Første revision af eldiagrammet viste sig at være fejlbehæftet. For at sikre at AS, LDS, UDS og R/W går høje, som de skal, er der monteret pull up-modstande på. Desuden blev der glemt at sikre afkobling af processorens forsyning hvilket fik den til at halt e. Da afkoblingen blev monteret var det ikke længere processoren der halt ede men poweron-reset kredsløbet. Hver gang processoren gik i gang blev den halt et kort tid efter. Dette skyldtes at når systemet var i gang var der mere støj på forsyningen end når det var halt et. Den ekstra støj var nok til at reset-kredsløbet blev aktiveret, men så snart systemet blev halt et forsvandt støjen og systemet blev sat i gang igen, hvilket gentog sig med korte mellemrum. Det viste sig at fejlen skyldtes at GND forbindelserne til power-onreset kredsløbet og dets komponenter var forbundet til den fælles GND, men skulle have været forbundet til GND på IC ens sokkel, for at sikre at de er ens. Efter disse rettelser kører systemet, som det skal og er klar til at gennemgå accepttesten. Det rettede eldiagram er vist i bilag [21]. 52

53 4.12 Accepttest For at teste minimumssystemet er der valgt at undersøge om de forskellige delblokkes funktionaliteter virker efter hensigten. En liste over funktionaliteter der skal testes er derfor opstillet. Afvikling af kode på processoren Interface med enheder i minimumssystemet Afvikling af debugger program på processoren Afvikling af interrupts Interface med perifere enheder Hver funktionalitet er forsøgt testet med mindst indflydelse fra andre funktioner, for at gøre fejlfinding nemmere. Afvikling af kode på processoren For at bestemme om processoren virker, skal der undersøges, hvordan den håndterer en FNOP instruktion på databussen. Der ønskes at programcounteren tæller opad, og at dennes værdi kan aflæses på adressebussen. Afvikling af debugger program på processoren TS2MON debuggeren testes ved at forbinde minimumssystemet til en PC via RS232, hvortil debuggeren skal skrive en meddelelse. Yderligere skal debuggeren også reagere korrekt på en given kommando. Afvikling af interrupts Minimumssystemet har ét enkelt interrupt der skal testes for at systemets interrupt kan godkendes. Debuggeren afvikler NMI interrupt ved at tilsidesætte afvikling af brugerprogrammet. Til at udføre testen bruges et testprogram, som ikke udføre nogle handlinger, men blot hopper til starten af testprogrammet. Interface med DAC og ADC Til minimumssystemet er der valgt at have en DAC og en ADC. For at teste om de to perifere enheder virker sættes DAC til ADC, hvorefter DAC en giver forskellige spændinger der måles af ADC en. Hvis det viser sig at der er forskel på inputtet på DAC en i forhold til ADC en vil det være nødvendigt at teste de to seperat. 53

54 Resultat af accepttest Det har ikke været muligt at teste DAC og ADC på den ønskede måde, men istedet er de blevet testet hver for sig. Deltest Afvikling af kode på processoren Interface med enheder i minimumssystemet Afvikling af debuggerprogram på processoren Afvikling af interrupts Interface med DAC og ADC Opfyldt Tabel 4.13: Opnået succes med accepttest 54

55 Modulopbygning 5 Udover minimumssystemet er det nødvendigt med en controller, til at styre ubåden, samt en computer som binder det hele sammen og udfører udregninger på de målinger ubåden foretager. Desuden benyttes et kommunikationsmodul samt sensorer og aktuatorer, for at ubåden skal kunne fungere. Disse er opdelt i moduler, for at gøre det nemmere at teste, samt for at kunne lade udviklingen af dem foregå seperat. Controlleren sender kommandoer til computeren, som behandles og sendes videre til M68k, som ved hjælp af sine sensorer og aktuatorer returnerer det output computeren beder om. Modulopdelingen ses på figur 5.1. Figur 5.1: Figur over de forskellige moduler. 55

56 5.1 Computer Computeren fungerer som master i systemet; det er her al udregningen foregår, og her der styres om det er tilladt for ubåden at bevæge sig længere op eller ned. Computeren beder M68k om at foretage målinger og beregner, ved hjælp af disse målinger, om det er tilladt for ubåden at dykke eller stige, samt ubådens hastighed og position. Desuden videregives disse udregninger til brugeren. 5.2 Kommunikation Det er nødvendigt at benytte en ACIA til kommunikation mellem minimumssystem og styrecomputer. Dette er nødvendigt da debuggeren benytter den første ACIA, og ændrer i statusregisteret når man benytter NMI-switchen. Derfor er det nødvendigt at have to RS232 kommunikationslinier, til debugging under udvikling. 5.3 Sensorer Der skal, for at kunne måle de, i kravspecificationen, opstillede parametre, benyttes en sensor der kan registrere fremdrift og position, en sensor der kan registrere dybde samt en sensor, som kan registrere når ballasttanken er fyldt eller tom. Fremdriften og positionen kan udregnes ud fra 3 forskellige informationer om ubådens bevægelse: Acceleration, hastighed og position. Hvis én af dem er kendt, er det muligt at udregne de 2 andre, ved hjælp af integral- og differentialregning. Positionen kan findes ved hjælp af eksempelvis et GPS-system. Ved at differentiere én gang, fåes hastigheden; differentieres to gange fåes accelerationen. GPS har den ulempe at det ikke fungerer under vand, men den fordel at det benytter et absolut koordinat-system, hvilket gør det muligt at udregne hastigheden i absolutte retninger, frem for relative. Dette gør det nemmere at finde retningen ubåden bevæger sig i. Hastigheden kan findes ved hjælp af eksempelvis flowmetere, monteret uden på ubåden, som måler vandstrømningen henover ubåden. Dette giver hastigheden som vandet flyder forbi ubåden med, og gengiver derfor ikke ubådens hastighed præcist. Fordelen ved at kende hastigheden, er at det kun er nødvendigt at integrere eller differentiere én gang, for at finde henholdsvis positionen og accelerationen. Dette minimerer fejlen der kommer som følge af upræcise målinger. Hastighedmåling benytter sig af et relativt koordinatsystem, hvilket komplicerer måling af retning. Dette kunne eksempelvis løses ved at montere hastighedssensorer på hver side af ubåden, og måle forskellen imellem dem. 56

57 Accelerationen kan findes ved hjælp af et accelerometer, og integreres op, for at finde hastigheden og positionen. Fordelen ved at benytte et accelerometer, er at det kan monteres inde i ubåden, uden at skulle kommunikere med noget eksternt. På denne måde kan bevægelsen registreres uanset hvilket miljø ubåden befinder sig i. Ulempen er at accelerometeret går ud fra at ubåden starter med en hastighed på nul. Et accelerometer benytter desuden et relativt koordinatsystem. Der er valgt at benytte et accelerometer, da dette ikke kræver nogle ændringer af ubådens ydre, eller kræver nogen form for trådløs kommunikation. Da dybden er positionen i z-aksen, benyttes accelerometeret også til at måle dybden. Hvis man måler strømmen af vand, der flyder ind og ud af ballasttanken, kan denne integreres op, for at finde ud af hvor meget vand der befinder sig i ballasttanken. I takt med at ballasttanken bliver fyldt, vil trykket i den desuden stige. Dette giver to forskellige metoder at måle ballasttankens niveau: tryksensor eller flowmeter. Da slangen til pumpen i ubådsmodellen, beskrevet i afsnit 2.6, allerede er lavet til at inkludere en tryksensor, og da det direkte giver os den information vi har behov for at vide, er der valgt at benytte en tryksensor. 5.4 Aktuatorer For at kunne drive ubåden er det nødvendigt med en fremdriftsmotor, et ror til at styre retningen samt en pumpe der styrer mængden af vand i ballasttanken. Der findes to måder at styre hastigheden på motorerne på: PWM eller spændingstyret. Fordelen ved PWM er, at niveauerne er lineære, når de føres igennem en H-bro, hvilket ikke er tilfældet ved spændingsstyring. Fremdriftsmotoren benytter sig af et PWM signal for at styre den afsatte effekt. Til dette benyttes 2 adresser der adresserer et PWM-modul: En til fremdrift og en til at bakke. For at kunne sejle både frem og tilbage med ét PWM-modul, benyttes også en udgang som definerer retningen. Til at styre roret benyttes en servo. Denne skal styres med endnu et PWM signal; pulsens længde bestemmer hvilken position servoen befinder sig i. Til denne er det kun nødvendigt med én adresse, da denne står stille ved et konstant PWM-signal, og det derfor ikke er nødvendigt at retningsbestemme eller slukke for signalet, som ved fremdriftsmotoren. Dette gennemgåes i afsnit 8.3. For at styre dybden benyttes en pumpe, som kan fylde en pose, inde i ubåden, med vand. Det er på denne måde ikke nødvendigt at styre hvor hurtigt posen tømmes; det er tilstræk- 57

58 keligt at styre om der kommer vand ind eller ud af posen. Denne styres med en DAC, hvor der skiftes mellem 3 niveauer, op, ned og slukket. 58

59 Kommunikationsmodul 6 For at kunne modtage informationer om ubådens tilstand fra debuggeren, samt sende kommandoer til den, skal endnu en ACIA implementeres i systemet. Denne ACIA implementeres på samme vis som debuggerens bortset fra, at den skal sættes op til at interrupte, således at programmet ikke skal poll e hele tiden. Årsagen til at endnu en ACIA skal implementeres er, at når debuggeren benytter den nuværende ACIA til at sende debug information, er der ingen umiddelbar kontrol eller vished om, hvad den foretager sig. Kravene til dette modul er vist i tabel 6.1. Område Krav Kommunikationsstandard RS232 Interruptniveau 4 Tabel 6.1: Kravene til kommunikationsmodulet. Kommunikationsinterfacet skal kommunikere i henhold til RS232 og interrupte med et niveau 4 interrupt. Da der ikke forventes flere interrupts end dette, og debuggerens NMI, er niveau 4 valgt. ACIA nummer 2 kaldes i resten af rapporten ACIA Implementering ACIA 2 implementeres på samme måde som debuggerens ACIA med den forskel, at IRQ er tilsluttet interrupt controlleren og dens 8 bit databus er tilsluttet den øvre databus, D8-15, på M68k. Årsagen til, at den øvre databus benyttes, er for at lette adressedekodningen, da debuggerens ACIA og ACIA 2 vil ligge på de samme adresser kun med LDS og UDS til forskel. På denne måde skal der ikke bruges flere indgange på adressedekoderen. Hardwaren implementeres som vist på figur 6.1. ACIA 2 benytter den allerede implementerede MAX232A, da den har to ind-/udgange og debuggerens ACIA kun optager det halve. For at kommunikere med ACIA 2 monteres endnu et D-SUB9 stik på systemet, så en computer kan tilsluttes. 59

60 Figur 6.1: Implementering af ACIA Initialisering For at kunne benytte ACIA 2 skal den, via dens control register, initialiseres med de ønskede indstillinger. Initialiseringen finder sted i starten af koden og vil bestå af en byte med den værdi, som er afgjort af de ønskede indstillinger. I tabel 4.5 er betydningen af bittene i ACIA ens control register vist. Den binære værdi der skal skrive til registeret bliver b, som er 149 i decimal. Specifik kode til initialiseringen af ACIA 2 vil blive forklaret i afsnit Accepttest Måleresultaterne til kommunikationsmodulets accepttest er angivet i målejournalen appendiks G og i tabel 6.2. Kravet om at kommunikationsstandarden skal være RS232 er opfyldt idet det er en faktor bestemt af de valgte komponenter. At komponenterne opfylder RS232 er testet ved at sende og modtage kendt data imellem modulet og en computer. Testen viste sig succesfuld, hvormed kravet er opfyldt. Testen viste ydermere at interrupt niveau blev genereret korrekt hvormed samtlige krav er opfyldt for dette modul. Krav Målt Opfyldt Kommunikationsstandard RS232 RS232 Intteruptniveau 4 4 Tabel 6.2: Resultater af kommunikationsmodulets accepttest. 60

61 Sensormodul 7 Sensormodulet indeholder det nødvendige hardware til at kunne måle ubådens acceleration samt om ballasttanken er tom eller fuld. Dette kapitel beskriver hvordan sensormodulet er opbygget med dets sensorer og ADC er. Minimumssystemet ændres så sensormodulet kan monteres derpå. 7.1 Ballasttankmodul For at vide hvornår ballasttanken er fyldt eller tom, er der valgt at montere en tryksensor på slangen til tanken. Med denne tryksensor kan der holdes øje med og reageres på, hvorvidt ballasttanken er i en af de uønskede tilstande, hvor den er enten helt fyldt eller helt tømt. Valg af måleudstyr For at afgøre hvilke sensore der skal bruges til at bestemme hvor fyldt ballasttanken er, er der undersøgt hvilke krav der skal opfyldes. Der ønskes målingen kan foretages på en fleksibel ballasttank, som den i ubåden. Der er valgt, at bruge en tryksensor af typen MPX5010DP [22], da denne kan holde til et tryk på 10 kpa, hvilket er mere end det maksimale tryk ved en fyldt ballasttank. Tryksensoren er sat på som vist på figur 7.1, hvorfor sensoren vil blive udsat for det tryk, der er i ballasttanken. Analyse af trykmåler Tryksensoren MPXV5010DP kan måle et tryk på mellem 0 og 10 kpa i forhold til trykket ved jordens overflade. Dette svarer til et maksimalt tryk på 0,1 atm. Der er et spænd på 4,5 V fra 0 til 10 kpa, med en usikkerhed på 5%. 61

62 Figur 7.1: Installation af tryksensor til ballasttank, billedet er taget under testopstilling med en ardouino til at aflæse data fra sensoren. Figur 7.2: Skitse af dynamikområde for MPXV5010DP. På figur 7.2 er der skitseret dynamikområdet for tryksensoren. Der antages som vist på billedet, at der vil blive brugt en 8 bit ADC, hvor det øverste område af ikke vil blive brugt, hvorfor målinger fra tryksensoren ikke kan opdeles i 256 områder, men 256 0, 9, hvilket er 230 områder. Der er en trykændring på op til 10 kpa, hvilket sammen med antallet af områder kan bestemme den maksimale præcision. P = Pa 230 inddelinger (7.1) 62

63 Pa P = 43, 5 inddeling (7.2) En præcision på 43,5 Pa vil ikke være en mærkbar fejlkilde, og en 8 bit ADC er derfor mere end nok, da der er en måleusikkerhed på 5% i tryksensoren, hvilket svarer til en usikkerhed i målingen på 500 Pa, mere end 10 gange så meget som usikkerheden grundet opløsningen, og der er derfor valgt ikke at forstærke tryksensorens output for at udnytte hele ADC ens dynamikområde. Fejl på grund af usikkerhed ved måling med tryksensoren kan minimeres ved kalibrering, dog vil unøjagtigheder hovedsagligt kunne tillægges usikkerheden på målinger. Dimensionering Tryksensoren er sat op, med V CC til 5 V og GND til 0 V. Outputtet, V out, er ført til ADC en der bliver beskrevet i afsnit 7.3. Indgangen, der skal måles på, er forbundet til ballasttanken ved hjælp af en slange som vist på figur 7.1. I databladet for tryksensoren ses det at tryk og output spænding har en lineær sammenhæng, hvilket giver et spændingsoutput fra 0,2 V til 4,7 V. Ud fra dette kan ses, at sensorens output bevæger sig over et område svarende til 230 af ADC ens niveauer. Sensoren er målt ved 1 atmosfære, hvor der ønskes en måling på 0, og resultatet af denne måling blev derfor bestemt til sensorens offset, 217,5 Pa. Herefter blev outputtet målt ved maksimal udstyring til Pa, hvor det skulle give Pa. Denne forskel korrigeres ved at dividere med 1,0831. For at undgå at overbelaste pumpen og ballasttanken, er der bestemt et maksimalt tilladt tryk i tanken på 4500 Pa, samt et minimalt tilladt tryk på 0 PaD. Dette overvåger computerprogrammet, ved at behandle målinger fra tryksensoren. Hvis én af grænserne overskrides vil det ikke længere være muligt for brugeren at sende et signal til M68k om yderligere at overskride grænserne. For at beregne trykket i ballasttanken, ud fra ADC-værdierne, er der fundet en formel for sammenhængen mellem tryk og ADC ens værdi. Denne ses opstillet i formel (7.3). P Ballasttank = ADC Pa Niveau 43, 5 inddeling 217, 5 Pa 1, 0831 (7.3) Software til beregning af tryk i ballasttanken er implementeret sammen med software til accelerometeret, og er forklaret i afsnit

64 7.2 Accelerometer Et accelerometer kan fortælle et objekts acceleration i et plan. Accelerometret kan således bruges til at bestemme en hastighed som vist ved formel (7.4), hvor v 0 er starthastigheden. Formel (7.4) er udnyttet til at bestemme ubådens hastighed, hvor v 0 er ubådens hastighed beregnet ved den foregående måling. v = a t + v 0 (7.4) Den tilbagelagte afstand kan videre beregnes ved brug af formel (7.5), hvor s 0 kan ses som den afstand ubåden har tilbagt før den nuværende måling. s = 1 2 a t2 + v 0 t + s 0 (7.5) Både ønsket om at kunne vise ubådens hastighed og den tilbagelagte afstand kan realiseres med accelerometre. Endvidere kan ubådens dybde bestemmes ved brug af et accelerometer der ligger så det måler i z-planet. For et sådan accelerometer i z-planet vil afstanden tilbagelagt svare til dybden. Der bruges i ubåden et 3-aksers accelerometer til bestemmelse af ubådens bevægelser. Accelerometeret er brugt til bestemmelse af ubådens hastighed og dybde, samt den tilbagelagt afstand. Et 3-aksers accelerometer løser dette, da det viser accelerationen i alle 3 akser. Idet ubåden ikke er designet til at foretage store accelerationer, er det ikke set nødvendigt at finde et accelerometer der kan måle mere end 2 g. Der er valgt 2 g da dette vil give mulighed for en acceleration på 1 g i samme retning som tyngdeacceleration. Der er valgt at bruge et accelerometer af typen adxl330, da det kan måle en acceleration på op til ± 3 g, hvilket er mere end minimumskravet. Accelerometeret giver en spænding på 0 V ud ved -3 g, og ved en acceleration på 3 g er spændingen 3 V, svarende til 60 % af ADC ens dynamikområde eller 153 niveauer. 153 niveauer betyder en acceleration på 0,039 g per niveau. Dette giver dog ikke et billede af hvor mange niveauer accelerometeret reelt bruger. Selvom 60 % af ADC ens dynamikområde er en dårlig udnyttelse, er der valgt ikke at ændre på designet for at udnytte en større del, hvilket skyldes det ønskes testet hvilke kræfter ubåden bliver udsat for, for derefter at optimere efter nødvendighed. 64

65 Figur 7.3: Implementering af accelerometer. 7.3 Sampling af sensorer Der findes 2 måder at aflæse flere spændingsniveauer, fra forskellige kilder; man kan benytte en ADC til hver kilde eller man kan benytte én ADC og skifte imellem inputs til den. Der findes fordele og ulemper ved begge metoder. Én ADC Ved at benytte en enkelt ADC, som skifter mellem de forskellige inputs, ved hjælp af en mux, vil det være muligt kun at benytte sig af én ADC til en lang række målinger. Dette gør det nemt at udvide, da man kan benytte en større mux, hvis flere målinger ønskes. Desuden er det ofte den billigste løsning, da det kræver færre IC er. Tiden, det tager at konvertere alle spændingerne til digitale værdier, er afhængig af antallet af spændingskilder, der skal måles på. Tiden det tager før en konvertering er stabil, samt tiden det tager at aflæse en ADC skal påregnes hver gang, da en ny konvertering skal igangsættes for hver måling. Dette kan udregnes ved hjælp af formel (7.6). ADC read = (ADC Stabil + read) ADC Antal (2, 5µs ns) ADC Antal (7.6) Flere ADC ere Hvis der i stedet benyttes én ADC per måling er det muligt at foretage flere målinger samtidigt. På denne måde er det muligt at skabe et øjebliksbillede for den situation ubåden befinder sig i. Modsat situationen med én ADC, er det i dette tilfælde ikke nødvendigt at regne konverteringstiden med for hver konvertering; det er kun read cyclen som skal gentages for hver måling. Tiden for at læse fra ADC erne kan udregnes ved formel (7.7). ADC read = ADC Stabil + read ADC Antal 2, 5µs ns ADC Antal (7.7) Denne tid kan yderligere reduceres ved at læse words i stedet for bytes, da disse tager lige lang tid, jævnfør M68k datablad [5]. Dette halverer antallet af read-cycles der er 65

66 nødvendige. Dette tal rundes op til nærmeste hele, da man stadig skal læse en byte, hvis man kun skal aflæse en enkelt ADC. Figur 7.4: Graf over hvordan antallet af ADC er påvirker læsetiden for ADC erne. Den røde graf er med én ADC, mens den grønne er med én ADC per måling. I dette tilfælde læses bytes. Der kan, ud fra formlerne, ses at det vil være hurtigere at lave ADC-målinger ved at benytte flere ADC ere, hvis antallet af nødvendige målinger er over 1, som vist på figur 7.4. Dette er dog kun tilfældet, hvis det er nødvendigt at aflæse ADC erne samtidigt; hvis ADC erne skal aflæses uafhængigt af hinanden, vil antallet ikke nødvendigvis have nogen større indflydelse. Til ubåden er der valgt at benytte flere ADC ere, da der ønskes et øjebliksbillede af ubådens sitation. Til dette er det nødvendigt med 4 ADC ere, som simultant kan starte en konvertering. Sensorerne vælges aflæst af samme type ADC, som den i minimumssystemet, ADC0820, da det er hvad der er tilgængelig og der haves erfaring med at implementere den. Aflæsning af ADC erne ADC0820 kan sættes op i WR-RD mode, som gør det muligt at starte en konvertering med en Write cycle hvorefter den kan aflæses med en read. Timing for ADC en i WR-RD mode er vist på figur 7.5. I stedet for at ADC erne aflæses én af gangen efter endt konvertering placeres to af dem på den nedre databus og to på den øvre. På den måde kan to ADC er aflæses på en enkelt 16 bit read cycle, som tager lige så lang tid som en 8 bit. For også hurtigt at kunne sætte ADC erne igang laves en specifik adresse i adressedekodningen som adresserer samtlige ADC er hvorefter en Write cycle kan udføres. Da ADC en er 1,6 µs om at færdiggøre en konvertering og M68k har en minimum access 66

67 Figur 7.5: Timingsdiagram for ADC0820 i WR-RD mode [16]. time på 290 ns, er der behov for indsættelse af wait-states fra ADC en chip selectes til den er færdig med at konvertere. ADC en signalerer med INT at konverteringen er færdig ved at sætte den lav, som vist på timingsdiagrammet figur 7.5. Ved at gøre DTACK afhængig af både ADC ernes chip selects og deres INT indsættes wait states til konverteringen er færdig. Håndteringen af DTACK beskrives i afsnit 9. Opbygning af hardware Udover de fire ADC er er der behov for at en PEEL håndterer adressedekodning og DTACK. Da ADC erne implementeres på et eksternt board implementeres også en forbindelse til minimumssystemet som indeholder pins, som vist i appendiks I. Argumentet for kablets forbindelser kan ses i afsnit 9. ADC erne implementeres i WR-RD mode, som opnåes ved at sætte 5 V på MODE hvormed pin 6 på ADC bliver WR. Opsætningen af en enkelt ADC er vist på figur 7.6. Denne opsætning repeteres fire gange med ADC 1 og 3 på den nedre databus og 2 og 4 på den øvre. 7.4 Accepttest Følgende afsnit sammenligner krav fra kravspecifikationen med målejournaler. Krav der ikke er taget fra kravspecifikation er markeret med et *. Idet der ikke er blevet 67

68 Figur 7.6: Opsætning af ADC erne. implementeret automatiseret sejlads i projektet er der valgt at se bort fra retning, som der derfor ikke er opfyldt kravene til. Krav Målt Afvigelse Opfyldt Stop af pumpe * 4500 Pa 8250 Pa 83 % X Stop af pumpe * 0 Pa 0 Pa 0 % Dybdemåling præcision ± 0,1 m ikke målt - X Retning målepræcision 1 ikke målt - X Fremdrift målepræcision ± 0,1 knob ikke målt - X Tabel 7.1: Krav til sensore. 68

69 Motormodul 8 I dette kapitel beskrives det hardware der er konstrueret til ubådens motormodul. Der er konstrueret hardware der kan styre ubådens fremdrift, ror og ballastpumpe. 8.1 Fremdrift Til at drive ubåden frem og tilbage er der valgt at bruge den motor, der var i ubåden. Motoren er blevet testet og resultatet af testen kan ses i Appendiks F. Desuden er et billede at motoren vist på figur 8.1. I testen er peakstrømmen for motoren blevet målt til 5,8 A og 0,8 A kontinuert. Disse værdier er målt for at finde en H-bro til projektet. H-broen der er valgt til projektet er en L298N Dual Full-Bridge Driver [23]. Den er valgt fordi den har to H-broer i en IC, selvom den ikke helt kan leve op til kravet motoren stiller. H-broen kan levere 2 A kontinuert til motoren, hvilket er mere end motoren trækker, men den er ikke designet til at kunne holde til mere end 3 A i peakstrøm, hvor motoren trækker 5,8 A. Fordi det var den eneste der var tilgængelig er det valgt at bruge denne H-bro. Idet det skal være muligt at styre motorens hastighed er det valgt at bruge PWM til at styre den, hvilket er beskrevet i afsnit Ballastpumpe For at ubåden kan dykke er der en ballastpumpe, det er valgt bruge den pumpe modellen er udstyret med, afbilledet på figur 8.2. Denne er blevet testet og resultatet fremgår af Appendiks F. I denne test er peakstrømmen, motoren trækker, blevet målt til 5,8 A og 1 A kontinuert. Disse værdier er målt for at kunne finde en H-bro til projektet. H-broen er som før nævnt en L298N Dual Full-Bridge Driver [23]. Idet ballastpumpen ligner motoren til fremdrift, er der også de samme problemer med at den trækker for meget strøm lige når den bliver tændt. Fordi ballastpumpen ikke behøver mange hastighedstrin er det valgt at den skal styres af projektets DAC, beskrevet i afsnit

70 Figur 8.1: Billede af motor til fremdrift og servo til at styre roret. Figur 8.2: Billede af ballastpumpe. 8.3 Ror Til at styre roret på ubåden er der monteret en servo, afbilledet på figur 8.1. Servoen styres med et PWM-signal. Denne servo er bygget til at skulle operere ved en frekvens på 50 Hz og en pulstid mellem 1 og 2 millisekunder, hvor en pulstid på 1 millisekund svarer til 0 på servoen og 2 millisekunder svare til 180. Der er valgt at anvende en Arduino til at generere dette signal. Opbygningen er forklaret i afsnit

71 8.4 PWM, H-bro og komparatorkredsløb På figur 8.3 er opbygningen af H-broen samt komparatorkredsløbet vist. Der er valgt at bruge to komparatorer til at styre ballastpumpen. Dette er valgt fordi denne pumpe kun skal kunne pumpe vand ind og ud af ballasttanken med én hastighed. Figur 8.3: Diagram over opbygningen af H-bro og komparatorkredsløb. Komparatorkredsløbet er opbygget af to OPA27 operationsforstærkere samt, to spændingsdelere til at kontrollere de tre forskellige niveauer. Som det ses på figur 8.3 er det valgt at lave det sådan at OPA27 nummer 1 ser en spænding på 1 3 af forsyningen på den inverterede indgang og OPA27 nummer 2 ser en spænding på 2 3 af forsyningen på den ikke inverterede indgang. Dette giver sandhedstabellen 8.1 for de tre forskellige stadier på DAC en. DAC-spænding OPA27-1 OPA V 0 1 2,5 V V 1 0 Tabel 8.1: Sandhedsabel over komparator kredsløb. Som tidligere nævnt er der valgt en L298N Dual Full-Bridge Driver [23] som H-bro. 71

72 Diagrammet for styringen er afbilledet på figur 8.3. Der er valgt at anvende en typisk implementation af H-broen fra databladet. Denne opbygning giver en sandhedstabelen som er givet ved tabel 8.2. Input1 Input2 Funktion 0 0 Stop 1 0 Tilbage 0 1 Frem 1 1 Stop Tabel 8.2: Sandhedstabel for H-bro fra datablad [23]. Til at styre H-broen er der valgt at anvende en Arduino som PWM modul, softwaren til denne findes i billag [24]. Der er valgt at føre databussen D0-D7 fra M68k systemet, samt tre chip selects, CS1_Forward, CS2_Backward og CS3_Servo til Arduinoen. Dette er gjort for at Arduinoen kan reagere på et chip select fra M68k systemet hvorefter værdien der står på databussen kan føres ud til den valgte enhed. Selvom Arduino opererer ved 16 MHz er det ikke muligt for den at følge med M68k systemet. Dette skyldes at Arduinoen ikke er sat op til at kunne læse hele databussen på én gang, men i stedet læser den over otte gange. For at dette kan fungere er Arduinoens kode lavet således at Arduinoen agerer ligesom projektets ADC er som også er for langsomme. Dette gøres ved at hver gang Arduinoen får et chip select sættes M68k systemet i wait state ved DTACK indtil Arduinoen sætter et wait signal lavt. Dette er illustreret på figur 8.4. Figur 8.4: Afbildning af timing mellem M68k og Arduino. Et uddrag af koden til PWM er vist på figur 8.5, hvor der vises hvorledes det er implementeret i koden at M68k systemet er i wait state indtil Arduinoen sætter signalet arduino_wait lavt. 72

73 Figur 8.5: Uddrag af kode til Arduino. 8.5 Acceptest motormodul Følgende afsnit sammenligner krav fra kravspecifikationen med hvad der kunne opnås ved målinger og målejournaler på motormodulet. Idet der ikke er blevet implementeret trinvis styring men trinløs styring af ballasttank i projektet er dette krav dermed ikke opfyldt. Krav Målt Opfyldt Fremdrift - trinvis 5 frem, 5 bak, 1 stop 5 frem, 5 bak, 1 stop Dybde - trinvis Trinvis Trinløs X Ror - trinløs Trinløs Trinløs Tabel 8.3: Krav til motorer. 73

74

75 Adressedekodning, interrupt og DTACK 9 De forskellige moduler i dette projekt stiller hver især krav til opbyggelsen af logiske kredsløb for at fungere korrekt. Samtlige enheder skal have adresser, for at kunne adresseres. ACIA 2 skal have en interrupt controller og DTACK skal genereres korrekt, så der indsættes wait states ved ADC-konvertering og styring af motorerne. Disse controllere implementeres med logiske kredsløb i PEELs. For at gøre forbindelserne mellem PEELs overskuelig er de vist på figur 9.1. Figur 9.1: Forbindelserne mellem PEELs. 9.1 Adressedekodning For at kunne interagere med modulerne i systemet skal de hver især tildeles adresser. I dette projekt implementeres partiel adressedekodning, hvilket vil sige at en IC s adresse ikke nødvendigvis er unik, men vil være spejlet på nogle adresser, som ikke er i brug. Partiel dekodning benytter adresserummet mindre effektivt end fuld dekodning, hvor hver enkelt IC har en unik adresse, da der vil opstå spejlinger. Til gengæld reducerer det antallet 75

76 af nødvendige inputs til de logiske kredse, som skal håndtere adressedekodningen, da der ikke er behov for hele adressebussen til partiel dekodning Hukommelse, debugger ACIA og DAC De fleste moduler i minimumssystemet skal bevare deres adresser, da debuggeren forventer at de ligger på bestemte adresser. Hvad der ændres fra minimumssystemet er at ADC en flyttes til ADC-modulet, så de fire ADC er er samlet. Hukommelse, DAC en og debuggerens ACIA forbliver uberørte i det samlede system ACIA 2 ACIA 2 wrappes på minimumssystemet og benytter samme PEEL til adressedekodning som debuggerens ACIA. For ikke at skulle ændre inputs til PEEL en får ACIA 2 samme adresser som debuggerens ACIA med datastroben til forskel. Derfor kommer ACIA 2 til at ligge på den øvre databus og adresseres med UDS. Som vist på figur 9.1 skal ACIA 2 ligge på h og h. Den boolske algebra, som implementeres i PEEL en, er som følger: ACIA2 = V MA UDS AS A23 V P A = (LDS + UDS ) AS A23 + V P A_INT ACIA 2 er en M6800 serie enhed, hvilket gør at VPA og VMA skal benyttes under adresseringen. Adresseringslogikken er lavet sådan, at adressen genererer VPA uden at chip selecte ACIA en. Først når M68k har sat VMA lav, chip selectes ACIA en. Da ovenstående VPA logik er for det færdig system indgår begge ACIA er samt VPA_ INT, som bliver nærmere forklaret i afsnit 9.3. Da der ikke er andre enheder, hvor adressepin A23 er høj, tillades der udelukkende at adressere ud fra denne. Dermed er ACIA 2 spejlet på samtlige lige adresser. hvor A23 er høj. Dette gælder også for debuggerens ACIA, som er spejlet på samtlige ulige adresser i samme adresserum ADC- og motormodul ADC- og motormodulets adressedekodning implementeres på printet med ADC-modulet. Det betyder, at forbindelsen mellem det udvidede minimumssystem og ADC-modulet skal indeholde de fornødne pins til brug i adresseringen. Der skal bruges adresser til fire ADC er, en adresse til at chip selecte alle ADC er på samme tid, to adresser til fremdriftsmotoren samt en adresse til servoen til roret. Adresserne er, som det kan ses i figur 9.1, alle placeret i xxx h. På denne måde er der udelukkende behov for fire adressepins; A1, A2, A3 og A21. Derudover skal LDS og UDS være til stede, for at sikre at chip select kun sker 76

77 Adresse Navn h. Debugger ROM FF h h. ROM 0003 FFFF h h. Debugger RAM FFF h h. Bruger RAM 0007 FFFF h h ADC Start h Forward h Backward h ADC h ADC h Servo A h ADC B h ADC h DAC h ACIA 2 Reg h ACIA 1 Reg h ACIA 2 Rx/Tx h ACIA 1 Rx/Tx Tabel 9.1: Endeligt memorymap. ved stabile adresser. Begge adressestrober skal medtages i denne adressedekoder, fordi ADC erne har behov for parvis at være på sammenhængende word-adresser. Det vil sige, at ADC erne skal ligge, som vist på figur 9.1, på adresse h og A-B h, og ved at læse et word fra den lige adresse, vil den ulige blive taget med, da det er byte adresser og et word er to bytes. ADC Start adressen, som adresserer samtlige ADC er samtidig, er tilfældigt valgt ud af de resterende adresser. Adresselogikken til ADC-adressering ser ud som følger: CS_ADC1 = A21 A1 A2 LDS + A21 A1 A2 A3 LDS CS_ADC2 = A21 A1 A2 UDS + A21 A1 A2 A3 LDS 77

78 CS_ADC3 = A21 A1 A3 LDS + A21 A1 A2 A3 LDS CS_ADC4 = A21 A1 A3 UDS + A21 A1 A2 A3 LDS Delen som går igen i alle udtrykkene er til adressering af dem alle samtidig, og den første del er hver ADC s adresse. Da kun A21 benyttes til adressering i dem alle, er alle enhederne spejlet i alle adresser hvor A21 er høj. For eksempel er ADC1 spejlet i xx2x xxx6 h. Motorernes adresser er valgt tilfældigt ud fra de resterende adresser. Adresserne har udelukkende behov for, at kunne aktiveres enkeltvis og samme spejling finder sted på motorernes adresser som på ADC ernes. Adresselogikken til motorernes adresser er som følger: CS_P W M_F ORW ARD = A21 A2 A3 A1 LDS CS_P W M_BACKW ARD = A21 A2 A3 A1 LDS CS_SERV O = A21 A2 A3 A1 LDS 9.2 DTACK-håndtering Da ADC erne er langsommere til at lave en konvertering, end M68k er til at læse, og Arduinoen, som agerer PWM-modul, er langsom til at reagere på et chip select, er der behov for indsættelse af wait states. Wait states kan indsættes på to måder; ved hjælp af DTACK eller VPA. DTACK er i M68k manualen [5] beskrevet som værende, hvad der bruges til at generere wait states, men ud fra timingsdiagrammet i appendiks B i manualen [25] kan der ses, at wait states indsættes fra VPA sættes lav til den sættes høj igen. Grunden til at der i dette projekt vælges at bruge DTACK er, at Read cycle en afsluttes for hurtigt efter en wait state med VPA afsluttes. ADC erne benytter INT signalet til at signalere, at en konvertering er færdig og klar til at blive aflæst. Afslutningen af en wait state vil være direkte forbundet med, at INT går lav og dermed, at VPA går høj. Tiden, fra en ADC sætter INT lav, til dataen er klar på bussen, er typisk 70 ns, mens processoren i worst case forventer, at dataen er der så snart VPA sættes høj. Efter DTACK sættes lav, forventer processoren derimod først data på bussen 90 ns efter, hvilket gør, at der er sikkerhed for, at ADC erne har dataen klar. DTACK er lavet sådan, at hvis ikke Arduinoen eller ADC erne chip selectes følger DTACK og AS hinanden. Så snart en af enhederne chip selectes, bliver DTACK 78

79 høj, indtil ADC ernes INT går lav eller Arduinoens ARDUINO_WAIT går lav, hvormed CS_ARDUINO_OUT går høj. CS_ARDUINO_OUT og CS_ARDUINO_IN er forbundet, da udtrykkene er implementeret i to PEELs. DTACK er implementeret med følgende udtryk: DT ACK = AS CS_ADC_IN CS_ARDUINO_IN CS_ADC_IN (INT _ADC + W R ) CS_ARDUINO_IN CS_ARDUINO_OUT = CS_P W M_F ORW ARD CS_P W M_REV ERSE CS_SERV O + ARDUINO_W AIT Årsagen, til at det er delt op i to udtryk, er, at de implementeres i hver sin PEEL, da der ikke var tilstrækkeligt mange in- og outputs på en enkelt 22CV10 PEEL. For først at sætte DTACK lav når alle ADC erne er klar, er følgende udtryk implementeret og forbundet til INT_ADC, som er vist i DTACK udtrykket ovenfor. INT _OUT = INT _ADC1 INT _ADC2 INT _ADC3 INT _ADC4 9.3 Interrupt-håndtering I det samlede system kan der forekomme to interruptniveauer; 7 og 4. Når et interrupt request modtages skal det dekodes, hvormed den rette værdi skal sættes på IPL0, IPL1 og IPL2. NMI knappen signalerer et interrupt request med en mekanisk knap koblet på et logisk kredsløb, som fjerner prel. Når ACIA 2 har modtaget en ny byte, vil den sætte IRQ lav, til byten er aflæst. Dette implementeres med følgende udtryk: V P A_OUT = F C0 F C1 F C2 IP L2 = IRQ_ACIA2 nnmi IP L1 = IP L0 IP L0 = nnmi VPA_ OUT er forbundet til VPA_ INT, som indgår i VPA genereringen i afsnit I dette projekt benyttes autovektor, hvilket er grunden til, at VPA skal genereres, efter FC0, FC1 og FC2 er sat høj af processoren for at signalere et interrupt acknowledge. 79

80

81 Controllermodul 10 For at kunne styre ubåden udvikles en controller, som sender kommandoer fra sine knapper, via en Arduino, til computerprogrammet via en seriel forbindelse. På figur 10.1 ses den endelige controller, med knap-definitioner. Controlleren består af 5 trykknapper, samt en dreje knap. Ved hjælp af disse er det muligt at sende alle de nødvendige kommandoer, for at styre ubåden. Figur 10.1: Controller til ubåden. Ved hvert tryk på Frem, Bak eller Stop sendes én kommando, hver gang knappen trykkes i bund. Knapperne Op og Ned sender derimod henholdsvis u og d, når de trykkes ned, 81

82 og h når de slippes. På denne måde sikres der, at kommandoen kører så længe knappen holdes i bund, uden det er nødvendigt at sende information løbende. For at styre retningen aflæses spændingen over et potentiometer. Denne spænding omregnes til en værdi, der sendes efter kommandoen c, hvilket indstiller servoens position. På denne måde kan det afgøres hvor meget der er drejet, hvilket kan bruges til at udregne den ønskede position for roret. Koden, som afvikles på Arduinoen i controlleren, kan ses i billag [26]. 82

83 Software - Computer 11 For at behandle dataen, som sendes fra M68k til computeren, benyttes et program skrevet i Python [27]. Programmet har til formål at behandle målte data, for at kunne beregne dybde, hastighed, tilbagelagt afstand samt trykket i ballasttanken. Desuden skal programmet kunne oplyse brugeren om resultatet af disse udregninger, samt videresende de kommandoer brugeren giver til systemet, ved hjælp af controlleren beskrevet i kapitel 10. Til dette er det nødvendigt med en protokol, beskrevet i tabel Derudover skal programmet kunne sørge for, at brugeren ikke udfører nogle handlinger, som kan skade ubåden såsom at overfylde ballasttanken, dykke for langt ned, eller forsøge at tømme ballasttanken når den er tom. Kommando f b s u d h cx m Funktion Forwards Backwards Stop Up Down Hold (Pumpe) Course + value Measure Tabel 11.1: Liste over gyldige kommandoer, fra controlleren, til ubåden Måling af sensorer Der sendes med fast interval en kommando til M68k, som beder om en måling af sensorerne. For at modtage data fra M68k er det nødvendigt med en protokol. Da alle målinger er lavet med 8-bits ADC er, er det muligt at sende hver måling som én byte. Dette letter kommunikationen, da det derfor kun er nødvendigt at sende fire bytes, for at have data fra alle målinger. For at sikre at de data der modtages er korrekte, sendes alle fire bytes to gange, hvorefter de sammenlignes parvis. Informationen sendes i en fastdefineret rækkefølge, da der ikke sendes nogen identifikationsinformation med. Til dette er valgt rækkefølgen: x, y, z og tryk. Disse lægges ind i hver sin liste, så gamle målinger 83

84 gemmes. Informationen fra x-, y- og z-aksens målinger ses alle som brugbare, mens data fra tryksensoren er ubrugelige, når pumpen kører samtidigt med en måling. Der blev desuden, i målejournal D, konstateret at trykket i slangen, fra pumpen til ballasttanken, ikke er stabilt øjeblikkeligt, når pumpen stoppes. Når pumpen kører holdes der for hvert andet sekund en pause, hvor trykket i ballasttanken måles. Trykket bruges til at vurdere om pumpen forsat må køre Kalibrering og omregning For at tage højde for tyngdeaccelerationen, kalibreres accelerometeret i starten til at vise 0, når den ligger stille. Dette gøres ved at tage en række målinger, og sammenligne dem med hinanden. Når de seneste 50 målinger har været i en afstand af hinanden på én, ses ubåden som liggende i hvilestilling med tyngdekraften som eneste kraft der påvirker ubåden. Denne værdi kan så trækkes fra de nyeste målte værdier, for at finde accelerationen i en given retning. Denne værdi kan herefter bruges til at bestemme hastigheden og den tilbagelagte afstand. Ved at integrere accelerationen fåes hastigheden, og ved at integrere denne fåes positionen, eller længden ubåden er sejlet i den givne retning. I praksis gøres dette ved at gange den nyeste målte værdi med tiden siden den sidste værdi, og lægge den til den tidligere hastighed. Det samme gøres med hastigheden, for at finde den tilbagelagte afstand. 84

85 Software - Motorola 68k 12 I dette kapitel beskrives softwaren udviklet til at blive afviklet på M68k, hvilket er skrevet i Assembly og C [28]. M68k har, i det færdige produkt, til opgave at kontrollere aktuatorer og sensorer udfra hvilke ønsker den modtager fra brugeren, gennem en serielforbindelse med en computer. Softwaren er udviklet så den overordnet har to indstillinger den kan køre efter. Én, hvor der er ekko på den serielle kommunikation og behøves carriage return ved funktionskald, samt én uden ekko, hvor der ikke ventes på carriage return. Dette er lavet, da det giver en mere overskuelig fejlfindingsproces under udvikling med ekko og carriage return. De er dog ikke nødvendige, når systemet er færdigudviklet. Der er desuden foruddefineret en række tekststrenge, som kan benyttes til at gøre output fra softwaren mere læsevenlig og dermed lette udviklings- og fejlfindingsprocessen yderligere. Softwaren til det færdige produkt er opbygget, så M68k har en række forskellige funktioner, herefter kaldet eksterne funktioner, den kan udføre afhængigt af hvilken kommando den får fra computeren, som styres af brugeren eller programmøren. For at bestemme hvilken funktion der skal udføres, hvis nogen, skal M68k først være i stand til at aflæse den serielle kommunikationslinie. Desuden skal M68k også, både til fejlfinding og det færdige software, kunne sende information via den serielle forbindelse. Derfor er der skrevet nogle funktioner, herefter kaldet interne funktioner, som brugeren af det færdige produkt ikke selv kommer til at kalde, men som bruges internt i softwaren på M68k. Softwaren er opbygget, så systemet med M68k er slave i det endelige produkt med en computer tilsluttet. M68k laver med andre ord kun noget, når den bliver bedt om det, efter de indledende interne initialiseringsfunktioner er blevet kaldet. Derfor køres, som det kan ses på figur 12.1, nop, hvilket kun afbrydes af et interrupt 4, som indtræffer når systemet modtager data via den serielle forbindelse. Figur 12.1: Softwarens hovedløkke. De foruddefinerede tekststrenge samt alle de interne og eksterne funktioner vil i den 85

86 resterende del af dette kapitel blive gennemgået Tekststrenge Disse tekststrenge, som er vist på figur 12.2, anvendes ved at benytte funktionen print_string eller print_string_debug, der er beskrevet i henholdsvis afsnit og Figur 12.2: De foruddefinerede tekststrenge. Eksempelvis vil et linieskift på enheden, der aflæser ACIA 2, frembringes af koden vist på figur Dette sker da tekststrengen crlf, indeholder et carriage return og et line feed, som det fremgår af figur Figur 12.3: Kode til linieskift på ACIA Interne funktioner De interne funktioner er, som nævnt, de funktioner, der kaldes internt i M68k-softwaren og som brugeren af det endelige produkt dermed ikke kommer i kontakt med. Under fejlfinding er mange af funktionerne dog nyttige for programmøren, eksempelvis er BELLfunktionen udelukkende lavet med fejlfinding for øje. Alle disse funktioner, med navnene benyttet i softwaren, er: initialize init_interrupt_asm int4proc read_rs232 int_to_string_dec int_to_string_hex print_char 86

87 print_char_debug print_int_dec print_int_hex print_string print_string_debug string_cmp motor BELL Funktionerne er beskrevet enkeltvis i de næstkommende afsnit initialize Dette er en funktion, som kaldes af softwaren selv, når den startes. Som det er vist på figur 12.4, er det den gør at sende en værdi til ACIA 2 og læse fra den. Værdien, der sendes, sætter ACIA en op til at den kan interrupte, hvilket der kan læses mere om i afsnit 6. Der læses fra ACIA en for at tømme den for eventuelt irrelevant data. Figur 12.4: Funktionen initialize skrevet i Assembly init_interrupt_asm Denne funktion kaldes af softwaren selv, når den startes. Den sætter, i henhold til TS2MON-debuggeren, M68k op til at udføre funktionen skrevet i int4proc, som beskrevet i afsnit , når den modtager et interrupt 4. Opsætningen foregår ved, at lægge en jump instruktion efterfulgt af adressen på int4proc ud på den plads i RAM, der tilgåes når, der modtages et interrupt 4. Desuden sættes M68k status register op til, at den i det hele taget accepterer et interrupt 4. Koden er vist på figur int4proc Denne funktion er, hvad der afvikles, når processoren modtager et interrupt 4, hvilket den gør når ACIA 2 modtager data fra den serielle forbindelse. Den kalder en anden funktion, read_rs232, og tjekker om den melder tilbage med en fejlkode. Hvis det skulle være aktuelt, sendes en fejlmeddelelse til computeren. Koden kan ses på figur

88 Figur 12.5: Funktionen init_interrupt_asm skrevet i Assembly. Figur 12.6: Funktionen int4proc skrevet i C read_rs232 Denne funktion kaldes af interrupt funktionen, int4proc, når der modtages et interrupt 4. Det den gør er, som det kan ses på figur 12.7, at den tjekker statusregisteret på ACIA 2 for, at se om den har modtaget noget data. Er det tilfældet kaldes funktionen read_rs232_asm, vist på figur 12.8, som lægger den byte, ACIA 2 har modtaget, over i den variabel, den har fået adressen på som argument. Herefter kører read_rs232 videre ved at kigge på indholdet, der nu ligger i variablen, for at bestemme hvad der skal ske. Dette er indgangsvinklen til at kalde de eksterne funktioner, som er beskrevet i afsnit int_to_string_dec I denne funktion benyttes funktionen itoa, fra stdlib.h, til at konvertere den første inputvariabels decimalværdi til en streng. Resultatet lægges på adressen som den anden inputvariabel til funktionen peger på. Koden kan ses på figur

89 Figur 12.7: Funktionen read_rs232 skrevet i C. Figur 12.8: Funktionen read_rs232_asm skrevet i Assembly. Figur 12.9: Funktionen int_to_string_dec skrevet i C int_to_to_string_hex I denne funktion benyttes funktionen itoa, fra stdlib.h, til at konvertere funktionens første inputvariabels hexadecimaleværdi til en streng. Resultatet lægges på adressen som den anden inputvariabel peger på. Koden kan ses på figur Figur 12.10: Funktionen int_to_string_hex skrevet i C. 89

90 print_char Denne funktion, vist på figur 12.11, er lavet til at sende en byte ud gennem ACIA 2. Den holder desuden også øje med om skrivningen timer out, ved at læse statusregistret for ACIA 2 og returnerer en fejlkode, hvis det er aktuelt. Selve det at sende byten foregår med et kald af en funktion, print_char_asm, som kan ses på figur Denne funktion skriver inputvariablen til ACIA 2. Figur 12.11: Funktionen print_char skrevet i C. Figur 12.12: Funktionen print_char_asm skrevet i Assembly print_char_debug Denne funktion er som udgangspunkt identisk med funktionen print_char, som er beskrevet i afsnit Eneste forskel ligger i Assembly-funktionen print_char_debug_asm, som der kaldes. Koden for den er vist på figur 12.13, hvor det kan ses at den sender sin inputvariabel til ACIA 1 i modsætning til print_char_asm, hvor der sendes til ACIA 2. Figur 12.13: Funktionen print_char_debug_asm skrevet i Assembly. 90

91 print_int_dec Dette er en funktion til at få et tal i decimalformat ud gennem ACIA 2. Som det kan ses på figur 12.14, benyttes int_to_string_dec for at sikre, at værdien kan sendes videre til funktionen print_string samt, at den behandles som en decimalværdi. Funktionen print_string er beskrevet i afsnit Figur 12.14: Funktionen print_int_dec skrevet i C print_int_hex Denne funktion er til at få et tal i hexadecimalt format ud gennem ACIA 2. Som det kan ses på figur 12.15, benyttes int_to_string_hex for at sikre, at værdien kan sendes videre til funktionen print_string samt, at den behandles som en hexadecimal værdi. Funktionen print_string er beskrevet i afsnit Figur 12.15: Funktionen print_int_hex skrevet i C print_string Dette er en funktion til at sende en tekststreng gennem ACIA 2. Dette gøres ved, at tage den streng funktionen får som input og håndtere den én byte ad gangen. Så længe den byte der kigges på ikke er nultermineringsbyten sendes den videre til funktionen print_char, som får sendt byten ud gennem ACIA 2. Desuden holdes der i denne print_string funktion øje med om print_char melder tilbage med en fejlkode. Koden er vist på figur print_string_debug Denne funktion er identisk med print_string, pånær på et punkt. Med denne funktion sendes der nemlig ud gennem ACIA 1, i stedet for ACIA 2. Funktionaliteten af denne funktion kan derfor læses i afsnit

92 Figur 12.16: Funktionen print_string skrevet i C string_cmp Dette er en funktion, som tager adresserne på to strenge som argument. Disse strenge gennemløbes, som det kan ses på figur 12.17, indtil der findes en forskellighed eller til begge strenges nulterminering. Er de forskellige returneres en fejlkode, som indikerer dette mens en fejlkode, der indikerer, at de er ens returneres, hvis nultermineringen findes samme sted i dem. Figur 12.17: Funktionen string_cmp skrevet i C motor Motor-funktionen, hvis kode ses på figur 12.18, er en funktion, som holder styr på, at fremdriftsmotoren ikke bliver bedt om at køre både frem og tilbage på samme tid. Er dette i orden kaldes enten Assembly-funktionen motor_forward_asm eller motor_backward_asm afhængig af hvilken vej ubåden skal sejle. Koden til motor_forward_asm er vist på figur 12.19, som tager hastigheden frem som argument. Denne hastighed lægges på adressen for motoren, hvilket er på Arduinoen som styrer h- broen. Dette beskrives yderligere i afsnit 8.4. Funktionen motor_backward_asm fungerer på samme måde, dog med hastigheden bagud. 92

93 Figur 12.18: Funktionen motor skrevet i C. Figur 12.19: Funktionen motor_forward_asm skrevet i Assembly BELL BELL-funktionen er lavet udelukkende med fejlfinding for øje. Det er en funktion, som kan kaldes for at få en lyd ud, så man har en tydelig indikation af, om man passerer det stykke i koden, hvor den kaldes. Det foregår ved at sende 7 h til den tilsluttede computer gennem den serielle forbindelse. Til at sende benyttes en anden af funktion, nemlig print_char, som er beskrevet i afsnit Koden ses på figur Figur 12.20: BELL-funktionen skrevet i C. 93

94 12.3 Eksterne funktioner De eksterne funktioner er, som nævnt, de funktioner, brugeren eller programmøren af det endelige produkt er i kontakt med. Brugeren benytter sig af contolleren, beskrevet i afsnit 10, hvilket får computeren med softwaren beskrevet i afsnit 11 til at sende kommandoer til M68k, når der trykkes på knapperne. Programmøren kan som den eneste aktivere funktionerne Version, Echo, Exit og Restart, hvilke også er funktioner lavet til fejlfinding. Ud fra hvilken kommando M68k modtager udfører den en af de eksterne funktioner. Disse funktioner, med navnene benyttet i softwaren, er: Echo Version Restart Exit Forward Stop Backward Course Up Hold Down Measure Funktionerne er beskrevet enkeltvis i de næstkommende afsnit. Måden funktionerne kaldes på er ved at sende en eller flere karakterer via den serielle forbindelse. Disse karakterer lægges af read_rs232, som er beskrevet i afsnit , ind i en streng, som derefter med string_cmp, beskrevet i afsnit , sammenlignes med strenge som indeholder kommandoerne til hver funktion Echo Denne funktion kaldes med kommandoen E og er skrevet for at lette fejlfindingsprocessen på systemet. Som det kan ses på figur 12.21, ændrer den én variabels værdi mellem nul og et, hver gang den kaldes. Når variablen bliver sat til et, sendes desuden en streng med en meddelelse ud gennem ACIA 2 ved brug af print_string. Variablen, som ændres i denne funktion, bruges igennem alt det andet software til M68k til at undersøge om det, der laves, skal fortælles til programmøren gennem den serielle forbindelse. I det endelige produkt skal der sendes så lidt kommunikation gennem den serielle forbindelse som muligt, da der ikke er noget behov for at sende læselige beskeder, eftersom alt kommunikation følger en bestemt protokol. 94

95 Figur 12.21: Funktionen Echo skrevet i C Version Denne funktion kaldes med kommandoen VERSION og er udelukkende skrevet til benyttelse under fejlfinding og udvikling af systemet. Som det kan ses på figur 12.22, er det den gør at sende en streng ud gennem den serielle forbindelse. Den kan bruges til at sikre, at systemet kører og ved at ændre i strengen kan programmøren sikre sig, at det nyeste software afvikles. Figur 12.22: Funktionen Version skrevet i C Restart Denne funktion kaldes med kommandoen RESTART og den kalder, som det kan ses på figur 12.23, funktionen restart_asm efter den eventuelt har sendt en meddelelse via den serielle forbindelse. På figur ses funktionen restart_asm, som får M68k til at gå til startadressen for programmet, hvilket dermed effektiviserer et restart. Figur 12.23: Funktionen restart skrevet i C. Figur 12.24: Funktionen restart_asm skrevet i Assembly. 95

96 Exit Funktionen Exit kaldes med kommandoen EXIT og er en funktion, som kun bruges under udvikling. Som det kan ses på figur 12.25, kalder den funktionen exit_asm efter den har sendt en meddelelse gennem ACIA 2. Når exit_asm, som er vist på figur 12.26, kaldes, afbrydes softwaren og M68k returnes til TS2MON-debuggeren. Figur 12.25: Funktionen Exit skrevet i C. Figur 12.26: Funktionen exit_asm skrevet i Assembly Forward Denne funktion kaldes med kommandoen F, hvilket, som det kan ses på figur 12.27, får M68k til at undersøge de to hastighedsvariabler. Først undersøges hvorvidt hastigheden fremad er sat til sit maksimale i forvejen og der sendes en meddelelse herom, hvis det er tilfældet. Efter dette undersøges hastigheden bagud og hvis den er større end nul tælles den ned. Sidst tælles hastigheden fremad et trin op, hvis intet af det andet er opfyldt. Trinene er en femtedel af det fulde span, hvilket stemmer overens med kravene i kapitel 3. Endeligt kaldes funktionen motor, som er beskrevet i afsnit Figur 12.27: Funktionen Forward skrevet i C. 96

97 Stop Denne funktion kaldes med kommandoen S og får ubåden til at stoppe, ved at sætte de to hastighedsvariabler til nul og kalde motor-funktionen. Koden er vist på figur Figur 12.28: Funktionen Stop skrevet i C Backward Denne funktion kaldes med kommandoen B og er identisk med Forward-funktionen, som er beskrevet i afsnit , bortset fra at den i stedet får ubåden til at sejle langsommere fremad eller hurtigere bagud. Koden er vist på figur Figur 12.29: Funktionen Backward skrevet i C Course Course-funktionen kaldes med kommandoen C og er en funktion til at få ubåden til at ændre kurs. Efter M68k har genkendt funktionskaldet ventes, som det kan ses på figur 12.30, på næste byte, som bestemmer retningen, der skal ændres til. Denne byte sendes videre til funktionen turn, som kan ses på figur 12.31, hvor værdien sendes til servomotoren. Kommer der ikke denne anden byte, returneres en fejlmeddelelse. 97

98 Figur 12.30: Funktionen Course skrevet i C. Figur 12.31: Funktionen Turn skrevet i Assembly Up Denne funktion kaldes med kommandoen U og den kalder, som det kan ses på figur 12.32, funktionen writedac med argumentet DEPTHUP. Som det er vist på figur 12.33, sender writedac værdien af argumentet videre til DAC en. DEPTHUP indeholder altså den værdi, der gør, at pumpen til ballasttanken, som styres af DAC en, får ubåden til at stige. Hvordan DAC en fungerer i samspil med pumpen, kan der læses nærmere om i afsnit 8.4. Figur 12.32: Funktionen Up skrevet i C. Figur 12.33: Funktionen writedac skrevet i Assembly. 98

99 Hold Denne funktion kaldes med kommandoen H og det den gør, er det samme som funktionen Up, som er beskrevet i afsnit , bortset fra, at værdien, der sendes til pumpen, der styrer ballasttanken, er så ubåden holder den aktuelle dybde i stedet for at stige Down Denne funktion kaldes med kommandoen D og det den gør, er det samme som funktionen Up, som er beskrevet i afsnit , bortset fra, at værdien, der sendes til pumpen, der styrer ballasttanken, er så ubåden dykker i stedet for at stige Measure Denne funktion kaldes med kommandoen M og den, som det er vist på figur 12.34, kalder funktionen read_adc1 som returnerer den værdi der er på ADC1. Herefter kaldes der funktioner for de andre ADC er, som fungerer på samme vis. ADC erne er placeret i adresserne, så det skulle være muligt med fordel at læse words fra ADC erne i stedet for at læse dem enkeltvis. De aflæses dog enkeltvis, da det gav komplikationer i softwaren. Til sidst sender den værdierne som read_adc har lagt i disse variabler ud gennem den serielle forbindelse. Funktionen read_adc1, som det ses på figur 12.35, søger for en konvertering fra ADC 1 returnerer resultatet af konverteringen. 99

100 Figur 12.34: Funktionen Measure skrevet i C. Figur 12.35: Funktionen read_adc1 skrevet i Assembly. 100

101 Implementering 13 For at kunne implementere modulerne i ubådsmodellen, er der behov for enkelte modifikationer og tilføjelser til hardwaren. Alle moduler, med undtagelse af controller modulet, ønskes implementeret internt i modellen. For at have plads til dette fjernes alt den forudinstallerede elektronik samt batteriet. Desuden skal en kablet forsyningsog kommunikationslinje etableres, således at samlingerne er vandtætte. Da der er en vægtforskel mellem det forudinstallerede elektronik samt batteri og det implementerede hardware på 700 g, er der lagt ekstra vægtlodder i ubåden. På figur 13.1 er der vist, hvor modulerne hver især er blevet placeret i ubåden. Figur 13.1: Placering af modulerne i ubåden. 101

102 Forsyning og kommunikation Den kablede forbindelse mellem ubåden og overfladen skal muliggøre kommunikation til systemet samt spændingsforsyning til modulerne. Da programmet skal uploades til systemet via debuggeren ved opstart, er der både behov for at kunne kommunikere med debugger og ACIA 2, hvilket i alt giver fire forbindelser eksklusiv GND. Modulerne skal have 12 V, 5 V, 10 V, -10 V og GND. Da kablet, som er til rådighed, kun har otte ledere, er der valgt at designe spændingsregulatorer således, at der kun er behov for én 12 V forsyning. Da ubåden ønskes testet i en sø skal forsyningen være så transportabel som muligt. Derfor er der valgt at bruge en 12 V blyakkumolator til forsyningen. Regulator hardwaren er bygget op som vist på figur Figur 13.2: Spændingsregulator kredsløb. Der benyttes to regulatorer, en 5 V [29] og en DC til DC converter [30]. Begge er implementeret efter en typical application fundet i databladene. DC til DC converteren laver 12 V input om til -12 V output, hvorefter denne spænding reguleres op til -10 V med to dioder. Løber der en strøm gennem en 1N4148 højere end 10 ma, vil spændingsfaldet over den være 1 V [31] og da strømmen forventes at være højere, vil denne opsætning regulere til den korrekte spænding. Udfordringer og fejl Under implementeringen opstod der fejl på systemet, som ikke er forsøgt afhjælpet. Under opstart af programmet er det meningen, at computeren skal modtage 8 bytes gennem ACIA 2, men én byte går konsekvent tabt. Dette kan skyldes at forsyning, hvor der trækkes op til 3 A, og kommunikationsledninger løber side om side i kablet, hvormed der kan forekomme indbyrdes induceret støj. 102

103 Lige efter programmet er startet op, er målingerne på samtlige sensorer stabile. Så snart fremdriftsmotoren eller ballastpumpen startes, kommer der udsving på accelerometermålingerne, som ikke burde være der. Dette menes, at kunne skyldes støj fra motorerne, da den store strøm de trækker, vil kunne sænke forsyningsspændingen eller gøre den ustabil. Efter implementering af servo en til roret begyndte systemet at reset e hele tiden. Det viste sig at servo en gjorde forsyningen ustabil med korte dyk, som fik power-up-reset kredsen til at reset e processoren. For at løse problemet blev kredsen fjernet, så der nu skal reset es manuelt under hver opstart. 103

104

105 Accepttest 14 Efter implementering er det samlede system testet for at afklare, hvorvidt systemet lever op til kravene stillet i kravspecifikationen i afsnit 3. Accepttesten er foretaget ved at benytte controlleren til at komme igennem alle ubådens funktioner og samtidig observere, hvordan det forløber. Desuden observeres ubådens output til den tilsluttede computers terminalprogram, som fungerer som display. Testen gav resultaterne vist i tabel Det ses, at fire krav er bestået og fem krav er dumpet. Område Krav Opfyldt Ubåd: Dybde Målepræcision ± 0,1 m X Fremdrift Målepræcision ± 0,1 knob X Retning Målepræcision 1 X Styring: Dybde Trinvis X Fremdrift Trinvis Retning Trinløs Display: Dybde Opløsning 0,1 m Fremdrift Opløsning 0,1 knob Retning Opløsning 1 X Tabel 14.1: Samlet accepttestsresultater. 105

106

107 Konklusion 15 Formålet med projektet var at få designet et undervandsfartøj der kan agere testplatform for sensorer. Der skulle derfor designes et mikrodatamatsystem til styring af ubåden, samt aflæses sensorer for at modtage data fra omverdenen. Det endelige ubådssystem opfylder kun delvist kravspecifikationen. Kravene til målepræcision på sensorer har ikke været muligt at opfylde, da det ikke var muligt at modtage brugbare målinger fra systemet, efter implementering. Det var muligt at opfylde kravet om trinvis styring af fremdrift og trinløs styring af retningen, men styring af ubådens dybde blev ikke designet til at være trinvis, og kravet blev derfor ikke opfyldt. Det har ikke været muligt at beregne ubådens retning, med de tilgængelige sensorer, og der er derfor kun vist ubådens dybde og hastighed til brugeren. Efter implementering er det muligt, ved hjælp af controlleren, at styre ubåden, som viser sig både i stand til at sejle frem og tilbage, styre retningen samt dykke og stige. Ubåden ses ikke klar til brug som testplatform for sensorer, da der igennem projektet er valgt at afgrænse sig fra opgaver der ses som nødvendige for det endelige testsystem. Det regnes dog for muligt at få ubåden klar til at løse opgaven ved senere videreudvikling på det eksisterende system. 107

108

109 Litteratur [1] Aalborg havn A/S, Aalborg Centralhavn. Bilags-CD aalborghavnpejling.pdf, marts [2] DHI - Bo Brahtz Christensen, Maksimal strøm storm. Bilags-CD maksimalstrom-storm.png, april [3] DHI - Bo Brahtz Christensen, Maksimal strøm tidevand. Bilags-CD maksimalstrom-tidevand.png, april [4] Lloyd Butler VK5BR, Underwater Radio Communication. Bilags-CD uwatercomms.pdf, april [5] Motorola, M Bilags-CD m68k-um.pdf, [6] Auris, Oscillator THT, clock-type. Bilags-CD aqo14.pdf. [7] Seiko Epson Corp., SRM20100LC. Bilags-CD srm20100.pdf. [8] Andrew S. Tanenbaum, Structured Computer Organization, femte udgave. Pearson Education International, [9] Advanced Micro Devices, Am29F010. Bilags-CD am29f010.pdf, november [10] Sofus Birkedal Nielsen, M68000 Debugger/Monitor: TS2MON. Bilags-CD 68000refman.pdf, marts [11] Dallas Semiconductor, Fundamentals of RS 232 Serial Communications. Bilags- CD rs232.pdf, september [12] Philips Semiconductors, 14-stage binary counter. Bilags-CD 4020.pdf, januar [13] Motorola, Asynchronous communication interface adapter. Bilags-CD mc6850acia.pdf. [14] Eilhard Haseloff, Supply voltage Supervisor. Bilags-CD tl7705.pdf, marts [15] Aalborg University - Komponenten, Adc, Dac, Sample Hold. Bilags-CD adc_dac_sample_hold.pdf, april [16] National Semiconductor Corporation, ADC Bit High Speed µp Compatible A/D Converter with Track/Hold Function. Bilags-CD adc0820.pdf, marts

110 [17] Analog Devices, AD CMOS 8-Bit Buffered Multiplying DAC. Bilags-CD ad7524.pdf, november [18] Burr-Brown Corporation, OPA27 - Ultra-Low Noise Precision Operational Amplifiers. Bilags-CD opa27.pdf, marts [19] 11gr411, Software til PEEL. Bilags-CD peel-kode.pdf, [20] 11gr411, Eldiagram rev 1 A3. Bilags-CD eldiagram_rev_1_a3.pdf, maj [21] 11gr411, Eldiagram rev 2 A3. Bilags-CD eldiagram_rev_2_a3.pdf, maj [22] Motorola, Integrated Silicon Pressure Sensor On-Chip Signal Conditioned, Temperature Compensated and Calibrated. Bilags-CD mpx5010dp.pdf, [23] STMicroelectronics, L298 Dual Full-Bridge Driver. Bilags-CD l298n.pdf, januar [24] 11gr411, Software til PWM Arduinoen. Bilags-CD arduino_motor.pde, [25] Motorola, M Bilags-CD m68k-um2.pdf, [26] 11gr411, Software til controller Arduinoen. Bilags-CD controller.pde, [27] 11gr411, Software til computeren. Bilags-CD main2med_omregning.py, [28] 11gr411, Software til M68k. Bilags-CD software-m68k, [29] National Semiconductor Corporation, LM78XX Series Voltage Regulators. Bilags- CD lm7805c.pdf, [30] Maxim Integrated Products, Switched-Capacitor Voltage Converters. Bilags-CD icl7660.pdf, juli [31] Fairchild Semiconductor Corporation, Small Signal Diode. Bilags-CD 1n4148.pdf,

111 Målejournal FNOP-operation A Denne målejournal dokumenterer målinger foretaget på projektets minimumssystem, opbygget som beskrevet i kapitel 4. Målingerne er foretaget på Fredrik Bajers Vej 7 i lokale B1-104 på Aalborg Universitet den af gruppe 411. Formål Målingernes formål er at teste hvordan minimumssystemet reagerer når det bliver udsat for en FNOP-instruktion. Testobjekt På figur A.1 er objektet der bliver testet afbilledet. Figur A.1: Afbildning af minimumssystem, herefter benævnt DUT. 111

112 Teori Ved at sætte en FNOP-instruktion direkte på databussen opnås det at, hvis systemet virker korrekt vil man kunne se at AS, LDS UDS alle operer samtidigt og ved samme frekvens. derudover vil A1 kører ved den halve frekvens af AS, og A2 den halve frekvens af A1. Dette gør processoren fordi den tæller en op i adressen for hver gang den læser FNOP-instruktionen. Måleopstilling På figur A.2 er måleopstillingen af testen afbilledet. Figur A.2: Afbildning af måleopstilling. Anvendt udstyr Instrument AAU-nr. Fabrikant, type m.v. Spændingsforsyning HAMEG HM7042 Multimeter Fluke and Philips FLUKE 37 Logic analyzer Aligent 54621D Måleprocedure Måleproceduren er som følger: 1. Spændingsforsyningen indstilles til 5 volt og tjekkes med multimeter. 2. Testobjektets forsyning og stel forbindes til spændingsforsyningen 3. Prope 1 fra logic analyzer tilsluttes CLK på DUT. 4. Prope 2 fra logic analyzer tilsluttes AS på DUT. 5. Prope 3 fra logic analyzer tilsluttes LDS på DUT. 6. Prope 4 fra logic analyzer tilsluttes UDS på DUT. 112

113 7. Prope 5 fra logic analyzer tilsluttes A1 på DUT. 8. Prope 6 fra logic analyzer tilsluttes A2 på DUT. 9. Målingen fortages nu på alle 6 indgange samtidigt. Resultater Som det ses på figur A.3 Er AS, LDS og UDS alle ens hvilket er korrekt. Det ses yderligere at A1 har den halve frekvens af AS og at A2 har den halve frekvens af A2. Med disse resultater kan det konkluderes at processoren kan kører en FNOP-instruktion korrekt. Figur A.3: Målt FNOP-instruktion på minimumssystem. 113

114

115 Målejournal - ADC B Denne målerapport dokumenterer målinger foretaget på projektets ADC, opbygget som beskrevet i kapitel 4.7. Målingerne er foretaget på Fredrik Bajers Vej 7 i lokale B1-104 på Aalborg Universitet den af gruppe 411. Formål Målingernes formål er at teste at minimumssystemet er i stand til at omsætte en givet spænding til et rigtigt digitalt output. Testobjekt På figur B.1 er objektet der bliver testet afbilledet. Figur B.1: Afbildning af minimumssystem, herefter benævnt DUT. 115

116 Teori Den ADC der anvendes til systemet er tilkoblet 5 volt og har en opløsning på 8 bit, hvilket giver 2 8 mulige kombinationer. Til at teste ADC en er der valgt tre forskellige spændinger 0, 2,5 og 5 volt. For at kunne vurdere om ADC en virker skal disse spændinger omregnes til de værdier de repræsentere. Dette giver at ved 0 volt skulle den digitale værdi gerne være som i ligning B.1 0 V 5 V (28 1) = 0 (B.1) Ved 2,5 volt skal værdien være som i ligning B V 5 V (28 1) = 127 (B.2) Ved 5 volt skal værdien være som i ligning B.2 5 V 5 V (28 1) = 255 (B.3) Måleopstilling På figur B.2 er måleopstillingen af testen afbilledet. Figur B.2: Afbildning af måleopstilling. Anvendt udstyr Instrument AAU-nr. Fabrikant, type m.v. Spændingsforsyning HAMEG HM7042 Multimeter Fluke and Philips FLUKE

117 Måleprocedure Proceduren for at teste systemets ADC er som følger: 1. Spændingsforsyningen indstilles til 5 volt og tjekkes med multimeter. 2. Spændingsforsyningen indstilles til ± 10 volt og tjekkes med multimeter 3. Testobjektets forsyning og stel forbindes til 5 og ± 10 volt på spændingsforsyningen 4. Testobjektets ADC tilkobles et spænding på 0, 2,5 og 5 volt en ad gangen 5. Testprogrammet køres og værdien aflæses for hvert målepunkt Resultater Beregnet værdi Målt værdi Tabel B.1 Som det ses i tabel B.1 passer de målte data overens med de beregnede indenfor ±1, hvilket er acceptabelt og derved virker ADC en som den skal. 117

118

119 Målejournal - DAC C Denne målerapport dokumenterer målinger foretaget på projektets DAC, opbygget som beskrevet i kapitel 4.8. Målingerne er foretaget på Fredrik Bajers Vej 7 i lokale B1-104 på Aalborg Universitet den af gruppe 411. Formål Målingernes formål er at teste at minimumssystemet er i stand til at omsætte en givet digital værdi til den spænding den skal repræsentere. Testobjekt På figur C.1 er objektet der bliver testet afbilledet. Figur C.1: Afbildning af minimumssystem, herefter benævnt DUT. 119

120 Teori Den DAC der anvendes til systemet er tilkoblet 5 volt og har en opløsning på 8 bit, hvilket giver 2 8 mulige kombinationer. Til at teste DAC en er der valgt tre forskellige værdier 0, 127, 255. For at kunne vurdere om DAC en virker skal disse værdier omregnes til de spændinger de repræsentere. I tabel C.1 ses de tre værdier DAC en vil blive testet ved. Digital input Analogt output V REF (255/256) V REF (127/256) V REF (0/256) Tabel C.1: Output fra DAC ved bestemte inputs Ved værdien 0 er spændingen fra DAC en som i ligning C.1 10 V = 0 (C.1) Ved 2,5 volt skal værdien være som i ligning B.2 10 V 127 = 4, 96 V (C.2) 256 Ved 5 volt skal værdien være som i ligning B.2 10 V 255 = 9, 96 (C.3) 256 Måleopstilling På figur C.2 er måleopstillingen af testen afbilledet. Anvendt udstyr Instrument AAU-nr. Fabrikant, type m.v. Spændingsforsyning HAMEG HM7042 Multimeter Fluke and Philips FLUKE 37 Måleprocedure Proceduren for at teste systemets DAC er som følger: 1. Spændingsforsyningen indstilles til 5 volt og tjekkes med multimeter. 120

121 Figur C.2: Afbildning af måleopstilling. 2. Spændingsforsyningen indstilles til ± 10 volt og tjekkes med multimeter 3. Testobjektets forsyning og stel forbindes til 5 og ± 10 volt på spændingsforsyningen 4. DAC sættes til at 0, 128, 256 en efter en 5. Testprogrammet køres og spændingen aflæses for hvert målepunkt Resultater Beregnet værdi Målt værdi 0 V -0,0031 V -4,96 V -5 V -9,96 V -9,6 Tabel C.2 Som det ses i tabel C.2 passer de målte data godt overens med de beregnede og derved kan de konkluderes at DAC en virker. 121

122

123 Målejournal - tryksensor D Denne målejournal dokumenterer målinger foretaget på projektets tryksensor, opbygget som beskrevet i kapitel 7.1. Målingerne er foretaget på Fredrik Bajers Vej 7 i lokale B1-104 på Aalborg Universitet den af gruppe 411. Formål Målejournalen har til formål at undersøge om tryksensoren kan måle trykket i ballasttanken ved fyldt og tom tank, ved opstilling der ønskes brugt i ubåden. Testobjekt På figur D.1 er der et billede af testobjektet, og softwaren brugt til testen kan findes på projekt cd en Figur D.1: Billede af testobjekt i opstillingen. 123

124 Teori Når ballasttanken fyldes med vand vil trykket stige. En stigning i tryk vil få spændingen mellem tryksensoren og ADC en til at ændre sig. Da der er lineært sammenhæng mellem ændring i spænding og ændring i tryk, kan spændingen omsættes direkte til et tryk. Ved brug af formel D.1 kan trykket ved et bestemt spænding beregnes. Spænding 4, 5 10 kpa = tryk [kpa] (D.1) Måleopstilling Måleopstillingen er vist på figur D.2 Figur D.2: Måleopstilling. Anvendt udstyr Instrument AAU-nr. Fabrikant, type m.v. Spændingsforsyning HAMEG HM7042 Måleprocedure Proceduren for målingerne er: 1. Tryksensoren måles for tryk ved tom tank, og programmet beregner trykket 2. Forsøget gentages med tank fyldt op ved brug af motoren Resultater Tryk i ballasttank [kpa] Tom tank 0 Fyldt tank

125 Måleusikkerheder Der blev observeret under forsøget, at målinger foretaget mens pumpen køre, og kort efter, ikke er brugbare, da trykket i slagen skal stabilisere sig efter en ændring. 125

126

127 Målejournal sensor-accepttest E Denne målerapport dokumenterer målinger foretaget på projektets styring, opbygget som beskrevet i kapitel 7. Målingerne er foretaget på Fredrik Bajers Vej 7 i lokale B1-104 på Aalborg Universitet den af gruppe 411. Formål Målejournalen har til formål at dokumentere om sensorene opfylder kravene stillet i tabel 7.1: Testobjekt Der vises på figur E.1 testobjektet Figur E.1: Billede af testobjektet. 127

128 Teori Den samplede data fra de fire ADC er sender systemet i en fast rækkefølge (x,x,y,y,z,z,tryk,tryk), hvilket bliver oversat på computeren til værdier for de 3 accelerometre og trykket i ballasttanken. De tre accelerometre bliver brug til beregning af ubådens hastighed og tilbagelagte vej ved brug af formlerne givet i afsnit 7.2 der forklare om accelerometrene. Måleopstilling Måleopstillingen er vist på figur H.2 Figur E.2: Skitse af testopstilling. Anvendt udstyr Instrument AAU-nr. Fabrikant, type m.v. Spændingsforsyning HAMEG HM7042 Måleprocedure Proceduren for målingerne er: 1. Der gives kommando til ubåden skal dykke ved brug af controlleren, og der observeres om trykket når at stabilisere sig før målinger tages 2. Der bliver dykket indtil programmet stopper motoren, og trykket i ballasttanken aflæses 3. Ballasttanken tømmes for vand indtil programmet stopper motoren, og trykket aflæses 4. Accelerometret bliver flyttet 10 cm i z-aksens retning, hvor de to andre accelerometre er slået fra, og der noteres den beregnede tilbagelagte afstand, gentages 10 gange 5. Alle 3 accelerometre aktiveres og adxl330 eren flyttes 10 cm ved en kombination af alle 3 akser og den tilbagelagte afstand beregnet aflæses. Forsøget gentages 10 gange 128

129 Resultater Beregnet værdi Målt værdi Enhed Stop for pumpe Pa Stop for pumpe 0 0 Pa Målepræcision dybde 10 Invalid data cm Målepræcision fremdrift 10 Invalid data cm Tabel E.1: maalejournal:sensor-accept Måleusikkerheder Der er fejl på målingerne af målepræcision på dybde og fremdrift, idet en ændring på et niveau på ADC en har et spænd på 0,36 m s 2. Endvidere er ændringen fra niveauet ved stillestående til næste niveau fjernet for at stoppe accelerometret i at give en hastighed når det ligger stille. Endnu en fejl kan tillægges accelerometret skal holdes i præcis samme vinkel under hele flytningen for at det beregnede offset passer. Det blev derfor ikke set muligt at frembringe brugbare data på accelerometret med redskaberne til rådighed. 129

130

131 Målejournal - Motorer F Denne målerapport dokumenterer målinger foretaget på projektets motorer. Målingerne er foretaget på Fredrik Bajers Vej 7 i lokale B1-104 på Aalborg Universitet den af gruppe 411. Formål Målingernes formål er at teste hvilken peak strøm der løber igennem projektet to motorer, hvilket er en til fremdrift og en til ballastpumpe. Testobjekt På figur F.1 er motoren til fremdrift afbilledet, og på figur F.2 er ballastpumpen afbilledet. Figur F.1: Afbildning af motor til fremdrift, herefter benævnt DUT. 131 Figur F.2: Afbildning af ballastpumpe, herefter benævnt DUT.