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