Oppgave 5. Mikrokontroller. Gruppe GF506: Per Christian Henden

Transkript

1 Oppgave 5 Mikrokontroller Gruppe GF502: Marianne Andersson Kyrre Giertsen Gruppe GF506: Per Christian Henden SIE4005 DIGITALTEKNIKK OG DATAMASKINER NTNU 2001

2

3 Mikrokontroller

4

5 Sammendrag 1. Tema Laboratorieoppgave 5 i faget Digitalteknikk og Datamaskiner gikk ut på å kort undersøke virkemåten til en mikrokontroller av 8051-familien. 2. Problemstilling Det skulle skrives Assemblykode for kommunikasjon med tilknyttede inn- og utenheter. Dette skulle gjøres på to forskjellige måter; ved polling og ved avbrudd. Deretter skulle ekvivalente rutiner i høynivåspråket C og lavnivåspråket Assembler sammenlignes. 3. Resultater Vi greide å løse alle oppgavene. Under arbeidet fant vi at C-ekvivalenten kompilert til Assembler tok opp mange flere kodelinjer. I ett tilfelle så vi at 3 C-kodelinjer vi skrev ble gjort om til 10 Assembly-kodelinjer.

6

7 Innhold 1 Innledning 2 2 Bakgrunnsteori GT-kort Tastatur /8051 mikrokontroller Registre og I/O enheter Instruksjonssett Polling og avbrudd Stakk Keil PK Arbeidsbeskrivelse Oppgave Oppgave Oppgave Resultater Oppgave Oppgave Oppgave Konkluksjon 14 6 Utstyr 15 7 Tilbakemelding 15

8

9 1 INNLEDNING 1 Innledning Oppgaven gikk ut på å programmere en 8031 mikrokontroller ved hjelp av utviklingsmiljøet Keil PK51. Programmeringsspråkene C og Assembler skulle brukes i dette arbeidet, og en sammenligning av språkene skulle gjøres. Det var nødvendig å sette seg inn i instruksjonssettet og virkemåten til 8051-familien for å gjøre oppgavene. Mikrokontrolleren var koblet til et GT-kort 1. GT-kortet hadde blant annet skjerm og tastatur. Vi hadde tre oppgaver: 1. Programmere en rutine for å lese ett tegn fra tastatur og presentere det på skjermen til GT-kortet ved å bruke polling. 2. Bruke rutinen fra oppgave 1 sammen med en avbruddsrutine i et større program. 3. Undersøke et C-program med hensyn på generert Assemblykode for gitt C-kodebit. Vi skrev inn koden på datamaskina, kompilerte, simulerte og lastet ned koden til GT- kortet for så å teste programmet. I seksjon 3 på side 8 beskrives det hvordan vi i detalj gjennomførte arbeidet. 1 Detaljer om GT-kortet og teori bak avbrudd og polling kommer i neste seksjon 2

10 2 BAKGRUNNSTEORI 2 Bakgrunnsteori 2.1 GT-kort På labben bruker vi et spesialdesignet GT-kort, avbildet på figur 1. GT-kortet inneholder disse hovedkomponentene: Xess-kort, tastatur og brytere, to typer LCDdisplay, lysdioder, inn- og ut-porter og Codec 2. Xess-kortet inneholder blant annet mikrokontrolleren (8031), som denne rapporten hovedsaklig dreier seg om. Det inneholder også FPGA 3, ram 4 og kontakter for strøm og dataoverføring fra PC. Figur 1: GT-kort 2 Coder-Decoder. Behandler lydsignal fra mikrofon og sender ut på høyttaler-utgang 3 Field Programmable Gate Array, en brikke med programmerbar logikk 4 Random Access Memory, mikrokontrollerens program lagres her 3

