Prosjektoppgave. Bergen tekniske fagskole. Christian Håkonsund Åsmund Lillegraven Ronny Dammann. 2. Elektronikk

Prosjektoppgave ved Bergen tekniske fagskole Christian Håkonsund Åsmund Lillegraven Ronny Dammann 2. Elektronikk 2005

Forord Elektronikk studiet ved Bergen Teknisk Fagskole avsluttes med et større prosjekt som på mange måter skal oppsummere det vi har lært etter 2 års studier. Tankene og ideene rundt prosjektet startet allerede ved skolestart andre år. Dette medførte at prosjektet endret seg mye i form og omfang frem mot den endelige prosjektsøknaden som ble levert i desember 2004. Vi har hatt et ønske om å dekke flest mulig mål i fagplanene, med mest vekt på mikrokontrollere, programmering og produksjon av kretskort. Arbeidet med prosjektet har foregått hele skoleåret 04/05, men det var først i andre halvår 2005 arbeidet ble intensivert og konkretisert. I tillegg til de avsatte timene og prosjektukene ved skolen, har det blitt mange sene kvelder for å komme i mål med arbeidet. Det har vært en omfattende oppgave, større og mer tidkrevende enn vi kunne drømme om. Vi er derfor stolte av resultatet av prosjektet og samarbeidet vi har gjennomført. Vi har tilegnet oss kunnskap som på mange måter er unik og som vil komme til nytte i en fremtidig sammenheng. Denne rapporten er rettet mot teknisk personell i fremtidig utviklings øyemed. Vi håper og tror at denne rapporten kan være spesielt nyttig for andre som skal arbeide med Atmel sine 8 bits RISC mikrokontrollere. Vi vil til slutt takke alle som har bidratt, spesielt: Per Bjarne Ødegård hos Elprint A/S for produksjon av prototyp. Bruce McKibben hos Elprint A/S for støtte og veiledning i utviklingen av prototyp. Gunnar Moen hos Elprint A/S for utfresing av boks til bruk på prototyp. Laboratoriums assistent Roger Ølmheim for svært god logistikk og fleksibilitet. Bergen 12. mai 2005 Christian Håkonsund Åsmund Lillegraven Ronny Dammann - 2 -

Innholdsfortegnelse SAMMENDRAG... 6 DEL 1 - ADMINISTRATIVT... 8 INNFORMASJONSINNHENTING... 8 HVORDAN VI ORIENTERTE OSS OM MULIGHETER OG BEGRENSINGER I PROSJEKTET... 8 HVILKE RESSURSPERSONER BLE BRUKT... 8 BEHOV FOR KUNNSKAP... 9 TYPE KILDER SOM BLE BRUKT... 10 ULIKE LØSNINGER GENERELT... 10 SAMARBEIDSPARTNERE... 10 DATAPROGRAM SOM BLE BENYTTET... 11 DEL 2 - HOVEDKOMPONENTER OG SENSORER... 13 HOVEDKOMPONENTER... 13 MIKROKONTROLLER ATMEGA16L... 13 STK500... 15 MMC... 17 2 I C BUSSEN... 19 RS232 (USART)... 22 VALG AV SENSORER OG TEKNISKE LØSNINGER... 25 A/D KONVERTERING... 25 DS1307... 27 DS1621... 28 KNAPPERAD... 29 DEL 3 - KILDEKODE... 31 GENERELT OM C-PROGRAMMERING... 31 HOVEDPROGRAM... 32 INTERRUPT RUTINE (ISR)... 33 A/D FUNKSJONEN... 34 RS232 FUNKSJON... 35 DEL 4 - PRODUKSJON AV PROTOTYP... 37 KRETSSKJEMA... 37 DESIGN AV KRETSKORT... 39 KRETSFORKLARING... 42 MONTERING AV KOMPONENTER PÅ PROTOTYP... 45 UTFRESING AV BOKS TIL ADL... 48-3 -

DEL 5 - PROBLEMER, VURDERINGER OG MULIGHETER... 49 PROBLEMER OG VURDERINGER... 49 MMC... 49 2 I C BUSSEN... 50 STK500... 52 FREMTIDIGE MULIGHETER FOR PROSJEKTET... 53 HOVEDKONKLUSJON FOR PROSJEKTET... 54 INNLEDNING... 54 DRØFTNING... 54 HOVEDKONKLUSJON... 55 VEDLEGG... 56 VEDLEGG 1 PROSJEKTSØKNAD... 56 VEDLEGG 2 SØKNAD TIL ELPRINT A/S... 59 VEDLEGG 3 FLYTSKJEMA FOR HOVEDPROGRAM.... 60 VEDLEGG 4 KILDEKODE... 61 VEDLEGG 5 FLYTSKJEMA ISR... 69 VEDLEGG 6 SKJEMATISK TEGNING KNAPPERAD.... 70 VEDLEGG 7 UTDRAG FRA EN RS232 LOGGFIL... 71 VEDLEGG 8 KRETSSKJEMA ADL... 72 VEDLEGG 9 PCB... 73 VEDLEGG 10 HENDELSESLOGG... 74 VEDLEGG 11 KOSTNADSOVERSLAG... 75 VEDLEGG 12 KILDER... 76-4 -

Figurliste Figur 1 - Prinsippskisse for ADL... 7 Figur 2 - AVR arkitektur... 14 2 Figur 3 - Offisiell I C logo... 19 2 Figur 4 - Skjematisk tegning av I C med pull up motstander... 20 Figur 5 - Gyldig dataoverføring... 21 2 Figur 6 - Dataoverføring på I C bussen... 21 Figur 7 - RS232 spenningsnivå... 23 Figur 8 - Analogt signal representert som digitale verdier... 26 Figur 9 - Spenningsdeling... 26 Figur 10 - Skjematisk tegning som viser prinsippet for prototypen av knapperaden... 29 Figur 11 - Lederbredde og strømmengde... 41 Figur 12 - Skrutilkoblinger... 44 Bildeliste Bilde 1 - ATmega16 fra Atmel Corporation... 13 Bilde 2 - STK500 utviklingskort fra Atmel... 16 Bilde 3 - Emigrert vekk fra STK500... 16 Bilde 4 Innstillinger i HyperTerminal... 22 Bilde 5 - NTC motstand... 25 Bilde 6 - DS1307 Real Time Clock (RTC)... 27 Bilde 7 - DS1621 Temperaturkrets... 28 Bilde 8 - Prototypen av knapperaden... 30 Bilde 9 - Tidlig skisse av prototypens tilkoblinger... 37 Bilde 10 - Ferdig koblet RJ45 kontakt i part reference... 40 Bilde 11 - Samarbeid med Bruce McKibben på Elprint A/S... 41 Bilde 12 - Nyprodusert ADL PCB... 45 Bilde 13 - Utbedring av feil på prototyp... 46 Bilde 14 - Lodding av prototyp... 47 Bilde 15 - Ronny Dammann fra ADL styrer rødspriten... 48 Bilde 16 - MMC kort... 49 2 Bilde 17 - I C støy problemer... 50 2 Bilde 18-2 mastere på en I C buss... 51-5 -

