Sveiks, Habr!
Šodien es jums pastāstīšu par tik interesantu lietu kā operētājsistēma reālā laikā (RTOS). Es neesmu pārliecināts, vai tas būs interesanti pieredzējušiem programmētājiem, bet es domāju, ka iesācējiem tas patiks.

Kas ir RTOS?

Ja paskatāmies Wikipedia, mēs redzam pat 4 definīcijas.
Īsāk sakot, RTOS ir operētājsistēma, kas noteiktā laika posmā reaģē uz ārējiem notikumiem. Tādējādi mēs varam saprast RTOS galveno mērķi - ierīces, kurās nepieciešama ātra reakcija uz notikumiem (tomēr nekādā gadījumā nejauciet RTOS darbību ar pārtraukumiem).

Kāpēc mums tas ir vajadzīgs?

Tam ir diezgan daudz iemeslu.
Pirmkārt, RTOS atbalsta vairākuzdevumu veikšanu, procesa prioritātes, semaforus un daudz ko citu.
Otrkārt, tas ir ļoti viegls un neprasa gandrīz nekādus resursus.
Treškārt, visu iepriekš minēto varam iegūt gandrīz jebkurā aparatūrā (piemēram, FreeRTOS darbojas pat ar 8 bitu AtMega).
Un ceturtkārt: vienkārši spēlējiet un izklaidējieties.

Pārskats par 3 labi zināmiem RTOS.

Uzmanību: sekojošais ir mans personīgais viedoklis.

FreeRTOS

Viens no populārākajiem RTOS šodien. Pārnests uz milzīgu dzelzs daudzumu. Oficiālā vietne.

plusi

1) Bezmaksas
2) Pārvietots uz liels skaits dziedzeris
3) Spēcīga funkcionalitāte
4) Ir dažādas bibliotēkas: grafika, internets un daudz kas cits.
5) Laba dokumentācija.

Mīnusi

1) Diezgan sarežģīts pārnešanas process uz jaunu aparatūru.

Secinājums: Šis ir patiesi profesionāls RTOS ar labu dokumentāciju. Iesācējam būs labi, ja viņa aparatūrā jau ir ports.

KeilRTX

Vēl nesen šis RTOS bija komerciāls, bet nesen kļuva atvērts. Darbojas tikai uz roku arhitektūras. Oficiālā vietne.

plusi

1) Bezmaksas
2) Viegli pārnēsājama uz jaunu aparatūru (roku arhitektūrā).
3) Ir dažādas bibliotēkas: grafika, internets un daudz kas cits.

Mīnusi

1) Kopā ar viņu strādāt Keilā ir gandrīz neiespējami
2) Nedaudz noņemta funkcionalitāte
3) Tiek atbalstīta tikai roka.
4) (ieslēgts Personīgā pieredze) Zaudē ātrumu daudziem RTOS.
Secinājums: ideāli piemērots iesācējiem un maziem projektiem.

uc / os

Spēcīgs komerciāls RTOS. Vietne.

plusi

1) Milzīgs skaits funkciju un bibliotēku.
2) Atbalsta daudz dzelzs

Mīnusi

1) komerciāls.
2) Grūti izmantot.

Secinājums: iesācējam to var saukt par RTOS.

Citas interesantas RTOS

RTLinux RTOS, kas balstīta uz parasto Linux.
QNX RTOS, pamatojoties uz Unix.

Attīstības iezīmes, izmantojot RTOS

Pirmkārt, jums ir jāsaprot sekojošais: RTOS nav Windows. To nevar uzstādīt. Šī sistēma ir vienkārši apkopota kopā ar jūsu programmu.
Rakstot programmas ar RTOS, funkcijas to parastajā nozīmē netiek izmantotas. Funkciju vietā tiek izmantoti procesi (vai uzdevumi) Atšķirība ir tāda, ka procesi, atšķirībā no funkcijām, ir bezgalīgas cilpas un nekad nebeidzas (ja vien kāds vai viņš pats viņu nenogalina - tas ir, izlādē no atmiņas).
Ja ir iespējoti vairāki procesi, RTOS tos pārslēdz, savukārt parādot mašīnas laiku un resursus. Šeit rodas procesa prioritātes jēdziens - ja diviem procesiem vienlaikus ir nepieciešams mašīnas laiks, RTOS to piešķirs tam, kuram ir augstāka prioritāte.
RTOS ir īpašas aizkaves funkcijas - lai viena procesa kavēšanās laikā netiktu tērēts laiks, otrais tiek izpildīts.
Tagad parunāsim par tādu lietu kā semafors - tā ir lieta, kas kontrolē procesa piekļuvi lietojumprogrammu resursiem. Katram resursam ir marķieris - kad procesam ir vajadzīgs resurss, tas to paņem un izmanto. Ja nav marķiera, tad procesam būs jāgaida, līdz tas tiks atgriezts. Es minēšu piemēru: dažādi procesi nosūta informāciju uz vienu UART. Ja nebūtu semafora, tad viņi pēc kārtas sūtītu baitus, un tas būtu haoss. Un tā pirmais process paņēma marķieri uz UART, nosūtīja ziņu un nodeva to otrajam (un tā tālāk - bezgalīgi).

Papildu RTOS bibliotēkas.

RTOS bieži piedāvā dažādas bibliotēkas darbam, piemēram, ar grafiku, internetu utt. Tie ir patiešām ērti, un jums nevajadzētu vilcināties ar to izmantošanu. Tomēr atcerieties, ka bez RTOS, par kuru tie ir rakstīti, tie nedarbosies.
Šeit ir daži piemēri:
RTX

Kas nāk prātā, dzirdot operētājsistēmu? Noteikti ventilācijas atveres, Linux, Macos .. vai kaut kas tamlīdzīgs. Tieši tā, un uz jautājumu, kāpēc tas ir vajadzīgs, visi droši atbildēs: klausieties mūziku, spēlējiet spēli (internetā!), Sarunājoties ar draugu Skype. Tajā pašā laikā, domājot par to, kā mirgo LED, saņemot baitu no uart =).