11 /8051 mikrokontroller 2 BAKGRUNNSTEORI Tastatur Tastaturet krever ekstra oppmerksomhet. Det er en forskjell på signalet som sendes når vi trykker på en vilkårlig tast, og symbolet som er påmerket den tasten. For eksempel gir en 7 på tastaturet signalet 8, se figur 2 og 3. Vi trenger altså å konvertere verdiene vi får fra tastaturet om vi skal behandle dem matematisk eller vise dem på et av GT-kortets LCD-skjermer. Vi realiserer dette programmeringsmessig ved å lagre en tabell over hva de forskjellige interne verdiene tilsvarer for å så gjøre oppslag i denne. Konkret bruker vi formelen adresse = startadresse + index, hvor index er den verdien vi får av å trykke på knapp nummer index og startadresse er der konverteringstabellen starter i minnet. På den utregnede adressa vil vi da finne den "riktige" verdien for tastetrykket. Figur 2: Tastaturet på GT-kortet /8051 mikrokontroller En mikrokontroller er en liten prosessor som har forskjellige inn- og ut-enheter på samme brikke, og kan programmeres til å utføre flere forskjellige funksjoner familien av mikrokontrollere er verdens mest brukte. Over halvparten av alle verdens prosessorer er av denne typen. Den ble først lansert av Intel i 1980 og er senere produsert av en rekke leverandører i ulike varianter. Vår variant heter 8031 og har den forskjellen fra 8051 at den ikke har noen ROM, som typisk brukes for lagring av program. Den består av en sentral prosesseringsenhet (CPU), intern 4

12 2 BAKGRUNNSTEORI /8051 mikrokontroller RAM (128 byte), 4 stk. 8-bits I/O-porter, en serieport for seriell overføring, to tellere, avbruddskontroll og busskontroll. Den kan adressere 64Kbyte minne og kjører på en frekvens på 6.17 Mhz Registre og I/O enheter Figur 3 på neste side er en skjemategning av GT-labkortet med eksternt minne og I/O enheter. Alle I/O-enheter må tilordnes adresser som man kan lese inn til minnet og adresser og prosessere hvis man trenger det. På samme måten kan man skrive ut til denne adressen om enheten tillater dette. I vårt tilfelle brukte vi GT-kortets tastatur som INN-enhet og syvsegment-displayet som UT-enhet. I oppgave 3 benyttet vi også LCD-displayet til utskrift. Her følger en tabell over de enkelte I/O-enhetenes adresser: Adresse (HEX) Enhet Adresse (HEX) Enhet 8000 LCD-disp. Write code 9000 Tastatur, Read 8100 LCD-disp. Write data A000 Logikk R/W 8200 LCD-disp. Read code B000 Relé, Write 8300 LCD-disp. Read data F004 7-segmentdisplay Tabell 1: adresser for I/O enheter I Assembler kan vi definere konstanter. Det forenkler koden om vi definerer IO-adressene til konstanter. For eksempel: TASTATUR EQU 09000H gjør det mulig å bruke #TASTATUR for å referere til tastaturet. Den nedre delen av det interne minnet (0x00 til 0x29) til mikrokontrolleren brukes til en rekke spesielle registre, se tabell 2 på side 7. Området 0x30 til 0x7E kan brukes til datalagring. Vanligvis vil vi lagre stakken 5 her. I vårt oppsett hadde mikrokontrolleren adgang til 32Kbyte eksternt minne på GT-kortet. Der lagret vi programmer. Den siste, øvre delen av det intene minnet (0x7F til 0xFF) brukes til en rekke spesielle registre. Dette minneområdet kalles SFR 6. De registrene vi kommer til å manipulere er gjengitt i tabell 2 på side 7. 5 Forklaring i 2.4 på side 8 6 Spesial Functions Register 5

13 /8051 mikrokontroller 2 BAKGRUNNSTEORI Figur 3: Hva mikrokontrolleren er koblet til Fordi kontrolleren bare har 8-bits registre må vi gjøre et "triks" når vi skal aksessere I/O enhetene koblet til mikrokontrolleren. Det er fordi disse har 16-bits adresser. Vi lagrer de første åtte bit-ene i ett register (DPH) og de åtte siste bitene i ett annet register (DPL). Dette sammensatte registeret er på 16bit og kalles DPTR Instruksjonssett Figur 4 på side 16 inneholder et utdrag av instruksjonssettet til 8051/8031 mikrokontrolleren. For eksempel kan instruksjoner se slik ut: MOV Rn,#01H MOV Rn,Rm ADD Rn,Rm MOVX hvor n og m er registernummer fra 0 til 7. 6