Sammendrag ADL Automatisk Data Loggar er resultatet av et tverrfaglig prosjekt ved Bergen tekniske fagskole. Prosjektet omhandler design og produksjon av en mikrokontrollerbasert innsamlingsenhet. Denne skal kunne presentere og lagre aktuelle sensorverdier. I tillegg er det blitt programmert et grafisk grensesnitt for visuell presentasjon av lagrede data til bruk på PC. Dette oppdraget er utført av en prosjektgruppe i dataklassen ved skolen. Kjernen i prosjektet vårt har vært en 8 bits AVR basert mikrokontroller fra Atmel. Denne sørger for å hente inn alle måledata og presenterer de på LCD. Samtidig blir også de loggede sensorverdiene sendt ut på RS232 for ekstern lagring. På ADL prototyp har vi valgt å logge innetemperatur, klokke ved hjelp av I²C baserte kretser. Utetemperaturen hentes fra en NTC krets som blir digitalisert i mikrokontrolleren ved hjelp av den innebygde A/D konverterer. Under arbeidet med programmering av kildekoden har fokus vært at ADL enkelt skal kunne utvides med flere sensorer og muligheter. Vi har derfor forøkt å skrive koden punktvis slik at den enkelt skal kunne utvides senere. Koden er basert på de funksjoner som finnes i CodeVisionAVR, samt 2 egne funksjoner vi har skrevet selv. Kildekoden leser valgt meny via en knapperad som er tilkoblet mikrokontrolleren. På denne måten bestemmer brukeren selv hva som skal vises på LCD. Mye av tiden i prosjektet har blitt brukt til å designe en prototyp av kretskortet ADL. Det er prosjektmedlemmene som hele veien har utviklet ADL fra en idé til en prototyp. Dette har medført at vi har fulgt hele produksjonsprosessen fra tidlige skisser, skjemategning og kretsutlegg, til produksjon av kretskort på Elprint A/S. Vi vil til slutt få påpeke at produktet i dag er en prototyp. Vi har i rapporten kommet med flere forslag til forbedringer, spesielt på PCB. ADL fremstår allikevel som et produkt vi er stolte av og som vi gjerne ser at andre studenter utvikler videre. - 6 -

Innledning I forbindelse med det tverrfaglige prosjektet ved Bergen tekniske fagskole ble vår prosjektgruppe bestående av 3 personer fra elektronikk klassen. Vi ønsket å utvikle en datalogger (ADL 1 ) som presenterte innhentet data fra forskjellige sensorer på et LCD display. Samtidig ønsket vi også å lagre informasjonen på en ekstern enhet. Prosjektet medførte også samarbeid med 2 personer fra dataklassen som utviklet det grafiske grensesnittet til bruk for presentasjon av de lagrede data på datamaskin. Denne prosjektgruppen valgte å ikke være en del av vår prosjektgruppe administrativt sett, og de har derfor utarbeidet en egen rapport som omfatter deres prosjekt. SENSOR 1 SENSOR 2 SENSOR 3 Figur 1 - Prinsippskisse for ADL Bakgrunnen for prosjektet har vært et felles ønske og mål om å utvikle en rimelig data logger som samtidig skulle være fleksibel og klar for fremtidige bruksområder/sensorer. Prosjektgruppen hadde også et sterkt ønske om å få brukt og videreutviklet det Bergen tekniske fagskole hadde tilført oss over en 2 års periode. Som et resultat av våre ønsker og mål ble samarbeidet skolen hadde med Elprint A/S på Hop i Bergen videreført. Resultatet av dette samarbeidet er prototypen av kretskortet og monteringsboks til ADL I begynnelsen av arbeidet med prosjektet visste vi at vi ville møte mange forskjellige utfordringer. De som det knyttet seg mest spenning til var ekstern lagring av data, kommunikasjon mellom to mikrokontrollerne og ikke minst selve designet av kretskortet. Vi har hele tiden vært under et sterkt tidspress, men i 2. halvår av prosjektet fikk vi virkelig føle trykket. Vi prioriterte derfor å bli ferdig med prototypen fremfor å programmere flere rutiner for innehenting av data. - 7 -

Del 1 - Administrativt Innformasjonsinnhenting Under hele prosjektet har vi lagt vekt på å bruke tilgjengelig informasjon. Vi har lest mye i tilgjengelige datablader, artikler og ikke minst forum på internett. Vi har hele tiden prøvd å finne konkrete løsninger og forklaringer på de utfordringer vi har stått ovenfor. Ved hjelp av forumet på www.avrfreaks.net har vi kunnet lufte ideer og få oppfatninger fra forskjellige personer med variert erfaring fra AVR 2 design. Vi har også prøvd å validere de innlegg som er skrevet i forumet da internett er et sted hvor hvem som helst kan utgi seg for å være fagfolk og dermed legge ut den informasjonen de mener er korrekt. Etter å ha vært brukere av forumet på www.avrfreaks.net i mer enn 8 måneder mener vi at vi har klart å kartlegge hvilke som er seriøse bidragsytere til forumet, og som dermed har gitt informasjon som vi mener har vært til å stole på. Hvordan vi orienterte oss om muligheter og begrensinger i prosjektet Før vi begynte på prosjektsøknaden hadde vi en såkalt brainstorming der alle sa hva de kunne tenke seg å ha med i prosjektet. Deretter ble det vurdert hva vi mente var realistisk å klare å gjennomføre. Første utkast til prosjektsøknad ble levert veileder i oktober 2004. Vår veileder Toralf Skrede mente vi ikke hadde dekket fagplanen godt nok og ville ha med flere punkter. Vi revurderte søknaden og implementerte flere funksjoner som vi trodde vi kunne klare å gjennomføre og som samtidig ville dekke flere mål i fagplanene. Vi satt da med en lang liste over funksjoner, løsninger og sensorer som ADL skulle bestå av. Da vi mot slutten av 2004 begynte å vurdere hvor lang tid de forskjellige delene av prosjektet ville ta, forstod vi at vi aldri ville kunne klare dette innenfor den tidsrammen prosjektet hadde. Prosjektgruppen tok da en avgjørelse og kuttet prosjektsøknaden ned der vi følte det var nødvendig, slik at det hele ble mer realistisk med tanke på tid. Endelig prosjektsøknad ble sendt i midten av desember og ble godkjent av veileder. I ettertid føler vi at veileder burde ha vært enda sterkere involvert i å sette begrensninger i prosjektet med tanke på tid og kvantitet. Hvilke ressurspersoner ble brukt Vi har stort sett basert oss på internettforum for hjelp. Vi har i realiteten bare hatt to ressurspersoner i umiddelbar nærhet som har kunnet hjelpe oss. Dette har vært Inge Vivås fra høyskolen i Bergen og Bruce McKibben på Elprint A/S. Inge Vivås har forelest klassen vår og introduserte oss for C-programmering av Atmel sine mikrokontrollere. Han har derfor hjulpet oss med grunnleggende spørsmål i C-programmering og gitt oss generelle råd og vink. Bruce McKibben er en av Norges fremste på design av kretskort. Han har svart på alle spørsmål vi har hatt rundt bruk av CADint og generelt rundt kretskortdesign. Uten hjelp fra Bruce McKibben ville vi ikke fått et så godt resultat på kretskortet vi designet til prototypen. - 8 -

