Keskeytykset¶
Tietokoneessa keskeytys on signaali CPU:lle, joka saa sen nimensämukaisesti keskeyttämään ajettavana olevan ohjelman suorituksen. Keskusyksikkö tallentaa tilansa ja siirtyy suorittamaan keskeytyksen käsittelyrutiinia. Kun käsittelijä on suoritettu, keskusyksikkö lataa tallennetun tilansa takaisin ja jatkaa ajossa olleen ohjelman suorittamista juuri siitä tilasta mihin jäätiin. Keskeytyksen etuna on se, että koska signaalit oheislaitteelta tai -komponentilta voivat tulla milloin vain (ts. asynkronisesti), keskusyksikön ei tarvite käyttää aikaansa kyselemään oheislaitteen tilaa.
Keskeytys voi olla joko laitteistopohjainen (keskusyksikön sisäinen oma tai oheislaiteelta tuleva) tai ohjelmallinen. Laitteistokeskeytyksen aiheuttaa tyypillisesti jokin asynkroninen (riippumaton ohjelmien ajoituksesta) tapahtuma keskusyksikön sisällä tai oheislaitteessa. Keskeytys voi siis tapahtua CPU:ssa ajettavan ohjelman näkökulmasta millä hetkellä tahansa. Laitteistokeskeytyksiä tuottavat keskusyksikössä esim. nollalla jakaminen (virhetilanne) tai oheislaitteista mm. kiintolevy, I/O-liitynnät, näppäimistö, hiiri, jne, kertovat että olisi uutta dataa. Ohjelmallinen keskeytys aikaansaadaan erityisellä konekielen keskeytyskäskyllä, esim. INT-käsky Intelin x86 -prosessoreissa. Ohjelmistokeskeytys ei ole sama asia kuin sen käsittelyrutiini ajateltuna tavallisena funktiona, vaan käsky laukaisee keskusyksikössä keskeytyssignaalin, joka käsitellään käyttöjärjestelmässä samoin kuten muutkin keskeytyssignaalit ja sitten suoritetaan käsittelijä. Ts. kyse on laiteläheisemmästä korkeamman prioriteetin toiminnosta.
Kuvassa alla ATmelin ATtiny2313-mikrokontrollerin pinnijärjestys, jossa punaisella merkittynä kaksi ulkoista laitteistokeskeytys-pinniä. Näihin pinneihin voisimme kytkeä jonkun oheislaitteen keskeytyslinjan ja näin vastaanottaa sen lähettämät keskeytyssignaalit. Keskeytyksiä varten mikrokontrollereissa on yleensä omat pinnit, jotka on kytketty fyysisesti piirin keskeytysten hallintalogiikkaan.
Keskeytyksillä on prioriteetti. Korkeamman prioriteetin keskeytys suoritetaan ensin, jos vaikkapa useita eri keskeytyksiä ilmenee samaan aikaan tai kun toista ollaan suorittamassa. Tällöin korkeamman prioriteetin keskeytys keskeyttää alemman prioriteetin käsittelyrutiniin suorituksen ja suorittaa omansa ensin. Yleensä RESET-pinnistä tulevalla laitteistokeskeytyksellä on kaikkein korkein prioriteetti. Sitten tulevat laitteistokeskeytykset, koska ne ovat tyypillisesti aikakriittisiä, esimerkiksi kovalevyltä tulevat keskeytykset. Sitten tulevat ohjelmistokeskeytykset, joille ohjelmoija voi asettaa prioriteetin. Ohjelmistokeskeytyksiä siis hallitaan ohjelmoijan määrittämällä tavalla ja nekin voivat ajaa toistensa yli.
Keskeytyksen käsittelyrutiini on melkein kuin funktio, mutta sitä ei koskaan kutsuta itse ajettavista ohjelmista. Tämä on tärkeää siksi, että ennen keskeytyksen käsittelijän suorittamista täytyy prosessorin tila tallentaa, ja kutsumalla käsittelijää funktiona ei tätä tallennusta tehtäisi. Rutiini ei myöskään palauta mitään arvoa, mutta siinä voidaan käsitellä globaaleja muuttujia tai rekistereitä.
Käsittelyrutiinit ovat aikakriittisiä kahdesta syystä: ne keskeyttävät ajossa olevan ohjelman ja ne voivat ajaa toistensa yli. Tällöin koko ohjelman suoritus on helppoa (virheellisesti) blokata korkean prioriteetin keskeytyksen käsittelijällä, jonka suoritus kestää pitkään. Meidän RTOS määrittelee, että laitteistokeskeytys saisi kestää max 5 mikrosekuntia ja ohjelmistokeskeytys luokkaa 100 mikrosekuntia. Eli käytännössä vain vähän asiota voidaan tehdä käsittelijässä. Tästä syystä käsittelijät usein vain muuttavat rekisterien tai globaalien muuttujien arvoja, esimerkiksi kertoakseen, että oheislaitteelta olisi tulossa uutta dataa. Reagointi käsittelijän muuttamaan arvoon tehdään sitten ajettavassa ohjelmassa.
Keskeytysten käyttö¶
Seuraavaksi käymme esimerkinomaisesti läpi useita tapoja, joilla RTOS:ssa voidaan käyttää keskeytyksiä. Esittelemme sekä ulkoisia laitteistokeskeytyksiä (pinnin ja oheislaite) sekä sisäisen laitteistokeskeytyksen (UART-sarjaliikenne).
Pinni-keskeytys¶
Aiemmalla kappaleessa esittelime pinnin tilan muutokseen reagoivan keskeytyksen. Palataanpa asiaan..
...
// Pinnin asetusmuuttuja
PIN_Config buttonConfig[] = {
Board_BUTTON0 | PIN_INPUT_EN | PIN_PULLUP | PIN_IRQ_NEGEDGE,
PIN_TERMINATE
};
...
// Pinnin keskeytyksen käsittelijä
void buttonFxn(PIN_Handle handle, PIN_Id pinId) {
...
}
Int main() {
...
// Kerrotaan RTOS:lle että pinnin buttonHandle keskeytyksen käsittelijä on buttonFxn
if (PIN_registerIntCb(buttonHandle, &buttonFxn) != 0) {
System_abort("Error registering button callback function");
}
...
}
Huomataan Pin_Config-rakenteessa pinnille asetettu vakio
PIN_IRQ_NEGEDGE
, joka itseasiassa määrittelee pinnille keskeytyksen! Tämä keskeytys tapahtuu, kun pinnin tila muuttuu HIGH (käyttöjännite) -> LOW (maataso), ts. laskevalla reunalla, ja siitä lähtee signaali MCU:lle. Signaalin sieppaamme funktiokutsussa
PIN_registerIntCb
(Pin Interrupt Callback) annetulle funktiolle, eli tässä funktiolla buttonFxn
. Pinnille voimme asettaa keskeytyksen myös nousevalla reunalla, eli kun tila muuttuu LOW -> HIGH, vakiolla
PIN_IRQ_POSEDGE
tai molemmille reunoille PIN_IRQ_BOTHEDGES
. Se, millaisen keskeytyksen oheislaite antaa, on määritelty sen datakirjassa. Mitä tässä itseasiassa tapahtuu? No, Pin-kirjaston funktiot asettavat MCU:n sisäisistä keskeytysrekistereistä näitä vakioita vastaavat bitit päälle ja pois käyttäen bittioperaatioita. Meidän helpotukseksi tämä toiminnallisuus on abstrahoitu kirjaston funktioihin.
Oheislaitteiden keskeytykset¶
Esimerkkinä oheislaitteen aiheuttamasta ulkoisesta keskeytyksestä käytämme SensorTagiin integroitua varsin monipuolista MPU9250-sensoria. Sensoriin on integroitu asentoanturi (gyro), kiihtyvyysanturi, magnetometri. Sensoria voidaan käyttää myös kompassina.
SensorTag:ssa on valmiiksi asetettu ulkoinen keskeytyslinja
Board_MPU_INT
sensorille (CC2650STK.h). Tämän otamme käyttöön ihan samoin kuin yllämainitun I/O-pinni -keskeytyksen, mutta nyt opimme lisäksi kontrolloimaan milloin keskeytyksiä tapahtuu.// Pinnien asetus
static PIN_Config MpuPinTable[] = {
Board_MPU_INT | PIN_INPUT_EN | PIN_PULLDOWN | PIN_IRQ_DIS | PIN_HYSTERESIS, // TAI-operaatio
PIN_TERMINATE
};
...
// Taskifunktio
Void sensorTask(UArg arg0, UArg arg1) {
...
// Sallitaan nousevan reunan keskeytys pinniltä Board_MPU_INT
PIN_setInterrupt(hMpuPin, PIN_ID(Board_MPU_INT) | PIN_IRQ_POSEDGE); // Hox! TAI-operaatio
...
// Kielletään pinnin Board_MPU_INT keskeytykset
PIN_setInterrupt(hMpuPin, PIN_ID(Board_MPU_INT) | PIN_IRQ_DIS); // Hox! PIN_IRQ_DIS
}
// Käsittelijafunktio
Void MpuIntFxn(PIN_Handle handle, PIN_Id pinId) {
// Tässä nyt kutsutaan toista funktiota
// Mutta nopeampaa olisi tehdä asiat itse tässä
erittain_nopea_funktio();
}
int main(void) {
...
// Otetaan käyttöön pinnin ym. MpuPin
hMpuPin = PIN_open(&MpuPinState, MpuPinTable);
if (hMpuPin == NULL) {
System_abort("Pin open failed!");
}
// Asetetaan sen keskeytyksen käsittelijäfunktio
PIN_registerIntCb(hMpuPin, &MpuIntFxn);
...
}
Puretaanpas tämä esimerkki. Ensin pinnin
Board_MPU_INT
alustuksessa käytämme vakiota PIN_IRQ_DIS
kertomaan että pinnin keskeytys on pois päältä (disabled). Main-funktiossa asetamme keskeytykselle käsittelijäfunktion
PIN_registerIntCb
, joka on tässä esimerkissä MpuIntFxn
. Nyt, joka kerta kun keskeytys tulee, suoritetaan tämä funktio. Funktiossa itsessään sitten suoritamme erittäin nopeaa koodia, joka tekee mahdollisimman vähän! Tämä siksi, kun todellakin keskeytämme muun ohjelman suorituksen.. Nyt tosin alustuksessa asetimme keskeytyksen pois päältä, joten käytämme taskissa funktiota
PIN_setInterrupt
asettamaan keskeytyksen ensin päälle. Vakiolla PIN_IRQ_POSEDGE
keskeytys aiheutuu pinnin nousevalla reunalla. Tyypillisesti keskeytys kannattaa laittaa päälle viimeisellä mahdollisella hetkellä koodissa. Keskeytystä ei saisi laittaa päälle ennenkuin sensori on alustettu haluttuun toimintamoodiin. Esimerkissä on vielä keskeytyksen asetus pois päälle samalla funktiolla, tällöin vakio on sama kuin alustuksessa, eli PIN_IRQ_DIS
.Sarjaliikenne-keskeytys¶
Viime luennoilla kävimme läpi tavan lukea sarjaporttidataa UART_read-funktiolla niin, että taski jäi jumiin odottamaan dataa saapuvaksi (Blocking) . Tämä ei kuitenkaan ole paras tapa odottaa dataa UART-piiriltä, koska nyt.. taskimme jäi jumiin odottamaan. Sarjaliikenne, ainakin UART:n kautta on CPU:lle varsin hidas operaatio, joten ei oikein ole syytä jumittaa taskia viemään laitteen resursseja.
Onneksi voimme asettaa sarjaliikenteen toimimaan ei-blokkaavalla tavalla, kuten esimerkissä alla. Nyt UART_read-funktio ei enää jumitakaan taskin suoritusta vaan odottaa keskeytystä, johon reagoida.
...
uint8_t rxBuf[10]; // Vastaanottopuskuri
...
static void uartFxn(UArg arg0, UArg arg1) {
UART_Handle handle;
UART_Params params;
UART_Params_init(¶ms);
params.baudRate = 9600;
params.readMode = UART_MODE_CALLBACK; // Keskeytyspohjainen vastaanotto!
params.readCallback = &uart_receive; // Käsittelijäfunktio!
params.readDataMode = UART_DATA_TEXT;
params.writeDataMode = UART_DATA_TEXT;
// Otetaan UART käyttöön ohjelmassa
handle = UART_open(Board_UART, ¶ms);
if (handle == NULL) {
System_abort("Error opening the UART");
}
// Käynnistetään odotus, odotamme kunnes tulossa on yksi merkki dataa
UART_read(handle, rxBuf, 1);
while(1) {
// ikuinen looppi
}
}
// Käsittelijäfunktio
static void uart_receive(UART_Handle handle, void *rxBuf, size_t len) {
// Nyt meillä on siis haluttu määrä merkkejä käytettävissä
// rxBuf-taulukossa, pituus len, jota voimme käsitellä halutusti
// Tässä ne annetaan argumentiksi toiselle funktiolle (esimerkin vuoksi)
tehdaan_jotain_nopeasti(rxBuf,len);
// Käsittelijän viimeisenä asiana siirrytään odottamaan uudelleen..
UART_read(handle, rxBuf, len);
}
Int main() {
...
Board_initUART();
...
BIOS_start();
return 0;
}
Erona aiempaan tässä on readMode-parametrin asetus
params.readMode=UART_MODE_CALLBACK
, joka muuttaa kirjaston toimintaa oleellisesti. Tässä nyt asetamme vastaanottoon callback-funktion uart_receive
, jota kutsutaan kun dataa on saatavilla. Funktion määrittelyssä sen parametrien, taulukon rxBuf
ja vastaanotettujen merkkien määrä len
, kautta pääsemme käsiksi vastaanotettuun dataan. Kirjaston sisäisesti tähän toiminnallisuuteen liittyy myös asioita, jota ei käsitellä tällä kurssilla, kuten säikeistys. Meille riittää tieto, että uart_receive-funktio suoritetaan kun sarjaliikennedataa on saatavilla, ts. CPU:lle saapuu sarjaliikennekeskeytys.
Ajastimet¶
RTOS:n tarjoaa meille myös ajastimen
Clock
-kirjastossa, jolla voimme toteuttaa ajastettua tapahtumia. Esimerkiksi kerran sekunnissa kommunikoida oheislaitteen kanssa tai vilkuttaa lediä.Clock
-kirjaston esimerkki kertoo meille enemmän kuin tuhat sanaa....
#include <ti/sysbios/knl/Clock.h>
...
/ Kellokeskeytyksen käsittelijä
Void clkFxn(UArg arg0) {
sprintf(str,"System time: %.5fs\n", (double)Clock_getTicks() / 100000.0);
System_printf(str);
System_flush();
}
int main(void) {
// RTOS:n kellomuuttujat
Clock_Handle clkHandle;
Clock_Params clkParams;
Board_initGeneral();
// Alustetaan kello halutusti
Clock_Params_init(&clkParams);
clkParams.period = 1000000 / Clock_tickPeriod;
clkParams.startFlag = TRUE;
// Luodaan kello
clkHandle = Clock_create((Clock_FuncPtr)clkFxn, 1000000 / Clock_tickPeriod, &clkParams, NULL);
if (clkHandle == NULL) {
System_abort("Clock creat failed");
}
BIOS_start();
return(0);
}
Jälleen kerran meillä on käytössä tietorakenne, tässä
Clock_Params
. Sen jäseneen period
asetamme halutun ajan tikityksinä. Muistellaan aiempaa materiaalia, jossa kerrottiin että yksi tikitys vastaan meidän ajassa noin 10 mikrosekuntia. Asetamme periodiksi tässä 100000, eli sekunti. Tällä asetuksella saadaan aikaan ajastinkeskeytys NOIN yhden sekunnin välein. Tämä noin-epätarkkuus johtuu mm. siitä, että Clock-kirjaston kello on toteutettu ohjelmallisesti ja siten sen keskeytykset ovat ohjelmistokeskeytyksiä. Ajettuamme ohjelmaa näemme sen tulosteesta, että kellon laskenta heittelee muutamia kymmeniä mikrosekunteja suuntaan taikka toiseen, joka on riittävä tarkkuus meille (sovitaan nyt näin).
Rakenteen
startFlag
-jäsenellä voidaan asettaa kello käyntiin heti Clock_create
-kutsusta (startFlag=TRUE) tai erikseen käynnistettäväksi Clock_start
-kutsulla (startFlag=FALSE). Kello pysäytetään Clock_stop
-kutsulla. Näissä kutsuissa tarvitaan parametriksi kellon kahva, joten se on syytä esitellä globaalina muuttujana. Clock_create-kutsussa on myös meille uutta. Kutsun ensimmäinen parametri on meidän keskeytyksen käsittelyrutiini, eli tässä funktio
clkFxn
. Funktion ideana on osoittaa miten ohjelmistolla toteutettu kello toimii.Nyt muistetaan, että tulostus konsoli-ikkunaan, on hidas operaatio (CPU:n mielestä), joten tässä rikomme kirkkaasti sääntöä ettei keskeytyksen käsittelijarutiinin suoritusajan pitäisi olla kovin pitkä. Tulostusoperaatiot (varsinkin oheislaitteelle, kuten LCD-näyttö) ovat aivan liian hitaita ajettaviksi keskeytysrutiineissa! Oikeampi tapa tehdä sama asia olisi tallettaa kellonaika globaaliin muuttujaan ja luoda erikseen taski, joka tulostaa sen konsoli-ikkunaan / LCD-näytölle.
Clock_create-kutsun toinen parametri,
timeout
(tässä 1s), kertoo ajastimelle kuinka monta tikitystä se odottaa ennen keskeytyksen ensimmäistä laukaisua. Tässä ideana on, että voidaan myös toteuttaa ajastimia, jotka odottavat annettuun arvoon vain kerran ja laukaisevat sitten keskeytyksen. Näissä kelloissa Clock_params-rakenteen period-jäsen asetetaan nollaksi ja tähän timeout-argumenttiin tulee haluttu aika. Clock-kirjaston kaksi erityyppistä kelloa.
Kirjastolla voidaan luoda ohjelmaamme useita yhtäaikaisia kelloja, tarvitsee vain esitellä kahva per kello sekä asetusparametrit ja luoda kellot jokainen Clock_create-kutsulla.
Lisäksi, kirjasto esittelee meille jo tutun
Clock_tickPeriod
-muuttujan, joka kertoo kuinka monta mikrosekuntia yksi tikitys on. Clock_getTicks
-kutsulla saadaan selville ohjelman käynnistyksestä kulunut aika tikityksinä.Reaaliaikakello¶
RTOS tarjoaa myös reaaliaikakello-kirjaston
Seconds
, joka pyörii meidän ihmisten ajassa. Ainoa varjopuoli tässä on, että meidän pitää itse alustaa kello kääntämällä viisarit haluttuun aikaan, ennen sen käyttöönottoa. Luotamme jälleen esimerkin voimaan.
...
#include <ti/sysbios/hal/Seconds.h>
...
Void clkFxn(UArg arg0) {
time_t nyt = time(NULL);
struct tm *aika = localtime(&nyt);
System_printf("Kello on %02d:%02d:%02d\n", aika->tm_hour+3, aika->tm_min, aika->tm_sec);
System_flush();
}
Int main() {
...
// Asetetaan reaaliaikakellon aloitusaika
Seconds_set(1475578882); // Jännempi argumentti..
BIOS_Start();
return 0;
}
Huomataan ensin main-funktiossa kutsu
Seconds_set
, jolla kello asetetaan haluttuun aikaan. Nyt homma menee mielenkiintoiseksi (noo.. jonkun mielestä ihan varmasti!) Nimittäin, kellonaika annetaan Unix-aikana, eli kuluneina sekunteina sitten 1. tammikuuta 1970 00:00:00 UTC, joka ilmaistaan 32-bittisenä kokonaislukuna. Avuksemme netistä löytyy useita sivustoja, jotka tarjoavat tämän luvun meille, esimerkiksi Epoch converter (Kurssin henkilökunta ei ole missään kaupallisessa suhteessa mainittuun sivustoon). Josta selviää, että esimerkissä yllä käytetty luku 1475578882 vastaa kellonaikaa 4. lokakuuta 2016 11:01:22 GMT.
Nyt funktiossa clkFxn on myös uusia asioita, kun käytämme time.h-standardikirjastoa. Itseasiassa tässä RTOS tarjoaa oman time-standardikirjaston toteutuksen, joka alustuu sekin samalla Seconds_set()-kutsulla. Kirjasto tarjoaa käyttöömme funktion
time(NULL)
, jolla voimme kysyä kuluneen reaaliajan 32-bittisenä kokonaislukuna. Lisäksi time-kirjasto tarjoaa joukon funktioita, joilla tämä kokonaisluku voidaan muuntaa luettavampaan muotoon. Yllä käytämme localtime
-kutsua, jolla täytämme struct tm
-rakenteen, josta saamme irti mm. tunnit, minuutit ja sekunnit tulostusta varten. Huomatkaa osoitinesitys rakenteelle. Yllä joudumme vielä asettamaan aikavyöhykkeen varsin typerästi
tm_hour+3
, mutta tämä ratkaisu menettelee meille. Huom! Seconds-kirjasto ei ole käytettävissä CCS Cloud-ohjelmointiympäristön kautta, mutta voimme tehdä ihan vastaavan operaation Clock-kirjastolla.
Lopuksi¶
Sulautettuna laitteena SensorTag on varsin tehokas, ja RTOS abstrahoi meiltä monia asioita. Esimerkiksi Arduinoissa, tai laitteissa joissa ei ole käyttöjärjestelmää, sarjaliikenteen odottelu olisi katastrofaalisen hidasta laitteen toiminnan kannalta. Jos näissä laitteissa toteutetaan sarjaliikenne ilman keskeytystä, joudutaan kyselemään koodissa sarjaporttirekisteriltä tasaisin väliajoin, että onko uutta dataa. Tämä hidastaa muun ohjelman toimintaa, mutta Arduinoissa laitteen suunnittelun päämäärä onkin ollut helppokäyttöisyys.
Sulautetuissa laitteissa ajastettuja tapahtumia toteuttaa CPU:hun integroitu laskuripiiri (tuttu kurssilta Digitaalitekniikka I), joka laskee jokaisella systeemin kellonjaksolla yhden numeron eteenpäin, kunnes törmää ohjelmallisesti asetettuun maksimiarvoon ja aloittaa jälleen laskennan nollasta. Kaikki muut aika-arvot johdetaan sitten tästä, kun tiedetään systeemin kellotaajuus (megahertsejä).
RTOS abstrahoi tämänkin toiminnan ja (meidän tarpeisiin) keskeytysten käytön varsin yksinkertaiseksi käsittelijän kirjoittamiseksi funktiona. Emme edes välttämättä tiedä, toimiiko kirjasto keskeytyspohjaisesti vai onko kyseessä vain ohjelmafunktio. Tätä varten on syytä lukea kyseisen kirjaston dokumentaatiosta mistä on kyse. Muutoin saatamme tietämättämme toteuuttaa liian raskaan käsittelijän keskeytykselle.
Anna palautetta
Kommentteja materiaalista?