Klimaovervågningssystem

Transkript

1 AALBORG UNIVERSITET INSTITUT FOR ELEKTRONISKE SYSTEMER AFDELING FOR KOMMUNIKATIONSTEKNOLOGI Klimaovervågningssystem ELEKTRONIK 4. SEMESTER GRUPPE 415 Maj 2004

2

3 Institut for Elektroniske Systemer Aalborg Universitet SYNOPSIS: TITEL: Klimaovervågningssystem PROJEKTPERIODE: P4, 2. februar maj, 2004 PROJEKT GRUPPE: E4, 415 GRUPPEMEDLEMMER: Jens Christensen Jes Vestervang Jensen Mads Sølver Svendsen Thomas Kjærulff Torben Green Peter August Simonsen VEJLEDER: Ove Andersen Center for Personkommunikation ANTAL KOPIER: 9 RAPPORT SIDEANTAL: 196 BILAG: 1 CD-ROM Denne rapport omhandler analyse og design af et klimaovervågningssystem til overvågning af temperatur og relativ luftfugtighed. Systemet bygger på en Motorola mikroprocessor og debugger / monitorsystemet TS2MON. Først analyseres de funktionaliteter, systemet ønskes udstyret med. Dette leder videre til en kravspecifikation, der specificerer præcist hvilke krav, de opstillede brugssituationer stiller til systemet. Ud fra denne kravspecifikation kan systemet deles op i hardware og software, der herefter designes. Designet af hardwaren tager udgangspunkt i et minimumsystem, hvor der kan afvikles en debugger / monitor til at teste og overvåge systemet. Herudover opbygges de hardwareenheder, der er nødvendige for at realisere de funktionaliteter, der stilles krav om i kravspecifikationen. Hardwaren designes med en I 2 C-bus til måleenhederne, der gør det muligt at udvide systemet med flere sensorer. Dette vil dog kræve en opdatering af softwaren. Der udvikles software til at styre hardwaren og realisere en brugergrænseflade til systemet. Resultatet af designet er et klimaovervågningssystem, der kan måle og lagre data om temperatur og relativ luftfugtighed, efter indstillinger, der foretages af systemets bruger. Måledata kan desuden udlæses til en PC i et format, der kan importeres til for eksempel et regneark, hvor data kan bruges til statitik over klimaforholdene.

4

5 Institute of Electronic Systems Aalborg University ABSTRACT: TITLE: Climate monitoring system PROJECT PERIOD: P4, February 2nd - May 26th, 2004 PROJECT GROUP: E4, 415 PROJECT PARTICIPANTS: Jens Christensen Jes Vestervang Jensen Mads Sølver Svendsen Thomas Kjærulff Torben Green Peter August Simonsen SUPERVISOR: Ove Andersen Center for Personkommunikation COPIES: 9 NUMBER OF PAGES: 196 ATTACHMENT: 1 CD-ROM This report deals with the analysis and design of a system for monitoring temperature and relative humidity. The system is built around a Motorola microprocessor and the debugger / monitor system TS2MON. At first the desired functionalities of the system are analysed. This leads to a requirement specification, which specifies the needed requirements for the system based on its intended use. Using the requirement specification, the system is divided into a hardware and a software part, which are then designed. The design of the hardware is based on a minimum system where the system can be tested and monitored using the debugger / monitor. In addition, the hardware needed to realise the required functionalities, is built. In order to ease the task of adding additional sensors the system communicates with sensors over an I 2 C BUS. Adding sensors will demand an update of the system software. The system software is designed to operate the hardware and to implement a user interface. The climate monitor is able to measure temperature and relative humidity and to store the collected data with intervals set by the system user. It is possible to transfer the stored data onto a PC. The data is transferred in a format usable in statistical applications such as spreadsheets.

6

7 Forord Denne rapport er skrevet i løbet af foråret 2004 i forbindelse med 4. semester projektet på Aalborg Universitet. Temaet for semesteret er Mikrodatamatsystemer og projektet tager udgangspunkt i projektforslaget Overvågning af indeklima. Vejleder på projektet er Ove Andersen fra Center for Personkommunikation. Rapporten er delt op i et antal dele, der hver især beskriver en fase af projektet. I disse dele dokumenteres arbejdet med analyse, opstilling af krav, design og test af systemet til overvågning af indeklima. I forbindelse med opbygning og afprøvning af de designede kredsløb, har gruppen gjort brug af Institut for Elektroniske Systemers laboratorie på Fredrik Bajers vej 7 B Henvisninger til anvendte kilder læses som (forfatter årstal), der gør det muligt at identificere kilden i litteraturlisten sidst i rapporten. I appendiks C på side 177 findes det samlede eldiagram over det opbyggede microprocessorsystem. Vedlagt rapporten findes en CD-ROM, som indeholder kildekoden til systemets software og datablade for anvendte komponenter. Henvisninger til datablade i rapporten refererer til filer på denne CD-ROM. En liste over indholdet på CD en findes i appendiks E. Desuden findes bagest i rapporten oversigter over tabeller og figurer. Jens Christensen Jes Vestervang Jensen Mads Sølver Svendsen Peter August Simonsen Torben Green Thomas Kjærulff 3

8 Indhold 1 Indledning Udviklingsmetoder I Analyse 10 2 Systemanalyse Use Cases Overvåg klima Konfigurér system Overfør data Alarmér Udlæs data Kravspecifikation Systemets begrænsninger Funktionelle krav Overvåg klima Konfigurér system Overfør data Alarmér Udlæs data Eksterne grænseflade-krav Krav til menusystem Eksterne hardware grænseflader Accepttest og brugervejledning

9 INDHOLD II Design 23 4 Designforudsætninger Konventioner M68k specifikationer Arkitektur Ekstern hardwaregrænseflade Softwarekrav og begrænsninger Timing ved asynkron overførsel på databussen Debugger/monitor-systemet TS2MON Anvendelse Interrupt-vektorer Minimumssystem Kompilering/simulerings systemet IDE68k Testcompiler - GCC Designmetoder III Hardware 34 5 Strukturdesign Hardware udover minimumsystemet Modulintegration Moduldesign af minimumsystem Power-on resetkredsløb Clock-generator Hukommelse Adressedekodning Interrupthåndtering NMI Test af minimumssystem Moduldesign af øvrigt hardware Display Taster og alarm I 2 C-bus

10 INDHOLD I 2 C controller: PCF Temperatursensor Fugtighedssensor Opkobling af sensorer EEPROM Sekund-generator Test RS IV Software 82 8 Programdesign Symbolforklaring Funktionaliteter Procesopdeling Procesdesign Menusystem Sekundhåndtering PC-grænseflade Datastrukturer Moduldesign Generelle funktioner delay int2ascii Jiffytoiso Isotojiffy Debugrutiner fra TS2MON Funktioner til I 2 C Funktioner til EEPROM Hent temperatur og luftfugtighed Sekundhåndtering Moduldesign af ur Dataopsamling Test

11 INDHOLD Alarm Menusystem Menuer Test Skriv til display PC-grænseflade Grænseflader Moduler Test af PC-grænseflade V Implementering Integrationsstrategi Hardwarenære moduler Procesintegration Menusystem Sekundhåndtering PC-grænseflade Udførsel af accepttest Software-bugs Udvidelsesmuligheder Software Hardware Konklusion 158 A Foreløbig brugervejledning 159 B Accepttestspecifikation 164 C Eldiagram 177 D Stykliste 185 E Filliste for bilags-cd 186 7

12 Kapitel 1 Indledning Overvågning af indeklima kan være relevant i mange sammenhænge. Ofte vil det være i forbindelse med opbevaring af ting, som ikke kan tåle udsving i indeklimaet. Af eksempler kan nævnes arkivering af film, bøger og billeder, særligt skrøbelige og værdifulde ting som kalkmalerier i kirker eller museumsgenstande. Endelig er der mere dagligdags ting som drivhuse i gartnerier og kølerum til opbevaring af fødevarer. Typisk er det temperaturen og luftfugtigheden der er vigtigst, hvorfor dette projekt fokuserer på disse parametre. I situationer, hvor indeklimaet er kritisk, vil det være relevant at sikre, at det holdes inden for nogle definerbare grænseværdier. En måde at opnå dette, er at aktivere en alarm, hvis det for eksempel bliver for varmt. Denne kan gøre personnel på stedet opmærksom på, at der er en situation, der skal udbedres. Derudover kan det være relevant at kunne udlæse en historik over, hvordan indeklimaet har været over den sidste periode, specielt hvis det har overskredet de tilladte værdier. En sådan historik vil efterfølgende kunne anvendes til at vurdere, hvilke konsekvenser overskridelsen kan have haft. Hvis overskridelsen f.eks. sker i forbindelse med fødevareopbevaring, risikeres det at varerne må kasseres, hvis overskridelsen har været for stor, og varet for længe. En sådan overvågning kan i en vis udstrækning klares manuelt, men samme overvågning er i de fleste tilfælde nødvendig hele døgnet. Det vil derfor være hensigtsmæssigt at denne overvågning varetages af et system der kan kontrollere klimaparametrene løbende. 1.1 Udviklingsmetoder For at opnå et struktureret udviklingsforløb, er der gennem projektet gjort brug af en række værktøjer som er blevet præsenteret i PE-kurset Struktureret systemudvikling. I dette afsnit vil de vigtigste af disse værktøjer blive præsenteret. Der tages igennem udviklingsprocessen udgangspunkt i SPU 1 s V-model fra (Stephen Biering-Sørensen & Madsen 2000). Denne model giver en struktureret tilgang til opdeling af programmet eller systemet i mindre dele. Dermed opnås på det nederste niveau en række moduler som er så velspecificerede at de umiddelbart kan implementeres. Dette 1 Struktureret Program Udvikling 8

13 1.1. UDVIKLINGSMETODER Figur 1.1: V-model gøres på baggrund af den dokumentation, som er udarbejdet under de forskellige designfaser. Til hvert designniveau knyttes også et test- eller integrationsdesign, så det på forhånd overvejes, hvordan de forskellige moduler skal integreres for at udgøre et samlet program. Den første del af rapporten omhandler udarbejdning af en kravspecifikation for et klimaovervågningssystem. Her gøres brug af UML 2 til at opstille en række brugssituationer, Use Cases, for systemet. Disse skal bruges til at danne overblik over hvilke funktionaliteter der ønskes. På baggrund af disse usecases udarbejdes en kravspecifikation, som fastsætter en række konkrete krav til systemet. I forbindelse med kravspecifikationen udarbejdes en accepttestspecifikation, som er at finde i appendiks B sammen med resultaterne fra udførelsen af den. Del II beskriver de værktøjer og metoder, der tages i brug i designfasen, ligesom allerede kendte krav og begrænsninger også behandles. Del III og IV omhandler design af hhv. hard- og software til systemet. I afsnittet 4.6 redegøres for, hvordan opdelingerne i designfasen foretages. Del V beskriver, hvordan integrationen af hard- og software gennemføres. Efter designfasen er gennemført og systemet er blevet integreret til en helhed, udføres accepttesten. Resultatet af denne test kommenteres i kapitel 12. Ud fra disse resultater konkluderes, hvorvidt det er lykkedes at konstruere et system, som lever op til kravspecifikationen. 2 UML: Unified Modeling Language 9

14 Del I Analyse 10

15 Kapitel 2 Systemanalyse Denne analyse vil fokusere på at identificere de funktionaliteter, klimaovervågningssystemet skal realisere. Dette gøres ved at opstille Use Cases, der bekriver de ønskede funktionaliteter, hvordan disse funktionaliteter skal bruges og hvem eller hvad, der gør brug af dem. På baggrund af Use Case-analysen kan kravene til systemet opstilles i en kravspecifikation. I denne opstilles de specifikke krav til systemets funktionalitet. Til at understøtte kravspecifikationen er desuden skrevet en foreløbig brugervejledning, der redegør for brugen af systemets eksterne grænseflader. Denne brugervejledning er at finde i appendiks A på side 159. Kravspecifikationen identificerer desuden de begrænsninger, der bliver i systemet, når der udvikles en laboratoriemodel med udgangspunkt i bestemte komponenter og hjælpemidler. For at følge op på at kravspecifikationen bliver opfyldt, specificeres en accepttest, som udføres på det færdige system. Denne test kan findes i appendiks B på side Use Cases Systemet, der ønskes opbygget, skal bestå af en mikroprocessor, hvortil der tilsluttes et antal sensorer, som kan måle klimadata i form af temperatur og relativ luftfugtighed(rf). Systemet skal kunne gemme disse data. Der skal være et display, hvor aktuelle måleværdier kan aflæses. Der skal desuden være mulighed for at overføre de målinger, der er gemt i hukommelsen, til en PC. Endelig skal systemet kunne give en alarm, hvis klimadataene overskrider de indstillede alarmniveauer. På figur 2.1 er vist et system, der kan opfylde den ønskede funktionalitet. Systemet er delt op i 5 Use Cases. I det følgende beskrives det, hvordan hver enkelt Use Case opfylder en ønsket funktionalitet i forhold til den aktør, der gør brug af systemet eller som systemet gør brug af. 11

16 KAPITEL 2. SYSTEMANALYSE tur" & - ågningsenhed "! #%$ $ ugtighed" rvå figurér em rfør "PC" + $),# r" "')( * æser" & æ rmér "Læser" Figur 2.1: System delt op i Use Cases Overvåg klima Målbeskrivelse Denne Use Case initieres med et interval på ét sek. Når den initieres, indsamles og lagres de aktuelle værdier for RF samt temperatur. Normalscenarie 1. Målinger af Temperatur og Relativ luftfugtighed gentages med et interval på ét sek 2. Måledata opsamles fra sensorer 3. Måledata lagres i hukommelsen Undtagelser 1. Måledata lagres ikke nødvendigvis hver gang normalscenariet køres igennem, men kun med det interval, der er defineret i Use Casen Konfigurér system. 2. Når hukommelsen er fyldt, kan lagringen enten ophøre, eller de ældste data overskrives, afhængigt af hvordan systemet er konfigureret i Use Casen Konfigurer system. En anden mulighed er, at data sendes direkte til fjernbrugeren. Derved gemmes data ikke i hukommelsen på systemet. 12

17 2.1. USE CASES Konfigurér system Målbeskrivelse Det skal være muligt for aktøren Konfigurator at indstille, hvor ofte der skal foretages målinger med sensorerne. Det skal være muligt for aktøren at ændre ved hvilke værdier for klimaparametrene, alarmen skal initieres. Desuden skal det kunne vælges, hvorvidt hukommelsen skal overskrive den ældste måling, når der ikke er mere hukommelse, eller om lagringen skal stoppes, når hukommelsen er brugt. Endvidere skal det være muligt at indstille hukommelsen til at sende målingerne direkte til en PC. Normalscenarie 1. Konfigurator initierer konfigurationsprocessen 2. Konfigurator bliver præsenteret for konfigurationsparametrene 3. Konfigurator vælger hvilken parameter der skal ændres og ændrer den 4. Ændringerne gemmes 5. Konfigurator bliver præsenteret for konfigurationsparametrene 6. Der vælges en anden parameter eller konfigurationen afsluttes Undtagelser Ved førstegangsbrug skal systemet have et sæt standardindstillinger. Det skal endvidere være muligt for aktøren at genskabe disse indstillinger. Systemet skal huske indstillingerne når det bliver slukket Overfør data Målbeskrivelse At overføre de måledata, der er gemt i hukommelsen, til en PC. Normal scenarie 1. Initieres ved at Fjernlæser åbner forbindelsen igennem en PC 2. Fjernlæser forespørger de ønskede data 3. Systemet svarer med disse data 4. PC en gemmer eventuelt dataene i en fil 5. Fjernlæser skal selv sige god for at dataene er modtaget, og dermed vælge at de kan slettes fra systemet. 13

18 KAPITEL 2. SYSTEMANALYSE 6. Sessionen afsluttes ved, at fjernlæser afbryder kommunikationen Undtagelser 1. Hvis forbindelsen afbrydes midt i en overførsel, skal systemet automatisk vende tilbage til normal tilstand Alarmér Målbeskrivelse Use Casen Alarmér skal give alarmmodtageren et signal, når de indstillede grænseværdier overskrides. Når forholdene normaliseres, skal alarmen annulleres. Der skal optages en log over udløste alarmer. Normalscenarie 1. Initieres af overskridelse af grænseværdier for temperatur eller relativ fugtighed 2. Alarmen sender signal til alarmmodtager Alarmsignalet indeholder information om alarmtype 3. Alarmmodtageren standser alarmen 4. Alarmen annulleres ved normalisering af forholdene 5. Det gemmes en log for alarmen, der indeholder alarmtype, overskridelsens størrelse, tidspunkt og varighed. Undtagelser 1. Hvis alarmmodtageren ikke standser alarmen, før forholdene normaliseres: (a) Alarmen annulleres automatisk ved normalisering af forhold 2. Hvis der kommer flere alarmer samtidig: (a) Der optages log over alle alarmer Udlæs data Målbeskrivelse Use Casen Udlæs data skal vise max-, min- og gennemsnitsværdier, samt de aktuelle værdier for læser, på et display. 14

19 2.1. USE CASES Normalscenarie 1. Udlæs data initieres af læser 2. Læser vælger de data, der skal skrives på displayet 3. Data vises på displayet 4. Udlæs data afsluttes af læser 15

20 Kapitel 3 Kravspecifikation I kravspecifikationen specificeres de præcise krav, der stilles til systemet. Kravene er delt op i funktionelle krav og eksterne grænseflade-krav. De funktionelle krav dækker over de funktioner systemet skal have for at opfylde de opstillede Use Cases. Kravene til de eksterne grænseflader beskriver hvilke forbindelser, der skal være til eksterne enheder, samt hvordan systemet skal kunne betjenes. 3.1 Systemets begrænsninger Der er blevet lavet visse begrænsninger i dette projekt for at forenkle dele af projektet, så der kan blive lagt vægt på indholdet fra PE kurserne. I et færdigudviklet klimaovervågningssystem, vil det være praktisk, hvis der er en backup spændingskilde, så systemet kan fortsætte med at tage målinger, selvom strømmen går. Hvis klimaovervågningssystemet f.eks. bliver benyttet i et køleanlæg med fødevarerprodukter, vil det være nødvendigt at kunne se om fødevarene er blevet udsat for en for høj temperatur, mens strømsvigtet stod på. Et backup system vil ikke blive implementeret i dette system. Systemet vil tage udgangspunkt i at benytte en laboratoriestrømforsyning uden backupbateri. Der vil i projektet ikke blive lagt vægt på systemets udseende og design, da målet med systemet ikke er at få et færdigt produkt. I stedet udvikles en laboratorie model, der let kan fejlfindes på, og let kan kobles op med strømforsyning, oscilloskop og andet testudstyr. Det er blevet valgt at benytte en Motorola processor, da undervisningen er rettet mod denne. Det færdige system vil blive forsynet med en debugger, der stiller krav til software såvel som hardware. Debuggeren/monitoren kan benyttes til at se status for programcounteren, info om data- og adresse-registre samt flere andre systemrelevante informationer. 16

21 3.2. FUNKTIONELLE KRAV 3.2 Funktionelle krav Overvåg klima I dette afsnit beskrives kravene til klimaovervågning og lagring af data. 1. Skal kunne måle temperatur: (a) Systemet skal kunne måle temperaturer fra -20 C til +60 C. (b) Den målte temperatur må højst afvige ±0,5 C i forhold til den faktiske, når den er mellem -5 C og 30 C. Uden for dette område må den målte temperatur afvige ±2 C i forhold til den faktiske. (c) Temperaturen skal kunne vises og lagres med en opløsning på 0,1 C. 2. Skal kunne måle relativ luftfugtighed (RF): (a) Systemet skal kunne måle RF fra 5 til 95 %. (b) Den målte RF må højst afvige ±5 % fra den faktiske. Måleværdier skal ligge mellem 0 og 100 % RF, da værdier herudover ikke er mulige. (c) Måledata skal kunne vises og lagres med en opløsning på 1 %. Fælles for ovenstående er, at det kun er sensorerne og ikke hele systemet der befinder sig i det målte klima. 3. Lagring: (a) Der skal foretages én måling per sekund som ikke nødvendigvis lagres, men blot benyttes til alarmer, gennemsnit, maksimum og minimum. (b) Lagringsinterval skal kunne være mellem 1, 15, 30 eller 60 sekunder, eller 10, 15, 30 eller 60 minutter. Intervallet indstilles i Use Casen Konfigurér system. (c) Der skal være plads til 1000 lagrede målinger i hukommelsen. (d) Målingerne skal gemmes i kronologisk rækkefølge. Derudover skal måleinterval og starttidspunktet for målingerne fremgå ved udlæsning af lagrede data, hvilket giver mulighed for udregning af tidspunktet for hver enkelte måling. 4. Ikke-verificérbare krav: (a) Systemet skal forberedes på mulighed for tilslutning af flere sensorer, så omfattende software- og hardwareændringer ikke påkræves, hvis muligheden ønskes Konfigurér system I dette afsnit beskrives de funktionelle krav til Use Casen Konfigurér system. 1. Det skal være muligt at indstille systemets lagringsinterval til 1, 15, 30 eller 60 sekunder samt 10, 15, 30 eller 60 minutter. 17

22 KAPITEL 3. KRAVSPECIFIKATION 2. Alarmniveauerne skal kunne indstilles uafhængigt af hinanden. Alarmniveauet for temperaturen skal kunne indstilles med 1 C interval. Alarmniveauet for luftfugtigheden skal kunne indstilles med et interval på 1 % relativluftfugtighed. 3. Det skal være muligt at indstille en øvre og en nedre grænse for alarmniveauerne. 4. Lagringen skal kunne indstilles til 3 forskellige tilstande, således at: (a) De ældste data overskrives, når der ikke er mere hukommelse til rådighed (b) Lagringen stoppes når der ikke er mere hukommelse til rådighed (c) Dataene sendes direkte til en PC 5. Det skal være muligt at indstille dato og tid for systemet. Uret må ikke gå mere end 1 sek forkert per time. 6. Det skal være muligt at genskabe standardindstillinger. 7. Systemet skal kunne huske de gemte indstillinger ved strømafbrydelse Overfør data Det skal være muligt at overføre de data som er lagret i systemets interne hukommelse til en PC. I dette afsnit beskrives kravene til hvordan dette skal foregå. 1. Overførselshastighed: Det skal være muligt at overføre data med en hastighed på 9600 baud 1 2. Kommunikationen skal foregå med tegn i ASCII-formatet. Det vil sige at måleværdierne fra hukommelsen skal konverteres til talværdier som skrives med tegn. Begrundelsen for dette er, at der som PC-software skal kunne bruges et standard terminalprogram. Som eksempler kan nævnes HyperTerminal som følger med Microsoft Windows, eller Minicom til Linux. 3. Der skal være mulighed for at overføre samtlige målinger fra systemets hukommelse. Dataene skal overføres i et format så det umiddelbart kan importeres til et regneark. Dette gøres ved at separere de enkelte celler med et semikolon, og separere hvert datasæt med et linjeskift. Hvert målesæt sendes sammen med en tidsstempling efter ISO Det vil sige at hver linje bliver på formen: ÅÅÅÅ-MM-DD TT:MM:SS;±##,#;###<Linjeskift> Den første linje skal indeholde etiketter for kolonnerne, det vil sige Tid ; Temperatur ; Fugtighed <Linjeskift>. 4. Der skal være mulighed for at overføre nøgledata om klimaet i form af maximum, minimum, gennemsnit og aktuelle værdier for henholdsvis fugtighed og temperatur. 5. Der skal være en kommando til at slette alle de gamle måledata fra hukommelsen. Se tabel 3.1 for beskrivelse af kommandoerne. 1 Baud: antal mulige overførte bits per sekund. 18

23 3.2. FUNKTIONELLE KRAV Kommando nu send slet hlp Forklaring Udlæs øjeblikkelig temperatur og fugtighed, gennemsnit og ekstrema Overfør alle målinger gemt i hukommelsen Slet alle gemte målinger Udskriv liste over kommandoer og deres funktion Tabel 3.1: Kommandoer i terminalvinduet Udvidelsesmuligheder Der kan, sammen med måledataene, sendes en form for checksum 2, således at der er mulighed for at kontrollere at der ikke sker nogen fejl under overførslen til PC en Alarmér For at opnå den ønskede funktionalitet, er der opstillet følgende testbare krav til alarmen: 1. Alarmen skal have en udgang, som går høj ved aktivering af alarmen. Dette kan styre en ekstern signalgiver, fx en sirene. 2. Alarmen skal automatisk annulleres, når grænseværdier ikke længere er overskredne. 3. Når alarmen udløses skal der kunne udlæses informationer om alarmtype, starttidspunkt og ekstrema for den overskredne værdi på displayet ved at tilgå alarmloggen. 4. Der optages en log over alarmerne, indeholdende alarmtype, tidspunkt, varighed samt ekstrema for overskridelsen. 5. Der skal kunne være log for de sidste 10 alarmer i hukommelsen. 6. Systemet skal i tilfælde af flere samtidige alarmer skrive alarmdata for hver alarm i hver sin log. 7. Hvis menusystemet benyttes, når en alarm indtræffer, skal alarmudgangen gå høj, mens alarmvisning i displayet først udføres, når menusystemet vender tilbage til højeste niveau. Det ønskes, at systemet kan udvides med følgende funktionali- Udvidelsesmuligheder tet: Hvis systemet udbygges med flere sensorer skal loggen og udlæsningen til displayet desuden indeholde information om sensor-id. 2 Checksum: Talværdi, der beregnes ud fra sendte data, som bruges til at kontrollere modtagne datas integritet. 19

24 KAPITEL 3. KRAVSPECIFIKATION Udlæs data Formålet med denne Use Case er at udlæse de data, som systemet har aflæst fra sensorerne. Displayet skal samtidig sætte Konfigurator i stand til at tilgå de menuer og undermenuer, der bliver valgt, visuelt. De specifikke krav til udlæsningen af data er: 1. Udlæsningen skal bestå af 2 linjer med 16 tegn pr. linje. Udlæsningen skal være alphanumerisk således at både bogstaver, tal og specialtegn kan gengives 2. Tastaturet skal bestå af en < tast, en > tast, en enter tast og en escape tast. Knapperne vil herefter blive benævnt som [<], [>], [enter] og [esc]. 3. Ved hjælp af udlæsningen skal det være muligt direkte at tilgå max-, min- og gennemsnitsværdier. Gennemsnitsværdien skal udregnes over et døgn ved at tage gennemsnittet af hver 5. måling, dvs. hvert 5. sekund. Kl. 00:00:00 skal gennemsnitsværdien sættes til aktuel temp/fugt -værdi. Det skal desuden være muligt at tilgå de aktuelle måleværdier fra øverste niveau i menuen. 4. Udlæsningen skal vise de menuvalg og indstillinger som konfigurator foretager. 5. Når der indtræffer en alarm skal udlæsningen gøre opmærksom på dette ved at vise et! ud for enten temp eller fugt, alt efter hvilken alarm der er tale om. Udvidelsesmuligheder Når en alarm indtræffer kan der gøres opmærksom på dette ved at lade baggrundsbelysningen blinke. Udlæsningens type er endnu ikke afgjort, og falder valget på en udlæsning uden baggrundsbelysning udelukkes denne form for alarmering. 3.3 Eksterne grænseflade-krav Krav til menusystem Da det skal være muligt at ændre indstillinger for systemet samt at se aktuel temperatur/rf og tidligere alarmer, skal der udvikles et menusystem til systemet. Menusystemet skal opbygges så, der kan navigeres rundt i menuerne samt ændre indstillinger ved hjælp af 4 knapper. Knapperne er [<], venstre, [>], højre, [enter] og [esc], escape. På fig. 3.1 ses en oversigt over menusystemet. Systemet skal opbygges som på fig Fælles for alle blokke, og hermed menupunkterne i det endelige system er at trykkes der på [enter], vælges et menupunkt, og trykkes der [esc] gås et niveau tilbage i menusystemet. Hvis systemet er ude i datavisning, skal den aktuelle temperatur samt luftfugtighed vises i displayet. Tastes hhv. [<] eller [>]-pilen skal displayet vise maximums-, minimums- eller gennemsnitstemperatur, og fortsætte med dette indtil der foretages en ny handling. Tastes [enter] skal systemet gå ind i hovedmenuen, hvor der med piletasterne skal kunne vælges mellem to muligheder, Alarmlog og Konfiguration. Når der trykkes på [enter], vil det viste menu-punkt blive valgt og det kan vælges at gå ind i Alarmlog-menuen 20

25 / 3.3. EKSTERNE GRÆNSEFLADE-KRAV sning 423 uel må ling ;< = ;> imum må ling imum må ling + nemsnitsmå ling [esc] er] edmenu [esc]! er][ esc]! er] menu "# $8 9. o :- o [esc] "# $ alle data %& er] tionsmenu, -$( *.- o Indstil tid M å )) 0/!1 / ed 23 $ $( * $( $ #$( 7! [esc]! er] ' $( ) *! er] + indstilling Figur 3.1: Oversigt over menusystemet eller Konfigurationsmenuen. Ved at trykke [esc] skal der kunne gås et niveau tilbage til datavisning. Da der er for mange punkter i både alarmlog-menuen og konfigurationsmenuen til at de kan vises på een gang i displayet, skal der kunne bladres rundt i menuen vha. [<] samt [>]-piletasterne. I alarmlog-menuen kan de forskellige alarmer, der har været, vælges og data for disse skal kunne blive vist. Uden øvrige tastetryk vises alarmnummer og dato for denne. Tastes [enter], vil alarmens tidspunkt, varighed, type og største overskridelse blive vist. Hukommelsen indeholder altid de 10 sidst indkomne alarmer, forudsat at der har været 10 alarmer. I konfigurationsmenuen skal der kunne foretages indstilling af systemet. Ved at trykke på [<] og [>]-pilene skal der kunne bladres blandt de forskellige parametre. Ved tryk på [enter], når den ønskede parametre vises, skal der være mulighed for at ændre indstillingerne for denne. Tastes [enter] efter parametrene er blevet indstillet, gemmes disse ændringer og konfigurationsmenuen vises på ny. Tastes [esc] går systemet tilbage til konfigurationsmenuen, uden at lagre indstillingen, og brugeren får mulighed for at vælge en anden indstilling. 21

26 KAPITEL 3. KRAVSPECIFIKATION Ved gentagne tryk på [esc] skal der kunne gås tilbage til Datavisning. Systemets funktion er her blevet beskrevet. En detaljeret gennemgang af menusystemet, samt referencer til skærmbilledernes udseende findes i brugervejledningen på side Eksterne hardware grænseflader Forsyningsspænding Systemet skal fungere med en intern forsyningsspænding på 5 V. Denne spænding skal leveres af en laboratoriestrømforsyning. Det nøjagtige strømforbrug af systemet kendes ikke, da det ikke på forhånd er fastsat hvilket hardware der skal bruges. Det vurderes dog at 1 A vil være tilstrækkeligt, derfor kræves en strømforsyning der mindst kan levere dette. PC forbindelse Forbindelsen til PC, skal ske igennem et RS-232 interface. Dette interface vil bliver beskrevet nærmere i afsnit 7.5 på side 74. Alarmudgang Der skal være en alarmudgang, som kan aktivere en ekstern signalgiver. Den skal give et signal på 5 V, når der er alarm, og skal mindst kunne levere 20 ma. 3.4 Accepttest og brugervejledning Ud fra kravspecifikationen kan det nu bestemmes hvilke hardware- og softwareenheder, der skal til, for at realisere de opstillede krav. For at sikre at kravene bliver opfyldt, er der skrevet et accepttestspecifikation, som beskriver de tests, der verficerer systemets funktion. Accepttesten findes i appendiks B på side 164, hvor resultaterne af de enkelte tests er kommenteret. For at kunne opbygge brugergrænsefladen til systemets udlæsning af data, findes der i appendiks A på side 159 en foreløbig brugervejledning, der beskriver, hvordan brugergrænsefladen skal benyttes. I accepttesten bliver der også testet for at brugergrænsefladen lever op til brugervejledningens specifikationer. 22

27 Del II Design 23

28 Kapitel 4 Designforudsætninger Med udgangspunkt i den foregående analyse og opstillede kravspecifikation, skal der designes et system, som kan opfylde de stillede krav. I dette kapitel bliver der gjort rede for hvilke forudsætninger designet tager udgangspunkt i. Som nævnt under systemets begrænsninger i kravspecifikationen, afsnit 3.1 på side 16, vil designet af systemet tage udgangspunkt i en Motorola serie mikroprocessor. Valget af processor stiller krav til den hardware, der ønskes tilsluttet systemet. Valget giver desuden mulighed for at bruge et allerede udviklet debuggerprogram til at overvåge afviklingen af softwaren på mikroprocessorsystemet. Dette kapitel vil gennemgå den valgte mikroprocessor med hensyn til opbygning, funktionaliteter og begrænsninger. Dette gøres for at give et overblik over forudsætningerne for det videre design af hardware. Derefter gennemgås de udviklingsprogrammer, der bruges i forbindelse med designet af et Motorola mikroprocessorsystem. Programmerne gennemgåes med hensyn til funktionaliteter, muligheder, begrænsninger og hvilke krav programmerne stiller til den hardware de skal afvikles på. Desuden bliver det gennemgået hvilke metoder, der bliver gjort brug af i designfasen af hardware og software. 4.1 Konventioner Ved behandling af hardwarerelaterede emner benyttes vedtagne konventioner for, hvordan en række egenskaber ved ben-identifikationer, talværdier etc. vises. Talværdier er opgivet i det decimale talsystem, medmindre andet er angivet. Hexadecimale tal er angivet ved at de begynder med enten et dollartegn eller 0x. Binære tal angives ved at de begyndes med en %-tegn, f.eks. %101. Ben-identifikationer der ender på et *, eller har en streg over forkortelsen, er inverterede. Det vil sige at de er aktivt lave og at et binært 0 dermed repræsenteres ved en elektrisk høj spænding. Ved ben, der er aktivt lave, benyttes udtrykket asserteret ved et binært 1 og udtrykket negeret ved et binært 0, for at undgå misforståelser. Ved omtale af funktionsnavne fra programmer, skrives de med denne font. 24

29 4.2. M68K SPECIFIKATIONER 4.2 M68k specifikationer Til projektet er udleveret en microprocessor, en Motorola 68HC000 (M68k). Denne processor stiller en række krav til perifære enheder, samt til softwaren den skal afvikle. I dette afsnit redegøres for processorens grænseflader til den eksterne hardware samt krav til softwaren. Desuden redegøres for processorens timing i forbindelse med læse- og skriveoperationer. Hele gennemgangen tager udgangspunkt i (Clements 1997) Arkitektur I dette afsnit beskrives M68k-arkitekturen, altså data- og adressebus, interne registre og interrupts. Formålet med denne beskrivelse er, at bidrage til en forståelse af processorens virkemåde, hvilket er nødvendigt i forbindelse med hardwarenær programmering. Processoren har en 23 bit adressebus, dvs. at der er 23 ben på processoren til at adressere ekstern hardware. Endvidere har den en 16 bit databus til at kommunikere med den eksterne hardware. Adressebus Adressebussen bruges til at adressere eksterne enheder såsom hukommelse og input / output (I/O) hardware. Bussen er 23 bit bred, hvilket vil sige at den kan adressere bit words. Det resulterer i, at der i alt kan adresseres 16 MB. Adressebussen drives af tri-state output, hvilket betyder at indgangsimpedansen kan stige til uendelig, hvorved andre enheder kan kontrollere bussen. Dette er relevant i forbindelse med enheder, der tilgår hukommelsen direkte, hvilket ikke finder sted i dette system, hvorfor det ikke beskrives nærmere. Adressebussens tre første ben, A0 til A2, bruges endvidere, i forbindelse med vektoriseret og autovektoriseret, til at bekræfte et interrupt. Dette kaldes Interrupt Acknowledge, IACK. Når dette finder sted, asserteres processorens tre Function Code ben, FC0-FC2. Databus Databussen bruges til at kommunikere med de eksterne enheder, der adresseres af adressebussen. Databussen består af benene D0-D15, dvs. den er 16 bit bred. Den er bidirektionel, hvilket vil sige at processoren både kan læse og skrive på bussen, afhængigt af læse-/skrivebenet, R/W*. Når processoren udfører en operation på et word, der udgør 16 bit, er alle databen i brug. Når der arbejdes på bytes (8 bit), er det enten de første eller sidste 8 ben, der er i brug, afhængigt af UDS* (Upper Data Strobe)- og LDS* (Lower Data Strobe)-benene. Databussens ben kan, i lighed med adressebussens, tri-states, så eksterne enheder kan bruge busssen uafhængigt af processoren. 25

30 KAPITEL 4. DESIGNFORUDSÆTNINGER Interne registre Processoren har 8 dataregistre, D0-D7 og 8 adresseregistre A0-A7, hvor A7 er stackpointeren. Da processoren internt er organiseret som en 32 bit maskine, er hvert register på 32 bit. Endvidere har processoren to special registre. Det ene indholder, program counteren (PC) der indeholder data om hvor i programkoden der arbejdes. Det andet er et statusregister, der indeholder en status byte og et Condition Code register (CCR) på 8 bytes. Status byten bruges bl.a. til at maskere interrupts ud, dvs. filtrere de interrupts fra, der ikke skal reageres på. CCR fortæller om status på en udregning, f.eks. om der er sket et overflow. Interrupts Processoren understøtter to typer interrupthåndtering, vektoriseret og autovektoriseret. Hvor den vektoriserede kræver at de eksterne enheder, efter et interrupt, tilkendegiver sig på databussen, kræver den autovektoriserede intet af dem. Da enhederne der skal benyttes, ikke forventes at være i stand til at tilkendegive sig på databussen, benyttes autovektoriseret interrupt. Hvordan denne realiseres, kan der læses mere om i afsnit 6.5 på side 47. M68k har 8 niveauer af interrupts, hvoraf det ene indikerer, at der ikke er en aktuel interrupt. Seks andre, IRQ1-IRQ6 kan tildeles forskellige enheder, der har behov for at udstede interrupts. Den sidste, IRQ7, er den såkaldte non-maskable interrupt. Denne interrupt kan, som navnet antyder, ikke maskeres ud i processorens status-register. Det vil med andre ord sige at processoren, selvom dens afvikling af programkode er stoppet, kan bringes til at køre et stykke programkode. Dette er nyttigt i forbindelse med debugging af software, hvor fejl i softwaren kan stoppe programafviklingen uden ellers at give mulighed for at finde fejlen Ekstern hardwaregrænseflade Udover data- og adressebussen, er der en mængde forbindelser, hvis formål bl.a. er at forsyne processoren med en clockfrekvens. I det følgende vil forbindelserne i tabel 4.1 på modstående side blive gennemgået, evt. med referencer til steder de behandles i rapporten. Strømforsyningen V cc skal være 5 V over stel, hvilket beskrives nærmere i afsnit på side 22. Clock-benet skal forsynes med en clockfrekvens, der genereres af en oscillator som beskrives kort i 6.2. Reset-benet benyttes bl.a. til at nulstille processoren. Kredsløbet omkring denne beskrives nærmere i afsnit 6.1 på side 39, hvor Halt-benet også er omtalt. Address Strobe bruges til at fortælle eksterne enheder, at der er en gyldig adresse på adressebussen, mens Read/Write-benet bruges til at vælge om der skal læses eller skrives til en enhed på databussen. Upper og Lower Data Strobe bruges til at fortælle om det er lige og/eller ulige adresser, der adresseres på bussen. Data Transfer Acknowledge bruges, ved asynkron dataoverførsel, af ekstern hardware, til at fortælle når data er klar på bussen. Bus Error-benet kan benyttes til at fortsætte efter fejl i hukommelsessystemet, men da dette ikke er nødvendigt, benyttes benet ikke i dette system. 26

31 4.2. M68K SPECIFIKATIONER Signal benævnelse Forkortelse Input/Output Strømforsyning V cc Stel GND Clock CLK I Reset RESET* I/O Halt HALT* I/O Adressebus A 01 A 23 I/O Databus D 00 D 15 Adress strobe AS* O Read/Write R/W* O Upper data strobe UDS* O Lower data strobe LDS* O Data transfer acknowledge DTACK* I Bus error BERR* I Enable E O Valid memory address VMA* O Valid peripheral address VPA* I Bus request BR* I Bus grant BG* O Bus grant acknowledge BGACK* O Function code FC0, FC1, FC2 O Interrupt priority level IPL0*, IPL1*, IPL2* I Tabel 4.1: Benævnelser for M68k s benforbindelser Benene beskrevet fremefter, benyttes i forbindelse med synkron kommunikation på databussen. Når adressedekoderen registrerer at en synkron, perifær enhed adresseres, asserterer den Valid Peripheral Address, for at anmode om en synkron bus. Når processoren er klar, asserterer den Valid Memory Address. Processoren udsender, til brug ved asynkron bus, en clock med en frekvens lig systemclocken (8 MHz) delt med 10 på Enable-benet. Følgende ben benyttes når der er flere enheder, der kan tage kontrol over databussen: Bus Request, Bus Grant og Bus Grant Acknowledge. De anvendes dog ikke, da det kun er processoren der styrer adressebussen i dette projekt. De tre Function Code ben benyttes til at aflæse hvilken tilstand processoren er i. De kan f.eks. vise om processoren er i Supervisor- eller User-mode og er igang med hhv. Data- eller Program-aktivitet. De to modes er kun relevante, hvis processoren kører et operativsystem, hvor aktivitetsangivelsen kan benyttes til at dele hukommelsesområdet op. Endvidere benyttes Function Code-benene til at indikere en Interrupt Acknowledge som benyttes i forbindelse med vektoriseret og autovektoriseret interrupt, hvor processoren benytter benene til at bekræfte en Interrupt Request. Interrupthåndteringen omtales nærmere i afsnit 6.5 på side 47. De tre Interrupt Priority Level ben benyttes af perifære enheder, til at anmode om et interrupt, altså til at sende Interrupt Request til. Der skal tilsluttes et interrupt encoder, der kan omregne de 8 interrupt-niveauer til en tre bit binær værdi der kan sendes ind på IPL*-benene. 27

32 KAPITEL 4. DESIGNFORUDSÆTNINGER Softwarekrav og begrænsninger Da systemet ikke udstyres med en floating point enhed (FPU) eller emulering af en sådan, kan der kun foretages heltalsberegninger i systemet. Der kan arbejdes med talværdier på op til 32 bit, dvs Når der skrives talværdier på databussen, som er større end end én byte, 2 8, skal de anbringes på lige adresser, for at kunne læse eller skrive data i en readeller write-cycle Timing ved asynkron overførsel på databussen Instruktioner udføres inden for bus-cycles. En bus-cycle er inddelt i 4 clock-cycles eller 8 states. Timingen vil blive forklaret ud fra disse 8 states, da det kun er inden for disse states at processoren ændrer udgangsniveauer. States bliver benævnt som S0-S7 og vil blive forklaret for henholdsvis en read cycle og en write cycle. Kilden der tages udgangspunkt i, er i dette afsnit (Clements 1997) s Read cycle Signalerne der anvendes i en read cycle er A1-A23 (Adressebus), D0-D15 (Databus), AS*, UDS*, LDS*, R/W* og DTACK*. S0: I S0 negeres alle signaler og adresse- og databusbenene gøres højimpedante. S1: Inden for S1 asserteres adressebussen og ved udgangen af S1 er adressen stabil. S2: Eftersom adressen er stabil asserteres AS*, for derved at indikere overfor perifære enheder at adressebussen indeholder en gyldig adresse. UDS* og LDS* asserteres også i S2. I enkelte tilfælde bliver AS* dog først asserteret i S3. S3: Signaler bliver ikke ændret i denne state. I enkelte tilfælde, som omtalt i S2, asserteres AS* først i S3. S4: I S4 undersøger processoren om DTACK* er blevet asserteret. Bliver denne ikke asserteret minimum 20 ns før den nedadgående flanke i S4, indsættes der wait states. Indtræffer DTACK* aldrig vil processoren, teoretisk set, vente evigt på dette signal. S5: I S5 ændres der ikke på signaler, men databussens indhold er gyldigt. S6: I S6 læses databussen og indholdet latches internt. S7: AS*, UDS* og LDS* negeres, ligesom benene til databussen gøres højimpedante. Processoren anvender DTACK* til at sikre at databussens indhold er gyldigt. DTACK* kan dog undværes, hvis den perifære enhed kan latche de data, som processoren placerer på bussen, før S6 er afsluttet. Dermed spares logik til at generere eller videreføre DTACK*. Gennem brug af timing-diagrammet for en read cycle, kan den tilladte adgangstid findes. En read-cycle er tre clock-cycles lang. I løbet af denne tid, skal processoren 28

33 4.2. M68K SPECIFIKATIONER sætte adressebussen op (t gyldig adresse ), den perifære enhed skal sætte data op på databussen (t opsaet l ) og processoren skal læse disse (t laes ). Adgangstiden, dvs. den tid der går fra adressebussen er klar, til data er gyldige, kan dermed beregnes som følger: 3 t cycle > t gyldig adresse +t opsaet l +t laes (4.1) t opsaet l < 3 t cycle t gyldig adresse t laes (4.2) Når t cycle, t gyldig adresse og t laes kendes (fra (Clements 1997)[s. 232]), kan den maksimale t opsaet l beregnes: t opsaet l < ns 70 ns 15 ns (4.3) t opsaet l < 290 ns (4.4) Det skal dog bemærkes at denne tid er for hukommelseskredse, der er tilsluttet hele adressebussen. Perifære enheder, der først aktiveres når CS* asserteres, har en mindre tilladt adgangstid. CS* asserteres efter at AS* er blevet asserteret i S2, men adressen er stabil allerede i S1, hvilket giver den reducerede adgangstid. Den reducerede adgangstid (t opsaet l red ) bestemmes som tiden fra AS* asserteres til tidspunktet hvor data skal være gyldige. Derfor skal tiden mellem adressebussen er gyldig og AS* er asserteret, trækkes fra t opsaet l. Denne tid, t as set, kan i (Motorola 1993)[s.10-10], aflæses til 30 ns, hvorved t opsaet l red kan udregnes til: t opsaet l red < t opsaet l t as set (4.5) t opsaet l red < 290 ns 30 ns = 260 ns (4.6) t opsaet l red < 260 ns (4.7) Overskrides disse tider, skal DTACK* anvendes for at sikre at den perifære enhed har asserteret databussen korrekt. Write cycle Forskellen mellem read og write cycle er sekvensen, der finder sted i S3. S0: I S0 negeres alle signalet, mens adresse- og databus sættes til at være højimpedante. S1: Inden for S1 asserteres adressebussen og ved udgangen af S1 er adressen stabil. S2: Eftersom adressen er stabil asserteres AS*, for at indikere overfor perifære enheder, at adressenbussen indeholder en gyldig adresse. S3: Databussen asserteres og UDS* og/eller LDS* asserteres umiddelbart efter, for at øvre og/eller nedre byte og indikere, at databussens indhold er gyldigt. S4: Processoren undersøger om DTACK* er blevet asserteret. Bliver denne ikke asserteret minimum 20 ns før den nedadgående flanke i S4, indsættes der wait states. Indtræffer DTACK* aldrig, vil processoren, teoretisk set, vente evigt på dette signal. UDS* og LDS* asserteres også i S4. 29

34 KAPITEL 4. DESIGNFORUDSÆTNINGER S5: I S5 ændres der ikke på signaler, men databussens indhold er gyldigt. S6: I S6 læses databussen og indholdet latches internt. S7: AS*, UDS* og LDS* negeres, mens databus-benene gøres højimpedante Igen kan DTACK* udelades, hvis den perifære enhed har en tilstrækkelig lav adgangstid. For en hukommelseskreds udgøres dette tidsrum af tiden fra adressen er gyldig i S1 til CS* negeres i S7. Denne tid, t opsaet s, bestemmes som tiden, der går fra adressen er gyldig, til AS* asserteres, t as set, plus den tid AS* er asserteret, t as. Det er i (Motorola 1993)[s ] t as set og t as t opsaet s < t as set +t as (4.8) t opsaet s < 30 ns ns = 300 ns (4.9) Tiden t opsaet s er den tid, kredsen har til at adressere sin adresse, samt skrive indholdet af databussen til denne dertil. Aktiveres den perifære kreds først ved assertering af CS*, bliver den maksimale skrivetid væsentligt nedsat, da UDS* og LDS* først asserteres i S4. Dette må nødvendigvis være tidsrummet hvor CS* er lav, hvilket er det samme som tidsrummet, hvor UDS* og LDS* er asserteret. Ud fra (Motorola 1993)[s.10-10], kan dette tidsrum aflæses til: t opsaet s red < 140ns Enheder der kobles til processorens adresse- og databus skal derfor, som minimum, overholde ovenstående tider. I tiderne er der dog ikke indregnet nogen form for margin til adressedekodning. I afsnit omhandlende perifære enheder, vurderes det om marginen er stor nok til at DTACK* kan udelades. 4.3 Debugger/monitor-systemet TS2MON Debugger/monitor-systemet TS2MON anvendes for at muliggøre fejlsøgning på og overvågning af mikrocomputersystemet Anvendelse TS2MON-systemet giver mulighed for at lægge ny programkode ind på mikroprocessorsystemet via en RS232 fra en PC. Endvidere giver det en lang række debugging-værktøjer, der omtales nærmere i (Nielsen 2001). Debugging-værktøjerne betjenes via et RS232- terminalprogram på en PC, hvorfra programkoden også sendes. TS2MON kan køre to hovedtilstande, Debugger/Monitor (D/M) tilstand eller Execute tilstand. I D/M tilstand kan der kommunikeres med TS2MON fra en PC, hvilket vil sige at det er her debugging mv. finder sted. Der kan sendes og køres programkode, der kan indsættes breakpoints, altså afbrydelsespunkter, i det, ligesom indhold af registre og dataområder kan udlæses. I Execute tilstand køres det indlagte brugerprogram i realtid, indtil 30

35 4.3. DEBUGGER/MONITOR-SYSTEMET TS2MON det enten når et indsat breakpoint eller NMI-knappen, der bringer systemet i D/M tilstand, aktiveres. Når det sker, foregår det uden at brugerprogrammet ser D/M-systemet, medmindre der aktivt gøres noget for at ændre på registrene, mens systemet er i D/M tilstand. Dog skal man være opmærksom på at interrupts og indgående data, f.eks. fra en RS232-enhed, ikke modtages af brugerprogrammet, da TS2MON udmaskerer IRQ Interrupt-vektorer Normalt starter M68k s vektor-tabel ved $8, men når TS2MON-systemet anvendes ligger denne adresse i Flash EEPROM en, hvilket gør det besværligt at ændre vektorerne. Derfor flytter TS2MON-systemet vektorerne til et andet hukommelsesområde, som er lettere tilgængeligt. Vektorernes nye adresser bliver dermed som følger: vektornummer 8 bytes + $40000 (4.10) Hvor der normalt blot skal stå en adresse i vektortabellen, skal der istedet stå en kodelinje i ovennævnte, nye adresse, der fortæller processoren at den skal springe videre til en given adresse på en interruptrutine. Det vil sige, at der på ovenstående adresser f.eks. kan stå en kodelinje som JMP sekhaand, der får processoren til at springe til funktionen sekhaand Minimumssystem For at kunne afvikle TS2MON er opstillet følgende krav fra programudviklerens side til et minimumssystem (Kilde: (Krav til M68000 system 2004)): Motorola 68HC000 mikroprocessor EPROM eller Flash-RAM til TS2MON Debugger/Monitor 2*128kbit*8 (adr: $0- $1200) D/M-RAM til TS2MON user-ram ($40000-$40FFF) User-ram til brugerens eget program og data M6850 ACIA (UART) til seriel kommunikation med PC (memory mappes på adresserne $ og $800003, Baudrate: 9600 baud) RS232 forbindelse inklusiv RS232 drivere Adressedekoder til memory, I/O og M6850 Reset-knap NMI-knap til generering af interrupt 7 for at starte TS2MON Interrupt-dekoder Minimumsystemet er i sig selv ikke nok til at realisere klimaovervågningssystemet. Derfor er der i det endelige system tilføjet yderligere hardware, hvilket gennemgås i afsnit

36 KAPITEL 4. DESIGNFORUDSÆTNINGER 4.4 Kompilering/simulerings systemet IDE68k Programmet IDE68k benyttes til at kompilere og simulere C- og Assemblerkode til et M68k-system. Værktøjet indeholder en oversætter, der genererer assemblerkode ud af C- kode. Dette kompileres derefter sammen med den kode, der er skrevet i assembler til et program, der kan loades op på M68k systemet. Ved at sætte oversætteren til at generere listfiler 1 over den kode, der oversættes og kompileres, er det muligt at simulere hver enkelt linie af den genererede/skrevne Assemblerkode. Dette gøres i programmets visuelle simulator, der indeholder et kort over systemets hukommelsesområde, samt programcounter, adresse-, data- og statusregistre. Ved at single steppe gennem programmet, kan det nu ses hvordan der arbejdes i hukommelsen og processorens interne registre. For at kunne bruge den kompilerede programkode i et M68k-system med Debugger / monitoren TS2MON, er det nødvendigt at ændre i de forudsætninger kompileren benytter til generering af programkoden. Når et projekt skal kompileres inkluderes et sæt standardfiler som indeholder opsætning af programmet og funktionsbiblioteker til standard C-rutiner. Opsætningsfilen bestemmer som standard at hukommelsesområdet hvor programmet, der skal afvikles, bliver lagt, starter i adresse $400. På et system med TS2MON er det, som nævnt i afsnit 4.3 på side 30, bestemt, at RAM området, hvor systemets program skal være, skal ligge på adresserne over $ Udover at ændre den laveste adresse for placering af programmet, er det også nødvendigt at placere interruptinstruktionerne i opsætningsfilen, da disse skal skrives ned i TS2MON Ram-område fra $ $40FFF, dvs. før området for systemsoftwaren. Filen med funktionsbiblioteker, sætter C-oversætteren i stand til at fortolke standard C- rutiner og arbejde med strenge. Derudover skal funktionsprototyper til det specifikke system udføres af programudvikleren. Disse begrænsninger i C-oversætteren resulterer i, at der ikke foretages nogen optimering af den assemblerkode, oversætteren genererer. Derfor bør tidskritiske funktioner skrives direkte i Assembler. 4.5 Testcompiler - GCC Til at teste funktioner og moduler inden de implementeres i systemet, vil GCC (GNU Compiler Collection) i flere tilfælde blive benyttet. Dette vil især gøre sig gældende i moduler som skal sende data til brugeren af systemet, det vil sige formaterede tekststrenge. Ved hjælp af GCC s print-funktioner kan disse karakterer skrives ud til en PC-skærm og input kan tages fra tastaturet på den PC, der testes på. Desuden bruges GCC til at lave testprogrammer, der gennemgår behandlingen af hele dataområder, og tester at resultaterne i alle tilfælde er korrekte. 1 listfiler indeholder den assemblerkode, oversætteren genererer, når C-koden oversættes. 32

37 4.6. DESIGNMETODER 4.6 Designmetoder Designet af systemet tager udgangspunkt i at få identificeret de funktioner, der skal implementeres i systemet. Funktionaliteterne inddeles i moduler, som kan designes hver for sig, med klart definerede grænseflader og krav til funktionalitet. For hvert modul foretages endnu en nedbrydning i mindre dele, som umiddelbart kan realiseres som en hardwarekomponent eller en softwarefunktion. På figur 4.1 ses princippet for den trinvise nedbrydning af hardware og software. / ul ul funktion funktion funktion funktion Figur 4.1: Princippet for nedbrydningen af hardware og software For hvert modul, der nedbrydes i, foretages desuden test for at sikre modulets funktion i det samlede system. Desuden foretages implementationsovervejelser, således at moduler, der afhænger af andre, ikke implementeres før deres afhængigheder kan tilfredsstilles i systemet. På denne måde opnåes et udviklingsmodel, der ifølge (Stephen Biering-Sørensen & Madsen 2000) side 37 kaldes V-modellen. 33

38 Del III Hardware 34

39 Kapitel 5 Strukturdesign På baggrund af kravspecifikationen om systemets funktionaliteter og de forudsætninger, der blev beskrevet i foregående kapitel, kan opstilles et blokdiagram over systemet funktioner. Dette ses på figur 5.1. Tempsensor Fugtsensor Taster PC-Link Microprocessorsystem Display Ur Lager til målinger Figur 5.1: Blokdiagram Der tages udgangspunkt i et mikroprocessorsystem, baseret på en Motorola 68000, med et Debugger/monitor-system integreret. Debugger/monitoren stiller, som nævnt i afsnit på side 31, nogle krav til det system, det skal afvikles på. På baggrund af disse krav opbygges et minimumsystem, som derefter udbygges til at opfylde klimaovervågningssystemets funktioner. For at opfylde Debugger/monitorens krav til et minimumsystem og i øvrigt opnå et funktionelt system skal følgende hardwareenheder designes: 35

40 KAPITEL 5. STRUKTURDESIGN Power-on reset kredsløb: For at kunne starte og genstarte systemet er det nødvendigt at designe et kredsløb, der kan styre processorens RESET*- og HALT*-ben. Clockgenerator: Mikroprocessorsystemet skal bruge en clock for at kunne udføre instruktioner. Hukommelse: Systemet har brug for hukommelse hvor programmet, der skal afvikles, kan ligge, og hvor processoren kan placere og hente de variabler, der arbejdes med. Adressedekodning: Da alle moduler tilsluttes processorens data og adressebus, skal der bruges et system, som kan sørge for, at der kun kommunikeres med den/de ønskede enheder. NMI (Non Maskable Interrupt): Debugger/monitoren implementerer en funktion, der stopper programafviklingen, når autovektorinterruptet med højest prioritet aktiveres. Derfor skal der designes et kredsløb, som kan aktivere dette interrupt. RS-232 forbindelse: For at kunne styre Debugger/monitoren og indlæse programmer på systemet, stilles der krav om en RS-232 forbindelse. Da systemet også skal bruge en PC-forbindelse til en fjernbruger, skal der implementeres to RS-232 forbindelser, som behandles samlet i forbindelse med den øvrige hardware. 5.1 Hardware udover minimumsystemet For at kunne realisere klimaovervågningssystemet, er det tilføjet en række moduler til minimumsystemet. Det drejer sig om: I 2 C-bus, der kommunikerer med temperatur- og fugtighedssensorer, samt statisk lager: Da et af kravene til systemet er, at det skal være let at udvide med ekstra sensorer, vil det ikke være hensigtsmæssigt at denne kommunikation foregår vha. M68k s parallelle databus. Skal systemet udvides skal adresse-dekoderen samt software re-designes for at nye sensorer kan adresseres og aflæses. Dette problem løses ved at vælge en I 2 C-bus til formålet. Grunden til at en I 2 C kan løse problemet er at sættes de nye sensorer i stedet på en I 2 C-bus er det blot softwaren der skal re-designes. På I 2 C-bussen placeres også blivende hukommelse, der kan gemme måledata mens systemet er slukket. I/O controller med inputknapper og alarmudgang: Der skal realiseres 4 knapper ([<], [>], [enter] og [esc]) og én alarmudgang, der kan styre en ekstern alarmgiver. RS-232 forbindelse til PC fjernbruger: Minimumsystemet råder i forvejen over en RS-232 forbindelse til TS2MON og kunne i princippet også anvendes til PC fjernbruger. For at der ikke skal opstå konflikt, tilføjes en ekstra RS-232 forbindelse. De to RS-232 forbindelser behandles samlet, da de konstruktionsmæssigt er ens. Display: For at kunne udlæse måledata, indstillinger, og alarmlog på selve systemet implementeres et display. 36

41 MODULINTEGRATION Ur: Det er stillet som krav at målinger skal tidsstemples. Derfor skal systemet råde over et ur. På figur 5.2 er der vist et blokdiagram over klimaovervågningssystemet. "#"$ 8 + indst. ( " - udgang ) D C6 B A@ ) " 8 m å ler r -? & tigheds - m å ler ck esse dning I/O - I2C - M US '*)+-,/./0 upt dning % /E er On : et! "#"$ % '& (" A D/M PC A : <=; : -; NMI 78 9 er Ur PC > ugger ; Figur 5.2: Blokdiagram over hardwaren inddelt i moduler I det følgende vil hardwaren til systemet blive gennemgået modulvis. For hvert modul opstilles krav, der foretages den nødvendige analyse for at kunne vælge hardwarekomponenter, og der laves et el-diagram og en beskrivelse af implementationen af hvert modul. 5.2 Modulintegration Efter at have identificeret de nødvendige hardwaremoduler til systemet, skal integrationen af disse fastlægges. Da det i forbindelse med fejlsøgning er uhensigtsmæssigt at integrere hele systemet på en gang, opbygges systemet et modul ad gangen i en rækkefølge, der sikrer, at det modul, der integreres, ikke er afhængigt af et endnu ikke integreret modul. Den første del af systemet, der skal opbygges, er det nævnte minimumssystem. Med dette bliver der mulighed for at lægge programmer over på systemet og afvikle disse ved hjælp af TS2MON-systemet. Herefter kan de systemspecifikke moduler bygges på. Som udgangspunkt er der ingen moduler, som kræver, at et andet er implementeret, for at fungere. 37

42 KAPITEL 5. STRUKTURDESIGN Af hensyn til den software, der skal benyttes på systemet og de debuggingmuligheder, som enkelte moduler resulterer i, er følgende implementeringsrækkefølge valgt: 1. Display: Displayet giver mulighed for at udskrive debuggerinformationer fra det program der kører på systemet. Derfor implementeres dette modul først. 2. I/O - taster og alarmudgang: I/O-enhederne implementeres efter displayet da disse giver mulighed for at teste mulighederne for at fortolke input og generere output til og fra systemet. 3. I 2 C - sensorer og blivende hukommelse: I 2 C-komponenterne integreres herefter, for at få mulighed for at tage målinger og lagre disse. 4. Ur: Som det første modul efter sensorerne er implementeret, bygges sekundgeneratoren til uret på systemet. Dette giver mulighed for at foretage og lagre målinger med faste intervaller. 5. RS232 - PC-forbindelse: PC-forbindelsen implementeres sidst, da denne bruges til udlæsning af data, som kun findes, når resten af systemet er funktionelt. I det følgende moduldesign designes modulerne i samme rækkefølge, som implementeringen vil finde sted. Dermed kan hvert modul testes og implementeres i umiddelbar forlængelse af designet. 38

43 Kapitel 6 Moduldesign af minimumsystem Som nævnt i afsnittene om designforudsætninger og strukturdesign, tager designet af hardware udgangspunkt i et minimumsystem. I dette kapitel designes de hardwareenheder, der blev identificeret som nødvendige for at realisere dette minimumsystem. For at sikre systemets funktion, inden de systemspecifikke hardwareenheder designes, gennemføres et sæt tests på de enkelte moduler og på minimumsystemet som en helhed. 6.1 Power-on resetkredsløb I dette afsnit vil systemets power-on resetkredsløb blive beskrevet. Grunden til at der implementeres et power-on resetkredsløb er at processoren kræver at RESET* og HALT* benene asserteres i mindst 100 ms ved opstart af processoren. Det skyldes at der skal være tid til at, M68k erens interne biaskredsløb kan komme op på de nødvendige spændingsniveauer. Til at implementere power-on reserkredsløbet er valgt en TL7705 fordi den med få eksterne komponenter kan løse opgaven. På figur 6.1 se hvorledes TL7705 eren skal kobles op. De to modstande er pullup-modstande. Da RESET* og HALT* både kan være ind- og udgange er det nødvendigt med de to dioder så de to ben ikke kan påvirke hinanden. De dioder, der er valgt er schottky dioder af typen BAT85. Kontakten er brugt da det ønskes at kunne resette systemet uden at skulle fjerne forsyningsspændingen. Kondensatoren på 0, 1 µf bruges for at undgå påvirkning af transienter fra strømforsyningen. Fra databladet for TL7705 er det givet et sammenhæng mellem C 1 og t d som er følgende: t d = 1, C 1 (6.1) Fra (Clements 1997) side 206 er det givet at t d minimum skal være på 100 ms ved opstart. Det medføre at C 1 min kan udregnes på følgende måde. C 1min = t dmin 1, (6.2) C 1min = 100ms = 7,7 µf (6.3) 1,

44 KAPITEL 6. MODULDESIGN AF MINIMUMSYSTEM 5V 5V 5V R8 10k 0 SW 5 RESET 0 C1 10u C2 5V 100n 0 U12 2 RESIN 3 1 CT REF 7 SEN TL7705A RST RST 6 5 D1 BAT85 D2 BAT85 R6 1k R7 1k RESET* HALT* 6.2 Clock-generator Figur 6.1: Power-on resetkredsløb Processoren skal bruge et clocksignal til at kontrollere sin interne timing. I følge (Clements 1997) side 225 er grænserne for periodetiden, for en 8-MHz clock til M68k, på 125 ns for den nedre grænse og 250 ns for den øvre grænse. Hvis processoren ikke får et regelmæssigt clocksignal vil processorens interne data gå tabt og det vil ikke være muligt at forudse processorens videre funktion. Til at generere clocksignal til processoren anvendes en MCO1415B, som opfylder de krav som processoren har til clocksignalet. Krystaloscillatoren MCO1415B har fire ben som er nummereret 1, 7, 8 og 14. Ben 14 kobles til forsyningen. Ben 7 kobles til stel. Ben 8 kobles til ben 15 på processoren. Ben 1 er ikke i brug. 6.3 Hukommelse Typer af hukommelse Til et mikroprocessorsystem skal der typisk bruges to forskellige overordnede typer af hukommelse. Der kræves en blivende hukommelse hvor processoren kan læse det program, der skal eksekveres når strømmen tilsluttes. Denne hukommelse skal der ikke kunne skrives til, hvorforfor den benævnes Read Only Memory, herefter ROM. Desuden skal der bruges hukommelse til at gemme midlertidige variabler, mens programmet kører. Dette kaldes Random Access Memory, herefter RAM. Både RAM og ROM hukommelse findes med flere forskellige teknologier. I afsnittene herefter, vil nogle af de vigtigste blive forklaret. Disse forklaringer stammer fra siderne i (Clements 2000). SRAM SRAM står for Statisk-RAM. Det dækker over at den enkelte hukommelsescelle husker den værdi der er gemt i den, så længe der er spænding på kredsløbet. I princippet kan hver enkelt celle opbygges som en flip-flop. DRAM DRAM står for Dynamisk-RAM. I modsætning til statisk RAM husker denne type hukommelse ikke uden videre på de data, der bliver gemt i den. Princippet i lagringen er en kondensator, der enten lades op til en spænding, eller aflades. Denne ladning vil dog aftage med tiden. Derfor skal DRAM genopfriskes hele tiden, for at sikre at dataene 40

45 6.3. HUKOMMELSE huskes. Dette synes umiddelbart at være en ulempe, men DRAM muliggør en højere hukommelsestæthed, da der skal bruges færre transistorer pr. hukommelsescelle. PROM PROM står for Programmable-ROM. Det vil sige at hukommelsen kan programmeres én gang, hvorefter disse data vil være brændt fast i kredsen. Denne brænding foregår i princippet ved at kredsen indeholder en række sikringer, som brændes over i et mønster, som repræsenterer de data, der skal brændes. EPROM EPROM står for Erasable-PROM. I modsætning til en PROM kan en EPROM slettes, hvorefter der kan brændes nye data i den. Denne sletning foregår ved at belyse kredsen med UV-lys. Det er altså kun muligt at slette hele kredsen, det kan ikke lade sig gøre at overskrive enkelte bytes. Selve lagringen af data foregår ved at en leder, som er isoleret fra omgivelserne, tilføres en ladning under programmeringen. Denne leder fungerer som gate i en FET transistor, men da gaten er isoleret er transistoren enten permanent åben eller permanent lukket, og den fungerer dermed som en hukommelsescelle. Ladningen kan fjernes fra gaten igen ved at belyse kredsen med UV-lys. Flash EPROM I en Flash EPROM kan dataene slettes elektrisk, det vil sige uden brug af UV-lys. Ligesom ved en almindelig EPROM kan det kun lade sig gøre at slette hele kredsen på én gang. I nogle tilfælde er kredsen delt op i sektorer, som kan slettes enkeltvis. Selve sletningen af data tager lang tid (Op til et sekund i nogle tilfælde), men til gengæld går det hurtigt (under 100 µs) at skrive nye data. EEPROM EEPROM står for Electrically-Erasable-PROM. Den har den store fordel, frem for Flash, at bytes kan slettes enkeltvis. Det er altså muligt at overskrive en enkelt byte med en anden. Dette giver dog den ulempe at skrivning altid tager lang tid (nogle ms) fordi de gamle data skal slettes først. Valg af hukommelse I dette projekt er der som nævnt behov for flere forskellige typer af hukommelse. Der kræves noget hukommelse til at lagre selve programkoden, og noget til at lagre midlertidige variable under eksekveringen af koden. Derudover skal der være mulighed for at lagre de opsamlede måledata og konfigurationsindstillingerne. Sidstnævnte skal kunne huskes ved strømafbrydelse, hvorfor der kræves en type hukommelse, der ikke slettes ved strømafbrydelse. Samtidig skal det være muligt for systemet at skrive nye data mens det kører. Det er umiddelbart nærliggende at placere selve programkoden i en form for ROM-hukommelse, men da projektet er baseret på en udviklingsmodel, vil det program, som skal ligge i ROM, i stedet være debugger/monitor programmet TS2MON. Dette program stiller krav om en ganske bestemt størrelse af ROM-hukomelsen, og ligeledes hvilke adresser den skal ligge på. Selve programmet til klimaovervågningssystemet lægges i stedet i RAM-hukommelse, da det derved er nemmere løbende at ændre på programmet under fejlfinding. 41

46 KAPITEL 6. MODULDESIGN AF MINIMUMSYSTEM Krav i forbindelse med TS2MON ROM fra adresse 0 til $1200 RAM fra adresse $40000 til $40FFF Herudover kræves ram til brugerprogram og -data. Valg af ROM Til ROM hukommelse vælges Flash EPROM af typen AM29F010B, da denne kreds hører under de standardkomponenter, som er tilgængelige i laboratoriet. Desuden er den anbefalet til brug i forbindelse med TS2MON. Kredsen har en størrelse på 1 Mbit, arrangeret i 128 k words af 8 bits. Der anvendes to ens kredse, for at udnytte M68k s 16 bit databus, og dermed opnås en samlet ROM mængde på 256 kilobytes. Dette udfylder adresseområdet op til $40000 hvor RAM hukommelsen skal begynde ifølge kravene. Valg af RAM RAM hukommelsen skal indeholde både programmet til klimaovervågningssystemet, og alle de midlertidige data og variable der måtte være behov for at gemme under afviklingen af dette program. Desuden skal de første 4 kbytes bruges af TS2MON. Da det ved designtidspunktet ikke vides hvor meget programmet vil komme til at fylde vælges det at bruge 256 kbyte, hvilket forventes at være mere end der er brug for. Dette skyldes at det er forholdsvist kompliceret at skifte til en større RAM kreds når først systemet er designet, da det ændrer kraftigt på memorymap og adressedekodning. Desuden forventes det at størstedelen af programmet skal skrives i C, hvilket ikke nødvendigvis giver den mest kompakte kode. Til RAM vælges kredsen SRM20100LC som er tilgængelig i laboratoriet. Den er ligesom ROM hukommelsen organiseret i 128 k words af 8 bits, og der bruges ligeledes to ens kredse for at udnytte processorens 16 bit databus. Valg af hukommelse til måle- og konfigurationsdata Måle- og konfigurationsdata skal kunne huskes ved afbrydelse af forsyningsspændingen. Derfor kræves en form for ROM hukommelse. Da det også skal være muligt at skrive disse data imens systemet kører, kan det realiseres med enten Flash-EPROM eller EEPROM. Flash-EPROM har dog den ulempe at det kun er muligt at overskrive store blokke af data ad gangen, hvilket ikke er hensigtsmæssigt i forbindelse med lagring af hverken måleeller konfigurationsdata, da der her typisk vil være tale om at overskrive én måling eller indstilling ad gangen. EEPROM har den ulempe at det tager relativt lang tid at skrive en byte, men dette kan accepteres, da det eneste tidskrav i den forbindelse er at der skal kunne tages en måling hvert sekund. Hastigheden af EEPROM er mere end tilstrækkelig til at opnå dette. De EEPROM kredse der er tilgængelige i laboratoriet har alle serielt interface. Det vælges at bruge en kreds af typen 24LC256. Denne kreds har et serielt interface, som er kompatibelt med en I 2 C-bus. Den kan dermed ikke kommunikere direkte med M68k s databus, men da systemet i forvejen skal kommunikere med sensorerne gennem en I 2 C-bus er dette 42

47 6.3. HUKOMMELSE imidlertid ikke noget problem, da den fornødne hard-/software kan genbruges. Kredsen har plads til 256 kbit, det vil sige 32 kb. Der er stillet krav om at der skal være plads til 1000 målinger i hukommelsen, dette kan opnås såfremt hvert målesæt fylder mindre end 32 bytes. Derudover skal der være plads til konfigurationsdata. EEPROM kredsen og kommunikationen med den vil blive beskrevet nærmere i afsnit på side 70. Kontrolsignaler til hukommelse For at styre adgangen til hukommelsen kræves visse kontrolsignaler. Disse skal vælge hvorvidt der skal skrives til eller læses fra hukommelsen. På de valgte hukommelseskredse (AM29F010 og SRM20100) består disse signaler af indgangene WE* og OE*, som henholdsvist står for Write Enable og Output Enable. Disse kan ikke kobles direkte til M68k, idet den kun har et enkelt kontrolben til denne funktion, R/W*, som er højt i read-cycles og lavt i write-cycles. For at sikre at WE* og OE* ikke asserteres utilsigtet, hvilket f.eks. kunne resultere i at hukommelsesdata overskrives, skal det sikres at de kun asserteres når AS* er asserteret. Der kan opstilles følgende udtryk: OE = R AS WE = W AS Ifølge DeMorgans s regel fås den inverterede værdi af et udtryk ved at invertere alle variable i udtrykket og bytte om på AND og OR. Det vil sige at udtrykkene kan skrives om til: OE = R + AS WE = W + AS Det kan altså implementeres med to OR-gates og en inverter, forbundet som det ses på figur 6.2. AS* R/W * U7A HCT U8A 74HCT32 3 OE* 4 5 U8B 6 W E* 74HCT32 Figur 6.2: Generering af kontrolsignaler til hukommelse Da det ikke skal være muligt at ændre på indholdet af ROM hukommelsen mens systemet kører, forbindes dennes WE* ben til 5V for at sikre at de ikke asserteres. Da der benyttes Flash EPROM til ROM kan det godt lade sig gøre at overskrive dem, men dette er ikke ønskeligt her. 43

48 KAPITEL 6. MODULDESIGN AF MINIMUMSYSTEM Timing For at sikre at de valgte hukommelseskredse kan fungere sammen med M68k, skal det kontrolleres at de overholder de timingkrav, som stilles. Disse krav er beskrevet i afsnit på side 28, hvor der beregnes hvor lang tid hukommelseskredsene har til at reagere i henholdsvis read- og write-cycles. Databladet for ROM kredsen kan findes som ROM-AM29F010B.pdf på bilagscd en. Databladet for RAM kredsen SRM20100LC er ikke tilgængeligt i elektronisk format, men findes i komponentudleveringen B Læsning I afsnit på side 28 bestemmes at en hukommelseskreds, som aktiveres af et chipselect signal, som genereres ud fra UDS* og LDS*, i en read-cycle skal reagere inden for: t opsaet l red < 260 ns Access tiden for RAM kredsen SRM2100LC er 70 ns, og for ROM kredsen AM29F010B er den 90 ns. De opfylder dermed begge kravene og DTACK* kan derfor asserteres samtidig med AS*, så der undgås indsættelse af waitstates. Skrivning En hukommelseskreds, som aktiveres af et chipselect signal, der genereres ud fra UDS* og LDS*, skal i en write cycle være færdig med skrivningen inden: t opsaet s red < 140ns Når der skrives til RAM kredsen SRM2100LC kræves ifølge databladet mindst 60 ns, fra chipselect signalet, til skrivningen er færdig. Dette overholder dermed kravet. Da der ikke skal skrives til ROM er det ikke relevant at undersøge dennes timing under skrivning. 6.4 Adressedekodning For kun at skrive til og læse fra de rigtige kredse på de rigtige tidspunkter, skal der generes et chipselectsignal til hver kreds, når dennes adresseområde tilgås. Krav For at kunne opbygge et adressedekodningssystem er det nødvendigt at kende de adresser, hvor hver kreds tilgås. Derfor er der i tabel 6.1 på modstående side opstillet et memorymap, der viser i hvilke hukommelsesområder de perifære enheder skal findes. De hexadecimale tal på memorymappet omsættes til binære på M68k s 24 bit adressebus. Den mindst betydende bit findes ikke direkte på mikroprocessoren, men er repræsenteret 44

49 6.4. ADRESSEDEKODNING Komponent Adresse ROM $0 $3FFFF RAM $40000 $7FFFF ACIA_DM $ $ ACIA_PC $ $ I/O $ I 2 C $80000D + $80000F LCD $ $ Tabel 6.1: Memorymap ved LDS* og UDS*. Dermed kan følgende sandhedstabel opstilles for adresseområderne til hver perifære kreds, som vist i tabel 6.2. Komponent A22 A21 - A17 A16 - A3 A2 A1 A0 UDS* LDS* A18 A4 ROM_UP X X X X X 0 X ROM_LOW X X X X X X 0 RAM_UP X X X X X 0 X RAM_LOW X X X X X X 0 ACIA_DM X 1 0 ACIA_PC X 1 0 I/O I 2 C X X X LCD X = høj, 0 = lav, X = ligegyldig Tabel 6.2: Sandhedstabel for adresser Det ses af sandhedstabellen, at det kun er følgende ben, der er nødvendige for at opnå en entydig tilgang til de perifære kredse: LDS*, UDS*, A0, A1, A2, A3, A17 og A22. Desuden skal adressestroben (AS*) bruges, da denne asserteres, når der findes en gyldig adresse på processorens adressebus. AS* er dog ikke nødvendig for at generere et chip-select til hukommelseskredsene, da læse/skrive rutinen ikke startes før der er et AS* alligevel. For at kommunikere med de forholdsvis langsomme enheder; ACIA erne og displayet, skal der gøres brug af processorens mulighed for synkron kommunikation. Her gøres 1 brug af processorens E-clock, der er 10 af processorens clockfrekvens. For at aktivere denne skal adressedekoderen generere et VPA*-signal, hvorefter VMA* asserteres. Først her skal chipselect signalet asserteres til den perifære enhed. 45

50 KAPITEL 6. MODULDESIGN AF MINIMUMSYSTEM VPA* signalet skal også bruges i forbindelse med interruptrutinerne, se afsnit 6.5 på modstående side, til at gøre processoren opmærksom på at der skal bruges autovektorinterrupt. Dette gøres ved at generere et VPA*, når processoren asserterer IACK*. UDS* og LDS* udelades til at generere chipselect til I 2 C-controlleren. Dette gøres for hurtigere at generere chipselect til denne enhed i forbindelse med skrive rutiner. Konsekvensen bliver en yderligere spejling af I 2 C ens adresseområde, men da der ikke ligger andre enheder i det område spejlingen bliver i, er det ikke noget problem. Desuden skal chipselectet til displayet, i modsætning til alle andre perifære enheder, være ikke-inverteret og synkroniseret med E-clocken. Valg Til at realisere adressedekoderen vælges en PEEL-kreds, der kan programmeres til at udføre de ønskede logiske operationer til at generere chipselect, VPA* og E-clock. Da displayet kræver et chipselecet, der er AND et med E-clocken, bliver der brug for 11 indgange og 10 udgange. Derfor gøres brug af en PEEL22CV10, som har 12 indgange og 10 kombinerede ind/udgange. Denne kreds er standard i laboratoriet, og det er kun én indgang, som ikke benyttes. Databladet over kredsen findes på bilagscd en. Design PEEL-kredsen skal programmeres til at udføre de logiske operationer, der skal til at generere VPA* og chip-select. Dette gøres ved hjælp af programmeringsværktøjet Abel, som kan generere den kode, der kan brændes ned i PEEL en. Udgangspunktet for programmeringen er (Corporation 1990) kap I Abel s Equation-miljø indsættes ligninger, der beskriver hvornår udgangene skal asserteres. Dette gøres med udgangspunkt i tabel 6.2 på foregående side og kommer til at se således ud: equations!cs_ram_low =!LDS & A17 &!A22;!CS_RAM_UP =!UDS & A17 &!A22;!CS_ROM_LOW =!LDS &!A17 &!A22;!CS_ROM_UP =!UDS &!A17 &!A22;!CS_ACIA_DM = UDS &!LDS &!AS &!A1 &!A2 &!A3 &!A17 & A22 &!VMA;!CS_ACIA_PC = UDS &!LDS &!AS & A1 &!A2 &!A3 &!A17 & A22 &!VMA;!CS_IO = UDS &!LDS &!AS &!A1 & A2 &!A3 &!A17 & A22;!CS_I2C =!AS & A1 & A2 &!A3 &!A17 & A22; CS_LCD = UDS &!LDS &!AS &!A1 &!A2 & A3 &!A17 & A22 &!VMA & E;!VPA = (UDS &!LDS &!AS &!A1 &!A2 &!A3 &!A17 & A22) # (UDS &!LDS &!AS & A1 &!A2 &!A3 &!A17 & A22) # (UDS &!LDS &!AS &!A1 &!A2 & A3 &!A17 & A22) #!IACK; Kompilering af Abel-programmet resulterer i en.jed fil, som brændes ned i PEEL-kredsen. Herved dannes forbindelser i kredsen til at udføre de kodede logiske operationer. 46

51 6.5. INTERRUPTHÅNDTERING GND UDS* LDS* AS* A1 A2 A3 A17 A22 VMA* E GND CV Vcc CS_I2C* CS_IO* _PS* _DM* GND Figur 6.3: Benforbindelser på adressedekoder Implementering For at indbygge adressedekoderen i systemet er ind- og udgange blevet fordelt på PEEL ens ben, som vist på figur 6.3. De ikke benyttede indgange er som vist på figuren blevet trukket til GND. Dermed er der implementeret en adressedekoder i systemet, der genererer de nødvendige signaler til at mikroprocessoren kan vælge den/de perifære kredse, der skal kommunikeres med. 6.5 Interrupthåndtering Dette afsnit vil omhandle hvordan interrupthåndteringen, sekundgeneratoren og NMI 1 kan bringes til at fungere i systemet. Valg af håndteringstype Ved brug af vektoriserede interrupts er det nødvendigt at kredsen, der sender et interrupt request, kan identificere sig på databussen. Evnen til at identificere sig kræver et mere komplekst kredsløb, hvilket ikke er ønskeligt i dette system. I stedet kan anvendes autovektor-interrupts som eliminerer dette problem, der blev beskrevet nærmere i afsnit på side 26. For at realisere dette, skal de forskellige interrupts AND es med deres tilsvarende interrupt acknowledges, IACK*-signaler, og sendes ind på processorens VPA*-ben. Herved informeres processoren om at den skal bruge autovektoriserede interrupts. Der skal endvidere anbringes et antal programlinjer, der hvor TS2MON retter interruptvektorerne mod, hvilket beskrives nærmere i på side 31. Disse linjer fortæller processoren, hvad der skal ske ved de forskellige IRQ 2 -niveauer. 1 NMI: Non-Maskable Interrupt 2 IRQ: Interrupt ReQuest, anmodning om interrupt. 47

52 KAPITEL 6. MODULDESIGN AF MINIMUMSYSTEM Interrupt-prioritering og encoding En M68k har tre inputs til interruptkontrol, IPL0*, IPL1* og IPL2*. Dette giver mulighed for 8 interrupts, hvor interrupt 0 har laveste prioritet og betyder at der ikke forefindes nogle interrupts. For at gøre plads til 8 interrupts på processorens tre interruptkontrolben skal de 8 ben encodes til et 3-bit binært tal. Endvidere skal der ske en prioritering af de forskellige interrupts, så interrupt 0 prioriteres lavest og 7 højest. Interrupt 7 bliver dermed til en såkaldt Non-Maskable Interrupt (NMI), der betyder at processoren, uanset hvad den er midt i, afbrydes. Dette interrupt er velegnet til debugging-formål, da den giver mulighed for udlæsning af processorens registre, selv ved softwarefejl, der standser programafviklingen. Endvidere kræver TS2MON dette interrupt. Valg af interrupt-encoder Prioriteringen og encodingen kan foregå i IC er, kaldt 74HC148, som forbindes til de perifære enheders interruptben og M68k ens interruptkontrolinput. Et asserteret ben på indgangen repræsenteres ved en 3-bit binær talværdi på udgangen. Det er det asserterede ben som repræsenterer den højeste værdi på indgangen, der encodes på udgangen, resten ignoreres. Derved realiseres den ønskede prioritering. Tilslutning af interrupt-encoder *IRQ0 *IRQ1 *IRQ2 *IRQ3 *IRQ4 *IRQ5 *IRQ6 *IRQ I0 I1 I2 I3 I4 I5 I6 I7 EI EO GS 74HC148 A0 A1 A IPL0* IPL1* IPL2* Figur 6.4: Tilslutning af 74HC148 interrupt-encoderen Interrupt encoderen 74HC148 tilsluttes som vist på figur 6.4. I0* til I7* tilsluttes interruptbenene fra de eksterne enheder, nummeret angiver hvilket interrupt-nummer der er tale om. A0* til A2*-benene tilsluttes processorens interruptkontrolinput, IPL0* til IPL2*- benene, med de tilsvarende numre. Enable Input-benet, EI*, tilsluttes stel, så interrupts altid encodes. Interruptbekræftelse Nogle enheder skal, når de har afsendt et interrupt, bruge en bekræftelse fra processoren, en IACK* (Interrupt Acknowledge). Når en IACK* sendes, asserteres de tre functioncode (FC) ben, AS* asserteres og IACK*-nummeret signaleres med A01, A02 og A03 på processoren. Dette 3-bit tal skal dekodes til et signal på et af otte ben, hvilket kan gøres 48

53 6.6. NMI med en 74HC138. Den er forsynet med tre Enable-input ben, hvor G1 tilsluttes 5 V, G2A* tilsluttes AS* og G2B* tilsluttes et kredsløb der AND er de tre FC-ben. Sidstnævnte kredsløb kan realiseres i form af endnu en 74HC138, hvilket har den fordel at function codes er lettere at udlæse. Når begge 74HC138 er tilsluttet processoren kommer kredsløbet til at se ud som på 6.5. A0 A1 A2 AS* 5V A B C G1 G2A G2B 74HC138 Y0 Y1 Y2 Y3 Y4 Y5 Y6 Y IACK* IACK*-Ur FC0 FC1 FC2 5V A B C G1 G2A G2B 74HC138 Y0 Y1 Y2 Y3 Y4 Y5 Y6 Y Figur 6.5: IACK og Function code dekoder Da alle interrupts skal være autovektoriserede, er det ikke nødvendigt at AND e hver eneste IACK* med dettes IRQ*, for at informere processoren om brug af autovektoriseret interrupt. I stedet tilsluttes IACK* på figur 6.5, via adressedekoderen, processorens VPA*- ben. 6.6 NMI I tilfælde af fejl som stopper programafviklingen, er det nødvendigt at kunne starte debugger / monitor-systemet, der behandles i afsnit 4.3 på side 30. Når programafviklingen er stoppet, kan debugger/monitor-systemet startes ved at sende et NMI (Non-Maskable Interrupt). Et NMI behandles af processoren uanset om der er andre interrupts, da dette har højeste prioritet. NMI en genereres af en kontakt med et simpelt kredsløb, som fjerner prell 3. Et kredsløb, der gør dette kan opbygges som vist på figur 6.6. Kredsløbet består af to NAND-gates, der er koblet, så deres udgange altid er i hhv. høj og lav tilstand. Når kontakten aktiveres, vil udgangene skifte tilstand i et tidsrum svarende det som kontakten er aktiveret i, blot frit for prell. Til at realisere gatene vælges en 74HC00, der er en quad 2-input NAND-gate, hvilket vil sige at kun halvdelen af gatene benyttes. Tilslutningen foregår som vist på figur Prell: En række transienter der opstår ved tilstandsskift i en kontakt 49

54 KAPITEL 6. MODULDESIGN AF MINIMUMSYSTEM 5V 5V R12 10k R11 10k SW6 1 2 U20A 3 *IRQ7 74HCT00 0 SW SPDT 4 5 U20B 6 74HCT00 Figur 6.6: Kredsløb som eliminerer prell 6.7 Test af minimumssystem Inden de systemspecifikke hardwaremoduler bygges på systemet, skal minimumssystemets funktion testes igennem. Målet med dette er at få debugger/monitoren til at fungere på systemet. Inden dette kan ske skal minimumsystemets hardwareenheder dog testes hver for sig. Power-on reset Power-on resetkredsløbets funktion kan testes ved at måle med et oscilloskop, hvordan udgangen på kredsløbet styres, når systemet startes op og i øvrigt, når reset-knappen aktiveres. Det kontrolleres, at udgangen asserteres i mindst 100 ms, der er den tid processoren kræver, for at være sikker på reset af processoren ved opstart. Endvidere skal det testes at power-on resetkresløbet overholder processorens krav til stigetid. Kravet er her på 150 ns i henhold til (Motorola 1993) side Kravet testes ved at måle på RESET*- benet på processoren med et oscilloskop og så måle stigetiden med oscilloskopets quick meas funktion. Testresultater På figur 6.7 på modstående side ses opstartsforløbet for systemet. Øverst ses forsyningen, nederst ses RESET*-benet på processoren. Det ses at power-on reset tiden er 171 ms, og er dermed lang nok til at systemet er korrekt opstartet. På figur 6.8 på næste side ses det at stigetiden er helt oppe på 100 µs, hvilket betyder at kredsløbet ikke overholder processorens krav til stigetiden på Reset*-benet. På trods af, at kravet til stigetiden ikke overholdes, nulstilles processoren uden problemer. Clock Clock kredsløbet testes ved, med et oscilloskop, at måle clocksignalet, der sendes fra oscillatoren til clock-indgangen på mikroprocessoren. Dette signal skal være et 8 MHz 50

55 6.7. TEST AF MINIMUMSSYSTEM Figur 6.7: Power-on-reset forløb Figur 6.8: Power-on reset stigetid firkantsignal. Testresultater På figur 6.9 ses et signalet på M68k s clockindgang, en 8MHz firkant. Adressedekoder Adressedekoderen, der skal generere chipselect og VPA*, er realiseret i en PEEL-kreds, som kan testes på et board, hvor indgangene kan styres med et sæt kontakter. På udgangene er sat dioder, som viser hver enkelt udgangs tilstand. Med dette board kan det dermed testes, at adressedekodningen sker korrekt ved at simulere adressebussen, VMA*, E-clockens og IACK* s styring af indgangene. Testresultater Adressedekoderen er testet med kombinationer på indgangene svarende til tabel 6.3. Kolonnen yderst til højre viser udgangene, der blev asserteret ved den viste 51

56 KAPITEL 6. MODULDESIGN AF MINIMUMSYSTEM Figur 6.9: 8 Mhz clock kombination. Ved markeringen X er der testet med indgangen både asserteret og negeret. Resultatet af testen er altså at adressedekoderen vælger de perifære hardwareenheder korrekt. UDS* LDS* A1 A2 A3 A17 A22 VMA* AS* E IACK* UDGANG 1 X X X X 0 0 X X X X ROM_LOW* X 1 X X X 0 0 X X X X ROM_UP* 1 X X X X 1 0 X X X X RAM_LOW* X 1 X X X 1 0 X X X X RAM_UP* X X ACIA_DM* + VPA* X X ACIA_PC* + VPA* X 1 X X IO* X X X 1 X X I 2 C X LCD + VPA* X X X X X X X X X X 1 VPA* Tabel 6.3: Testresultater for adressedekoder Free-run test Den første test, der udføres på det samlede miminumssystemet er en såkaldt free-run test. Denne består i at alle ben på databussen, igennem nogle modstande forbindes til 0 V. Det får processoren til hele tiden at udføre en simpel instruktion, hvis vigtigste opgave er at få den til at gå videre til den næste adresse, og læse den samme instruktion. Hvis denne test forløber som den skal vil adressebenene tælle sekventielt igennem hele adresseområdet. Med et oscilloskop kan der på adressebenene måles firkantsignaler, hvor frekvensen halveres fra et ben til det næste. Testresultater På figur 6.10 på modstående side ses signalet på adressebussens ben A5 og A6, og det ses at frekvensen på A6 er den halve af A5 s. Test af TS2MON Efter at have opbygget det minimumssystem, som kræves til TS2MON, testes at debugger/monitor softwaren kan afvikles på systemet. Systemet tilsluttes en PC s serielport, via 52

57 6.7. TEST AF MINIMUMSSYSTEM Figur 6.10: Skopshot af A5 og A6 i free run debugger/monitor serielporten på systemet. Når systemets forsyningsspænding tilsluttes skal det sende TS2MON s opstartsprompt: #TSBUG 2 Version Når prompten vises, er næste trin at kontrollere at systemet reagerer på kommandoer som RESET og DISPLAY, og tryk på NMI-knappen. Når der trykkes på denne skal TS2MON afbryde det igangværende program og udskrive registrene. Hvis dette er tilfældet er næste trin at uploade testprogrammer til systemet. Hukommelsestest For at teste at RAM hukommelsen fungerer, anvendes et assembler program, som skriver talrækker i hele hukommelsen, og derefter læser at de rigtige tal står som de blev skrevet. Programmet tæller processorens dataregister D2 op, hver gang et lagerelement ikke indeholder det, der forventes. Kildekoden til dette testprogram findes i memtest.asm på bilags-cd en. Testresultater Ved afvikling af programmet til test af hukommelsen, blev der indlagt en testfejl i programmet. Dermed skal dataregistret D2 tælles op til 1 og ikke mere for at være korrekt gennemført. Dette var også resultatet ved udlæsning af dataregister D2 med TS2MON, efter afvikling af hukommelsestest-programmet. 53

58 Kapitel 7 Moduldesign af øvrigt hardware Med et fungerende minimumsystem kan de systemspecifikke hardwaremoduler nu designes og integreres. Det er disse moduler, der realiserer de funktionaliteter der er stillet krav om, at systemet skal opfylde. Modulerne designes i den rækkefølge de ønskes integreret i. Derfor er det første modul displayet. 7.1 Display Da det skal være muligt at aflæse temperaturen, luftfugtigheden og andre informationer listet i kravspecifikationen, skal der tilsluttes et display til systemet. Det vælges at benytte et display med indbygget controller. Controlleren, der er monteret er HD44780 kompatibel. En af fordelene ved denne controller er bl.a. at den har indbygget tegnsæt, mulighed for egne karakterer og opfrisker selv LCD-krystallerne. I dette afsnit er det kun controlleren til displayet der omtales, da det er dens grænseflade der kommunikeres med. Grunden til dette er, at controlleren sidder på displayet og sørger for alle nødvendige benforbindelser til displayet. Data og informationer i dette afsnit er alle hentet i databladet for HD44780 controlleren, der ligger på bilags-cd en med filnavnet DIS- PLAY_CONTROLLER_hd44780.pdf De ben, der skal benyttes for at skrive til displayet, vil her blive gennemgået : DB0-DB7 er databen. DB7 er MSB 1. Alle databenene bliver automatisk tri-stated, gjort høj impedante, når Enable benet sættes lavt. E står for Enable. Den fungerer som strobe. Når E er sat lav, læses der ikke data fra inputbenene. Når E sættes høj, kan der skrives til displayet ved at skrive til dataregistret, læses fra registrene, samt ændres data i registrene. Når E sættes lavt, tri-states DB0-DB7. R/W* står for Read-Write. Nå dette sættes lavt kan der skrives til controlleren. Når det sættes højt kan der læses fra controlleren. RS står for Register Select og benyttes for at bestemme om der skal skrives/læses til/fra instruktionsregistret eller dataregistret. Sættes det lavt, arbejdes der i instruktionsregisteret og der kan skrives kommandoer til controlleren, såsom at flytte cursoren, fjerne cursoren, slette indhold på display etc. Sættes RS højt kan der sendes karakterer til dataregistret, 1 Most Significant Bit 54

59 7.1. DISPLAY som indeholder karakter-data. V CC er den positive forsyningsspænding. GND er forsyningsspændingens stel. Vo skal benyttes for at indstille kontrast. Dette kan med fordel tilslutes på et potentiometer, der fungerer som en spændingsdeler mellem GND og V CC som er forsyningsspændingen. På denne måde vil der være mulighed for at jurstere kontrast på displayet. Controlleren lagrer de karakterer, der ønskes vist, i DDRAM en, hvilket står for Display Data RAM. DDRAM en er på 80 Bytes, og kan rumme 80 karakterer, da hver karakter fylder en byte. Adressen i DDRAM en svarer til positionen af cursoren på displayet. Adresse 0 er dermed positionen længst til venstre på øverste linie i displayet. Command Clear Display Return Home Write Data to CG or DD RAM Read Data from CG or DD RAM RS Code R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB Description Clears the display and returns the cursor to the h (address 0). Returns the cursor to the home position (address 0). Also returns * a shifted position. DD RAM contents remain unchanged. 1 0 Write Data 1 1 Read Data Writes data into DD RAM or CG RAM. Reads data from DD RAM or CG RAM. Execution Time 82µs~1.64ms 40µs~1.64ms 46µs 46µs Figur 7.1: Kommandoversigt for karakterskrivning Initialisering af display-controlleren Displayet kan klargøres på to måder. Enten ved at benytte displayets interne resetkredsløb, eller ved at initialisere det vha. kommandoer. Displayets interne reset-kredsløb aktiveres fra spændingsforsyningen, der skal leve op til givne rise-time krav. Ønskes det at benytte det interne reset-kredsløb, skal spændingen stige fra 0 V til V CC på en hvis tid. Ønskes det ikke at benytte denne metode, kan det vælges at initialisere displayet, ved at sende kommandoer til det. De tabeller, der er vist er hentet fra databladet til controlleren, der findes på bilagscd en. Det vil her blive forklaret hvordan displaycontrolleren kan initialiseres vha. software : 1. Sæt forsyningsspænding til displayet, og vent mindst 15 ms. efter V CC er steget til 4,5 V. 2. Sæt parametrene, som vist på fig. 7.2 (a) og vent mere end 4,1 ms. 3. Samme handling som pkt. 2, denne gang skal der ventes mere end 100 us 4. Samme handling som pkt. 2, denne gang skal der ikke ventes. 5. Her skal det specificeres om der benyttes 4 eller 8 bits interface samt hvor mange linier, der benyttes. Se fig. 7.2 (b). N et indikerer hvor mange linier displayet er på. 55

60 KAPITEL 7. MODULDESIGN AF ØVRIGT HARDWARE Dette sættes til 1, hvilket betyder at der er 2 linier. F et indikerer font-typen. Denne sættes til 0, hvilket svarer til 5x8 pixel. 6. Indholdet af DDRAM en slettes, se fig. 7.2 (b) (Display Clear). 7. Initialiseringen er færdig, og displayet er klart til brug. RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB * * * * (a) RS R/W DB7 DB6 DB5 DB4 DB3 DB2 DB1 DB N F * * cific tal af linier ! lear I/D S " $# % & (b) Figur 7.2: Initialisering af display-controller Opsætning af display Controlleren har flere funktioner, der kan vælges imellem. Der er mulighed for at teksten overskriver karakterer på displayet, skubber dem ud, scroller med bogstaverne etc. Derudover kan det defineres om det ønskes at cursoren skal være synlig eller usynlig, om den skal blinke eller ikke blinke. Det ses på fig. 7.3 hvordan der skrives kommandoer til displayet. Som det ses, er RS-benet sat lav i alle tilfælde hvor der ændres på opsætningen af controlleren. Grunden til dette er, som tidligere nævnt, at man med RS kan vælge om det ønskes at arbejde med instruktionsregistret eller dataregistret. For at benytte de funktioner controlleren besidder, skrives software, der indeholder funktioner, der kan sætte controlleren op til den ønskede tilstand. Dette står beskrevet i afsnit på side 132. Visning af karakterer Controlleren har indbygget tegnsæt. Der findes to udgaver af controlleren, hver med sit tegnsæt. Der er op til 256 forskellige tegn i tegnsættet. Det enkelte tegn vælges ved at angive adressen til tegnet (tegnets nummer) i dataregistret vha. 8 bit parallelt på DB0- DB7. Nogle af disse karakterer er tomme og andre er beregnet til egne karakterer. Det enkelte bogstav eller tegn, samt adresse, findes i en tabel i databladet for controlleren. Cursoren står samme sted som adressepointeren peger på i DDRAM en. Efter displayet er blevet initialiseret, peger adressepointeren på adresse 0, og sendes der et bogstav til 56

61 7.1. DISPLAY displayet, vil det derfor blive vist på displayets første position, hvilket er øverste række til venstre. COMMANDS FOR CHARACTER ODULES M Command Clear Display Return Home Entry Mode Set Display ON/OFF Control Cursor & Display Shift Function Set Set CG RAM Address Set DD RAM Address Read Busy Flag & Address BADC :E6! F ft. I/D = 1: Incremen t I/D = 0: Decrement S/C= 1: Display shift S/C = 0: cursor move R/L= 1: Shift to the right. R/L= 0: Shift to left. the DL = 1: 8 bits DL = 0: 4 bits N = 1: 2 lines N = 0: 1 e lin F = 1: 5x10 dots F = 0: 5 x 7 dots BF = 1: Busy BF = 0: Can accept data G;HJIK K LNMEL O P Q!R QSLTUV I W Code RS R/W DB7 DB6DB5 DB4 DB3 DB2 DB1 DB * I/D S D C B S/C R/L * * DL N$ F * # A DD 0 1 BF AC $ With KS0072 is Address Mode. A CG Clears the display and returns the cursor to the h (address 0). Returns the cursor to the home position (address 0). Also returns a shifted position. DD RAM contents remain unchanged. and enables/disables the display. Turns the display ON/OFF (D), or the cursor ON/OFF (C), and blink! " t the cursor position (B). 8! " ( " RAM contents. Sets the data width (DL), the number of lines in the display (L), "! " #%$&. Sets the CG RAM address. CG RAM data can be read or altered after making this setting. Sets the DD RAM address. Data ' (% " ) k- ing this setting. *,+.- )/ 0 #%+.$"& 1 cating that an internal operation is being performed and reads the! " *7698;: 3 *7698 CG RAM: Character generator RAM: <4=>*7698?6 A CG ress : 3435*7698@6 A DD AC: Descriptio n! < 1 sor address. Address counter Used for both DD and CG RAM address. Figur 7.3: Kommandooversigt for display-controlleren Execution Time 82µs~1.64ms 40µs~1.64ms 40µs 40µs 40µs 40µs 40µs 40µs 1µs Execution times are typical. If transfers ' software and the busy flag is not used, add 10% to the ' F 2 På fig. 7.1 på side 55 ses det hvordan der skrives til displayet. Når en karakter skrives i DDRAM en skrives den umiddelbart efter på displayet. Displayet, der er et 4x16 karakters display, bliver af controlleren registreret som to 2x16 karakters displays. Startadresserne til linierne er sat op således at 1. linie starter med adresse 0, 2. linie stater på adresse 64, 3. linie starter på adrese 16 og 4. linie starter på adresse 80. Udover, at der kan vælges karakterer fra det interne tegnsæt, kan der også lagres egne karakterer. Der kan lagres 8 egne tegn. Disse kan med fordel benyttes hvis der er behov for et særligt tegn, der ikke er defineret i tegnsættet. De gemmes i CGRAM en, der indeholder de tegn, der er lavet af brugeren. Hver read-write instruktion tager 46 µs at udføre. Det vil derfor tage under 2 ms at skrive de to linier ud på displayet. 57

62 KAPITEL 7. MODULDESIGN AF ØVRIGT HARDWARE HW interface Controlleren er udviklet med henblik på interfacing til microprocessorsystemer, og kan derfor, uden ekstra hardware, tilsluttes systemet. Det vælges at tilslutte displayet som vist på fig. 7.1: Minimumssystem HD44780 Beskrivelse A0 RS Valg af register R/W* R/W* Read/Write* CS-LCD E Aktivering af controller D0-D7 DB0-DB7 Databen Tabel 7.1: HW Interface af display CS-LCD er Chip Select fra adressedekoderen. Denne bliver sat høj, når displayets adresse bliver kaldt fra processoren og den har svaret ved at assertere VMA samt E-clocken, hvilket får adressedekoderen til at aktivere chip select, som er forbundet til enable-benet på displayet. Udover de listede ben, skal V o, der er kontrastjusteringen, også benyttes. Dette ben tilsluttes et potentiometer, der skal fungere som spændingsdeler mellem V CC og GND. Dette vælges til 2,2 kω. Med dette er det muligt at ændre kontrasten på displayet. På fig. 7.4 ses el-diagrammet for display-controlleren. 5V R5 CONTRAST 0 A0 A0 R/W * R/W * 5V 0 RS R/W* E D0 D1 D2 D3 D4 D5 D6 D J1 HD44780 CS-LCD abus DISPLAY Figur 7.4: Display el-diagram 7.2 Taster og alarm Da kravspecifikationen, i afsnit på side 20 som omhandler krav til menusystemet, stiller krav om et tastatur med 4 taster til systemet, skal der udvikles et interface, der muliggør dette. Det vælges at lave taste-systemet således at det kan tilkobles databussen. Adressedekoderen, se afsnit 6.4 på side 44, sætter CS* lav på den kreds, der skal aktiveres. Der kan på denne måde kommunikeres med tastaturet gennem databussen på systemet. Udover tast-input skal det også være muligt at sætte et alarmben højt hvis der opstår en alarm. 58

63 7.2. TASTER OG ALARM Krav til tast- og alarm-kredsløb Selve tast-systemet skal bestå af et antal logiske kredse, der bliver aktiveret når deres CS* bliver asserteret af adressedekoderen. Det er vigtigt at de logiske kredse, der skal kobles på databussen, har mulighed for at blive tristated / gjort højimpedante. Hvis ikke enhederne kan tristates, vil de enten holde databussen lav eller høj, alt efter hvilken tilstand de sidst var i. Kredsløbene skal fungere så hurtigt, at der kan benyttes asynkron bus, uden DTACK*. Propagation delayet for OE* til Q n er i databladet fundet til et max på 13,5 ns, hvilket lever op til de krav, der stilles til enheder, der ikke benytter DTACK*. Det er et krav at systemet kun skal benytte eet CS*, som skal kunne aktivere tast-input og alarm-output alt efter om der skal læses eller skrives. Analyse af tast- og alarm-kredsløb Der skal kobles 4 taster til systemet, [enter], [esc], [<] og [>]. Disse taster kan ikke umiddelbart kobles på databussen, hvorfor der skal benyttes nogle passende logiske kredse ved grænsefladen til databussen. Hvis dette ikke gøres, opstår der problemer med databussen. Hardwaren kan bygges op på flere forskellige måder. Der kan benyttes en latch, en PEEL, en mikroprocessor eller andre logiske enheder. Det vælges at benytte to latches, som hhv. benyttes til tast-input og alarm-output. Det skal være muligt at tilslutte en alarmenhed til systemet, hvorfor der skal designes et kredsløb, der kan modtage et alarmsignal fra systemet, og efterfølgende holde et alarm-ben højt. Det vælges at benytte et CS* fra adressedekoderen. Der skal derfor laves et kredsløb der på baggrund af CS* og R/W* kan bestemme om alarmbenet skal sættes eller om der skal læses fra tasterne. Valg og design Det vælges at benytte en 74HCT373 latch til alarm-output og tast-input. Denne er valgt da det er en HCT-kreads, da den kan tristates, og da dets output-ben kan levere 25 ma. Der er i dette afsnit benyttet information, hentet fra databladet, der findes på bilagscd en med filnavnet TAST_ALARM_74HCT373.pdf. Tast-input kredsløbet skal kun være aktivt når CS* er negeret samtidigt med at R/W* er asserteret. Dog gør det ikke noget at kredsløbet registrerer tast-input. Altså kan Latch- Enable (LE) sættes til V CC på denne kreds, men OE* skal asserteres når det er aktivt. Alarm-output kredsløbet skal kun være aktivt når CS* er negeret samtidigt med at R/W* også er negeret. Kredsløbet skal dog holde benet asserteret hvis der tidligere har været en alarm, altså kan output-enable på denne kreds (OE*) sættes til stel. LE på denne kreds skal asserteres ved aktivitet. På bagrund af disse to definitioner, kan to sandhedstabeller opskrives. Sandhedstabellen for taste-input er vist på fig. 7.2 og sandhedstabellen for alarm-output er vist på fig På baggrund af de to sandhedstabeller, der er blevet opstillet, kan det umiddelbart ses at taste-input kredsløbet kan opbygges af en inverter (NOT-gate) samt en OR-gate. Det ses også umiddelbart at alarm-output kredsløbet kan opbygges af en enkelt OR-gate samt en inverter. De to kredsløb ses på fig

64 KAPITEL 7. MODULDESIGN AF ØVRIGT HARDWARE CS* R/W* OE* Tabel 7.2: Sandhedstabel for taste-input CS* R/W* LE Tabel 7.3: Sandhedstabel for alarm-output abus 5V SW 1 CS-IO* R/W * R/W * SW 2 SW 3 SW 4 CS-IO* U7B R1 10k 3 4 R2 10k 0 R3 10k 9 10 U8C R4 10k 74HCT32 8 5V U9 D0 D1 D2 D3 D4 D5 D6 D7 LE OE 74HCT373 Q0 Q1 Q2 Q3 Q4 Q5 Q6 Q D0 D1 D2 D3 D4 D5 D6 D7 74HCT04 ALARM-UD U8D HCT Q0 Q1 Q2 Q3 Q4 Q5 Q6 Q7 U7C U10 D0 D1 D2 D3 D4 D5 D6 D7 LE OE 74HCT D0 D1 D2 D3 D4 D5 D6 D7 0 74HCT04 Figur 7.5: Tast-input samt alarm-output kredsløb Output fra 74HCT373 latchen kan levere 25 ma. og lever derfor op til kravspecifikationens krav til alarmudgangen i afsnit på side 22. Der er derfor ikke behov for et transistortrin. Test Alarmudgangen testes ved hjælp af software. I softwaren holdes benet asserteret, og det registeres at det fortsat er asserteret indtil det negeres vha. software igen. Tast-input testes ved at udlæse tast-status på displayet. På displayet kan det ses når tasterne trykkes og 60

65 7.3. I 2 C-BUS slippes. Testresultater Ved gennemførslen af ovenstående test opnåedes et tilfredsstillende resultat. På displayet kunne det ses at tasterne kun var aktive når de blev benyttet, og det blev verificeret at alarmbenet blev holdt højt fra det blev asserteret og til det blev negeret igen. Altså regnes hardwaren for værende fungerende. 7.3 I 2 C-bus I 2 C står for Inter Integrated Circuit og blev udviklet af Philips i slutningen af 1970 erne. I 2 C er en to-leder bus-teknologi, der bliver anvendt, blandt andet i PC ere, som en fælles bus mellem temperaturmålere. Følgende afsnit forklarer hvorledes I 2 C standarden er defineret og hvorledes denne kan implementeres i et system med en mikroprocessor. Afsnittet tager udgangspunkt i (Dominique Paret 1997) side Opbygning I 2 C er en to-leder busteknologi, dvs. at 2 ledere sørger for al kommunikationen på bussen. De 2 ledere hedder henholdsvis SDA (Serial DAta) og SCL (Serial CLock). På SDA bliver al data i systemet overført, skrive- og læseoperationer, dvs. 2-vejs kommunikation. På SCL genereres clocken, som dataoverførsler bliver synkroniseret i forhold til. Hver enhed på bussen har en unik adresse som denne kan addresseres udfra. Elektrisk specifikation I 2 C er en 5 V teknologi. I 2 C bussen understøtter bidirectional dataflow, dvs. der kan sendes og modtages data på SDA. Dette opnås ved at enhederne på bussen bruger Open-Drain kredsløb til at drive bussen. Derfor sidder der pull-up modstande på bussen til at holde bussen høj, når der ikke er nogen enheder, der er aktive. Enheden kan sænke niveauet på bussen ved at aktivere Open-Drain kredsløbet. Specifikationen for I 2 C-bussen siger at der ikke må kunne trækkes mere end 3 ma over bussen. Pull-up modstandene kan derfor beregnes til ikke at må være mindre end: 5V 1,7 kω 3mA Stige- og faldtiden for bussen må ikke overstige 1µs og det kan derved beregnes hvor stor en kapacitiv belastning der kan tillades på bussen: 1µs 588 pf 1,7kΩ Det er dog i I 2 C-standarden fastsat at bussen maksimalt må belastes med 400 pf. Der er derfor en øvre grænse for pull-up modstandene og derved hvor mange enheder der kan tilsluttes bussen før specifikationerne ikke længere er overholdt. Ovenstående specifikation gælder for en bus-hastighed på op til 100 khz og det er således den, der vil blive anvendt i projektet. 61

66 KAPITEL 7. MODULDESIGN AF ØVRIGT HARDWARE Dataoverførsel Når der indtræffer en start-betingelse regnes bussen for optaget, og ledig igen når der forekommer en stop-betingelse. Start- og stop-betingelser vil blive specificeret senere. Det er vigtigt at alle enheder på bussen genkender dette, da det betyder at de kan gøre brug af bussen. I beskrivelsen vil der anvendt følgende indforståede ord: Master: Den enhed der har kontrollen med bussen, dvs. den enhed, der sørger for clock-pulsen på SCL, og giver kommandoer til andre enheder. Slave: En enhed opfattes som slave, når en anden enhed, master, har kontrollen med bussen. En slave-enhed lytter derfor på SDA og sender/modtager data efter clock-pulsen på SCL hvis den er blevet adresseret. Herefter vil de forskellige situationer der kan opstå på bussen blive beskrevet. Denne beskrivelse viser en typisk overførsel af data fra master til slave. Overførslen er vist på bit-niveau på figur 7.6 Start betingelse (ST) Er bussen ledig, kan en enhed tage kontrollen med bussen ved at sænke SDA fra høj til lav, mens SCL er høj. Derved bliver denne enhed master. Adressering (ADR) Efter ST vil masteren skrive 8 bit til bussen. De første 7 bit angiver den slave som masteren ønsker at adressere 2 og den sidste angiver om det skal være en skrive eller læse operation. Er den 8. bit 0 indikerer masteren, at den ønsker at skrive til slaven. Er den istedet 1 indikerer masteren at den ønsker at læse fra slaven. Da beskrivelsen tager udgangspunkt i en dataoverførsel fra master til slave er den 8. bit her 0. Acknowledgement (ACK) Efter ADR skal den slave, hvis adresse stemte overens med den, der blev skrevet på bussen, indikere dette til masteren. Masteren har siden ST skrevet 8 clock-pulser på SCL og den 9. skal anvendes til at verificere at de sendte data på SDA blev forstået af slaven. Slaven, der blev adresseret angiver sin accept af dataene ved at trække SDA lav i den 9. clock-puls. Overførsel af data (DATA) Efter de foregående begivenheder er masteren nu parat til, at overføre data til slaven. Data sendes byte-vis over bussen og afsluttes af en ACK. Indtræffer ACK ikke indikerer slaven overfor masteren at den sidste byte ikke blev forstået. Masteren vil derfor typisk sende de samme data igen. I dette til fælde blev der overført én byte og slaven svarede med en ACK. Stop betingelse (SP) Efter DATA indikerer masteren til slaven, og resten af bussen, at den ikke ønsker at overføre mere data. For at indikere dette lader masteren SDA gå fra lav til høj mens SCL holdes høj. Efter SP er bussen igen ledig og ovenstående beskrivelse kan starte forfra. 2 7 bit giver mulighed for at adressere 2 7 = 128 enheder. I 2 C er siden blevet udvidet til at kunne adressere 2 10 = 1024 enheder, men dette vil ikke blive gennemgået. 62

67 7.3. I 2 C-BUS SDA SCL ST ADR W A SP Figur 7.6: Kommunikation på I 2 C bus Adresserne til enheder kan ikke frit vælges da disse inddeles efter den funktion I 2 C- enheden har. Disse blive bestemt af The I 2 C Bus Commitee. I forbindelse med projektet skal der ikke konstrureres enheder, der skal følge denne standard, da der kun findes en master i systemet. En enkelt af disse adresser vil dog blive nævnt. Skrives adressen 0 (General Call Address) til bussen skal alle enheder på bussen svare. Derved kan de samme data overføres til mange enheder. I 2 C er kompatibel med SMBus, dog med den forskel at SMBus-protokollen indeholder en time-out funktion, der typisk er på 25 ms. Time-out funktionen indebærer at en SMBus enhed ikke vil vente evigt på en overførsel fra en master, hvilket er tilfældet med en I 2 C- enhed I 2 C controller: PCF8584 For at realisere den ønskede I 2 C-funktionalitet anvendes en dedikeret IC til dette. Systemet har kun en bus-master, da sensorerne skal være slave-transmitter/receiver, derved skal controlleren kun understøtte master-transmitter/receiver. Laboratoriet på universitet råder kun over en I 2 C-controller der understøtter både master-transmitter/receiver og slave-transmitter/receiver, samt multimaster. Da denne opfylder kravet om understøttelse af master-tranmitter/receiver vil denne blive anvendt. Kredsen er en PCF8584 fra Philips og vil blive beskrevet nærmere i det følgende afsnit. Henvises der til databladet findes dette som I2C_cnt-PCF8584_4.pdf på den vedlagte bilags-cd. PCF8584 understøtter flere typer CPU er. Beskrivelsen tager udgangspunkt i at det er en M68k CPU der anvendes. Anvendes en anden type CPU betegnes enkelte benforbindelser anderledes, hvilket kan ses i databladet. Long distance mode omtalt i databladet vil ikke blive beskrevet, da dette forudsætter kommunikation mellem 2 PCF8584 kredse. Benforbindelser Benfobindelserne for PCF8584 kan ses på tabel 7.4. PCF8584 kan ses opkoblet på el-diagrammet i appendiks C. Opsætning PCF8584 har et antal registre, der bestemmer opsætningen og statusen af kredsen. Disse vil i det følgende blive beskrevet: 63

68 KAPITEL 7. MODULDESIGN AF ØVRIGT HARDWARE Ben I/O Navn Funktion 1 I CLK Clock-frekvensen til kredsen. Samme som clockfrekvensen til M68k. 2 I/O SDA I 2 C-bussens Signal DAta I/O. Temperatur- og RF-sensor skal have SDA tilsluttet til denne således at klimadata kan overføres. 3 I/O SCL I 2 C-bussens Signal CLock. Temperatur- og RF-sensor skal have SCL tilsluttet til denne således at disse arbejder efter den clock som PCF8584 genererer. 4 I IACK* Interrupt ACKnowledge. Tilsluttes til M68k hvis der kommunikeres vha. interrupt. Anvendes ikke. 5 O INT* Interrupt udgang til M68k. Dette ben går lavt når PCF8584 har modtaget data på I 2 C-bussen og aktivere et interrupt. Anvendes ikke. 6 I A0 Tilsluttes A1 fra M68k. Sættes denne til logisk 1 vælges register S1 7 I/O DB0 Databus-ben 0. Tilsluttes til DB0 på M68k. 8 I/O DB1 Databus-ben 1. 9 I/O DB2 Databus-ben V SS Stel 11 I/O DB3 Databus-ben I/O DB4 Databus-ben I/O DB5 Databus-ben I/O DB6 Databus-ben I/O DB7 Databus-ben O DTACK* Data Transfer ACKnowledge. Går lavt når data på den parallelle bus er gyldig. 17 I CS* Chip Select. Skal tilsluttes adressedekoderen for at PCF8584 aktiveres ved de rigtige adresser. 18 I R/W* Read/Write. 19 I/O RESET* Tilsluttes til power on reset V DD Forsyning. Tabel 7.4: Benforbindelser på PCF8584 S0. Dette register indeholder kredsens I 2 C-adresse. Systemet skal i princippet ikke anvende denne, da den aldrig vil blive adresseret på bussen, men den skal sættes op for at sikre kredsens funktionalitet. Det skal dog bemærkes at registret har en offset på 1 bit. Dvs. at en programmeret adresse %11111 bliver til % pga. dette offset. S0. Dette register står for kommunikation af data mellem I 2 C-bussen og parallelbussen, også kaldet shift/buffer-registret, hvilket vil sige at den opfylder to funktioner. Data fra parallel-bussen bliver altid skrevet til shift-registeret og læst fra buffer-registret. Data fra I 2 C-bussen bliver enten skrevet til, eller læst fra, shiftregisteret. På figur 7.7 er shift-registret vist, som er hentet fra databladet. Det skal dog bemærkes, at læsning af buffer-registeret skal behandles specielt. Den første læse-operation af buffer-registeret sørger for at dataene i shift-registeret bliver over- 64

69 7.3. I 2 C-BUS Figur 7.7: Shiftregister i PCF8584 ført til buffer-registeret, hvor den næste læse-operation giver de ønskede data. For at der ikke skal blive skrevet nye data til shift-registeret, fra I 2 C-bussen, før det er blevet læst, bliver SCL holdt lav. S2. Dette register sørger for at alle clock-frekvenser er indstillet korrekt i forhold til det hardware som PCF8584 skal arbejde sammen med. Registret bestemmer hvorledes de interne clock-delere skal indstilles ud fra den clock-frekvens microcontrolleren kører med og hvor hurtig overførsel der ønskes på I 2 C-bussen. PCF8584 er i stand til at drive I 2 C-bussen med maksimalt 90 khz, hvilket vil blive anvendt. Da M68k i systemet anvender en 8 MHz clock kan det bestemmes, vha. databladet for PCF8584, at registeret skal have værdien % S3. Registeret indeholder en 8 bit interrupt-vektor og vil blive sendt på bussen hvis PCF8584 anvendes vha. interrupt. Det er valgt at anvende polling til at bestemme om der skal hentes data fra PCF8584. Derfor bliver dette register ikke anvendt. S1. Registeret er delt i to sektioner, en der kan læses fra og en der skrives til. Sektionen der læses fra giver statussen for I 2 C-bussen og sektionen der skrives til giver kontrol over PCF8584 funktioner på I 2 C-bussen. Der opnås adgang til registret ved at sætte A0 høj. Kontrol sektionen er delt op som vist i tabel 7.5. PIN ESO ES1 ES2 ENI STA STO ACK Tabel 7.5: Bit-mønster i kontrol-sektion i S1 3 Se datablad PIN (Pending Interrupt Not): Under overførsel af data kan der læses fra PIN for at se om data er blevet sendt eller om det er blevet sendt. Derved anvendes PIN ved polling for at tjekke om den ønskede operation er færdig, hvilket angives ved at PIN er 0. ESO (Enable Serial Output): Bliver denne bit sat til logisk 1 bliver, I 2 C- interfacet aktiveret og status-sektionen i S1, samt buffer-registeret i S0, kan læses. ES1, ES2: Alt efter hvordan disse sættes, gives der adgang til de før omtalte registre som PCF8584 råder over 3. 65

70 KAPITEL 7. MODULDESIGN AF ØVRIGT HARDWARE ENI: Sættes dette til logisk 0 bliver interrupt-udgangen, INT*, aktiveret og INT* asserteres hvergang der forekommer et interrupt i PCF8584, dvs. hver gang der er modtaget eller afsendt data. STA, STO: Disse bit bestemmer om PCF8584 skal være master eller slave, og herunder om dette skal være som receiver eller transmitter. Da der i systemet kun er en master vil slave-operationer ikke blive anvendt. Dette gør at kun kombinationerne for STA og STO, der giver master/transmitter (MST/TRM) og master/receiver (MST/REC) funktionerne vil blive anvendt. Skal en slave adresseres skal dette gøres ved at STA er 1 og STO er 0. Herved er PCF8584 MST/REC og en start-betingelse og adressen på slaven bliver sendt på bussen. Hvis R/W* er 0 forbliver PCF8584 MST/TRM, ellers hvis R/W* er 1 indstiller PCF8584 sig til MST/REC (STA = 0, STO = 1) efter adressen er blevet sendt. ACK: Denne bit er normalt sat til logisk 1 og derved sendes der automatisk en ACK-betingelse på bussen efter hver modtagen byte. Når MST/REC ikke længere ønsker at modtage mere data fra slaven skal ACK sættes til logisk 0. Derved sender PCF8584 ikke en ACK efter den sidste byte er modtaget, og slaven opfatter dette som at masteren ikke ønsker flere data. Status-sektionen i registeret S1 vil her blive omtalt, og er udformet som vist i tabel 7.6. PIN 0 STS BER AD0/LRB AAS LAB BB* Tabel 7.6: Bit mønster i status-sektion i S1 4 Se afsnit 7.3 PIN: Skrives denne bit som logisk 1, bliver alle andre status-bits sat til logisk 0, dvs. en reset af PCF8584. STS: Anvendes kun i slave/receiver. Denne bit bliver sat til logisk 1 når masteren på bussen sender en stop-betingelse. BER (Bus ERror): Opstår der en fejl på bussen, dvs. en start- eller stopbetingelse midt i en overførsel af data, bliver denne bit sat til logisk 1. Dette betyder at alle andre enheder på bussen lader SCL og SDA blive høje, dvs. bussen er ledig. AD0/LRB (ADdress 0/Last Received Bit): Hvis AAS er 1, opfattes bit en som AD0, og denne bit bliver sat til logisk 1 hvis adressen der er blevet modaget på bussen er general call address 4. Hvis adressen i stedet stemmer overens med PCF8584 s egen adresse bliver AD0 sat til logisk 0. Er AAS i stedet 0, opfattes bit en som LRB. Ved denne indstilling indeholder denne bit den sidste bit der blev modtaget på bussen. Derved kan den anvendes til at undersøge om slaven sendte en ACK-betingelse efter den sidste byte. AAS (Addressed As Slave): Hvis PCF8584 er indstillet til receiver vil denne bit blive sat til logisk 1 når den modtager en adresse fra bussen der stemmer overens med den der er gemt i adresse-registeret S0. 66

71 7.3. I 2 C-BUS LAB (Lost ArBitration): Denne bit bliver sat til logisk 1 hvis PCF8584 taber kontrollen med bussen til en anden master. Dette vil ikke indtræffe i systemet da der kun findes en master på bussen. BB* (Bus Busy): Denne bit indikerer hvorvidt bussen er ledig eller ej. Denne bit skal således altid læses før der foretages en operation på bussen. Er BB* 0 er bussen optaget og der skal derfor ventes indtil BB* er 1 før bus-operationer er tilladt. Timing Før PCF8584 kan kobles på adresse- og databussen skal det undersøges om den overholder timing-kravene i afsnit på side 28. Tiden der skal findes er derfor tiden fra at CS* asserteres til DTACK* asserteres. Denne er i databladet opgivet til: t CLDV = 3 t CLK ns = 525 ns Dette er opfylder ikke kravet for t opsaet l red hvilket gør det nødvendigt at designe et kredsløb der kan koble PCF8584 s egen DTACK* ind når CS* er asserteret. De valgte hukommelseskredse behøver ikke en DTACK* generator og AS* kobles derfor direkte til DTACK* når CS* asserteres på disse. Når PCF8584 s CS* asserteres skal DTACK* fra PCF8584 kobles ind i stedet for AS*. Der er derfor opstillet en sandhedstabel for DTACK* generatoren på figur 7.7 DTACK* CSI2C* DTI2C AS* Tabel 7.7: Sandhedstabel for DTACK-generator til PCF8584 Sandhedstabellen indsættes i et Karnaugh kort (Se figur 7.8) for derved at kunne bestemme en boolsk ligning, der beskriver kredsløbet til DTACK-generatoren. A\BC Tabel 7.8: Karnaugh kort for DTACK-generator til PCF8584. A = CSI2C*, B = DTI2C* og C = AS* Ud fra Karnaugh kortet kan følgende boolske ligning opstilles for DTACK: DTACK = CSI2C DTI2C +CSI2C AS 67

72 KAPITEL 7. MODULDESIGN AF ØVRIGT HARDWARE Udfra ligningen ses det at der skal bruges 2 OR gates, en AND gate og en inverter. Systemet råder i forvejen over ubrugte NAND gates. Derfor anvendes de Morgans regel til at omskrive ligningen til udelukkende at anvende NAND gate logik, ved at lave en dobbelt negering. DTACK = CSI2C DT I2C +CSI2C AS Den ene negering på højre side af ligningen omskrives for at fjerne OR operationen: DTACK = CSI2C DTI2C CSI2C AS DTACK-generatoren kan derfor udformes som på figur 7.8. AS* 1 2 U23A 3 CSI2C* DTI2C* U7D HCT04 74HCT U23C 74HCT U23B 74HCT00 6 DTACK* Figur 7.8: DTACK-generator til PCF Temperatursensor I dette afsnit gennemgås den valgte temperatursensors funktioner, samt hvorfor denne sensor er blevet valgt. Når der henvises til et datablad, uden en efterfølgende angivelse af hvilket, menes der I2C_tempsensor-sa56004.pdf, der ligger på bilags cd en. De temperatursensorer laboratoriet råder over, som benytter I 2 C-bus, er ikke i stand til at opfylde de krav der er stillet i kravspecifikationen 3 på side 16, hvilket gjorde at der blev søgt efter alternativer andre steder. Det lykkedes dog aldrig at finde en temperatursensor, der kunne opfylde kravene, til en rimelig pris. De bedste løsninger er SE95A eller en SA56004, begge fra Philips. Philips blev derfor kontaktet mht. vareprøver og Philips var villig til sende eksemplarer af SA Dette var desværre ikke den bedste af de to, men umiddelbart den bedste løsning, der kunne opnås. Tabel 7.9 viser de opstillede krav samt det der er opnået ved at anvende en SA El-diagrammet for sensoren kan ses i afsnit på side 70. Udfra tabel 7.9 ses det at det eneste krav, der blev opfyldt med den valgte løsning var temperaturområdet. Havde SE95A været tilgængelig havde det opnåede været tættere på kravene, men ikke opfyldt. SA56004 s afvigelser fra kravene accepteres dog og vil blive anvendt til projektets løsning. Opsætning SA56004 laves i 8 udgaver, alle med forskellige I 2 C-adresser, således at 8 kredse kan fungere på samme bus. Udgaven, der er modtaget fra Philips er en SA56004-ED og har 68

73 7.3. I 2 C-BUS Krav SA56004(anvendt) SE95A Temp. min. -20 C -55 C -55 C Temp. min. +60 C +125 C +125 C Max. temp. afvigelse (-5 C- +30 C) ±0,5 C ±3 C ±1 C Max. temp. afvigelse yderområde ±2 C ±3 C ±1 C Opløsning 0,1 C 0,125 C C Tabel 7.9: Krav til temperatursensor adressen % Kredsen er opbygget således at temperaturen er gemt i to registre. Et register indeholder temperaturen, med en opløsning på 1 C, og kan anvendes alene til at vise temperaturen. Ønskes der en højere opløsning, hvilket er tilfældet i projektet, kan et andet register læses for at tilføje decimaler til temperaturen med opløsningen 0,125 C. Temperaturen skal således læses i 2 omgange for at få den største præcision. Nu da temperatursensorens opsætning er forklaret, vil luftfugtighedssensoren blive forklaret Fugtighedssensor Da det er valgt at benytte en I 2 C bus vil det være praktisk at benytte denne bus til fugtighedssensoren. Da det ikke har været muligt at finde nogen luftfugtighedssensor, der benytter I 2 C bussen, blev det valgt at benytte en I 2 C-AD-converter, da der findes luftfugtighedssensorer, der giver en spænding som er proportional med luftfugtigheden. Disse sensorer er dog ret dyre (koster mindst 200 dkr. ved 1 stk.) så det blev valgt at montere et potentiometer som spændingsdeler mellem forsyningspændingen og stel. Fra denne spændingsdeler modtages en spænding mellem 0 og 5 V DC, som sendes til AD converterens indgang. På denne måde kan luftfugtigheden simuleres med et potentiometer. Hvis der senere købes en luftfugtighedssensor, der giver en spænding ud, som er proportional med luftfugtigheden, kan denne sættes direkte til AD converteren, og systemet skulle uden videre problemer fungere. Det vælges at benytte en MAX1236EUA, der er en 12-bit 4 kanals AD-converter med I 2 C-interface. Datablad for denne kan findes på bilags- CD en med filnavnet I2C_AD-MAX1236-MAX1239.pdf. Der er i dette afsnit benyttet data fra dette datablad. Denne AD-converter tilsluttes direkte på I 2 C-bussen. Da det er en 4 kanals AD-converter er der mulighed for at montere op til 4 luftfugtighedssensorer eller andre sensorer. El-diagrammet kan ses i afsnit på den følgende side. AD-converteren kan køre med bushastighed på op til 1,7 MHz, og kan derfor let følge med til bussens 100 khz. Derudover har den en maksimal konverteringstid på 7,5 µs. og kan derfor let opfylde kravene på en måling pr. sekund. Opsætning AD-converteren kan sættes op ved at sende konfigurations og setup-bytes til den. Det kan indstilles hvad den skal måle i forhold til, hvilke kanaler, der benyttes, om den skal skifte mellem de forskellige kanaler etc. Konverteringsresultatet bliver sendt i to bytes. Første byte indeholder 4 høje bits og de 4 mest betydende bits. Den næste byte indholder de 69

74 KAPITEL 7. MODULDESIGN AF ØVRIGT HARDWARE 8 mindst betydende bit. Da luftfugtigheden er mellem 0 og 100% og 1% opløsning, er de 4 mindst betydende bits ikke nødvendige, derfor samles de 4 mest betydende bits fra hver byte til et enkelt byte, der indeholder konverteringsresultatet. Grunden til at de 4 mindstbetydende bits ikke er nødvendige, er at der ikke er behov for så høj opløsning. En illustration af de to bytes, der samles, ses på fig på side 116. Efter de 8 bits er samlet, skal de regnes om til en luftfugtighed, dvs. et tal på mellem 0 og 100. Dette gøres i software. Der kan læses mere om dette i afsnit på side Opkobling af sensorer Temperatursensoren og AD-converteren opfattes som eksterne enheder fra klimaovervågningssystemet, der således kobles på et stik på systemet. Derfor inkluderes eldiagrammet for de valgte sensorer ikke på det samlede eldiagram i appendiks C men er vist her i forbindelse med de forrige afsnit om sensorerne. Diagrammet på figur 7.9 viser sensorerne koblet op. Mærkningerne SDA og SCL på diagrammet skal kobles på de tilsvarende mærkninger på eldiagrammet i appendiks C. Figur 7.9: Diagram over I 2 C-sensorer EEPROM Til at lagre konfigurations- og måledata, samt alarmloggen anvendes en EEPROM af typen 24LC256, som blev valgt i afsnit 6.3. Denne kreds kommunikerer med et I 2 C- interface, derfor kobles den på samme bus som sensorerne. Databladet for kredsen findes som EEPROM_24lc256.pdf på bilags-cd en. Ekstern adressering For at vælge EEPROM en på I 2 C-bussen skal der sendes en kontrolbyte, som indeholder dens I 2 C-adresse. De første fire bits i denne adresse er %1010 for alle EEPROMs af 70

75 7.3. I 2 C-BUS denne type. De tre næste bits bestemmes af tre eksterne adresseben på kredsen. Dette giver mulighed for at have 8 ens EEPROM kredse, hvormed systemets hukommelse til målinger kan udvides, ved blot at koble flere hukommelseskredse på I 2 C-bussen. Det sidste bit i kontrolbyten bestemmer, hvorvidt der skal skrives til eller læses fra EE- PROM en. Da der i systemet kun er behov for en enkelt EEPROM-kreds, kobles alle tre adresseben på den til 0 V, og den får dermed adresse % eller $A0 ved skrivning og $A1 ved læsning. Intern adressering Når EEPROM kredsen er valgt, ved at sende den rigtige kontrolbyte over I 2 C-bussen, skal det desuden vælges, hvilken adresse der skal skrives til, eller læses fra, internt i kredsen. Kredsen indeholder 256 kbits hukommelse, og adresseres på byte niveau, hvilket vil sige at den indeholder 32 kbytes svarende til 2 15 forskellige adresser. Det giver et adresseområde som går fra $0000 til $7FFF. En adresse kan altså angives med 15 bits. For at sætte EEPROM ens interne adressecounter, skal der sendes to adressebytes, hvor den første indholder de 7 mest betydende adressebits. Den næste byte indeholder de 8 mindst betydende adressebits. De første to bytes som skrives til EEPROM en vil altid blive opfattet som adressebytes. Se figur 7.10 for en illustration af hvordan adressecounteren sættes. Figur 7.10: Adressering i EEPROM (fra EEPROM_24lc256.pdf) Skrivning For at lave en skriveoperation sendes en kontrolbyte med EEPROM ens adresse hvor den sidste bit er nul. Derefter sendes de to adressebytes, for at vælge hvilken adresse der ønskes at skrive til. Endelig sendes den databyte, som skal skrives på adressen, og der afsluttes med en stop-betingelse. Kredsen lagrer de modtagne data i en buffer, og begynder så skrivningen når stop betingelsen modtages. Det er muligt at skrive op til 64 bytes ad gangen, med et såkaldt page write. Det gøres ved at sende flere databytes lige efter den første, i stedet for stop betingelsen. Ligesom ved skrivning af en enkelt byte, begynder skrivningen internt i EEPROM en først når stopbetingelsen modtages. Hukommelsesområdet er delt op i såkaldte pages af 64 bytes, som starter ved adresser der er delelige med 64 (0, 64, ). Det er muligt at skrive en hel page i en enkelt skriveoperation. Til gengæld er det kun muligt at skrive inden for den samme page i én skriveoperation. Det vil sige at man godt kan skrive i adresserne fra 0 til 63 på én gang, men ikke fra 32 til 95, fordi de er fordelt over to forskellige pages. Dette 71

76 KAPITEL 7. MODULDESIGN AF ØVRIGT HARDWARE betyder at den software som skal håndtere skrivningen til EEPROM en enten skal skrive en enkelt byte ad gangen, hvilket er forholdsvist ineffektivt, eller den skal tage højde for hvor disse pages starter og slutter, og skrive så meget ad gangen som muligt. Når der sendes en stop-betingelse, som får EEPROM en til at begynde skrivningen af data, vil det vare op til 5 ms før den er færdig, og dermed kan lave andet. For at kontrollere om der er en igangværende skriveoperation, sendes en kontrolbyte til EEPROM en, hvor den sidste bit er lav for at indikere en skriveoperation. Hvis EEPROM en er igang med en skriveoperation, vil den ikke svare med et acknowledge signal, som den normalt bør. Dette kan anvendes til at kontrollere at EEPROM en er færdig med at skrive, før en ny læsning/skrivning påbegyndes. Læsning Når der læses fra EEPROM en skal adressecounteren først sættes til den adresse der skal læses fra. Dette gøres ved at starte en skriveoperation, men afslutte den når de to adressebytes er sendt. Det resulterer i at der ikke skrives nogen data, men adressecounteren sættes til den ønskede adresse. Derefter sendes en kontrolbyte hvor den sidste bit er høj, for at indikere en læseoperation. Derefter vil EEPROM en sende de data som står på den pågældende adresse. Bus masteren kan derefter læse det antal bytes der ønskes. EEPROM en vil sende indholdet af de enkelte adresser sekventielt, så længe masteren laver acknowledge for at indikere at der ønskes flere data. 7.4 Sekund-generator For at imødekomme kravet om et ur i systemet, skal der laves et kredsløb, der giver et interrupt, hver gang et veldefineret tidsrum er forløbet. Da kravspecifikationen i afsnit på side 17 angiver at der skal kunne foretages målinger ned til én gang i sekundet, vælges det, at kredsløbet skal generere ét interrupt i sekundet. Oscillatortype For at overholde kravet om en afvigelse på højst ét sekund per døgn, vælges en oscillator baseret på et krystal, da temperaturafhængigheden er mindre end på RC- og LC-baserede oscillatorer. Da der ikke findes krystaller der svinger med en frekvens på 1 Hz, er det nødvendigt at vælge et hurtigere krystal og derefter dividere frekvensen ned til 1 Hz. Det langsomst svingende krystal, der er til rådighed i laboratoriet, svinger med en frekvens på Hz, hvilket vil sige at frekvensen skal deles med 2 15 for at ende på 1 Hz. Interrupt-styring og frekvensdeling Da interruptet kun skal finde sted indtil CPU en sender et IACK*, anvendes en flip-flop der resettes af IACK*. Den valgte flip-flop hedder 74HCT73 og indeholder to flip-flops der trigger på den nedadgående flanke, hvilket er nødvendigt når IACK* er aktivt lav. Da 72

77 7.4. SEKUND-GENERATOR det kun er den ene indbyggede flip-flop der benyttes, kan den anden bruges til at dividere frekvensen med to. Der er ikke en kreds til rådighed der umiddelbart kan dele med 2 15, men en 74HC4060 kan dele med Kombineret med den ekstra flip-flop i den benyttede 74HC73 er der nu mulighed for at dele frekvensen fra oscillatorkredsløbet med Opkobling af 74HC4060 binærtælleren 74HC4060 binærtælleren opkobles som vist på figur Svingningskredsen, der er en Pierce oscillator, befinder sig yderst til venstre og er opbygget efter en anbefaling i databladet til 74HC4060. Modstandene skal jf. (Wilmott 2004) dimensioneres som følger: R 10 = 15 MΩ, R 9 = 680 kω, mens C 7 jf. databladet til 74HC4060 skal være 100 pf. C 8 skal beregnes ud fra følgende formel, fra (Sörensen 2004): Formlen kan omskrives til følgende: C load = C 7 C 8 C 7 +C 8 +C S (7.1) C 8 = C 7(C S C L ) C L C S C 7 (7.2) I ovenstående formel repræsenterer C load krystallets belastningskapacitans, der for komponentudleveringens Hz krystaller er på 12,5 pf. C S repræsenterer spredningskapacitansen i svingningskredsløbet, der anslås at være på 6 pf. Med heri regnes kapacitansen på 74HC4060 s CLK-ben som ifølge databladet er på 5 pf. Hermed kan C 8 udregnes: C 8 = 100p(6p 12,5p) = 6,95 pf (7.3) 12,5p 6p 100p Opkobling af 74HCT73 For at bringe den ene flip-flop til at dele frekvensen med to, skal dens udgang Q skifte tilstand på hver nedadgående flanke på CLK-benet. Det gøres ifølge databladet ved at tilslutte J-, K- og CLR*-benene til +5 V, mens udgangssignalet hentes på Q-benet. Se evt. figur 7.11 Den anden flip-flop skal kobles så interrupt-signalet ophører når et IACK* finder sted. Dette opnås ved at sende signalet fra Q-benet på ovennævnte flip-flop ind på CLKbenet. Endvidere skal J tilsluttes +5 V og K tilsluttes stel. IACK3* fra CPU en tilsluttes flip-floppens CLR*-ben. Udgangssignalet på Q* sendes derefter til interrupt-encoderens IRQ3* Test Oscillatoren til at generere interrupt hvert sekund kan testes ved at måle med et oscilloskop på udgangen af den kreds, der foretager den sidste neddeling af clockfrekvensen. 73

78 KAPITEL 7. MODULDESIGN AF ØVRIGT HARDWARE 0 C7 C8 Y3 R9 CRYSTAL R10 0 5V OSC OSC CLK RST VCC 74HC4060 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q12 Q13 Q V 5V 14 3 J K 1 2 CLK CLR 74HCT73 Q Q V IACK'-UR* J K 5 6 CLK CLR 74HCT73 Q Q 9 8 IRQ-UR* Figur 7.11: Kredsløb som genererer ét interrupt per sekund Her kan måles et 1 Hz firkantsignal. Der kan ikke umiddelbart testes efter flipflop en, der sidder på indgangen til interruptdekoderen, da processoren ikke genererer IACK*, når dens stausregister ikke er sat op til at reagere på interrupts. Testresultater På figur 7.12 ses et skopbillede af clocksignalet til sekundinterruptet. Som det ses er der tale om en 1 Hz firkant. Figur 7.12: Sekundclock 7.5 RS-232 Til kommunikation mellem klimaovervågningsenheden og PC benyttes en RS-232 forbindelse. Interfacet til en sådan forbindelse er på de fleste nyere PC ere et 9-pins D-sub stik som vist på figur Figur 7.13: 9-pin sub-d stik til RS-232 forbindelse, set ind i en PC De 9 nummererede pins har følgende forbindelser: 74

79 7.5. RS-232 Pin Forbindelse Funktion In/Out 1 DCD Data Carrier Detect In 2 RD Recieve Data In 3 TD Transmit Data Out 4 DTR Data Terminal Ready Out 5 SG Signal Ground - 6 DSR Data Set Ready In 7 RTS Request To Send Out 8 CTS Clear To Send In 9 RI Ring Indicator In Tabel 7.10: Forbindelser i 9-pin D-sub stik Ind- og udgangene på en RS-232 forbindelse er defineret som set fra en terminal, der er forbundet til et modem. I forklaringerne herunder er disse termer bibeholdt på trods af at forbindelsen brugt til kommunikation mellem hardware og PC nærmere kan beskrives som terminal til terminal, kilde: (Putman 1987)[kap. 3]. Data Carrier Detect (DCD) Hvis RS-232 forbindelsen er forbundet til et modem bruges DTD til at gøres opmærksom på at der er opnået en fjernforbindelse, når modemet har ringet op. Recieve Data (RD) På denne forbindelse modtages data fra modemet. Transmit Data (TD) Herfra sendes data fra terminalen til modemet. Data Terminal Ready (DTR) Denne forbindelse asserteres, når terminalen er tændt og klar for at indikere at der er en forbindelse på RS-232. Signal Ground (SG) forbindelsen. Referencen for de signaler der sendes og modtages over RS-232 Data Set Ready (DSR) Svarer til DTR blot set fra modemet. DSR bliver altså asserteret, når modemet er tændt og klar. Request To Send (RTS) Asserteres af terminalen, når denne er klar til at sende data. Clear To Send (CTS) CTS er modemets svar på terminalens RTS. Når modemet er klar til at modtage data fra terminalen asserteres CTS. Terminalen sender ikke data før den modtager dette signal på CTS. Ring Indicator (RI) RI kan bruges af modemet til at indikere et indkommet opkald. 75

80 KAPITEL 7. MODULDESIGN AF ØVRIGT HARDWARE Terminal - Terminal Når man forbinder to terminaler over en RS-232 forbindelse, modificeret kablet til forbindelsen således, at modemet bliver unødvendigt. TD bliver forbundet til RD, RTS til CTS og DTR til DSR og DCD. På denne måde opfatter en terminal den anden som et modem, og kommunikationen kan derfor foregå som beskrevet ovenfor. Denne komunikation kaldes også NULL-modem. Bit-stream for RS-232 Når der sendes data over RS-232 forbindelsen (på TD og RD), sendes bit efter hinanden. For at sikre at der modtages de data, der sendes og kun disse, skal de sendes på en bestemt måde. Princippet i dataoverførslen af en karakter er vist på figur Det første, der sendes, er en startbit med værdien 0, der indikerer starten af karakteren. Herefter følger selve karakteren. På figuren er vist ASCII-værdien af et V. Den mindst betydende bit sendes først og den mest betydende sidst. Herefter kommer en paritetsbit, hvis værdi er afhængig af antallet af 0 er og 1 er i karakteren. Denne bit kan bruges til kontrol af om karakteren er korrekt modtaget. Til sidst sendes en stopbit med værdien 1 for at indikere slutningen af karakteren. ame 7-bit ASCII LSB MSB +12V -12V s bit T0 T1 T2 T3 T4 T5 T6 T7 T8 T9 T10 Figur 7.14: ASCII V sendt over RS-232, kilde (Putman 1987)[kap. 4] Når modtageren får startbittet ved tiden T0 synkroniseres den til at modtage midt i afsendelsen af hver bit, dvs. til tiderne T1, T2... På denne måde sikres det at RD har opnået den værdi, der sendes, og det risikeres ikke at læse på indgangen, når denne er ved at skifte tilstand. Styring af RS-232 forbindelse (ACIA) Da et mikroprocessorsystem anvender parallel kommunikation internt, bliver der brug for et kredsløb, der kan omsætte de data, der skal sendes til serielle sekvenser og fortolke de data, der modtages serielt til et parallelt signal, som mikroprocessoren kan arbejde med. Til dette bruges en ACIA, for hvilken, der er vist et blokdiagram på figur De fleste ind og udgange på diagrammets højre side genkendes, som de forbindelser, der findes på 9-pin stikket til RS-232 forbindelsen. Desuden har ACIA en et antal forbindelser, som gør det muligt for mikroprocessorsystemet at styre ACIA en og kende dennes status. 76

81 RS-232 D0-D7 *,. bus ssor er nsmitter : $; TxD E CS0 CS1 CS2 R /W RS < >= #$ %!&'&( ) * +, on -., s and % / ers bus er em!" : ; RxD DTR DSR - : - DCD Figur 7.15: Blokdiagram for ACIA CTX og CRX CTX og CRX er clockindgange, hvorpå der sættes en ekstern pulsgenerator, som bruges af ACIA en til timing af dens operationer. For eksempel når der modtages data, skal ACIA en være i stand til at læse præcist midt i perioden for hver bit, der modtages. Clocken har som regel en frekvens på 16 gange baud-raten, for at sikre præcis timing. E E er et clocksignal fra mikroprocessoren som sætter ACIA en i stand til at synkronisere dataudvekslinger med mikroprocessoren. CS0 - CS2* Da en mikroprocessor kun er i stand til at kommunikere med én ekstern enhed ad gangen, bruges Chip Select (CS) af processoren til at vælge ACIA en, når der skal kommunikeres med denne. ACIA en har tre CS indgange, og kredsen vælges når CS0 og CS1 er høje og CS2* er lav. IRQ* Interrupt ReQuest bruges til at starte en interruptrutine i mikroprocessorsystemet, for eksempel, når der er modtaget en karakter. Under hvilke omstændigheder IRQ* asserteres, bestemmes ved at skrive til kontrolregistret. RS - R/W* Register Select bruges sammen med R/W* til at tilgå ACIA ens interne registre. Når RS er høj, vælges sende- og modtageregistrene, hvor der vha. R/W* vælges om der skrives til senderegistret eller læses fra modtageregistret. Når RS er lav kan der vha. R/W* skrives til kontrolregistret eller læses fra statusregistret. Desuden kan man på ACIA en indstille egenskaberne for de karakterer, der sendes over RS-232 forbindelsen. Det drejer sig om antallet af databit, om der skal bruges én eller flere paritetsbit, reglerne for paritetsbit ens værdi og antallet af stopbit. 77

82 KAPITEL 7. MODULDESIGN AF ØVRIGT HARDWARE Spændingsniveauer ACIA en og mikroprocessoren arbejder med TTL-spændingsnivaeuer, hvor logisk 0 er 0V og logisk 1 er 5V. På en RS-232 forbindelse er logisk 0 defineret som +12V og logisk 1 som -12V. Derfor benyttes RS-232 drivere og recievere til at sende og modtage RS-232 signalerne, og adskille dem fra TTL niveauerne på ACIA en. Driveren er en inverteret AND gate og recieveren en inverter, som vist på figur RS-232 TTL TTL RS-232 Figur 7.16: Driver og reciever til at adskille ACIA ens TTL niveauer og RS-232 spændingerne I tabel 7.11 ses sammenhængen mellem TTL- og RS-232-spændinger. Logisk niveau Spænding TTL Spænding RS V -12V 0 0V +12V Tabel 7.11: Spændingsniveauer for TTL og RS-232 Det ses af tabellen, at inverteringen, der er markeret på symbolerne for komponenterne, skal forstås som en invertering af spændinger. Dette er nødvendig for at opnå det samme logiske niveau for forbindelsen på ind- og udgang. Transmissionshastighed Transmissionshastigheden indstilles i ACIA en til en standardværdi vha. en baudgenerator på ACIA ens clockben. Begge terminaler på RS-232 forbindelsen skal være indstillet til samme transmissionshastighed for at sikre korrekt læsning af de data, der sendes over forbindelsen. Transmissionshastigheden beskrives som mulige bit per sekund (benævnes også baud). Med en hastighed på 9600 baud er tiden det tager at sende en streng på 30 karakterer (svarende til en streng med måledata, som blev beskrevet i kravspecifikationen, afsnit på side 18) dermed mindst: t = 30 10bit 9600baud t = 300 sek = 0,031sek (7.4) 9600 Indeholder hukommelsen 1000 målinger, vil alle målingerne hurtigst kunne udskrives på: t min = ,031sek = 31sek (7.5) 78

83 7.5. RS-232 Komponentvalg Der opbygges to uafhængige RS-232 forbindelser til systemet. Forbindelsen til debugger/monitor softwaren, skal placeres på en bestemt adresse og desuden ikke bruge interrupt, da TS2MON poller på forbindelsen. Den anden forbindelse skal bruges til systemets PC-forbindelse, og i denne forbindelse skal systemet lave en interruptbehandling, når der modtages fra fjernbrugeren. Denne opdeling er sket med udgangspunkt i at debugger/monitoren ikke anses for at være en del af systemet, når dette er færdigt og dermed skal behandles særskilt. ACIA Til rådighed i laboratoriet er en ACIA af typen S68B50, som er en ACIA designet til M68k mikroprocessorfamilien, hvorfor denne er et naturligt valg til systemet. Baudgenerator Til at generere Baud-frekvensen er valgt en oscillator MCO1610B med en frekvens på 2,4576 MHz. Ved at dele med 16 2 opnås en frekvens på de ønskede 9600 Hz. Deling med 16 realiseres i selve ACIA en, der kan sættes op til at dele med 1, 16 eller 64. Derfor skal clocksignalet deles med yderligere 16 og dette realiseres ved hjælp af en binær tæller, 74HC4040, der sættes op til at dele med 2 4. Line driver De absolut nødvendige forbindelser der skal være over RS-232 forbindelsen er Tx, Rx samt stel. Dermed er der kun en forbindelse, der skal modtages på, og en forbindelse, der skal sendes over, pr. RS-232 forbindelse. Som linedriver og -reciever vælges derfor en MAX232A, der realiserer 2 drivere og 2 recievere. Kredsen kræver kun 0V og 5V DC, som resten af systemet benytter. De højere positive og negative spændinger genererer kredsen ved hjælp af to eksterne 100 nf kondensatorer. De øvrige forbindelser til RS232- interfacet bruges ikke og trækkes derfor til deres aktive spændingsniveauer, således at ACIA en altid vil sende karakterer over forbindelsen uanset om den er tilsluttet en PC. El-diagram På figur 7.17 på den følgende side ses det, hvordan de valgte komponenter til de to RS-232 forbindelser skal være. Kontrol- og statusregistre Kontrol- og statusregistrene bruges til at indstille ACIA en og til at kontrollere tilstanden, den er i. Disse tilgås ved hjælp af RS og R/W*. I tabel 7.12 på side 81 er vist betydningerne 79

84 KAPITEL 7. MODULDESIGN AF ØVRIGT HARDWARE Y2 8 OUT ACIA-CLOCK U12 10 CLK 11 RST 16 0 VCC 5V 74HCT4040 Q1 Q2 Q3 Q4 Q5 Q6 Q7 Q8 Q9 Q10 Q11 Q RX-DM TX-DM E CS-ACIA-DM* A0 R/W* IRQ-ACIA-PC* CS-ACIA-PC* M68k databus A0 5V 5V E A U14 E CS0 CS1 CS2 RS RXDATA CTS DCD RXCLK TXCLK R/W* 13 R/W 6850 U16 E CS0 CS1 CS2 RS RXDATA CTS DCD RXCLK TXCLK R/W* 13 R/W 6850 TXDATA RTS IRQ D0 D1 D2 D3 D4 D5 D6 D7 TXDATA RTS IRQ D0 D1 D2 D3 D4 D5 D6 D D0 D1 D2 D3 D4 D5 D6 D7 D0 D1 D2 D3 D4 D5 D6 D7 C3 100n C4 100n C5 C6 100n 100n U15 R1IN R2IN T1IN T2IN C1+ C1- C2+ C2- V+ V- MAX232 R1OUT R2OUT T1OUT T2OUT RX-PC TX-PC Figur 7.17: El-diagram over RS-232 forbindelserne af de enkelte bits i de forskellige registre, samt hvordan kontrolregistret skal sættes op til PC-forbindelsen. Implementering Debugger/monitoren sætter selv RS-232 forbindelsen på $ og $ op til ikke at bruge IRQ* overhovedet, da TS2MON poller på forbindelsen. For at kunne bruge PC-forbindelsen skal ACIA en til dette formål sættes rigtigt op. På adresse $ skrives i forbindelse med initialisering af systemet en byte som vist på den midterste tabel 7.12 på modstående side. Desuden skal systemet sættes op til at kontrollere statusregistret, når der kommer et interrupt på det tildelte autovektorinterrupt. Se evt. afsnit 6.5 på side 47 for detaljer herom. Når systemet kører og der skal sendes over PC-forbindelsen, skal kontrolregistret sættes op, så ACIA en ikke genererer et interrupt, når en karakter modtages. Dette forhindrer at flere strenge forsøges afsendt samtidigt, da systemet dermed ikke vil reagere på kommandoer, der modtages mens der sendes. Med RS-232 forbindelsen implementeret, som den sidste hardwareenhed, er næste skridt at designe den software, som skal styre mikroprocessorsystemet og kommunikere med hardwaren. 80

85 7.5. RS-232 RS Control Send data R/W* 1 Status Modtag data Kontrolregister CR0 CR1 CR2 CR3 CR4 CR5 CR6 CR CTX og CRX deles med 16 8 databit, 1 stopbit, ingen paritetsbit RTS og TD- IRQ* deaktiv RD IRQ* aktiv Statusregister SR0 SR1 SR2 SR3 SR4 SR5 SR6 SR7 RD TD DCD CTS Frame Modtager Paritets IRQ Register fuld register tomt error overrun fejl Tabel 7.12: Øverst vises hvordan ACIA ens registre tilgås. Midterst forklares kontrolregistret. Nederst forklares statusregistret 81

86 Del IV Software 82

87 Kapitel 8 Programdesign Softwaredesignet opdeles i tre kapitler: Programdesign, Procesdesign og Moduldesign. Ideen er, at programmet deles op i processer. En proces er en programdel, som kan køre uafhængigt af de andre processer. Det eneste processerne har til fælles er datalagrene. For at kunne opdele programmet i processer, skal programmets funktionaliteter først identificeres hvorefter opdelingen i processer kan foretages. Efter at programmet er delt op i selvstændige processer, opdeles hver proces i moduler. I moduldesign skal de enkelte funktioner, der skal til for at kunne implementere det enkelte modul i den givne proces, beskrives. 8.1 Symbolforklaring I de følgende afsnit gøres brug af to typer diagrammer, til at illustrere hvordan softwaren skal opbygges. I dette afsnit forklares hvordan disse diagrammer skal læses. Dataflowdiagram Dataflowdiagrammer anvendes til at illustrere hvilke data der udveksles imellem de forskellige moduler i softwaren. De symboler som anvendes ses på 8.1. Figur 8.1: Symboler i dataflowdiagrammer Start/slut eller ender. En kasse på et dataflowdiagram angiver et endepunkt, hvor data enten opstår Modul En cirkel på et dataflowdiagram angiver et modul, som foretager en behandling af de modtagne data, og sender dem videre. 83

88 KAPITEL 8. PROGRAMDESIGN Dataflow Pile angiver de data som flyttes. Teksten på pilen fortæller hvilken type data der er tale om. Lager To parallelle streger angiver et lager, hvor data gemmes. Flowchart Til at illustrere hvordan programafviklingen i de enkelte moduler og funktioner foregår, anvendes flowcharts. Disse giver mulighed for at angive hvilken sekvens de forskellige operationer skal udføres i. På figur 8.2 ses de symboler som vil blive anvendt på flowcharts. Start / slut Databehandling Beslutning Ja Nej Figur 8.2: Symboler i flowcharts Start/slut En afrundet kasse angiver hvor programflowet starter eller slutter. Databehandling En kasse på et flowchart angiver at der udføres en form for operation, som for eksempel kunne være en behandling af data. Beslutning En rombe på et flowchart angiver, at der sker en beslutning, som f.eks. kunne afhænge af værdien af en variabel. Der vil typisk være to pile ud af en sådan beslutning. Ved hver pil angives hvilket valg, der resulterer i, at denne pil skal følges. 8.2 Funktionaliteter Funktionaliteter som kræves af systemets software, i henhold til kravspecifikationen vil blive gennemgået i dette afsnit. I dette afsnit behandles de overordnede funktionaliteter. Den første overordnede funktionalitet, der kan identificeres i kravspecifikationen, er, at softwaren skal være i stand til at indsamle data og gemme dem i et lager. Endvidere er der krav om en funktionalitet som muligør at brugeren kan konfigurere systemet. Der kan også læses i kravspecifikationen at systemmet skal kommunikere med brugeren via et display. Derfor skal softwaren indeholde en funktionalitet som muliggør at skrive på et sådant display. Da det i flere tilfælde skal være muligt at gemme et tidspunkt, skal der også implementeres et ur. Da er stillet krav om en funktionalitet som muliggør kommunikation med en PC, skal der implementeres en funktionalitet i softwaren, der kan håndterer en sådan kommunikation. Der skal endvidere være en funktionalitet som kan gemme oplysninger om eventuelle alarmer. 84

89 8.3. PROCESOPDELING 8.3 Procesopdeling For at danne et bedre overblik over softwaren, opdeles funktionaliteterne i tre processer. De tre processer, som softwaren bliver inddelt i er: 1. Menusystem 2. Sekundhåndtering 3. PC-grænseflade Menusystemet er den proces, som sørger for, at displayet hele tiden viser de rigtige informationer. Det vil sige, at Menusystemet skal kunne tage input fra brugeren i form af tastetryk, og bruge det til at navigere rundt i menuen, og lave eventuelle ændringer af indstillinger. Sekundhåndteringen sørger for at der hvert sekund bliver udført en række opgaver. Opgaverne i Sekundhåndtering består af at opdatere systemets ur, aktivere en opsamling af data fra sensorerne kontrollere for en eventuel alarm og skrive i alarmloggen, hvis det er relevant. PC-grænsefalde er den proces som håndterer kommunikation med PC. I tabel 8.1 er der en oversigt over hvilke moduler de tre processer indeholder. Proces Menusystem Sekundhåndtering PC-grænseflade Modul Konfiguration Alarmlog Datavisning Hovedmenu Trykfordeler Skriv til display Dataopsamling Ur Alarm Komandofortolker Hent og formatér data Slet data Send streng Tabel 8.1: Procesoversigt Procesgrænseflader Processen Menusystem poller hele tiden efter et tasteinput fra brugeren, som skal bruges til at navigere i menuen. Menusystems grænseflade til omverdenen er tasterne og displayet. De to andre processer bliver aktiveret ved hjælp af interrupt. Sekundhåndtering bliver aktiveret hvert sekund af interrupt. Sekundhåndterings grænseflade til omverdenen er systemets sensorer. PC-grænsefladen bliver aktiveret af et interrupt der indtræffer når en PC sender en kommando til systemet. PC-grænsefladens grænseflade til omverdenen er den PC som kommunikerer med systemet. Processernes interne grænseflader er de fælles lagre. På figur 8.3 på side 87 ses et 85

90 KAPITEL 8. PROGRAMDESIGN dataflowdiagram over softwaren, som den ser ud efter denne opdeling af systemets tre processer. De enkelte moduler vil blive gennemgået i de efterfølgende afsnit. På figur 8.3 på modstående side ses det at grænsefladerne mellem de tre processer udgøres af de fælles datalagre. Lager hvor målingerne skal gemmes, Alarmlog hvor alarmloggen gemmes, Tid hvor den aktuelle tid gemmes og Indstillinger hvor systemets indstillinger gemmes. 86

91 u # 8.3. PROCESOPDELING tag mando PC * té r ) sning Lager og Indstillinger ( & * deler t t og tion rm Opsamling " "! madata UR le indstillinger $ tid % '& tid p & fugt Æ ger Figur 8.3: Dataflowdiagram for systemsoftware 87

92 Kapitel 9 Procesdesign Formålet med dette kapitel er, at designe de enkelte processer som sekventielle programmer. Dette sker umiddelbart uden hensyntagen til de andre processer i programmet. Da der ikke er nogen direkte grænseflader imellem processerne, bør dette ikke være et problem. De eneste grænseflader mellem de tre processer består af de fælles datastrukturer. Hver proces opdeles i moduler, og for hvert modul beskrives hvilket input det skal have, hvordan det skal behandle dette input, og hvilket output der skal returneres. Som den sidste del af procesdesignet specificeres de fælles datastrukturer, således at der enighed om hvad disse indeholder inden moduldesignet påbegyndes. 9.1 Menusystem Processen menusystem har til opgave at håndtere systemets brugergrænseflade. Ifølge kravspecifikationen skal menusystemet være opbygget som beskrevet i afsnit på side 20. Al kommunikation med tastaturet og displayet foregår igennem menusystemsprocessen. På figur 9.1 ses et dataflowdiagram over menusystemsprocessen. Menusystemet er den del af programmet, som ikke bliver aktiveret af et interrupt. Det vil sige, at det kører, når systemet ikke har andet at lave. Kernen i det er, at der hele tiden polles efter tastetryk. Når der kommer et tastetryk, skal Trykfordeler sørge for, at dette tryk bliver sendt videre til det rigtige modul. Når det pågældende modul så har reageret på dette tastetryk, sender det en tekststreng til modulet Skriv til display, som så sørger for at sende strengen ud på displayet. Herefter polles igen efter tastetryk. Udover tastetryk skal der også polles efter hvorvidt uret har ændret sig. Dette har to formål, dels at opdatere displayet, når der bliver taget nye målinger, mens datavisningen er aktiv. Trykfordeler Modulet Trykfordeler, modtager alle de tastetryk der kommer. Det skal så, ved hjælp af en menupositionsvariabel, holde styr på hvor i menusystemet brugeren befinder sig, og dermed hvilket modul tastetrykket skal sendes videre til. 88

93 + Æ 9.1. MENUSYSTEM 6!7 8 9: <!5= 9 ger!!5% #$ deler u sning t t "#$&% '( tion le indstillinger ) *. /4, , 0 - / -./, og 8% #$ mer Lager og!; uelle må linger Indstillinger Figur 9.1: Dataflowdiagram over menusystemsproces Skriv til display Dette modul har til opgave at kommunikere med displayet. Dets input er de tekststrenge der skal skrives på displayet. Dets output består af at de pågældende strenge bliver sendt til displayet, så brugeren kan se dem. Modulet skal ikke behandle strengene, men blot sende dem videre til displaycontrolleren. Hovedmenu Hovedmenumodulet skal sætte brugeren i stand til at vælge mellem konfiguration- og alarmlogmenuerne. Når en af disse vælges skal hovedmenuen sende brugeren videre til den valgte menu. Som input tager hovedmenumodulet tastetryk fra trykfordeleren i form af en menupositionsvariabel og et taste-id. Derudfra kan hovedmenuen opdatere displayet med enten Konfiguration eller Alarmlog. Når der sendes et [enter] sendes variablerne videre til det valgte modul. Ved [esc] startes datavisning. Datavisning Datavisning er det modul, der viser aktuelle målinger, gennemsnit og ekstrema på displayet. Disse værdier beregnes løbende af sekundhåndteringen, hentes af datavisningen i hukommelsen og sendes til displayet. Datavisningen tager, udover de aktuelle data fra hukommelsen, en menupositionsvariabel og et tastetryk fra Trykfordeleren, så Datavisningen kan afgøre hvilke af de aktuelle data, der skal sendes til displayet. 89

94 3 KAPITEL 9. PROCESDESIGN Konfiguration Konfigurationsmodulet skal sætte brugeren i stand til at ændre indstillingerne i klimaovervågningssystemet. På figur 9.2 er vist hvordan modulet skal ændre en indstilling på baggrund af en menupositionsvariabel og et tastetryk. Variablen identificerer den indstilling, som konfigurationsmodulet skal ændre, mens tastetrykket fortæller i hvilken retning variablen skal ændres. Når der tastes[enter] gemmes indstillingen og ved tryk på [esc] returneres fra konfigurationsmodulet uden at gemme indstillingen.! t indstilling t væ! ""#%$ té r # 4 indstilling Ny indstilling mel indstilling & t Indstillinger Æ tidig [<] / [>] ' 5" indstilling +, er] +,.-/ Ny indstilling ( )* é r Figur 9.2: Dataflowdiagram for konfigurationsmodulet Figur 9.2 viser hvordan en indstilling generelt ændres. Da de forskellige måder at ændre indstillinger på er forskellige fra indstilling til indstilling, skal konfigurationsmodulet starte forskellige Ændre midlertidig indstilling -rutiner ud fra menupositionsvariablen. For ændring af hukommelsestilstand og måleinterval skal piletasterne skifte mellem et antal valgmuligheder, hvor der for dato, tid og grænser skal skiftes mellem tal i et defineret område i henhold til kravspecifikationen. Hver gang et tastetryk er blevet behandlet, skal den midlertidige indstilling desuden formateres til displaytekst og sendes til displayet. Alarmlog Alarmloggen har til opgave at læse i lageret Alarmlog og at videresende data til brugeren. Som input tager den tasteinput, som den får fra Trykfordeler. Tasteinput bruges til at bestemme hvilke data brugeren efterspørger. Modulets output er en formateret tekststreng, som kan sendes til modulet Skriv til display. 90

95 9.2. SEKUNDHÅNDTERING Opsamling madata p & fugt M å rm UR! tid tid Lager og sstæ mpling uelle indstillinger Indstillinger Figur 9.3: Dataflowdiagram for sekundhåndteringsprocessen 9.2 Sekundhåndtering I forbindelse med hardwaredesignet blev der konstrueret en interruptgenerator, som laver et interrupt hvert sekund (se evt. afsnit 6.5 på side 47). Sekundhåndteringen skal udføre de funktioner, som skal ske automatisk hvert sekund uden indblanding fra brugeren, dvs. hver gang der kommer et interrupt på niveau 3. Først og fremmest skal uret opdateres hvert sekund, så systemet hele tiden kender den aktuelle tid. Desuden drejer det sig om at hente data fra temperatur- og fugtighedmålerne på I 2 C- bussen og behandle disse data. Når data er blevet hentet skal det tjekkes om de målte værdier overskrider de indstillede grænser. Hvis de gør, skal alarmen startes og når de ikke længere overskrider, skal den stoppes igen. I forbindelse med en alarm, skal alarmloggen startes med tidpunkt og alarmtype og kontinuert opdateres med hensyn til varighed og overskridelse. Desuden skal de målte data enten gemmes i hukommelsen eller sendes til PC iht. de indstillinger brugeren har foretaget. Desuden skal maksimum-, minimum- og gennemsnitsværdier til datavisningen beregnes og gemmes i RAM. På figur 9.3 er vist hvilke moduler sekundhåndteringsprocessen kommer til at indeholde for at opfylde de ønskede funktionaliteter og sammenhængen mellem dem. For at afvikle processen bliver de tre moduler kaldt efter hinanden, hvor det første, der sker, er, at uret opdateres, hvorefter måledata hentes og til sidst afvikles alarmmodulet. Ur Ur-modulet opdaterer tiden ved at lægge 1 sekund til systemets tid hver gang sekundhåndteringsprocessen køres. Modulet henter systemets tid fra hukommelsen opdaterer den og gemmer den på ny. 91

96 KAPITEL 9. PROCESDESIGN Dataopsamling Dataopsamlingsmodulet står for hentning og behandling af data fra temperatur og fugtighedssensorerne. Modulet tager temperatur- og fugtighedsmålingerne som input. De målte værdier sendes videre til en funktion, som genererer et alarmsignal, hvis der er en grænseværdi, der er overskredet. Værdierne sendes til en funktion, der beregner de gennemsnitsværdier, der skal bruges i datavisningen. Efterfølgende kontrolleres hvorvidt temperaturmålingen og luftfugtighedsmålingen er ekstremer. Værdierne sendes foruden til førnævnte funktioner også til en funktion, som gemmer måledata dem med det interval, der findes i indstillingerne. Indstillingerne indeholder desuden information om hvorvidt værdierne skal gemmes i systemets hukommelse eller om de skal sendes til PC. De data, der sendes til PC, indeholder for hver måling information om måletidspunktet. Gemmes værdierne i hukommelsen, vil funktionen lave et tidsstempel, som indeholder starttidspunkt før den første måling gemmes. Alarm Når dataopsamlingsmodulet sender et alarmsignal, er det alarmmodulets opgave at behandle alarmen ved at skrive alarmloggen. Når en ny alarm konstateres, skal modulet starte alarmloggen med starttidspunkt og alarmtype. Herefter skal modulet, hvert sekund alarmen stadig er til stede, opdatere loggen med varighed og maksimal overskridelse. Udover at skrive alarmloggen, bliver det nødvendigt, at opdatere en variabel i hukommelsen, når der er en alarm, som datavisningen kan bruge til at markere overskridelser, i forbindelse med visning af aktuelle målinger på displayet. 9.3 PC-grænseflade Dette afsnit beskriver hvilke funktionaliter PC-grænsefladen er blevet tildelt, modularisering af processen, modulspecifikationer og dataflow for processen. Tildelte funktionaliteter PC-grænsefladeprocessen er tildelt følgende funktionaliteter: Reaktion på skrevne kommandoer Formatering af data Overføring af data til PC Sletning af lagrede data 92

97 9.4. DATASTRUKTURER Inddeling i moduler Ud fra foregående afsnit kan processen opdeles i en række moduler, der kan realisere funktionaliterne fra sidste afsnit. Modtag streng Kommandofortolker Hent og formatér data Send streng Modulspecifikationer og dataflow I dette afsnit gennemgås hvad de forskellige moduler gør ved et givet input, ligesom dataflowet i hele processen kan ses på figur 9.4. Modtag streng Dette modul skal modtage de data, der sendes over PC-forbindelsen og holde styr på disse data. Kommandofortolker Kommandofortolkeren skal, som navnet antyder, fortolke de modtagne data og udføre den kommando, der er modtaget. I forbindelse med sletning af data vil kommandofortolkeren gøre brug af det modul, som udfører samme opgave i dataopsamlingen. Hent og formatér data Dette modul kaldes af kommandofortolkeren, hvis der fra PC en udstedes en kommando som kræver at der hentes og formateres data fra hukommelsen, hvilket dette modul gør. Send streng Dette modul kører i forlængelse af det forrige og tager den formaterede tekststreng og sender til PC en. 9.4 Datastrukturer Som grænseflader mellem de tre processer vedtages et sæt datastrukturer til at realisere lagrene i systemet. Opbygningerne af disse lagre, skal kendes i hele systemet for at kunne realisere dem som grænseflader mellem processerne. Desuden bestemmes formatet af de data, der skal sendes ud af systemet via PC-forbindelsen. I det følgende gøres brug af datatyper, som har bestemte størrelser. Det drejer sig om char, som er en 8 bit størrelse, int, som er 16 bit og long, som er 32 bit. Tid/Dato 00:00:00 Tiden angives som en long, der angiver antal sekunder siden kl. 93

98 KAPITEL 9. PROCESDESIGN PC! )#&% % $( * *! $#&% % '( ( tag Lager +, -.!" uelle m å linger té r mando mando Indstillinger Figur 9.4: Dataflow i PC-grænsefladen Målelager I målelageret skal der gemmes et tidsstempel, der angiver det tidspunkt, hvor den ældste måling er gemt. Hver måling gemmes i en struct, som indeholder følgende: struct maal_elm{ int temp; char fugt; } Hvert struct skal kunne tilgås med et målingnummer fra 0-999, hvor 0 er den ældste måling. Der skal desuden findes en variabel, hvor antallet af målinger er gemt, så det er muligt kun at læse de målinger ud, der er taget. Alarmlog Alarmloggen gemmes ligesom målingerne i structs. Opbygningen af en struct til en alarmlog er: struct alarmlog_elm{ long tid; char type; long varighed; int max_overskr; } For alarmloggen findes 10 af disse structs til i alt 10 alarmer. Disse nummereres 0-9, hvor 0 er den ældste. Der skal desuden være en variabel, der holder styr på antallet af skrevne alarmer. Aktuelle målinger For at kunne tilgå de aktuelle målinger, gennemsnitsværdier og ekstrema oprettes et array, int akt_maal[8] som indeholder disse data for både temperatur og fugtighed. Det vedtages på forhånd, hvilke data der skal gemmes i hvilke arrayets elementer: 94

99 9.4. DATASTRUKTURER 0 = temp 1 = fugt 2 = gns temp 3 = gns fugt 4 = max temp 5 = min temp 6 = max fugt 7 = min fugt Indstillinger Indstillingerne for systemet gemmes i en struct, som indeholder grænseværdier for temperatur og fugtighed, samt hukommelsesindstillinger. Structen kommer derfor til at se ud som følger: struct indstil_elm{ int temp_up; int temp_low; char fugt_up; char fugt_low; char huk_mode; char lager_int; } Måledata over PC-forbindelse I kravspecifikationen blev det bestemt, at udlæsning af måledata til PC skal foregå med strenge, der indeholder dato, tidspunkt, temperatur og fugtighed, hvor hver datatype er adskilt med et semikolon. Strukturen for en streng bliver dermed: YYYY-MM-DD HH:MM:SS;TTT,T;FFF; Der bliver dermed sendt én af ovenstående strenge for hver måling, der udlæses fra hukommelsen. 95

100 Kapitel 10 Moduldesign I dette kapitel designes hvert softwaremodul som et sæt funktioner, der løser modulets opgave. Modulerne er, ligesom i det foregående kapitel, ordnet efter de processor, modulerne hører under. Udover selve designet af de enkelte moduler, testes de også for at sikre deres funktion inden implementering i systemet Generelle funktioner I dette afsnit gennemgås et sæt funktioner, som ikke umiddelbart hører ind under de processer, der blev designet i systemdesignet. Disse funktioner udfører opgaver i forbindelse med formatering af data, indsætning af pauser, udskrivning af debuginformationer og kommunikation med I 2 C-controlleren delay Flere steder i systemets software, for eksempel i forbindelse med at sende strenge til displayet, bliver det nødvendigt at indsætte delays eller venteløkker. Til dette formål skrives en assemblerfunktion, der tager en tid i mikrosekunder som argument, og som mindst tager denne tid at afvikle. Funktionen void delay(long) er en løkke, der tæller ned på argumentet, indtil dette tal bliver negativt, hvorefter funktionen afsluttes. Ved at udregne hvor mange clockcycles hver instruktion i løkken tager, kan det udregnes hvor lang tid funktionen vil tage at afvikle, og dermed hvordan argumentet skal behandles. I delay tager løkken 4µs at gennemføre. Derfor foretages en shiftoperation på funktionensargumentet, så hver nedtælling af argumentet svarer til at trække 4µs fra. Dette betyder også, at delayet kun kan ændres i intervaller på 4µs. Desuden vil det tage mindst 10µs at gennemføre delayfunktionen én gang, da der før løkken, der tæller ned, er instruktioner, som tager argumentet af stakken og foretager ovennævnte shiftoperation. 96

101 10.1. GENERELLE FUNKTIONER Test For at teste delayrutinen skrives nedenstående program, der kalder delay med en tid på 1000 µs. main(void){ unsigned char *adr; adr = 0x800009; } *adr = 1; delay(1000); *adr = 0; Før og efter afviklingen af delay skrives til alarmbenet, så det sat højt under afviklingen af delay. Derved kan det måles på systemets alarmben hvor lang tid det tager at afvikle delay. Denne tid skal være mindst 1000 µs. Afviklingstiden af runtinen forlænges med den tid det tager at gennemføre rutinerne til at ændre alarmbenets tilstand. Testresultater Ved kompilering af programmet og måling på systemets alarmben med et oscilloskop, kunne det konstateres, som vist på figur 10.1, at afviklingstiden blev 1016 µs. Figur 10.1: Afviklingstiden af delay(1000) int2ascii For at kunne udskrive måledata og tidspunkter, er det nødvendigt med en funktion, der kan omsætte de datatyper værdierne lagres i (integers) til strenge i asciiformat. Disse strenge kan sendes over PC-forbindelsen og udlæses til displayet. Derfor laves en funktion med følgende prototype: 97

102 KAPITEL 10. MODULDESIGN char *int2ascii(char *streng, int tal, int plads, int decimaler) Som argument tager funktionen først en pointer til den streng, som resultatet ønskes gemt i. Derefter tages den værdi, der ønskes behandlet, antallet af elementer strengen skal bestå af og antallet af decimaler. Funktionen returnerer en pointer til den streng, der dannes. Argumentet plads angiver, som nævnt, længden på strengen uanset hvor meget plads, der er nødvendig for at skrive integeren som ascii. Ubrugte pladser fyldes som standard ud med mellemrum. Angives argumentet plads som et negativt tal bliver der skrevet 0 i ubrugte pladser i strengen. Herefter kontrolleres argumentet tal for at være en negativ værdi. Hvis det er det, skal der skrives - foran tallet i strengen, og herefter kan tallet behandles som en positiv værdi. Hvis tallet er nul bliver det behandlet særskilt og strengen 0 eller 0,0 skrives alt efter værdien af argumentet decimaler. Er tallet forskelligt fra nul omdannes integeren nu til en asciistreng, der skrives bagfra, dvs. mindstbetydende ciffer skrives først. Der indsættes komma, når det ønskede antal decimaler er skrevet og til sidst skrives fortegnet, hvis der er plads til det i strengen. Strengen bliver aldrig længere end plads, hvilket betyder at den returnerede streng ikke nødvendigvis indeholder hele det tal, der bliver gives som tal. På figur 10.2 på modstående side er vist et flowchart over funktionen. Test Funktionen, der genererer strenge af integers, kan testes ved at skrive et C-program, der kalder int2ascii med en integer. Der sættes et NULL i strengens sidste element og den kan herefter skrives ud. Testes programmet med GCC kan resultatet skrives ud til skærmen ved hjælp af funktionen printf. Testprogrammet kommer til at se således ud: int main(void){ int testtal = 135; char streng[7]; /*Funktionen kaldes med en teststreng, et testtal, * *den får lov til at bruge 6 af arrayets pladser og * *der skal ikke være decimaler. */ int2ascii(streng, testtal, 6, 0); /*Arrayets sidste element gøres til et nul og * *arrayet kan dermed behandles som en streng */ streng[7] = 0; /*Strengen skrives ud*/ printf("%s\n", streng); /*Det testes at funktionen kan fylde strengen ud * 98

103 10.1. GENERELLE FUNKTIONER Start Er plads <0? Ja Tomme pladser = 0" Plads gøres positiv Nej Er tal <0? Ja Sæt fortegn til - Tal gøres positiv Nej Er tal = 0? Ja Decimaler? Ja Skriv 0,0 i streng Nej Nej Skriv 0" i streng Er tal >0? Ja Skal komma være her? Ja Skriv, i streng Gå til forrige plads i streng Nej Er sidste Tegn,? Ja Nej Skriv 0 i streng Skriv tal % 10 i streng Del tal med 10 Nej Fortegn og plads? Ja Skriv fortegn i streng Nej Skriv tomme pladser i streng Afslut Figur 10.2: Flowchart over int2ascii med 0 er ved at gøre plads negativ */ int2ascii(streng, testtal, -6, 0); streng[7] = 0; printf("%s\n", streng); /*Funktionen testes med et tal med én decimal.* *Sidste ciffer bliver dermed decimalen, * *derfor skal testtal tidobles. */ 99

104 KAPITEL 10. MODULDESIGN testtal = testtal * 10; int2ascii(streng, testtal, 6, 1); streng[7] = 0; printf("%s\n", streng); } /*Til sidst testes funktionen med et negativt tal*/ testtal = -135; int2ascii(streng, testtal, 6, 0); streng[7] = 0; printf("%s\n", streng); Testresultater Ved kompilering af ovenstående program med GCC og afvikling i en terminal blev følgende strenge skrevet ud på skærmen: ,0-135 Dermed er funktionen blev testet med tilfredsstillende resultat Jiffytoiso Denne funktion tager et antal sekunder siden nytåret 2000 som argument i form af en unsigned long integer. Der returneres et array af 6 integers, der henholdsvis beskriver årstal, månedsnummer (hvor Januar er 1), dato, timer, minutter og sekunder. Selvom en tilsvarende funktion, iflg. (Kelley & Pohl 2001)[s. 560], er indbygget i ANSI C s time.h headerfil, har det alligevel været nødvendigt selv at skrive en, da IDE68k s C-biblioteker mangler denne. Programflow På figur 10.3 på næste side ses et diagram over programmets flow. Konverteringen sker ved, at programmet fratrækker de tidsenheder, der tælles. De største tidsenheder, år, tælles først. Hvis f.eks. at antallet af sekunder rækker til en dato i år 2004, vil programmet tælle et år ad gangen, og hver gang trække et år fra antallet af sekunder. Når der er talt op til år 2004, vil optællingen afbrydes, da der ikke længere er sekunder nok til et helt år. I denne proces tages der også højde for skudår, hvilket komplicerer processen betragteligt. Månederne tælles ikke som årene, da der i stedet først afprøves om der er tilstrækkeligt med sekunder til at være nået forbi november, derefter oktober osv. I det følgende eksempel antages at antallet af sekunder befinder sig i september. Sekundantallet vil befinde sig inden for et år pga. den foregående optælling af årene. Først undersøges om sekundantallet rækker til at være nået til november, hvilket ikke er tilfældet. Samme proces gentages 100

105 10.1. GENERELLE FUNKTIONER Modtag sek til omregning,og array tilat lægge resultateti Ja Definér skudår Er detår 2000? Nej sek=365 dage Ja Skudår og Sek<366 dage Nej Skudår og Sek=1 dag Nej Nej Ja Ja Træk 1 dag fra sek Sek = 365 dage Tæl Nej årstalop Sekundantaleter i etskudår Nej Ja Ja Træk 365 dage fra sek Definér skudår Sekunder nok tilatvære nåetforbi november Nej Sekunder nok tilatvære nåetforbi oktober Nej Sekunder nok tilatvære nåetforbi januar Ja Ja Ja Tælmånedstal op og træk 30 dage fra sek Tælmånedstal op og træk 31 dage fra sek Tælmånedstal op og træk 31 dage fra sek Sek nok tilen dag Ja Nej Sek nok tilen time Ja Nej Sek nok tiletminut Ja Nej Indfør årstal, månedstal,dato, timer,minu ter og sekunder i etarray og læg 1 tilmåned og dato Tældato op og træk en dag fra sek Tæltimetalop og træk en time fra sek Tælminu tal op og træk 60 s fra sek Returnér Figur 10.3: Flowchart for jiffytoiso for oktober. Når forløbet når til september, er der derimod sekunder nok til at have nået denne måned. Derfor fratrækkes nu antallet af dage i september, for at de ikke bruges i optællingen af de mindre tidsenheder, såsom dage etc. Samtidig tælles månedsantallet op. Der er også sekunder nok til de foregående måneder, hvilket betyder, at månedstallet tælles op til 9 (for september) og antallet af sekunder reduceres til at omfatte mindre end en måned. Dermed kan datooptællingen nu finde sted. Optællingen af dato, timer og minutter foregår ved samme princip som månederne, blot i en while-løkke frem for en serie af if-statements, da dato, timer og minutter er ensartede størrelser i modsætning til måneder. Når minutterne er optalt, er der 0-59 sekunder tilbage, der repræsenterer sekundantallet. Til sidst indføres de optalte tidsenheder i det array, som returneres. Her tælles måneder og dato endvidere én op, da der ikke findes en 0 te måned (i modsætning til timer etc.). 101

106 KAPITEL 10. MODULDESIGN Test Funktionen kan testes ved at sammenligne dens output med det fra ANSI C-funktionen strftime. Her skal det bemærkes at strftime benytter 1. Januar 1970 som begyndelsestidspunkt, hvilket gør at der skal lægges et offset til dens inputværdi. I praksis skrives to C-funktioner, der hver skriver tiden ud i samme format, men ved hjælp af hhv. jiffytoiso og strftime. For at kunne bruge strftime benyttes GNU C compileren, GCC. Ved hjælp af en for-løkke i begge programmer afprøves tidsrum med et passende interval, op til den maksimalt ønskede tid. Intervallets omfang bør sættes til en værdi, der, så vidt muligt, ikke går op i de benyttede tidsenheder for at testen er grundig nok. Outputtet fra begge programmer skrives til hver sin fil og kan derefter sammenlignes med UNIX-værktøjet diff, der kan sammenligne filer linje for linje. I følgende C-kode er begge funktioner realiseret. Compilerdirektiver og hovedfunktionen i programmet er ikke inkluderet, da disse er trivielle. Når testen udføres, skal der kompileres to versioner, hvor hhv. den ene og den anden sektion er udkommenteret. Det hele kører som nævnt i en for-løkke, der tæller variablen totsek op med et antal sekunder. Hvis funktionerne testes over en lang tidsperiode, kan dette spring gøres større end et enkelt sekund, for at undgå at outputfilerne bliver større end hvad, der er praktisk håndterbart. for(totsek=0; totsek< MAX-TID; totsek = totsek + SPRING){ /* Denne sektion ud skriver tid ud omregnet vha. jiffytoiso */ jiffytoiso(tidsarray, totsek); arrayprint(tidsarray); // Udskriv tidsarray i YYYY-MM-DD-HH-MM-SS /* Denne sektion ud skriver tid ud omregnet vha. jiffytoiso */ /* Først lægges tidsrummet fra nytåret 1970 til nytåret 2000 til en variabel kaldt ansitime */ ansitime = totsek + OFFSET; /* Tiden udskrives vha. strftime, der tager et struct som argument. Denne struct genereres af localtime-funktionen med antal sekunder efter nytår 1970 som argument. strftime skriver en streng med tiden i samme format som der gøres i ovennævnte funktion. Denne streng udskrives derefter med printf */ } strftime(streng, strlen(streng), "%Y-%m-%d-%H-%M-%S", localtime(&ansitime)); printf("%s\n", s); Testresultater Jiffytoiso blev, ved hjælp af ovenstående funktion, testet med MAX-TID = 100 år, SPRING = 1111, og OFFSET lig tidsrummet fra nytår 1970 til nytår På trods af at 102

107 10.1. GENERELLE FUNKTIONER jiffytoiso skulle virke med sekundantal op til år, begrænsedes den højest mulige totsek af offsettet, der skal lægges til totsek. Testen forløb problemfrit op til med MAX-TID = 100 år, hvilket viser at jiffytoiso virker til år 2100, hvilket regnes for tilfredsstillende Isotojiffy Denne funktion gør det modsatte af jiffytoiso, dvs. den omregner et array af 6 integers (beskrivende år, måned, dato, timer, minutter og sekunder) til en unsigned long integer, som beskriver antal sekunder efter nytåret Programflow Programflowet i denne funktion er mindre komplekst end det i jiffytoiso, bl.a. fordi der kun er en enkelt variabel, der skal tælles op. Omregningen fra et tidspunkt opgivet i årstal, måned, dato, timer, minutter og sekunder til et antal sekunder fra nytår 2000 foregår som følger: Først trækkes 2000 fra årstallet, da sekunderne regnes fra dette årstal. Derudover trækkes 1 fra måned og dato, da 1. januar i funktionen regnes for 0. dag i 0. måned. I næste proces lægges et antal dage, svarende til antallet af passerede skudår, til sekundantallet. Dernæst kontrolleres, om sekundantallet befinder sig i år 2000, efter marts. Hvis det er tilfældet, lægges en dag til sekundantallet, da skuddagen i år 2000 ikke medregnes senere i funktionen, hvis sekundantallet er indenfor år Derefter lægges en dag til sekundantallet, hvis årstallet er efter år 2000, da skuddagen i år 2000 også skal medregnes i senere år. Denne dag trækkes derefter fra igen, hvis datoen er før skuddagen i et skudår. Dette gøres for at kompensere for om datoen er før eller efter skuddagen i et skudår, hvilket bestemmer om der skal kompenseres for skudåret ved at tilføje en dag til sekundantallet. På dette tidspunkt er alle årene lagt i sekundantallet, og månederne tælles herefter op. Hvis input-datoen er i januar, skal der ikke lægges yderligere sekunder til sekundantallet i denne del af funktionen. Hvis input-datoen er i februar, dvs. at januar er overstået, skal antallet af dage i januar lægges til sekundantallet. Hvis februar er passeret, lægges 28 dage til (skuddage er der kompenseret for tidligere). På samme måde regnes resten af årets måneder til sekundantallet. Dernæst lægges alle de ensartede tidsenheder til sekundantallet, der til sidst returneres. Test Såfremt testen af jiffytoiso forløber problemfrit, kan der skrives et C-program, der gennem en for-løkke, kan teste isotojiffy op mod jiffytoiso. For-løkken tæller en sekund-værdi op, der fortolkes af jiffytoiso, hvis output fortolkes tilbage til den oprindelige værdi gennem isotojiffy. Såfremt den tilbagefortolkede værdi er lig inputværdien kører for-løkken videre, hvis ikke skrives et fejlmeddelelse og programmet afsluttes. Såfremt testen forløber uden fejl, kan funktionen regnes for at fungere. En C-funktion, der udfører ovennævnte, kan opbygges som følger: 103

108 KAPITEL 10. MODULDESIGN Modtag array med tidspunkt, træk 2000 fra årstal og 1 fra måned og dato Tilføj så mange dage, som der har været skudår ved det aktuelle årstal Iår 2000, marts eller derefter Ja Læg en dag til sekundantallet Nej Årstal efter 2000 Nej Skudår, efter år 2000 og før marts Nej Januar overstået Nej Februar overstået Nej Ja Ja Ja Ja Læg en dag til sekundantallet Træk en dag fra sekundantallet Læg 31 dage til sekundantallet Læg 28 dage til sekundantallet November overstået Ja Nej Læg årstal x 365 dage, dato x dage, timetal x timer, minuttal x minutter og sekunder til sekundantallet Returnér sekundantallet Læg 31 dage til sekundantallet Figur 10.4: Dataflow i isotojiffy for(totsek=0; totsek<max-tid; totsek=totsek+spring){ /* Omregn totsek til tidsarray */ jiffytoiso(tidsarray, totsek); /* Er der forskel på totsek og tidsarrayet, regnet tilbage til sekunder, er der sket en fejl! */ if(totsek - isotojiffy(tidsarray)){ printf("fejl!\n", totsek); // Meld fejl og skriv totsek return -1; // Returnér og afslut programmet } } Testresultater Jiffytoiso blev testet ved hjælp af ovenstående funktion, med MAX-TID = 2 32 og SPRING = 1, hvilket betyder at samtlige tidspunkter med et helt antal sekunder, testes op til februar år Testen forløb uden fejl, hvilket betyder at isotojiffy ikke afviger fra jiffytiso, der blev testet til år Dette resultat regnes for værende tilfredsstillende Debugrutiner fra TS2MON Debugger/monitor programmet TS2MON indholder en række funktioner til bl.a. at skrive data ud via den ACIA, som er reserveret til TS2MON. Når brugerprogrammet kører, er denne ACIA imidlertid ledig. Disse rutiner kan med fordel anvendes til at skrive debuginformation ud, så man får en mulighed for f.eks. at overvåge værdien af variabler bestemte 104

109 10.1. GENERELLE FUNKTIONER steder i programmet. For at udnytte denne mulighed skrives en række assemblerfunktioner, som kan kaldes fra C, og som kalder TS2MON s udskrivningsrutiner. I manualen til TS2MON er angivet en række funktioner, og hvilke adresser de kan kaldes fra. Samtlige funktioner bruger dataregister D0 til både input og output. De funktioner, der ønskes anvendt, ses i tabel Hex adresse: Funktion Beskrivelse $ C JMP GETCHAR user input to GETCHAR, read character - ASCII $ JMP PUTCHAR user input to PUTCHAR, write character - ASCII $ A JMP OUT2X user input to write 2 hex (byte) $ JMP OUT4X user input to write 4 hex (word) $ JMP OUT8X user input to write 8 hex (longword) Tabel 10.1: Tabel over anvendte TS2MON funktioner Der opbygges følgende assemblerfunktioner, som kan kaldes fra C: char debuggetchar(void); Denne funktion kalder TS2MON s getchar rutine direkte med: JSR $40C. Dette skyldes at denne rutine selv lægger den modtagne karakter i D0, hvor C programmet vil hente returværdien. Det skal bemærkes at TS2MON s getchar rutine venter med at returnere indtil der modtages en karakter. void debugstr(char *streng); Denne funktion sender en tekststreng til debugger/monitor PC en. Den henter en pointer til strengen fra stakken, hvor C-programmet vil lægge parametrene inden funktionen kaldes. Derefter sendes hver enkelt karakter i strengen med TS2MON s putchar rutine, indtil den karakter, der skal sendes er NULL, hvilket indikerer slutningen af strengen. void debugbyte(char); void debugword(int); void debuglong(long); Disse tre funktioner har i princippet samme funktionalitet. De kan skrive værdien af en variabel ud til terminalen, som et hexadecimalt tal. Der er tre funktioner, fordi M86k kan håndtere tre størrelser af tal, på henholdsvis 8,16 og 32 bits: bytes, words, og longwords. Disse svarer til de tre heltalstyper i C: char, int og long. De kalder TS2MON s funktioner OUT2X, OUT4X, og OUT8X. Tallet inden X et repræsenterer det antal cifre som det hexadecimale tal der skrives ud vil have. void breakpoint(void); Udover funktioner, der direkte kan kaldes som normalt, giver TS2MON også mulighed for at indsætte breakpoints i brugerprogrammet, hvilket vil sige at programafviklingen stoppes, og TS2MON udskriver indholdet af processorens registre. Normalt indsættes disse breakpoints direkte i hukommelsen med kommandoen BRGT <BP-addresse>. I praksis sker dette ved, at instruktionen TRAP #14 sættes ind på den ønskede adresse. Dette bevirker dog, at den instruktion, som normalt skulle have været på den pågældende adresse, bliver overskrevet. For at kunne indsætte breakpoints i C-koden skrives denne assemblerfunktion, som blandt andet indeholder TRAP #14 instruktionen. For at kunne genoptage afviklingen af C-programmet, udskrives en adresse til den sidste instruktion i funktionen, som er RTS. Dette vil få programmet til at springe tilbage til det sted i programmet, hvor breakpointfunktionen blev kaldt fra. 105

110 KAPITEL 10. MODULDESIGN Test af debugrutiner For at teste at funktionerne fungerer, skrives et C-program, som kalder dem. Der udskrives både tekststrenge og tal. I slutningen af løkken kaldes debuggetchar, som får programmet til at pause, indtil det modtager et tastetryk. Det tastetryk der modtages, gemmes og skrives ud næste gang løkken gennemløbes. Efter der modtages et tastetryk, ventes i 5 sekunder, hvorefter breakpointfunktionen kaldes, og dermed får TS2MON til at stoppe programafviklingen og skrive indholdet af registrene i terminalen. Hvis løkken skal gennemløbes igen, skal programmet startes igen fra den adresse, som skrives ud lige inden indholdet af registrene. Dette gøres med kommandoen GO <addr>. Herunder ses kildekoden til testprogrammet: main(void) { unsigned char byte = 0x12; unsigned int word = 0x4321; unsigned long lang = 0x ; while(1){ debugstr("debugacia\n\r"); debugstr("\n\rbyte: "); debugbyte(byte); debugstr("\n\rword: "); debugword(word); debugstr("\n\rlong: "); debuglong(lang); byte = debuggetchar(); word++; lang++; } delay( ); breakpoint(); } return 0; Testresultater Når testprogrammet køres, genereres det output, som ses herunder. Det skal bemærkes, at systemet umiddelbart efter linjen Long: venter, på grund af kaldet af getchar funktionen. I eksemplet herunder blev trykket på S, hvilket kan ses i slutningen af den pågældende linje. Efter delayet blev programmet afbrudt af breakpointet. Selvom det ikke ses herunder, er det desuden testet at programafviklingen genoptages, hvis der skrives GO 410BC, som er den returadresse, der skrives ud umiddelbart inden, den faktiske breakpoint-instruktion udføres. #GO

111 10.1. GENERELLE FUNKTIONER #DebugAcia Byte: 12 Word: 4321 Long: S Resume Address: BC #Breakpoint # # Data reg Address reg #0 FFFFFFFF # FFFFFFF # FFFFFFFF # FFFFFFFF #4 0000FFFF DFFF0040 #5 FFFFFFFF #6 FFFF FFF8 # FFFFEFFF # # SS = 0007FFEC # SR = 2708 # PC = BA # Funktioner til I 2 C Det er i afsnit 7.3 på side 61 blevet valgt at anvende en PCF8584 til at implementere den ønskede I 2 C-funktionalitet. Der skal skrives software, der sætter M68k i stand til at kommunikere med I 2 C-controlleren og derved kommunikere med sensorer og statisk hukommelse på I 2 C-bussen. Da der kun findes én master på bussen, skal softwaren kun understøtte master-receiver og master-transmitter. Disse 2 tilstande er blevet implementeret i 2 funktioner, som vil blive forklaret herefter. Henvises der til databladet er dette I2C_cnt-PCF8584_4.pdf på den vedlagte bilags-cd. Først vil funktionen, der anvendes til at sende data over bussen, blive forklaret: int i2c_send(unsigned char i2c_adr, char *data_send, int num) Argumentet i2c_adr indeholder adressen til den I 2 C-enhed, det ønskes at sende til. Det er dog kun de syv mest betydende bits, der udgør adressen. Den 8. bit angiver om det skal være en læse- eller skriveoperation. Da det er en funktion til at sende, skal den sidste bit være 0. Derved skal adressen altid være lige, for at den er gyldig. data_send er en pointer til de data, der skal sendes, hvilket kan være et array hvis mere end én byte skal sendes ad gangen. num angiver hvor mange bytes, der skal sendes til den adresserede enhed. Hvis der ikke er nogen enhed, der svarer på den adresse, som blev angivet i i2c_adr, returneres -1. Der bliver også returneret -1, hvis en enhed svarer med en negativ ACK. Når dataene er sendt returneres 1. Figur 10.5 viser flowet for i2c_send. For også at kunne hente data fra bussen er følgende funktion skrevet: 107

112 KAPITEL 10. MODULDESIGN Start Nej Læs S1. (Vent på PIN bliver 0) Send 0xC5 til S1. (PIN=1, ESO=1, STA=1, ACK=1) Startbeting. genereres og adresse clockes ud på bus Skriv adressen (i2c_adr) til slaven i S0. A0 er lav. Er PIN = 0? Ja Svarede slaven? (LRB = 0?) Ja i = num? Nej Ja Send 0xC3. (PIN=1, ESO=1, STO=1, ACK=1) Stop beting. genereres Send send_data[i] i++ Stop Figur 10.5: Flowchart for master-transmitter forløb(i2c_send) int i2c_hent(unsigned char i2c_adr, char *str_down, int num) Argumentet i2c_adr virker som i i2c_send, dog skal den 8. bit være 1 for at læse fra en enhed. Pointeren str_down indeholder adressen til det sted, hvor de data, der hentes på bussen skal være. Pladsen afsat til str_down skal være det samme som heltallet num. Hvis der ikke er nogen enhed, der svarer på den adresse, som blev angivet i i2c_adr, returneres -1. Der bliver også returneret -1, hvis en enhed svarer med en negativ ACK. Når dataene er hentet returneres 1. Figur 10.6 viser flowet i i2c_hent. Det blev fundet nødvendigt at modificere måden databladet anbefaler at udforme funktionerne i2c_send og i2c_hent. Begge funktioner skal i flg. databladet starte med at kontrollere om bussen er ledig ved læse registeret S1 på controlleren, hvilket er udeladt på figur 10.5 og Dette viste sig dog problematisk da controlleren, i modstrid med oplysninger i databladet, ikke holdte op med at trække SCL til stel efter en stop betingelse var sendt på bussen. Efter første adgang til I 2 C-bussen holdte controlleren bussen optaget. Det kunne dog lade sig gøre at få controlleren til at slippe bussen, ved at slå driveren til I 2 C-bussen fra, men det kunne efterfølgende ikke lade sig gøre at aktivere driveren igen. Derved blev det valgt at i2c_send og i2c_hent ikke skulle kontrollere BB*. Dette overtræder ikke nogen krav, der er opstillet i kravspecifikationen da der ikke skal være flere mastere på bussen. Før controlleren kan anvendes skal kredsen initialiseres hvilket sker med ı2c_setup. 108

113 10.1. GENERELLE FUNKTIONER Start Send adresse (i2c_adr) til S0 Send 0xC5 til S1. (PIN=1, ESO=1, STA=1, ACK=1) Startbeting. genereres og adresse clockes ud på bus Send 0x40 til S1. (PIN = 1) Acknowledge ikke sidste byte for at fortæle slaven at der ikke ønskes mere data overført Nej Læs S1 (Vent på PIN bliver 0) PIN = 0? Nej (str_down[i] = S0) Læs modtaget data i S0. Er dette den første læseoperation skal denne forkastes, da det er slavens I2Cadresse Ja Læs S1 Svarede slaven? (LRB = 0?) Nej Ja i = i 1? Ja (str_down[i] = S0) i++ Læs modtaget data i S0. Er dette den første læseoperation skal denne forkastes, da det er slavens I2Cadresse Nej PIN = 0? Ja Send 0xC3 til S1. (PIN=1, ESO=1, STO=1, ACK=1) Stop beting. genereres Str_down[i] = S0 Stop Figur 10.6: Flowchart for master-receiver forløb(i2c_send) Denne funktion sørger for at controlleren ved, at der anvendes en 8 MHz clock, I 2 C- bushastighed på 90 khz og at kredsen får en adresse på bussen 1. 1 Adressen er sat til 0x55 men er ikke nødvendig da controlleren ikke kan blive adresseret af andre enheder på bussen 109

114 KAPITEL 10. MODULDESIGN Test For at det er muligt at teste i2c_send og i2c_hent skal der være en enhed til stede på bussen, der er i stand til at sende og modtage data. Derfor blev temperatursensoren SA koblet til bussen. Testens mål er at vælge register 0 (indeholder temperaturen) på enheden og herefter overfører data fra dette register og udlæse dette på displayet. Følgende testkode er derfor skrevet til at vælge register 0 på temperatursensoren. main(void){ unsigned char data; /*Opret variabel til en byte*/ data = 0x0; /*Tilskriv data 0*/ i2c_send(0x98, &data, 1); /*Adresser temp. sensor og skriv nul hertil*/ } Koden forespørger enheden på bussen, der har adressen 62 (temperatursensorens adresse) og beder om en skriveoperation (Mindst-betydende bit af 0x98 er 0, derved en skriveoperation) til enheden. Herefter skriver den en byte på bussen der har værdien 0. Efter afvikling af koden blev det ønskede data sendt over bussen hvilket ses på skopbilledet på figur 10.7 Det ses på figur 10.7 at enheden svarer i den 9. clock-puls, da SDA er Figur 10.7: Scopshot af I 2 C-bus efter afvikling af i2c_send lav i denne puls. Fjernes den 9. clockpuls, ses det, at adressen der er sendt over bussen svarer til 62, hvilket var hensigten. Samtidig ses det, at en byte med værdien 0 er overført på bussen og er bekræftet med en ACK. Det antages, at temperatursensoren har valgt register 0. Hastigheden på bussen afviger fra de 90 khz, som controlleren er konfigureret til at køre med, dog ikke i en udstrækning der nedsætter bussens ønskede funktionalitet. For at teste om i2c_send fungerer, afvikles følgende kode for at hente temperaturen: main(void){ 2 Se afsnit på side

115 10.1. GENERELLE FUNKTIONER } char str[16]; unsigned char data; /*Opret variabel til en byte*/ i2c_hent(0x99, &data, 1); /*Adresser temp. sensor og læg det modtagede i data*/ int2ascii(str, data, 5, 0); /*Konverter til en streng...*/ printg(str); /*og skriv temperaturen ud på displayet*/ Igen adresseres temperatursensoren på adresse 62 og lægger det modtagne i variablen data. Herefter skrives det hentede ud på displayet. Figur 10.8 viser forløbet på bussen efter afviklingen af ovenstående kode. Figur 10.8: Scopshot af I 2 C-bus efter afvikling af i2c_hent Det ses at første pulsforløb er identisk med det, der ses på figur 10.7, bortset fra at den 9. puls i stedet er høj, hvilket indikerer en læseoperation. Andet pulsforløb viser at der sendes en byte over bussen og denne byte afsluttes med en negativ ACK, som forventet. Værdien af andet pulsforløb kan bestemmes til 27, hvilket også var værdien der blev skrevet ud på displayet. Da i2c_send og i2c_hent skulle afprøves, viste det sig, at der er problemer med Power-on reset kredsløbets stigetid omtalt i afsnit 6.1 på side 39. Problemet består i at controlleren ikke bliver reset tilfredstillende hvilket resulterer i at kredsen ikke virker efter reset af systemet hvilket kunne ses ved at PIN aldrig blev 0. Dette resulterede i at der blev skrevet fejlbeskeder ud til TS2MON fra funktionen i2c_wait_pin, der undersøger, hvornår PIN bliver 0. Der er dog ikke omtalt krav til stigetid på reset-pulsen i databladet til controlleren hvilket gør at det ikke endeligt kan konkluderes at dette er kilden til problemet. Problemet kunne dog omgås ved at give controlleren en reset-puls flere gange efter hinanden hvorved kredsen opførte sig som tiltænkt. Udfra de udførte test af i2c_send og i2c_hent konkluderes det, at funktionerne fungerer efter hensigten og at disse kan anvendes i andre funktioner. 111

116 KAPITEL 10. MODULDESIGN Funktioner til EEPROM Som beskrevet i afsnit på side 70, omkring EEPROM en, i hardwaredelen, kan der ikke skrives direkte til den, som med RAM hukommelsen, da den bruger I 2 C-bussen. Derfor kræves et par funktioner, som kan håndtere skrivning til og læsning fra EEPROM en. Disse vil så igen kræve, at der findes nogle funktioner, som kan håndtere at sende og modtage data over I 2 C-bussen. Disse funktioner er beskrevet i afsnit på side 107. For en nærmere beskrivelse af hvordan læse- og skriveoperationerne til EEPROM en skal foregå, henvises til afsnit 7.3.5, da dette afsnit kun omhandler hvordan de håndteres i software. Start Er adressen gyldig? Ja Split adressen op i to bytes Send adresse over I 2 C bus Gik de godt? Ja Hent data over I 2 C bus Afslut Nej Nej Fejl: Returner -1 Figur 10.9: Flowchart over læsning fra EEPROM int hent_eeprom(unsigned int addr, void *datapointer, int antal); Denne funktion tager tre parametre. Først en adresse, som bestemmer hvilken adresse i EEPROM en, der skal hentes fra. Derudover, tages en pointer til der, hvor de hentede data skal ligge, og endelig hvor mange bytes, det ønskes at hente. På figur 10.9 ses et flowdiagram over hvordan hentning fra EEPROM en foregår. Først kontrolleres at adressen plus det antal bytes det ønskes at hente, ikke går uden for EEPROM ens adresseområde. Derefter splittes startadressen op i to bytes, som skal sendes til EEPROM en for at opsætte dens adressecounter. Hvis EEPROM en bekræfter dette med et ACK, er den klar til at gå videre. Hvis ikke indikerer det, at den er igang med en skriveoperation. Derfor sendes adressen igen, indtil den bliver modtaget. Derefter er det blot at hente det ønskede antal bytes fra EEPROM en ved hjælp af funktionen i2c_hent, og lægge dem der, hvor datapointeren peger. Til sidst returneres nul, for at indikere, at hentningen lykkedes. Start Er adressen gyldig? Ja Split adressen op i to bytes og sæt dem først i dataarray Beregn hvor mange bytes der kan skrives i denne page Fyld det antal bytes i dataarrayet Nej Fejl: Returner -1 Send dataarray over I 2 C bus Ja Afslut Nej Er der flere data? Antal > 0? Træk de data fra der er sendt: antal = antal sendt Næste ADDR = ADDR + sendt Ja Gik de godt? Nej Figur 10.10: Flowchart over skrivning til EEPROM int skriv_eeprom(unsigned int addr, void *datapointer, int antal); Denne funktion tager de samme argumenter som hent_eeprom. Her vil dataene blot blive flyttet den modsatte vej. De data, som pointeren peger på, vil altså blive skrevet 112

117 10.1. GENERELLE FUNKTIONER til EEPROM en. På figur ses et flowchart over skrivning til EEPROM en. Ligesom i hentningsfunktionen kontrolleres først, at adressen plus antallet af bytes er inden for adresseområdet. Derefter splittes adressen op i to bytes, som sættes først i et dataarray. Dette dataarray bruges til at lave en midlertidig kopi af datene, inden de skrives. Grunden til dette er, at EEPROM en kun kan skrive inden for en memory page ad gangen. Disse pages er på 64 bytes, og begynder ved adresser, som er delelige med 64. Efter de to adressebytes er kopieret ind i dataarrayet, beregnes hvor mange databytes, der kan skrives inden for den aktuelle memory page. Dette antal bytes kopieres derefter ind i dataarrayet, og sendes til EEPROM en. Denne sending forsøges gentaget indtil den lykkes, da den vil mislykkes hvis EEPROM en allerede er igang med en skriveoperation. Når sendingen er overstået, trækkes det antal bytes, som lige er sendt fra det antal bytes der skal sendes. Det samme antal lægges til adressen. Hvis der stadig er flere bytes, der skal sendes, foretages endnu en sending. Ellers afsluttes og returneres nul, for at indikere, at skrivningen forløb uden fejl. Memorymap For at organisere, hvor i EEPROM en de forskellige data skal placeres, skal der laves et memorymap, som bestemmer ved hvilke adresser de enkelte variable skal placeres. Dette sikrer at ingen variable kan overskrive andre. En egnet måde at organisere denne tildeling af adresser, er ved at lave en række definitioner, med nogle synonymer som refererer til hvilken variabel, der skal gemmes på den pågældende adresse. Disse synonymer kan derefter bruges de steder i programmet, hvor der er behov for at skrive eller læse i EE- PROM en. Test af EEPROM For at teste EEPROM en, skrives et program, som ved hjælp af de to omtalte funktioner skriver en række tal i EEPROM en og læser dem igen. Herunder ses dette program. De læste data skrives ud på debugger/monitor serielporten med funktionerne debugstr og debugword, så det kan kontrolleres, at de rigtige data blev læst. #define ANTAL 200 int main(void) { int dataarray[antal]; int hentarray[antal]; int n; for(n=0; n< ANTAL;n++) { dataarray[n]= n; hentarray[n]=0; } 113

118 KAPITEL 10. MODULDESIGN i2c_setup(); debugstr("\n\ri2c sat op, skriver nu data..."); while(1) { skriv_eeprom(0,dataarray, 2*ANTAL); debugstr("\n\n\n\rstarter hentning..."); hent_eeprom(0, hentarray, 2*ANTAL); debugstr("\n\n\rhentede data: \n\r"); for(n=0; n< ANTAL;n++) { debugword(hentarray[n]); } } debuggetchar(); } return 0; Testresultater Herunder ses output fra udførslen af testen. Det ses, at de hentede data, som forventet, er en række hexadecimale tal, som tælles en op for hvert tal. Det viste output er forkortet, så der kun vises de 16 første tal. Der tælles helt op til værdien af ANTAL. #GO # I2C sat op, skriver nu data... Starter hentning... Hentede data: A000B000C000D000E000F... Det kan hermed konkluderes at skrive- og læsefunktionerne til EEPROM en fungerer, da de læste data stemmer overens med, hvad der blev skrevet Hent temperatur og luftfugtighed Det skal være muligt at hente temperaturen og luftfugtigheden fra de to sensorer. På baggrund af de I 2 C-funktioner, der i forvejen er lavet, skal der laves to funktioner der, kan hente temperaturen samt luftfugtigheden. Disse kaldes henttemp og hentfugt. 114

119 10.1. GENERELLE FUNKTIONER int henttemp(void) Denne funktion henter temperaturen fra I 2 C temperatursensoren. Den benytter sig af de I 2 C-funktioner, der tidligere er beskrevet, i2c_send i afsnit på side 107 og i2c_hent i afsnit på side 107. Som beskrevet i afsnit på side 68 skal temperaturen hentes i to bytes. I første byte ligger temperaturen med fortegn i hele antal grader, i det næste byte ligger decimalerne i steps af 0,125 C. Det funktionen skal gøre, er først at hente de hele antal grader ved at sende 0x0 til I 2 C-bussen,for at vælge registeret LTHB (Local Temperature HIGH Byte). Herefter skal den sende 0x22 til I 2 C-bussen for at modage LTLB (Local Temperature Low Byte). Efterfølgende skal disse adderes. Da der ikke kan regnes med floats, ganges det hele antal grader med 10, og efterfølgende lægges decimalerne til som heltal. Efterfølgende returneres summen, som netop er beregnet. Denne vil være ganget med 10, altså skal den deles ned igen for at få udlæst den korrekte temperatur. Dette gøres i de funktioner, der udskriver temperaturen. Hvis der opstår en fejl i de to funktioner, der kalder hhv. i2c_send og i2c_hent, returnerer de -1, hvilket vil få henttemp til at returnere 10001, eller alt efter hvilken fejl der er tale om. Test af henttemp(void) For at verificere, at funktionen virker som den skal, blev den testet i systemet og det blev verificeret at den modtog en temperatur, der lå inden for den angivne afvigelse i forhold til reference termometret. Da dette var tilfældet regnes henttemp(void) for at fungerer efter hensigten. unsigned char hentfugt(void) Denne funktion skal hente luftfugtigheden fra I 2 C-bussen. Luftfugtighedssensoren emuleres af en variabel spænding, sat ind på en AD-converter. Der skal læses fra en MAX1236EUA, se evt. afsnit på side 69. Dette er en 12 bit AD-converter, men da luftfugtigheden skal læses som et heltal mellem 0 og 100, kan de mindst betydende bits ignoreres. For at læse fra AD-converteren, skal der først sendes to konfigurationsbytes. Den første, der sendes, har værdien 0x82, der angiver, at man sender en setupbyte, der indikerer, at referencespændingen skal være Vcc, at den skal bruge intern clock, måle indgangsspændingen i forhold til GND og ikke skal nulstille indstillingerne. Den næste byte, der sendes, som har værdien, 0x61, angiver, at der sendes konfigurationsdata. Denne angiver, at der kun skal læses fra een kanal på AD-converteren, at det er kanal 0, den skal læse fra, og at den skal køre i single-ended mode, dvs. den skal ikke sammenligne indgangsspændingerne på portene. Herefter modtages to bytes fra AD-converteren. Den første byte indeholder 4 høje bits. Herefter kommer de 4 mest betydende bits. Den næste byte indeholder de 8 mindstbetydende bits. De 8 mest betydende bits, dvs. de sidste 4 bits af byte 1 og de 4 første bits af byte 2 samles i een byte. Se fig på næste side. Denne byte indholder konverteringsresultatet. Denne ganges med 100, da der ønskes et resultat imellem 0 og 100%. Herefter divideres med opløsningen, dvs Dette resultat, som er et heltal mellem 0 og 100 returneres herefter. 115

120 KAPITEL 10. MODULDESIGN e 1 e x x x x x x x x x x x x MSB LSB Figur 10.11: MSB fra to bytes samles til én byte Test af hentfugt(void) Denne funktion blev på lige vis med henttemp testet i systemet. Hvis funktionen virker som den skal, skal den returnere fra 0 til 100 når potentiometret drejes fra den ene yderlighed til den anden. Da funktionen returnerede det ønskede, regnes funktionen for at virke efter hensigten Sekundhåndtering Systemet skal udføre en række handlinger hvert sekund, hvilket denne proces skal sørge for. Et eksternt stykke hardware genererer en interrupt hvert sekund, hvorved processen Sekundhåndtering kaldes. Designet af processen fandt sted i afsnit 9.2 på side 91. Processen blev delt op i følgende moduler: Ur Dataopsamling Alarm Ur-modulet tæller en ur-variabel op, mens dataopsamling henter data ind, behandler og lagrer eller videresender til en pc. Alarmmodulet kaldes af dataopsamlingen, når temperatur eller relativ luftfigtighed overskrider de, af brugeren, indstillede grænseværdier. Alarmmodulet sørger for at assertere alarmbenet og logge hændelsen til alarmloggen. Sekund-håndteringsprocessen kalder modulerne i processen gennem følgende stykke assemblerkode: sekhaand MOVEM.L D0-D7/A0-A7,-(A7) ; Gem registre der arbejdes i ADD.L #1,(UR) ; Ur-modul: Tæl uret 1 op JSR _dataopsamling ; Spring til dataopsamlingsmodulet, ; der kalder alarm om nødvendigt MOVEM.L (A7)+,D0-D7/A0-A7 ; Genopret registre RTE ; Returnér fra exception Da rutinen kaldes via et interrupt (IRQ3), bliver et evt. kørende program afbrudt efter den igangværede instruktion er overstået. Derfor lægges samtlige data- og adresseregistre først på stakken via stackpointeren A7, hvorved det afbrudte program kan fortsætte problemfrit, 116

121 10.2. SEKUNDHÅNDTERING når interruptrutinen er udført og registrene gendannet. Derefter udføres Ur-modulet, der består af en linje som forklares i næste afsnit, Moduldesign af ur. Tredje linje kalder dataopsamlingsmodulet via en JSR (Jump to SubRoutine). Dette modul kalder alarmmodulet, hvis temperatur eller relativ luftfugtighed er uden for de grænseværdier, som brugeren har defineret. Næstsidste linje genopretter data- og adresseregistrene, der blev lagt på stakken i første linje. Den sidste linje, RTE (Return from exception), får processoren til at fortsætte afviklingen af det program, der blev stoppet af interrupten. Der skal endvidere skrives en linje kode til interrupt-vektortabellen, der er blevet flyttet af TS2MON-systemet som nævnt i afsnit på side 31. Denne kodelinje skal, ifølge formlen der findes i førnævnte afsnit lægges på adressen som udregnes med følgende formel, hvor vektornummeret for IRQ3 er 27: vektornummer 8 bytes + $40000 = 27 8 bytes + $40000 = $400DA (10.1) Formålet med linjen er at få processoren til at springe til sekundhåndteringen, når den læser indholdet på ovenstående adresse. Det vil sige at følgende stykke kode, der kalder sekhaand-funktionen, skal lægges på adressen $400DA: JMP seekhaand Moduldesign af ur Ur-modulet tæller en ur-variabel op, som udgøres af en 32 bit (unsigned long) talværdi, der angiver antallet af sekunder siden nytår Til at regne dette antal sekunder om til den gregorianske tidsregning, er der konstrueret funktionerne jiffytoiso og isotojiffy, der kan læses mere om i hhv. afsnit på side 100 og afsnit på side 103. Disse funktioner skal bruges til omregning mellem de forskellige tidsregninger. Navnene kommer af, at den engelske betegnelse jiffy ofte bruges om små korte tidsrum, mens iso kommer af at den gregorianske tidsregning let arrangeres i ISO8601-tidsformatet. Uret er realiseret ved to stykker assemblerkode, hvor det ene er et kompilerdirektiv, der allokerer 32 bits i i hukommelsen: UR DS.L 1 Det andet stykke kode udgøres af linje 2 i sekundhåndteringsprocessens assemblerkode, som ses ovenfor. Omtalte kodelinje gør ikke andet, end at lægge én til 32 bit værdien der ligger på adressen UR, som compileren definerer. Når indholdet af UR skal tælles op til 2 32 sker et overflow, der vil afbryde programafviklingen. Det accepteres dog, da det først vil ske 136,1 år efter år 2000, som det ses nedenfor. aar over f low = 2 32 [sek] = 136,1 [aar] (10.2) 365,25 [dage] 24 [timer] 60 [min] 60 [sek] 117

122 KAPITEL 10. MODULDESIGN Dataopsamling Modulet dataopsamling henter klimadata fra I 2 C bussen og kontrollerer for overskridelser af alarmgrænser. Endvidere lagres målingerne i EEPROM en med det rette lagringsinterval. Modulet dataopsamling er blevet opdelt i et antal funktioner, da der er mange aktiviteter der skal aktiveres flere gange eller flere steder. For at få et overblik over hvilke funktioner der skal anvendes for at implementere modulet dataopsamling vil de blive gennemgået herefter en for en. Hovedfunktionen dataopsamling I modulet dataopsamling er hovedfunktionen dataopsamling. Det er sker hvert vil blive bekrevet her.der skal opsamles data fra I 2 C- bussen, der skal kontrolleres for alarm og der skal kontrolleres om der er kommet nye ekstremer for enten temperaturen eller for RF. Endvidere skal der udregnes gennemsnit for både temperatur og for RF. De opsamlede data samt eventulle ekstremer og gennemsnit tilskrives det fælles datalager aktuelle målinger. Det slal også undersøges hvorvidt det er tid til at lagre målingerne. Det gøres med funktionen indstillinger Hvis det er tid til gemme, skal det undersøges hvilken hukommelsestilstand der er valgt. Det gøres ved at læse i det fælles lager indstillinger. Der anvendes en switch case konstruktion, til at sørge for at der bliver afviklet det korrekte kode, alt efter hvilken hukommelsestilstand der er valgt. Den første case aktiveres hvis indstillingen fyld hukommelse er valgt. I denne case skrives målingerne, måling nummer, antal elementer og variablen gammel i EEPROM en. Det gøres indtil der ikke er mere hukommelse til rådighed. Er det case 2 der er aktiveret, er det fordi at der er valgt ringbuffer som hukommelses tilstand. Indtil bufferen er fyldt, sker der stort set det samme som i case 1. Forskellen er at variablen ny bliver sat lig måling_nr og derefter skrives til EEPROM en. Når ringbufferen er fyldt, skal den overskrive de ældste målinger. Det vil ske eftersom variablen maaling_nr bliver sat til nul, hvis ny er Variablerne gammel og ny angiver hvor den ældste og nyeste måling er gemt. De to variable bruges, når der skal læses fra ringbufferen. Den tredje og sidste case vil blive aktiveret, hvis der er valgt Send til PC som hukommelses tilstand. Når det er tilfældet, sendes målingerne direkte til PC via RS232 forbindelsen. Pseudokode for dataopsamling For at give et bedre indblik i hvad funktionen dataopsamling skal varetage, er der skrevet pseudokode. Denne kode ses her: void dataopsamling(void) { hent temperatur; hent RF; kontroller for alarm; kontroller for ny Max temperatur; kontroller for ny Min temperatur; kontroller for ny Max RF; kontroller for ny Min RF; Udregn nyt gennemsnit for temperatur og RF; 118

123 10.2. SEKUNDHÅNDTERING Hvis (Det er tid til at gemme i EEPROM) { Hvilken hukommelsestilstand er valgt? { Tilfælde Fyld hukommelse: Hvis (der er hukommelse tilrådighed) { Skriv temperatur og RF til EEPROM på den næste plads i hukommelsen; returner Det er gået godt ; } returner fejl ; //hukommelsen er fuld Tilfælde Ringbuffer: Hvis (bufferen ikke er fyldt endnu) { Skriv temperatur og RF til EEPROM; antal elementer i bufferen incrementeres; maaling_nr incrementeres; gammel=0; maaling_nr, ny og gammel skrives til EEPROM; } Hvis (bufferen er fyldt) { Hvis (ny==buffer størrelse) maaling_nr=0; Skriv temperatur og RF til EEPROM; ny=maalinger_nr; maaling_nr incrementeres; maaling_nr og ny skrives til EEPROM; gammel=maaling_nr; gammel skrives til EEPROM; returner Det er gået godt ; } returner Det er gået godt ; Tilfælde Send til PC: temperaturen laves til en streng; strengen formateres; strengen sendes til PC; RF laves til en streng; strengen formateres; strengen sendes til PC; } } returner Det er gået godt ; } 119

124 KAPITEL 10. MODULDESIGN Beskrivelse af funktionerne I hovedfunktionen dataopsamling bliver der gjort brug af et antal funktioner for at realisere det ovenstående. De funktioner, der bliver kaldt hvert sekund, i starten af funktionen dataopsamling, er følgende funktioner: void tjekalarm(unsigned char fugt, int temp ) void gennemsnit(unsigned char fugt, int temp) void min_fugt(unsigned char fugt) void max_fugt(unsigned char fugt) void min_temp(int temp) void max_temp(int temp) Ud fra disse prototyper ses det at ingen af funktionerne returnere noget. For funktionerne gennemsnit, max_temp, min_temp, max_fugt og min_fugt gælder det at de bliver kaldt med de relevante data fugt, temp eller begge dele. Endvidere kalder de førnævte funktioner akt_maal for at få skrevet værdierne i det rigtige lager for de aktuelle målinger. Funktionen tjekalarm tager både temp og fugt som argument. Funktionen kalder indstillinger for at finde ud af hvilke grænser der er sat for alarmen. void init_foerstegang(void) Da data skal være tilgængelig når systemet startes skal, der først hentes data fra EE- PROM en. Det sørger funktionen init_foerstegang for. Den henter variablerne foerste_tid, maaling_nr, ny, antal_elm og gammel. Endvidere henter den også indstillingerne fra EEPROM en. Dernæst sørger funktionerne for at hente temperatur og RF, og skrive det som gennemsnitsværdier og som max og min værdier for både temperatur og RF. void dataopsamling_init(void) Funktionen tager ikke nogle argumenter og returnere ikke noget. Den sørger for, at variablerne gammel, ny antal_elm og maaling_nr til nul. Den variablen foerste_tid bliver også sat til det aktuelle tidspunkt. Alle disse variable skrives til sidst til EEPROM en. int maalinger(char rw, maal_elm *datapointer, int jegvilha_nr) Når der skal gemmes i målelageret, anvendes funktionen maalinger. Fra funktionens synopsis ses det, at det første argument er rw som bruges til at afgøre, om der skal skrive eller læses fra målelageret. Det andet argument, *datapointer, er en pointer til der, hvor målingerne ligger i rammen. Det sidste argument jegvilha_nr bliver kun brugt hvis rw er sat til READ. jegvilha_nr angiver hvilken måling nr der ønskes læst. Funktionen returnerer 0, hvis det er gået godt, og -1, hvis det er gået galt. int akt_maal(int data, int type) Da de aktuelle målinger, gennemsnitsværdierne og maximum- minnimum-værdierne skal bruges af datavisningen, skal disse skrives i et lager og det skal være muligt at læse fra samme lager. Til at håndtere denne opgave skal der være en funktion med navn akt_maal. Eftersom der kun er to argumenter skal funktionen konstrueres, så den afgør om der skal skrives eller læses fra lageret. Det gøres ved at benytte en switch case konstruktion, hvor der switches på variablen type. Hvis type bliver kaldt med værdier fra så skal en af case ne aktiveres og der læses den efterspurgte værdi fra lageret. Kaldes type med en værdi fra 0-7 skal switch case konstruktionen gå til default. Ved default skal typen bruges til at bestemme hvilken plads i arrayet der skal skrive på. Se evt afsnit 9.4 på side

125 10.2. SEKUNDHÅNDTERING int indstillinger(char rw,char type, int data) Da hovedfunktionen skal kunne læse i lageret indstillinger er der lavet en funktion, som kan håndtere der kaldes indstillinger. Funktionen kan, ud over at læse i indstillingslageret, også skrive i indstillingslageret. Lige som maalinger er det første argument rw som afgør hvorvidt der skal skrives eller læses fra lageret. Det andet argument type skal bruges til at bestemme hvilket medlem af strukturen det ønskes at læse fra eller skrive til. Det sidste argument data er den værdi, der ønsker at tilskrive det valgt mellem i strukturen. Lige som i funktionen maalinger er data ligegyldig hvis rw bliver kaldt med READ. Funktionen indstillinger sørger for, at der bliver skrevet til EEPROM en, hvis indstillingerne er blevet ændret. For at sikre, at der ikke vil blive sendt ugyldige målinger, efter der er blevet ændret hukommelsestilstand eller lagerinterval, kaldes funktionen dataopsamling_init. Den sørger for at de gamle målinger ikke bliver sendt til PC en, hvis kommandoen send bliver sendt til systemet fra en PC. void standardindstilling(void) For at kunne genskabe standardindstillingerne er der lavet en funktion til formålet, som hedder standardindstillinger. Den tager ingen argumenter og returnerer intet. Funktionen gør er at skriver standardindstillingerne ind i strukturen og får det skrevet til EEPROM en. Standardindstillingerne ligger som konstanter i koden, hvilket vil sige, at hvis det ønskes at ændre standard indstillingerne, skal der rettes i programkoden og koden skal herefter kompileres igen. int intervalisek(void) Da det er nødvendigt for dataopsamling at vide hvad lagringsintervallet er sat til skal der konstrueres en funktion, som ikke tager argumenter og returnerer et heltal, som er det valgte lagringsinterval i sekunder. Funktionen skal kalde indstillinger, som returnerer hvilket lagringsinterval, der er valgt. Ud fra indstillingers returværdi skal intervalisek afgøre hvilket antal sekunder, den skal returnere til den kaldende funktion. void gennemsnit(unsigned char fugt, int temp) Da en af modulet Dataopsamlings opgaver er at udregne et gennemsnit for temperaturen og for RF, skal der laves en funktion som kan varetage denne opgave. Funktionen returnerer intet. Argumenter til funktionen skal være temperatur og RF. Funktionens opgave er endvidere at sørge for, at gennemsnitsværdierne bliver opdateret i lageret aktuelle målinger. Gennemsnitsværdierne, der skal udregnes, skal sættes til den aktuelle værdi for temperatur og RF ved midnat. Det vil sige, at gennemsnitsværdierne kun er et gennemsnit siden kl 00:00:00. Funktionen skal konstrueres, så det ikke er nødvendigt at læse alle målingerne fra EEPROM en for at udregne gennemsnitsværdierne. Funktionen skal derfor kunne afgøre om det er midnat. Endvidere skal funktionen kontrollere, om det er første gang, den bliver kaldt. Det skyldes at første gang funktionen bliver kaldt skal den blot skrive de argumenter, den er kaldt med, på de rigtige steder i aktuelle målinger. Når det ikke er midnat og det ikke er første gang funktionen bliver kaldt skal den regne gennemsnittet ud og skrive det i aktuelle målinger. Da det ikke er særlig hensigtsmæssigt at gennemgå alle målinger hvert femte sekund anvendes en konstruktion hvor den gamle gennemsnitsværdi adderes med den nye værdi, for enten temperaturen eller RF. Denne sum af gennemsnitsværdier diveres så med antallet af gennemsnitsværdier i den før omtalte sum. Pseudokode for føromtalte udregning ses her: /*Temperatur gennemsnit anvendes som eksempel.*/ Antal_af_gennemsnit incrementeres; Sum_af_gennemsnitsværdier=(Sum_af_gennemsnitsværdier+Ny_temperaturværdi); 121

126 KAPITEL 10. MODULDESIGN Ny_gennemsnitværdi=Sum_af_gennemsnitsværdier / Antal_af_gennemsnit; Test For at teste modulet dataopsamling er der skrevet nogle få tilføjelser til koden, så det er muligt at teste koden på en PC. Compileren, der er anvendt, er GCC. For at kunne teste modulet som et selvstændigt C-program, er der tilføjet main funktion som ser ud på følgende måde int main(void) //Tilføjet for at starte de forskellige funktioner. { dataopsamling_init(); while(1) { dataopsamling(); } return 0; } Fra main ses det at dataopsamling bliver kaldt i en uendelig løkke. Da programmet er blevet testet på en PC, har nogle af de funktionskald, der er i dataopsamling, været erstattet med testfunktioner. Det er funktionerne hentfugt og henttemp. Funktionen hentfugt har været implementere på følgende to måder måder: unsigned char hentfugt(void) { static unsigned char fugt; printf("indtast fugt\n"); scanf("%d",&fugt); return fugt; // Returnerer den indtastede værdi for fugt } Den første udgave af hentfugt har været anvendt til at teste at funktionerne akt_maal, max_temp, min_temp, max_fugt, tjekalarm og min_fugt. En identisk konstuktion blev anvendt til at implementere henttemp. Til at teste funktioner som gennemsnit og funktionaliteter som fyld hukommelse og ringbuffer er de to funktioner implementeret på følgende måde for at undgå at skulle indtaste temperatur og RF værdier hele tiden: unsigned char hentfugt(void) { static unsigned char fugt = 30; if(fugt < 90) { fugt=fugt+10; return fugt; } fugt = 20; 122

127 10.2. SEKUNDHÅNDTERING return fugt; } Igen anvendt den samme konstruktion for henttemp. For at være i stand til at kontrollere, hvad der sker i programmet, har der endvidere været indsat et antal printf på relevante steder i programmet. Funktionen intervalisek blev testet ved at indsætte en printf på det sted i programmet, hvor der bliver gemt i lageret og på det sted i programmet, hvor der bliver hentet en måling. Derefter kan det kontrolles, at det er det korrekte antal målinger mellem, at der bliver gemt i lageret Alarm Modulet alarm, er en del af processen sekundhåndtering, og står for at skrive alarmloggen. Det aktiveres, hvis dataopsamlingsmodulet registrerer at en af måleværdierne overskrider de indstillede grænser. Efter en sådan overskridelse skal det ses som én alarm, indtil måleværdien igen kommer inden for de tilladte grænser. Så længe målingen overskrider alarmgrænsen kaldes alarmen for aktiv. Der kan maksimalt være to aktive alarmer samtidigt, en for temperatur og en for fugtighed. typedef struct alarmlog_elm{ long tid; char type; long varighed; int max_overskr; } alarmlog_elm; Som vedtaget i afsnit 9.4 på side 93 om datastrukturer, skal alarmloggen bygges op af structs. For hver alarm, gemmes en sådant struct alarmlog_elm, som indeholder data om alarmens starttidspunkt, varighed og hvad den største eller mindste værdi af henholdvis fugtighed eller temperatur har været mens alarmen har stået på. Desuden gemmes hvilken type alarmen er, altså om det er temperaturen eller luftfugtigheden, der har overskredet en grænse. Typen kan enten være 1, hvis det er en alarm for temperaturen, eller 2 hvis det er fugtigheden, der har overskredet sin grænseværdi. Hvis typen er nul, indikerer det at alarmen skal opfattes som ugyldig. Alarmloggen skrives som en ringbuffer. Det vil sige at de sidste ti alarmer huskes, og når der kommer en ny alarm overskrives den ældste. Ved udlæsning ønskes det, at den nyeste alarm kommer først, og derefter de ældre. I stedet for at flytte alle elementerne, når der indsættes et nyt, vælges det at holde styr på hvordan elementerne ligger, ved at have en variabel til at huske, hvor det ældste element ligger, og en til at vide hvor mange elementer der er gemt. Det vil sige, at selv om det første(nyeste) element måske ligger midt i arrayet, skal der laves en funktion, som kan finde frem til det, når der spørges efter det første. Der anvendes to globale variable, antal_elementer og aeldste_element, til at holde styr på arrayet. I praksis gemmes alarmloggen i EEPROM en, i stedet for at gemme den i et almindeligt array i RAM en. Dette gør, at alarmloggen huskes, selv om systemet slukkes. Dermed er det også nødvendigt, at gemme kopier af de to variable antal_elementer og aeldste_element i EEPROM en, hver gang der ændres på dem. De skal så hentes derfra, når systemet startes op. 123

128 KAPITEL 10. MODULDESIGN Alarmniveau overskredet Findes der en aktiv alarm? Nej Find en plads til en ny alarm Indsæt alarmdata Ja Nej Skriv data til EEPROM Returner Hent data for den aktive alarm Er den stadig aktiv? Ja Opdater data for alarmen Figur 10.12: Flowchart over alarmmodul På figur ses et flowchart, over hvordan alarmmodulet behandler de indkommende alarmer. Denne behandling foretages af en række funktioner, som herefter vil blive beskrevet. På flowchartet er der ikke nogen forskel på hvilken type alarmen har, men der skal være mulighed for en aktiv alarm af hver type. Udover hovedfunktionen alarm kræves nogle funktioner til at håndtere alarmloggen som en ringbuffer (ny_alarm og hent_alarmlog), og skrive og læse de enkelte alarmer i EEPROM en (skriv_alarm og hent_alarm). Der skal desuden bruges en initialiseringsfunktion (alarm_init) og endelig en funktion som kan nulstille alarmloggen (nulstil_alarmlog). Disse funktioner vil herefter blive beskrevet void alarm(char type, char overunder, int data); Funktionen alarm er hovedfunktionen i alarmmodulet, som kaldes, når det konstateres at en måling overskrider en alarmgrænse. Den finder ud af, om der findes en aktiv alarm, der skal opdateres, eller om der skal oprettes en ny. Der gemmes to statiske variable, som husker nummeret på den aktive alarm for henholdsvis fugtighed og temperatur. Hvis disse variable sættes lig med minus en, indikerer det at der ikke er nogen aktiv alarm af den pågældende type. Hvis der allerede findes en aktiv alarm af den type, som funktionen blev kaldt med, hentes denne alarm med funktionen hent_alarm. Derefter kontrolleres hvorvidt den pågældende alarm stadig skal være aktiv. Hvis den skal, vil alarmens starttidspunkt plus alarmens varighed plus en, være lig med det nuværende tidspunkt. Dermed skal denne alarm blot opdateres, ved at lægge en til varigheden, og eventuelt indsætte en ny værdi for den maksimale overskridelse. Derefter gemmes den nye alarm med funktionen skriv_alarm. Hvis der ikke fandtes nogen aktiv alarm, eller den sidste aktive alarm ikke længere skal være aktiv, skal der oprettes en ny. Det foregår ved at skrive de aktuelle data ind i en struct alarmlog_elm, og kalde funktionen ny_alarm, som finder ud af hvor det skal placeres, og skriver det ind. I funktionen findes desuden en mulighed for at nulstille de to variable, som peger på de aktive alarmer. Dette gøres ved at kalde funktionen med type nul. Dette vil sætte de pågældende variable lig med minus en, som netop indikerer at ingen alarmer er aktive. 124

129 10.2. SEKUNDHÅNDTERING void skriv_alarm(unsigned char nummer, alarmlog_elm *data); Denne funktion skriver et element ind i alarmloggen, som ligger i EEPROM en. Det kan sammenlignes med at skrive i et array af alarmlog_elm, som blot ligger i EEPROM en. I praksis kan det realiseres, ved at beregne hvilken adresse i EEPROM en, elementet skal lægges på, og så kalde funktionen skriv_eeprom, som står for selve skrivningen. void hent_alarm(unsigned char nummer, alarmlog_elm *data); Henter et element i alarmloggen fra EEPROM en. Det svarer lige som ved skriv_alarm til at hente et element ud af et array. char ny_alarm(alarmlog_elm *data); Når der skal indsættes et nyt element i alarmloggen, skal det først bestemmes hvilken plads det skal stå på. Det er denne funktions opgave. Hvis loggen endnu ikke er fyldt, skal den næste ledige plads blot anvendes, men når loggen er fyldt skal det ældste element overskrives. De to globale variable aeldste_alarm og antal_alarmer bruges til at bestemme hvilken plads der skal bruges. Når det er fastlagt hvor det nye element skal stå, kaldes skriv_alarm for at skrive det ind. void hent_alarmlog(char plads, alarmlog_elm *data); Denne funktion kaldes, når alarmloggen skal vises i menusystemet. Den finder, ved hjælp af aeldste_alarm, og antal_alarmer, et element i alarmloggen, men vil altid svare med det nyeste element hvis den kaldes med nul som parameter, det næstældste hvis parameteren er en, og så videre. Den faktiske hentning af elementet foregår ved hjælp af hent_alarm. Hvis der spørges efter et element der ikke findes, returneres et element med typen nul, som er ugyldig. Hvis for eksempel der spørges efter element nr 4, og der kun er 2 alarmer. Da denne funktion kun kaldes fra menusystemet, hører den ikke til i processen sekundhåndtering, men da den fungerer som menusystemets adgang til alarmloggens datastruktur, er det valgt at holde den sammen med resten af alarmmodulet. Dette skyldes, at den skal bruge de to variable antal_alarmer og aeldste_alarm. Fordi den ikke hører til i sekundhåndteringen, skal interruptet, som aktiverer sekundhåndteringen slås fra mens EEPROM en tilgås for at hente alarmdataene, da der ellers kan opstå en konflikt, hvis læsningen fra EEPROM en bliver afbrudt af at sekundhåndteringen også vil bruge I 2 C- bussen. void nulstil_alarmlog(void); Når menupunktet i konfigurationsmenuen til nulstilling af alarmloggen aktiveres, kaldes denne funktion. Den nulstiller alarmloggen ved at sætte aeldste_element og antal_alarmer til nul. Der skrives ingen data i selve arrayet, men aeldste_element og antal_alarmer kopieres til EEPROM en. Ligesom i hent_alarmlog er det også her nødvendigt at deaktivere sekundhåndteringens interrupt, mens EEPROM en tilgås. Udover dette kaldes 125

130 KAPITEL 10. MODULDESIGN funktionen alarm med type nul, som får den til at nulstille, således at ingen alarmer er aktive. int alarm_init(void); Denne funktion skal kaldes hver gang systemet starter op. Den sørger for at hente aeldste_alarm og antal_alarmer fra EEPROM en. Desuden kaldes alarm med type nul, som får den til at nulstille, således at ingen alarmer er aktive. Test af alarmmodul For at teste, at alarmloggen kan skrives som en ringbuffer, laves et program, som opretter nye alarmer og læser dem ud ved hjælp af funktionen hent_alarmlog. De alarmer, der oprettes, nummereres fortløbende, således at det kan ses hvilken rækkefølge de er oprettet i. Når der udlæses, skal alarmen med det højeste nummer stå som den første, og derefter skal de ti senest oprettede vises. Et sådant program er skrevet og kompileret med GCC, og kan findes på den vedlagte cd under filnavnet alarmtest.c. For at få programmet til at fungere på en PC, skal alle funktionskald der vil bruge EEPROM en udkommenteres og erstattes med almindelige variable i RAM. F.eks. gemmes selve alarmloggen som et array af struct alarmlog_elm. Selve funktionen alarm, som skal stå for at indsætte data i de elementer, der skal skrives i alarmloggen, testes først når processen sekundhåndtering samles, da den er afhængig af at kunne modtage data fra dataopsamlingsfunktionen. Den skal desuden kunne hente det nuværende klokkeslet Menusystem Menusystemets formål er at sætte brugeren i stand til at kommunikere med systemet. Menusystemet aktiveres af tastaturet på systemet. Da dette ikke sender interrupt når der trykkes på en knap, er det nødvendigt med polling på tastaturets adresse, for at se om brugeren trykker på en knap. Polling-funktionen realiseres ved at lade en uendelig løkke kalde henttast ved hver gennemløb. Hvis værdien er forskellig fra 0, er der trykket på en knap, og det undersøges om værdien svarer til ét tastetryk. Processen får derved den laveste prioritet i systemet, da interrupt fra de 2 andre processer vil afbryde pollingen. Dette anses for den bedste løsning, da brugerens adgang til menusystemet ikke er tidskritisk som, fx sekundhåndtering, der skal opdatere uret. Det er tidligere blevet bestemt hvilke moduler, der hører under denne proces, men disse vil blive gentaget her: Trykfordeler Datavisning Hovedmenu Konfiguration 126

131 10.3. MENUSYSTEM Alarmlog Alle disse moduler i samspil skal sætte brugeren i stand til at manipulere med de underliggende datastrukturer og funktioner. Da det er bestemt at modulet trykfordeler skal sørge for at sende tastetryk videre til de korrekte menuer, opbygges menusystemet omkring dette modul. Modulet trykfordeler designes derfor så opdateringen af menutræet varetages enerådigt her, hvilket gør at menuer skal kalde trykfordeler for at bestemme om de er aktive. Med aktive menes at menuen skal vises i displayet. Modulet trykfordeler er derfor udformet som en funktion: int trykfordeler(int n_menu, int n_niveau, int type, char *is_end, char cmd){ static int p[n_array]; static int n_position;... } Kravspecifikationen stiller krav om at systemet skal kunne betjenes med 4 knapper; [esc], [enter], [<] og [>]. Disse bliver repræsenteret ved argumentet cmd og antager værdierne 1, 2, 4 og 8 når disse skal læses fra tasteturet i softwaren. Andre værdier for cmd vil trykfordeler ikke reagere på, og en fejlmeddelse vil blive udlæst til displayet Pointer-argumentet is_end skal angive overfor den kaldende menu om den er aktiv. Den kaldende menu sender derfor en adresse til en lokal variabel og trykfordeler sætter variablens indhold til 1 hvis menuen er aktiv og 0 hvis ikke. Argumentet n_niveau angiver hvilket niveau menuen ligger på, dvs. hvor dybt i menutræet menuen befinder sig. Er det aktive niveau, angivet i n_position, det samme som argumentet n_niveau er menuen aktiv og det argumentet is_end peger på sættes til 1. Samtidig returneres nummeret på den undermenu der skal vises i displayet, ud fra hvad der står på p[n_position], hvilket også er tilfældet hvis n_niveau ikke er lig n_position, dog ændres det som is_end peger på til 0. Argumentet n_menu fortæller trykfordeler hvor mange undermenuer den kaldende menu råder over. Er cmd [<] eller [>] tælles p[n_position] op eller ned. Trykfordeler sørger for at værdien i p[n_position] aldrig bliver større end n_menu Er kommandoen [esc] eller [enter] og n_position er lig n_niveau kalder trykfordeler menutræets start igen. Dette gøres fordi n_position er blevet flyttet og en anden menu nu er aktiv. Denne situation indikeres overfor den kaldende menu ved at der returneres -1. I dette tilfælde skal den kaldende menu reagere på dette, ved at returnere 1, for at indikere overfor menuen i det overliggende niveau at alt gik godt i det underliggende niveau. Er typen i stedet sat til 0 reagerer trykfordeler anderledes på [enter], da n_position ikke tælles op, dog sættes is_end stadig til 1. Typen sat til 0 kan bruges hvis en menu ikke har undermenuer, men i stedet ændrer en indstilling ved tryk på [enter]. Returneringen af 1 fra en menu indikerer, at enden på menutræet er nået og alt er gået godt. Returneres der i stedet 0, hvilket ikke burde være muligt, er der sket en fejl. Figur viser flowchartet for trykfordeler. 127

132 KAPITEL 10. MODULDESIGN Start n_position = n_niveau? Ja cmd = INIT e lersetup? Ja Er cmd INIT var forrige tastetryk ESC eller ENTER, derfor: *is_end = 1 Returnérp[n_position] Nej Kaldende er ikke aktiv, derfor: *is_end = 0 Returnérp[n_position] Nej cmd = ESC? cmd = ENTER? cmd = LEFT? cmd = RIGHT? Ja Ja Ja Gå et niveau op i menu-træet: n_position Returnérdatavisning(INIT)-2 Ja Gå et skridt til venstre i menu: p[n_position]-- Returnérp[n_position] Gå et skridt til højre i menu: p[n_position]++ Returnérp[n_position] Gå et niveau ned i menu-træet: n_position++ Returnérdatavisning(INIT)-2 Ja type = 1? Nej Æ ndr ikke menu-træet, blot: Returnérp[n_position] Slut Figur 10.13: Flowchart for trykfordeler Menuer Under processen menusystem findes, udover trykfordeler, hovedmenu, datavisning, konfiguration og alarmlog. Funktionaliteten af modulerne er forskellige, men de kan alle opfattes som menuer, der kan laves over den samme skabelon. Dvs. de alle kan anvende trykfordeler. Dette indebærer at alle menuer skal lave mindste ét kald af trykfordeler og returnere 1 hvis trykfordeler returnerer -1. Menuer kan niveauinddeles som på figur Følgende afsnit beskriver menuerne og hvordan deres kald af trykfordeler foregår. Datavisning Datavisning er det øverste niveau i menu-træet og alle kald til menu-træet har sit udgangspunkt her. Datavisning står for at vise de aktuelle værdier som systemet, iflg. kravspecifikationen, skal råde over. Fælles for alle menuer, er at de kalder hovedmenu som deres undermenu og de anvender akt_maal til at finde de tilhørende værdier. Udfra datavisningsmenuens placering (n_niveau = 0), type (type = 1, da der er undermenuer) og antal undermenuer (n_menu = 4) sker følgende kald: trykfordeler(4, 0, 1, &is_end, cmd). Til trods for, at der ikke er nogen menuer over datavisning, skal den stadig kunne kaldes med et tastetryk eller en anden kommando. Prototypen for funktionen kommer derfor til at se således ud: int datavisning(char cmd); 128

133 10.3. MENUSYSTEM Datavisning (0,1) Hovedmenu (1,1) Konfiguration Alarmlog (2,8) (2,10) Dato (3,1) Alarm 0 (3,4) Tid (3.1) Alarm 1 (3,4) Lagringsinterval (3,8) Alarm n (3,4) Hukommelsestilstand (3,3) Alarm 9 (3,4) Alarmniveau (3,4) Slet hukommelse Slet alarmlog Standard indstillinger (3,2) (3,2) (3,2) Temp. øvre Temp. nedre RF øvre RF nedre (4,1) (4,1) (4,1) (4,1) Figur 10.14: Blokdiagram over menusystem. Niveauet af menuen samt antal undermenuer er vist i parentesen Menuernenes funktionalitet under datavisning kan ud fra kravspecifikationen, bestemmes til: Visning af aktuel temperatur og RF Kalder akt_maal(none, R_AKTTEMP) og akt_maal(none, R_AKTFUGT) hvis is_end er 1 og menu_hovedmenu hvis is_end er 0 Visning af gennemsnitstemperatur og fugt Kalder akt_maal(none, R_GENTEMP) og akt_maal(none, R_GENFUGT) hvis is_end er 1 og menu_hovedmenu hvis is_end er 0 Visning af max. og min. temperatur. Kalder akt_maal(none, R_MAXTEMP) og akt_maal(none, R_MINTEMP) hvis is_end er 1 og menu_hovedmenu hvis is_end er 0 Visning af max. og min. RF. Kalder akt_maal(none, R_MAXFUGT) og akt_maal(none, R_MINFUGT) hvis is_end er 1 og menu_hovedmenu hvis is_end er 0 129

134 KAPITEL 10. MODULDESIGN Hovedmenu Hovedmenuen giver adgang til det, der for brugeren ligner starten af menusystemet. Den råder over 2 undermenuer; Konfiguration og Alarmlog. Hovedmenuen skal ikke have adgang til dynamiske data, dvs. data, der ændrer sig hvert sekund. Den skal blot kunne kalde konfigurations-menuen og alarmlog-menuen, så kald af andre funktioner er begrænset til trykfordeler. Prototypen for funktionen er: int menu_hovedmenu(char cmd). Konfiguration Menuen konfiguration giver adgang til alle menuer der kan ændre på systemets opsætning. Prototypen for funktionen til konfiguration er int menu_konf(char cmd). Menuerne er inddelt på følgende måde: Dato: Er denne menu aktiv hentes tiden vha. funktionen henttid og tiden formateres så datoen vises på linie 2. Trykkes der [enter] kaldes funktionen menu_konf_dato hvor datoen kan indstilles. Ved at trykke [enter] på enten dag, måned eller år kaldes funktionen menu_konf_dato_indstil hvor disse kan indstilles med [<] og [>]. Når enten dag, måned eller år er indstillet kaldes stil_tid med [enter] og den nye dato indstilles. Trykkes der i stedet [esc] forkastes den indstillede værdi. Tid: Vælges denne menu vises tiden på linie 2, ved at kalde henttid og formaterer den indstillede tid. Trykkes der [enter] på menuen Tid kaldes funktionen menu_konf_tid hvor tiden kan indstilles. Trykkes der [enter] på timer, minutter eller sekunder kaldes menu_konf_tid_indstil og disse kan derved indstilles med [<] og [>]. Efter enten timer, minutter eller sekunder er blevet indstillet trykkes der [enter] for at indstille tiden. Trykkes der [esc] forkastes den indstillede værdi. Lagringsinterval: Menuen lagringsinterval sørger for at intervallet mellem hvor tit målinger gemmes, kan indstilles. Disse er iflg. kravspecifikationen blevet bestemt til at være 1 sek, 15 sek, 30 sek, 1 min, 5 min, 15 min, 30 min og 1 time. Disse implementeres i funktionen menu_konf_lagring ved at lade den råde over 8 undermenuer med et lagringsinterval tilknyttet. trykfordeler kaldes derfor med argumenterne trykfordeler(8, 3, 0, &is_end, cmd). n_menu er sat til 8 for hver lagringsinterval, n_niveau er på dette niveau i menutræet og typen er sat til 0 da der ikke er undermenuer tilknyttet lagringsintervallet. Hukommelsestilstand: Menuen hukommmelsestilstand indstiller systemet til at anvende hukommelsen som ringbuffer, fuld hukommelse eller sende måledata direkte til en PC. Dvs. at menuen skal råde over 3 undermenuer, hver med deres hukommelsestilstand tilknyttet. Er denne menu aktiv vises Huk. tilstand på linie 1 og den hukommelsestilstand systemet er indstillet er vist på linie 2. Trykkes der [enter] på menuen kaldes funktionen menu_konf_huktilstand hvor der kan vælges mellem de forskellige hukommelseslindstillinger. Ved tryk på [enter] ved den ønskede hukommelsestilstand kaldes 130

135 10.3. MENUSYSTEM indstillinger og de nye indstillinger skrives. Alarmniveau: Menuen råder over 4 undermenuer; Temp. øvre, Temp. nedre, RF øvre og RF nedre. Trykkes der [enter] på menuen kaldes funktionen menu_konf_alarmniveau og her kan vælges mellem Temp. øvre, Temp. nedre, RF øvre og RF nedre. Trykkes der [enter] på enten Temp. øvre eller Temp. nedre kaldes funktionen menu_konf_temp hvor alarmniveauet kan indstilles, alt efter hvilken menu, der blev valgt. Trykkes der i stedet [enter] på RF øvre eller RF nedre kaldes funktionen menu_konf_fugt hvor indstillingen foregår på samme måde som i menu_konf_temp. Alle 4 alarmniveauer indstilles med et kald af indstillinger med den værdi alarmniveauet skal have. Slet hukommelse: Trykkes der [enter] på denne menu kaldes menu_konf_slethuk. Menuen spørger efter bekræftelse på sletning af hukommelsen hvor < Nej > vises først på linie 2. Et tryk på [<] eller [>] skifter til < Ja >. Ved tryk på [enter] på < Ja > kaldes slethuk. Slet alarmlog: Trykkes der på [enter] på denne menu kaldes menu_konf_sletalarm. Menuen beder om bekræftelse på sletning af alarmloggen på samme måde som ved slet af hukommelsen. Standard indstillinger Vælges denne menu kaldes funktionen menu_konf_stdindstil hvor der spørges om bekræftelse af at gendanne standard indstillinger for systemet. Menuen kan vise enten Gendan: < Nej > eller Gendan: < Ja > og trykkes der [enter] på sidstnævnte kaldes standardindstilling. Alarmlog Menuen alarmlog viser de 10 sidste indkomne alarmer. Er der i forvejen 10 alarmer i alarmloggen slettes den ældste når der indtræffer en ny. Opbygningen af funktionen er anderledes da alle undermenuer ikke nødvendigvis er gyldige. Der sker derfor 2 kald af trykfordeler. Det første med typen sat til 0. Derved returneres blot hvilken undermenu der ønskes at gøre aktiv. Grunden til dette kald er at undermenuen (den gemte alarm) ikke nødvendigvis har alarmdata, der skal vises. Er cmd [enter] skal et kald af trykfordeler ikke tillades med typen sat til 1 hvis alarmen er ugyldig. Til at afgøre om alarmen, brugeren ønsker at se, har alarmdata anvendes structet alarmlog_elm med funktionen hent_alarmlog. Er alarmen gyldig vises datoen for dens indtræffen på linie 2, ellers skrives der ugyldig på linie 2. Menuens prototype er: int menu_alarmlog(char cmd) cmd er et tastetryk eller en kommando fra trykfordeler. 131

136 KAPITEL 10. MODULDESIGN Alarmdata for alle 10 alarmer varetages af én funktion der tager tastetrykket (cmd), alarmnummeret (alarmnr) og en adresse til et alarmlogelement ( data) som argument. Prototypen ser derfor således ud: int menu_alarmlogvis(char cmd, int alarmnr, alarmlog_elm *data) Kaldet af trykfordeler foregår med typen 0, da der ikke findes undermenuer til en visning af en alarm. Skriv til displayet prototypen Fælles for de foregående menuer er at de anvender funktion med void skriv_display(char linie1[size], char linie2[size]) Indholdet af argumenterne linie1 og linie2 skrives ud på linie 1 og linie 2 på displayet. For at skrive ud på displayet kaldes printg først argumentet linie1 og derefter med linie Test Udviklingen af menusystemet foregik ikke på minimumsystemet men i stedet i IDE68k s terminalbaserede simulator. Grunden er at denne simulator kunne tage imod tastaturtryk vha. C s getchar og skrive menutekst ud vha. printf på terminalen. Da menusystemet skulle sættes til at anvende det opbyggede minimumsystemet blev getchar erstattet med henttast og printf blev erstattet med printg. Testen af menusystemet er udført i acceptestspecifikationen og der henvises til appendiks B på side 164 for resultatet af denne test Skriv til display Der skal skrives et display-modul, der kan skrive til det udleverede display. I projektet er der kun behov for to linier, men det udleverede har 4 linier. Display-modulet skal opbygges således at det kan skrive til alle 4 linier på displayet, og skal samtidigt kunne styre de cursor-funktioner som display-controlleren besidder. Da displayets tegnsæt ikke er europæisk, skal de danske specialtegn defineres i display-controllerens CGRAM 3, der indeholder de brugerdefinerede tegn. For at opnå den mest effektive/hurtigste skrivning, optimeres koden således at det undersøges om displayet er aktivt inden der skrives til det. Det kunne vælges at indsætte et fast delay, der svarer til max instruktionstiden, som står opgivet i databladet, men ved at tjekke busy-flag et kan der spares tid når der skrives til displayet. Derudover er koden optimeret således at kun nye karakterer vil blive skrevet til displayet, og adressepointeren i datarammen på display-controlleren kun vil blive sat, hvis det tegn den skal til at skrive, ikke står ved siden af det forrige tegn, der blev skrevet. Der er blevet hentet informationer om controlleren i dens datablad, der findes på bilagscd en med filnavnet DISPLAY_CONTROLLER_hd44780.pdf. 3 Character Generator RAM 132

137 10.3. MENUSYSTEM Opdeling i funktioner For at initialisere displaycontrolleren, ændre indstillinger samt skrive data til det, skal der laves et antal funktioner. Det første, der skal ske med controlleren, er at den skal initialiseres og have indlæst danske specialtegn. Det vælges at lave to funktioner, der varetager denne opgave. int disp_init(void) Denne funktion er særlig vigtig, da denne initialiserer displaycontrolleren. Når displayet tændes, kan det ikke umiddelbart benyttes. Det skal sættes op hvor mange databen, der skal benyttes som interface til controlleren, hvor mange linier displayet er på, hvordan karaktererne skal se ud og om cursoren skal være sat til eller ej. Dette sættes op i denne funktion. Hvis funktionen kaldes, og den har returneret 0, er displayet initialiseret og klar til brug. Ellers returnerer den -1. En nærmere beskrivelse af hvad, der sker i initialiseringsprocessen kan læses i afsnit 7.1 på side 54. int disp_custom(void) Da det udleverede display har kinesisk tegnsæt, skal de danske specialtegn defineres. Der er plads til 8 specialtegn i displaycontrolleren. I denne funktion defineres følgende karakterer : æ, Æ, ø, Ø, å og Å. Tegnene laves som nøjagtige kopier af tegnene som de ser ud på det display, der har europæisk tegnsæt. Funktionen returnerer 0, hvis displayet har modtaget de danske special tegn og -1 hvis det ikke har. Når der skal skrives til controlleren, skal der inden afsendelse af hver byte undersøges om displayet er optaget, ved at tjekke om dets busy-flag er sat. int disp_bf(void) skal programmeres således at den læser busy flag et fra controlleren, og returnerer 1 hvis det er sat, og 0 hvis det ikke er sat. Der skal udvikles en funktion, der kan kaldes fra de øvrige funktioner, tage en tekststreng samt linie nummer som argument, og efterfølgende udskrive strengen på den rigtige linie. De funktioner, der får til opgave at løse dette er disp_send og printg. Printg, der er den funktion, der bliver kaldt fra de øvrige funktioner i systemet, tager den tekst streng, der skal udskrives på displayet og linie nr. som argument, og sender efterfølgende disse videre sammen med den tidligere streng, til disp_send. Er strengen kortere end de 16 karakterer, der er plads til på displayet, bliver der udskrevet tomme felter på de øvrige pladser. Er strengen længere end 16 karakterer vil de øvrige karakterer sidst i strengen blive skåret fra. Disp_send analyserer tekststrengen, scanner for æ, ø og å og retter disse til henvisninger til custom karaktererne i CGRAM en på displaycontrolleren. Hvis der er et i tekststrengen, vil dette blive udskiftet med et grader-tegn, som benyttes når temperaturen udskrives. int disp_send(char gammeltekst[], char nytekst[], int startposition) Denne tager, som nævnt, den gamle tekststreng, den nye tekststreng samt linie nr. som argument. Disp_send undersøger herefter om der skal skrives nye karakterer på displayet. Kun de nye karakter vil blive skrevet, og adressepointeren på controlleren, vil kun blive opdateret hvis de karakterer, der skal skrives, ikke er placeret ved siden af hinanden. Hvis de karakterer, der skal skrives, er placeret ved siden af hinanden, opdaterer adressepointeren sig selv i displaycontrolleren, da den altid tælles én op når der er skrevet en karakter. Et flowchart for denne funktion kan ses på fig på den følgende side. Foruden muligheden at skrive til displayet, skal det også være muligt at flytte cursoren. 133

138 KAPITEL 10. MODULDESIGN Funktionen til dette kaldes disp_placer_cursor og kaldes med linienummer samt plads som argument. De omtalte funktioner, er de eneste vitale funktioner. Med disse er det muligt at initialiserer displaycontrolleren samt skrive til displayet. Foruden disse funktioner vil det være praktisk at kunne benytte de cursorfunktioner, controlleren besider. Start Gammel tekst Ny tekst Start position Vælg næste karakter Sidste karakter? Ja Slut Nej Nej Sammenlign gammel tekst med ny tekst Ny karakter? Ja Udskriv karakter Ja Var forrige karakter ny? Nej Sæt adr.pointer Udskriv karakter Figur 10.15: Flowchart for send_disp Diverse opsætningsfunktioner int disp_setup(void) Denne funktion benyttes til at opsætte displayets cursor samt at tænde/slukke displayet. Når cursorfunktionerne kaldes, skriver de i et indstillingsarray, der i denne funktion sendes videre til displayet. Funktionen returnerer 0 hvis det gik godt og -1 hvis det ikke gik godt. int disp_on(void) Denne funktion tænder displayet. int disp_off(void) Denne funktion slukker displayet. int disp_cursor_on(void) Denne funktion tænder cursoren. int disp_cursor_off(void) Denne funktion slukker cursoren. int disp_cblink_on(void) 134

139 10.3. MENUSYSTEM Denne funktion får cursoren til at blinke. int disp_cblink_off(void) Denne funktion får cursoren til at holde op med at blinke. Alle de nævnte funktioner skriver i indstillingsarrayet og kalder efterfølgende disp_setup der sender indstillingerne til display-controlleren. void disp_placer_cursor(char linie, char plads) Denne funktion flytter cursoren til den ønskede plads på displayet. Funktionen benyttes i menusystemets indstillingsfunktion, hvor cursoren blinker ved det tal brugeren er ved at indstille. Denne funktion kan benyttes selv om cursoren er slået fra, men vil først blive vist når den aktiveres. Denne funktion bliver udført ved at sætte adressepointeren på displaycontrolleren. Test af modul For at verificere at den udviklede kode virkede, blev det sammen med et stykke testkode, sendt til boardet og det blev verificeret at der blev skrevet det rigtige ud på displayet. Testkoden, der blev skrevet, testede alle de funktioner, der er skrevet til display-modulet. Dvs. det flyttede cursoren, fik den til at blinke, tændte og slukkede displayet. Testkoden, der blev benyttet er følgende : int testafprintg() { disp_init(); printg("ææøøåå!&%x~#?-,.",1); printg(" <>\/%~",2); printg("aabbccddeeffgghh",3); printg("iijjkkllmmnnoopp",4); delay( ); printg("cursor ON 1,5",3); disp_cursor_on(); disp_placer_cursor(1, 5); delay( ); printg("cursor B ON 2,10",3); disp_cblink_on(); disp_placer_cursor(2,10); delay( ); //Initialiserer displaycontroller //Udskriver viste streng på 1. linie //Udskriver viste streng på 2. linie //Udskriver viste streng på 3. linie //Udskriver viste streng på 4. linie //Laver et delay på 1 sek. //Skriver "Cursor ON"+position //Tænder cursoren //cursor flyttes til 1.linie 5.tegn //Delay på 1 sek. //Skriver "Cursor B ON"+position //Tænder Cursor Blink //cursor flyttes til 2.linie tegn10 //Venter 5 sek. printg("cursor B Off 4,15",3); //Skriver "Cursor B Off"+position disp_cblink_off(); //Slukker cursor blink disp_placer_cursor(4,15); //Cursor flyttes til 4.linie,tegn15 delay( ); //Venter 5 sek. printg("cursor off",3); //Skriver "Cursor Off" på 3. linie 135

140 KAPITEL 10. MODULDESIGN } disp_cursor_off(); delay( ); disp_off(); delay( ); disp_on(); //Slukker cursoren //Venter 5 sek. //Slukker displayet //Venter 3 sek. //Tænder displayet igen De delays, der er indsat i koden, er lavet for at det er muligt at nå at se cursoren blive flyttet, se at den blinker og se at den til sidst holder op med at blinke. Testen forløb problemfrit og modulet blev inkluderet i den samlede projektfil. Også her fungerede modulet og det er derfor verificeret at modulet fungerer efter hensigten PC-grænseflade Til at realisere systemets PC-grænseflade, blev der i afsnit på side 96 designet en proces til at sende strenge til en pc og modtage kommandoer fra den. Processen skal desuden kunne fortolke den kommando, der modtages og sende de data retur, der bedes om. Overordnet ser flowet i processen ud som på figur Udover selve processen er PC! )#&% % $( * *! $#&% % '( ( tag Lager +, -.!" uelle m å linger té r mando mando Indstillinger Figur 10.16: Dataflow for PC-grænsefladen det nødvendigt med en initialiseringsrutine, der sætter ACIA en op med de nødvendige indstillinger, som beskrevet i designet af hardwaren i afsnit 7.5 på side Grænseflader For at kunne sende de relevante data over PC-forbindelsen skal processen kunne læse de datastrukturer, der indholder måledata, aktuelle målinger og indstillinger. Desuden skal processen gøre brug af de generelle rutiner til omregning af tid og til konvertering fra talværdier til karakterer til at generere de strenge, som skal sendes som karakterer over PC-forbindelsen. 136

141 10.4. PC-GRÆNSEFLADE Desuden skal det være muligt for funktioner i andre processer end PC-grænsefladen at gøre brug af modulet der sender en streng. Dette bruges, når systemet er sat til at sende måledata direkte til PC Moduler PC-grænsefladen er delt op i fire moduler som vist på figur Modulerne til at modtage og sende strenge skal kommunikere direkte med systemets hardware. Derfor vil disse moduler blive implementeret ved hjælp af assemblerfunktioner, der gør det muligt at tilgå hardwaren direkte. Send streng Modulet Send streng realiseres i assembler, da modulet skriver karakterer direkte til ACIA en på adresse $ og $ Modulet kan realiseres som en enkelt funktion med C- protoypen void txstr(char *). Funktionen kan kaldes fra C og tager en pointer til en streng som argument. Når en funktion i C kalder en assemblerfunktion med en streng, bliver en pointer til strengen lagt på stakken, og de enkelte karakterer kan flyttes fra den adresse pointeren indeholder og ud på adresse $ for at sende karaktererne over RS- 232 forbindelsen. Strengens sidste karakter skal have værdien NULL og ved at tjekke efter denne, identificeres enden på strengen hvor funktionen afsluttes. På figur er Start Gå til næste karakter Er karakter NULL? Nej Send karakter Ja Afslut vist et flowchart over modulets funktion. Figur 10.17: Flowchart for send streng modulet Test Funktionen testes ved at skrive en C-funktion, der kalder send streng-funktionen med en prøvetekst. Først kan funktionen testes i IDE68K-simulatoren, hvor det kan tjekkes at karaktererne bliver skrevet ud på adresse $ Herefter kan den hex-fil, der genereres ved kompilering af programmet uploades til mikroprocessorsystemet, og det kontrolleres 137

142 KAPITEL 10. MODULDESIGN at prøveteksten sendes ud over forbindelsen, ved at tilslutte den til en PC med et terminalprogram, der er sat op til at køre med 9600 baud, 8 databit, ingen paritet og 1 stopbit, som ACIA en bliver sat op til i forbindelse med initialiseringen. I første omgang testes programmets funktion i IDE68k-simulatoren, hvor det efterses at karaktererne, én efter én flyttes til adresse $ som er ACIA ens dataregister. Herefter kan programmet testes på selve mikroprocessorsystemet ved at uploade programmet og forbinde systemet med en PC. Denne skal have et åbent terminalprogram sat op til 9600 Baud, 8databit, 1 stopbit og ingen paritetsbit. Dermed kan det testes, at strengen bliver sendt til PC en. Programmet til test af send streng modulet kommer dermed til at se således ud: int main(void){ inacia(); while(1){ txstr( hej ); } return 0; } Testresultater Ved test i IDE68k-simulatoren blev følgende værdier lagt op i adresse $ i nævnt rækkefølge: $68, $65, $6A. Disse værdier er de hexadecimale asciiværdier for h, e og j. Ved upload af program til mikroprocessorsystemet og tilslutning af en PC, ses det at der udskrives en strøm af hej -strenge i PC ens terminalvindue. Dermed er sendstreng modulets funktion testet igennem. Modtag streng Modulet til at modtage strenge skal interruptstyres, så der ikke bruges tid på at polle på forbindelsen. Interruptrutinen, rxstr, kaldes, når ACIA en har modtaget en karakter, og den skal lægges over i en streng efter den seneste modtagne karakter. På figur er flowet i rutinen vist. Den længste gyldige kommando er 4 karakterer lang. Derfor sættes 5 bytes af til at gemme kommandoen i, da der skal være plads til at afslutte kommandoen med et NULL for at kunne behandle den som en streng. For at sikre, at der ikke skrives ud over den afsatte plads, kontrolleres det for hver modtaget karakter, at strengen ikke er for lang. Er bufferen fuld skrives forfra, og de tidligere modtagne karakterer overskrives. Når der modtages en carriage return flyttes strengen i bufferen over i en anden buffer, som kan hentes fra kommandofortolkeren. I denne buffer vil der dermed altid ligge en streng på maksimalt 4 karakterer. 138

143 10.4. PC-GRÆNSEFLADE Start Hent karakter Læg karakter i buffer Returnér modtaget karakter Er karakter \n? Ja Returnér \n Indsæt \0" i streng Nej Opdater bufferpointer Flyt kommando til ny buffer Er buffer fuld? Ja Nulstil bufferpointer Nej Afslut Figur 10.18: Flowchart for modtag streng modulet Interrupthåndtering For at få modtagerutinen til at køre, når ACIA en genererer et interrupt, skal der lægges en assembler jumpinstruktion ind et bestemt sted i hukommelsen, der peger på modtagefunktionen. Den brugte debugger/monitor flytter adressen for placeringen af funktionskaldet op i RAM en. For interrupt 5, som er det interrupt ACIA en er placeret på, skal kaldet ligge på adresse $400E8. Ifølge brugermanualen for M68k har interrupt 5 vektornummer 29 og adressen for jumpinstruktionen i et system med TS2MON kan dermed beregnes som: adr = $ vektornr 8 (10.3) Dette giver for interrupt 5 $400E8 og på denne adresse skrives instruktionen jmp _rxstr. 139

144 KAPITEL 10. MODULDESIGN Test Efter tilfredsstillende test af Send streng kan Modtag streng testes. Dette gøres ved hjælp af nedenstående C-program, der henter kommandostrengen og sender indholdet til en tilsluttet PC. int main(void){ /*Array til kommando*/ char *kommando; /*Opsætning af ACIA*/ inacia(); /*Udskriv kommandobufferen*/ while(1){ delay(500000); kommando = getkom(); txstr(kommando); } return 0; } Som det kan ses af programkoden, gøres også brug af delayrutinen fra afsnit på side 96. Dette gøres for at kunne adskille returneringen af de karakterer, der sendes til systemet fra den rutine, der returnerer hele kommandobufferen. Med indsættelsen af delay(500000) bliver der en pause på 5 sekunder mellem hver udskrivning af kommandobufferen. Desuden gøres brug af en funktion fra Kommandofortolkeren getkom(), som returnerer en pointer til kommandostrengen. Denne funktion er nødvendig, hvis hele strengen skal udlæses. Modulets evne til at modtage enkelte karakterer kunne også testes ved kun at implementere selve rxstr, da denne returnerer den modtagne karakter over PCforbindelsen. Det ville dog ikke have været muligt at teste at karaktererne bliver gemt rigtigt i en streng som kan læses af en C-rutine uden at gøre brug af getkom(). Desuden består getkom() kun af én linie assemblerkode, der flytter en adresse over i et dataregister, så en testrutine, der havde gjort det samme kunne ikke have været kortere. Testresultater Ved test af ovenstående program blev testet med karakterkombinationer, der svarer til de gyldige kommandoer, hlp, nu, send og slet, og i alle tilfælde blev kommandoen returneret over PC-forbindelsen. Kommandofortolker Kommandofortolkeren henter den streng som Modtag streng modulet har genereret udfra de modtagne karakterer. Kommandoen læses og hvis denne er gyldig, udføres den handling der er forbundet med dette. Kommandofortolkeren kalder først en assemblerfunktion, der returnerer en pointer til den streng som indeholder kommandoen. Strengen sammenlignes med de mulige gyldige kommandoer, og der køres en rutine, som genererer og sender strenge med de informationer, kommandoen er knyttet til. 140

145 10.4. PC-GRÆNSEFLADE Læses kommandoen send kaldes en funktion, der udskriver alle gemte målinger som strenge bestående af dato, tidspunkt, temperatur og fugtighed i henhold til de bestemte datastrukturer, se afsnit 9.4. Læses kommandoen nu kaldes en funktion, der udskriver de data, som er gemt i arrayet til aktuelle målinger, dvs. sidste målte temperatur og fugtighed, gennemsnit siden midnat, og max. og min. værdier i hukommelsen. Læses kommandoen slet kaldes funktionen dataopsamling_init, der nulstiller hukommelsen til målinger. Læses kommandoen hlp kaldes en funktion, der udskriver en liste over gyldige kommandoer. Læses en kommando, der ikke er én af overnstående udskrives en fejlmeddelelse, der gør opmærksom på ugyldig kommando samt en henvisning til hlp. Kommandoerne slet og hlp realiseres, som dele af kommandofortolkermodulet, da disse skal returnere strenge, som ikke ændrer sig fra gang til gang. Resten af kommandoerne skal hente informationer fra andre dele af systemet og realiseres derfor i Hent og formatér modulet. Efter at have gennemført én af ovenstående rutiner skal kommandobufferen nulstilles, så samme kommando ikke fortolkes mere end én gang. Dette gøres ved at skrive værdien NULL i strengbufferens første karakter. På figur ses et flowchart for forløbet af kommandofortolkeren. Kommandofortolkeren skal være en del af den pollingrutine, der kører hele tiden i systemet, så der hele tiden tjekkes for gyldige kommandoer. Funktionsprototyper Kommandofortolkeren kommer dermed til at bestå af 7 funktioner: int komfort(void) Den overordnede kommandofortolkerfunktion. char *getkom(void) Denne funktion skrives i assembler med navnet _getkom og returnerer en pointer til den streng, hvor den modtagne kommando findes. void resind(void) Denne funktion kaldes hver gang en gyldig kommando er blevet afviklet. Den skrives i assembler som _resind og skriver NULL i kommandobufferens første element. void sletalt(void) Funktionen, der kaldes, når kommandoen slet er modtaget. Efter at have slettet hukommelsen sendes en tekststreng, der bekræfter udførelsen af kommandoen. 141

146 KAPITEL 10. MODULDESIGN Start Hent kommando Tjek for send Ja Er huk. tilst. Send t. PC? Ja Send fejlbesked Nej Tjek for slet Ja Nej Nulstil Hukommelses pointere Udskriv målehukommelse til PC Nej Tjek for nu Ja Send info fra akt_maal array Nej Tjek for hlp Nej Ja Send kommandoliste Kommando!=0? Nej Ja Send fejlmeddelelse Nulstil kommandobuffer Afslut Figur 10.19: Flowchart for kommandofortolker modulet void sendhlp(void) Funktionen, der kaldes, når kommandoen hlp er modtaget. Hent og formatér Når kommandoerne send eller nu skal behandles, bliver Hent og formatér modulet brugt til at hente de måledata og tider, der skal skrives ud til PC en, og til at generere de strenge, der skal sendes til PC en. Modulet deles op i to funktioner, der behandler hver sin kommando. Funktionen til at behandle send kommandoen henter variablen, der indikerer hvor mange målesæt, der er gemt i hukommelsen. Hvert målesæt sættes ind i en streng med tidspunktet for målingen, der beregnes udfra starttidspunktet og det indstillede hukommelsesinterval. 142

147 10.4. PC-GRÆNSEFLADE Funktionen, der behandler nu kommandoen, tager elementerne i arrayet med aktuelle målinger, og sætter hvert element ind i en streng med navnet på værdien, som sendes til PC. Funktionsprototyper Med udgangspunkt i funktionsbeskrivelserne skal der dermed bruges følgende funktioner: void sendalt(void) Funktionen, der kaldes, når kommandoen send er modtaget. void sendnu(void) Funktionen, der kaldes, når kommandoen nu er modtaget. Test af modulerne Kommandofortolker og Hent og formatér Modulerne testes ved hjælp af GCC. Til dette skrives testudgaver af txstr(char *) og getkom(), således at strenge, der skal sendes bliver skrevet ud på skærmen og kommandoer bliver hentet fra tastaturet. Testprogrammet er vist herunder. int main(void){ /*Kør kommandofortolkeren*/ komfort(); return 0; } /*Testudgave af getkom, der henter fra tastatur*/ char *getkom(){ char kommando[6]; char *streng = kommando; printf("tast kommando:\n"); scanf("%s", streng); return streng; } /*Testudgave af txstr, der sender til skærm*/ void txstr(char *streng){ printf("%s\n", streng); } Desuden skal alle funktioner, der kaldes af Kommandofortolker og Hent og formatér, inkluderes i programmet. Det drejer sig om akt_maal(int, int), jiffytoiso (long int) og int2ascii(char *, int, int, int). Funktionerne indstillinger(int, int, int) og maalinger(int, int, int) kaldes også fra kommandofortolkeren, men kan ikke umiddelbart implementeres i testprogrammet. Derfor indsættes disse også som test funktioner, der ikke gør andet end at returnere 1. Dette resulterer i, at svaret på send -kommandoen ikke testes før modulerne 143

148 KAPITEL 10. MODULDESIGN implementeres. Testen af disse kommandoer henvises til accepttesten, da gennemførelsen af denne ligger i umiddelbar forlængelse af implementering af modulerne. Funktionen til sletning af målehukommelse, dataopsamling_init, skrives også som en testfunktion, der returnerer en tekststreng, da der ikke er noget dataopsamling at nulstille før implementering i systemet. Desuden gøres opmærksom på, at elementerne i akt_maal(int, int) ikke bliver skrevet til, hvorfor det ikke kan forventes, at der bliver skrevet gyldige måleværdier i strengene, der bliver sendt til PC. Testresultater Ved test af hlp -kommandoen blev kommandolisten med forklaringer af de 4 kommandoer udskrevet på skærmen. Ved test af slet -kommandoen blev den indsatte tekststreng Hukommelse slettes returneret, hvilket viser korrekt kald af funktionen. Test af selve dataopsamling_init er foretaget i forbindelse med test af dataopsamlingen. Ved test af nu -kommandoen blev der udskrevet en liste med navne på de værdier, som ønskes udskrevet. Værdierne i hvert element lå udenfor måleområderne, men dette skyldes, at der ikke er skrevet værdier ind i array et i akt_maal(int, int) i forbindelse med denne test. Ved test af send -kommandoen returneres ingen tekststrenge, da der ikke findes gyldige data i de funktioner, der skal hente indstillinger og målinger. Denne kommando tjekkes efter implementering i forbindelse med accepttesten i afsnit B på side 164. Initialisering af PC-forbindelse Ved opstart af systemet skal PC-forbindelsen initialiseres, da det ikke er muligt ellers at kende tilstanden ACIA en er i ved opstart. Dette realiseres ved hjælp af en rutine, der første laver en master reset på ACIA en ved at skrive % til kontrolregistret på adresse $ Herefter sættes ACIA en op som specificeret i hardwaredesignet, afsnit 7.5 på side 74. Herefter opsættes bufferen, der bruges til at gemme modtagne karakterer i. Dette gøres ved at gemme adressen på den første karakter i kommandostrengen i en variabel, som kan tælles op efterhånden som karakterer modtages. Start Reset ACIA Sæt ACIA kontrolreg. Nulstil indbuffer Sæt M68k Statusreg. Slut Figur 10.20: Flowchart for initialisering af PC-forbindelse Til sidst sættes M68k s statusregister op til at reagere på interrupt ned til interrupt 5, så systemet vil køre modtagerutinen, når ACIA en genererer et interrupt for modtaget karakter. 144

149 10.4. PC-GRÆNSEFLADE Test Initialiseringsrutinen, inacia, testes vha. simulering i IDE68k-simulatoren. Her tjekkes det at opsætningsværdierne skrives til ACIA ens kontrolregister på adresse $ og at statusregistret bliver sat op til $2400. Herefter kan programmet testes på mikroprocessorsystemet. Der kan testes for at runtinen kan køre, og at processorens statusregister bliver sat rigtigt op ved at udlæse dette i TS2MON. Opsætningen af ACIA ens kontrolregister kan ikke umiddelbart testes, da dette ikke kan udlæses. Derfor vil test af opsætningen blive foretaget i forbindelse med test af send og modtag streng modulerne. Testresultater I forbindelse med test af inacia i simulatoren blev der skrevet værdierne $03 og $95 på adresse $800005, som svarer til ACIA ens kontrolregister. $03 svarer til den binære værdi % , som først skrives for at nulstille ACIA en. $95 svarer til den binære værdi % , som skrives i anden omgang for at sætte ACIA en op. Når funktionen i derefter lægges op på mikroprocessorsystemet, køres programmet igennem uden problemer, og ved udlæsning af processorens statusregister, ses det at dette er blevet sat op til $ Test af PC-grænseflade Modulerne til at sende og modtage strenge er testet i forbindelse med moduldesignet i de foregående afsnit. Derfor er ydeligere test af disse ikke nødvendig. Kommandofortolkeren derimod er kun testet ved hjælp af GCC på en PC. Derfor skal der gennemføres et testforløb af dennes funktion. Dette gøres ved at implementere funktionerne i mikroprocessorsystemets software og sende de 4 kommandoer til det via PCforbindelsen. Det testes, at de informationer, der returneres, er i overensstemmelse med den kommando, der er sendt. Denne test er beskrevet i detaljer i accepttesten, appendiks B på side

150 Del V Implementering 146

151 Kapitel 11 Integrationsstrategi Efter at have gennemført moduldesign af både hardware og software, bør systemet umiddelbart kunne integreres til en helhed, blot ved at samle alle modulerne. Hardwaremodulerne er opbygget, og testet i det omfang det er muligt uden software. Alle software moduler er skrevet, og testet enkeltvis. Derfor mangles nu at få dem til at fungere i samarbejde med hinanden. I praksis foretages integrationen ved trinvist at sætte flere og flere moduler sammen, indtil alle moduler til sidst er integreret og der haves et færdigt system som er klart til gennemførelse af accepttesten. Ved at integrere systemet i små trin, gives mulighed for at kunne debugge undervejs, således at fejl udryddes efterhånden som de kommer til udtryk. Efter en større del af programmet, som f.eks. en proces, er implementeret, kontrolleres at de trin i accepttesten som er relevant for denne, og ikke afhænger af endnu ikke implementerede processer, kan gennemføres. Da flere af modulerne er afhængige af hinanden, er det vigtigt at overveje hvilken rækkefølge de implementeres i. Først implementeres og testes de hardwarenære moduler, da de er nødvendige for systemets samlede funktionalitet. Implementeringen af disse moduler vil blive beskrevet i det følgende afsnit. Når alle hardwarenære moduler er testet og fungerer kan resten af softwaren tilføjes. Dette gøres ved at tilføje en proces ad gangen. Dette vil blive beskrevet i afsnit 11.2 på næste side Hardwarenære moduler Da mange af modulerne i systemet er afhængige af en række hardwarerelaterede moduler og funktioner, som sørger for kommunikationen med hardwaren, skal disse implementeres først. Disse hardwarenære moduler samt test af dem er allerede beskrevet i forbindelse med moduldesignet. Formålet med dette afsnit er at redegøre for den rækkefølge som implementeringen er foretaget i. Mange af de hardwarenære moduler kan godt fungere selvstændigt, og er dermed ikke direkte afhængige af de andre. Det skal dog stadig sikres, at de fungerer, inden de moduler, som er afhængige af dem, implementeres. 1. Delayfunktion: For at implementere displaymodulet kræves mulighed for at indsætte ventetid. 147

152 KAPITEL 11. INTEGRATIONSSTRATEGI 2. Display: Displaymodulet implementeres som det første, da det er vitalt for at kunne vise output fra systemet. 3. Knapper: For at kunne få input til systemet implementeres hent-tast funktionen tidligt. 4. TS2MON debugrutiner: For at kunne udlæse debugging information, mens programmet kører, implementeres en række rutiner, som kan skrive strenge og tal ud til terminalen. 5. I 2 C-controller: For at kunne tage målinger og gemme dem i EEPROM en er I 2 C- bussen nødvendig. 6. Temperatur og fugtighedssensor: Disse funktioner kan passende bruges til at teste I 2 C-bussen. 7. EEPROM: For at kunne gemme måleresultaterne skal der kunne skrives til EE- PROM en. 8. Ur: For at kunne starte dataopsamlingsmodulet kræves en interruptrutine som skal køre hvert sekund. 9. ACIA til PC: Dette modul implementeres som det sidste, da det kun er processen PC-grænseflade som gør brug af den, og denne proces har ikke den store funktionalitet hvis ikke dataopsamlingen har genereret nogen data som kan overføres Procesintegration Efter det hardwarenære software er blevet implementeret og afprøvet kan de øvrige processer afprøves på systemet. Processerne aktiveres enkeltvis for at sikre at hver proces fungere. Fælles for integrationen af de 3 processer er at de testes med hele koden kompileret. Modulerne aktiveres ved at kalde initialiseringsfunktionerne i main funktionen. Følgende kildekodefiler samles i et projekt i IDE68k og kompileres: cstart.asm acia.asm delay.asm sekhandler.asm ts2routines.asm henttast.c komfort.c alarm.c dataopsamling.c eeprom.c i2c.c int2ascii.c isodate.c skrivtildisp.c menu_alarmlog.c 148

153 11.2. PROCESINTEGRATION menu_tid.c menu.c Clib.asm De efterfølgende afsnit tager udgangspunkt i ovenstående kode, dog med forskellige main funktioner til at initialisere funktionaliteter i koden Menusystem Den første proces der implementeres er menusystemet. Menusystemet afprøves uden software der gør brug af interrupt. Dvs. at der hentes ikke data fra sensorer og at tiden ikke opdateres. Der anvendes følgende main funktion til at starte systemet: main(){ char ch; /*Kode til initialisering START*/ i2c_setup(); /*Initialiser I2C*/ disp_init(); /*Initialiser display*/ /*Kald datavisning med SETUP for at initialisere variabler i trykfordeler:*/ datavisning(setup); /*Kode til initialisering SLUT*/ } while (1){ /* Poll efter tastetryk */ /*Reager kun på et tastetryk hvert 180ms for at fjerne prell*/ delay(180000); ch = henttast(); /*Afgør om tastetrykket kan anvendes:*/ if (ch == ESC ch == ENTER ch == LEFT ch == RIGHT){ datavisning(ch); } } I ovenstående kode er der udeladt kode, der initialiserer ACIA en til PC-forbindelsen og aktiverer interrupt da disse starter processer udover menusystemet. Efter at koden er overført til systemet kan det lade sig gøre at navigere rundt i menusystemet og indstillinger kan ændres, hvilket indikerer at der overføres data over I 2 C-bussen som forventet. Med den nuværende funktionalitet af systemet, vælges det at gå videre med at aktivere de resterende processer Sekundhåndtering Implementeringen af menusystemet indikerede at I 2 C-bussen fungerede, hvorfor processen sekundhåndtering startes, der i stor udstrækning gør brug af I 2 C-bussen. main funktionen udvides til følgende kode for at aktivere processen sekundhåndtering: 149

154 KAPITEL 11. INTEGRATIONSSTRATEGI /*Kode til initialisering START*/ i2c_setup(); /*Initialiser I2C*/ disp_init(); /*Initialiser display*/ /*Sæt systemet til at anvende standardindstillinger:*/ standardindstilling(); init_foerstegang(); /*Hent indstillinger og anvend disse*/ irq_setup(); /*Skriv interruptvektorer i TS2MON s RAM*/ ur_irq_on(); /*Sæt SR til at reagere på interrupt 3*/ /*Kald datavisning med SETUP for at initialisere variabler i trykfordeler:*/ datavisning(setup); /*Kode til initialisering SLUT*/ Samtidig tilføjes følgende kode under polling-løkken for at opdatere værdier på displayet når der er hentet nyt data: henttid(&tid); if (tid!= sidstetid){ datavisning(refresh); sidstetid = tid; } Aktivering af processen sekundhåndtering har ikke nedsat den funktionalitet af menusystemet, der tidligere er opnået. Navigation i menusystemet er stadig mulig, og uret er begyndt at køre. Samtidig bliver der hentet måleværdier fra sensorerne, der vises i menuen datavisning. Det kan dog ikke ses om der bliver gemt målinger i hukommelsen, da PC-grænsefladen mangler til at udlæse hukommelsens indhold PC-grænseflade PC-grænsefladen aktiveres som det sidste da funktionaliteten af denne proces ikke er systemkritisk, dvs. nødvendig for at resten af systemet kan fungere. Funktionen main skrives færdig således at alle processer aktiveres ved opstart af systemet. Nedestående kode viser den endelige main funktion, der anvendes på systemet: main(){ char *p, ch, oldch; int n; unsigned long tid, sidstetid; /*Kode til initialisering START*/ irq_setup(); /*Skriv interruptvektorer i TS2MON s RAM*/ inacia(); /*Initialiser ACIA til PC-grænseflade*/ p = getkom(); /*Hent adressen til kommandobuffer*/ *p = 0; /*Nulstil kommandobuffer*/ i2c_setup(); /*Initialiser I2C*/ disp_init(); /*Initialiser display*/ 150

155 11.2. PROCESINTEGRATION /*Sæt systemet til at anvende standardindstillinger:*/ standardindstilling(); init_foerstegang(); /*Hent indstillinger og anvend disse*/ /*Udskriv velkomst til terminal når system tændes:*/ txstr("\n\n\rklimamonitor beta 47 up n running!\n\r\n Tast hlp for liste over kommandoer.\n\r#"); stiltid(0x0834f512); /*Sæt starttidspunkt*/ ur_irq_on(); /*Sæt SR til at reagere på interrupt 3*/ /*Kald datavisning med SETUP for at initialisere variabler i trykfordeler:*/ datavisning(setup); /*Kode til initialisering SLUT*/ while (1){ /* Poll efter tastetryk i uendelig løkke */ /*Aktiver kommandofortolkeren for at undersøge om der er en gyldig kommando i kommandobufferen:*/ komfort(); n = 0; /*Vent længe hvis tastetryk er det samme*/ while ((ch == oldch) && (n<10)){ delay(20000); ch = henttast(); n++; } henttid(&tid); /*Hent systemtiden*/ if (tid!= sidstetid){ /*Hvis tiden har ændret sig...*/ datavisning(refresh); /*Opdater menusystemet..*/ sidstetid = tid; /*og marker tiden for sidste opdatering*/ } } } ch = henttast(); /*Hent tastetryk*/ /*Afgør om tastetrykket kan anvendes*/ if (ch == ESC ch == ENTER ch == LEFT ch == RIGHT) datavisning(ch); Ved at tilslutte en PC til serielporten og starte et terminalprogram kan processen PCgrænseflade testes, samt dataopsamlingens funktion. Efter afvikling af programkoden med den nye initialiseringskode blev følgende udskrevet i terminalprogrammet: Klimamonitor beta 47 up n running! Tast hlp for liste over kommandoer. # Kommandoen send afprøves for at udskrive indholdet af hukommelsen. Systemet udskriver de målinger, der er gemt i EEPROM en og det kan derved konkluderes at systemet er begyndt at hente måledata fra sensorerne og gemme disse i hukommelsen. 151

156 KAPITEL 11. INTEGRATIONSSTRATEGI Udfra den opnåede funktionalitet vælges det at gennemføre accepttesten for at undersøge om alle dele af systemet fungerer som bestemt i kravspecifikationen. 152

157 Kapitel 12 Udførsel af accepttest For at verificere at systemet lever op til de krav, der er stillet til det, er der i forbindelse med kravspecifikationen udarbejdet en accepttestspecifikation. Dette afsnit vil omhandle de fejl og mangler, der blev fundet på systemet under udførsel af denne accepttest. Ikke alle fejl, der bliver nævnt, er fejl i henhold til kravspecifikationen, men grundet de konsekvenser, de medfører, må de betegnes som fejl. De test, der står listet i accepttesten, blev udført i den rækkefølge, de står beskrevet. Testen blev udført i universitetets laboratorium, hvor der er adgang til et klimaskab, der kan køle ned til -30 C og varme op til 100 C. Under testen blev visse fejl og mangler konstateret. Disse fejl og mangler vil blive beskrevet i dette kapitel Software-bugs Kommunikation mellem computer og klimaanlæg Det skete periodisk, at kommandofortolkeren ikke fortolkede de kommandoer, der blev sendt via terminalprogrammet. Efterfølgende skulle samme kommando sendes et antal gange (typisk 3-5 gange) inden kommandofortolkeren accepterede kommandoen og svarede i henhold til kravspecifikationen. Der blev ikke fundet nogen årsag eller løsning på dette problem. Ustabil I 2 C-bus Der har været problemer med I 2 C-bussen. Det skete ofte, at I 2 C-controlleren ikke blev nulstillet ordentligt og derfor ventede efter data på bussen, der aldrig kom. Dette resulterede i et timeout i I 2 C-modulet, hvilket stod på til controlleren igen blev nulstillet. Ofte skulle den nulstilles flere gange før den begyndte at fungere igen. Dette problem blev der ikke fundet nogen løsning på i projektperioden. 153

158 KAPITEL 12. UDFØRSEL AF ACCEPTTEST Manglende målinger under udlæsning Hvis der benyttes ringbuffer som hukommelsestilstand, og hvis ringbufferen er fyldt, opstår der problemer med at ikke alle målinger udskrives under overførsel til PC. Grunden til dette er at den variabel, der peger på ældste måling, som bestemmer hvorfra målingerne skal udskrives, bliver flyttet hver gang der tages en ny måling. Da dataopsamlingen kører sideløbende med dataudlæsningen til PC, vil der hver sekund 1 ske en flytning af pointeren, der peger på ældste måling. Hvert sekund vil udlæsningen springe over en måling, hvilket medfører at der vil være målinger, der ikke bliver udlæst. Da tidsstemplingen af målingerne beregnes ud fra starttiden og tiden mellem dem, vil det ikke kunne ses på de data, der bliver udlæst, at der er en fejl. Som løsning på dette problem kunne det vælges ikke at foretage dataopsamling mens en dataoverførsel til PC er igang. Dette kan dog give et problem med tidsstemplingen af målingerne, da alle målingerne da ikke vil være taget med samme interval, hvilket er en forudsætning for at kunne lave tidsstempling kun ud fra starttiden og måleintervallet. Data gemmes først efter et måleinterval Når en dataopsamling påbegyndes, vil første måling blive taget, når der er gået den tid som måleintervallet er sat til. Sættes måleintervallet til en time, vil der gå 1 time før der bliver skrevet en måling til hukommelsen. Det kunne være en fordel hvis første måling blev taget med det samme dataopsamlingen blev påbegyndt. Problemer med max/min værdier Der vil først blive beregnet maximum og minimum værdier efter der er gemt en måling. Hvis måleintervallet er sat til 1 time, vil der gå 1 time før max/min værdierne bliver gemt. Årsagen til dette er, at max/min-funktionerne nulstiller, når antallet af gemte målinger er nul. Når der ikke er taget målinger, skal de nulstille, men da første måling først tages, når der er gået den tid, der er sat som måleinterval, kan der gå op til en time før funktionerne holder op med at nulstille. Når funktionerne nulstiller, vil max- og min-værdierne være de samme som de aktuelle temperatur- og fugtighedsværdier. 1 Denne beskrivelse tager udgangspunkt i at måleintervallet er ét sekund, hvor problemet er mest udtalt. 154

159 Kapitel 13 Udvidelsesmuligheder Efter implementering af et klimaovervågningssystem baseret på den kravspecifikation som blev opstillet i kapitel 3, kan det konstateres, at der er en række yderligere funktioner som ville have været ønskelige i et klimaovervågningssystem. I dette kapitel beskrives først de software funktionaliteter som kunne være ønskelige. Derefter beskrives de mulige hardwaremæssige udvidelser som kunne foretages på systemet Software Der er flere funktioner, der kunne være fordelagtige at implementere. Grundet den begrænsede projekttid, der er til rådighed, har der dog ikke være mulighed for dette. Disse funktioner vil her blive beskrevet. Midlet temperatur/luftfugtighed-værdier Da temperaturen, der læses, ofte svinger med ± 0,2 C vil det være praktisk hvis den værdi, der vises som aktuel måling bliver midlet over de sidste 5-10 sekunder, så temperaturen ikke vil svinge som den gør nu. Denne funktion ville også være praktisk at implementere i dataopsamlingen, så den måling der gemmes er midlet over de sidste 5-10 sekunder. Indikation af temperatur/luftfugtighed udvikling Det vil være nyttigt, hvis der i displayet bliver angivet om temperaturen samt luftfugtigheden er stigende eller faldende. Dette kan realiseres ved at sætte en pil ind, der enten peger op eller ned alt efter hvordan udviklingen er. Snooze funktion Hvis der sættes en sirene eller andet forstyrrende på alarmbenet vil det være at foretrække at sirenen kan slås fra når brugeren er blevet opmærksom på at der er alarm. Denne funk- 155

160 KAPITEL 13. UDVIDELSESMULIGHEDER tion kan med fordel slukke alarmen i f.eks. 5 min. hvorefter den påny skal give alarm hvis alarmgrænsen stadig er overskredet. Alarmlog over terminal Det vil være praktisk hvis alarmloggen kan udlæses over terminalen på lige fod med de måledata, der er gemt. Menu over terminal Det ville være praktisk, hvis systemet kunne styres over terminalen. På denne måde vil indstillingerne kunne ændres uden at brugeren er i nærheden af systemet. I princippet vil det være muligt at ændre indstillinger fra et hvilket som helst sted i verden. Der kræves blot at den PC hvor terminalprogrammet kører på er på internettet. Tidsstempling Det vil i nogle situationer være en fordel, hvis der blev knyttet et tidsstempel til hver enkelt måling, i stedet for kun at gemme tiden for den første måling. Sidstnævnte metode kan give problemer hvis f.eks. strømmen til systemet afbrydes, og således står til et andet tidspunkt næste gang det startes op. De nye målinger vil så komme til at ligge i forlængelse af de gamle, og når de udlæses, vil deres tidsstempling se ud som om de er taget umiddelbart efter. Der er et tilsvarende problem hvis uret stilles imens der tages målinger. Dette vil ikke ændre på tidsstemplingen af de målinger der tages. Først når målingerne slettes, ved f.eks. at vælge nyt måleinterval, vil dataopsamlingen starte forfra med den nye tidsstempling. En løsning på dette problem kan som nævnt være at tilføje et tidsstempel til hver enkelt måling, hvilket dog vil resultere i at tidsstemplingen fylder mere end måledataene. Alternativt kunne det forestilles at der blev lavet mulighed for at indsætte et nyt starttidspunkt midt i rækken af målinger, således at alle målinger tages efter denne nye starttid blev stemplet i forhold til denne. Denne mulighed kunne udnyttes når der har været strømafbrydelse, eller uret indstilles. Checksum Det vil være fordelagtigt hvis der overføres en form for checksum 1. sammen med måledataene, således at det kan kontrolleres om der er sket nogen fejl under overførslen. Dette kunne f.eks. implementeres ved at bruge en protokol, som er beregnet til filoverførsel, et eksempel på en sådan protokol kunne være Xmodem. 1 En sum, der beregnes på baggrund af de data, der sendes/modtages 156

161 13.2. HARDWARE 13.2 Hardware De mulige forbedringer, der her har været omtalt indtil nu har alle været software relaterede. Der kan herudover også foretages visse forbedringer og udvidelser på hardwaren. Disse vil her blive beskrevet. Systemet kan, pga. I 2 C-bussen, forholdsvist nemt udbygges. Det er muligt at montere op til 8 temperatur-sensorer og 4 luftfugtighedssensorer, som systemet ser ud nu. På ADconverteren kan der, foruden luftfugtighedssensorer, monteres f.eks. lufttrykssensorer, eller andre sensortyper. Det eneste, der kræves er en sensor som giver et spændingssignal. Der kan også tilføjes flere AD-convertere, og dermed flere fugtighedssensorer, eller andre typer af sensorer. Der kunne med fordel monteres et backupbatteri, der i tilfælde af strømafbrydelse, vil være i stand til at forsyne systemet med strøm i en given tidsperiode. Hvis dette blev implementeret, ville det være en fordel at den software, der ligger i systemet er i stand til at operere i en minimum tilstand, hvor displayet bliver slukket og evt. slukker for andre unødvendige enheder hvis der eksisterer sådanne. 157

162 Kapitel 14 Konklusion Efter at have analyseret, specificeret, designet og konstrueret systemet, og derefter gennemført accepttesten af det, kan det konkluderes at det fungerer som specificeret, med enkelte undtagelser. Det blev fra starten valgt, at systemet skulle bygges over et minimumsystem. Minimumsystemet udgør en platform for de hardwaremoduler, der skal tilføjes for at systemet kan opfylde de krav, der gennem analysen blev stillet til systemet. Desuden giver minimumsystemet mulighed for afvikling af debugger/monitorsystemet TS2MON som kan bruges til fejlfinding og overvågning af programafviklingen. Minimumsystemet fungerede efter konstruktionen, hvorefter det kunne udvides med de yderligere hardwaremoduler, der kræves, for at realisere klimaovervågningssystemet. Disse blev testet, i det omfang det var muligt uden software. Softwaren blev designet ved at nedbryde programmet i tre processer, som blev inddelt i en række moduler. Endeligt blev disse moduler designet i form af specifikation af en række funktioner, som umiddelbart kunne realiseres i form af programkode. Disse moduler blev testet enkeltvis og derefter integreret procesvis til det samlede program. Efter at have samlet hele systemet blev accepttesten gennemført, og der blev i denne forbindelse konstateret enkelte problemer med softwaren, som ikke blev løst inden projekafleveringen. Der var to væsentlige problemer med systemet, det ene var at systemet indimellem misfortolkede de kommandoer som blev sendt fra PC en. Det andet var I 2 C- bussen, som periodisk begyndte at lave timeouts, hvorefter den ikke kunne bringes tilbage til funktion uden at resette systemet. Valget af I 2 C-bussen til kommunikation med sensorer og en del af hukommelsen, giver desuden mulighed for at systemet kan udvides med en lang række I 2 C-enheder. Derved er det kun softwaredelen af systemet, der skal modificeres, hvis systemet ønskes udvidet med flere sensorer eller mere hukommelse. Det samlede klimaovervågningssystem fungerer derfor med de ovennævnte begrænsninger. Systemet fungerer i en sådan grad, at det i praksis er muligt at overvåge klimaet i form af temperatur og relativ luftfugtighed. Der er endvidere mulighed for at lagre målinger og udlæse dem fra en PC, ligesom alarmer også kan udlæses på displayet. 158

163 Appendiks A Foreløbig brugervejledning Inden brug af systemet, anbefales det at læse denne brugervejledning igennem. Før brug Brugeren skal før brug sørge for at tilslutte temperatur- og fugtighedssensor(er). Hvis det ønskes at udlæse data til PC skal denne have et terminalprogram installeret og tilsluttes stikket mærket RS232 på enheden. Desuden kan en ekstern alarmsignalgiver tilsluttes alarmudgangen. Opstart Systemets ur og dato skal indstilles for at sætte systemet i stand til at tidsstemple målinger og gemte data. Desuden skal det ønskede lagringsinterval, samt alarmniveauer for temperatur og fugtighed indstilles. Hvis dette ikke sker har systemet et sæt standardindstillinger, der bruges. Daglig brug Udlæsning af data på display Når systemet anvendes første gang vil displayet vise temperatur og fugtighed. Ønsker man at kende max-, min- og gennemsnitsværdier trykkes på [<] eller [>] indtil den ønskede værdi fremkommer. Udlæsning af data til PC For at data kan udlæses på en PC skal denne være tilsluttet. Dataene tilgås ved hjælp af et sæt kommandoer fra PC ens terminalprogram. De gyldige kommandoer er vist i tabel A.1. Alarmhåndtering Når der indtræffer en alarm viser displayet! i datavisningsmenuen ud for fugtighed eller temperatur, alt efter hvad der er overskredet. 159

164 APPENDIKS A. FORELØBIG BRUGERVEJLEDNING Kommando nu send slet hlp Forklaring Udlæs øjeblikkelig temperatur og fugtighed, gennemsnit og ekstrema Overfør alle målinger gemt i hukommelsen Slet alle gemte målinger Udskriv liste over kommandoer og deres funktion Tabel A.1: Kommandoer I alarmlog-menuen vil den aktuelle alarm være først, og ved at trykke [enter] udlæses data for alarmtypen, starttidspunkt, varighed og max værdi. I tilfælde af at både temperatur og fugtighed er overskredet, vil displayet vise! ved både temp. og fugt. Når man går ind i alarmlogmenuen ved hjælp af [enter], vil den alarm der startede sidst vises først. Menusystemet På figur A.1 ses et kort over den samlede menustruktur. I det følgende gennemgås brugen af de enkelte menuer. sning edmenu tion #$ %. og o #$ % 1 m 1 #$ % 2! " m 2 #$ %& #$ % n '%)(! ø m n '%)(! *! ø * +,' %)%& - ræft +. indstil. - ræft Figur A.1: Menusystemets opbygning 160

165 Datavisning Denne menu er den øverste i menusystemet. ###.#C t. ###% < >. ###.#C fugt. ###% < >. t. t ###.#C ###.#C < >. f ugt. ###&. f ugt. ###% Figur A.2: Datavisning På displayet vises den øjeblikkelige temperatur og fugtighed for sensorerne. Ved af trykke [<] eller [>] skiftes mellem de øjeblikkelige målinger, middelværdierne af de gemte målinger, samt max. og min. værdier i hukommelsen. Ved at trykke [enter] skiftes til hovedmenuen. Der kan vendes tilbage til datavisningsmenuen ved tryk på [esc].!" menu - #%$ '&)(+*,'-. /0* on > < > 12!" menu - #4365 /7. 8 5,:9 Figur A.3: Hovedmenuen Menu I -Hovedmenu- kan der med piletasterne [<] og [>] vælges mellem Konfiguration og Alarmlog. Menuen vælges med [enter]. Fra konfigurations- og alarmlogmenuerne kan der vendes tilbage til hovedmenuen med [esc]. Konfiguration I konfigurationsmenuen kan der vælges mellem følgende indstillelige parametre: Dato, Tid, Lagringsinterval, Hukommelsestilstand og Alarmniveauer. Der bladres mellem parametrene med [<] og [>] og den parameter, der ønskes indstillet vælges med [enter]. ;<)= o: = er < > < > < > = = ;<)= o: ##/##/## er o: ##/##/## er o: = er Figur A.4: Indstilling af dato. Tiden indstilles på samme måde Dato og tid indstilles talvis. Det ciffer der indstilles er understreget og værdien ændres med [<] og [>]. Når der trykkes [enter] efter indstilling af sidste tal gemmes indstillingen. Den indstilling man er i gang med at foretage kan annulleres med [esc], og der hoppes tilbage til datovisningen. BDC7EGFIH JGEGKH JDL MNF O'CNP 1 sek MNJDL er BDCNEGF+H JQEGKH JDLMF O'C7P < 1 sek > < > MJL er Figur A.5: Indstilling af målehyppighed. Hukommelsestilstand indstilles på samme måde Under Lagringsinterval og Huk. tilstand kan der vælges mellem et sæt faste indstillinger. For Lagringsinterval kan der vælges mellem 1 sek, 15 sek, 30 sek, 1 min, 5 min, 15 min, 30 min og 60 min. 161

166 APPENDIKS A. FORELØBIG BRUGERVEJLEDNING For Huk. tilstand kan der vælges mellem Ringbuffer, Fuld huk. 1 og PC 2. Der skiftes mellem indstillingsmulighederne med [<] og [>] og den valgte indstilling gemmes med [enter], hvorefter displayet vender tilbage til konfigurationsmenuen. Ønsker man ikke at vælge en ny indstilling trykkes [esc] og der vendes tilbage til konfigurationsmenuen. ø ### C er < > ø < ### C > er Figur A.6: Indstilling af øvre temperaturgrænse. Nedre temperaturgrænse samt grænser for fugtighed indstilles på samme måde Alarmniveauerne indstilles ved at vælge niveauet, der skal indstilles med [<] og [>], for derefter at trykke [enter] og ændre værdien med [<] og [>]. Indstillingen gemmes med [enter] eller annulleres med [esc], hvorefter der vendes tilbage til menuen hvor alarmniveauer vælges til justering.! er "$# %! er < > < Ja >! er Figur A.7: Sletning af målehukommelse. Indstillinger nulstilles på samme måde Desuden er det muligt at vælge Slet hukommelse for at slette alle gemte målinger og Std. indstil, der sætter parametrene Lagringsinterval, Hukommelsestilstand og Alarmniveau til systemets standardværdier. Funktionen vælges med [enter] og bekræftes ved at vælge Ja med [<] og [>] og trykke [enter] igen. Derefter vender systemet tilbage til konfigurationsmenuen. Vælges Nej vender systemet tilbage til konfigurationsmenuen uden at udføre handlingen. Alarmlog Når Alarmlog vælges vises den sidst indtrufne alarm og datoen for denne. Med [<] og [>] kan der vælges mellem de sidste 10 alarmer. Ved at trykke [enter] ved den valgte alarm, vises informationer om tidspunkt, type, varighed og maksimal temperatur eller fugt, alt efter hvilken type der er tale om. Der bladres mellem informationerne med [<] og [>]. Der vendes tilbage til alarmlogmenuen med [esc], og ved endnu et tryk på [esc] kan der vendes helt tilbage til hoved-menuen. 1 Målinger gemmes til hukommelsen er fuld (1000 målinger) 2 Målinger udlæses direkte til tilsluttet PC 162

167 ## ##/##/## er ## ##/##/## esc e: XXXX < > ## ##/##/##!"$#%#&" ##:## < > ## ##/##/## ##dg ##:##:## < > ## ##/##/## : ###.# esc esc esc Figur A.8: Fremgangsmåde for udlæsning af data fra alarmlog 163

168 Appendiks B Accepttestspecifikation Test af de enkelte elementer i systemet vil på de følgende sider blive beskrevet. Menu-system Overførsel af data Ur Opdateringsfrekvens Kapacitet af hukommelse Lagringsinterval Måleområde Opløsning Yderområde Alarm

169 Dette afsnit søger at verificere at den ønskede funktionalitet af systemet er opfyldt. Derfor beskrives proceduren til at undersøge systemets funktioner, så de kan sammenholdes med kravspecifikationen. Hver accepttest har en liste over de krav der ønskes at blive verificeret. Forudsætning for at gennemfører de efterfølgende tests er at den foreløbige brugervejledning 1 er læst. Det skal verificeres hvorvidt menu-systemet virker, hvilket gøres på føl- Menu-system gende måde: Kravene der testes for, i denne test, er beskrevet i afsnittet Krav til menu-systemet på side 20 og i den foreløbige brugervejledning som findes i appendiks A. Begrundelsen for at denne test er beskrevet mere detajeret end de efterfølgende test er at de efterfølgende tests afhænger af at denne test er blevet gennemført korrekt. 1. Start systemet. OK 2. Verificér, at displayet viser en værdi for temperatur og RF. OK 3. Verificér ved at trykke på [>] at displayet skifter gennem følgende visninger: (a) Øverste linie Temp.± ##,#. Nederste linie Fugt ###% OK (b) Øverste linie Gns. Temp: ±##,#C Nederste linie Gns. Fugt: ###% Mangler : efter fugt. Lille t og f i temp og fugt. (c) Øverste linie Max. Temp. ±##,#C Nederste linie Min. Temp. ±##,#C Lille t i temp (d) Øverste linie Max. RF: ###% Nederste linie Min. RF: ###% OK 4. Tryk på [enter]. Verificér at displayet viser Menu, se figur A.3 på side 161. Der står -HOVEDMENU- i displayet. 5. Verificér at man ved at betjene [<] og [>] kan vælge mellem Konfiguration og Alarmlog. OK 6. Vælg ved brug af [<] og [>] punktet Konfiguration og tryk [enter]. OK 7. Verificér, at displayet viser Dato i øverste linie af displayet. OK 8. Verificér, at displayets nederste linie viser aktuel dato i formatet DD/MM/YYYY. OK 9. Verificér ved at trykke på [>], at nederste linie skifter gennem følgende: (a) Tid OK (b) Lagringsinterval OK 1 Foreløbige brugervejledning er på A på side

170 APPENDIKS B. ACCEPTTESTSPECIFIKATION (c) Huk. tilstand OK (d) Alarmniveau OK (e) Slet hukommelse OK (f) Slet alarmlog OK (g) Std. indstil. OK 10. Tryk på [esc]. Verificér at displayet viser Menu, se figur A.3 på side 161. Der står -HOVEDMENU- i displayet. 11. Vælg Konfiguration. Brug [>] indtil displayets øverste linie viser Alarmniveau og tryk [enter]. OK 12. Verificér at displayets øverste linie viser Temp. øvre og nederste linie viser aktuel øvre værdi. OK 13. Verificér ved at trykke på [>] at øverste linie på displayet skifter igennem følgende: (a) Temp.nedre OK (b) RF øvre OK (c) RF nedre OK 14. Tryk [esc]. Verificér at displayet viser Alarmniveau OK 15. Brug [>] indtil displayets øverste linie viser Slet hukommelse på øverste linie og tryk [enter]. OK 16. Verificér at displayet viser Slet huk.: på øverste linie og < Nej > på nederste og tryk [enter]. OK 17. Tryk [esc]. Verificér, at displayet igen viser Slet hukommelse. OK 18. Brug [>] indtil displayets øverste linie viser Std. indstil. og tryk [enter]. OK 19. Verificer at displayet viser Gendan: < Nej > OK 20. Tryk [esc]. Verificér at displayet igen viser Std. indstil. OK 21. Tryk [esc]. Verificér at displayet viser Hovedmenu. Der står -HOVEDMENU- i displayet. 22. Brug [>], vælg Alarmlog og tryk [enter]. OK 23. Verificér, at der i displayets øverste linie står Alarmlog og nederste linie står Alarm 0. Der står -ALARMLOG- i displayet. 24. Verificér, at nederste linie skifter i gennem Alarm 0-9 DD/MM/YYYY ved brug af [>]. OK 25. Vælg Alarm 0 hvis denne eksisterer og tryk [enter]. Verificér at data for Alarm 0 vises. OK 26. Gentag forrige punkt for Alarm 1-9, hvis disse eksisterer. OK 166

171 27. Tryk [esc] to gange for at returnere til datavisning. OK 28. Verificér at displayet viser en værdi for temperatur og RF. OK -Dog vises øvrige værdier, såsom max. min. hvis disse blev vist inden man gik ind i menuen. 29. Tryk på [enter]. Verificér at displayet viser Menu se figur A.3 på side 161. Der står -HOVEDMENU- i displayet. 30. Tryk på [esc]. OK 31. Verificér at displayet viser en værdi for temperatur og RF. OK 32. Verificér ved at trykke på [<] at displayet skifter gennem følgende visninger: (a) Øverste linie Temp: ±##,#. Nederste linie Fugt: ###% OK (b) Øverste linie Max.RF: ###% Nederste linie Min.RF: ###% OK (c) Øverste linie Max.temp: ±##,#C Nederste linie Min.temp: ±##,#C OK (d) Øverste linie Gns.temp: ±##,#C Nederste linie Gns.fugt: ###% Mangler : efter fugt 33. Tryk på [enter]. Verificér at displayet viser Menu. Der står -HOVEDMENU- i displayet. 34. Verificér, at man ved at betjene [<] og [>] kan vælge mellem Konfiguration og Alarmlog. OK 35. Vælg ved brug af [<] punktet Konfiguration og tryk [enter]. OK 36. Verificér at displayet viser Dato i øverste linie af displayet. OK 37. Verificér endvidere, at displayets nederste linie viser aktuel dato i formatet DD/MM/YYYY. OK 38. Verificér ved at trykke på [<], at nederste linie skifter igennem følgende punkter: (a) Std. indstil. OK (b) Slet alarmlog OK (c) Slet hukommelse OK (d) Alarmniveau OK (e) Huk. tilstand OK (f) Lagringsinterval OK (g) Tid OK (h) Dato OK 39. Tryk på [esc] og verificér at displayet viser Menu. Se figur A.3 på side 161. Der står -HOVEDMENU- i displayet. 40. Vælg Konfiguration. Brug [<] indtil displayets øverste linie viser Alarmniveau og tryk [enter]. OK 167

172 APPENDIKS B. ACCEPTTESTSPECIFIKATION 41. Verificér, at displayets øverste linie viser Temp. øvre og nederste linie viser aktuel nedre grænse. OK 42. Verificér ved at trykke på [<] at nederste linie skifter gennem følgende punkter: (a) RF nedre OK (b) RF øvre OK (c) Temp. nedre OK (d) Temp. øvre OK 43. Tryk [esc] og verificér, at displayet viser Alarmniveau. OK 44. Brug [<] indtil displayets nederste linie viser Slet hukommelse og tryk [enter]. OK 45. Verificér, at displayet viser Slet huk.: på øverste linie og < Nej > på nederste. OK 46. Tryk [esc] og verificér, at displayet igen viser Slet hukommelse. OK 47. Brug [<] indtil displayets nederste linie viser Std. indstil. og tryk [enter]. OK 48. Verificér at displayet viser Std. indstil. på øverste linie og Gendan: < Nej > på nederste. OK 49. Tryk [esc] og verificér at displayet igen viser Std. instil. OK 50. Tryk [esc] og verificér at displayet viser Menu. Der står -HOVEDMENU- 51. Brug [<], vælg Alarmlog og tryk [enter]. OK 52. Verificér at der i displayets øverste linie står Alarmlog og nederste linie står Alarm 0 + alarmdato. Der står -ALARMLOG- i displayet. 53. Verificér, at nederste linie skifter i gennem Alarm 9-0 ved brug af [<]. OK 54. Vælg Alarm 0 hvis denne findes og tryk [enter]. Verificér at data for Alarm 0 vises. OK 55. Gentag forrige punkt for Alarm 9-1 hvis disse findes. OK Overførsel af data Krav, der verificeres med denne accepttest: Kommunikationen skal foregå med tegn i ASCII-formatet. Det vil sige at måleværdierne fra hukommelsen skal konverteres til talværdier som skrives med tegn. Begrundelsen for dette er, at der som PC-software skal kunne bruges et standard terminalprogram. Der skal være mulighed for at overføre samtlige målinger fra systemets hukommelse. 168

173 Der skal være mulighed for at overføre nøgledata om klimaet som maximum, minimum, gennemsnit og aktuelle værdier for henholdsvis fugtighed og temperatur. Der skal være en kommando til at slette alle de gamle måledata fra hukommelsen.se tabel 3.1 på side 19 for kommandoer, der verificeres For at teste ovenstående krav anvendes følgende procedure: 1. Sørg for at displayet viser datavisnings-menuen ved at trykke på [esc] indtil displayet viser RF og temperatur fra sensorer. OK 2. Gå ind i Konfiguration. OK 3. Vælg Lagringsinterval og indstil denne til ét sek. OK 4. Vælg Huk. tilstand og vælg Fuld huk.. OK 5. Det tager ca. 20 min. at fylde hukommelsen. OK 6. Tilslut PC og start terminalprogram. OK 7. Sørg for, at displayet viser datavisnings-menuen ved at trykke på [esc], indtil displayet viser RF og temperatur fra sensorer. OK 8. Skriv nu, tryk [retur] 2 og verificér, at RF og temperatur er det samme på terminalskærm og display. OK 9. Tryk på [>] og verificér, at gns. RF og temperatur er det samme på terminalskærmen og display. OK 10. Tryk på [>] og verificér at max/min temperatur er det samme på terminal-skærmen og display. OK 11. Skriv send, tryk [retur] og verificér at indhold af hukommelsen bliver udlæst til skærm. OK 12. Kontrollér, at der er blevet sendt 1000 målinger. OK 13. Gå ind i Konfiguration. OK 14. Vælg Lagringsinterval og indstil denne til én time. OK 15. Vælg Huk. tilstand og vælg Fuld huk.. OK 16. Skriv slet, tryk [retur] og verificér, at systemet skriver Hukommelse slettet på terminal-skærm. OK 17. Skriv send, tryk [retur] og verificér, at der ikke forefindes nogen målinger i hukomelsen. OK 18. Skriv hlp, tryk [retur] og verificér, at nu, send, slet og hlp angives som gyldige kommandoer og betydningen af kommandoerne udskrives. OK Kan ovenstående punkter gennemføres som beskrevet, er de anførte krav opfyldt. 2 Her menes [retur] på tastaturet på terminal-pc en. 169

174 APPENDIKS B. ACCEPTTESTSPECIFIKATION Ur Uret kontrolleres på følgende måde: 1. Sørg for, at displayet viser datavisnings-menuen ved at trykke på [esc], indtil displayet viser RF og temperatur fra sensorer. OK 2. Gå ind i Konfiguration og vælg Indstil ur. OK 3. Tidspunktet indstilles efter et reference-ur. OK 4. Der ventes 24 timer, hvorefter tidspunktet fra systemet kontrolleres med tidspunktet aflæst på reference-uret. Der accepteres en afvigelse på 24 sekunder i forhold til reference-uret (1 sek pr. time). OK -Afvigelse var på under 1 sek. Opdateringsfrekvens For at verificere at systemet henter data fra temperatur- og fugtighedssensorerne hvert sekund, sættes et oscilloskop på bussen. Efter der er optaget 2 målinger på oscilloskopet verificeres det at der er et sekund mellem disse. Krav der verificeres med denne accepttest: Der skal foretages én måling per sekund, som ikke nødvendigvis lagres, men blot benyttes til alarmer etc. (Overvåg klima). For at teste ovenstående krav anvendes følgende procedure: 1. Start systemet. OK 2. Kobl et oscilloskop på I 2 C-bussens SCL-leder. OK 3. Indstil oscilloskopet til en periode på 10 sekunder. OK 4. Efter der er indtruffet 2 pulser på oscilloskopet verificeres det, at der er ca. ét sekund mellem disse. OK Kan ovenstående punkter gennemføres som beskrevet, er det anførte krav opfyldt. Kontroller kapacitet af hukommelse Krav der verificeres med denne accepttest: Der skal være plads til 1000 lagrede målinger i hukommelsen. (Overvåg klima). For at teste ovenstående krav anvendes følgende procedure: 1. Gå ind i Konfiguration. OK 2. Vælg Lagringsinterval og indstil denne til ét sek. OK 3. Vælg Huk. tilstand og vælg Fuld huk.. OK 4. Det tager ca. 20 min. at fylde hukommelsen. Herefter overføres dataene til en PC 3. OK 5. Det verificeres på PC, at der er overført 1000 målinger. OK 3 Se brugervejledning for at koble en PC til systemet 170

175 Lagringsinterval Krav, der verificeres med denne accepttest: Det skal være muligt at indstille lagringsintervallet af systemet til 1, 15 og 30 sekunder samt 1, 5, 15, 30 og 60 minutter. (Konfigurér system). For at teste ovenstående krav anvendes følgende procedure: 1. Sørg for at displayet viser datavisnings-menuen ved at trykke på [esc], indtil displayet viser RF og temperatur fra sensorer. OK 2. Gå ind i Konfiguration, vælg Lagringsinterval og indstil til ét sekund. OK 3. Mål over en periode på 10 gange lagringsintervallet. OK 4. Udlæs data til en PC. OK 5. Kontrollér, at antallet af målinger er korrekt. OK 6. Gentag testen for samtlige indstillinger af lagringsinterval. OK Måleområde Den vigtigste del af denne test er at verificere, at der kan indtræffe et fortegnsskift ved temperaturmålinger. Krav, der verificeres med denne accepttest: Systemet skal kunne måle temperaturer fra -20 C til +60 C. (Overvåg klima). For at teste ovenstående krav anvendes følgende procedure: 1. Sørg for at displayet viser datavisnings-menuen ved at trykke på [esc] indtil displayet viser RF og temperatur fra sensorer. OK 2. Udsæt temperatursensoren for en reference-temperatur over 0 C. OK 3. Verificér, at displayet viser reference-temperaturen uden fortegn. OK 4. Udsæt temperatursensoren for en reference-temperatur under 0 C. OK 5. Verificer, at displayet viser reference-temperaturen med negativt fortegn. OK Da der ikke forekommer negative værdier af RF, foretages ovennævnte test ikke for fugtighedssensoren. Opløsning Det ønskes verificeret, at opløsningen på måleområderne fungerer korrekt. Dette gøres for at sikre, at udlæsningen fungerer korrekt. Dette kan verificeres ved at udsætte sensorerne en langsom temperaturændring/rf-ændring og kontrollere, at alle skift skrives korrekt på displayet. Temperatur Krav, der verificeres med denne accepttest: 171

176 APPENDIKS B. ACCEPTTESTSPECIFIKATION Temperaturen skal kunne vises med en opløsning på 0,1 C (Overvåg klima). For at teste ovenstående krav anvendes følgende procedure: 1. Sørg for at displayet viser datavisnings-menuen ved at trykke på [esc], indtil displayet viser RF og temperatur fra sensorer. OK 2. Udsæt temperatursensoren for en temperaturkilde, der falder med under 0,1 C pr. sekund. OK 3. Hold øje med displayet og verificér, at alle skift sker med 0,1 C s interval indtil 3 C under temperaturkildens starttemperatur. Fejl : kan ikke vise,2 og,7 Luftfugtighed Krav, der verificeres med denne accepttest: Måledata skal kunne vises og gemmes med 1 %-intervaller, for at kunne detektere mindre ændringer i den relative luftfugtighed. (Overvåg klima). For at teste ovenstående krav anvendes følgende procedure: 1. Sørg for at displayet viser datavisnings-menuen ved at trykke på [esc], indtil displayet viser RF og temperatur fra sensorer. OK 2. Udsæt fugtighedssensoren for en luftfugtighed, der falder med under 1 % RF pr. sekund. OK -Blev udført ved at dreje langsomt med potentiometret 3. Hold øje med displayet og verificér at alle skift sker med 1 %. OK Yderområde For at sikre at systemet kan håndtere maximum- og minimumværdier, skal temperatur- og fugtighedssensor udsættes for disse. Dette gøres primært for at sikre, at der ikke forekommer overflow i systemet ved disse ekstremer. Temperatur Krav, der verificeres med denne accepttest: Systemet skal kunne måle temperaturer fra -20 C til +60 C. (Overvåg klima). For at teste ovenstående krav anvendes følgende procedure: 1. Sørg for at displayet viser datavisnings-menuen ved at trykke på [esc], indtil displayet viser RF og temperatur fra sensorer. OK 2. Udsæt temperatursensoren for 60 C. OK 3. Verificér, at displayet viser 60,0 C ± 2. OK -selvom den anvendte temperatursensor har større unøjagtighed. 4. Verificér, at systemet stadig fungerer ved at foretage et menuskift. OK 172

177 5. Udsæt temperatursensoren for -20 C. OK 6. Verificér, at displayet viser -20,0 C ± 2 C. OK -selvom den anvendte temperatursensor har større unøjagtighed. 7. Verificér, at systemet stadig fungerer ved at foretage et menuskift. OK Kan ovenstående punkter gennemføres uden fejl, er det anførte krav opfyldt. Luftfugtighed Krav, der verificeres med denne accepttest: Systemet skal kunne måle relativ fugtighed fra 5 % til 95 %. (Overvåg klima). Det skal bemærkes at der blev benyttet et potentiometer, som emulering af luftfugtighedssensor. For at teste ovenstående krav anvendes følgende procedure: 1. Sørg for at displayet viser datavisnings-menuen ved at trykke på [esc] indtil displayet viser RF og temperatur fra sensorer. OK 2. Udsæt fugtighedssensoren for en reference RF på 100 %. 95 % RF accepteres som yderområde. OK 3. Verificér, at displayet viser reference RF en. OK 4. Verificér, at systemet stadig fungerer ved at lave et menuskift. OK 5. Udsæt fugtighedssensoren for en reference RF på 5 %. 10 % RF accepteres som yderområde. OK 6. Verificér, at displayet viser reference RF en. OK 7. Verificér, at systemet stadig fungerer ved at foretage et menuskift. OK Kan ovenstående punkter gennemføres uden fejl, er det anførte krav opfyldt. Alarm Krav, der verificeres med denne accepttest: Alarmen skal have en udgang, som går høj ved aktivering af alarmen. Dette kan styre en ekstern signalgiver, fx en sirene. (Alarmér) Alarmen skal automatisk annulleres, når grænseværdier ikke længere er overskredne. (Alarmér) Når alarmen udløses, skal der udlæses informationer om alarmtype, på datavisningsmenuen i form af et udråbstegn Der optages en log over alarmerne, type, tidspunkt, varighed samt største overskridelse. (Alarmér) 173

178 APPENDIKS B. ACCEPTTESTSPECIFIKATION Der skal kunne være log for de sidste 10 alarmer i hukommelsen. (Alarmér) Systemet skal i tilfælde af flere alarmer skrive alarmdata for hver alarm i hver sin log, indtil 10 alarmer, så overskrives den ældste. For at teste ovenstående krav anvendes følgende procedure: 1. Temperatursensoren udsættes for en reference-temperatur på over 20 C. OK 2. Sørg for at displayet viser datavisnings-menuen ved at trykke på [esc], indtil displayet viser RF og temperatur fra sensorer. OK 3. Gå ind i Slet alarmlog og slet alarmloggen. OK 4. Gå ind i Alarmniveauer OK. 5. Gå ind i RF øvre og indstil denne til 100 %. OK 6. Gå ind i RF nedre og indstil denne til 0 %. OK 7. Gå ind i Temp. øvre og indstil denne til 20 C. OK 8. Gå ind i Temp. nedre og indstil denne til 10 C. OK 9. Indtræffer der nu en alarm kan det konkluderes, at alarmfunktionen alamerer korrekt ved en øvre grænseoverskridelse af temperaturen. OK 10. Alarmens indtræffen kan verificeres ved at sikre, at displayet markerer temperaturen med et!, samt at Alarm ud bliver høj. OK 11. I alarmloggen skal den sidste alarm, der er registreret, vises. Tryk på [enter] for at vælge denne alarm. (a) Verificér, at der ud for Type står Temperatur. OK (b) Tryk på [>]. OK (c) Verificer, at der ud for Tid: står tidspunktet for hvornår alarmen gik i gang. OK (d) Tryk på [>]. OK (e) Verificer, at alarmens varighed står angivet, og at den stiger hvert sek. OK (f) Tryk på [>]. OK (g) Verificér, at der ud for max/min står reference-temperaturen ± 0,5 C.OK -På trods af, at der blev benyttet en sensor med større unøjagtighed. 12. Temperatursensoren udsættes nu for en reference-temperatur på under 10 C. OK 13. Indtræffer der nu en alarm, kan det konkluderes, at alarmfunktionen alarmerer korrekt ved en nedre grænseoverskridelse af temperaturen. OK 14. Udsæt temperatursensoren for en reference-temperatur mellem 10 og 20 C. OK 15. Vent 5 min. og verificér at alarmen ikke indtræffer igen. 174

179 Kan ovenstående punkter gennemføres uden fejl, virker alarmeringen for en overskridelse af øvre og nedre temperaturniveauer. For at teste alarmen for fugtighedssensoren gøres følgende i menuen Konfiguration : 1. Temperatursensoren udsættes for en reference RF på over 70 %. OK 2. Gå ind i Slet hukommelse og slet hukommelsen. OK 3. Gå ind i Alarmniveau. OK 4. Gå ind i Fugt. øvre og indstil denne til 70 %. OK 5. Gå ind i Fugt. nedre og indstil denne til 30 %. OK 6. Gå ind i Temp. øvre og indstil denne til 60 C. OK 7. Gå ind i Temp. nedre og indstil denne til -20 C. OK 8. Indtræffer der nu en alarm, kan det konkluderes, at alarmfunktionen alamerer korrekt ved en øvre grænseoverskridelse af fugtigheden. OK 9. Alarmens indtræffen kan verificeres ved at sikre, at displayet markerer den målte RF med et!, samt at Alarm ud bliver høj. OK 10. I alarmloggen skal den sidste alarm, der er registreret vises. Tryk på [enter] for at vælge denne alarm. OK (a) Verificér, at der ud for Type står Fugt. OK (b) Tryk på [>]. OK (c) Verificer, at der ud for Tid: står tidspunktet for hvornår alarmen gik i gang. OK (d) Tryk på [>]. OK (e) Verificer, at alarmens varighed står angivet, og at den stiger hvert sek. OK (f) Tryk på [>]. OK (g) Verificér, at der ud for max/min står reference-rf ± 1 % C.OK 11. Fugtighedssensoren udsættes nu for en reference RF på under 30 %. OK 12. Indtræffer der nu en alarm, kan det konkluderes, at alarmfunktionen alarmerer korrekt ved en nedre grænseoverskridelse af fugtigheden. OK 13. Gå ind i Temp. øvre og indstil denne til 20 C. OK 14. Gå ind i Temp. nedre og indstil denne til 10 C. OK 15. Temperatursensoren udsættes for en reference-temperatur på over 20 C. OK 16. Indtræffer der nu en alarm, kan det konkluderes, at alarmfunktionen alamerer korrekt ved en grænseoverskridelse af både temperaturen og fugtigheden. OK 17. Verificér, at displayet markerer både den målte RF og temperatur med et!. OK 175

180 APPENDIKS B. ACCEPTTESTSPECIFIKATION 18. Udsæt fugtighedssensoren for en reference RF mellem 30 og 70 %. OK 19. Udsæt temperatursensoren for en reference-temperatur mellem 10 og 20 C. OK 20. Verificér, at alarmen ikke indtræffer igen. OK Kan ovenstående punkter gennemføres uden fejl, virker alarmeringen for en overskridelse af øvre og nedre fugtighedsniveauer. 176

181 Appendiks C Eldiagram Heroverfor ses side 1 af eldiagrammet. På denne side findes selve processoren, hukommelseskredsløbet og adressedekoderen. 177

182

183 Heroverfor ses side 2 af eldiagrammet. På denne side findes forbindelserne til displayet, taste- og alarmudgangs-kredsløbet, I 2 C- controlleren og EEPROM en. 179

184

185 Heroverfor ses side 3 af eldiagrammet. På denne side findes power-on resetkredsløbet og de to ACIA er samt linedriver og clock til dem. 181

186

187 Heroverfor ses side 4 af eldiagrammet. På denne side findes interruptkredsløbet, samt sekundgeneratoren og NMI switch-kredsløbet. 183

188

189 Appendiks D Stykliste I tabel D.1 findes en liste over samtlige komponenter som er at finde på eldiagrammet. På det opbyggede system findes desuden et antal afkoblingskondensatorer. Sensorerne sidder på et print for sig selv, og er derfor ikke med i denne liste. Se evt. afsnit på side 70. Antal Komponent Værdi/Navn Beskrivelse 1 C1 10u Elektrolytkondensator 5 C2,C3,C4,C5,C6 100n Kondensator 1 C7 100p Kondensator 1 C8 6p8 Kondensator 2 D1,D2 BAT85 Diode 1 J1 DISPLAY BE-PC 1604-A 1 J2 CON4 Connector til I 2 C-bus til sensorer 2 P1,P2 CON-DB9 9 pins DSUB stik til RS R1,R2,R3,R4,R8,R9, 10k Modstand R10,R13,R14,R15 1 R5 2k2 Modstand 2 R6,R7 1 k Modstand 1 R11 680k Modstand 1 R12 15 M Modstand 4 SW1,SW2,SW3,SW4 Ringetryk Taster 1 SW5 RESET Fjederpåvirket omskifter 1 SW6 NMI Fjederpåvirket omskifter 1 U1 68HC000/LCC M68k processor 2 U4,U2 AM29F010 ROM-kreds 2 U3,U5 SRM20100 RAM-kreds 1 U6 22CV10A PEEL(Adressedekoder) 1 U7 74HCT04 Inverter 1 U8 74HCT32 OR-gate 2 U9,U10 74HCT373 Latch 1 U11 PCF8584_P I 2 C-controller 1 U12 TL7705A Power-on Reset 1 U13 74HCT4040 Tæller 2 U14,U ACIA 1 U15 MAX232 Linedriver 1 U17 74HC148 Enkoder 2 U19,U18 74HC138 Dekoder 2 U20,U23 74HCT00 NAND-gate 1 U21 74HC4060 Tæller og oscillator 1 U22 74HCT73 Flip-flop 1 U24 24LC256 EEPROM 1 Y1 MCO MHz oscillator 1 Y2 ACIA-CLOCK 2,4576 MHz oscillator 1 Y Krystal Tabel D.1: Stykliste 185

190 Appendiks E Filliste for bilags-cd På roden af bilags-cd en ligger rapporten. Filnavnene er: main.ps eller main.pdf Liste over datablade i mappen datablade på bilags-cd en: 74HCT373.pdf ACIA_6850.pdf ACIA_c6850.pdf BAUDGENERATOR_MC14060B.pdf BAUDKRYSTAL_mco1610b.pdf BINAERTAELLER_74HC HC4040.pdf DEBUGMON_tsmon2.pdf DIODE_BAT85_4.pdf display-be-pc1604-a.pdf Dual_flipflopn-edg-trig_74HC_HCT73_CNV_2.pdf DUART_scn68681.pdf EEPROM_24lc256.pdf DISPLAY_CONTROLER_hd44780.pdf I2C_AD-MAX1236-MAX1239.pdf I2C_cnt-PCF8584_4.pdf I2C_tempsensor-sa56004.pdf IRQ-ctrl_74HC148.pdf IRQ_IACK-decoder_74hc138.pdf Latch_quad_transparent_74hc75.pdf PEEL_18cv8.pdf PEEL_22cv10a.pdf POWERONRESET_tl7705a.pdf ROM-AM29F010B.pdf 186

191 RS232DRIVER_MAX220-MAX249.pdf Tabel over filer i mappen code på bilags cd en: Filnavn acia.asm aciatest.c adrdek.abl alarm.c alarm.h asmfunc.h cstart.asm dataopsamling.c dataopsamling.h dataopsamlingtest.c delay.asm eeprom.c eeprom.h eepromtest.c henttast.c i2c.c i2c.h int2ascii.c isodate.c isodate.h komfort.c menu_alarmlog.c menu.c menu.h menu_tid.c samlet.hex sekhandler.asm skrivtildisp.c testafprintg.c ts2routines.asm ts2rout-test.c urtest.c Indhold Funktioner til kommunikation med acia Testfunktion til acia.asm Abel kode til adressedekoderen Funtioner der skriver i Alarmloggen Headerfil til alarm.c Headerfil med prototyper på alle assembler funktioner Initialisering af C-kode Funktioner til modulet dataopsamling Headerfil til dataopsamling.c Dataopsamling med testkode Kode til delay funktionen Funktioner til at kommunikere med EEPROM en Headerfil til eeprom.c Test af EEPROM s funktioner Funktion til at hente taste-input Funktioner til at kommunikere med I 2 C-bussen Headerfil til i2c.c Funktion til konvertering af int til char Funktion til konvertering af tid i sekund til et array af int og til at konvertere den anden vej Headerfil til isodate.c Funktioner til at kommunikere med PC Funktioner til håndetering af alarmlogmenu Funktioner til menusystemet Headerfil til menu.c Funktioner til at indstille tid og dato Endelige hexfil Funktioner til håndtering af uret Funktioner til at skrive til displayet Test af skrivtildisp.c Funktioner til debug Test af ts2routines.asm Test af sekhandler.asm Tabel E.1: Tabel med kodefiler 187

192 Tabeller 3.1 Kommandoer i terminalvinduet Benævnelser for M68k s benforbindelser Memorymap Sandhedstabel for adressedekoder Testresultat adressedekoder HW Interface af display Sandhedstabel for taste-input Sandhedstabel for alarm-output Benforbindelser på PCF Bit-mønster i kontrol-sektion i S Bit mønster i status-sektion i S Sandhedstabel til DTACK*-generator Karnaugh kort for DTACK-generator Krav til temperatursensor Forbindelser i 9-pin D-sub stik Spændingsniveauer for TTL og RS ACIA ens interne registre Procesoversigt Tabel over anvendte TS2MON funktioner A.1 Kommandoer D.1 Stykliste E.1 Tabel med kodefiler

193 Figurer 1.1 V-model System delt op i Use Cases Oversigt over menusystemet Princip for designmetode Simpelt blokdiagram Blokdiagram over hardware Power-on resetkredsløb Kontrolsignaler til hukommelse Benforbindelser på adressedekoder Interrupt-encoder IACK og Function code dekoder Kredsløb som eliminerer prell Skopshot af power-on-reset Power-on reset stigetid Skopshot af 8 Mhz clock Skopshot af A5 og A6 i free run Kommandoversigt for karakterskrivning Initialisering af display-controller Kommandooversigt for display-controlleren Display el-diagram Tast-input samt alarm-output kredsløb Kommunikation på I 2 C bus Shiftregister i PCF DTACK-generator til PCF

194 FIGURER 7.9 Diagram over I 2 C-sensorer Adressering i EEPROM Sekund-generatorkredsløb Sekundclock pin sub-d Bitstream for RS Blokdiagram for ACIA Driver og reciever til RS-232 forbindelse El-diagram over RS-232 forbindelserne Symboler i dataflowdiagrammer Symboler i flowcharts Dataflowdiagram software Dataflowdiagram over menusystemsproces Dataflowdiagram for konfigurationsmodulet Dataflowdiagram for sekundhåndteringsprocessen Dataflow i PC-grænsefladen Skopshot fra test af delay Flowchart over int2ascii Flowchart for jiffytoiso Programflow i isotojiffy Flowchart for master-transmitter forløb(i2c_send) Flowchart for master-receiver forløb(i2c_hent) Scopshot af I 2 C-bus efter afvikling af i2c_send Scopshot af I 2 C-bus efter afvikling af i2c_hent Flowchart over læsning fra EEPROM Flowchart over skrivning til EEPROM MSB fra to Bytes samles til een Byte Flowchart over alarmmodul Flowchart for trykfordeler Blokdiagram over menusystem Flowchart for send_disp Dataflow for PC-grænsefladen Flowchart for send streng modulet

195 FIGURER 10.18Flowchart for modtag streng modulet Flowchart for kommandofortolker modulet Flowchart for initialisering af PC-forbindelse A.1 Menuens opbygning A.2 Datavisningsmenu A.3 Hovedmenuen A.4 Dato og tidsindstilling A.5 Indstilling af målehyppighed og hukommelsestilstand A.6 Indstilling af grænseværdier A.7 Reset indstillinger og hukommelse A.8 Fremgangsmåde for udlæsning af data fra alarmlog

196 Litteratur Clements, Alan (1997), Micoprocessor system design, 3rd edn, PWS Publishing Company. ISBN: Clements, Alan (2000), The Principles of Computer Hardware, 3rd edn, Oxford University Press. ISBN: Corporation, Data I/O (1990), ABEL-PLD User Manual, Data I/O Corporation. Dominique Paret, Carl Fenger (1997), The I 2 CBUS - From Theory to Practice, 1st edn, John Wiley & sons. Kelley, Al & Ira Pohl (2001), C by Dissection, 4th edn, Addison Wesley Longman. ISBN: Krav til M68000 system (2004) april Motorola (1993), M68000 Microprocessors User s Manual, 9th edn, Motorola Inc. Nielsen, Sofus Birkedal (2001), Debugger/Monitor for the M68000 Microprocessor Family, version 1.2 edn, Aalborg University, Denmark. Putman, Byron W. (1987), RS-232 Simplified, Prentice-Hall Inc. ISBN: Stephen Biering-Sørensen, Finn Overgaard Hansen, Susanne Klim & Preben Thalund Madsen (2000), Struktureret Program-Udvikling, 1st edn, Ingeniøren Bøger. ISBN: Sörensen, Stefan (2004), Opgavebesvarelse til mikrocomputer hw mm april Wilmott, Kenn E. (2004), sci.electronics faq, assorted ascii schematics maj