Behov for Kunnskap Vi har hatt behov for kunnskap innenfor en rekke områder. Nesten all dokumentasjon vi har hatt tilgang til har vært skrevet på engelsk. Tilnærmet all kommunikasjon som har foregått på internett har også vært på engelsk. Dette har ført til god trening for hele gruppen når det gjelder å uttrykke seg på en skikkelig måte på et fremmedspråk. Ordbøker som for eksempel Clue, og funksjonene i MS 3 Word har vært nyttige i denne sammenheng. For å få skrevet kildekoden har vi måtte tilegne oss mer kunnskap om C-programmering. Vi begynte på prosjektet med et tynt grunnlag, men har lært mer og mer etter hvert som prosjektet har gått fremover. Det er imidlertid langt igjen før vi kan kalles drevne innen C-programmering. Når kildekoden var ferdig og vi startet utviklingen av kretskortet, måtte vi ha gode kunnskaper om CADint og generelt om kretskort utlegg. Denne kunnskapen har vi fått gjennom et kurs som ble holdt hos Elprint A/S. Når prototyp av kretskortet var ferdig produsert, måtte vi montere komponentene på en skikkelig måte. Dette krevde at vi oppdaterte oss på det nye loddetinnet som er på markedet og som krever litt høyere temperatur enn det vi er vant med fra tidligere. Når vi skulle lage prototyp av boksen til kretskortet måtte Elprint A/S ha tegninger produsert i AutoCAD. Årsaken var at maskinen som fresen var tilkoblet baserte seg på CAD tegninger. På denne måten kunne vi selv gjøre forarbeidet med å definere hva som skulle freses ut hvor i AutoCAD. Vi hadde på forhånd god kjennskap til AutoCAD 2000 da dette er et eget fag ved Bergen tekniske fagskole Til slutt har vi hatt behov for kunnskap innenfor en rekke områder når det gjelder utarbeidelse av denne rapporten. Nyttige automatiserings funksjoner i MS Word har bidratt til en oversiktelig rapport. Vi har i tillegg bruk MS Visio for de skjematiske tegningene og utarbeidelse av fremdriftsplaner. Adobe Photoshop har blitt brukt til å designe logoer og retusjere noen komponentbilder til bruk i prosjektrapporten og til bruk på internett. Til den muntlige prosjektpresentasjonen vil vi komme til å bruke MS Powerpoint. Dette krever god kunnskap om de forskjellige mulighetene i MS Powerpoint for å få til en god presentasjon med bra flyt. - 9 -

Type kilder som ble brukt Forum Den beste og mest brukte kilden til kunnskap har gjennom hele prosjektet vært diskusjonsforum på internett. Generelt er forum basert på at folk har en plass de kan stille spørsmål til andre som er interessert i og arbeider med et spesielt emne. Det forumet vi har brukt mest er www.avrfreaks.net hvor det primært er Atmel sine AVR kontrollere som diskuteres. I forumet kan medlemmene spørre hverandre om råd og få synspunkter og hjelp med AVR mikrokontrollere, generell programmering og elektroniske løsninger. Forumet har vært en fin og lærerik måte å lufte tanker og ideer på. Faglitteratur Av faglitteratur har vi hatt tilgang til datablader på alle komponenter vi har tatt i bruk. Vi fikk også bestilt en bok som forklarer C-programmering i CodeVisionAVR. Dessverre tok det uvanlig lang tid fra vi bestilte boken til den var oss i hende. Da vi endelig mottok boken, var vi egentlig ferdig med den innledende programmeringen av prosjektet. Bokas tittel er Embedded C Programming and the Atmel AVR. Ulike løsninger generelt Vi har gjennom hele prosjektet prøvd å velge de løsninger som gir flest muligheter for videre utvikling av ADL. Dette har medført merarbeid, men vi står igjen med et produkt som kan videreutvikles på sikt. ADL kan også benyttes på andre plasser enn i en bil, som for eksempel serverovervåkning, værstasjon og lignende. Samarbeidspartnere Vi har hatt et tett samarbeid med Elprint A/S på Hop i Bergen som fremstår som en unik bedrift på flere måter. Vi har alltid blitt godt mottatt og hjulpet på beste måte når vi har vært på besøk. Elprint A/S har bidratt mye og har hatt en viktig nøkkelrolle for at dette prosjektet har blitt en suksess for oss. Gjennom Elprint A/S kom vi også i kontakt en annen del av selskapet som heter Mekatronik. Det var her vi fikk frest ut lokkene til boksene våre. Vi tar også med at ELFA A/S har levert alle komponenter som vi har brukt i prosjektet. Alle deler har blitt bestilt gjennom laboratoriumassistent Roger Ølheim. Dette har fungert utmerket. - 10 -

Dataprogram som ble benyttet CodeVisonAVR CodeVisionAVR er et verktøy for å skrive kildekode til en mikrokontroller i høynivåspråket C. CodeVisionAVR gjør det mulig å kompilere kode slik at den kan brukes i program som AVR studio for simulering og overføring til mikrokontrolleren. CodeVisionAVR har et relativt stort bibliotek med ferdige funksjoner som vi har utnyttet. For mer informasjon se hjemmesiden http://www.hpinfotech.ro/ AVRstudio AVRStudio er et program som kan brukes til å skrive assemblerkode og teste denne koden ved hjelp av simulatoren. Dette blir så kompilert til maskinkode som kan overføres til mikrokontrolleren via STK500. Det er Atmel som står bak utviklingen av AVRstudio. For mer informasjon se hjemmesiden www.atmel.com AutoCAD Dette er et program for data maskinassistert konstruksjon. Det er et avansert og anvendelig program som brukes i mange sammenhenger. Vi brukte det til å definere utfresingen av lokket til monteringsboksen. For mer informasjon se hjemmesiden http://www.autodesk.no Skoleportalen It s:learning It s:learning er et pedagogisk og administrativt verktøy som er laget for å forbedre lære aktiviteter og lære metoder. Vi har valgt å bruke denne portalen for å holde alle gruppemedlemmene oppdatert på fremdriften i prosjektet. På denne måten har det vært mulig å være fleksibel i forhold til hvor vi har arbeidet med prosjektet. Vi har også latt alle relaterte personer få tilgang til prosjekt siden, slik at de kan følge utviklingen i prosjektet. For mer informasjon se hjemmesiden http://www.itsolutions.no/ MS Word Microsoft Word er verdens mest brukte tekstbehandlingsprogram og er en del av MS Office serien fra Microsoft. MS Word innholder gode verktøy som gjør arbeidet med tekstdokumenter enklere og raskere. Vi har brukt programmet under hele prosjektet for å dokumentere og logge alt som har blitt gjort. For mer informasjon se hjemmesiden http://www.microsoft.com/norge/office/word/prodinfo/overview.mspx - 11 -

MS Vision Visio 2003 er et program for oppretting av diagrammer og som vi har brukt til å illustrere flyt- og kretsskjemaer med. MS Visio er en del av MS Office serien fra Microsoft og er derfor tett integrert i resten av programmene som for eksempel MS Word. Dette har gjort det enklere å redigere skjemaer rett i MS Word under utarbeidelse av denne prosjektrapporten. For mer informasjon se hjemmesiden http://www.microsoft.com/norge/office/visio/prodinfo/overview.mspx CADint CADint er det programmet Elprint A/S baserer sine design på og er det programmet vi fikk en innføring i da vi var på kurs hos dem. Dette er en komplett programpakke for konstruksjon av skjema og kretsutlegg. Firmaet som i dag utvikler CADint har hovedsete i Sverige. CADint baserer seg på et eldre program som var lansert første gang i 1983 og som var DOS 4 basert. Programmet finnes i en evalueringsversjon som støtter maks 100 hull og to lag. Dersom det er behov for mer enn dette, må lisens kjøpes. Skolen har lisens på fullversjon. For mer informasjon se hjemmesiden http://www.cadint.se MACAOS MACAOS 5 er programmet som benyttes ved bestilling av kretskort hos Elprint A/S. Programmet ble utviklet på grunnlag av en idé Helge Nilsen, eier av Elprint A/S hadde. Han så for seg et program skulle redusere Elprint sitt arbeid i forbindelse med produksjon av kretskort. Tanken var at kundene skulle ha mulighet til å gjøre mer av arbeidet selv. Programmet ble lansert i 1999 og førte til at Elprint A/S har kunnet redusere sine priser på produksjon av småserier og prototyper. I dag blir MACAOS benyttet av Elprint A/S i Norge og av Norrköping Printed Circuits AB i Sverige. For mer informasjon se hjemmesiden http://www.macaos.no/ - 12 -