Un, ja jūs iedziļināties dziļāk, tad mūzikas klausīšanās, datu sūtīšana internetā ir viens process, un, tā kā mums ir viens procesors, tas vienlaikus var veikt tikai vienu uzdevumu. Tāpēc uzdevumi tiek veikti pa vienam nelielās "porcijās", OS būtība ir to darīt nemanāmi lietotāja vietā: lai skaņa nesāpētu un velosipēdi izslēgtos un viss darbotos vienlaikus. Tajā pašā laikā, ja kāds no uzdevumiem "karājas", tad viss pārējais turpināja strādāt.

Ja mēs izmetam visas papildu maizītes un atstājam tukšo būtību, tad, pirmkārt, OS ir tikai taimeris, kas skaita vienādus laika intervālus, kā arī pārslēdzas starp uzdevumiem bez lietotāja iejaukšanās, veic kādu daļu un pārslēdzas vēlreiz. Jums jāņem vērā arī tas, ka lielākajai daļai uzdevumu var nebūt laika, lai tos izpildītu vienā laika šķēlītē, tāpēc jums ir jāsaglabā uzdevuma stāvoklis, pārejot uz citu, un nākamajā reizē, lai atjaunotu uzdevuma stāvokli. mainīgie. To visu pārvalda uzdevumu plānotājs.

Pastāv divi galvenie operētājsistēmu veidi: preventīva un kooperatīva. Pirmajā gadījumā pārslēgšanās starp uzdevumiem būs "grūta", ti. ja laika šķēle ir 1ms, tad vispirms pirmais uzdevums tiks izpildīts tieši 1ms, tad otrais precīzi 1ms utt. Šādas asis sauc par reālā laika (RTOS). Kooperatīvie ir nedaudz vienkāršāki, pašam procesam jāsaka, ka “esmu izpildījis”, tāpēc tos nevar attiecināt uz RTOS.

Iemesla dēļ nevarēs izmantot preemptive uz maziem AVR neliels daudzums RAM. No kooperatīviem pieejamajām iespējām man patika mRTOS, sīkāku informāciju par šo sistēmu varat izlasīt autora vietnē (viegli googlē). galvenais iemesls tā izmantošana - vienkāršība, CAVR gatavas versijas pieejamība, izpratnei visparīgie principi pati lieta.

Tātad paliek galvenie jautājumi, kāpēc un kad izmantot asi. Teorētiski viss ir tas pats, ko jūs darāt ar asi, jūs varat iztikt bez tā, jo resursi ir vienādi. No tā, ka jūs to pielāgojat projektam, megaherci neizlidos kosmosā, dzelzs paliks nemainīgs, tāpēc arī resursi ir vienādi.

Tāpēc ir vērts uzdot sev dažus jautājumus:
1. Vai varat gudri pārvaldīt savus resursus?
2. Vai programmaparatūras rakstīšanas procesā nav paredzēts izgudrot to pašu velosipēdu, līdzīgi kā plānotājs?
3. Cik lasāms ir jūsu kods? Vai jūs varat to atvērt sešu mēnešu vai gada laikā un uzreiz saprast?
4. Vai rakstāt viens vai grupā?

Uz pirmo jautājumu ir grūti atbildēt, jo viss ir atkarīgs no izstrādātāja izliekuma. Ar otro kļūst arvien skaidrāks, ja ir daudz neatkarīgu uzdevumu un plānots tos veikt regulāri, tad labāk jāskatās uz OS. Ar trešo ir arī skaidrs, ka ir daudz vieglāk saprast atsevišķu uzdevumu, nekā izvēlēties atkarības galvenajā cilpā. Ja nerakstāt viens, tad šeit ir arī priekšrocības, jo katrs var uzrakstīt savu problēmu atsevišķi, netraucējot pārējo.

Apvienojot iepriekš minēto, piemērošanas joma ir diezgan specifiska noteiktam uzdevumu klāstam. Jums nevajadzētu to ievietot katrā projektā. Lielākajai daļai radioamatieru amatniecības asis ir lieka, taču, ja par to bija priekšstats iepriekš, es, iespējams, to būtu iebīdījis pāris projektos.

Tagad paskatīsimies zem pārsega. Lai palaistu mRTOS, projektam jāpievieno mrtos.c un jāiekļauj mrtos.h. Koda struktūra nedaudz atšķiras no parastās

#iekļaut #include "mrtos.h" // šeit ir funkcijas pamatteksts, kurā mēs rakstām savu super kodu tukšs uzdevums1 () (kamēr (1) // uzdevumi jebkurā OS ir veidoti, pamatojoties uz bezgalīgu cilpu { // šeit ir jūsu uzdevuma kods DISPATCH; // kontroles nodošanas funkcija plānotājam } ; } // taimera pārtraukšanas apstrādātājs 0 pārtraukt [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 ) { // inicializēt perifērijas ierīces Init_mRTOS (); // inicializēt os // šeit mēs veidojam uzdevumus (uzdevumus) Šeit ir izveidoti 3 uzdevumi create_task (uzdevums1, 1, aktīvs); // izveidot uzdevumu (uzdevuma nosaukums, prioritāte, statuss) create_task (uzdevums2, 1, aktīvs); create_task (uzdevums3, 1, aktīvs); Šedlers (); // palaist plānotāju kamēr (1); )

#iekļaut #include "mrtos.h" // šeit ir funkcijas pamatteksts, kurā mēs rakstām savu super koda void task1 () (kamēr (1) // uzdevumi jebkurā OS ir veidoti, pamatojoties uz bezgalīgu cilpu (// šeit ir jūsu uzdevuma kods DISPATCH; // funkciju vadības pārsūtīšana uz plānotāju);) // taimeris 0 interrupt handler interrupt void timer0_ovf_isr (void) (char ii; #asm ("cli") TCNT0 = 0x9C; inc_systime (); par (ii = 0; ii

Tagad sīkāk. uzdevumu skaitu mrtos.h norāda APPTASKS N. Uzdevums tiek deklarēts jūsu plānotāja 1. uzdevuma () (), 2. uzdevuma () () utt. iekšpusē. Kā redzat, uzdevums sastāv no bezgalīgas cilpas, tas ir normāli un tam vajadzētu būt, taču uzdevuma ietvaros ir obligāti jādod plānotājam kontrole. Vai nu WAIT vai DISPATCH funkcija. Ja tas nav izdarīts, uzdevums tiks izpildīts bezgalīgi.

Kā tas strādā? Izveidosim LED mirgojošu uzdevumu.

