Ahoj, HABR!
Dnes vám poviem o takej zaujímavej veci operačný systém Real Time (OSR). Nie som si istý, že to bude zaujímavé pre skúsených programátorov, ale myslím, že sa mi bude páčiť začiatočníkov.
Čo je OSR?
Ak sa pozrieme na Wikipédiu, uvidíme toľko ako 4 definície.Ak ste krátko povedali, OSR je operačný systém, ktorý reaguje na externé udalosti v určitom časovom období. Odtiaľ môžeme pochopiť hlavného účelu OSR - Zariadenia, v ktorých je potrebná rýchla reakcia na udalosti (ale v žiadnom prípade nebudú zamieňať prácu OSR s prerušeniami).
Prečo ju potrebujeme?
To je dosť dôvodov.Po prvé, OSRV podporuje multitasking, priority semaforov procesov a oveľa viac.
Po druhé, je veľmi jednoduché a takmer nevyžaduje zdroje.
Po tretie, všetky vyššie uvedené môžeme dostať takmer na akúkoľvek žľazu (napríklad Freertos beží aj na 8-bitovom attegu).
No, štvrté: Len hrať sami a vychutnať si.
Prehľad 3 známych OSR.
Pozor: potom ide o môj osobný názor.Freertos.
Jeden z najobľúbenejších OSRS dnes. Na obrovské množstvo železa. Oficiálne stránky.prostý
1) ZADARMO2) Portované veľký počet žľaza
3) Výkonná funkcia
4) Existujú rôzne knižnice: grafika, internet a viac.
5) Dobrá dokumentácia.
Móda
1) celkom komplexný proces portingu na nové železo.Záver: Je to naozaj profesionálne zdieľanie s dobrou dokumentáciou. Bude to dobré pre začiatočníkov, ak má port už port.
Keilrtx.
Donedávna bola táto OSRV komerčné, ale nedávno sa otvorila. Pracuje len na architektúre. Oficiálne stránky.prostý
1) ZADARMO2) ľahko porty do nového železa (v architektúre ARM).
3) Existujú rôzne knižnice: grafika, internet a iné.
Móda
1) Práca v Keil je takmer neskutočná2) Malé orezané funkcie
3) Podporované je len rameno.
4) (Na osobnej skúsenosti) stráca mnoho druhov rýchlosti.
Záver: ideálny pre začiatočníkov a malých projektov.
uC / OS.
Výkonné komerčné zdieľanie. Webové stránky.prostý
1) Obrovské množstvo funkcií a knižníc.2) Podporuje veľa železa
Móda
1) komerčné.2) Protectiv.
Záver: Môžete ho zavolať na nováčik s veľkým úsekom.
Ostatné zaujímavé OSRV
RTLINUX OSRVS na základe obyčajného Linuxu.QNX OSRV na základe UNIX.
Vývojové funkcie pomocou OSRV
No, po prvé, je potrebné pochopiť nasledovné: DRA nie je Windows. Nie je možné nainštalovať. Tento systém je jednoducho zostavený s vaším programom.Pri písaní programov s OSR sa funkcie nepoužívajú v ich obvyklom porozumení. Namiesto funkcií sa používajú procesy (alebo semenníky). Skutočnosť, že procesy, na rozdiel od funkcií, sú nekonečné cykly a nikdy neskončí (ak to nie je niekto alebo nie je zabiť - to znamená, že vykladanie z pamäte).
Ak je zahrnutých niekoľko procesov, OSR ich prepne, vydáva čas a zdroje. To je miesto, kde sa koncepcia priority procesu vzniká, ak tieto dva procesy potrebujú jednorazový čas motora, OSR ho dá, ktorý má väčšiu prioritu.
V OSRV existujú zvláštne funkcie oneskorenia - aby čas zbytočne nezmizne v čase oneskorenia jedného procesu, druhá sa vykonáva.
Poďme teraz hovoriť o takej veci, ako je semafor - táto vec, ktorá kontroluje prístup žiadosti o zdroje aplikácií. Pre každý zdroj je marker - keď proces potrebuje zdroj - to trvá a používa tento zdroj. Ak nie je žiadny marker, proces bude musieť počkať, kým sa vráti. Uvediem príklad: rôzne procesy posielajú informácie o jednej UART. Ak by nebol semafor, poslali bytes zase a boli bytou. A tak prvý proces vzal marker na UART poslal správu a dal druhú (a tak - do nekonečna).
Ďalšie knižnice OSR.
OSRV často ponúka rôzne knižnice pre prácu, napríklad s grafikou, internetom atď. Sú naozaj pohodlné a nemali by byť nútení používať ich. Pamätajte však, že bez OSR, pre ktoré sú napísané, nebudú fungovať.Tu sú príklady:
Pre rtx
Čo príde na myseľ, keď počujete operačný systém? Určite okná, Linux, makro .. alebo niečo také. TRUE, A TÝKAJÚCE SA OTÁZKA, PREČO POTREBUJE, PREHRÁVAČOVAŤ, KTORÁ SAŤ SAŤ SIVÁLNY: Počúvajte hudbu, hrajte hru (na internete!), Hovoriť s druhým na Skype. Zároveň, uvažuje o LED bliká, pričom dostal bajt z yuart \u003d).
A ak vykopáte hlbšie, potom počúvajte hudbu, odosielanie údajov cez internet je všetky jednotlivé procesy, a pretože máme jeden procesor, potom v rovnakom čase môže vykonať iba jednu úlohu. Preto sa úlohy vykonávajú striedavo v malých "častiach", podstata operačného systému to robí nepozorovane pre užívateľa: takže zvuk nie je chrapľavý a bicyketika spieva a všetko funguje súčasne. Zároveň, ak jedna z úloh bude "zavesiť", potom všetko ostatné pokračovalo v práci.
Ak spadnete všetky extra buchty a nechať nahú essenciu, potom prvý z operačného systému, to je len časovač, ktorý počíta rovnaké intervaly, a sám, bez toho, aby sa účasť používateľa, prepne medzi úlohami, vykonáva časť a znova vypne. Je tiež potrebné zvážiť, že väčšina úloh nemusí mať čas dokončiť v jednom kvantóne času, takže musíte ušetriť stav úlohy v čase prechodu na iný, a nabudúce na obnovenie stavu premenných . Riadenie všetkého je to Plánovač úloh.
Existujú dva hlavné typy OS: vysídlenie a družstev. V prvom prípade bude prepnutie medzi úlohami "tvrdé", t.j. Ak je kvantón času 1MS, potom prvá úloha bude vykonaná presne 1MS, potom druhý presný 1 ms, atď. Takéto osi sa nazývajú v reálnom čase (ORVD). Družstvo je trochu jednoduchšie, samotný proces musí povedať, že "bol vykonaný", preto nie je možné ich priradiť.
Rýchly výslovný AVR nebude fungovať, pretože malý počet RAM. Zo dostupných možností pre družstiev som bol priťahovaný MRTO, môžete si prečítať podrobnosti o tomto systéme na internetovej stránke autora (ľahko googles). hlavný dôvod Jeho použitie je jednoduchosť, prítomnosť verzie pripravenosti pod Cavr, na pochopenie všeobecné zásady Najviac.
Takže hlavné otázky zostali, prečo a kedy aplikovať os. Teoreticky, všetky to isté, čo robíte s osou, môžete ho prejsť bez neho, pre zdroje sú rovnaké. Zo skutočnosti, že ho prijmete na projekt, Megahertz v priestore nebude vzlietnuť, železo zostane rovnaké, preto zdroje sú rovnaké.
Preto by ste sa mali pýtať niekoľko otázok:
1. Môžete riadiť kompetentné zdroje?
2. Nemalo by to vymyslieť rovnaký bicykel v procese písania firmvéru?
3. Koľko čítate svoj kód? Ste schopní otvoriť ho za pol roka starý a ísť von?
4. Píšete alebo skupina?
Je ťažké dať odpoveď na prvú otázku, pretože všetko závisí od značiek developera. S druhým je všetko pochopiteľnejšie, ak existuje mnoho nezávislých úloh a plánuje sa ich vykonávať po určitých intervaloch, je lepšie pozrieť sa na stranu OS. Tretie je tiež jasné, je oveľa jednoduchšie porozumieť v samostatnej úlohe, než aby sa vysporiadali závislosti v hlavnom cykle. Ak napíšete nie sám, potom tu sú výhody, pretože každý môže napísať svoju úlohu samostatne, bez toho, aby zasahovali do zvyšku.
Kombinácia vyššie uvedeného, \u200b\u200brozsah aplikácie je v rámci určitej škály úloh pomerne špecifický. Nesnažte ho na každý projekt. Pre väčšinu amatérskych rádiových zariadení je os nadbytočná, ale mať jej predstavu predtým, pravdepodobne jej lemovala niekoľko projektov.
Teraz sa pozrite pod kapotou. Ak chcete spustiť MRTO do projektu, musíte pripojiť MRTOS.C a mincersky MRTOS.H. Štruktúra kódu je mierne odlišná od zvyčajného
| #Include. |
#Include. Teraz viac. Počet úloh je uvedený v Mrty.h Defaras apptasks N. Úlohou je vyhlásená za vnútornú úlohu1 () (), úlohy2 () () a podobne, vo vnútri (1) nemusíte nič písať, nie je potrebné Ak chcete volať funkcie, toto všetko urobíte, že ste plánovač. Ako vidíte, že úloha pozostáva z nekonečného cyklu, malo by to byť normálne a malo by byť, ale vo vnútri úlohy, ktoré potrebujete na ovládanie o plánovači. Buď funkcia čakania alebo odoslania. Ak sa to nerobí, úloha sa vykoná nekonečne. Ako to funguje? Vytvorenie Blikajúceho úlohy LED. neplatná úloha1 (zatiaľ čo (1) (portb.0 \u003d! Portb.0; počkajte (100););) Počkajte len určité oneskorenie () Analóg, počas oneskorenia Mikrokontrolér nevykonáva nič a riadi prázdne cykly. Počas toho istého počkania sa kontroluje na iné úlohy. Tí. Môžete vytvoriť veľa úloh blikaním rôznych LED diódy, s rôznymi čakaním a všetkými z nich budú blikať s rôznymi frekvenciami. Ak nie sú potrebné oneskorenia, potom na konci používajú odoslanie. Pri použití čakania je dôležité pochopiť, že celý systém má minimálnu TIC (Quantum of time), takže čakáme, že nebudeme čakať (50) 50 miliicokov, ale 50 teakových systémov. Nastavenie začiarknutia závisí od toho, ako sa často nazýva prerušenia časovača, t.j. Ak sme nakonfigurovali prerušenie 1MS, potom môžeme predpokladať, že naša činnosť je vykonaná pre 1 ms. Experimenty ukázali, že systém je možné znížiť na ~ 20 μs s hodinami 16 MHz. Nastavenie časovača sa nelíši v predchádzajúcom študovanom, pretože Timer0 má iba prerušenie pretečenia, potom všetky nastavenia sú viazané. V najnovších verziách CAVR je veľmi vhodné napísať časové podmienky, nastavenia automaticky vytvárajú. create_Task (úloha1,1, aktívna); S prioritami je všetko dosť nielen. Ak existujú dve úlohy s rozdielnou prioritou a úloha s veľkou prioritou sa neustále vykonáva, potom nikdy nebudeme ísť do úlohy s nízkou prioritou. Preto potrebujete organizovať prácu tak, aby všetky úlohy mali prístup. Pozornosť na to, že nebudeme, zdieľať nabudúce. Stav úlohy, Active - Začiatok, StopTask zastavil. Takže pre tých, ktorí chcú jednoducho blikať LED: #Include. Ako bonus som sa snažil urobiť polyfonickú (dvojvrstvovú) melódiu "Dr.Mario Chill". Myšlienkou je, že každá noha regulátora je neustále obrátená v samostatnom tasku, čím sa vytvára frekvencia. Zmena uzávierky Môžete zmeniť výšku poznámok. void TASK2 (prázdnota) (zatiaľ čo (1) (ak (MUTE \u003d\u003d 0) // Ak máte možnosť prehrávať (IF_CH2 \u003d\u003d 0) // Ak čakáte na pauzu, nehrajeme nič (portb. 4 \u003d 0; počkajte (5);) inak (portb.4 \u003d! Portb.4; // ak nie pozastavenie, potom s nohou s požadovanou frekvenciou čakania (note_CH2);)))) Neobťažoval som sa s myšlienkou, 1 tastám generuje meandru s frekvenciou poznámok pre sólovú párty, v druhej pre basy. Výška každého notického je prevzatá z polí. Trvanie, prepínanie a lámanie v Tasque3. neplatné úlohy3 (neplatné) (počkajte (1) (počkajte (1500); // Prehrávanie minimálnej diality poznámok pre (MUTE \u003d 0; MUTE< 500; mute++) //обрываем ноту, чтобы не сливались
{
PORTB.3 = 0;
PORTB.4 = 0;
};
mute = 0; //выставляем флаг, что можно воспроизводить звук
n_n++; //переходим на следующую ноту
if(n_n == n_max) //если сыграли все то идем по кругу
{
n_n = 0;
}
}
} Zmiešajte dva kanály jednoduchú schému. Celkový malý kúsok Pre tých, ktorí chcú firmvér Vyvinula som o niečo viac ako 10 elektronických zariadení a bola úplne účtovaná v ich nízkej úrovni práce bez operačného systému. Situácia sa zmenila, keď sa funkčnosť nasledujúceho zariadenia prudko rozšírila. Okrem toho bola potrebná úloha, ktorá sa nazýva podľa určených časových intervalov a presnosť hovoru ovplyvňuje výsledok. Taktiež sa objasnilo, že by to nefungovalo všetko pre pridelený čas, a to bude vytvorený neskôr. Po krátkom odraze som si uvedomil, že projekt musí obsahovať prevádzkový systém v reálnom čase (ORVD alebo RTO). Na rozdiel od PC, kde OS je viac vrstvou pre prácu so systémovými zdrojmi, pre mikrokontroller OSR - to je predovšetkým plánovač úloh, v skutočnosti hrá hlavnú úlohu v "reálnom čase". V súčasnosti je pre mňa dôležité zabezpečiť tzv. "Pseudo-paralelný" výkon úloh. To znamená, že existuje niekoľko úloh s rovnakou prioritou a je dôležité, aby sme ich spôsobili v danej objednávke v určených časových intervaloch. Nasledujúci príklad bol vizuálne: V projekte Eurobot 2011 bolo v systéme prítomných 18 periférnych zariadení. 2 e-maily by sa mohli zlúčiť do jedného. Ich náklady by sa znížili, spoľahlivosť sa zvýšila (znížil počet komponentov v systéme), množstvo voľného miesta v prípade zvýšilo. Táto okolnosť komplikuje skutočnosť, že počet úloh rastie úmerne a tu sa už neuskutoční bez OS. Tiež OSR pomáha vyhnúť sa možným prestojom procesora, napríklad počas konverzie ADC, môžete túto úlohu zablokovať a vykonávať ostatné, čím sa správne distribuuje prevádzku zariadenia. Je tiež dôležité, aby teraz zariadenie nespadlo kvôli zlyhaniu v úlohe, namiesto toho je možné zachovať čiastočný výkon (hoci to môže viesť k nepredvídateľným výsledkom). Vzhľadom k tomu, čo zabezpečíme rast týchto ukazovateľov? V skutočnosti stlačíme všetko možné z MC, efektívne využívame svoje výpočtové schopnosti. Po krátkom vyhľadávaní sa voľba padla na freertos. Tento Obj je distribuovaný v zdrojovom kóde o C a portoch na 27 architektúr. Posledná okolnosť pre mňa je rozhodujúca. Pri práci s Mk ostatných výrobcov zníži náklady práce. Teraz som záujem o prístav pre AVR. Dostupnosť prehľadu Freertos v projekte je asi 9.8 cb programov programov a 1,8 kB RAM. Napríklad pre ATMEGA32 a FORMAVR kompilátor je 60% a 85%. Už pre tento model vytvorte zariadenie s veľkou funkčnosťou je ťažké - nie je dostatok pamäte. Tento problém však zmizne pri používaní nových modelov AVR. Je úplne urazený pre Mega2560 s jeho 256kb programov programov a 8 kB RAM. Tendencia budúceho MK sprevádza len úspech OSR. Beh beží na ruke, bol som prekvapený, že na OS v ruštine nie je žiadna dokumentácia. Čo je tu! Pôvodná dokumentácia sa vzťahuje na dodatočné náklady. Situácia zjednodušila článok Andrei Kurtica ( [Chránené e-mail]) Z časopisu "komponenty a technológie". Na základe dohody s autorom použijem článok v recyklovanej verzii. Jeho článok môže slúžiť ako dokumentácia v ruštine. Originál však nie je k dispozícii v tlači, lokalita časopisu leží, takže materiál bude musieť trochu recyklovať. Všeobecne platí, že autor urobil vynikajúci článok a nemá zmysel prejsť teóriu znova, bude to tu plne publikované. Pôvodný článok bude pripojený na konci publikácie. Tiež som si všimol, že používatelia mali problémy s kompiláciou OSR. Je to spôsobené tým, že sa používa vonkajšie makefile, v ktorom sú písané cesty do priečinkov. Preto budem aplikovať hotový projekt vo forme šablóny pre AVR Studio a AVR Eclipse. Nanešťastie, rodná makefile nevyberie informácie o ladeniach, ako je stupeň zamestnania RAM a pamäti programov, musela byť fiktovať pridaním príslušnej štandardnej výzvy. Takže, krátko o potrebe, vo vašom projekte je žiaduce používať OSR v prípade potreby: Usporiadajte multišpeciálne a alternatívne úlohy Poskytnite spustenie úloh prostredníctvom striktne definovaných časových intervalov Prevod informácií z jednej úlohy na druhú Pridajte nové úlohy podľa potreby Výhody OSRV pred mNa: Nevýhody OSRV: 1. Osporný nárast potreby programu na implementáciu jadra 2. Zvýšenie požadovanej pamäte RAM na uloženie stohu každej úlohy, semaforov, frontov, mutexov a iných objektov objektov. 3. oneskorenie pri prepínaní medzi kontextovými konzervačnými úlohami. Popisfreertos.: Freertos je bezplatný open source tuhý v reálnom čase. Výhodne napísané na C, ale existujú montážne vložky. Bola vyvinutá inžiniermi v reálnom čase LTD pre vstavané systémy. Nedávno projekt "SAFERTOS" - zlepšil, zdokumentoval, testoval a minulú certifikáciu pre dodržiavanie bezpečnostnej normy IEC 61508 pre dodržiavanie verzie IEC 61508. Nemecká spoločnosť bola zapojená do tohto projektu a teraz sa používa v leteckom priemysle a lekárskej technike SAFERTOS. K dispozícii je aj projekt OpenRTOS - komerčná verzia s zárukou výrobcu. Hlavné charakteristiky Fertos: 1. Plánovač podporuje 3 typy multitaskingu: Obežník Družstevný Hybrid 2. Veľkosť jadra je 9,8 kB v zostavenej forme AVR. (Winavr) 3. Základňa súborov Core - 4 na C. 4. Podporuje úlohy a koprogramy. Dopravníky sú špeciálne vytvorené pre MK s malým objemom RAM. 5. Bohaté možnosti stopy. 6. Je možné sledovať pretečenie stohu. 7. Žiadne obmedzenia softvéru na počte súčasne vykonaných úloh. 8. Žiadne obmedzenia týkajúce sa počtu priorít úloh. 9. Niektoré úlohy môžu byť priradené rovnakou prioritou. 10. Vyvinuté nástroje na synchronizáciu "úlohy úloh" a "prerušenie problému": Fronty Binárne semafor Semafory účtov Rekurzívne semafory Muškátový 11. Mutexy s prioritným dedičstvom. 12. Podpora modulu ochrany pamäte pre CORTEX-M3 13. Dodáva sa v dlhu s demo projektmi pre rôzne platformy a kompilátory. 14. ZADARMO. Môžete použiť v projektoch bez zverejnenia zdrojového kódu v súlade s rozšírenou licenciou GPL. 15. Platená dokumentácia, ale je k dispozícii online. 16. Kontextový spínací čas pre AVR s kremeňom na 16 MHz bude len 20,8 μs. Je to potrebné na uloženie údajov do zásobníka úloh a zavolajte nasledovne. (Zaujímavá poznámka, ak ho porovnáte s PIC18xxx, regulátor z AVR je rýchlejší 4-krát !!!, S najväčšou pravdepodobnosťou je to spôsobené kvalitou kompilátora) Premiestnenie multitasking znamená, že úloha s nízkou prioritou je prekrývajúca sa pripravenou úlohou s vyššou prioritou. Prepínanie medzi úlohami nastáva cez rovnaký čas. Preto predtým, ako spravodajská úloha spustí realizáciu, súčasný kvantón času by mal skončiť, keď sa vykoná nízka priorita. Čas freertos reakcie na externých udalostiach v režime vytesňovania multitasking nie je teda viac ako jeden časový limit, ktorý môže byť zadaný v nastaveniach. V predvolenom nastavení sa rovná 1 ms. Ak ste pripravení na vykonanie niekoľkých úloh s rovnakou prioritou, potom v tomto prípade plánovač prideľuje každý z nich jeden kvantový čas, po ktorom kontrolu prijíma nasledujúcu úlohu s rovnakou prioritou, a tak ďalej v kruhu. Družstvo Multitasking sa líši od vysídlenia Planner nezávisle nemôže prerušiť vykonanie súčasnej úlohy, dokonca dokončená na vykonanie úlohy s veľkou prioritou. Každá úloha musí nezávisle preniesť správu plánovača. Úloha s vysokou prioritou sa preto očakáva, až kým sa nízka priorita dokončí svoju prácu a dáva správu plánovača. Systémový reakčný čas na externú udalosť sa stane neurčitým a závisí od toho, ako dlho bude aktuálna úloha vykonaná pred kontrolou. Družstvo Multitasking sa použil v rodine Windows 4 OS. Posunutie a kooperatívna koncepcia multitaskingu sa kombinuje spolu v hybridnom multitaskingu, keď nastáva výzva Challenger každý kvantovaný čas, ale na rozdiel od vytesňovacieho multitaskingu má programátor schopnosť robiť to nútené v tele úlohy. Tento režim je obzvlášť užitočný, keď je potrebné znížiť čas odozvy systému na prerušenie. Predpokladajme, že v súčasnosti sa vykonáva úloha s nízkou prioritou a vysoká priorita čaká na určité prerušenie. Ďalej sa vyskytuje, ale po ukončení ručného rušenia sa bude vykonanie vráti do aktuálnej úlohy s nízkou prioritou a vysoká priorita očakáva, že aktuálny čas kvantózy. Avšak, ak po vykonaní ručného rušenia, preneste kontrolu plánovača, bude prenášať kontrolu s vysokou prioritnou úlohou, ktorá znižuje systém reakcie systému spojený s externou udalosťou. Prečonachatb? Zariadenie mikrokontroléra môžete začať spúšťať freertos, z načítania jeho najnovšej verzie. Distribúcia freertos je k dispozícii ako obyčajný alebo samoobslužný zips. Distribúcia obsahuje priamo kódu jadra (ako viac súborov hlavičky a zdrojové súbory) a demonštračné projekty (jeden projekt pre každé vývojové prostredie pre každý port). Ďalej by ste mali rozšíriť archív na akomkoľvek vhodnom mieste na vývojovej stanici. Napriek pomerne veľkému počtu súborov v archíve je štruktúra adresárov skutočne jednoduchá. Ak plánujete navrhnúť zariadenia na 2-3 architektúry v 1-2 vývojových prostrediach, väčšina súborov týkajúcich sa demonštračných projektov a rôznych rozvojových prostredí nebude potrebná. Podrobná štruktúra adresára je uvedená na náplasti. Celý zdrojový kód jadra je v adresári / zdroj. Obsah: 1.Tasks.c. - Implementácia mechanizmu úloh, Plánovač 2.
qUEUE.C. - Implementácia majetku 3.
lIST.C. - Vnútorné potreby plánovača však môžu byť použité v aplikačných programoch. 4. CROUTINE.c. - Implementácia rozpremu (môže byť neprítomné, ak sa dopravníky nepoužívajú). Súbory hlavičky, ktoré sú v adresári Zdroj / vrátane.
1. TASKS.H, QUEUE.H, TIST.H, CROUTINE.H - Súbory hlavičky, resp. Pre súbory kódu rovnakého mena. 2. Freertos.h. - vykonávať smernice predprocesora na konfiguráciu kompilácie. 3. MPU_WRAPPERS.H. - Obsahuje prepíše funkcie programového rozhrania (API Funkcie) Freertos na podporu modulu ochrany pamäte (MPU). 4. Prenosné.-Plappo závislé nastavenia. 5. PROJDEFS.H.-Zobraziť definície systému 6. SEMPHR.H. - Definuje API funkcie pracovať s semaformi, ktoré sa vykonávajú na základe frontov. 7. Stackmacros.h. - obsahuje makrá na monitorovanie pretečenia zásobníka. Každá hardvérová platforma vyžaduje malú časť základného kódu, ktorá implementuje freertos interakciu s touto platformou. Celý kód závislý od platformy je v podadresári / Zdroj / prenosnýTam, kde je systematizovaný, ale vývojové prostredie (IAR, GCC atď.) A hardvérové \u200b\u200bplatformy (napríklad ATMELSAM7S64, MSP430F449). Napríklad podadresár / Zdroj / prenosný / GCC / ATMEGA323 Obsahuje port.c a portmacro.h súbory, ktoré implementujú / obnovujú kontext úlohy, inicializujte časovač na vytvorenie dočasnej databázy, inicializovať stoh každej úlohy a iných funkcií závislej od hardvéru pre mikrokontroléry Rodiny Mega AVR a Compiler (GCC). Samostatne je potrebné zdôrazniť podadresár / Zdroj / prenosný / MEMMANGktorý obsahuje súbory hEAP_L.C, HEAP_2.C, HEAP_3.CImplementácia 3 rôznych mechanizmov prideľovania pamäte pre potreby Freertosu, ktoré budú podrobne opísané neskôr. Adresár / demo je pripravený na kompilácie a montážne demonštračné projekty. Celková časť kódexu pre všetky demonštračné projekty je zvýraznená v subderektoráte / Demo / common. Ak chcete používať freertos vo vašom projekte, musíte povoliť zdrojový kód zdrojového kódu jadra a pridružených súborov hlavičky. Nie je potrebné ich modifikovať alebo pochopiť ich implementáciu. Napríklad, ak plánujete používať port pre MSP430 mikrokontroléry a kompilátor GCC, potom vytvoriť projekt - nula "bude potrebné podadresár / Zdroj / prenosný / GCC / MSP430_GCC a / Zdroj / prenosný / MEMMANG. Všetky ostatné podadresáry z / Source / Prenosné adresára nie je potrebné a možno ho odstrániť. Ak sa plánuje zmeniť existujúci demo projekt (ktorý sa v skutočnosti odporúča vykonať na začiatku štúdie freertos), potom budete potrebovať aj podadresár / Demo / msp430_gcc a / Demo / spoločné. Zvyšok podadresára / demo nie je potrebné a môže byť odstránený. Pri vytváraní aplikácie sa odporúča používať makefile. (alebo vývojový súbor rozvojového prostredia) z príslušného demonštračného projektu ako východiskový bod. Odporúča sa vylúčiť zo súborov zhromaždenia (stavby) z adresára / demo, nahradenie ich vlastným a súborom z adresára / zdroj sú neporušené. Uveďte tiež aj súbor hlavičky Fertosconfig.h.ktorý sa nachádza v každom demonštračnom projekte. Freertosconfig.h obsahuje definície (#define), čo umožňuje nastavenie freertos jadra: 1. Súbor funkcií systému. 2. Pomocou rozpramu. 3. Počet úloh a konštrukcií 4. Veľkosť pamäte (zásobník a hromady). 5. Frekvencia hodín MK. 6. Obdobie prevádzky časového plánovača prideleného každej úlohe realizácie, ktorá sa zvyčajne rovná 1 ms. Vypnutie niektorých systémových funkcií a zníženie počtu priorít (znižuje spotrebu pamäte). Distribúcia Freertos je tiež zahrnuté nástroje na prevod informácií o sledovaní prijatých od plánovača, v textovom formulári (adresár / Tgssun.) A text licencie (adresár / Licencia.). závery S pomocou prvého článku cyklu sa čitateľ oboznámil s operačným systémom pre freertos la mikrokontroléry. Zobrazujúci funkcie práce. Opísal obsah distribúcie freertosu. Mali by sa spustiť hlavné kroky, z ktorých by sa mal začať vývoj zariadenia na freertose. V nasledujúcich publikáciách sa bude venovať pozornosť mechanizmu multitaskingu, a to úlohami a dopravníkom. Vzorka plánovača bude vzorka s použitím mikrokontrolérov ATTHEl AVR a kompilátorom WINAVR (GCC). Stellaris LaunchPad a Arduino Dued sú veľmi silné, ale nie sú určené na spustenie Linuxu. Oni prevádzkujú buď na spustiteľnom kódexe napísanom priamo pre nich, alebo prevádzkujú operačný systém v reálnom čase (RTO), - minimalistický systém, s veľmi krátkou dobou odozvy na externé udalosti. Aj obaja sú oveľa zložitejšie ako MSP430 alebo 8-bit AVR. Na druhej strane, v reálnom živote (v zahraničí), z ktorých väčšina z nich viem, používajte Raspberry PI alebo iné vstavané systémy na Linuxe. Použitie mikrokontrolérov, skôr zriedkavým prípadom, medzi tými, ktoré som sa stretol. Aj Arduino, oveľa menej populárne v mojom okolí ako vstavaný Linux. Ako to chápem, je to dôvod, prečo kúpiť Arduino niekomu, keď si môžete kúpiť Raspberry Pi, čo môže byť oveľa viac, a stojí za to isté alebo menej? Pod Linuxom je obrovské množstvo hotového softvéru, a to môže byť naprogramované pomocou jednoduchých skriptovaných jazykov. Pre mňa osobne, dôvod, prečo nechcem používať Linux, je, že ho používam denne v práci, a vraciam sa domov, necítim sa potešenie z potreby pracovať znova na systémov Linuxu. Nemám žiadne problémy s Linuxom, ale je to príliš veľa všade, utláča ma. Je pre mňa oveľa zaujímavejšie pracovať s jednoduchými elektronickými zariadeniami na 8/16-bitových mikročipoch. Avšak, neodvrátim sa z reality. Ak chcem zostať na tej istej vlny so skutočným svetom, musím použiť tieto nástroje, ktoré sa používajú v reálnom svete. V opačnom prípade vyzerá ako túžba riadiť auto s parným motorom, len preto, že vnútorný spaľovací motor je príliš zábavný, používam ho po celú dobu. Ak svet po celom svete ide na pokročilejšiu technológiu, musíte ho zvládnuť, páči sa mi to alebo nie. Najmä, ak chcem, aby sa môj blog mal záujem o ľudí a zostal relevantný. V mojom projekte Smart Home som naozaj stretol s týmto problémom. Už som urobil miestny ovládač siete pre riadiaci systém na MSP430 a všetko vyzerá veľmi hodné. V podstate môžem urobiť všetko, čo potrebujete pre automatizačný systém na MSP430. Avšak, myslím, či to robím? Snažím sa, ak je vidlica polievka, keď je lyžica? Možno Linux je správnejší systém? Nechaj ma vysvetliť. Ak sa zastavíte a pozrite sa na súčasnú situáciu podľa technologického pokroku v novembri 2012. Pýtam sa sám seba, sú mikrokontroléry dobré a relevantné a relevantné sú v porovnaní s on-chipovými systémami pomocou Linuxu? Ak zoznam projektov na vstavaných systémoch, ktoré ku mne prichádzajú do hlavy, je: drones, roboti, domáce automatizácia, motory regulátory, senzory, náramkové hodinky, 3D tlačiarne atď. V ktorom z týchto prípadov je vstavaný Linux vhodný viac ako mikrokontroléry? A prečo? Myslím si, že existujú tri situácie, keď je mikrokontrolér najlepšou voľbou: kde je instant (realtime) dôležitý pre udalosti; ak je to nevyhnutné na extrémne nízku spotrebu energie; A kde potrebujete používať čipy čo najnižšie. Začnite s použitím lacných čipov, nie je to tak dôležité pre mňa. Zapojujem sa do môjho hobby za seba a nebude nikdy vyrábať konkurenčné produkty. Nemusím premýšľať o prevode výroby do rastliny, ktorá využíva slave prácu, aby mali konkurencieschopnú cenu za menšie projekty, ktoré si žela. Bol by som rád, keby som mohol, rozbaliť viac ako jednu dosku za deň, vďaka mojim schopnostiam! Napríklad, pre projekt inteligentného domova, môžem vyvinúť, diaľkovo ovládaný spínač. Môže sa zapnúť / vypnúť svetlo alebo niečo iné. Zároveň môžem ísť do miestneho obchodu elektrotechniky a kúpiť to isté za 20 dolárov, vyrobené v Číne. Môžem zabiť túto cenu, snažím sa predať svoj vlastný spínač? Nemyslím si, že je to možné. Ak o tom premýšľate, platí aj na súbor iných vecí potrebných pre domácu automatizáciu. Teplotné snímače, dym, pohyb, atď., Som celkom schopný robiť to isté, ale je nepravdepodobné, že by ste mohli získať finančné výhody. Kto sa stará o kúpu takýchto vecí za 75 dolárov, keď ich nájdu za 20 dolárov v tovare pre domácnosť? Ak sa zamyslíme na extrakciu niektorých druhov výhod z vášho hobby, je lepšie venovať pozornosť drahšie a zložité výrobky. Napríklad regulátor domácej automatizácie alebo termostat, zvyčajne stojí viac ako 100 dolárov, a zanechať viac slobody pre individuálnu kreativitu, môžete stavať jeden, predať svojich susedov a dokonca zarobiť na ňom niečo. Ale túžba dosiahnuť ziskovejšiu cenu konečného zariadenia neznamená, že potrebujete použiť najlacnejší mikrokontrolér na Zemi. V skutočnosti je to zlý nápad, pretože Rozvojový čas robí rovnaké náklady, ako aj použité časti. Možno, že mikrokontrolér je lacný, ale vyžaduje viac času na napísanie riadiaceho kódu. Čas je peniaze, a ak pracujete rýchlejšie, budete mať čas na dosiahnutie viac. Všetky tieto úvahy, zhrnúť ma, že je to výhodnejšie vytvoriť inteligentný domovský systém na Linuxe ako na mikrokontroléry, napriek mojim osobným preferenciám, nepoužívajte Linux (mám rád nízkoúrovňové programovanie viac ako skripty, Linux ma zachytí. Ak sa vrátite na tému tému, cena mikrokontrolérov, môže to byť dôležitý faktor pre veľké spoločnosti, ktoré budú uvoľniť nový produkt, ale na individuálnej úrovni, ak sa pokúsite vykonávať podnikanie v štýle Kickstarter, tento faktor je V skutočnosti nie je tak významný, rýchly rozvojový čas, dôležitejšie ako náklady na komponenty. Na druhej strane mikrokontroléry môžu byť najlepšou voľbou ako systém-on-čip, keď je potrebná nízka spotreba energie. V takýchto systémoch existujú dva body: nízka spotreba samotného diagramu, počas prevádzky a krátky čas začiatku. Typický spôsob, ako šetriť batériu pre malé zariadenia, je samočinné vypnutie (vypnuté). Keď vypnete počítač na Linux, potrebuje dôstojný čas vrátiť sa do práce, niekedy až niekoľko minút. Tento čas nie je prijateľný pre vstavané systémy. Ak užijete taký mikrokontrolér ako MSP430, potom môže pracovať celé roky z jednej batérie. Stellaris Launchpad a Arduino splatné, v zásade, to isté je schopné takých, konzumujú viac energie ako MSP430, ale stále veľmi málo v porovnaní s Raspberry PI. Tiež MSP430, môže okamžite začať po vypnutí. Som teda absolútne presvedčený, že vo všetkých situáciách, keď sú potrebné nízkonapäťové operácie, má zmysel používať mikrokontroléry. Existuje veľký počet rôznych zariadení pracujúcich na batériách, v ktorých sa táto potreba objaví. V treťom prípade, ako som povedal, použitie mikrokontroléra je zmysluplnejší ako Linux, v operáciách, ktoré vyžadujú okamžitú reakciu (Realtime Response). Mám na mysli také zariadenia ako 3D tlačiarne a CNC stroje, viem, o čom hovorím, ako som venoval veľa času na štúdium. Prirodzene si vyžadujú vysokú presnosť v práci, čo je o niečo menej, než úplne závisí od času odozvy na príkazy. Napríklad, ak máte kruhovú pílu, ktorá v súčasnosti znižuje kus dreva alebo kovu, nemôžete zastaviť proces, kvôli tomu, že ho ovláda, to znamená pozastavenie, aby vyhodil dáta z pamäte alebo niečo iné v tej istej žily. Každý, kto používa počítač, je oboznámený s náhodným valcovaním, pravidelne vznikajú počas obvyklého diela. A teraz si predstavte, že máte veľký vŕtací stroj, spustený počítač, ktorý zrazu začne kontrolovať aktualizácie pre okná počas prevádzky, a vŕtajte, vŕtajte cez stôl, na ktorom stojí za to, pretože Počítač stratil kontrolu nad ním. PCS a on-chipové systémy nie sú určené na prácu v reálnom čase, aspoň s Windows, dokonca aj s Linuxom, ale sám sa sám snažia dostať sa k nemu bližšie. Ako príklad existuje náplasť v reálnom čase pre jadro Linux, a špeciálny CNC softvér vytvorený pre tento druh. Nie som dosť s touto patch Linux, a neviem, ako flexibilné je to, aby dokončili akcie v reálnom čase. Ale myslím, že je to len možná alternatíva, pretože Linux, bez ohľadu na to, aké opravy klesli, nikdy nebudú poraziť mikrokontroléry v tejto oblasti, kvôli ich systémom prerušenia. Pre mikrokontroléry zostávajú iba oblasti nízkonapäťových zariadení, prevádzky v reálnom čase a nízkonákladové zariadenia. Nezáleží na tom, že mikrokontroléry sa môžu zdať viac zábavy ako PC. To je to, čo bude musieť konkurovať. Preklad z anglického pôvodného príspevku Neplatná úloha1 (zatiaľ čo (1) (portb.0 \u003d! Portb.0; počkajte (100););)
Create_Task (úloha1, 1, aktívna);
#Include.
Neplatná úloha2 (prázdnota) (zatiaľ čo (1) (ak (MUTE \u003d\u003d 0) // Ak je dovolené hrať (if_CH2 [n_n] \u003d\u003d 0) // Ak čakáte na pauzu, nehrajeme nič (Portb.4 \u003d 0; počkajte (5);) inak (portb.4 \u003d! Portb.4; // ak sa nezobrazí, potom dotiahnite nohu požadovanou frekvenciou Počkajte (note_CH2 [N_N]); )))
Neplatná úloha3 (prázdnota) (počkajte (1) (počkajte (1500); // Zahrajte si minimálny počet poznámok pre (mute \u003d 0;<
500
;
mute++
)
// kliknite na poznámku, že sa nezlučuje (Portb.3 \u003d 0; portb.4 \u003d 0;); Mute \u003d 0; // Nastavte príznak, ktorý môžete prehrať zvuk n_n ++; // Prejdite na nasledujúcu poznámku Ak (n_n \u003d\u003d n_max) // ak hrajú všetko v kruhu (n_n \u003d 0;)))
Čiastočne to bolo vyzvané vzhľadu Stellaris LaunchPad a Arduino. Obaja sú založené na 32-bitových mikrokontrolérii a mnohými spôsobmi sú veľmi podobné. Študoval som špecifikáciu (datasheet) na oboch, a hoci sú slušne odlišné v cene, sú určené pre jednu cieľovú skupinu. Premýšľal som o tom, čo som sa mohol pohybovať s MSP430 na Stellaris, a to môže byť dokonca prenesené do zásadne odlišného systému, použiť niečo ako Raspberry PI namiesto mikrokontrolérov.
Na záver chcem povedať, že som strávil veľa času, ktorý sa snaží nájsť oblasti, kde má použitie mikrokontrolérov v mojich projektoch výhodu. A všetko vyzerá ako éra svetovej nadvlády Raspberry PI a Beaglebones. Ide o súčasnú situáciu v komunite DIY. Vo väčšine prípadov, rýchlejšie a jednoduchšie rozvíjať sa na týchto systémoch, takže je to často najlepšia voľba pre väčšinu projektov.