Del 2 - Hovedkomponenter og sensorer Hovedkomponenter Mikrokontroller ATmega16L Mål som dekkes i henhold til Vedlegg 1 Prosjektsøknad. 1. Felles mål a. Kunne bruke aktuell engelskspråklig dokumentasjon og faglitteratur. 2. Mål for fordypningsfaget elektronikk b. Kunne gjøre rede for mikroprosessorsystemer som brukes innen databehandling og i måle- og styresystemer. Spesifikasjoner ATmega16L AVR basert mikroprosessor. 1-8 MHz klokkefrekvens. 16kB ISP 6 Flash programminne. 512 Bytes med EEPROM. 7 1kB med SRAM. 8 32 GPR 9 registre. 3 timere/tellere. Intern oscillator. USART. 10 Interne og eksterne interrupt. 8 kanals 10 bits A/D 11 -konverterer. Bilde 1 - ATmega16 fra Atmel Corporation. - 13 -

Innledning Mikrokontrolleren ATmega16 fra Atmel er selve kjernen i prosjektet vårt og brukes til alt fra A/D-konvertering og til å styre LCD 12. ATmega16 ble lansert i 2002 og er en 8 bits AVR mikrokontroller. AVR er forkortelsen for Advanced Virtual RISC 13 og var en ny type teknologi som ble utviklet og patentert av Vegard Wollan og Alf-Egil Bogen som da arbeidet hos Nordic VLSI 14. Nordic VLSI klarte ikke å skaffe nok kapital til å kunne realisere produksjon av denne type mikrokontrollere i Norge. Rettighetene ble derfor i 1996 solgt til Atmel i USA. Utviklerne av AVR teknologien ble ledere av det norske datterselskapet Atmel Norway i Trondheim. I dag er det solgt mer enn 500 millioner AVR baserte mikrokontrollere fra Atmel og daglig produseres 100.000 nye. Detaljert beskrivelse For en fullstendig beskrivelse av ATmega16 henviser vi til Atmel sitt offisielle datablad som er lagt ved som vedlegg på CD. Vi nevner bare noen av de ulike egenskapene og spesielle funksjonene til ATmega16 som var viktige for oss, og som gjorde at vi valgte denne mikrokontrolleren. Figur 2 - AVR arkitektur ATmega16 er en mikrokontroller med høy ytelse og med svært lite energibehov, 1.1 ma ved 3V og 1 MHz hastighet. Den baserer seg på AVR teknologien, noe som er en kombinasjon av prosessortypene RISC og CISC 15. AVR baserte kontrollere omtales ofte som RISC fordi de fleste instruksjonene utføres i løpet av en klokkesyklus. Det er kun fem prosent av instruksjonene som krever to klokkesykluser. Dette betyr at mikrokontrolleren er svært effektiv, den klarer 1 MIPS 16 pr MHz, noe som igjen betyr at ved 1MHz utfører kontrolleren 1 instruksjon for hvert mikrosekund. For å oppnå denne effektiviteten benytter - 14 -

AVR-prosessoren Harvard-arkitektur 17 (i motsetning til Von-Neuman 18 ). Dette betyr at datakanalene for instruksjoner og data er atskilt slik at de mates inn i prosessoren uavhengig av hverandre. ATmega16 er utstyrt med egen en ADC 19 /MUX 20 krets som er svært sentral i vårt prosjekt. Det er nettopp denne kretsen som lar oss konvertere målinger til digitale verdier. Utetemperatur målingene ved hjelp av NTC 21 motstand er et eksempel på bruk av ADC/MUX kretsen og er forklart senere i rapporten. ATmega16 er også utstyrt med en intern klokkeoscillator slik at vi ikke trenger å bruke et eksternt krystall for å lage klokkepulser til mikrokontrolleren. Vi har valgt å sette denne til 1MHz, men hastigheten kan enkelt forandres til for eksempel 8 MHz ved å endre fuses 22 når mikrokontrolleren programmeres. Selv om kontrollerens klokkefrekvens drives av den interne klokkeoscillatoren, har vi gjort klar for tilkobling av ekstern oscillator på kretskortet. Dette er fordi andre har hatt problemer med den interne oscillatoren ved kommunisering med andre enheter via for eksempel RS232. Delkonklusjon ATmega16 ble valgt på bakgrunn av de egenskapene skissert over. ATmega16 har mange innebygde funksjoner og er en rimelig og relativt rask mikrokontroller. Dette passet svært godt til vårt planlagte prosjekt og dersom det i fremtiden er behov for mer programminne, kan vi gå over på ATmega32 eller en annen AVR basert 40 pins mikrokontroller. STK500 Mål som dekkes i henhold til Vedlegg 1 Prosjektsøknad. 1. Felles mål a. Vise kreative, praktiske og eksperimenterende evner i møte med utfordringer og ved løsning av oppgaver. b. Kunne bruke aktuell engelskspråklig dokumentasjon og faglitteratur. 2. Mål for fordypningsfaget elektronikk a. Kunne bruke programmeringsverktøy for mikrokontrollere til å lage enkle programmer for måling og styring. Innledning Utviklingskortet STK500 fra Atmel er et allsidig kort som brukes til å programmere, teste og eksperimentere med mikrokontrolleren. STK500 gir brukeren mulighet til å teste inn- og utganger ved hjelp av brytere og lysdioder som er montert på kortet. STK500 kobles til datamaskin via RS232, og mikrokontrolleren blir programmert ved hjelp av dataprogrammet AVRStudio. STK500 støtter mer enn 22 mikrokontrollere fra Atmel og kan utvides med forskjellige ekspansjonskort. Detaljert beskrivelse Vi brukte STK500 for å teste kildekoden vi utviklet. Prosjektgruppen arbeidet med forskjellige deler av kildekoden samtidig. Et prosjektmedlem utviklet rutinen for A/D - 15 -

konvertering, mens andre arbeidet med selve hovedprogrammet, interrupt og RS232 rutinen. Hver enkelt del av prosjektet ble grundig testet ved hjelp av STK500 som ble koblet opp med LCD, I 2 C sensorer og NTC-kretsen. I tillegg ble det også testet RS232 kommunikasjon med PC 23 for lagring av loggede data. Bilde 2 - STK500 utviklingskort fra Atmel STK500 ble også tilkoblet den utviklede knapperaden som styrer hva som skal vises på LCD. Det viste seg at knapperaden og mikrokontrolleren ikke kommuniserte som forventet og dette skapte mye hodebry og frustrasjon for den som arbeidet med nettopp denne delen av prosjektet. Se side 52 for mer informasjon vedrørende dette. Alle de elektriske kretsene ble til slutt koblet opp på et koblingsbord og mikrokontrolleren ble programmert slik at vi kunne foreta de endelige funksjons- og verifikasjonstestene før vi sendte prototypen til produksjon hos Elprint A/S. Bilde 3 - Emigrert vekk fra STK500-16 -