14 2 BAKGRUNNSTEORI 2.3 Polling og avbrudd Register Forklaring Adresse SP Stakkpeker 81H DPL Datapeker lav 82H DPH Datapeker høy 83H TCON Timer register 88H IE Interrupt Enable register A8H A Akkumulator E0H Tabell 2: Spesielle registre For å plassere en instruksjonssekvens et bestemt sted i minnet brukes direktivet ORG. ORG 0003H betyr at de etterfølgende instruksjonene blir plassert fra 0x003 og oppover. 2.3 Polling og avbrudd Ved polling kjører datamaskinen et program i løkke hele tiden. Den utfører kun det spesielle programmet. En ulempe med det er at vi ikke får gjort noe annet enn de spesielle handlingene inni løkka. Avbrudd, derimot, er en ordning som tilrettelegger for at utførelsen av et program kan bli avbrutt for å gjøre spesielle operasjoner. I vårt tilfelle skriver vi tall til skjermen når noen trykker på en tast kan håndtere to eksterne avbrudd. Disse er satt til INT0 og INT1. Disse avbruddene må "skrus på" før prosessoren tar hensyn til dem. Dette gjøres ved å sette bit-ene IE (interrupt enable) og TCON (timer register). Avbruddet INT0 skjer når noen trykker på tastaturet. Vi skrudde på denne funksjonaliteten ved å sette EX0 bit-et. Vi satte også IT0 i TCON registeret, slik at prosessoren skulle "lytte" på negative flanke. I IE registeret måtte bit 7 (EA - enable interrupts) settes. TCON: TF1 TR1 TF0 TR0 IE1 IT1 IE0 IT0 IE: EA ET2 ES ET1 EX1 ET0 EX0 Når et avbrudd inntreffer vil mikrokontrolleren gå til en forhåndsdefinert plass i programminnet der avbruddrutinen for det aktuelle avbruddet er definert til å 7

15 2.4 Stakk 3 ARBEIDSBESKRIVELSE ligge. Avbruddet vi skal bruke (INT0) er tildelt plassen 0x03 i minnet. Neste forhåndsdefinerte avbruddsrutine er TF0 på adresse 0x0B. Det betyr at vår avbruddsrutine for INTO ikke kan ta opp mer enn 8 instruksjoner for å ikke kollidere med TF0. Instruksjonssekvensen vi skulle bruke var lengre enn dette. Dette problemet løste vi ved å legge inn et "hopp" (jump) til et annet sted i minnet for å få kjørt alle de instruksjonene vi ville. Merk: Vi kunne ha skrevet over avbruddsområdet til TF0 i dette tilfellet fordi vi ikke brukte TF0, men løsningen med hopp er mer generell. 2.4 Stakk En stakk er en LIFO 7 kø. Det er en datatype som har den egenskapen at man bare kan manipulere det øverste (siste som ble lagt på) elementet. Å legge til et element på stakken kalles en PUSH operasjon, og å ta ut det øverste elementet kalles en POP operasjon. Stakken har ingen fast plass i minnet på 8031, men stakkpekeren har fast posisjon i SFR. Vi setter stakkpekeren til adressa nederste element i stakken ligger på. Når vi legger noe på stakken må vi bruke minneadressen til elementet. For eksempel vil PUSH 82H legge DPL på stakken. 2.5 Keil PK51 På labben bruker vi et utviklingsmiljø laget av Keil Software, kalt Keil PK51, for å programmere 8031 kontrolleren. Det inneholder blant annet editor og debugger. Vi kan skrive både Assembly- og c-kode og kompilere denne til en hex-fil 8, som kan lastes ned til mikrokontrollerens minne (ekstern RAM på GT-kortet). Det er mulig å kompilere C-kode til Assembler. Debuggeren gjør det mulig å observere registre, programminne, dataminne, RAM og mer under hele kjøringen av programmet. 3 Arbeidsbeskrivelse I de følgende avsnittene beskrives det hvordan vi i detalj gjennomførte arbeidet. 7 Last In First Out 8 Fil som innholder maskinkode på binær form 8

