Tere, Habr!
Täna räägin teile sellisest huvitavast asjast nagu operatsioonisüsteem reaalajas (RTOS). Ma pole kindel, kas see on huvitav kogenud programmeerijatele, kuid arvan, et see meeldib algajatele.

Mis on RTOS?

Kui vaatame Vikipeediat, näeme koguni 4 definitsiooni.
Lühidalt öeldes on RTOS operatsioonisüsteem, mis reageerib välistele sündmustele teatud aja jooksul. Seega saame aru RTOS-i peamisest eesmärgist - seadmed, mille puhul on vajalik sündmustele kiire reageerimine (mitte mingil juhul ärge segage RTOS-i toimimist katkestustega).

Miks me seda vajame?

Sellel on üsna palju põhjuseid.
Esiteks toetab RTOS multitegumtöötlust, protsessiprioriteete, semafoore ja palju muud.
Teiseks on see väga kerge ega vaja peaaegu mingeid ressursse.
Kolmandaks saame kõike eelnevat saada peaaegu igale riistvarale (näiteks FreeRTOS töötab isegi 8-bitise AtMega peal).
Ja neljandaks: lihtsalt mängi ja lõbutse.

Ülevaade 3 tuntud RTOS-ist.

Tähelepanu: järgnev on minu isiklik arvamus.

FreeRTOS

Tänapäeval üks populaarsemaid RTOS-e. Ülekantud tohutule rauale. Ametlik sait.

plussid

1) Tasuta
2) teisaldatud suur hulk nääre
3) Võimas funktsionaalsus
4) Raamatukogusid on erinevaid: graafika, internet jm.
5) hea dokumentatsioon.

Miinused

1) Üsna keeruline uuele riistvarale teisaldamise protsess.

Järeldus: see on tõeliselt professionaalne RTOS, millel on hea dokumentatsioon. Algajale on hea, kui tema riistvaral on juba port.

KeilRTX

Kuni viimase ajani oli see RTOS kommerts, kuid hiljuti avati. Töötab ainult käearhitektuuriga. Ametlik sait.

plussid

1) Tasuta
2) Lihtsalt teisaldatav uuele riistvarale (käearhitektuuri piires).
3) Raamatukogusid on erinevaid: graafika, internet ja palju muud.

Miinused

1) Keiliga koos töötamine on peaaegu võimatu
2) Veidi eemaldatud funktsionaalsus
3) Toetatud on ainult käsi.
4) (sisse isiklik kogemus) Kaotab kiirust paljudele RTOS-dele.
Järeldus: ideaalne algajatele ja väikestele projektidele.

uc / os

Võimas kaubanduslik RTOS. Sait .

plussid

1) Suur hulk funktsioone ja teeke.
2) Toetab palju rauda

Miinused

1) Kaubanduslik.
2) Raske kasutada.

Järeldus: algajale on seda üsna raske nimetada RTOS -iks.

Muud huvitavad RTOS -id

RTLinux RTOS, mis põhineb tavalisel Linuxil.
QNX RTOS põhineb Unixil.

RTOS -i abil arendamise omadused

Kõigepealt peate mõistma järgmist: RTOS ei ole Windows. Seda ei saa paigaldada. See süsteem on lihtsalt koostatud teie programmiga.
RTOS -iga programme kirjutades ei kasutata funktsioone nende tavapärases tähenduses. Funktsioonide asemel kasutatakse protsesse (või ülesandeid). Erinevus seisneb selles, et protsessid, erinevalt funktsioonidest, on lõpmatud ahelad ja ei lõpe kunagi (kui keegi või ta ise teda ei tapa - see tähendab, et laadib ta mälust välja).
Kui mitu protsessi on lubatud, lülitab RTOS need ümber, kuvades omakorda masina aega ja ressursse. Siit tekib protsessi prioriteedi mõiste - kui kaks protsessi vajavad samaaegselt masinaaega, annab RTOS selle kõrgema prioriteediga protsessile.
RTOS -is on spetsiaalsed viivitusfunktsioonid - nii et ühe protsessi viivituse ajal aega ei raisata, käivitatakse teine.
Räägime nüüd sellisest asjast nagu semafor – see on selline asi, mis kontrollib protsessi juurdepääsu rakendusressurssidele. Iga ressursi jaoks on marker - kui protsess vajab ressurssi, võtab see selle ja kasutab seda ressurssi. Kui markerit pole, peab protsess ootama, kuni see tagastatakse. Toon näite: erinevad protsessid saadavad teavet ühe UART -i kohta. Kui ei olnud semafori, siis nad saadavad baite ükshaaval ja see oli jama. Ja nii võttis esimene protsess UART -i markeri, saatis sõnumi ja andis selle teisele (ja nii edasi - lõpmatuseni).

RTOS -i täiendavad raamatukogud.

RTOS pakub sageli erinevaid raamatukogusid töötamiseks, näiteks graafika, Interneti jms jaoks. Need on tõesti mugavad ja te ei tohiks kõhklemata neid kasutada. Kuid pidage meeles, et ilma RTOS-ita, mille jaoks need on kirjutatud, need ei tööta.
siin on mõned näidised:
RTX jaoks

Mis tuleb meelde, kui kuulete operatsioonisüsteemi? Kindlasti ventilatsiooniavad, Linux, Macos .. või midagi sellist. See on õige, ja kui küsitakse, miks seda vaja on, vastavad kõik enesekindlalt: kuulake muusikat, mängige (Internetis!), Sõbraga Skype'is rääkides. Samal ajal mõtiskledes, kuidas LED vilgub, olles saanud baidi uart =).

Ja kui süveneda, on muusika kuulamine, andmete saatmine Interneti kaudu kõik üksikud protsessid ja kuna meil on üks protsessor, saab see korraga täita ainult ühte ülesannet. Seetõttu täidetakse ülesandeid ükshaaval väikestes "portsjonites", OS -i põhiolemus on seda kasutaja jaoks märkamatult teha: nii et heli ei viliseks ja rattad läheksid käiku ja kõik töötaks korraga. Samas, kui üks ülesannetest "ripub", siis kõik muu toimis edasi.

