Provozní systémy v reálném čase pro mikrokontroléry. Vložené systémy a OS pro ně

Ahoj, Habr!
Dnes vám řeknu o takové zajímavé věci jako operační systém V reálném čase (OSR). Nejsem si jistý, že to bude zajímavé pro zkušené programátory, ale myslím, že se mi líbí začátečníky.

Co je OSR?

Podíváme-li se na Wikipedii, uvidíme se až 4 definice.
Pokud řeknete stručně, OSR je operačním systémem, který reaguje na externí události v určitém časovém období. Odtud můžeme pochopit hlavním účelem OSR - zařízení, ve kterých je zapotřebí rychlé reakce na události (ale v žádném případě se nezaměňují práci OSR s přerušením).

Proč ji potřebujeme?

To je, docela mnoho důvodů.
Za prvé, OSRV podporuje multitasking, priority procesů semaforu a mnoho dalšího.
Za druhé, je to velmi snadné a téměř nevyžaduje zdroje.
Zatřetí, všechny výše uvedené můžeme dostat téměř na jakékoli žlázy (například Freertos běží i na 8bitové atmega).
No, za čtvrté: jen hrát sami a užívat si.

Přehled 3 dobře známých OSR.

Pozor: pak jde o můj osobní názor.
FREERTOS.
Jeden z nejoblíbenějších OSR dnes. K obrovskému množství železa. Oficiální stránka.
profesionálové
1) zdarma
2) portováno velký počet žláza
3) Výkonná funkčnost
4) Existují různé knihovny: grafika, internet a další.
5) Dobrá dokumentace.
Minusy
1) docela komplexní proces portování do nového železa.

Závěr: Je to opravdu profesionální sdílení s dobrou dokumentací. Bude to dobré pro začátečníka, pokud má přístav již port.

Keilrtx.
Až do nedávné doby byl tento OSRV komerční, ale nedávno se otevřel. Pracuje pouze na architektuře paže. Oficiální stránka.
profesionálové
1) zdarma
2) Snadno porty do nového železa (v rámci architektury ramene).
3) Existují různé knihovny: grafika, internet a další.
Minusy
1) Práce na Keilu je téměř nereálná
2) malá oříznutá funkčnost
3) Podporováno je pouze rameno.
4) (Osobní zkušenosti) ztrácí mnoho druhů rychlosti.
Závěr: Ideální pro začátečníky i malé projekty.
uC / OS.
Výkonné obchodní sdílení. Webová stránka .
profesionálové
1) Obrovský počet funkcí a knihoven.
2) podporuje spoustu železa
Minusy
1) komerční.
2) Komplex v použití.

Závěr: Můžete ho zavolat na nováček s velkým úsekem.

Další zajímavé Osrvs.

Rtlinux OSRV na základě obyčejného Linuxu.
QNX OSRV na základě Unixu.

Vývojové funkce pomocí OSRV

Nejprve je nutné pochopit následující: DRA není systém Windows. Nelze nainstalovat. Tento systém je jednoduše zkompilován s vaším programem.
Při psaní programů s OSR nejsou funkce používány v jejich obvyklém porozumění. Místo funkcí, procesy (nebo testy) jsou použity. Skutečnost, že procesy, na rozdíl od funkcí, jsou nekonečné cykly a nikdy nekončí (pokud je to jen někdo nebo nezabije - to je vyloženo z paměti).
Pokud je zahrnuto několik procesů, pak je OSR přepne, vydávající čas a zdroje stroje. Je-li pojetí priority procesu vznikne, pokud tyto dva procesy potřebují jednorázový čas motoru, OSR ji dá tomu, kdo má více priority.
V OSRV existují zvláštní funkce zpoždění - takže čas v marném případě nezmizí v době zpoždění jednoho procesu, druhý se provádí.
Promluvme si o takové věci jako semafor - tato věc, která řídí přístup žádosti o zdroje aplikací. Pro každý zdroj je značka - když proces potřebuje zdroj - to trvá a používá tento zdroj. Pokud není značka, proces bude muset počkat, až bude vrácen. Dám příklad: různé procesy odesílat informace na jednom UART. Kdyby tam nebyl semafor, zasílají by bajty a byli by zmatenost. A tak první proces vzal značku na UART poslal zprávu a dal druhý (a tak - do nekonečna).

Další knihovny OSR.

OSRV často nabízí různé knihovny pro práci, například s grafikou, internetem atd. Jsou opravdu pohodlné a neměly by být nuceny používat je. Nezapomeňte však, že bez OSR, pro které jsou napsány, nebudou fungovat.
Zde jsou příklady:
Pro rtx.

Co se děje, když uslyšíte operační systém? Jistě okna, Linux, makro .. nebo něco takového. Pravda, a na otázku, proč potřebuje, každý bude s jistotou odpovědět: poslouchat hudbu, hrát hru (na internetu!), Mluvit s ostatními na Skype. Zároveň se uvažuje o blikání LED, když přijal bajt z Yuart \u003d).

A pokud vykopáte hlouběji, pak posloucháte hudbu, odesílání dat přes internet je všechny jednotlivé procesy, a protože máme jeden procesor, pak současně může provádět pouze jeden úkol. Proto jsou úkoly prováděny střídavě v malých "porcích", podstata operačního operačního operace je nepozorovaně pro uživatele: takže zvuk není chraptivý a biketika zpívají a vše pracovalo ve stejnou dobu. Pokud některá z úkolů bude "zavěsit", pak všechno ostatní pokračovalo v práci.