16 3 ARBEIDSBESKRIVELSE 3.1 Oppgave Oppgave 1 Oppgave 1 gikk ut på å lage en assemblyrutine som skulle gå i en evig løkke og lese tastaturet på GT- labkortet hele tiden. Dette kalles polling. Den skulle også skrive ut verdien som ble påtrykket tastaturet til syvsegmentsdisplayet. Følgende pseudokode var gitt til oppgaven: LOOP: Les tastatur. Filtrer bort 4MSB(null ut). Beregn oppslagsadresse i konverteringstabell. Gjør oppslag. Skriv verdi til 7- segmentdisplay. Hopp til LOOP. Vi skulle altså lage en løkke som oppfylte kravsspesifikasjonene gitt i pseudokoden, og sette inn denne på gitt plass i assemblyprogrammet gitt i oppgaven. Vi begynte med å kopiere katalogen lab5 til vårt område, og åpnet prosjektet lab5_1.prj i programmet KEIL. Så åpnet vi filen LAB5_A51 i prosjektet. I denne fila fantes et mangelfullt assemblyprogramm for oppgave 1. Ved hjelp av utdraget fra instruksjonssettet til mikrokontroller 8051/ 8031 som var gitt i labheftet, lagde vi følgende assemblykode for å løse oppgaven: 1 CLR A 2 MOV DPTR, # TASTATUR 3 MOVX 4 ANL A, # 0 FH 5 ADD A, R2 6 MOV R1, A 7 MOV 8 MOV DPTR, # SYVSEGM 9 A 10 JMP LOOP Forklaring: 1. Sletter evt. innhold i akkumulatoren 2. Laster DPTR med adressa til tastaturet 9

17 3.2 Oppgave 2 3 ARBEIDSBESKRIVELSE 3. Last data fra det DPTR peker på til akkumulator 4. Logisk and med for å filtere ut de fire første bit-ene 5. Legger innholdet i register R2 til det som er i akk. og lagrer resultatet i akkumulator. 6. Laster akkumulatoren til register R1 7. Laster det som adressa lagret i R1 peker på (konvertert tastaturverdi) til akkumulator 8. Last inn adressa til syvsegmentdisplayet i DPTR 9. Skriv data fra A til minneområdet DPTR peker på (syvegmentdisplayet) Videre kompilerte vi programmet. Det oppstod ingen problemer og programmet var klart til simulering i dscope- 51. For å kunne kompilere et prosjekt må vi ha ei ini- fil som inneholder navnene til alle filene som er med i prosjektet. For å realisere dette var det satt opp i en ini- fil, som lå ferdig til bruk. Vi anga plasseringen til ini- fila, og startet dscope- 51. Se figur 5 på side 17 for et skjermbilde. I dette skjermbildet fantes et Regs (register)- vindu. Mens vi gikk stegvis gjennom programmet, observerte vi i Regs- vinduet A (akkumulator), registrene R0 tilr7, DPTR, PSW (program status register), SP (stakk peker), og hvor lang tid(hvor mange sykler) koden brukte. Når vi mente at programmet fungerte som ønsket under simulering, lastet vi det ned til GT- labkortet. Vi trykte inn ulike verdier på tastaturet, og kontrollerte at de verdiene som stod på tastaturet var de samme som ble skrevet ut på syvsegmentsdisplayet. 3.2 Oppgave 2 I oppgave 2 skulle koden fra oppgave 1 skrives om til å bli et avbruddsdrevet program. Det avbruddsdrevne programmet skulle ha et hovedprogram som initialiserer for eksternt avbrudd 0, og ellers går i en evig løkke. Man må også ha en avbruddsrutine som leser tastaturet og skriver verdien til syvsegmentsdisplayet. Vi begynte med å åpne prosjektet lab5_2.prj, og videre å åpne fila lab_2.a51 som lå i det. Først skrev vi ei subrutine for avbrudd, og deretter initialiserte for avbrudd i hovedprogrammet. Vi brukte kode fra oppgave1 for å lese fra tastatur og skrive til syvsegmentsdisplayet. 10