Kui kõik lisakuklid ära visata ja sisuline olemus jätta, siis esiteks on OS lihtsalt taimer, mis arvestab võrdsete ajavahemike järel ning lülitub ka ilma kasutaja sekkumiseta ülesannete vahel, sooritab mingi osa ja lülitub uuesti. Samuti peate arvestama sellega, et enamikul ülesannetel ei pruugi olla aega ühe viiluna lõpetamiseks, seega peate salvestama ülesande oleku teisele ülemineku ajal ja järgmisel korral taastama muutujad. Kõike seda haldab ülesannete planeerija.

Operatsioonisüsteeme on kahte peamist tüüpi: ennetav ja ühistuv. Esimesel juhul on ülesannete vahetamine "raske", st. kui ajaviil on 1ms, siis esmalt täidetakse esimene ülesanne täpselt 1ms, siis teine ​​täpselt 1ms jne. Selliseid telgi nimetatakse reaalajaks (RTOS). Ühistulised on veidi lihtsamad, protsess ise peab ütlema, et “olen täitnud”, seetõttu ei saa neid RTOS-ile omistada.

See ei tööta põhjusel, et eelisvõimalusi väikestele AVR -idele lükata väike kogus RAM. Ühistutele saadaolevatest valikutest meeldis mulle mRTOS, selle süsteemi üksikasju saate lugeda autori veebisaidilt (lihtsalt googeldades). peamine põhjus selle kasutamine - lihtsus, CAVR -i jaoks valmisversiooni kättesaadavus, mõistmiseks üldised põhimõtted iseasi.

Seega jäävad põhiküsimused, miks ja millal telge kasutada. Teoorias on kõik sama, mida teljega teed, saab ka ilma, sest ressursid on samad. Alates sellest, et kohandate selle projektiga, megahertsid ei lenda kosmosesse, raud jääb samaks, järelikult on ka ressursid samad.

Seega tasub endalt küsida paar küsimust:
1. Kas saate oma ressursse targalt hallata?
2. Kas püsivara kirjutamise ajal ei peaks plaanijaga sarnaselt leiutama sama jalgratast?
3. Kui loetav on teie kood? Kas saate selle kuue kuu või aasta pärast avada ja kohe aru saada?
4. Kas kirjutad üksi või rühmas?

Esimesele küsimusele on raske vastata, sest kõik sõltub arendaja kõverusest. Teise puhul on üha enam selge, kui iseseisvaid ülesandeid on palju ja neid on plaanis korrapäraste ajavahemike järel täita, siis on parem vaadata OS -i poole. Kolmanda puhul on samuti selge, et eraldi ülesandest on palju lihtsam aru saada kui sõltuvuste valimine põhiahelas. Kui te ei kirjuta üksi, siis on siin ka eeliseid, sest igaüks saab oma probleemi eraldi kirjutada, ülejäänud sekkumata.

Ülaltoodut kombineerides on rakendusala teatud ülesannete jaoks üsna spetsiifiline. Te ei tohiks seda igasse projekti toppida. Enamiku amatöörraadio käsitöö jaoks on telg ülearune, kuid omades sellest ettekujutust, oleksin selle ilmselt paaris projektis sisse lükanud.

Nüüd vaatame kapoti alla. MRTOS -i käivitamiseks peate mrtos.c projektiga ühendama ja lisama mrtos.h. Koodi struktuur on tavapärasest veidi erinev

#kaasa #include "mrtos.h" // siin on funktsiooni keha, kuhu me kirjutame oma superkoodi tühi ülesanne1 () (samas (1) // ülesanded mis tahes OS-is on üles ehitatud lõpmatu tsükli alusel { // siin on teie ülesande kood LÄHETAMINE; // funktsioon ajakavale juhtimise ülekandmiseks } ; } // taimerkatkestuste käitleja 0 katkestus [TIM0_OVF] void timer0_ovf_isr (void) (char ii; #asm ("cli") TCNT0 = 0x9C; inc_systime (); for (ii = 0; ii< init_tasks; ii++ ) if (tasks[ ii] .delay ) -- tasks[ ii] .delay ; #asm("sei") } void main(void ) { // välisseadmete lähtestamine Init_mRTOS (); // initsialiseerida os // siin loome ülesandeid (ülesandeid) Siin on loodud 3 ülesannet create_task (ülesanne1, 1, aktiivne); // ülesande loomine (ülesande nimi, prioriteet, olek) create_task (ülesanne2, 1, aktiivne); loo_ülesanne (ülesanne3, 1, Aktiivne); Sheduler (); // käivita ajakava samas (1); )

#kaasake #include "mrtos.h" // siin on funktsiooni põhiosa, kuhu kirjutame oma superkoodi void task1 () (samas kui (1) // mis tahes OS-i ülesanded on üles ehitatud lõpmatu tsükli alusel (// siin on teie ülesande kood DISPATCH; // funktsiooni juhtimise ülekandmine planeerijale);) // taimer 0 katkestuse töötleja katkestus void timer0_ovf_isr (void) (char ii; #asm ("cli") TCNT0 = 0x9C; inc_systime (); jaoks (ii = 0; ii

Nüüd täpsemalt. ülesannete arvu märgib mrtos.h failis APPTASKS N. Ülesanne on deklareeritud ülesande1 () (), ülesande2 () () jms sees, samas kui (1) ei pea te midagi kirjutama, pole vaja ka funktsioone kutsuda; teie planeerija. Nagu näete, koosneb ülesanne lõpmatust tsüklist, see on normaalne ja peaks olema, kuid ülesande sees on hädavajalik anda juhtimine planeerijale. Kas funktsioon WAIT või DISPATCH. Kui seda ei tehta, töötab ülesanne lõputult.

Kuidas see töötab? Loome LED -i vilkuva ülesande.