Delkonklusjon STK500 er et helt nødvendig utviklingskort for å realisere prosjekt av vår type og karakter. Bergen tekniske fagskole var allerede godt utstyrt med kort og vi var også godt kjent med utviklingskortet gjennom undervisningen på skolen. Vi fant det derfor naturlig å bruke STK500. MMC Mål som dekkes i henhold til Vedlegg 1 Prosjektsøknad. 1. Felles mål a. Bruke aktuell engelskspråklig dokumentasjon og faglitteratur. 2. Mål for fordypningsfaget elektronikk a. Kunne bruke digitale kretser som kommuniserer med hverandre over et bussystem. Innledning Helt i begynnelsen av prosjektet startet vi arbeidet med valg av lagringsmedium for ADL. Vi ville ha et lagringsmedium som var fremtidsrettet og målingene skulle kunne flyttes mellom ADL og PC uten krav til gode datakunnskaper. Vi ønsket også tilstrekkelig plass til å lagre målinger over lengre tidsperioder, noe som vil kunne medføre store datamengder. Vi ønsket derfor en lagringskapasitet på 128 MB eller mer. Detaljert beskrivelse Før vi tok en avgjørelse på hva lagrings medium vi skulle velge, måtte vi stille opp de ulike alternativene og vurdere dem opp mot hverandre. Vi valgte en løsning hvor vi sammen satt oss ned for å kartlegge de alternativene som vi i første omgang var aktuelle. Deretter vurderte vi hvert enkelt forslag. Resultatet ble denne oversikten: 1. Valg av lagringsmedier a. Ulike format i. EEPROM. ii. Eksternt flashminne. iii. Compact Flash (CF). iv. Harddisk (HD). v. Secure Digital (SD). vi. Multi Media Card (MMC). b. Vurderinger i. EEPROM 1. Begrenset antall lese- og skriveoperasjoner. 2. I utgangspunktet liten kapasitet. 3. Ville ikke gitt mulighet for å overføre data til PC uten bruk av RS232. - 17 -

ii. Ekstern flash minne 1. Lagring av data på en montert flash basert minnekrets for så å overføre til PC via RS232, er programmeringsmessig en enklere løsning enn hva lagring i FAT 24 vil være. 2. Ville ikke gitt mulighet for å overføre data til PC uten bruk av RS232. iii. Compact Flash (CF) 1. Bruker parallell kommunikasjon. 2. Allsidig lagringsmedium. 3. Bruk av CF innebærer bruk av totalt 3 porter på mikrokontrolleren. iv. Harddisk (HD) 1. Bruker parallell kommunikasjon 2. Allsidig lagringsmedium. 3. Bruk av HD innebærer bruk av minst 3 porter. 4. Dyr i forhold til minnekort. 5. Større fysisk størrelse. 6. Mindre tolerant for vibrasjoner og støt. 7. Bruker mye strøm. v. Secure Digital (SD) / Multi Media Card (MMC) 1. Bruker seriell kommunikasjon (SPI 25 ) 2. SD og MMC har samme formfaktor. 3. Alle MMC rutiner kan brukes på SD. 4. Ved nærmere undersøkelser viste det seg samtidig at MMC var mest utbredt blant Atmel sine brukere. Delkonklusjon Vi valgte å bruke MMC kort fordi vi vurderte denne løsningen til å være det beste alternativet. Vi kom frem til at MMC var fremtidsrettet format fordi kortene er vanlig i andre elektroniske enheter som digitalkameraer og mobiltelefoner. MMC kortene er således lett tilgjengelig og rimelige. Prisen for 256MB ligger i dag (2005) på ca. 250.- kroner. Kortene er i dag tilgjengelig med en kapasitet på opp til 1GB. - 18 -

I 2 C bussen Mål som dekkes i henhold til Vedlegg 1 Prosjektsøknad. 1. Felles mål a. Kunne bruke aktuell engelskspråklig dokumentasjon og faglitteratur b. Vise kreative, praktiske og eksperimenterende evner i møte med utfordringer og ved løsning av oppgaver. 2. Mål for fordypningsfaget elektronikk a. Kunne bruke digitale kretser som kommuniserer med hverandre over et bussystem. Spesifikasjoner I 2 C Enkel 2-veis databuss. Krever kun 2 buss linjer, SDA 26 og SCL 27. Antall sensorer er i utgangspunktet begrenset til en maks kapasitiv last på 400pF. Maks lengde på bussegment ca. 2 meter (uten bruk av tilleggsutstyr) Overføringskapasitet maks a. 100 kbps 28 i standard mode. b. 400 kbps i Fast mode. c. 3.4 Mbps 29 i High-Speed mode. Innledning I 2 C bussen ble utviklet på begynnelsen av 1980 tallet av Philips og har over en 20 års periode blitt verdens ledende standard innen system kontrollstyring. Teknologien er implementert i mer enn 1000 forskjellige kretser og er lisensiert til mer enn 50 selskap som utvikler enheter basert på I 2 C. Philips leverer selv mer enn 400 sensorer basert på I 2 C og hvert år utvikler de 40-50 nye enheter. Figur 3 - Offisiell I 2 C logo I 2 C bussen har gjennomgått flere forbedringer etter hvert som vår teknologiske utvikling har krevd det. I dag er I 2 C bussen for eksempel mye brukt i mobiltelefoner av flipp typen. Bindeleddet mellom skjerm og tastatur er da gjerne en I 2 C buss fordi dette kun krever 2 forbindelser, en for data (SDA) og en for synkronisering (SCL). På denne måten er det færre ledninger som eventuelt kan ryke og dermed utgjøre en feil. Detaljert beskrivelse I 2 C baserte enheter kan enkelt kobles på bussen fordi hver enhet har kommunikasjonsprotokollen implementert on chip. Derfor kan de også kommunisere med hverandre. Segmentet består av minimum en master (mikrokontroller) og en slave. - 19 -

Master på bussen har til oppgave å generere klokkepulsene, kontrollere adgang til bussen, samt generere start og stopp signaler. Det kan være flere mastere på et bussegment. Disse vil da få samme prioritet til sensorene som er koblet til bussen, men kun en kan lese/skrive til sensorene samtidig. Dersom flere mastere er tilkoblet samme buss, kan de kommunisere via I 2 C bussen i stedet for RS232. Dette var noe vi planla å utnytte i vårt prosjekt, men som senere falt bort grunnet nødvendige endringer i prosjektet basert på tiden vi hadde til rådighet. Figur 4 - Skjematisk tegning av I 2 C med pull up motstander I følge I 2 C datablad skal eksterne pull up motstander brukes på hver av linjene på bussen. Ved hjelp av disse motstand dras nivået på linjene opp til 5V, altså logisk høy. Vi brukte 4.7kΩ motstander, noe som er en typisk verdi på disse pull up ene. I følge datablad skal de ligge mellom 2kΩ og 10kΩ. Masteren styrer I 2 C bussen og har unike definerte kombinasjoner av SDA og SCL for å angi forskjellige tilstander på bussen. Disse er: 1. Buss ledig (Bus not busy) - Både SDA og SCL forblir logisk høye. 2. START (S) - Tilstanden er definert når masteren lar SCL være høy, samtidig som SDA går fra høy til lav. 3. STOP (P) - Tilstanden er definert når masteren lar SCL være høy, samtidig som at SDA går fra lav til høy. 4. Gyldig data på SDA (Data valid) - Dersom SDA er stabil i perioden SCL er høy. SDA kan bare skifte tilstand når SCL er lav. (Se Figur 5) 5. Kvittering (Acknowledge) - Hver enhet på bussen som blir adressert, må generere en kvittering etter å ha mottatt hver enkelt Byte. Master enhet må generere en tilhørende klokkepuls til dette kvitterings bit et og de skal stemme overens. - 20 -