tukšs uzdevums1 () (kamēr (1) (PORTB.0 =! PORTB.0; GAIDA (100););)

tukšs uzdevums1 () (kamēr (1) (PORTB.0 =! PORTB.0; GAIDA (100););)

WAIT ir tikai aizkaves () analogs, aizkaves laikā mikrokontrolleris neko nedara un veic tukšus ciklus. Gaidīšanas laikā kontrole tiek pārnesta uz citiem uzdevumiem. Tie. jūs varat izveidot virkni uzdevumu, mirgojot dažādās gaismas diodēs, ar dažādiem GAIDĪJUMIEM, un tie visi mirgos ar dažādām frekvencēm. Ja kavēšanās nav nepieciešama, beigās tiek izmantota DISPATCH.

Izmantojot WAIT, ir svarīgi saprast, ka visai sistēmai ir minimālā atzīme (laika šķēle), tāpēc mēs negaidām GAIDA (50) 50 milisekundes, bet 50 sistēmas ērces. Ērču iestatījums ir atkarīgs no tā, cik bieži tiek izsaukti Timer0 pārtraukumi, t.i. ja mēs iestatām pārtraukumu uz 1 ms, mēs varam pieņemt, ka mūsu darbība tiks izpildīta 1 ms laikā. Eksperimenti parādīja, ka ar 16 MHz pulksteni ir iespējams samazināt sistēmas atzīmi līdz ~ 20 μs.

Taimera iestatījums neatšķiras no iepriekš pētītā, jo taimer0 ir tikai pārplūdes pārtraukums, tad visi iestatījumi ir saistīti ar to. Jaunākajās CAVR versijās ir ļoti ērti rakstīt laika pieprasījumus, iestatījumi tiks ģenerēti automātiski.

create_task (uzdevums1, 1, aktīvs);

create_task (uzdevums1,1, aktīvs);

Ar prioritātēm tas joprojām ir diezgan sarežģīti. Ja ir divi uzdevumi ar atšķirīgām prioritātēm un uzdevums ar augstu prioritāti tiek pastāvīgi izpildīts, tad mēs nekad neieviesīsim uzdevumu ar zemu prioritāti. Tāpēc jums ir jāorganizē darbs tā, lai visiem uzdevumiem būtu piekļuve. Mēs nekoncentrēsimies uz to, mēs to saglabāsim nākamajai reizei. Uzdevuma statuss, Aktīvs - sākts, apturēts StopTask.

Tātad, tiem, kas vēlas vienkārši mirgot LED:

#iekļaut #include "mRTOS.h" void task1 () (while (1) (WAIT (1000); PORTB.0 =! PORTB.0;)) // Taimeris 0 pārpildes pārtraukšanas pakalpojumu rutīna pārtraukt [TIM0_OVF] void timer0_ovf_isr (void) (char ii; #asm ("cli") TCNT0 = 0xb2; inc_systime (); for (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) ; // Taimera / skaitītāja 0 inicializēšana// Pulksteņa avots: sistēmas pulkstenis // Pulksteņa vērtība: 7,813 kHz TCCR0 = (0<< CS02) | (1 << CS01) | (1 << CS00) ; TCNT0= 0x83 ; // Taimeris (-i) / Skaitītājs (-i) Pārtraukšanas (-u) inicializēšana 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 ) ; }

#iekļaut #include "mRTOS.h" void task1 () (while (1) (WAIT (1000); PORTB.0 =! PORTB.0;)) // Taimeris 0 overflow interrupt service rutint interrupt void timer0_ovf_isr (void) (char ii) ; #asm ("cli") TCNT0 = 0xb2; inc_systime (); for (ii = 0; ii

Kā bonusu es mēģināju izveidot polifonisku (divu balsu) melodiju "Dr Mario chill". Ideja ir tāda, ka katra kontroliera kāja tiek pastāvīgi apgriezta atsevišķā uzdevumā, tādējādi radot frekvenci. Mainot aizkavi, varat mainīt piezīmes augstumu.