tühi ülesanne1 () (samas (1) (PORTB.0 =! PORTB.0; OOTA (100););)

tühine ülesanne1 () (samas (1) (PORTB.0 =! PORTB.0; OOTA (100););)

WAIT on ainult viivituse () analoog, viivituse ajal ei tee mikrokontroller midagi ja käivitab tühjad tsüklid. OOTAMISE ajal antakse juhtimine üle teistele ülesannetele. Need. saate luua hulga ülesandeid, vilkudes erinevaid LED -e, erinevate ootustega, ja need kõik vilguvad erineva sagedusega. Kui viivitusi pole vaja, kasutatakse lõpus DISPATCH.

OOTAMISE kasutamisel on oluline mõista, et kogu süsteemil on minimaalne linnuke (ajaviil), seega ei oota me ootamist (50) 50 millisekundit, vaid 50 süsteemipunkti. Puugiseade sõltub sellest, kui tihti Timer0 katkestusi kutsutakse, s.t. kui seame katkestuse pikkuseks 1 ms, siis võime eeldada, et meie tegevus sooritatakse 1 ms jooksul. Katsed on näidanud, et 16 MHz taktsagedusega on võimalik süsteemi tiksumist vähendada ~ 20 μs-ni.

Taimeri seadistus ei erine varem uuritust, kuna taimeril 0 on ainult ülevoolu katkestus, siis on kõik seaded sellega seotud. CAVR-i viimastes versioonides on ajanõudeid väga mugav kirjutada, seaded genereeritakse automaatselt.

loo_ülesanne (ülesanne1, 1, Aktiivne);

loo_ülesanne (ülesanne1,1, Aktiivne);

Prioriteetidega on see ikka päris keeruline. Kui on kaks erineva prioriteediga ülesannet ja pidevalt täidetakse kõrge prioriteediga ülesannet, siis me ei astu kunagi madala prioriteediga ülesannet. Seetõttu peate töö korraldama nii, et kõigile ülesannetele oleks juurdepääs. Me ei keskendu sellele, jätame selle järgmiseks korraks. Ülesande olek, Aktiivne – käivitatud, peatatud StopTask.

Niisiis, neile, kes soovivad LED -i lihtsalt vilkuda:

#kaasa #include "mRTOS.h" void task1 () (while (1) (WAIT (1000); PORTB.0 =! PORTB.0;)) // Taimer 0 ülevoolu katkestusteenuse rutiin katkestus [TIM0_OVF] void timer0_ovf_isr (tühine) (char ii; #asm ("cli") TCNT0 = 0xb2; inc_systime (); jaoks (ii = 0; ii< init_tasks; ii++ ) if (tasks[ ii] .delay ) -- tasks[ ii] .delay ; #asm("sei") } void main(void ) { DDRB= (1 << DDB7) | (1 << DDB6) | (1 << DDB5) | (1 << DDB4) | (1 << DDB3) | (1 << DDB2) | (1 << DDB1) | (1 << DDB0) ; PORTB= (0 << PORTB7) | (0 << PORTB6) | (0 << PORTB5) | (0 << PORTB4) | (0 << PORTB3) | (0 << PORTB2) | (0 << PORTB1) | (0 << PORTB0) ; // Taimer / loendur 0 lähtestamine// Kella allikas: süsteemikell // Kella väärtus: 7,813 kHz TCCR0 = (0<< CS02) | (1 << CS01) | (1 << CS00) ; TCNT0= 0x83 ; // Taimer (id) / Loendur (id) Katkestuse (de) initsialiseerimine TIMSK = (0<< OCIE2) | (0 << TOIE2) | (0 << TICIE1) | (0 << OCIE1A) | (0 << OCIE1B) | (0 << TOIE1) | (1 << TOIE0) ; Init_mRTOS() ; create_task(task1, 1 , Active) ; Sheduler() ; while (1 ) ; }

#kaasake #include "mRTOS.h" void task1 () (while (1) (WAIT (1000); PORTB.0 =! PORTB.0;)) // Taimer 0 overflow interrupt service rutiinne katkestus void timer0_ovf_isr (void) (char ii) ; #asm ("cli") TCNT0 = 0xb2; inc_systime (); jaoks (ii = 0; ii

Boonusena proovisin teha polüfoonilist (kahehäälset) meloodiat "Dr Mario chill". Idee on selles, et kontrolleri iga jalg pööratakse pidevalt ülesande täitmisel ümber, tekitades sellega sageduse. Viivitust muutes saate muuta noodi helikõrgust.