Figur 5 - Gyldig dataoverføring Dersom master vil ha informasjon fra en slave som for eksempel en temperatursensor (DS1621), initieres først START sekvensen. Deretter overføres en kontroll Byte som inneholder adressen som identifiserer slaven, samt om det skal foretas en lese- eller skriveoperasjon. Når dette er utført overføres data og det tilhørende kvitteringsbit. Når slaven har sendt alle Bytene, legges SDA lav av slaven slik at master kan sette STOP tilstanden. Bussen oppfattes som opptatt (Busy) etter at START er initiert og ledig igjen en bestemt tid etter at STOP er initiert (se section 15 i datablad for nærmere informasjon). Figur 6 - Dataoverføring på I 2 C bussen Delkonklusjon Philips sin I 2 C buss er en allsidig og utbredt standard i industrien. Det utvikles stadig nye sensorer og disse er relativt enkle å implementere i et eksisterende I 2 C basert system. Det som er tidkrevende er å lage programmene for å bearbeide dataene fra sensorene. Vi brukte I 2 C først og fremst fordi vi hadde fått den introdusert gjennom undervisningen til Inge Vivås. Vi har bare forklart de viktigste tilstandene på I 2 C bussen. For mer inngående og fullstendig informasjon henvises til dokumentet fra Philips: THE I 2 C -BUS SPECIFICATION som ligger på CD som vedlegg. - 21 -

RS232 (USART) Mål som dekkes i henhold til Vedlegg 1 Prosjektsøknad. 1. Felles mål a. Vise kreative, praktiske og eksperimenterende evner i møte med utfordringer og ved løsning av oppgaver. b. Kunne bruke aktuell engelskspråklig dokumentasjon og faglitteratur. 2. Mål for fordypningsfaget elektronikk a. Kunne bruke digitale kretser som kommuniserer med hverandre over et bussystem. Spesifikasjoner RS232 Maks teoretisk lengde på overføringsmediet er 15 meter. Maks teoretisk hastighet er 115kpbs. Mottakers inngangssensitivitet +/- 3V. Mottakers inngangsimpedans 3-7kΩ Innstillinger i Hyperterminal For overføringen anbefaler vi bruk av HyperTerminal program. For en korrekt overføring skal følgende innstillinger benyttes: Hastighet: 4800 bps Data bits: 8 bit Paritet: Ingen Stopp bit: 1 Flyt kontroll: Ingen Bilde 4 Innstillinger i HyperTerminal - 22 -

Innledning I begynnelsen av prosjektet var det aktuelt å bruke to mikrokontrollere. En for presentasjon av data og en for lagring av data. For å overføre informasjon mellom disse to, trengte vi en overføringsprotokoll. Vi brukte da RS232 og foretok en del tester for overføring av data mellom to kontrollere. Dette fungerte bare delvis og etter en stund ble I 2 C bussen vurdert som en bedre løsning for overføring av data. Da grunnlaget for å bruke 2 mikrokontrollere senere falt helt bort, ble RS232 aldri brukt til dette formålet. Når MMC delen av prosjektet ikke ble realisert, trengte vi i stedet å få sendt data til en PC for lagring. Den enkleste måten å gjøre dette ble igjen vurdert til å være via RS232. Detaljert beskrivelse Protokollen ble utviklet på begynnelsen av 1960 tallet av det som i dag kalles EIA - Electronic Industries Association. Tanken bak RS232 var å komme frem til en standard for å sikre en pålitelig kommunikasjon mellom to enheter. Samtidig skulle en standardisering forenkle tilkobling av utstyr og sikre at produsentene av det respektive utstyret hadde noe konkret å forholde seg til i utviklingsarbeidet. RS i RS232 står for Recommended Standard og spesifiserer signalspenning, signaltiming, signalfunksjon og fysisk grensesnitt. Alle signaler på RS232 refererer seg til felles signal jord. Positiv spenning mellom 3 og 15 VDC representerer logisk lav (space) og en tilsvarende negativ spenning representerer logisk høy (mark). RS232 bruker Bipolar RZ 30 koding, også kjent som AMI 31. Tilstanden mellom -3 og 3V skal bare oppstå når signalene skifter nivå eller når utstyret er slått av. Figur 7 - RS232 spenningsnivå Når vi skal sende signal fra ATmega16 til en PC bruker vi den innebygde USART porten. Signalet er da på mikrokontrollerens TTL 32 nivå 5V. For å få de korrekte spenningsverdiene på signalet trengs en driverkrets. Vi bruker MAX232 som er spesielt konstruert for å gjøre signaler om fra TTL til RS232 standard. - 23 -

Delkonklusjon Vi har jobbet en god del med RS232 og funnet ut at protokollen egner seg veldig godt til overføring av mindre data mengder over relativt korte avstander. Siden ATmega16 har innebygd USART blir det en relativt enkel jobb å få sendt data til en PC, PDA 33 eller andre enheter som støtter hyperterminal og RS232. - 24 -

Valg av sensorer og tekniske løsninger A/D konvertering Mål som dekkes i henhold til Vedlegg 1 Prosjektsøknad. 1. Felles mål a. Kunne bruke aktuell engelskspråklig dokumentasjon og faglitteratur. 2. Mål for fordypningsfaget elektronikk a. Kunne gjøre rede for mikroprosessorsystemer som brukes innen databehandling og i måle- og styresystemer. b. Kunne forklare de mest vanlige prinsipper for omforming av fysiske størrelser til elektriske signal. Spesifikasjoner A/D konverteren i ATmega16 10 Bits oppløsning. 8 innganger. 2 differensielle innganger der det er mulighet for en forsterkning på 10x (20dB) eller 200x (46dB). Inneholder en sample and hold funksjon som gjør at inngangsspenningen blir holdt konstant gjennom hele konverteringen. Innledning A/D konvertering vil si å omforme analoge signaler til digitale verdier. Dette blir gjort ved å ta punktprøver av det analoge signalet og gjøre det om til en binær verdi. Hyppigheten til punktprøvene bestemmer nøyaktigheten på det konverterte signalet. I følge Nyquist sampling theorem skal foretas dobbelt så mange punktprøver som den høyeste frekvensen på det analoge signalet. A/D konverteren i ATmega16 har en 10 bits oppløsning. Dette betyr at vi får 2 10 = 1024 forskjellige trinn fra laveste til høyeste nivå på det analoge signalet. En av funksjonene til ATmega16 er innebygd A/D konvertering. Dette gjør at den passer godt til prosjektet. Når A/D konverteren er aktiv er det mulig å implementere 8 analoge sensorer. Vi har i test sammenheng valgt en NTC motstand for temperatur målinger, mye grunnet dens egenskaper og anbefalinger fra www.avrfreaks.net. Bilde 5 - NTC motstand - 25 -