tukšs uzdevums2 (tukšs) (kamēr (1) (ja (izslēgt == 0) // ja atļauts spēlēt(ja (note_ch2 [n_n] == 0) // ja ir pauze, tad pagaidi, neko nespēlē(PORTB.4 = 0; GAIDIET (5);) cits (PORTB.4 =! PORTB.4; // ja ne pauze, tad raustiet kāju ar vēlamo biežumu Gaidīt (piezīme_ch2 [n_n]); ))))

void task2 (void) (while (1) (if (mute == 0) // ja tam ir atļauts spēlēt (ja (note_ch2 == 0) // ja ir pauze, tad mēs gaidām, mēs nespēlējam) jebkas (PORTB.4 = 0; GAIDĪT (5);) cits (PORTB.4 =! PORTB.4; // ja nav pauze, tad sit ar nepieciešamo frekvenci GAIDI (note_ch2);))))

Es netraucēju ar ideju, 1 uzdevumā solo partijai tiek ģenerēts meanders ar notu frekvenci, otrajā - basam. Katras notis augstums tiek ņemts no masīviem. Ilgums, pārslēgšanās un pārtraukšana 3. uzdevumā.

void task3 (void) (while (1) (WAIT (1500)); // atskaņot minimālo piezīmes ilgumu par (mute = 0; mute< 500 ; mute++ ) // nogrieziet piezīmi, lai tie nesaplūst(PORTB.3 = 0; PORTB.4 = 0;); izslēgt skaņu = 0; // iestatiet karodziņu, lai varētu atskaņot skaņu n_n ++; // pāriet uz nākamo piezīmi ja (n_n == n_max) // ja mēs visu izspēlējām, tad ejam riņķī(n_n = 0;)))

void task3 (void) [while (1) [WAIT (1500); // atskaņot minimālo piezīmes ilgumu (mute = 0; mute< 500; mute++) //обрываем ноту, чтобы не сливались { PORTB.3 = 0; PORTB.4 = 0; }; mute = 0; //выставляем флаг, что можно воспроизводить звук n_n++; //переходим на следующую ноту if(n_n == n_max) //если сыграли все то идем по кругу { n_n = 0; } } }

Lai sajauktu abus kanālus, es izmantoju vienkāršu shēmu.

Kopā mazs gabals

Tiem, kas vēlas programmaparatūru

Es izstrādāju nedaudz vairāk par 10 elektroniskām ierīcēm un pilnībā atteicos no to zema līmeņa darbības bez operētājsistēmas. Situācija mainījās, kad nākamās ierīces funkcionalitāte krasi paplašinājās. Turklāt ir nepieciešams uzdevums, kas tiek izsaukts noteiktos laika intervālos, un zvana precizitāte ietekmē rezultātu. Tāpat kļuva skaidrs, ka piešķirto laiku nebūs iespējams uzrakstīt visu programmatūru, un tā tiks izveidota vēlāk. Pēc nelielām pārdomām es sapratu, ka projektā jāiekļauj reālā laika operētājsistēma (RTOS vai RTOS).

Atšķirībā no datora, kur OS ir vairāk kā slānis darbam ar sistēmas resursiem, RTOS mikrokontrolleram tas galvenokārt ir uzdevumu plānotājs, patiesībā tam ir galvenā loma "reālajā laikā". Šobrīd man ir svarīgi nodrošināt tā saukto "pseidoparalēli" uzdevuma izpildi. Tas ir, ir vairāki uzdevumi ar vienādu prioritāti, un ir svarīgi tos izsaukt noteiktā secībā ar noteiktiem intervāliem.

Šāds piemērs ir skaidrs: projektā Eurobot 2011 sistēmā bija 18 perifērijas ierīces. 2 elektroniskās plates varētu apvienot vienā funkcionalitātes ziņā. To izmaksas samazināsies, to uzticamība palielināsies (sistēmas komponentu skaits samazināsies) un brīvas vietas apjoms korpusā palielināsies. Apstākli sarežģī fakts, ka uzdevumu skaits proporcionāli pieaug un šeit nevar iztikt bez OS. RTOS arī palīdz izvairīties no procesora dīkstāves, piemēram, ADC pārveidošanas laikā jūs varat bloķēt šo uzdevumu un veikt citus, tādējādi pareizi sadalot ierīces darbu. Ir arī svarīgi, lai tagad ierīce nenokristu uzdevuma neveiksmes dēļ; tā vietā ir iespējams saglabāt daļēju darbību (lai gan tas var novest pie neparedzamiem rezultātiem). Kā mēs nodrošinām šo rādītāju pieaugumu? Patiesībā mēs izspiežam visu iespējamo no MK, efektīvi izmantojot tā skaitļošanas iespējas.

Pēc neilgas meklēšanas izvēle tika dota uz freeRTOS. Šis RTOS tiek izplatīts C avotā un pārnests uz 27 arhitektūrām. Pēdējais apstāklis ​​man ir noteicošais. Tas samazinās darbaspēka izmaksas, strādājot ar citu ražotāju MCU. Tagad mani vairāk interesē AVR ports.

RTOS freeRTOS klātbūtne projektā apēd aptuveni 9,8 KB programmas atmiņas un 1,8 KB RAM. Piemēram, ATmega32 un WinAVR kompilatoram tas ir attiecīgi 60% un 85%. Jau šim modelim ir grūti izveidot ierīci ar lielisku funkcionalitāti - nepietiks atmiņas. Bet šī problēma pazūd līdz ar jaunajiem AVR modeļiem. Tas ir pilnīgi nesvarīgi Mega2560 ar 256 KB programmas atmiņu un 8 KB RAM. Nākotnes MC tendence pavada tikai RTOS panākumus.

Izlūkojis Runet, es biju pārsteigts, atklājot, ka nav OS dokumentācijas krievu valodā. Kas tas ir! Oriģinālā dokumentācija tiek izplatīta par papildu samaksu. Situāciju vienkāršoja Andreja Kurņica raksts ( [e -pasts aizsargāts]) no žurnāla "Komponenti un tehnoloģijas". Ar autora piekrišanu es izmantošu raksta materiālus pārskatītā versijā. Viņa raksts var kalpot kā dokumentācija krievu valodā. Bet oriģināls nav pieejams drukātā veidā, žurnāla vietne melo, tāpēc materiāls būs nedaudz jāpārstrādā. Kopumā autore ir izveidojusi izcilu rakstu un nav jēgas vēlreiz pāriet pie teorijas, tā tiks publicēta šeit pilnībā. Raksta oriģināls tiks pievienots publikācijas beigās. Es arī pamanīju, ka lietotājiem bija grūtības sastādīt RTOS. Tas ir saistīts ar faktu, ka tiek izmantota ārējā makefile, kas satur ceļus uz mapēm. Tāpēc es pievienošu gatavu projektu kā veidni AVR Studio un AVR Eclipse. Diemžēl vietējā makefile neizdala atkļūdošanas informāciju, piemēram, RAM un programmas atmiņas izmantošanu, tas bija jānovērš, pievienojot atbilstošu standarta zvanu.

Tātad, īsi par nepieciešamību, ja nepieciešams, projektā ieteicams izmantot RTOS:

Organizējiet vairākuzdevumu veikšanu un alternatīvus uzdevumus

Nodrošiniet uzdevuma uzsākšanu stingri noteiktos intervālos

Pārsūtiet informāciju no viena uzdevuma uz citu

Ja nepieciešams, pievienojiet jaunus uzdevumus

RTOS priekšrocības salīdzinājumā ar M TO:

1. Daudzuzdevumu veikšana. RTOS nodrošina programmētājam gatavu, atkļūdotu daudzuzdevumu mehānismu. Vienkāršā gadījumā katru uzdevumu var ieprogrammēt atsevišķi, visu darbu var sadalīt starp vairākiem komandas locekļiem. Jums nav jāuztraucas par pārslēgšanos starp uzdevumiem, plānotājs to darīs.
2. Laika bāze. Ir jāmēra laika intervāli. RTOS jābūt šim rīkam. Tas ļaus jums veikt darbības stingri noteiktos intervālos.
3. Datu apmaiņa starp uzdevumiem. Šim nolūkam RTOS izmanto rindu.
4. Sinhronizācija. Ja dažādi uzdevumi izmanto vienu un to pašu resursu, piemēram, seriālo portu, var izmantot mutexes un kritiskās sadaļas. Ja jums ir jāizpilda uzdevumi stingrā secībā vai ja notiek kāds konkrēts notikums, uzdevumu sinhronizēšanai varat izmantot semaforus vai signālus.

RTOS trūkumi:

1. Straujš nepieciešamās programmas atmiņas pieaugums kodola ieviešanai

2. Nepieciešamās RAM palielināšana katra uzdevuma kaudzes, semaforu, rindu, muteksu un citu sistēmas kodola objektu uzglabāšanai.

3. Kavēšanās, pārslēdzoties starp uzdevumiem, lai saglabātu kontekstu.

AprakstsfreeRTOS:

FreeRTOS ir bezmaksas atvērtā pirmkoda cietā reālā laika OS. Pārsvarā rakstīts C, bet ir montāžas ieliktņi. To izstrādāja SIA “Real Time Engineers” speciāli iegultām sistēmām. Nesen tika izstrādāts projekts SafeRTOS - modificēta, dokumentēta, pārbaudīta un sertificēta FreeRTOS versija atbilstībai drošības standartam IEC 61508. Šo projektu veica vācu uzņēmums, un tagad safeRTOS tiek izmantots kosmosa rūpniecībā un medicīnas tehnoloģijās. Ir arī openRTOS projekts - komerciāla versija ar ražotāja garantiju.

FreeRTOS galvenās iezīmes:

1. Plānotājs atbalsta trīs veidu daudzuzdevumus:

Pārvietošana

Kooperatīvs

Hibrīds

2. Kodola izmērs ir 9,8 KB, kas apkopoti AVR. (WINAVR)

3. Kodola bāze - 4 faili C.

4. Atbalsta uzdevumus un norādes. Coroutines ir īpaši izstrādātas MCU ar nelielu RAM apjomu.

5. Bagātīgas izsekošanas iespējas.

6. Ir iespējams izsekot kaudzes pārpildei.

7. Nav programmatūras ierobežojumu vienlaicīgi izpildīto uzdevumu skaitam.

8. Uzdevumu prioritāšu skaits nav ierobežots.

9. Vairākiem uzdevumiem var piešķirt vienu un to pašu prioritāti

10. Uzlaboti sinhronizācijas līdzekļi "uzdevuma uzdevums" un "uzdevuma pārtraukšana":

Rindas

Binārie semafori

Semaforu skaitīšana

Rekursīvi semafori

Muteksi

11. Mutexes ar prioritāro mantojumu.

12. Atbalsts Cortex-M3 atmiņas aizsardzības modulim

13. Tiek piegādāts atkļūdotā veidā ar demonstrācijas projektiem dažādām platformām un kompilatoriem.

14. Bezmaksas. Var izmantot projektos, neizpaužot avota kodu saskaņā ar paplašināto GPL licenci.

15. Dokumentācija ir apmaksāta, bet pieejama tiešsaistē šeit.

16. Konteksta pārslēgšanās laiks AVR ar kvarcu pie 16 MHz būs tikai 20,8 µs. Tieši tik daudz ir nepieciešams, lai saglabātu datus uzdevumu kaudzē un izsauktu nākamo. (Interesanta piezīme, ja jūs to salīdzināt ar PIC18xxx, tad AVR kontrolieris to padara 4 reizes ātrāku !!!, visticamāk, tas ir saistīts ar kompilatora kvalitāti)

Preventīva vairākuzdevumu veikšana nozīmē, ka darbības uzdevums ar zemu prioritāti pārklājas ar pabeigtu uzdevumu ar augstāku prioritāti. Pārslēgšanās starp uzdevumiem notiek vienādās laika šķēlēs. Tāpēc, pirms augstas prioritātes uzdevums var sākt izpildi, pašreizējam laika posmam ir jābūt pagātam, kad tiek izpildīts zemas prioritātes uzdevums.

Tādējādi FreeRTOS reakcijas laiks uz ārējiem notikumiem preventīvā daudzuzdevumu režīmā ir ne vairāk kā viena plānotāja laika šķēle, kuru var iestatīt iestatījumos. Pēc noklusējuma tas ir 1 ms.

Ja vairāki uzdevumi ar vienādu prioritāti ir gatavi izpildei, tad plānotājs katram no tiem piešķir vienu laika šķēli, pēc kura vadību saņem nākamais uzdevums ar tādu pašu prioritāti utt.

Kooperatīvā daudzuzdevumu veikšana atšķiras no iepriekšējas daudzuzdevumu veikšanas ar to, ka plānotājs pats nevar pārtraukt pašreizējā uzdevuma izpildi, pat uzdevumu ar augstu prioritāti, kas ir gatavs izpildei. Katram uzdevumam neatkarīgi jāpārnes kontrole uz plānotāju. Tādējādi augstas prioritātes uzdevums gaidīs, kamēr zemās prioritātes uzdevums būs pabeigts, un atgriezīs kontroli plānotājā. Sistēmas reakcijas laiks uz ārēju notikumu kļūst nenoteikts un atkarīgs no tā, cik ilgi pašreizējais uzdevums tiks izpildīts pirms kontroles nodošanas. Kooperatīvā daudzuzdevumu veikšana tika izmantota operētājsistēmu Windows 3.x saimē.

Preventīvās un sadarbības daudzuzdevumu koncepcijas apvienojas hibrīda daudzuzdevumu veikšanā, kur plānotājs tiek izsaukts katru reizi, bet atšķirībā no iepriekšējas daudzuzdevumu veikšanas programmētājam ir iespēja to izdarīt piespiedu kārtā. Šis režīms ir īpaši noderīgs, ja nepieciešams saīsināt sistēmas reakcijas laiku līdz pārtraukumam. Pieņemsim, ka zemas prioritātes uzdevums pašlaik tiek izpildīts, un augstas prioritātes uzdevums gaida pārtraukumu. Tad notiek pārtraukums, bet pārtraukuma apstrādātāja beigās izpilde atgriežas pie pašreizējā zemas prioritātes uzdevuma, un augstas prioritātes nogaida, līdz beidzas pašreizējā laika šķēle. Tomēr, ja pēc pārtraukuma apstrādātāja izpildes jūs nododat vadību plānotājam, tas pārnes kontroli uz augstas prioritātes uzdevumu, kas var samazināt sistēmas reakcijas laiku, kas saistīts ar ārēju notikumu.

Kāpēcuztērzētb?

Jūs varat sākt izstrādāt FreeRTOS mikrokontrollera ierīci, lejupielādējot tās jaunāko versiju.

FreeRTOS izplatīšana ir pieejama kā parasts vai pašizpletes ZIP arhīvs. Izplatīšana Tieši satur kodola kodu (vairāku galvenes failu un failu ar avota kodu veidā) un demonstrācijas projektus (viens projekts katrai ostas attīstības videi). Tālāk jums vajadzētu izpakot arhīvu uz jebkuru piemērotu vietu attīstības stacijā.

Neskatoties uz lielo failu skaitu arhīvā, direktoriju struktūra patiesībā ir vienkārša. Ja plānojat izstrādāt ierīces uz 2-3 arhitektūrām 1-2 izstrādes vidēs, tad lielākā daļa failu, kas saistīti ar demonstrācijas projektiem un dažādām izstrādes vidēm, nebūs nepieciešami.

Diagrammā ir parādīta detalizēta direktoriju struktūra.

Viss kodola avota kods atrodas direktorijā / Source.

Saturs:

1.uzdevumi.c- uzdevumu mehānisma ieviešana, plānotājs

2. rinda.c- rindu ieviešana

3. saraksts.c- plānotāja iekšējās vajadzības, bet funkcijas var izmantot arī lietojumprogrammās.

4. krutīns.c- korutīnu ieviešana (var nebūt, ja korutīni netiek izmantoti).

Galvenes faili, kas atrodas direktorijā avots / iekļaut

1.uzdevumi.h, rinda.h, tist.h, krutīns.h- galvenes faili attiecīgi tāda paša nosaukuma failiem ar kodu.

2. FreeRTOS.h-satur priekšapstrādātāja direktīvas kompilācijas konfigurēšanai.

3.mpu_wrappers.h- satur FreeRTOS programmēšanas saskarnes (API) funkciju ignorēšanu, lai atbalstītu atmiņas aizsardzības moduli (MPU).

4. pārnēsājams.h-no platformas atkarīgi iestatījumi.

5.projdefs.h-dažas sistēmas definīcijas

6. semphr.h- nosaka API funkcijas darbam ar semaforiem, kuras tiek ieviestas, pamatojoties uz rindām.

7. StackMacros.h- satur makro, lai kontrolētu kaudzes pārpildi. Katrai aparatūras platformai ir nepieciešams neliels kodola koda gabals, kas īsteno FreeRTOS savietojamību ar šo platformu. Viss platformas kods atrodas apakšdirektorijā / Avots / Pārnēsājams, kur to klasificē pēc izstrādes vides (IAR, GCC utt.) un aparatūras platformām (piemēram, AtmelSAM7S64, MSP430F449). Piemēram, apakšdirektorijs / Avots / Pārnēsājams / GCC / ATMega323 satur failus port.c un portmacro.h, kas īsteno uzdevuma konteksta saglabāšanu / atjaunošanu, taimera inicializēšanu, lai izveidotu laika bāzi, inicializētu katra uzdevuma kaudzīti un citas no aparatūras atkarīgas funkcijas mega AVR saimes un WinAVR mikrokontrolleriem kompilators (GCC).

Atsevišķi jums vajadzētu izcelt apakšdirektoriju / Avots / Pārnēsājams / MemMang kurā ir faili kaudze_l.c, kaudze_2.c, kaudze_3.c kas īsteno 3 dažādus mehānismus atmiņas piešķiršanai FreeRTOS vajadzībām, kas tiks sīkāk aprakstīti vēlāk.

Katalogā / Demo ir demonstrācijas projekti, kas ir gatavi apkopošanai un veidošanai. Visu demo projektu koda kopējā daļa ir iezīmēta apakšdirektorijā / Demo / Commo n.

Lai projektā izmantotu FreeRTOS, jums jāiekļauj kodola avota faili un saistītie galvenes faili. Nav nepieciešams tos mainīt vai saprast to ieviešanu.

Piemēram, ja jūs plānojat izmantot portu MSP430 mikrokontrolleriem un GCC kompilatoram, tad, lai izveidotu projektu no jauna, jums būs nepieciešamas apakšdirektorijas / Avots / Pārnēsājams / GCC / MSP430_GCC un / Avots / Pārnēsājams / MemMang... Visas pārējās direktorijas / Source / Portable apakšdirektorijas nav vajadzīgas, un tās var noņemt.

Ja plānojat modificēt esošo demo projektu (ko patiesībā ieteicams darīt FreeRTOS pētījuma sākumā), tad jums būs nepieciešamas arī apakšdirektorijas / Demo / msp430_GCC un / Demo / Kopīgs... Pārējās apakšdirektorijas / Demo nav nepieciešamas, un tās var noņemt.

Veidojot lietojumprogrammu, ieteicams to izmantot makefile(vai attīstības vides projekta fails) no attiecīgā demonstrācijas projekta kā sākumpunkts. Ieteicams izslēgt no būvniecības (būvēšanas) failus no direktorija / Demo, aizstājot tos ar savējiem, un failus no direktorija / Avots - neskartus. Jāpiemin arī galvenes fails FreeRTOSConfig.h kas ir katrā demonstrācijas projektā. FreeRTOSConfig.h satur definīcijas (#define), kas ļauj konfigurēt FreeRTOS kodolu:

1. Sistēmas funkciju kopums.

2. Korutīnu izmantošana.

3. Uzdevumu un secību prioritāšu skaits

4. Atmiņas izmēri (kaudze un kaudze).

5. MK pulksteņa frekvence.

6. Katram izpildes uzdevumam piešķirtā laika plānotāja periods, kas parasti ir 1 ms. Atspējojiet dažas sistēmas funkcijas un samaziniet prioritāšu skaitu (samazina atmiņas patēriņu).

FreeRTOS izplatīšanā ir iekļauti arī rīki no plānotāja saņemtās izsekošanas informācijas pārvēršanai teksta formā (direktorijā) / TgaseCon) un licences tekstu (direktoriju / Licence).

secinājumus

Ar sērijas pirmā raksta palīdzību lasītājs iepazinās ar FreeRTOS mikrokontrolleru operētājsistēmu. Tiek parādītas darba iezīmes. Aprakstiet FreeRTOS izplatīšanas saturu. Ir norādītas pamata darbības, lai sāktu izstrādāt ierīci, kurā darbojas FreeRTOS.

Turpmākajās publikācijās uzmanība tiks pievērsta daudzuzdevumu mehānismam, proti, uzdevumiem un korodīniem. Plānotāja piemērs tiks parādīts, izmantojot Atmel AVR mikrokontrolleru un WinAVR kompilatora (GCC) piemēru.

Es pastāvīgi uzdodu šo jautājumu, vienlaikus darot savu hobiju - izstrādājot mājas automātiskās vadības sistēmu (viedo māju), kuras pamatā ir 16 bitu mikrokontrolleris - vai tā tiešām ir pareizā pieeja? Pirms pusotra mēneša savā emuārā jau rakstīju par tēmu "Mikrokontrolleri pret sistēmām mikroshēmā". Tātad, es atkal par to rakstīšu.

Daļēji mani motivēja Stellaris Launchpad un Arduino Due izlaišana. Tie abi ir balstīti uz 32 bitu mikrokontrolleriem un daudzējādā ziņā ir ļoti līdzīgi. Esmu izpētījis abu datu lapu, un, lai gan cenu ziņā tās atšķiras, tās ir paredzētas vienai un tai pašai mērķauditorijai. Es domāju, ka varbūt man vajadzētu pārslēgties no MSP430 uz Stellaris vai varbūt pat pāriet uz principiāli atšķirīgu sistēmu, mikrokontrolleru vietā izmantot kaut ko līdzīgu Raspberry Pi.

Gan Stellaris Launchpad, gan Arduino Due ir ļoti spēcīgi, taču nav paredzēti Linux darbināšanai. Tie darbojas vai nu uz izpildāmā koda, kas rakstīts tieši viņiem, vai arī tiek kontrolēts reāllaika operētājsistēmā (RTOS)-minimālistiskā OS ar ļoti īsu reakcijas laiku uz ārējiem notikumiem. Tie abi ir ievērojami sarežģītāki nekā MSP430 vai 8 bitu AVR.

No otras puses, reālajā dzīvē (ārpus interneta) lielākā daļa man pazīstamo cilvēku izmanto Raspberry Pi vai citas iegultās Linux sistēmas. Mikrokontrolleru izmantošana ir diezgan rets gadījums starp tiem, kurus esmu satikusi. Pat Arduino manā vidē ir daudz mazāk populārs nekā iegultais Linux. Kā es saprotu, kāpēc lai kāds iegādātos Arduino, ja jūs varat iegūt Raspberry Pi, kas spēj paveikt daudz vairāk, bet maksā tikpat vai mazāk? Linux ir pieejams milzīgs daudzums gatavas programmatūras, un jūs varat tajā programmēt, izmantojot vienkāršas skriptu valodas.

Man personīgi iemesls, kāpēc es nevēlos izmantot Linux, ir tas, ka es to izmantoju katru dienu darbā, un, atgriežoties mājās, man nav prieka atkal strādāt ar Linux līdzīgām sistēmām. Man nav problēmu izmantot Linux, bet to ir pārāk daudz visā vietā, tas mani nosver. Man ir daudz interesantāk strādāt ar vienkāršām elektroniskām ierīcēm uz 8/16 bitu mikroshēmām.

Tomēr es nepagriežu muguru realitātei. Ja es vēlos palikt saskaņā ar reālo pasauli, man ir jāizmanto rīki, kas tiek izmantoti reālajā pasaulē. Pretējā gadījumā tas ir kā vēlme vadīt automašīnu ar tvaika dzinēju tikai tāpēc, ka iekšdedzes dzinējs ir pārāk ikdienišķs, tāpēc es to izmantoju visu laiku. Ja apkārtējā pasaule pāriet uz modernāku tehnoloģiju, tas ir jāapgūst, man tas patīk vai nē. It īpaši, ja es vēlos, lai mans emuārs būtu interesants cilvēkiem un paliktu aktuāls.

Savā viedās mājas projektā es patiesībā saskāros ar šo problēmu. Es jau esmu izveidojis LAN draiveri vadības sistēmai MSP430, un viss izskatās ļoti pienācīgi. Būtībā es varu darīt visu, kas nepieciešams automatizācijas sistēmai MSP430. Tomēr es domāju, vai tas, kā es to daru, ir pareizs? Vai es mēģinu ēst zupu ar dakšiņu, ja ir karote? Varbūt Linux ir labāka sistēma? Ļauj man paskaidrot.

Ja jūs apstājaties un paskatāties uz pašreizējo situāciju, ņemot vērā tehnoloģisko progresu 2012. gada novembrī. Es jautāju sev, vai mikrokontrolleri ir pietiekami labi un atbilstoši, salīdzinot ar mikroshēmā esošām sistēmām, kurās tiek izmantota Linux?

Ja jūs uzskaitāt manā prātā ienākošo sistēmu projektus, tie ir: bezpilota lidaparāti, roboti, mājas automatizācija, motoru kontrolieri, sensori, rokas pulksteņi, 3D printeri utt. Kurā no šiem gadījumiem iegultā Linux ir piemērotāka nekā mikrokontrolleri? Un kāpēc?

Es domāju, ka ir trīs situācijas, kad mikrokontrolleris ir labākā izvēle: kur svarīga (tūlītēja) reakcija uz notikumiem; kur nepieciešams ārkārtīgi zems enerģijas patēriņš; un kur jums jāizmanto mikroshēmas ar viszemākajām iespējamām izmaksām.

Sākumā lētu mikroshēmu izmantošana man nav tik svarīga. Es nodarbojos ar savu hobiju un nedomāju izlaist konkurētspējīgus produktus. Man nav jādomā par ražošanas pārvietošanu uz vergu darbaspēka ražotni, lai par konkurētspējīgām cenām maksātu mazos projektus, kurus izstrādāju. Es būtu laimīga, ja, pateicoties savām spējām, varētu lodēt vairāk nekā vienu dēli dienā!

Piemēram, gudras mājas projektam es varu izveidot tālvadības slēdzi. Tas var ieslēgt / izslēgt apgaismojumu vai kaut ko citu. Tajā pašā laikā es varu doties uz vietējo elektrības veikalu un nopirkt to pašu par 20 ASV dolāriem, kas ražoti Ķīnā. Vai es kādreiz pārspēšu šo cenu, mēģinot pārdot savu slēdzi? Nedomāju, ka tas ir iespējams.

Ja tā padomā, tas attiecas arī uz daudzām citām lietām, kas nepieciešamas mājas automatizācijai. Temperatūras, dūmu, kustību u.c. sensori, es esmu diezgan spējīgs to izdarīt pats, taču maz ticams, ka no tā var gūt finansiālu labumu. Kam interesē šādas lietas no manis nopirkt par 75 ASV dolāriem, ja tās var atrast par 20 ASV dolāriem mājsaimniecības produktos?

Ja jūs domājat iegūt kādu labumu no sava hobija, tad labāk pievērst uzmanību dārgākiem un sarežģītākiem produktiem. Piemēram, mājas automatizācijas kontrolieris vai termostats parasti maksā vairāk nekā 100 USD un atstāj lielāku brīvību individuālai radošumam, jūs varat to izveidot, pārdot kaimiņiem un pat nopelnīt no tā.

Bet vēlme iegūt labāku cenu par galīgo ierīci nenozīmē, ka jums ir jāizmanto lētākais mikrokontrolleris uz zemes. Patiesībā šī ir slikta ideja, jo izstrādes laikam ir tādas pašas izmaksas kā izmantotajām detaļām. Mikrokontrolleris var būt lēts, taču vadības koda uzrakstīšana prasa vairāk laika. Laiks ir nauda, ​​un, strādājot ātrāk, jūs varat sasniegt vairāk.

Visas šīs pārdomas liek man secināt, ka ir izdevīgāk attīstīt viedās mājas sistēmu uz Linux, nevis uz mikrokontrolleriem, neskatoties uz manām personīgajām vēlmēm, neizmantot Linux (man zema līmeņa programmēšana patīk vairāk nekā skripti, Linux man kļūst garlaicīgi) .

Atgriežoties pie tēmas tēmas, mikrokontrolleru cena var būt svarīgs faktors lielajām korporācijām, kuras gatavojas laist klajā jaunu produktu, taču individuālā līmenī, ja jūs mēģināt vadīt biznesu Kickstarter stilā, šis faktors nav tāds patiesībā svarīgs ir ātrs izstrādes laiks, kas ir svarīgāks par sastāvdaļu izmaksām.

No otras puses, ja ir nepieciešams zems enerģijas patēriņš, mikrokontrolleri var būt labāka izvēle nekā sistēmas mikroshēmā. Šādās sistēmās ir divi punkti: mazs ķēdes patēriņš darbības laikā un īss sākuma laiks. Tipiska akumulatora taupīšanas metode mazām ierīcēm tiek izslēgta. Izslēdzot Linux datoru, atgriešanās darbā prasa pienācīgu laiku, dažreiz pat dažas minūtes. Šis laiks nav pieņemams iegultām sistēmām.

Ja ņemat tādu mikrokontrolleri kā MSP430, tas var darboties gadiem ilgi ar vienu akumulatoru. Stellaris Launchpad un Arduino Due principā uz to ir spējīgi, tie patērē vairāk enerģijas nekā MSP430, bet joprojām ir ļoti maz salīdzinājumā ar Raspberry Pi. Arī MSP430 var uzreiz sākt pēc izslēgšanas.

Tādējādi esmu pilnīgi pārliecināts, ka visās situācijās, kad nepieciešamas zemsprieguma darbības, ir jēga izmantot mikrokontrollerus. Vajadzības gadījumā ir pieejamas dažādas ar baterijām darbināmas ierīces.

Trešajā gadījumā, kā es jau teicu, mikrokontrollera izmantošana ir nozīmīgāka nekā Linux operācijās, kurām nepieciešama tūlītēja atbilde (reāllaika atbilde). Es domāju tādas ierīces kā 3D printeri un CNC mašīnas, es zinu, par ko es runāju, jo esmu veltījis daudz laika to izpētei. Pēc savas būtības viņi savā darbā prasa augstu precizitāti, kas ir nedaudz mazāk nekā pilnībā atkarīga no reakcijas laika uz komandām.

Piemēram, ja jūs izmantojat ripzāģi, kurā pašlaik tiek nogriezts koka vai metāla gabals, jūs nevarat pārtraukt procesu, jo datoram, kas to kontrolē, ir nepieciešama pauze, lai dati tiktu pārvietoti no atmiņas uz disku vai kaut kas cits tādā pašā garā. Ikviens, kurš ir lietojis datoru, ir iepazinies ar gadījuma rakstura sasalšanu, kas notiek intermitējoši normālas lietošanas laikā. Tagad iedomājieties, ka jums ir liela urbjmašīna, kurā darbojas dators, kas darba laikā pēkšņi sāk pārbaudīt Windows atjauninājumus, un urbis urbjas caur galdu, uz kura tas stāv, jo dators zaudēja kontroli pār viņu.

Datori un sistēmas mikroshēmā nav paredzēti darbam reālā laikā, pat ar Windows, pat ar Linux, taču, protams, viņi cenšas tam pietuvoties. Piemēram, Linux kodolam ir reāllaika ielāps un īpaša CNC programmatūra, kas izveidota šāda veida darbam. Es neesmu pietiekami pazīstams ar šo Linux ielāpu, lai zinātu, cik elastīga ir pilnīga reāllaika notikumu kontrole. Bet es domāju, ka tā ir tikai iespējama alternatīva, jo Linux, neatkarīgi no tā, kādi ielāpi ir uzlikti, nekad nepārspēs mikrokontrollerus šajā jomā, pateicoties to pārtraukšanas sistēmai.
Nobeigumā es gribu teikt, ka es pavadīju daudz laika, cenšoties atrast jomas, kurās mikrokontrolleru izmantošanai savos projektos ir priekšrocības. Un izskatās, ka ir pienācis Raspberry Pi un Beaglebones pasaules kundzības laikmets. Šī ir pašreizējā situācija DIY kopienā. Vairumā gadījumu šo sistēmu izstrāde ir ātrāka un vienkāršāka, tāpēc bieži vien tā ir labākā izvēle lielākajai daļai projektu.

Mikrokontrolleriem paliek tikai zemsprieguma ierīču, reālā laika darbību un lētu ierīču apgabali.

Tas nav atkarīgs no tā, ka mikrokontrolleri var šķist "jautrāki" nekā personālie datori. Ar to jums ir jāsamierinās.

Sākotnējā ziņojuma tulkojums no angļu valodas