Pokud upustíte všechny další buchty a nechte nahou podstatu, pak je to první z operačního systému, je to jen časovač, který počítá stejné intervaly, a sám, bez účasti uživatele, přepínače mezi úkoly, provádí nějakou část a přepne se znovu. Je také třeba zvážit, že většina úkolů nemusí mít čas dokončit v jednom kvantovém čase, takže je třeba zachránit stav úkolu v době přepnutí na druhý, a příště k obnovení stavu proměnných . Správa všeho to provádí plánovač úloh.

Existují dva hlavní typy OS: vysídlení a družstva. V prvním případě bude přepínání mezi úkoly "tvrdý", tj. Pokud je kvantum času 1ms, pak první úkol bude proveden přesně 1ms, pak druhé přesné 1 ms, atd. Takové osy se nazývají v reálném čase (orvd). Družstvo je o něco jednodušší, samotný proces musí říci, že "Byl jsem popraven", proto je nemožné je přiřadit.

Rychlé vynikající AVR nebude fungovat, protože malé číslo RAM. Z dostupných možností družstev byl přitahován MRTOS, můžete si přečíst podrobnosti tohoto systému na webových stránkách autora (snadno googles). hlavní důvod Jeho použití je jednoduchost, přítomnost připravené verze pod Cavr, pro porozumění obecné principy Nejvíce.

Hlavní otázky zůstaly, proč a kdy aplikovat osu. Teoreticky, všechny totéž, co děláte s osou, můžete bez něj překonat, protože zdroje jsou stejné. Ze skutečnosti, že jej přijmete na projektu, Megahertz v prostoru nebude vzlétnout, železo zůstane stejné, proto jsou zdroje stejné.

Proto byste se měli zeptat na pár otázek:
1. Můžete zvládnout kompetentní zdroje?
2. Nemá být vymyslet stejné kolo v procesu psaní firmwaru?
3. Kolik čtete kód? Jste schopni ho otevřít za půl roku a jít ven?
4. Píšete nebo skupinu?

Je těžké dát odpověď na první otázku, pro to vše závisí na studijní činnosti developera. S druhým je vše srozumitelnější, pokud existuje mnoho nezávislých úkolů a je plánováno k jejich provádění po určitých intervalech, je lepší se podívat na stranu OS. Třetí je také jasná, je mnohem snazší porozumět v samostatném úkolu než pro malování závislostí v hlavním cyklu. Pokud píšete ne sám, pak zde jsou zde výhody, pro každého může napsat svůj úkol odděleně, aniž by zasahoval do zbytku.

Kombinace výše uvedeného je rozsah použití zcela specifický v určitém rozsahu úkolů. Nenechte ho strkat do každého projektu. Pro většinu amatérských rádiových zařízení je osa nadbytečná, ale s ní má představu o ní, pravděpodobně ji lemoval pár projektů.

Nyní se podívejte pod kapotu. Chcete-li spustit MRTOS k projektu, musíte připojit MRTOS.c a mininly MRTOS.H. Struktura kódu je mírně odlišná od obvyklého

#Zahrnout. #Include "mrtos.h" // zde funkce těla, kde píšeme váš super kód VOID TASK1 () (zatímco (1) // Úkoly v jakémkoli operačním systému jsou postaveny na základě nekonečného cyklu { // Zde kód vašeho úkolu Odeslání; // Funkce správy plánovače } ; } // handler přerušení časovače 0 Přerušení [Tim0_ovf] void Timer0_ovf_isr (void) (char II; #asm ("CLI") tcnt0 \u003d 0x9c; inc_systime (); pro (II \u003d 0; II< init_tasks; ii++ ) if (tasks[ ii] .delay ) -- tasks[ ii] .delay ; #asm("sei") } void main(void ) { // inicializace periferie Init_mrtos (); // inicializace operačního systému // Zde vytvoříme hřiště (úkoly) 3 úkoly vytvořené zde Create_task (task1, 1, aktivní); // vytvořit úkol (název úlohy, prioritu, stav) Create_task (task2, 1, aktivní); Create_task (task3, 1, aktivní); Sheduler (); // Spustit plánovač Zatímco (1); )

#Zahrnout. #include "mrtos.h" // Zde tělo funkce, kde píšeme váš super kód void task1 () (zatímco (1) // Úkoly v jakémkoli operaci jsou postaveny na základě nekonečného cyklu (// zde Kód vašeho expedičního úkolu; // Funkce Správa plánovače přenosu);) // Proces přerušení časovače 0 přerušit void timer0_ovf_isr (neplatný) (char) (char II; #asm ("CLI") tcnt0 \u003d 0x9c; inc_systime (); pro (ii \u003d); 0; II.

Nyní více. Počet úkolů je uveden v MRTOS.H Defaines Apptasks N. Úkol je deklarován uvnitř TASK1 () () () () () () () () () () a podobně, uvnitř (1) nemusejí napsat nic, není nutné Chcete-li zavolat funkce, to vše udělá, že jste plánovač. Jak vidíte, že úkol se skládá z nekonečného cyklu, mělo by být normální a mělo by být, ale uvnitř úkolu musíte dát kontrolu nad plánovačem. Buď čekací funkce nebo expedice. Pokud to není provedeno, bude úkol proveden nekonečně.

Jak to funguje? Vytvořit blikání úlohy LED dioda.