Detaljert beskrivelse A/D konverteren gjør om analoge signaler til 10 bits digitale verdier. Den minste verdien tilsvarer jord og den største verdien tilsvarer i vårt tilfelle AVCC. Ved bruk av AREF låses referansespenningen til 5V, vi har derfor valgt å bruke AVCC for ha muligheten for flere uliker referansespenninger. Ved å bruke AVCC kan vi programmere mikrokontrolleren til å bruke en intern referansespenning på 2.56V, koble direkte til AREF 5V eller å bruke AVCC som gir en mulighet for bruk av støyredusering. Figur 8 - Analogt signal representert som digitale verdier NTC kretsen er en spenningsdeler referert til AVCC og jord. NTC motstanden har ved 25 C en motstand på 10kΩ. Vi får da en spenning på 2.5V på ADC0. Motstanden i NTC minker når temperaturen øker. Dette gir en spenningsendring på ADC0. Kondensatoren brukes for å redusere støy. Figur 9 - Spenningsdeling For at verdien fra A/D konverteren skal kunne representere en verdi i X C, bruker vi en tabell. Denne tabellen representerer temperatur verdier fra -27 C til +76 C. Verdiene fra ADC0 sammenlignes med tabellen og den respektive verdien lagres deretter i en variabel. Tabellen setter begrensninger på temperaturen fra -27 C til +76 C som passer til måling av ute temperaturer. Det er mulig å utvide tabellen eller eventuelt å bruke andre løsninger som 2. og 3. gradsligninger, men vi har valgt å ikke prioritere dette grunnet tid vi har hatt til rådighet. - 26 -

Delkonklusjon ATmega16 har en innebygd A/D konverter som gjør den meget anvendelig i kombinasjon med analoge sensorer. ATmega16 kan logge de fleste analoge signaler og dette gjør at ADL har et bredt bruksområde. DS1307 Mål som dekkes i henhold til Vedlegg 1 Prosjektsøknad. 1. Felles mål a. Kunne ta selvstendige avgjørelser og sette seg inn i nye problemstillinger. 2. Mål for fordypningsfaget elektronikk a. Kunne bruke digitale kretser som kommuniserer med hverandre over et bussystem. Spesifikasjoner DS1307 Real Time Clock som teller fra sekunder til dager og år. I 2 C buss lisensiert. Bruker mindre enn 500nA i batteri backup mode. Innledning DS1307 er en 8 pins klokke som også har en innebygd kalender funksjon. Den tar hensyn til skuddår og måneder med mindre enn 31 dager. Vi kan også velge om vi vil ha 12 eller 24 timers format på klokken. Ved å koble inn et lithiumsbatteri på 3V kan DS1307 holde på data i 10 år. DS1307 baserer seg på kommunikasjon over I²C bussen. Bilde 6 - DS1307 Real Time Clock (RTC) - 27 -

Detaljert beskrivelse For å få tilgang til klokken trenger den en adresse på I²C bussen slik at masteren vet hvilken krets den skal kommunisere med. Denne adressen er fastsatt til 1101000 fra produsent og kan ikke endres. I²C bussens virkemåte er nærmere forklart senere i rapporten. For at klokken skal gå må det kobles inn et krystall på 32,768 khz på pinne 1 og 2 (X1 og X2). Punktligheten til klokken avhenger av et nøyaktig krystall. Delkonklusjon Vi valgte å bruke DS1307 fordi vi trengte en klokke i ADL til presentasjon på LCD. Vi har også brukt klokken til å stadfeste tidspunktet på de lagrede sensorverdiene i RS232 filen. CodeVisionAVR har også støtte for denne kretsen. Dette har gjort den enklere å implementere i prosjektet. DS1621 Mål som dekkes i henhold til Vedlegg 1 Prosjektsøknad. 1. Felles mål a. Kunne ta selvstendige avgjørelser og sette seg inn i nye problemstillinger. 2. Mål for fordypningsfaget elektronikk a. Kunne bruke digitale kretser som kommuniserer med hverandre over et bussystem. Spesifikasjoner DS1621 Måleområde fra -55 C til 125 C. Oppløsning på 0,5. Innebygd termostat. Innledning DS1621 er temperatur sensor basert på I²C standarden. I ADL er kretsen brukt til å måle temperaturen i de omgivelsene hvor loggeren er plassert. Kretsen har også en termostatutgang på pinne 3 kalt T OUT. Bilde 7 - DS1621 Temperaturkrets Detaljert beskrivelse DS1621 er en såkalt bandgap basert temperatur sensor. Med bandgap menes en fysisk åpning som bare de elektronene med stor nok termisk energi (varme) kan bevege seg over. En integrert A/D konverter sørger for at målingene omformes til digitale verdier. Disse verdiene blir overført via I²C bussen. - 28 -

Delkonklusjon DS1621 er en temperatur sensor som har et stort måleområde. Grunnen til at vi valgte å bruke denne enheten er at vi ville måle temperaturen i de omgivelsene hvor loggeren skal plasseres. CodeVisionAVR har også støtte for denne kretsen. Dette har I likhet med DS1307 gjort den enklere å implementere i prosjektet. Knapperad Mål som dekkes i henhold til Vedlegg 1 Prosjektsøknad. 1. Felles mål a. Vise kreative, praktiske og eksperimenterende evner i møte med utfordringer og ved løsning av oppgaver. b. Kunne ta selvstendige avgjørelser og sette seg inn i nye problemstillinger. Innledning Vi trengte en menystyring på ADL for at brukeren skulle kunne velge hva som skulle vises på LCD. Vi designet en knapperad som gjorde menyvalg mulig ved hjelp av brytere. Da vi utviklet prototypen tok vi høyde for såkalt prelling (key-bouncing) som vil gjøre seg gjeldene i brytere. Prelling oppstår i tiden rett før kontaktflatene til bryteren føres sammen, og kan føre til at flere interrupt blir satt rett etter hverandre. Detaljert beskrivelse Vi brukte forumet på www.avrfreaks.net for å orientere oss rundt problematikken rundt prelling i brytere. Det viste seg at det var uenighet rundt dette temaet. Noen mente at problematikken ble best løst ved programmering, andre mente at eneste løsning var elektriske komponenter. Vi konfronterte Inge Vivås med problemet som mente dette var normalt å løse med elektriske komponenter, eventuelt i kombinasjon med kildekode. Vi valgte i første omgang å løse dette ved å designe en prototyp bestående av dioder, motstander og kondensatorer. Figur 10 - Skjematisk tegning som viser prinsippet for prototypen av knapperaden - 29 -

Hver bryter er koblet til mikrokontrolleren via et RC-ledd. Når en bryter trykkes vil kondensatoren sørge for en liten forsinkelse før inngangen legges lav. På vår prototyp er denne forsinkelsen ca. 47ns. På denne måten reduserer vi muligheten for prelling i trykknappene. Bryterne har jord på venstre side og på hver av inngangene på ATmega16 ligger det 5V fordi interne pull ups er satt. (Inngangene har Tri-state 34 ). I tillegg er alle bryterne koblet mot interrupt INT0 via diodene. På denne måten kan hver enkelt byter trigge interruptet uavhengig av den andre. Det ligger også 5V på INT0 og denne går ikke lav før en av diodene begynner å lede. Dette skjer når potensialet på katodesiden blir lavere enn på anoden. Da trekkes linjen mot jord, og interruptet trigges og ISR 35 utføres. Bilde 8 - Prototypen av knapperaden Delkonklusjon Vi testet prototypen ved hjelp av STK500 og den fungerte svært bra. Vi vurderte det slik at vi ikke hadde behov for å bedre knapperaden noe mer ved hjelp av programmering. - 30 -