18 3 ARBEIDSBESKRIVELSE 3.2 Oppgave 2 1 ; a v b r u d d s v e k t o r og a v b r u d d s s u b r u t i n e 2 3 ORG 0003H 4 PUSH 0 8 2H 5 PUSH 0 8 3H 6 PUSH 0 E0H 7 JMP AVBRUDD 8 9 AVBRUDD: ; Kode f o r IO f r a oppgave CLR A 14 MOV DPTR, # TASTATUR 15 MOVX 16 ANL A, # 0 FH 17 ADD A, R2 18 MOV R1, A 19 MOV 20 MOV DPTR, # SYVSEGM 21 A POP 0 E0H 24 POP 0 8 3H 25 POP 0 8 2H RETI ; i n i t i a l i s e r i n g f o r e k s t e r n e avbrudd SETB IT0 32 SETB EA 33 SETB EX0 Forklaring: 11

19 3.3 Oppgave 3 3 ARBEIDSBESKRIVELSE 3 ORG 0003H 4 PUSH 082H 5 PUSH 083H 6 PUSH 0E0H 7 JMP AVBRUDD 9 AVBRUDD: 10 ; Koden fra oppgave 1 23 Hente DPL ut fra stakken 24 Hente DPH ut fra stakken 25 Hente akkumulator ut fra stakken 26 ; Initialisering for eksterne avbrudd 27 Returner etter avbrudd, fortsetter med å blinke lys 31 Setter på mikrokontrolleren reagerer på negativ flanke for avbrudd 32 Setter på avbrudd 33 Setter på eksternt avbrudd 0 Vi kompilerte programmet, anga som i oppgave1 plasseringa til ini- fila, og startet dscope- 51. Vi åpnet Vinduet " Interrupt System" i dscope- 51. Her krysset vi av for eksternt avbrudd 0. Se figur 6 på side 18 Nå begynte vi å gå stegvis gjennom koden, og å observere at de riktige bitene ble satt når enable for avbrudd var satt høy i assemblykoden. Nå når disse bit-ene var satt, brukte vi avkrysningsboksen IEO til å generere avbrudd under kjøringa. Mens vi nå "steppet" gjennom programmet observerte vi innholdet i akkumulator, DPTR og Rn, der n = 0?7. Når disse verdien var som forventet lastet vi hexfila samt fila lab5.bit ned til GT- kortet. Vi observerte nå at det ble skrevet ut et løpelys på den ene dioderekka på GT- kortet. Da kunne vi begynne å kontrollere at programmet virket som ønsket. Vi testet dette på samme måte som i oppgave1 ved å skrive inn verdier på tastaturet og kontrollere at de verdiene som vistes på syvsegmentsdisplayet var de samme. 3.3 Oppgave 3 I oppgave 3 skulle vi få demonstrert hvordan et program skrevet i C- kode ville bli oversatt til assemblykode. På labben begynte vi med å åpne prosjektet lab5_3.prj, og så åpne fila LAB5_3.C som lå i prosjektet. Her lå det kode for å utføre regnestykket Produkt = Tall1 * Tall2 I denne koden lå blant annet kode for lesing av tastatur og skriving til LCDdisplay, initialisering for avbrudd, selve avbruddsrutina og hovedrutina. Mikro- 12