void task2 (void) (while (1) (if (mute == 0) // kui mängida lubatakse(kui (note_ch2 [n_n] == 0) // kui on paus, siis oota, ei mängi midagi(PORTB.4 = 0; OOTA (5);) else (PORTB.4 =! PORTB.4; // kui mitte pausi, siis tõmmake jalga soovitud sagedusega OOTA (note_ch2 [n_n]); ))))

void task2 (void) (while (1) (if (mute == 0) // kui on lubatud mängida (if (note_ch2 == 0) // kui on paus, siis ootame, me ei mängi midagi (PORTB.4 = 0; OOTA (5);) muud (PORTB.4 =! PORTB.4; // kui mitte paus, siis lüüa vajaliku sagedusega OOTA (märkus_ch2);))))

Ma ei vaevunud ideega, 1 ülesandes genereeritakse soolopartii jaoks noodisagedusega meander, teises bassi jaoks. Iga noodi helikõrgus võetakse massiividest. Kestus, vahetamine ja lõpetamine 3. ülesandes.

void task3 (void) (while (1) (OOTA (1500); // mängida minimaalset noodi kestust jaoks (vaigista = 0; vaigista< 500 ; mute++ ) // katkestage noot, et need ei ühineks(PORTB.3 = 0; PORTB.4 = 0;); vaigistada = 0; // määrake lipp, millega saate heli esitada n_n ++; // mine järgmisele märkmele kui (n_n == n_max) // kui mängisime kõike siis ringiga(n_n = 0;)))

tühine ülesanne3 (tühine) (samas (1) (OOTA (1500); // mängida minimaalset noodi kestust (mute = 0; mute)< 500; mute++) //обрываем ноту, чтобы не сливались { PORTB.3 = 0; PORTB.4 = 0; }; mute = 0; //выставляем флаг, что можно воспроизводить звук n_n++; //переходим на следующую ноту if(n_n == n_max) //если сыграли все то идем по кругу { n_n = 0; } } }

Kahe kanali segamiseks kasutasin lihtsat skeemi.

Kokku väike tükk

Neile, kes soovivad püsivara

Arendasin veidi üle 10 elektroonikaseadme ja loobusin täielikult nende madalatasemelisest toimimisest ilma operatsioonisüsteemita. Olukord muutus, kui järgmise seadme funktsionaalsus laienes järsult. Lisaks on vaja ülesannet, mis kutsutakse välja kindlate ajavahemike järel ning kõne täpsus mõjutab tulemust. Samuti selgus, et kogu tarkvara ei jõua ettenähtud aja jooksul kirjutada ning see luuakse hiljem. Pärast mõningast mõtlemist sain aru, et projekt peab sisaldama reaalajas operatsioonisüsteemi (RTOS või RTOS).

Erinevalt arvutist, kus OS on pigem kiht süsteemiressurssidega töötamiseks, on RTOS-i mikrokontrolleri jaoks see eelkõige tegumiplaneerija, tegelikult mängib see peamist rolli "reaalajas". Hetkel on minu jaoks oluline pakkuda nn pseudoparalleelset ülesande täitmist. See tähendab, et sama prioriteediga on mitu ülesannet ja on oluline helistada neile määratud järjekorras määratud ajavahemike järel.

Selge on järgmine näide: Eurobot 2011 projektis oli süsteemis 18 välisseadet. 2 elektroonilist tahvlit võiks funktsionaalsuse mõttes ühendada üheks. Nende maksumus väheneks, töökindlus suureneks (süsteemi komponentide arv väheneks) ja vaba ruumi hulk korpuses suureneks. Asjaolu muudab keeruliseks asjaolu, et ülesannete arv kasvab proportsionaalselt ja siin ei saa te ilma OS-ita hakkama. RTOS aitab vältida ka protsessori võimalikke seisakuid, näiteks ADC teisendamise ajal saate selle ülesande blokeerida ja teisi täita, jaotades seeläbi seadme töö õigesti. Samuti on oluline, et nüüd ei kukuks seade ülesande rikke tõttu alla, selle asemel on võimalik säilitada osaline töövõime (kuigi see võib kaasa tuua ettearvamatuid tulemusi). Kuidas tagame nende näitajate kasvu? Tegelikult pigistame MK -lt välja kõik võimaliku, kasutades tõhusalt selle arvutusvõimalusi.

Pärast lühikest otsimist langes valik freeRTOS -ile. See RTOS on levitatud C -allikas ja teisaldatud 27 arhitektuurile. Viimane asjaolu on minu jaoks määrav. See vähendab tööjõukulusid teiste tootjate MCU -dega töötamisel. Nüüd huvitab mind rohkem AVR -i port.

RTOS freeRTOS olemasolu projektis sööb umbes 9,8 KB programmimälu ja 1,8 KB RAM-i. Näiteks ATmega32 ja WinAVR kompilaatori puhul on see vastavalt 60% ja 85%. Juba selle mudeli jaoks on raske luua suurepärase funktsionaalsusega seadet - mälu ei jätku. Kuid see probleem kaob uute AVR-mudelitega. See on 256 KB programmimälu ja 8 KB muutmäluga Mega2560 puhul täiesti ebaoluline. Tulevaste MC -de suundumus saadab ainult RTOS -i edu.

Runeti läbi lugenud avastasin üllatusega, et OS -i dokumentatsioon vene keeles puudub. Mis see on! Originaaldokumentatsiooni levitatakse lisatasu eest. Olukorda lihtsustas Andrey Kurnitsa artikkel ( [e-postiga kaitstud]) ajakirjast "Komponendid ja tehnoloogiad". Autori nõusolekul kasutan artikli materjale muudetud versioonis. Tema artikkel võib hästi toimida venekeelse dokumentatsioonina. Kuid originaal pole trükitud kujul saadaval, ajakirja sait valetab, nii et materjali tuleb veidi ümber töötada. Üldiselt tegi autor suurepärase artikli ja pole mõtet teooriat uuesti üle käia, see avaldatakse siin täismahus. Originaalartikkel lisatakse väljaande lõppu. Samuti märkasin, et kasutajatel oli raskusi RTOS-i koostamisega. See on tingitud asjaolust, et kasutatakse välist makefile, mis sisaldab kaustade teed. Seetõttu lisan valmis projekti mallina AVR Studio ja AVR Eclipse jaoks. Kahjuks native makefile ei väljasta silumisinfot nagu RAM ja programmi mälukasutus, see tuli parandada vastava standardkõne lisamisega.

Niisiis, lühidalt vajadusest, on soovitatav oma projektis vajadusel kasutada RTOS-i:

Korraldage multitegumtööd ja vaheldumisi ülesandeid

Veenduge, et ülesanne algab rangelt määratletud ajavahemike järel

Teabe edastamine ühest ülesandest teise

Lisage vajadusel uusi ülesandeid

RTOS -i eelised M ees SAADA:

1. Multitegumtöötlus. RTOS pakub programmeerijale valmis silutud multitegumtöötlusmehhanismi. Lihtsal juhul saab iga ülesande programmeerida eraldi, kogu töö saab jagada mitme meeskonnaliikme vahel. Te ei pea muretsema ülesannete vahel vahetamise pärast, seda teeb ajakava.
2. Aja baas. Tuleb mõõta ajavahemikke. RTOS -il peab see tööriist olema. See võimaldab teil teha toiminguid rangelt määratud ajavahemike järel.
3. Andmevahetus ülesannete vahel. Selleks kasutab RTOS järjekorda.
4. Sünkroonimine. Kui erinevad ülesanded kasutavad sama ressurssi, näiteks jadaporti, saab kasutada mutekse ja kriitilisi sektsioone. Kui teil on vaja ülesandeid täita ranges järjestuses või kui toimub konkreetne sündmus, saate ülesannete sünkroonimiseks kasutada semafoore või signaale.

RTOS -i puudused:

1. Kerneli rakendamiseks vajaliku programmimälu järsk kasv

2. Vajaliku RAM-i suurendamine iga ülesande virna, semaforide, järjekordade, mutexide ja muude süsteemituuma objektide salvestamiseks.

3. Konteksti salvestamiseks viivitatakse ülesannete vahetamisel.

KirjeldusfreeRTOS:

FreeRTOS on tasuta avatud lähtekoodiga kõva reaalajas OS. Enamasti kirjutatud C -keeles, kuid monteerija lisad on olemas. Selle töötas välja Real Time Engineers ltd spetsiaalselt manussüsteemide jaoks. Hiljuti on hakatud välja töötama projekti SafeRTOS – FreeRTOS-i muudetud, dokumenteeritud, testitud ja sertifitseeritud versiooni, mis vastab ohutusstandardile IEC 61508. Selle projekti viis läbi Saksa ettevõte ja nüüd kasutatakse safeRTOS-i kosmosetööstuses ja meditsiinitehnoloogias. Samuti on olemas projekt openRTOS - kaubanduslik versioon, millel on tootja garantii.

FreeRTOS-i peamised omadused:

1. Planeerija toetab kolme tüüpi multitegumtöötlust:

Väljatõrjumine

Ühistu

Hübriid

2. Tuuma suurus on 9,8 KB, mis on koostatud AVR -i jaoks. (WINAVR)

3. Kerneli alus – 4 faili C-vormingus.

4. Toetab ülesandeid ja korrutine. Coroutines on spetsiaalselt loodud väikese RAM -iga MCU -de jaoks.

5. Rikkalikud jälgimisvõimalused.

6. On võimalik jälgida virna ületäitumist.

7. Samaaegselt täidetavate ülesannete arvule pole tarkvarapiiranguid.

8. Ülesannete prioriteetide arv ei ole piiratud.

9. Mitmele ülesandele saab määrata sama prioriteedi

10. Täiustatud sünkroonimisvahendid "task-task" ja "task-interrupt":

Järjekorrad

Binaarsed semafoorid

Semafooride lugemine

Rekursiivsed semafoorid

Muteksid

11. Prioriteediga pärilikud mutexid.

12. Cortex-M3 mälukaitsemooduli tugi

13. Tarnitakse silumisel erinevate platvormide ja kompilaatorite demoprojektidega.

14. Tasuta. Laiendatud GPL-litsentsi alusel saab kasutada projektides ilma lähtekoodi avaldamata.

15. Dokumentatsioon on tasuline, kuid kättesaadav veebis siin.

16. AVR -i kontekstivahetusaeg koos kvartsiga sagedusel 16 MHz on ainult 20,8 µs. Täpselt nii palju kulub andmete salvestamiseks ülesannete virnasse ja järgmisele helistamiseks. (Huvitav märkus, kui võrrelda seda PIC18xxx-ga, siis AVR-kontroller muudab selle 4 korda kiiremaks, tõenäoliselt on see tingitud kompilaatori kvaliteedist)

Ennetav multitegumtöötlus tähendab, et madala prioriteediga jooksev ülesanne kattub kõrgema prioriteediga lõpetatud ülesandega. Ülesannete vahel vahetamine toimub võrdsete ajaviiludena. Seetõttu peab enne kõrge prioriteediga ülesande täitmise alustamist olema praegune ajaviil madala prioriteediga ülesande täitmisel möödas.

Seega on FreeRTOS -i reaktsiooniaeg välistele sündmustele eelseisvas multitegumtöötlusrežiimis mitte rohkem kui üks ajakava ajaviil, mida saab seadetes määrata. Vaikimisi on see 1 ms.

Kui mitu sama prioriteediga ülesannet on täitmiseks valmis, eraldab ajakava igale neist ühe ajaviilu, mille järel võtab järgmise sama prioriteediga ülesanne juhtimise vastu jne.

Ühistuline multitegumtöötlus erineb ennetavast multitegumtööst selle poolest, et ajakava ise ei saa katkestada praeguse, isegi kõrge prioriteediga ülesande täitmist. Iga ülesanne peab iseseisvalt juhtimise planeerijale üle andma. Seega jääb kõrge prioriteediga ülesanne ootama, kuni madala prioriteediga ülesanne lõpetab oma töö ja tagastab juhtimise planeerijale. Süsteemi reageerimisaeg välisele sündmusele muutub määramata ja sõltub sellest, kui kaua praegune ülesanne täidetakse enne juhtimise üleandmist. Ühistulist multitegumtöötlust kasutati operatsioonisüsteemide perekonnas Windows 3.x.

Ennetavad ja koostöös toimivad multitegumtöötluse kontseptsioonid koonduvad hübriidseks multitegumtöötluseks, kus ajakava kutsutakse iga kord, kuid erinevalt ennetavast multitegumtööst on programmeerijal võimalus seda teha sunniviisiliselt. See režiim on eriti kasulik, kui on vaja lühendada süsteemi reageerimisaega katkestusele. Oletame, et praegu täidetakse madala prioriteediga ülesannet ja kõrge prioriteediga ülesanne ootab mõningast katkestust. Siis tekib katkestus, kuid katkestuste käitleja lõpus naaseb täitmine praeguse madala prioriteediga ülesande juurde ja kõrge prioriteediga ootab praeguse ajaviilu lõppu. Kui aga pärast katkestuste käitleja täitmist antakse juhtimine ajakavale üle, siis kannab see juhtimise üle kõrge prioriteediga ülesandele, mis vähendab välise sündmusega seotud süsteemi reageerimisaega.

Mikspealvestlusb?

Saate alustada FreeRTOS -i käivitava mikrokontrolleri arendamist, laadides alla selle uusima versiooni.

FreeRTOS-i jaotus on saadaval tavalise või iseenesest eralduva ZIP-arhiivina. Distribution Sisaldab otse tuumakoodi (mitme päisefaili ja lähtekoodiga faili kujul) ja demoprojekte (iga projekti jaoks iga arenduskeskkonna jaoks üks projekt). Järgmisena peaksite arhiivi lahti pakkima arendusjaama mis tahes sobivasse kohta.

Vaatamata suurele hulgale failidele arhiivis on kataloogistruktuur tegelikult lihtne. Kui kavatsete projekteerida seadmeid 2-3 arhitektuurile 1-2 arenduskeskkonnas, siis enamikku demoprojektide ja erinevate arenduskeskkondadega seotud failidest pole vaja.

Üksikasjalik kataloogi struktuur on näidatud diagrammil.

Kogu kerneli allikas asub kataloogis / Source.

Sisu:

1.ülesanded.c- ülesannete mehhanismi rakendamine, ajakava

2. järjekord.c- järjekordade rakendamine

3. nimekiri.c- planeerija sisemised vajadused, kuid funktsioone saab kasutada ka rakendusprogrammides.

4. krutiin.c- korutiinide rakendamine (võib puududa, kui korutiine ei kasutata).

Päisefailid, mis asuvad kataloogis allikas/kaasa

1.ülesanded.h, järjekord.h, tist.h, croutine.h- päisefailid vastavalt sama nimega failidele koos koodiga.

2. FreeRTOS.h-sisaldab kompileerimise seadistamiseks eeltöötlejaid.

3.mpu_wrappers.h- sisaldab FreeRTOS programmeerimisliidese (API) funktsioonide alistusi mälukaitsemooduli (MPU) toetamiseks.

4. kaasaskantav.h-platvormist sõltuvad seaded.

5.projdefs.h-mõned süsteemimääratlused

6.semphr.h- defineerib API funktsioonid semaforidega töötamiseks, mida realiseeritakse järjekordade alusel.

7. StackMacros.h- sisaldab makrosid virna ületäitumise kontrollimiseks. Iga riistvaraplatvorm nõuab väikest tuumakoodi, mis rakendab FreeRTOSe koostalitlusvõimet selle platvormiga. Kogu platvormipõhine kood on alamkataloogis / Allikas / Kaasaskantav, kus see on kategoriseeritud arenduskeskkondade (IAR, GCC jne) ja riistvaraplatvormide järgi (näiteks AtmelSAM7S64, MSP430F449). Näiteks alamkataloog / Allikas / Kaasaskantav / GCC / ATMega323 sisaldab faile port.c ja portmacro.h, mis rakendavad ülesande konteksti salvestamist / taastamist, taimeri initsialiseerimist ajabaasi loomiseks, iga ülesande virna ja muude riistvaraliste funktsioonide lähtestamist mega AVR perekonna ja WinAVR kompilaator (GCC).

Eraldi peaksite esile tõstma alamkataloogi / Allikas / Kaasaskantav / MemMang mis sisaldab faile hunnik_l.c, hunnik_2.c, hunnik_3.c mis rakendavad 3 erinevat mehhanismi mälu eraldamiseks FreeRTOSe vajadustele, mida kirjeldatakse hiljem üksikasjalikult.

Kataloog / Demo sisaldab demoprojekte kompileerimiseks ja ehitamiseks valmis. Kõigi demoprojektide koodi ühisosa on alamkataloogis esile tõstetud / Demo / Commo n.

FreeRTOS-i kasutamiseks oma projektis peate kaasama kerneli lähtefailid ja nendega seotud päisefailid. Neid pole vaja muuta ega nende rakendamisest aru saada.

Näiteks kui kavatsete kasutada MSP430 mikrokontrollerite ja GCC kompilaatori porti, siis projekti nullist loomiseks vajate alamkatalooge / Allikas / Kaasaskantav / GCC / MSP430_GCC ja / Allikas / Kaasaskantav / MemMang... Kõik muud alamkataloogid kataloogist / Source / Portable on mittevajalikud ja neid saab eemaldada.

Kui kavatsete olemasolevat demoprojekti muuta (mida tegelikult soovitatakse teha FreeRTOS -uuringu alguses), vajate ka alamkatalooge / Demo / msp430_GCC ja / Demo / Ühine... Ülejäänud / Demo alamkataloogid on mittevajalikud ja neid saab eemaldada.

Rakenduse loomisel on soovitatav kasutada makefile(või arenduskeskkonna projektifail) lähtepunktina vastavast demoprojektist. Soovitav on ehitamisest (ehitamisest) failid kataloogist / Demo välja jätta, asendades need enda omadega ja failid kataloogist / Source - terved. Samuti tuleks mainida päisefaili FreeRTOSConfig.h mis on igas demoprojektis. FreeRTOSConfig.h sisaldab definitsioone (#define), mis võimaldavad konfigureerida FreeRTOS-i tuuma:

1. Süsteemi funktsioonide komplekt.

2. Korutiinide kasutamine.

3. Ülesannete prioriteetide arv ja juhised

4. Mälu suurused (stack ja hunnik).

5. MK kella sagedus.

6. Igale täitmisülesandele eraldatud ajaplaneerija periood, mis on tavaliselt 1 ms. Keelake mõned süsteemi funktsioonid ja vähendage prioriteetide arvu (vähendab mälutarbimist).

FreeRTOS -i jaotus sisaldab ka tööriistu, mille abil teisendada planeerijalt saadud jäljeinfo tekstivormiks (kataloogiks) / TgaseCon) ja litsentsi tekst (kataloog / Litsents).

järeldused

Sarja esimese artikli abil tutvus lugeja FreeRTOS mikrokontrollerite operatsioonisüsteemiga. Näidatud on töö omadused. Kirjeldage FreeRTOSi levitamise sisu. Siin on toodud põhilised sammud FreeRTOS-i kasutava seadme arendamise alustamiseks.

Tulevastes väljaannetes pööratakse tähelepanu multitegumtöötluse mehhanismile, nimelt ülesannetele ja korutiinidele. Planeerija näidet näidatakse Atmel AVR mikrokontrollerite ja WinAVR kompilaatori (GCC) näitel.

Ma esitan seda küsimust pidevalt, tegeledes oma hobiga - kodu automaatse juhtimissüsteemi (nutikodu) väljatöötamisega, mis põhineb 16 -bitisel mikrokontrolleril - kas see on tõesti õige lähenemine? Poolteist kuud tagasi kirjutasin juba oma blogis teemal "Mikrokontrollerid versus süsteemid kiibil". Niisiis, ma kirjutan sellest uuesti.

Osaliselt ajendas mind Stellaris Launchpadi ja Arduino Due väljaandmine. Mõlemad põhinevad 32-bitistel mikrokontrolleritel ja on mitmes mõttes väga sarnased. Olen mõlema andmelehte uurinud ja kuigi need erinevad hinnalt korralikult, on need mõeldud samale sihtrühmale. Mõtlesin, et äkki peaks üle minema MSP430 pealt Stellarisele või ehk isegi põhimõtteliselt teistsugusele süsteemile, kasutama mikrokontrollerite asemel midagi Raspberry Pi sarnast.

Nii Stellaris Launchpad kui ka Arduino Due on väga võimsad, kuid pole mõeldud Linuxi käitamiseks. Need töötavad kas otse nende jaoks kirjutatud käivitataval koodil või reaalajas opsüsteemi (RTOS)-minimalistliku operatsioonisüsteemi-kontrolli all, millel on väga lühike reageerimisaeg välistele sündmustele. Mõlemad on oluliselt keerukamad kui MSP430 või 8-bitised AVR-id.

Teisest küljest kasutavad päriselus (väljaspool internetti) enamik minu tuttavaid inimesi Raspberry Pi või muid manustatud Linuxi süsteeme. Mikrokontrollerite kasutamine on üsna haruldane juhtum nende seas, kellega olen kohtunud. Isegi Arduino on minu keskkonnas palju vähem populaarne kui sisseehitatud Linux. Nagu ma aru saan, miks peaks keegi ostma Arduino, kui saate Raspberry Pi, mis suudab palju rohkem, kuid maksab sama või vähem? Linuxi jaoks on tohutul hulgal valmis tarkvara ja sellel saate programmeerida lihtsate skriptikeelte abil.

Minu jaoks isiklikult ei taha ma Linuxit kasutada, sest kasutan seda iga päev tööl ja koju jõudes ei ole mul rõõmu, et pean uuesti töötama Linuxisarnaste süsteemidega. Mul pole Linuxi kasutamisel probleeme, kuid seda on igal pool liiga palju, see kaalub mind. Minu jaoks on palju huvitavam töötada lihtsate elektroonikaseadmetega 8/16-bitistel mikrokiipidel.

Siiski ei pööra ma tegelikkusele selga. Kui ma tahan reaalse maailmaga kooskõlas olla, pean kasutama reaalses maailmas kasutatavaid tööriistu. Muidu on nagu tahtmine aurumasinaga autoga sõita, lihtsalt sellepärast, et sisepõlemismootor on liiga igapäevane, seega kasutan seda kogu aeg. Kui maailm meie ümber läheb üle arenenumale tehnoloogiale, on vaja seda hallata, meeldib see mulle või mitte. Eriti kui ma tahan, et mu blogi oleks inimestele huvitav ja jääks asjakohaseks.

Oma nutikodu projektis puutusin tegelikult selle probleemiga kokku. Olen juba teinud MSP430 juhtsüsteemile LAN draiveri ja kõik näeb väga korralik välja. Põhimõtteliselt saan teha kõike, mida MSP430 automatiseerimissüsteemi jaoks vaja on. Siiski mõtlen, kas see, kuidas ma seda teen, on õige? Kas ma üritan kahvliga suppi süüa, kui lusikas on olemas? Võib-olla on Linux parem süsteem? Las ma seletan.

Kui peatute ja vaatate praegust olukorda 2012. aasta novembri tehnoloogilise arengu osas. Küsin endalt, kas mikrokontrollerid on piisavalt head ja asjakohased võrreldes Linuxi kasutavate kiibisüsteemidega?

Kui loetleda manustatud süsteemide projektid, mis mulle meelde tulevad, on need: droonid, robotid, koduautomaatika, mootorikontrollerid, andurid, käekellad, 3D-printerid jne. Millistel neist juhtudest on manustatud Linux sobivam kui mikrokontrollerid? Ja miks?

Arvan, et mikrokontrolleri parim valik on kolm olukorda: kus oluline on kiire (reaalajas) reageerimine sündmustele; kus on vaja äärmiselt madalat energiatarbimist; ja kus peate kasutama võimalikult väikese hinnaga kiipe.

Alustuseks pole odavate mikrolülituste kasutamine minu jaoks nii oluline. Tegelen oma hobiga iseendale ega kavatse kunagi konkurentsivõimelisi tooteid välja anda. Ma ei pea mõtlema tootmise viimisele orjatööstusettevõttesse, et saada oma arendatavate väikeste projektide jaoks konkurentsivõimelist hinda. Oleksin õnnelik, kui saaksin tänu oma võimetele joota rohkem kui ühe tahvli päevas!

Näiteks targa kodu projekti jaoks saan disainida kaugjuhitava lüliti. See võib sisse / välja lülitada tuled või midagi muud. Samal ajal võin minna oma kohalikku elektripoodi ja osta 20 dollari eest sama, mis on valmistatud Hiinas. Kas ma alistan kunagi selle hinna, üritades oma lülitit müüa? Ma ei usu, et see on võimalik.

Kui järele mõelda, kehtib see ka paljude muude koduautomaatika jaoks vajalike asjade kohta. Temperatuuri-, suitsu-, liikumisandurid jne, olen üsna võimeline ise sama tegema, kuid rahalist kasu sellest tõenäoliselt ei saa. Keda huvitab minult selliseid asju 75 dollari eest osta, kui nad leiavad need 20 dollari eest majapidamistoodetest?

Kui mõtlete oma hobist kasu saada, siis on parem pöörata tähelepanu kallimatele ja keerukamatele toodetele. Näiteks koduautomaatika kontroller või termostaat maksab tavaliselt rohkem kui 100 dollarit ja jätab individuaalsele loovusele rohkem vabadust, saate selle ehitada, naabritele müüa ja isegi raha teenida.

Kuid soov saada lõppseadme eest paremat hinda ei tähenda, et peate kasutama maakera odavaimat mikrokontrollerit. Tegelikult on see halb mõte, sest arendusaeg maksab sama palju kui kasutatud osad. Mikrokontroller võib küll olla odav, kuid juhtkoodi kirjutamine võtab rohkem aega. Aeg on raha ja kui töötate kiiremini, saate rohkem saavutada.

Kõik need mõtisklused viivad mind järeldusele, et nutika kodu süsteem on kasulikum arendada Linuxis kui mikrokontrolleritel, vaatamata minu isiklikele eelistustele, Linuxit mitte kasutada (mulle meeldib madalatasemeline programmeerimine rohkem kui skriptid, Linuxiga ajab igav) .

Teema teema juurde tagasi tulles võib öelda, et mikrokontrollerite hind võib olla oluline tegur suurkorporatsioonide jaoks, kes hakkavad uut toodet välja laskma, kuid üksikisiku tasandil, kui proovite äri ajada Kickstarteri stiilis, ei ole see tegur nii. oluline tegelikult kiire arendusaeg.olulisem kui komponentide maksumus.

Teisest küljest võivad mikrokontrollerid olla parem valik kui kiibipõhised süsteemid, kui on vaja väikest energiatarbimist. Sellistes süsteemides on kaks punkti: vooluahela enda madal tarbimine töö ajal ja lühike käivitusaeg. Tüüpiline väikeste seadmete aku säästmise meetod on välja lülitatud. Kui lülitate Linuxi arvuti välja, kulub tööle naasmiseks korralik aeg, mõnikord kuni mõni minut. See aeg ei ole manussüsteemide jaoks vastuvõetav.

Kui võtate sellise mikrokontrolleri nagu MSP430, võib see ühe akuga töötada aastaid. Stellaris Launchpad ja Arduino Due on põhimõtteliselt selleks võimelised, nad tarbivad rohkem energiat kui MSP430, kuid võrreldes Raspberry Pi -ga siiski väga vähe. Samuti saab MSP430 pärast väljalülitamist kohe käivituda.

Seega olen täiesti kindel, et kõikides olukordades, kus on vaja teha madalpingeoperatsioone, on mõttekas kasutada mikrokontrollereid. Vajadusel on saadaval palju erinevaid patareidega töötavaid seadmeid.

Kolmandal juhul, nagu ma juba ütlesin, on mikrokontrolleri kasutamine mõttekam kui Linux, toimingutes, mis nõuavad kiiret reageerimist (reaalajas reageerimine). Pean silmas selliseid seadmeid nagu 3D-printerid ja CNC-masinad, tean, millest räägin, kuna olen nende õppimisele palju aega pühendanud. Oma olemuselt nõuavad nad oma töös suurt täpsust, mis sõltub veidi vähem kui täielikult käsklustele reageerimise ajast.

Näiteks kui kasutate ketassaagi, mis lõikab parasjagu puu- või metallitükki, ei saa te protsessi peatada, kuna seda kontrolliv arvuti vajab andmete mälust kettale viimiseks pausi või pausi. midagi muud samas vaimus. Igaüks, kes on arvutit kasutanud, tunneb tavakasutuse ajal tekkivat aeg -ajalt külmumist. Kujutage nüüd ette, et teil on suur puurmasin ja töötab arvuti, mis hakkab töötamise ajal ootamatult Windowsi värskendusi kontrollima ja külvik puurib läbi laua, millel see seisab, sest arvuti kaotas tema üle kontrolli.

Arvutid ja kiibipõhised süsteemid pole loodud reaalajas töötama, isegi Windowsiga, isegi Linuxiga, kuid loomulikult püüavad nad sellele läheneda. Näiteks on Linuxi tuuma jaoks olemas reaalajas plaaster ja spetsiaalne CNC-tarkvara, mis on loodud selliseks tööks. Ma pole selle Linuxi plaastriga piisavalt tuttav, et teada saada, kui paindlik on reaalajas toimuvate sündmuste täielik kontroll. Kuid ma arvan, et see on ainult võimalik alternatiiv, sest Linux, olenemata sellest, millised plaastrid sellele riputatakse, ei löö selles piirkonnas kunagi mikrokontrollereid tänu nende katkestussüsteemile.
Kokkuvõtteks tahan öelda, et kulutasin palju aega, püüdes leida valdkondi, kus mikrokontrollerite kasutamine minu projektides on eeliseks. Ja tundub, et Raspberry Pi ja Beaglebones'i maailmavalitsemise ajastu on kätte jõudnud. See on praegune olukord isetegijate kogukonnas. Enamikul juhtudel on nende süsteemide arendamine kiirem ja lihtsam, seega on see enamiku projektide jaoks sageli parim valik.

Mikrokontrollerite jaoks jäävad alles vaid madalpingeseadmete, reaalajas toimingute ja odavate seadmete alad.

See ei sõltu asjaolust, et mikrokontrollerid võivad tunduda "lõbusamad" kui arvutid. See on midagi, millega tuleb leppida.

Algse postituse tõlge inglise keelest