Del 3 - Kildekode Generelt om C-programmering Historikk C programmeringsspråket kom tidlig på -70 tallet og ble etter hvert en standard innen programmeringsspråk. De siste årene har de fleste som programmerer dataprogram emigrert til C++, men C fortsatt dominerende i programmering av mikrokontrollere. Funksjon i C Funksjoner er en måte å gjøre en kildekode mer oversiktlig på og fører ofte til mindre totalforbruk av RAM. Det vanligste er å lage en funksjon når det er ønskelig å bruke deler av et program flere steder i samme kildekode. Dersom vi henviser til en funksjon i programmet, vil mikrokontrolleren foreta et hopp og dermed utføre instruksjonene i funksjonen. Når den er ferdig vender den tilbake til linjen etter den som startet funksjonen. En funksjon er det samme som en subrutine i assembly. For at en funksjon skal virke må den angis under globale variabler i hovedprogrammet. Funksjonen må også angis med samme navn etter main sløyfa. Etter funksjonsnavnet kommer koden avgrenset av hakeparenteser {}. Foran funksjonsnavnet er det angitt type inn varibel funksjonen skal ha. I parentes etter funksjonsnavnet er det angitt hvilken type variabel funksjonen skal returnere. int funksjonens_navn (char); I en funksjon kan det opprettes lokale variabler. Disse vil ikke være tilgjengelige utenfor funksjonen og den plassen som disse variablene bruker i RAM frigjøres når funksjonen avsluttes. På denne måten blir RAM forbruk redusert. Mål som dekkes i henhold til Vedlegg 1 Prosjektsøknad. 1. Felles mål a. Kjenne eget arbeidsområde og kompetanse og vite når annen fagkompetanse er nødvendig. b. Kunne ta selvstendige avgjørelser og sette seg inn i nye problemstillinger. c. Vise kreative, praktiske og eksperimenterende evner i møte med utfordringer og ved løsning av oppgaver. d. Kunne bruke aktuell engelskspråklig dokumentasjon og faglitteratur. 2. Mål for fordypningsfaget elektronikk a. Kunne bruke programmeringsverktøy for mikrokontrollere til å lage enkle programmer for måling og styring. - 31 -

Hovedprogram Innledning ATmega16 fra Atmel trenger på lik linje med alle mikrokontrollere en kildekode for å kunne utføre noe konstruktivt. Selve hovedprogrammet er utviklet i CodeVisionAVR og utfører de forskjellige operasjonene basert på hvilke valg brukeren har foretatt. Disse valgene styres ved hjelp av en knapperad som er tilkoblet mikrokontrolleren. Detaljert beskrivelse Se Vedlegg 3 Flytskjema for hovedprogram. Se Vedlegg 4 Kildekode Hovedprogrammet er utviklet slik at det skal være enkelt og oversiktlig for andre å sette seg inn i. Kildekoden inneholder derfor kommentarer som forklarer hoveddelene i programmet. Kjernen i hovedprogrammet er while løkkene som utfører den valgte operasjonen/visningen på LCD skjermen. Det er interrupt rutinen (ISR) som skriver endringer i bryterstatusen som while løkkene foretar sjekk på. Disse while løkkene er bygd opp slik at de først sjekker på en variabel og i dette tilfellet den variabelen som forteller hvilket valg som interrupt rutinen har satt. Dersom dette er riktig (true) for den aktuelle while løkken, vil den tilhørende operasjonen utføres. I motsatt tilfelle går programmet videre til neste while løkke og utfører samme sjekk der. I all hovedsak vil det alltid være en while løkke som går i hovedsløyfen og da oppgavene utføres i følgende sekvens: 1. LCD vil bli slettet med kommandoen lcd_clear() dersom ISR har blitt utført. Årsaken til dette er at vi da skal fjerne eventuelle tegn som kan henge igjen fra tidligere visninger på LCD. Dette problemet kan oppstå fordi vi har valgt å løse LCD visning som beskrevet i punkt 2. 2. LCD markør flyttes til utgangsposisjonen 0,0 (x,y). Dette gjøres for å sikre at teksten og verdien som skrives på skjermen vises på samme sted hver gang. På denne måten forsikrer vi oss om at tekst ikke på LCD. Vi kunne ha brukt funksjonen lcd_clear(); for å oppnå det samme, men da ville LCD skjermen blinket for hver oppdatering. Dette er ikke er spesielt pent å se på. 3. Når utgangsposisjonen på LCD skjermen er satt (0,0) er neste oppgave å hente den aktuelle verdien som skal vises på LCD. Dette kan for eksempel være å lese inne temperatur. Denne er basert på I 2 C bussen og vi bruker innebygde funksjoner i CodeVisionAVR som henter temperaturen fra DS1307, t0=ds1621_temperature_10(0); Denne verdien blir så bearbeidet og formatert med tilhørende tekst slik at den er klar for visning på LCD. Funksjonen lcd_puts sender hele tekststrengen til LCD. - 32 -

4. Når while funksjonen har sendt data til LCD er siste oppgave å sørge for at alle målte data blir sendt ut på RS232 for ekstern lagring. Dette er en egen funksjon som er nærmere forklart under RS232. 5. Avhengig av hvilken sensor som er valgt for visning på LCD, tar while løkken en liten pause (satt til 100ms på prototyp) før den igjen starter på nytt. Det første som skjer i while løkken er å sjekke om det gjort endringer i valget som bestemmer hva som skal vises på LCD. Dersom ingen ny visning er valgt, fortsetter løkken som før og begynner i punkt 1. Dersom det er blitt valgt en ny visning, er ikke lenger denne while løkken true. Programmet hopper derfor til neste while løkke i programmet og utfører en ny sjekk der. Delkonklusjon Selv om vår kjennskap til C-programmering fortsatt er svært begrenset, føler vi at vi klarer å få til det vi ønsker med dette hovedprogrammet. Vi har bare forklart hovedpunktene i hovedprogrammet og anbefaler at den som er spesielt interessert, studerer kildekoden og kommentarene der. Interrupt rutinen og de andre funksjonene vi har skrevet er forklart i egne deler i rapporten. Slik vi vurderer det, kan hovedprogrammet enkelt utvides etter hvert som ADL får flere sensorer. Dette var også målet med hvordan dette hovedprogrammet ble utformet. Interrupt rutine (ISR) Innledning For å kunne registrere brukerens valg foretatt ved hjelp av knapperaden, brukes et interrupt. Når et interrupt trigges, vil inngangen på PORTB leses. På denne måtes registreres hvilken knapp og dermed hvilken meny brukeren har ønsket å vise på LCD. Detaljert beskrivelse Selve ISR rutinen er kort og konsis (Se Vedlegg 5 Flytskjema ISR). I god programmeringsskikk utføres det minst mulig i selve rutinen slik at ikke hovedprogrammet til kontrolleren stopper opp. // External Interrupt 0 service routine interrupt [EXT_INT0] void ext_int0_isr(void) { sjekk_bryter=pinb&0b11111100; slett_lcd=1; } Vi har brukt interrupt INT0 på kontrolleren som er å finne på pinne 2 på PORTD. Alle bryterne på knapperaden er koblet mot denne pinnen slik at ISR utføres hver gang en bryter trykkes. - 33 -