20 4 RESULTATER kontrolleren jobber såpass fort at det kan være vanskelig for oss å følge med på det som skjer. Derfor er det laget en funksjon delay() som legger inn pauser i programmet. Det vi gjorde var å lage en funksjon som kalte opp denne funksjonen flere ganger, slik at pausen ble lengre. 1 l o n g _ d e l a y ( i n t t ) 2 while ( t > 0 ) { 3 void ( d e l a y ( ) ) ; 4 t ; 5 } Når dette var gjort kompilerte vi prosjektet i Vision. Så anga vi plasseringen til ini- fila som hørte til oppgave3, og startet dscope- 51. Her brukte vi kommandoen StepInto til å steppe en instruksjon. Da hoppet vi til hovedprogrammet og så det i Module- vinduet. I vinduet kunne vi velge om vi ville se høynivåkoden, eller lavnivåkoden eller begge deler samtidig(mixed). Vi valgte mixed, og scrollet oss fram til det punktet hvor funksjonen long_delay() ble utført. Så fant vi fram til hvor mange kodelinjer vi hadde skrevet i C, og hvor mange assemblylinjer dette tilsvarte. Videre lukket vi dscope, lastet designet ned til testbenken og prøvde multipikatoren en del ganger. Dette gjorde vi ved å skrive to tall adskilt med * inn på tastaturet, og så å skrive # som var kommandoen for å regne ut regnestykket. Vi regnet produktene om fra heksasesimale tall og kontrollerte at de stemte med de forventede produktene. 4 Resultater 4.1 Oppgave 1 Under simuleringen så vi at registrene inneholdt de rette verdiene gjennom hele programrutinen vår. Etter å ha lastet ned kompilert kode til GT-kort, fant vi at den verdien vi trykket på tastaturet viste i syvsegmentdisplayet, som det skulle. 4.2 Oppgave 2 Under simuleringen så vi at registrene inneholdt de rette verdiene gjennom hele programrutinen vår. Ved jump-instruksjonen hoppet programpekeren til rett sted i minnet. Når vi sendte et avbrudd ved å velge avbrudd INT0 på meny, så vi at programpekere flyttet seg til rett sted (0x003). Da ble vår kode for å lese fra 13

21 4.3 Oppgave 3 5 KONKLUKSJON tastatur og skrive til skjerm ble utført. Etter å ha lastet ned kompilert kode til GTkort, fant vi at den verdien vi trykket på tastaturet viste i syvsegmentdisplayet, som det skulle. I tillegg til dette blinket alle lysene i sekvens på GT-kortet. Det så ut som om blinkinga og skriving til display skjedde samtidig, men mikroprosseren byttet på oppgavene. Byttet gikk så fort at vi ikke kunne se det. 4.3 Oppgave 3 Når vi prøvde ut multiplikasjon på GT-kortet fikk vi disse resultatene: 5*5= 19 8*8= 40 8*6= 30 9*8= 48 Inn-verdi og ut-verdi er hexadesimale verdier, og er rette. I denne oppgaven observerte vi at det er mye lettere å programmere i C, enn å programmere rett i assembly-kode. Grunnen til dette er at C-kode er mye mer oversiktlig og ganske likt andre kjente programmeringsspråk. I tillegg blir det mindre å skrive. Vi skrev 3 linjer C-kode (se oppgave 3) som ble til 10 linjer assembly-kode. Man har mer kontroll når man skriver direkte i assembly- kode. Skriver man i C vil kompilatoren oversette til assembly-kode. Det er ikke sikkert at den koden kompilatoren velger er den beste. 5 Konkluksjon Gjennom arbeidet med lab5 lærte vi forskjellen på polling og avbrudd, og litt om 8051-Assembly. Vi ble også kjent med programmeringsmiljøet Keil PK51 som vi brukte i arbeidet. Ved å se på en rutine for å gange sammen to tall i C og Assembly fikk vi sammenliknet programmering i de to språkene, og sett på forskjellene i arbeidsmengde og funksjonalitet. Det oppstod ingen problemer under arbeidet med oppgaven. 14

22 7 TILBAKEMELDING 6 Utstyr GT-kort nummer 13 Microsoft Windows NT 4.0 Service Pack 6 build 1381 Bitware Uvision/5.1 versjon 1.24 Evaluation Edition Keil dscope-251/51 versjon 1.3p 7 Tilbakemelding Labben har vært grei, synes vi. Det har vært for få studasser til tider på labben. Også på forberedelsene. Det har vært svært dårlig luft på labben, og vi får hodepine av det. 15

23 7 TILBAKEMELDING Figur 4: Utdrag av instruksjonssettet til 8051/8031 mikrokontroller 16

24 7 TILBAKEMELDING Figur 5: dscope debugger 17

25 7 TILBAKEMELDING Figur 6: Interrupt vindu 18