Void Task1 () (zatímco (1) (portb.0 \u003d! Portb.0; počkejte (100););)

void Task1 () (zatímco (1) (portb.0 \u003d! Portb.0; počkejte (100););)

Počkejte je určitý analogový zpoždění () pouze během zpoždění mikrokontrolér nevykonává nic a jednotku prázdných cyklů. Během stejného počátku je ovládací prvek přenášen do jiných úkolů. Ty. Můžete vytvořit spoustu úkolů blikáním různých LED diod, s různým čekáním a všechny budou blikat s různými frekvencemi. Pokud zpoždění není nutná, pak na konci používá expedici.

Když používáte čekat, je důležité pochopit, že celý systém má minimální tic (kvantum času), takže čekáme, ne čekat (50) 50 milikaCunds, ale 50 teakový systém. Nastavení klíště závisí na tom, jak se často nazývá přerušení časovače, tj. Pokud jsme nakonfigurovali přerušení na 1ms, pak můžeme předpokládat, že naše akce je provedena za 1 ms. Experimenty ukázaly, že je možné snížit systém klíšťat na ~ 20 μs s hodinami 16 MHz.

Nastavení časovače se neliší v dříve studovaných, protože časovače má pouze přerušení přetečení, pak je pro něj vázána všechna nastavení. V nejnovějších verzích Cavr je velmi výhodné napsat časová požadavky, nastavení automaticky generuje.

Create_task (task1, 1, aktivní);

create_task (task1.1, aktivní);

S prioritami je vše docela nejen. Pokud existují dvě úkoly s různou prioritou a úkol s velkou prioritou se neustále provádí, pak nikdy nebudeme jít na úkol s nízkou prioritou. Proto musíte organizovat práci tak, aby všechny úkoly měly přístup. Squake pozornost na to nebudeme, sdílet příště. Stav úlohy, aktivní - začal, zastavení zastavení.

Takže pro ty, kteří chtějí jednoduše blikat LED:

#Zahrnout. #include "mrtos.h" void task1 () (zatímco (1) (počkat (1000); portb.0 \u003d! portb.0;)) // Časovač 0 Přetečení přerušení služby rutina Přerušení [Tim0_ovf] void Timer0_ovf_isr (neplatný) (char II; #asm ("CLI") tcnt0 \u003d 0xb2; inc_systime (); pro (II \u003d 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) ; // Časovač / počítadlo 0 inicializace // Hodiny Zdroj: Systémové hodiny // Hodnota Hodiny: 7,813 kHz tccr0 \u003d (0<< CS02) | (1 << CS01) | (1 << CS00) ; TCNT0= 0x83 ; // Časovače (s) / čítač (y) inicializace inicializace Timsk \u003d (0<< OCIE2) | (0 << TOIE2) | (0 << TICIE1) | (0 << OCIE1A) | (0 << OCIE1B) | (0 << TOIE1) | (1 << TOIE0) ; Init_mRTOS() ; create_task(task1, 1 , Active) ; Sheduler() ; while (1 ) ; }

#Zahrnout. #include "mrtos.h" void task1 () (zatímco (1) (počkat (1000); portb.0 \u003d! ; #Asm ("CLI") tcnt0 \u003d 0xb2; inc_systime (); pro (II \u003d 0; II

Jako bonus jsem se snažil udělat polyfonní (dvouhlavá) melodie "Dr.Mario Chill". Myšlenka je, že každá noha regulátoru je neustále invertována v samostatném tasque, čímž se vytváří frekvenci. Změna závěrky Můžete změnit výšku poznámek.

Void Task2 (void) (zatímco (1) (pokud (MUTE \u003d\u003d 0) // Je-li povoleno hrát (IF_CH2 [n_n] \u003d\u003d 0) // Pokud čekáte na pauzu, nic nehrajeme (Portb.4 \u003d 0; počkejte (5);) else (portb.4 \u003d! Portb.4; // Pokud to nezastaví, dotáhněte nohu požadovanou frekvencí Počkejte (poznámka_ch2 [n_n]); )))))

void Task2 (void) (void) (zatímco (1) (pokud (ztlumení \u003d\u003d 0) // Pokud máte povoleno přehrát (IF_CH2 \u003d\u003d 0) // Pokud čekáte na pauzu, nehrajeme nic (portb. 4 \u003d 0; počkejte (5);) else (portb.4 \u003d! Portb.4; // Pokud není pauza, pak s nohou s požadovanou frekvencí čekání (poznámka_ch2);)))

Neobtěžoval jsem se s myšlenkou, 1 tasque generuje meandr s frekvencí poznámek pro sólovou stranu, ve druhé pro basy. Výška každého nisku je převzata z polí. Trvání, přepínání a lámání v tasque3.

Void Task3 (void) (Wait (1) (počkejte (1500); // Přehrát minimální počet poznámek pro (mute \u003d 0; ztlumení< 500 ; mute++ ) // klikněte na poznámku, abyste nespojili (Portb.3 \u003d 0; portb.4 \u003d 0;); Mute \u003d 0; // Nastavte vlajku, kterou můžete přehrát zvuk n_n ++; // jít na další poznámku Pokud (n_n \u003d\u003d n_max) // Kdyby hráli všechno v kruhu (n_n \u003d 0;)))

void Task3 (Void) (Wait (1) (počkejte (1500); // Přehrát minimální dialita poznámek pro (Mute \u003d 0; Mute< 500; mute++) //обрываем ноту, чтобы не сливались { PORTB.3 = 0; PORTB.4 = 0; }; mute = 0; //выставляем флаг, что можно воспроизводить звук n_n++; //переходим на следующую ноту if(n_n == n_max) //если сыграли все то идем по кругу { n_n = 0; } } }

Pro míchání dvou kanálů použilo jednoduché schéma.

Celkový malý kousek

Pro ty, kteří chtějí firmware

Vyvinula jsem o něco více než 10 elektronických zařízení a byl zcela započítán v jejich nízkoúrovňové práci bez operačního systému. Situace se změnila, když funkce dalšího zařízení prudce rozšířila. Kromě toho došlo k potřebě úkolu, který se nazývá stanovené časové intervaly, a přesnost hovoru ovlivňuje výsledek. Stalo se také zřejmé, že to nebude fungovat vše pro přidělené čas, a bude vytvořen později. Po krátké reflexi jsem si uvědomil, že projekt musí obsahovat operační systém v reálném čase (ORVD nebo RTO).

Na rozdíl od PC, kde OS je více vrstva pro práci se systémovými prostředky, pro mikrokontrolér OSR - to je především plánovač úloh, ve skutečnosti hraje hlavní roli v "v reálném čase". V tuto chvíli je důležité, abych zajistil takzvaný "pseudo-paralelní" výkon úkolů. To znamená, že existuje několik úkolů se stejnou prioritou a je důležité způsobit jejich v daném pořadí ve stanovených časových intervalech.

Následující příklad byl vizuálně: V projektu Eurobot 2011 bylo v systému přítomno 18 periferních zařízení. 2 e-maily by mohly být sloučeny do jednoho. Jejich cena by se snížila, spolehlivost se zvýšila (snížila počet složek v systému), množství volného prostoru v případě zvýšil. Okolnost komplikuje skutečnost, že počet úkolů roste proporcionálně a zde již není prováděno bez operačního systému. OSR také pomáhá vyhnout se možnému prostoji procesoru, například během konverze ADC, můžete tento úkol zablokovat a provádět ostatní, čímž správně distribuuje provoz zařízení. Je také důležité, aby se zařízení nespadlo z důvodu selhání úlohy, místo toho je možné zachovat částečný výkon (i když to může vést k nepředvídatelným výsledkům). Vzhledem k tomu, co zajišťujeme růst těchto ukazatelů? Ve skutečnosti mačkáme všechny možné z MC, efektivně využívajícím výpočtovým schopnostem.

Po stručném vyhledávání, volba padla na FREERTOS. Toto Ord je distribuován ve zdrojovém kódu na C a porty do 27 architektur. Poslední okolnosti pro mě je rozhodující. Snížení nákladů práce při práci s MK jiných výrobců. Nyní se zajímám o přístav pro AVR.

Dostupnost Přehled FREERTOS v projektu jí asi 9,8 CB programů programů a 1,8 KB RAM. Například pro kompilátor ATMEGA32 a WinAVR je 60% a 85%, resp. 85%. Již pro tento model vytvořte zařízení s velkou funkčností obtížné - není dostatek paměti. Tento problém však zmizí při použití nových modelů AVR. Je zcela uražen pro MGA2560 s 256KB programů programů a 8 kB RAM. Tendence budoucí MK doprovází úspěch OSR.

Běží běžící na runetu, byl jsem překvapen, že zjistí, že v OS v Ruštině není dokumentace. Tak co je tady! Původní dokumentace platí pro dodatečné náklady. Situace zjednodušila článek Andrei Kurtica ( [Chráněný emailem]) Z časopisu "Komponenty a technologie". Podle dohody s autorem použiju článek v recyklované verzi. Jeho článek může sloužit jako dokumentace v ruštině. Originál však není v tisku nedostupný, místo časopisu leží, takže materiál bude muset trochu recyklovat. Obecně autor učinil vynikající článek a nemá smysl projít teorií znovu, bude zde plně zveřejněn. Původní článek bude připojen na konci publikace. Také jsem si všiml, že uživatelé měli potíže s kompilovat OSR. To je způsobeno tím, že se používá externí makefile, ve kterém jsou napsány cesty ke složkám. Proto aplikuji ready-made projekt ve formě šablony pro AVR Studio a Eclipse AVR. Bohužel, nativní makefile nevyvolává informace ladění, jako je míra zaměstnání paměti RAM a paměti programů, muselo fiktovat přidáním příslušné standardní výzvy.

Takže stručně o potřebě, ve vašem projektu je žádoucí použít OSR v případě potřeby:

Organizovat multisascy a alternativní úkoly

Poskytněte spuštění úkolu prostřednictvím přísně definovaných časových intervalů

Přenos informací z jednoho úkolu do druhého

Podle potřeby přidejte nové úkoly

Výhody OSRV před mNA:

  1. Multitasking. OSRV poskytuje programátor připraven, dobře odolný mechanismus. Každý úkol v jednoduchém případě lze naprogramovat samostatně, všechny práce je rozbité mezi několika členy týmu. Není třeba se postarat o přepínání mezi úkoly, to bude plánovač.
  2. Dočasná základna. Je nutné měřit časové intervaly. OSRV by měl mít tento nástroj. To vám umožní provádět akce prostřednictvím přísně vyhrazených časových intervalů.
  3. Výměna dat mezi úkoly. Za tímto účelem se v OSR používá fronta.
  4. Synchronizace. Pokud různé úkoly používají stejný zdroj, například sériový port, pak mohou být použity MutExes a kritické sekce. Pokud potřebujete provádět úkoly v přísné sekvenci nebo pokud dojde ke konkrétní události, můžete použít semafory nebo signály pro synchronizaci úkolů.

Nevýhody OSRV.:

1. prudký nárůst potřeby programu implementovat jádro

2. Zvýšení požadované paměti RAM pro ukládání stoh každého úkolu, semaforů, front, mutexes a jiných objektů objektu Core objektů.

3. Zpoždění při přepínání mezi kontextovými úlohami.

PopisfREERTOS.:

Freertos je volný open source pevný v reálném čase OS. Přednostně napsané na C, ale tam jsou montážní vložky. Byl vyvinut real Time Engineers Ltd speciálně pro vestavěné systémy. Nedávno projekt "SAFERTOS" - vylepšená, zdokumentovaná, testovaná a minulá certifikace pro dodržování bezpečnostní normy IEC 61508 pro dodržení verzi IEC 61508. Německá společnost se v tomto projektu zabývala a nyní SAFERTOS se používá v leteckém průmyslu a lékařské technologii. K dispozici je také projekt OpenRTOS - komerční verze s zárukou výrobce.

Hlavní vlastnosti frertosu:

1. Plánovač podporuje 3 typy multitaskingu:

Obyčejný

Družstevní

Hybridní

2. Velikost jádra je 9,8 kb v kompilované formě pro AVR. (Winavr)

3. Základem jádra - 4 souborů na C.

4. Podporuje úkoly a kopium. Dopravníky jsou speciálně vytvořeny pro MK s malým objemem RAM.

5. Bohaté možnosti tras.

6. Je možné sledovat přetečení zásobníku.

7. Žádná omezení softwaru na počtu současně provedených úkolů.

8. Žádná omezení počtu priorit úkolů.

9. Některé úkoly lze přiřadit stejnou prioritu.

10. Vyvinuté nástroje pro synchronizaci úkolů "a" přerušení problému ":

Fronty

Binární semafor

Účty Semafores

Rekurzivní semafory

Mutexes.

11. Mutexes s prioritou dědictví.

12. Podpora modulu ochrany paměti pro CORTEX-M3

13. Dodáváno v dluhu s demo projekty pro různé platformy a kompilátory.

14. Zdarma. Můžete použít v projektech bez zveřejnění zdrojového kódu v souladu s rozšířenou licencí GPL.

15. Placená dokumentace, ale je k dispozici online zde.

16. Kontextová doba přepínání AVR s křemenem na 16 MHz bude pouze 20,8 μS. Je to mnohem nutné uložit data do zásobníku úkolu a volání následující. (Zajímavá poznámka, pokud ji porovnáte s pic18xxx, regulátor z avr to rychleji 4 krát !!!, s největší pravděpodobností je to způsobeno kvalitou kompilátoru)

Přestěhování multitasking znamená, že úkol s nízkou prioritou se překrývá hotový úkol s vyšší prioritou. Přepínání mezi úlohami se vyskytuje prostřednictvím stejného času kvanta. Proto před zahájením úlohy inteligence spustí provedení, aktuální kvantum času by mělo skončit, když se provádí s nízkou prioritou.

Doba reakce FREERTOS na vnějších událostech v režimu posunutí multitaskingu tedy není více než jeden plán plánovače kvanta, která může být zadána v nastavení. Ve výchozím nastavení se rovná 1 ms.

Pokud jste připraveni na provádění několika úkolů se stejnou prioritou, pak v tomto případě plánovač přiděluje každou z nich jedním množstvím času, po kterém kontrola obdrží následující úkol se stejnou prioritou a tak dále v kruhu.

COOPERATIVNÍ Multitasking se liší od vysídlení plánovače nezávisle nemůže přerušit provádění aktuálního úkolu, dokonce dokončena k provedení úkolu s velkou prioritou. Každý úkol musí samostatně převést správu plánovače. Úloha s vysokou prioritou se očekává, dokud nízká priorita nedokončí svou práci a dává správu plánovače. Doba reakce systému na externí událost se stává neurčitou a závisí na tom, jak dlouho bude aktuální úkol proveden před kontrolou. Kooperativní multitasking byl použit v rodině Windows 4 OS.

Posunutí a kooperativní koncept multitaskingu je kombinován společně v hybridním multitaskingu, když se objeví volání Challenger každý kvantový čas, ale na rozdíl od vysídleného multitaskingu má programátor schopnost provést to v těle úkolu. Tento režim je zvláště užitečný, pokud je nutné snížit dobu odezvy systému pro přerušení. Předpokládejme, že se provádí aktuálně úloha s nízkou prioritou a vysoce priorita čeká na určité přerušení. Dále nastane, ale po ukončení obslužného programu přerušení se provádění vrátí do aktuálního úkolu s nízkou prioritou a vysoce prioritou očekává aktuální čas kvantum. Pokud však po provedení obslužného programu přerušení přeneste řízení plánovače, přenáší ovládací prvek úlohy s vysokou prioritou, která snižuje dobu reakce systému spojenou s externí událostí.

Pročnapovídat sib?

Můžete začít vyvíjet mikrokontrolér zařízení spuštěnou FREERTOS, z načtení jeho nejnovější verzi.

Distribuce FREERTOS je k dispozici jako obyčejný nebo samorozbalovací archiv ZIP. Distribuce obsahuje přímo kód jádra (jako více souborů záhlaví a zdrojových souborů) a demonstrační projekty (jeden projekt pro každé rozvojové prostředí pro každý port). Dále byste měli rozbalit archiv na jakémkoliv vhodném místě na vývojové stanici.

Navzdory poměrně velkému počtu souborů v archivu je struktura adresářů skutečně jednoduchá. Pokud plánujete navrhnout zařízení pro 2-3 architektury v rozvojových prostředích 1-2, většina ze souborů týkajících se demonstračních projektů a různých vývojových prostředích nebude zapotřebí.

Podrobná struktura adresáře je uvedena na opravě.

Celý zdrojový kód jádra je ve zdrojovém adresáři.

Obsah:

1.tasks.c. - implementace mechanismu úkolu, plánovač

2. queue.c. - implementace nemovitostí

3. listina.c. - Interní potřeby plánovače však mohou být funkce použity v aplikačních programech.

4. Croutine.c. - Provádění spamu (může být nepřítomně, pokud nejsou dopravníky používány).

Soubory záhlaví, které jsou v adresáři Zdroj / včetně.

1. Tasks.h, queue.h, tist.h, croutine.h - Soubory záhlaví, resp. Pro soubory kódu stejného jména.

2. FREERTOS.H. - Provádět předprocesorové směrnice pro konfiguraci kompilace.

3. mpu_wrapers.h. - Obsahuje přepsání funkce rozhraní programu (API funkce) FREERTOS pro podporu modulu ochrany paměti (MPU).

4. Portable.h.-plappo-závislé nastavení.

5. PROJDEFS.H.-Hextujte definice systému

6. Semphr.h. - Definuje funkce API pro práci s semaforemi, které jsou implementovány na základě front.

7. Stackmacros.h. - Obsahuje makra pro monitorování přetečení zásobníku. Každá hardwarová platforma vyžaduje malou část základního kódu, která implementuje interakci FREERTOS s touto platformou. Celý kód závislý na platformě je v podadresáři / Zdroj / přenosnýTam, kde je systematizovaná, ale vývojová prostředí (IAR, GCC atd.) A hardwarové platformy (například ATMELSAM7S64, MSP430F449). Například podadresář / Zdroj / přenosný / gcc / atmega323 Obsahuje port.c a portmacro.h Soubory, které implementují / obnovují kontext úlohy, inicializujte časovač k vytvoření dočasné databáze, inicializovat zásobník každého úkolu a jiných funkcí závislých na hardwaru pro mikrokontroléry rodiny Mega Avr a WinAVR kompilátor (GCC).

Odděleně je nutné zvýraznit podadresář / Zdroj / přenosný / memmangkterý obsahuje soubory heap_l.c, heap_2.c, heap_3.cImplementace 3 různých mechanismů alokace paměti pro potřeby FREERTOS, které budou podrobněji popsány později.

Adresář / demo je připraven k kompilaci a demonstračních projektů montáže. Celková část kódu pro všechny demonstrační projekty je zvýrazněna v poddrelektory / Demo / komon.

Chcete-li používat FREERTOS ve svém projektu, musíte povolit zdrojový kód zdrojového kódu jádra a přidružených souborů záhlaví. Není třeba je upravovat nebo pochopit jejich realizaci.

Například, pokud plánujete použít port pro MSP430 mikrokontroléry a kompilátor GCC, pak vytvořit projekt - nula "bude zapotřebí podadresářem / Zdroj / přenosný / gcc / msp430_gcc a / Zdroj / přenosný / memmang. Všechny ostatní podadresáře z adresáře / zdroj / přenosný adresář není potřeba a lze jej odstranit.

Pokud je plánováno upravit existující demo projekt (což se ve skutečnosti doporučuje udělat na začátku studia FREERTOS), pak budete potřebovat podadresář / Demo / msp430_gcc a / Demo / Common. Zbytek podadresáře v / demo není nutný a může být odstraněn.

Při vytváření aplikace se doporučuje použít makefile. (nebo rozvojový soubor rozvojového prostředí) z odpovídajícího demonstračního projektu jako výchozí bod. Doporučuje se vyloučit ze souborů sestavy (sestavovat) z adresáře / demo, nahrazení vlastními vlastními soubory a soubory z adresáře / zdrojů jsou neporušené. Také zmínit také o souboru záhlaví Frertosconfig.h.který se nachází v každém demonstračním projektu. Freertosconfig.h obsahuje definice (#define), což umožňuje nastavení jádra FREERTOS:

1. Sada systémových funkcí.

2. Pomocí SPRAM.

3. Počet úkolů a staveb

4. Velikost paměti (zásobník a hromady).

5. Hodinová frekvence MK.

6. Doba provozu plánovače času přidělené každému úkolu provedení, která je obvykle rovnající se 1 ms. Zakázání některých systémových funkcí a snížení počtu priorit (snižuje spotřebu paměti).

Distribuce FREERTOS je také součástí nástrojů pro převod informací o trasování přijatých z plánovače, v textovém formuláři (adresář) / Tgssun.) a text licence (adresář / Licence.).

závěry

S pomocí prvního článku cyklu se čtenář seznámil s operačním systémem pro FREERTOS LA Microcontrollers. Zobrazující funkce práce. Popsal obsah distribuce FREERTOS. Hlavní kroky, ze kterých by měl být spuštěn vývoj zařízení spuštěného FREERTOS.

V následujících publikacích bude pozornost věnována mechanismu multitaskingu, konkrétně úkolů a dopravníků. Vzorek plánovače bude vzorek pomocí mikrokontroléry ATMEL AVR a kompilátoru WinAVR (GCC).

Neustále žádám o tuto otázku během vašeho koníčka, - vývoj domácího systému automatického řízení (inteligentní domov) založený na 16bitovém mikrokontroléru, je tento opravdový přístup? Před měsícem a půl před půl, jsem již napsal v mém blogu na téma "Mikrokontroléry proti systémům-on-chipu". Takže o tom bude psát znovu.

Částečně to bylo vyvoláno vzhledem Stellaris Launchpad a Arduino splatné. Oba jsou založeny na 32bitových mikrokontrolérech, a v mnoha ohledech jsou velmi podobné. Studoval jsem specifikaci (datasheet) jak oba, a přestože jsou slušně odlišní v ceně, jsou určeny pro jednu cílovou skupinu. Přemýšlel jsem o tom, co jsem mohl pohybovat s MSP430 na Stelllaris, a to může být dokonce převedeno do zásadně jiného systému, používat něco jako malina pi, místo mikrokontrolérů.

Oba, Stelllaris LaunchPad a Arduino splatné jsou velmi silné, ale nejsou určeny k provozu Linuxu. Provozují buď na spustitelném kódu, který je napsán přímo pro ně, nebo běží operačního systému v reálném čase (RTOS), - Minimalistické OS, s velmi krátkou dobou odezvy na externí události. Také jsou oba mnohem komplikovanější než MSP430 nebo 8-bit AVR.

Na druhou stranu, v reálném životě (v zahraničí), většina z nich vím, používat malinové pi nebo jiné vestavěné systémy na linuxu. Použití mikrokontrolérů, spíše vzácného případu, mezi ty, které jsem se setkal. Dokonce i Arduino, mnohem méně populární v mém okolí než vestavěný Linux. Jak to chápu, je to důvod, proč si koupit Arduino k někomu, když si můžete koupit malinový pi, což může být mnohem více, a stojí za to stejné nebo méně? Pod Linuxem je obrovské množství hotového softwaru a lze jej naprogramovat pomocí jednoduchých skriptovaných jazyků.

Pro mě osobně, důvod, proč nechci používat Linux, je proto, že ho používám denně v práci, a návratu domů, nemám rád radost z potřeby pracovat znovu na systémech Linux. Nemám problémy s Linuxem, ale je to příliš všude, utlačuje mě. Je pro mě mnohem zajímavější pracovat s jednoduchými elektronickými zařízeními na 8/16-bitových mikročipech.

Nicméně, neodvrátím od reality. Pokud chci zůstat na stejné vlně se skutečným světem, musím použít tyto nástroje, které se používají v reálném světě. Jinak to vypadá jako touha řídit auto s parním motorem, pouze proto, že vnitřní spalovací motor je příliš vtipný, používám to po celou dobu. Pokud svět po celém světě jde do pokročilejší technologie, musíte ho zvládnout, líbí se mi to nebo ne. Zejména pokud chci, aby můj blog měl zájem o lidi a zůstal relevantní.

V mém projektu SMART HOME, opravdu jsem se setkal s tímto problémem. Už jsem udělal místní síťový ovladač pro řídicí systém na MSP430 a všechno vypadá velmi hodné. V podstatě můžu udělat vše, co potřebujete pro automatizační systém na MSP430. Přesto přemýšlím o tom, zda to dělám? Snažím se, jestli je vidlice polévka, když je lžíce? Možná Linux je správnější systém? Nech mě to vysvětlit.

Pokud se zastavíte a podívejte se na aktuální situaci, podle technologických pokroků v listopadu 2012. Ptám se sám sebe, jsou mikrokontroléry jsou dobří a relevantní a jsou relevantní ve srovnání s systémy na čipu pomocí Linuxu?

Pokud uvádíte projekty na vestavěných systémech, které se ke mně přicházejí v hlavě, je: Drones, roboty, domácí automatizace, řadiče motory, senzory, náramkové hodinky, 3D tiskárny atd. Ve které z těchto případů je vestavěný Linux vhodný více než mikrokontroléry? A proč?

Myslím si, že existují tři situace, kdy je mikrokontrolér tou nejlepší volbou: kde je instantní (realtime) důležitý pro události; kde je nutné extrémně nízkou spotřebu energie; A kde potřebujete používat čipy co nejnižší.

Chcete-li začít, používání levných žetonů, ne tak důležité pro mě. Jsem zapojen do mého koníčky pro sebe a nebudete nikdy vyrábět konkurenční produkty. Nemusím přemýšlet o převodu výroby do rostliny, který využívá otrokářskou práci, aby měl konkurenceschopnou cenu pro drobné projekty, které si přeji. Byl bych rád, kdybych mohl, rozbalím více než jednu desku denně, díky svým schopnostem!

Například pro projekt chytrého domova mohu vyvíjet, dálkově řízený spínač. To může zapnout / vypnout světlo nebo něco jiného. Zároveň můžu jít do místního obchodu elektrotechniky a koupit totéž za 20 dolarů, vyrobený v Číně. Mohu tuto cenu někdy zabít, snaží se prodat svůj vlastní přepínač? Nemyslím si, že je to možné.

Pokud si o tom myslíte, platí také pro soubor dalších věcí nezbytných pro domácí automatizaci. Teplotní senzory, kouř, pohyb atd., Jsem docela schopný dělat to samé, ale je nepravděpodobné, že můžete získat finanční výhody. Kdo se stará o nákup takových věcí za $ 75, když je mohou najít za 20 dolarů v domácích potřebách?

Pokud přemýšlejeme o extrakci nějakého druhu přínosů z vašeho koníčka, je lepší věnovat pozornost dražším a komplexním produktům. Například regulátor domácí automatizace nebo termostat, obvykle stojí více než 100 dolarů, a ponechat více svobody pro individuální tvořivost, můžete postavit jeden, prodat své sousedy a dokonce vydělat něco na něm.

Ale touha dosáhnout ziskové ceny konečného zařízení neznamená, že potřebujete použít nejlevnější mikrokontrolér na Zemi. Ve skutečnosti je to špatný nápad, protože Doba vývoje dělá stejné náklady, stejně jako použité části. Možná, že mikrokontrolér je levný, ale vyžaduje více času napsat řídicí kód. Čas je peníze, a pokud pracujete rychleji, budete mít čas na dosažení více.

Všechny tyto úvahy, shrnout mě, že je výhodnější rozvíjet inteligentní domácí systém na Linuxu než na mikrokontrolérech, navzdory mým osobním preferencím, nepoužívejte Linux (Líbí se mi s nízkou úrovní programování více než skripty, Linux mě znudíšen).

Pokud se vrátíte k tématu tématu, cena mikrokontrolérů, může to být důležitým faktorem pro velké korporace, které budou vydávat nový produkt, ale na individuální úrovni, pokud se pokusíte provádět podnikání ve stylu kickstarter, tento faktor je Už není tak významný ve skutečnosti, rychlý vývoj vývoje, důležitější než náklady na komponenty.

Na druhé straně mohou být mikrokontroléry nejlepší volbou než systém-on-čip, když je nutná nízká spotřeba energie. V takových systémech existují dva body: nízká spotřeba samotného diagramu, během provozu a krátký čas začátku. Typický způsob, jak ušetřit baterii pro malá zařízení, je samo-vypínání (vypnutí). Když vypnete počítač na Linuxu, potřebuje slušný čas se vrátit do práce, někdy až několik minut. Tato doba není přijatelná pro vložené systémy.

Pokud vezmete takový mikrokontrolér jako MSP430, pak může pracovat několik let od jedné baterie. Stellaris Launchpad a Arduino splatné, v zásadě, totéž je schopna takové, konzumují více energie než MSP430, ale stále jen velmi málo, ve srovnání s malinovou pi. Také MSP430, může okamžitě začít po vypnutí.

Jsem tak naprosto přesvědčen, že ve všech situacích, kdy jsou potřeba nízkonapěťové operace, má smysl použít mikrokontroléry. Existuje velký počet rozmanitých zařízení pracujících na bateriích, kde vzniká taková potřeba.

Ve třetím případě, jak jsem řekl, použití mikrokontroléru je smysluplnější než Linux, v operacích vyžadujících okamžitou reakci (reakce v reálném čase). Mám na mysli taková zařízení jako 3D tiskárny a CNC stroje, vím, o čem mluvím, protože jsem věnoval spoustu času studovat. Podle přírody vyžadují vysokou přesnost v práci, což je o něco menší, než zcela závisí na době odezvy na příkazy.

Pokud máte například, pokud máte kruhovou pila, která v tuto chvíli rozřezává kus dřeva nebo kovu, nemůžete tento proces zastavit, kvůli skutečnosti, že jej ovládá, trvá pauzu k vyřazení dat z paměti disk nebo něco jiného ve stejné žíly. Každý, kdo používal PC, je obeznámen s náhodným válcováním, periodicky vznikající během obvyklé práce. A nyní si představte, že máte velký vrtací stroj, běh počítač, který náhle začne kontrolovat aktualizace pro Windows během provozu, a vrták, vyvrtejte přes tabulku, na které stojí za to, protože to stojí za to Počítač ztratil kontrolu nad ním.

PC a on-chip systémy nejsou určeny k práci v reálném čase, přinejmenším s okny, a to i s Linuxem, ale sama o sobě se snaží přiblížit se k němu. Jako příklad existuje oprava v reálném čase pro Jádro Linuxu a speciální CNC software vytvořený pro tento druh. S tímto patch Linuxem nestačím a nevím, jak je flexibilní, dokončit události v reálném čase. Ale myslím, že to je jen možná alternativa, protože Linux, jakékoli skvrny padly na to, nikdy nebudou porazit mikrokontroléry v této oblasti v důsledku jejich přerušení systémů.
Závěrem se chci říct, že jsem strávil spoustu času snahou najít oblasti, kde využívá mikrokontroléry v mých projektech výhodu. A všechno vypadá jako éra světové nadvlády malinových pi a beaglebones. To je současná situace v komunitě DIY. Ve většině případů rychlejší a jednodušší rozvíjet v těchto systémech, takže je to často nejlepší volbou pro většinu projektů.

Pouze oblasti nízkonapěťových zařízení, provozu v reálném čase a nízkonákladová zařízení zůstávají pro mikrokontroléry.

To nezávisí na skutečnosti, že mikrokontroléry se mohou zdát více zábavy než PC. To je to, co bude muset přijít konkurovat.

Překlad z anglického původního příspěvku