Szia, Habr!
Ma elmondom neked egy ilyen érdekes dologról operációs rendszer Valós idejű (OSR). Nem vagyok biztos benne, hogy érdekes lesz a tapasztalt programozók számára, de azt hiszem, szeretem a kezdőknek.
Mi az OSR?
Ha megnézzük a Wikipediát, akkor akár 4 definíciót fogunk látni.Ha röviden mondod, az OSR olyan operációs rendszer, amely bizonyos ideig a külső eseményekre reagál. Innen megérthetjük az OSR fő célját - olyan eszközöket, amelyekben szükség van az eseményekre adott gyors válaszra (de semmiképpen sem zavarja az OSR munkáját megszakításokkal).
Miért van szükségünk rá?
Ez nagyon sok oka van.Először is, az OSRV támogatja a multitasking, a szemafor folyamat prioritásait és még sok más.
Másodszor, nagyon könnyű, és szinte nem igényel erőforrásokat.
Harmadszor, a fentiek mindegyike szinte bármilyen mirigyre juthatunk (például a Freertos akár 8 bites atmega is fut).
Nos, negyedik: csak játszani magad és élvezd.
A 3 jól ismert OSRS áttekintése.
Figyelem: Ezután a személyes véleményemre megy.Freertos.
Az egyik legnépszerűbb OSRS ma. Hatalmas mennyiségű vasat. Hivatalos oldal.profik
1) Ingyenes2) kikötve nagyszámú mirigy
3) Erőteljes funkcionalitás
4) Vannak különböző könyvtárak: grafika, internet és így tovább.
5) Jó dokumentáció.
Mínusz
1) elég összetett hordozási folyamat egy új vashoz.Következtetés: Ez valóban professzionális megosztás jó dokumentációval. Jó lesz a kezdők számára, ha a portnak már van kikötője.
Keilrtx.
A közelmúltig ez az OSRV kereskedelmi volt, de a közelmúltban nyitott lett. Csak a kar építészeten működik. Hivatalos oldal.profik
1) Ingyenes2) Könnyen kikötik az új vashoz (a kar építészetben).
3) Vannak különböző könyvtárak: grafika, internet és egyéb.
Mínusz
1) A Keilben való munka szinte irreális2) egy kis vágott funkcionalitás
3) Csak a kar támogatott.
4) (Személyes tapasztalat esetén) sokféle sebességet veszít.
Következtetés: ideális kezdő és kis projektek.
uC / OS.
Erőteljes kereskedelmi megosztás. Weboldal .profik
1) Hatalmas funkciók és könyvtár.2) sok vasat támogat
Mínusz
1) kereskedelmi.2) Komplex használatban van.
KÖVETKEZTETÉS: A NEVICE-hez nagy szakaszban hívhatja.
Egyéb érdekes OSRVS
RTLLINUX OSRV a szokásos Linux alapján.QNX OSRV a Unix alapján.
Fejlesztési funkciók az OSRV használatával
Nos, először is meg kell érteni a következőket: a DRA nem ablak. Nem telepíthető. Ezt a rendszert egyszerűen összeállítja a programoddal.Az OSR-vel való programok írásakor a funkciókat nem használják a szokásos megértésükben. Funkciók, folyamatok (vagy herék) alkalmazása. Az a tény, hogy a folyamatok, a funkcióktól eltérően végtelen ciklusok és soha nem véget érnek (ha csak valaki, vagy nem öl meg - azaz a memóriából kimarad).
Ha több folyamat szerepel, akkor az OSR átkapcsolja azokat, a gépidőt és az erőforrásokat. Ez az, ahol a folyamat prioritásainak fogalma felmerül, ha a két folyamatnak egyszeri motorra van szüksége, az OSR megadja azt azoknak, akiknek több prioritása van.
Az OSRV-ben a késedelem különleges jellemzői vannak - így az idő hiába nem tűnik el az egyik folyamat késedelme idején, a második végrehajtásra kerül.
Most beszéljünk egy ilyen dologról, mint a szemafor - ez olyan dolog, ami ellenőrzi az alkalmazáshoz való hozzáférést az alkalmazási erőforrásokhoz. Minden egyes erőforrás esetében van egy marker - ha a folyamatnak erőforrásra van szüksége - azt veszi, és ezt az erőforrást használja. Ha nincs jelölő, akkor a folyamatnak meg kell várnia, amíg vissza nem kerül. Például adok: Különböző folyamatok küldenek információt egy UART-on. Ha nincs szemafor, viszont bájtokat küldnének, és zavart lenne. Így az első folyamat átvette az UART jelölőjét, küldött egy üzenetet, és megadta a második (és végtelen).
További OSR könyvtárak.
Gyakran az OSRV különböző könyvtárakat kínál a munkához, például grafikával, internettel, stb. Nagyon kényelmesek, és nem szabad kénytelenek használni őket. Ne feledje azonban, hogy az OSR nélkül, amelyre írtak, nem fognak működni.Íme példák:
RTX
Mi jön az elme, amikor hallja az operációs rendszert? Biztosan az ablakok, a Linux, a makró .. vagy valami ilyesmi. Igaz, és arra a kérdésre, hogy miért van szüksége, mindenki magabiztosan válaszol: zenét hallgatni, játszani a játékot (az interneten!), A másikval beszélve a Skype-on. Ugyanakkor a LED villogása, miután kapott egy bájtot Yuart \u003d).
És ha mélyebben ássz, majd zenét hallgatsz, az adatok küldése az interneten keresztül minden egyes folyamat, és mivel egy processzorunk van, ugyanakkor csak egy feladatot végezhet. Ezért a feladatok elvégzünk váltakozva a kis "részekben", az operációs rendszer lényege észrevétlenül a felhasználó számára: így a hang nem rekedt, és a biketika énekel, és minden egyszer dolgozott. Ugyanakkor, ha az egyik feladat "lóg", akkor minden más továbbra is dolgozik.
Ha eldobja az összes extra zsemle, és elhagyja a meztelen lényegét, akkor először az operációs rendszer, ez csak egy időzítő, amely egyenlő időközönként számít, és maga is, a felhasználó részvétele nélkül, a feladatok közötti kapcsolók, néhány részt veszek, és újra váltak. Szükséges továbbá figyelembe kell venni, hogy a legtöbb feladatnak nincs ideje befejezni az egy mennyiségi időtartamot, így meg kell mentenie a feladat állapotát a másikra való áttérés idején, és a következő alkalommal, amikor visszaállítja a változók állapotát . Mindezek kezelését a feladattervező végzi.
Az OS két fő típusa van: kiszorítás és szövetkezet. Az első esetben a feladatok közötti váltás "kemény" lesz, azaz Ha az idő mennyisége 1 mm, akkor először az első feladat pontosan 1 ms, majd a második pontos 1 ms stb. Az ilyen tengelyeket valós idejűnek nevezzük (ORVD). A kooperáció egy kicsit egyszerűbb, maga a folyamatnak meg kell mondania, hogy "én kivégezték", ezért lehetetlen hozzárendelni őket.
Gyorsan a kiemelkedő AVR nem fog működni, mert kisszámú RAM. A szövetkezetek rendelkezésre álló lehetőségeiről az MRTOS vonzódott, olvashatod a rendszer részleteit a szerző honlapján (könnyen googles). fő ok Használata egyszerűség, egy készenléti változat jelenléte a CavR alatt, a megértéshez Általános elvek A legtöbb dolog.
Tehát a fő kérdések maradtak, miért és mikor kell alkalmazni a tengelyt. Elméletileg ugyanolyan dolog, amit csinálsz a tengelyhez, átkelhetsz anélkül, hogy az erőforrások megegyeznek. Anttól, hogy elfogadja azt a projekthez, a Megahertz az űrben nem veszi le, a vas ugyanaz marad, ezért az erőforrások ugyanazok.
Ezért néhány kérdést kell feltenned:
1. Kezelheti az illetékes erőforrásokat?
2. Nem kellene feltalálnia ugyanazt a kerékpárt a firmware írásában?
3. Mennyit olvas a kódod? Képes-e fél évben megnyitni, és kimegy?
4. Ön írja vagy csoportosít?
Nehéz megválaszolni az első kérdésre, mert mindez a fejlesztő tantervétől függ. A második, minden érthetőbb, ha sok független feladat létezik, és azt tervezik, hogy bizonyos időközönként elvégezhessék őket, jobb, ha az operációs rendszer oldalára néz. A harmadik is világos, sokkal könnyebb megérteni egy külön feladatban, mint a fő ciklusban lévő függőséget. Ha nem írsz egyedül, akkor itt vannak előnyei, mert mindenki külön írhatja feladataikat, anélkül, hogy zavarná a többieket.
A fentiek kombinálása érdekében az alkalmazás terjedelme meglehetősen specifikus, bizonyos feladatok mellett. Ne húzza be minden projektbe. A legtöbb amatőr rádióeszközök esetében a tengely felesleges, de előtte egy ötlete, valószínűleg pár projekt.
Most nézzen a motorháztető alatt. Az MRTOS elindításához a projekthez csatlakoztatnia kell az Mrtos.c-t és a Mrstos.h-t. A kód szerkezete kissé eltér a szokásosnál
| #Inlude. |
#Inlude. Most több. A feladatok száma van feltüntetve MRTOS.H defaines AppTasks N. A feladat nyilvánították belül Task1 () (), TASK2 () () és hasonlók, belső while (1) nem kell írni semmit, nem szükséges A funkciók hívásához mindez ezt megteszi, akkor tervező. Amint láthatja, hogy a feladat végtelen ciklusból áll, normálisnak kell lennie, és kell lennie, de a feladat belsejében kell megadnia a tervező irányítását. Vagy a várakozási funkció vagy a szállítás. Ha ez nem történik meg, akkor a feladat végtelenül kerül végrehajtásra. Hogyan működik? Feladat létrehozása villogó LED. void Task1 () (míg (1) (Portb.0 \u003d! Portb.0, várakozás (100);););); A várakozás egy bizonyos késleltetés () analóg csak, a késleltetés során a mikrokontroller nem végez semmit, és meghajtja az üres ciklusokat. Ugyanezen várakozás során a vezérlést más feladatokra továbbítják. Azok. A különböző LED-ek villogásával létrehozhat egy csomó feladatot, különböző várakozással, és mindegyikük különböző frekvenciákkal villog. Ha a késedelmek nem szükségesek, akkor a végén a küldeményt használja. Ha várjon, akkor fontos megérteni, hogy az egész rendszer minimális TIC-t (kvantum idő), így nem várunk (50) 50 milicecunds, de 50 teak rendszert. A Tick Setup attól függ, hogy az időzítő megszakítását gyakran hívják, vagyis Ha megszakítunk 1ms-ig, akkor feltételezhetjük, hogy cselekedeteinket 1 ms-ra hajtjuk végre. A kísérletek kimutatták, hogy a rendszer kullancsának csökkentése ~ 20 μs-ra van jelölve 16 MHz-es órával. Az időzítő beállítás nem különbözik a korábban vizsgált, hiszen a Timer0 csak túlcsordulási megszakítással rendelkezik, majd minden beállítás kötődik hozzá. A CavR legújabb verzióiban nagyon kényelmes az időbeli igények írása, a beállítások automatikusan generálnak. create_task (feladat1.1, aktív); A prioritásoknál minden elég nem csak. Ha két különböző prioritású feladat van, és a nagy prioritású feladatot folyamatosan elvégzik, akkor soha nem fogunk menni az alacsony prioritással. Ezért meg kell szerveznie a munkát, hogy minden feladat hozzáférjen. Figyelmet kell fordítani erre, amit nem fogunk megosztani a következő alkalommal. Feladat állapota, Aktív indítás, Stoptask leállt. Tehát azok számára, akik egyszerűen villognak a LED-t: #Inlude. Bónuszként próbáltam polifonikus (kétszőrű) dallamot készíteni, "dr..mario chill". Az ötlet az, hogy a vezérlő mindegyik lábát folyamatosan megfordítják egy külön taszkban, ezáltal generálják a frekvenciát. A zár cseréje megváltoztathatja a jegyzetek magasságát. void Task2 (Void) (míg (míg (1) (ha (mute \u003d\u003d 0) //, ha lejátszani kell (ha_CH2 \u003d\u003d 0) // Ha egy szünetet vár, akkor nem játszunk semmit (Portb. 4 \u003d 0, várakozás (5);) más (Portb.4 \u003d! Portb.4; // ha nem szünetel, akkor a lábbal a kívánt várakozási gyakorisággal (Note_CH2);))))))) Nem zavartam az ötletet, 1 Tasque generálja kanyargós, a Solo Party jegyzetek gyakoriságával, a második a basszus. Az egyes figyelmesek magassága a tömbökből származik. Időtartam, átkapcsolás és törés Tasque3. void Task3 (Void) (Várjon (1) (várjon (1500); // A jegyzetek minimális párosítása (némítás \u003d 0; néma)< 500; mute++) //обрываем ноту, чтобы не сливались
{
PORTB.3 = 0;
PORTB.4 = 0;
};
mute = 0; //выставляем флаг, что можно воспроизводить звук
n_n++; //переходим на следующую ноту
if(n_n == n_max) //если сыграли все то идем по кругу
{
n_n = 0;
}
}
} Két csatorna keveréséhez egyszerű sémát használ. Teljes kis darab Azok számára, akik firmware-t akarnak Egy kicsit több mint 10 elektronikus eszközt dolgoztam ki, és az operációs rendszer nélküli alacsony szintű munkájukban teljesen elszámoltam. A helyzet megváltozott, amikor a következő eszköz funkcionalitása élesen bővült. Ezenkívül szükség volt olyan feladatra, amelyet a megadott időintervallumok keresztül hívnak, és a hívás pontossága befolyásolja az eredményt. Nyilvánvalóvá vált, hogy nem dolgozik mindent a kiosztott időért, és később jön létre. Rövid visszaverődés után rájöttem, hogy a projektnek tartalmaznia kell a valós idejű operációs rendszert (Orvd vagy RTO-k). Ellentétben a számítógépen, ahol az operációs rendszer egy réteg a rendszer erőforrásokkal való munkavégzéséhez, egy mikrokontroller OSR - ez elsősorban a feladat ütemezője, valójában jelentős szerepet játszik a "valós időben". Jelenleg fontos számomra, hogy biztosítsam az úgynevezett "pszeudo-párhuzamos" feladatokat. Azaz, több feladat azonos prioritás, és fontos, hogy okoz nekik egy adott sorrendben a megadott időközönként. A következő példa vizuálisan volt: az Eurobot 2011 projektben 18 perifériás eszköz volt jelen a rendszerben. 2 e-mailt lehet egyesíteni. Annak a költsége csökken, a megbízhatóság növelik (csökkentik az alkatrészek számát a rendszerben), a rendelkezésre álló szabad hely esetén nőtt. A körülmény bonyolítja, hogy a feladatok száma arányosan növekszik, és itt már nem történik meg az operációs rendszer nélkül. Továbbá az OSR segít elkerülni a processzor lehetséges leállási idejét, például az ADC konverzió során blokkolhatja ezt a feladatot, és másokat is elvégezhet, ezáltal helyesen forgalmazza az eszköz működését. Fontos továbbá, hogy most a készülék nem esik a feladat meghibásodása miatt, ehelyett a részleges teljesítmény megőrzése (bár kiszámíthatatlan eredményekhez vezethet). Ami a mutatók növekedését biztosítjuk? Valójában minden lehetséges az MC-től, hatékonyan használjuk számítási képességeit. Rövid keresés után a választás a Freertosra esett. Ez az ORD a C forráskódban és a portok 27 architektúráig terjed. Az utolsó körülmény számomra döntő. Ez csökkenti a munkaerőköltségeket, amikor más gyártók MK-val dolgozik. Most jobban érdekel az AVR kikötőjében. A FREATTOS áttekintése a projektben kb. 9,8 Cb programprogramot és 1,8 kb RAM-ot fogyaszt. Például az ATMEGA32 és a WIDAVR fordító 60% és 85%. Már erre a modellre van szükség, hozzon létre egy nagy funkcionalitású eszközt - nincs elég memória. De ez a probléma eltűnik az új AVR modellek használatakor. Teljesen megsértődik a Mega2560-ra, 256 kB programprogramjaival és 8 kb RAM-vel. A jövőbeni MK tendenciája csak az OSR sikerét kísérte. Runly fut a futamon, meglepődtem, hogy úgy találom, hogy oroszul nincs dokumentáció az operációs rendszerben. Tehát mi van itt! Az eredeti dokumentáció a többletköltségre vonatkozik. A helyzet egyszerűsítette az Andrei Kurtica cikket ( [E-mail védett]) A "Alkatrészek és a technológia" magazinból. A szerzővel kötött megállapodással a cikket az újrahasznosított verzióban fogom használni. A cikke jól szolgálhat az orosz nyelvű dokumentációként. De az eredeti nem érhető el a nyomtatásban, a magazin webhelye rejlik, így az anyagnak egy kicsit újrahasznosítani kell. Általában a szerző készített egy kiváló cikket, és nincs értelme, hogy menjen át az elmélet újra, akkor teljesen közzé. Az eredeti cikk a közzététel végén található. Azt is észrevettem, hogy a felhasználók nehézségekbe ütköznek az OSR összeállításával. Ez annak köszönhető, hogy a külső makefilt használják, amelyben a mappákra vonatkozó útvonalak íródnak. Ezért egy kész projektet alkalmazok az AVR Studio és avr Eclipse sablon formájában. Sajnos a natív makefile nem vonja vissza a hibakeresési információkat, például a RAM foglalkoztatásának mértékét és a programok emlékét, akkor a megfelelő szabványos kihívás hozzáadásával meg kellett fiktálnia. Tehát röviden a szükségletre, a projektben kívánatos, ha szükséges, ha szükséges: Multisascy és alternatív feladatok szervezése A feladat bevezetése szigorúan meghatározott időintervallumokon keresztül történik Átadási információkat az egyik feladatról a másikra Szükség szerint új feladatokat kell hozzáadni Az OSRV előnyei m előtt mNAK NEK: Az OSRV hátrányai: 1. Élesen növeli a programot a rendszermag végrehajtására 2. A szükséges RAM növekedése az egyes feladatok, a szemaforák, a sorok, a mutexek és más objektum alapvető objektumok tárolásához. 3. Késleltetés a kontextus megőrzési feladatok közötti váltáskor. Leírásfreertos.: A Freertos ingyenes nyílt forráskódú, merev valós idejű operációs rendszer. Előnyösen C írva, de vannak összeszerelő betétek. A valós idejű mérnökök Kft. Kifejlesztve a beágyazott rendszerekhez. A közelmúltban a "SAFERTOS" projekt - javított, dokumentált, tesztelt és múltbeli tanúsítvánnyal rendelkezik az IEC 61508 biztonsági szabványnak való megfelelés érdekében az IEC 61508 verziónak való megfeleléshez. A német cég részt vett ebben a projektben, és most SAFERTOS-t használnak az űrkutatásban és az orvosi technológiában. Van egy Openrtos projekt - kereskedelmi verzió a gyártó garanciájával. Frertos fő jellemzői: 1. Az ütemező támogatja a multitasking 3 típusát: Megsérül Szövetkezet Hibrid 2. A rendszermag mérete 9,8 kb, az AVR összeállítási formájában. (Winavr) 3. A Core - 4 fájl alapja C. 4. Támogatja a feladatokat és a koprogramokat. A szállítószalagok speciálisan MK-t hoznak létre, kis mennyiségű RAM-val. 5. Rich Trace képességek. 6. Lehetőség van nyomon követni a verem túlcsordulását. 7. Nincs szoftverkorlátozás az egyszerre végrehajtott feladatok számáról. 8. Nincs korlátozás a feladatok prioritásainak számáról. 9. Bizonyos feladatok ugyanazt a prioritást kaphatják. 10. Fejlesztett eszközök a "Task-Task" és a "Problem-Borrupció" szinkronizálásához: Sorok Bináris szemapácsok Számlák szemegóriák Rekurzív szemaforák Mutexes 11. Mutexes az elsőbbségi örökséggel. 12. A Cortex-M3 memóriavédelmi moduljának támogatása 13. A demóprojektek demóprojektekkel ellátott adóssággal szállították a különböző platformok és fordítók számára. 14. Ingyenes. Használhatja a projektekben, anélkül, hogy a forráskódot a kiterjesztett GPL-licencnek megfelelően tárolná. 15. Fizetett dokumentáció, de itt elérhető. 16. Az AVR kontextuskapcsolási ideje a Quartz-rel 16 MHz-re csak 20,8 μs lesz. Annyira szükséges, hogy az adatokat a feladatcsomagra mentse, és hívja a következőket. (Érdekes megjegyzés, ha összehasonlítod a PIC18XXX-vel, az AVR vezérlője gyorsabban teszi 4-szer !!!, a legvalószínűbb, hogy a fordító minőségének köszönhető) Az elmozdító multitasking azt jelenti, hogy az alacsony prioritású feladatot egy előre készített feladat átfedik, magasabb prioritással. A feladatok közötti váltás egyenlő időben kvantán történik. Ezért, mielőtt az intelligencia feladat elindítja a végrehajtást, a jelenlegi mennyiségi időnek meg kell végeznie az alacsony prioritás elvégzését. Így a külsõ események FREATTOS reakcióideje a multitasking elmozdulás módjában végzett külső eseményeknél nem egynél több ütemező idő Quanta, amelyet a beállításokban lehet megadni. Alapértelmezés szerint 1 ms. Ha készen áll arra, hogy több feladatot végezzen ugyanolyan prioritással, akkor ebben az esetben a tervező mindegyiküket egy kvantummal osztja ki, majd a vezérlés ugyanazzal a prioritással rendelkezik, és így egy körben. A szövetkezeti multitasking különbözik a tervezőtől függetlenül a tervezőtől függetlenül nem szakíthatja meg az aktuális feladat végrehajtását, még akkor is, ha nagy prioritásként végezheti el a feladatot. Minden feladatnak önállóan kell átadnia az ütemező irányítását. Így a kiemelt feladat elvárható, amíg az alacsony prioritás befejezi munkáját, és megadja a tervező irányítását. A rendszer reakció ideje egy külső eseményre határozatlanul válik, és attól függ, hogy mennyi ideig tart az aktuális feladat a vezérlés előtt. A Windows 4 OS családban együttműködő multitaskinget használtunk. A multitasking elmozdulási és kooperatív koncepciója egy hibrid multitaskingben kombinálva van, amikor egy kihívó hívás minden idők mennyiségben fordul elő, de ellentétben az elmozdulási multitasking-szel, a programozó képes erre kényszeríteni ezt a feladatot. Ez az üzemmód különösen akkor hasznos, ha szükséges a rendszer válaszidejének csökkentése a megszakításhoz. Tegyük fel, hogy jelenleg az alacsony prioritású feladatot végezzük, és a nagy prioritás egy bizonyos megszakításra vár. Ezután következik be, de a megszakítási kezelő megszüntetése után a végrehajtás visszatér a jelenlegi alacsony prioritású feladathoz, és a nagy prioritás elvárja az aktuális idő kvantumot. Ha azonban a megszakítási kezelő végrehajtása után adja át az ütemező vezérlését, akkor továbbítja a kiemelt feladat ellenőrzését, amely csökkenti a külső eseményhez kapcsolódó rendszer reakcióidejét. Miértacsevegésb? Elkezdheti fejleszteni a FREERTOS-t futtató mikrokontroller eszköz kifejlesztését, a legújabb verzió betöltésétől. A FREATTOS eloszlás rendes vagy önkicsomagoló zip archívumként érhető el. Az elosztás közvetlenül a rendszermag-kódot (mint több fejléc fájl és forrásfájl) és demonstrációs projekteket tartalmaz (minden egyes port minden egyes fejlesztési környezethez). Ezután csomagolja ki az archívumot a fejlesztő állomás bármely megfelelő helyén. Annak ellenére, hogy meglehetősen nagy számú fájl az archívumban, a könyvtárak szerkezete valójában egyszerű. Ha 2-3 architektúrákra tervezi az eszközöket 1-2 fejlesztési környezetben, a demonstrációs projektekhez és a különböző fejlesztési környezetekhez kapcsolódó fájlok többsége nem lesz szükség. A könyvtár részletes szerkezetét a javításon adják meg. A mag teljes forráskódja a / forráskönyvtárban van. Tartalom: 1.tasks.c. - A feladatmechanizmus, az ütemező végrehajtása 2.
queue.c. - Tulajdonos megvalósítás 3.
lista.c. - A tervező belső igényei azonban alkalmazhatók az alkalmazási programokban. 4. CROUTINE.C. - A verzió végrehajtása (hiányozhat, ha a szállítószalagokat nem használják). A könyvtárban található fejlécfájlok Forrás / közé tartozik.
1. tracks.h, queue.h, tist.h, crutine.h - fejlécfájlok, az azonos név kódjainak fájljaihoz. 2. Freertos.h. - Az előfeldolgozó irányelvek végrehajtása a kompiláció konfigurálásához. 3. MPU_WROPERS.H. - A memóriavédelmi modul (MPU) támogatásához felülírja a programinterfész (API funkciók) FREETTOS funkcióit. 4. hordozható.h.-Plappo-függő beállítások. 5. PROJDEFS.H.- A rendszer meghatározása 6. SEMPHR.H. - Az API funkciókat határozzák meg a sorok alapján végrehajtott szememászatokkal való munkavégzéshez. 7. Stackmacros.h. - makrókat tartalmaz a verem túlcsordulásának monitorozásához. Minden hardverplatformnak szüksége van a legfontosabb kóddal, amely végrehajtja a FREATTOS interakciót ezzel a platformtal. A teljes platformfüggő kód az alkönyvtárban van / Forrás / hordozhatóahol rendszerezést, de fejlesztési környezeteket (IAR, GCC stb.) és hardverplatformok (például Atmelsam7s64, MSP430F449). Például az alkönyvtár / Forrás / hordozható / GCC / ATMEGA323 Tartalmaz port.c és portmacro.h fájlokat, amelyek végrehajtják / visszaállítani a feladat kontextusát, inicializálja az időzítőt egy ideiglenes adatbázis létrehozásához, inicializálja az egyes feladatok és egyéb hardverfüggő funkciókat a MEGA AVR család mikrokontrollerekéhez Winavr fordító (GCC). Külön, ki kell emelni az alkönyvtárat / Forrás / hordozható / memmangamely fájlokat tartalmaz heap_l.c, heap_2.c, heap_3.c3 különböző memóriaelosztási mechanizmus megvalósítása a Freertos igényeihez, amelyeket később később részletesen ismertetünk. A / Demo könyvtár készen áll a összeállításra és az összeszerelési demonstrációs projektekre. A kód teljes részét az összes demonstrációs projekthez kiemelik a szubdrélektorban / Demo / common. A FREATTOS használatához a projektben engedélyeznie kell a rendszermag forráskódjának forráskódját és a hozzá tartozó fejléc fájlokat. Nincs szükség arra, hogy módosítsa őket, vagy megértsük a végrehajtásukat. Például, ha az MSP430 mikrokontrollerek portját és a GCC-fordítót kívánja használni, akkor egy projekt létrehozása - nulla "szükséges lesz az alkönyvtárhoz / Forrás / hordozható / GCC / MSP430_GCC és / Forrás / hordozható / memmang. A / forrás / hordozható könyvtárból származó összes többi alkönyvtár nem szükséges, és eltávolítható. Ha azt tervezi, hogy egy meglévő demo projektet módosítani kell (amely valójában ajánlott a Freertos tanulmányának kezdetén), akkor szükséged lesz az alkönyvtárra is / Demo / msp430_gcc és / Demo / közös. A / demó többi részét nem kell, és eltávolíthatjuk. Alkalmazás létrehozásakor ajánlott használni makefile. (vagy a fejlesztési környezet fejlesztési fájlja) a megfelelő demonstrációs projektből kiindulási pontként. Javasolható, hogy kizárja a / demo könyvtárból származó összeszerelő (építési) fájlokat, és helyezze be őket saját, és a / forráskönyvtár fájlok érintetlenek. Említse meg a fejlécfájlról is Frertoconfig.h.amely minden egyes demonstrációs projektben található. FreertsisconFig.h definíciókat tartalmaz (#define), amely lehetővé teszi a Freertos kernel beállítását: 1. Rendszerfunkciókészlet. 2. A sprab használata. 3. Feladatok és konstrukciók száma 4. Memória mérete (verem és heaps). 5. Az óra frekvenciája mk. 6. Az egyes végrehajtási feladathoz rendelt időtartalom működési ideje, amely általában 1 ms-nak felel meg. Bizonyos rendszerfunkciók letiltása és a prioritások számának csökkentése (csökkenti a memóriafogyasztást). A FREATTOS eloszlás tartalmazza az ütemezőtől kapott nyomkövetési információk konvertálásához szükséges eszközöket a szöveges űrlapon (könyvtár) / TGssun.) és a licenc szövege (könyvtár / Engedély.). következtetések A ciklus első cikke segítségével az olvasó megismerte az operációs rendszert a Freertos LA mikrokontrollerek számára. A munka jellemzői. Leírta a FREATTOS eloszlás tartalmát. El kell indítani a fő léptékeket, amelyekből a Freertos-t futó eszköz kifejlesztését el kell indítani. A következő kiadványokban a figyelmet a multitasking mechanizmusára, nevezetesen, feladatokra és szállítószalagokra kell kifizetni. Az ütemező mintája az Atcal AVR Microcontrollers és a WinAvr Compiler (GCC) segítségével kezdődik. Mindkettő, a Stellaris Launchpad és az Arduino esedékessége nagyon erős, de nem célja a Linux. Olyan végrehajtható kódon működnek, amelyek közvetlenül rájuk írtak, vagy futtatják a valós idejű (RTO-k), - minimalista operációs rendszer operációs rendszerét, nagyon rövid válaszidővel a külső eseményekhez. Mindkettő sokkal bonyolultabb, mint az MSP430 vagy a 8 bites avr. Másrészt, a valós életben (külföldön), a legtöbb, akit ismerek, használhatom a Raspberry Pi-t vagy más beépített rendszereket a Linuxon. A mikrokontrollerek használata, egy meglehetősen ritka eset, az általam találkoztam. Még Arduino, sokkal kevésbé népszerű a környezetemben, mint a beépített Linux. Ahogy értem, ezért vásárolhatsz Arduino-t valakinek, amikor megvásárolhatod a Raspberry Pi-t, ami sokkal több lehet, és ugyanazt vagy kevesebbet érdemes? A Linux alatt hatalmas mennyiségű kész szoftver található, és egyszerű szkriptált nyelvekkel programozható. Számomra személyesen, az ok, amiért nem akarom használni a Linuxot, mert naponta dolgozom a munkahelyen, és hazatérek haza, nem érzem magam örömmel, hogy újra kell dolgoznunk a Linux-szerű rendszereken. Nincs probléma a Linux-szal, de túl sok mindenhol, elnyomja. Sokkal érdekesebb számomra, hogy egyszerű elektronikus eszközökkel dolgozzam a 8/16-bites mikrochipeken. Mindazonáltal nem fordulok el a valóságtól. Ha ugyanolyan hullámon akarok maradni egy igazi világgal, akkor a valós világban használt eszközöket kell használnom. Ellenkező esetben úgy néz ki, mintha egy autót vezetne egy gőzmotorral, csak azért, mert a belső égésű motor túl vicces, egész idő alatt használom. Ha a világ szerte a világ egy fejlettebb technológiához megy, meg kell mennie, szeretem, vagy sem. Különösen, ha azt szeretném, ha a blogom érdekel az emberek iránt, és releváns maradt. A projektemben okos otthon, tényleg találkoztam ezzel a problémával. Már létrehoztam egy helyi hálózati illesztőprogramot az MSP430 vezérlőrendszerére, és minden nagyon méltónak tűnik. Lényegében mindent megteszek, amire szüksége van az MSP430-as automatizálási rendszerhez. Mindazonáltal azt gondolom, hogy ezt csinálom? Megpróbálok, ha van egy villa leves, amikor van egy kanál? Talán a Linux egy megfelelőbb rendszer? Hadd magyarázzam. Ha abbahagyja és megnézi a jelenlegi helyzetet a technológiai fejlődés szerint 2012 novemberében. Megkérdezem magam, a mikrokontrollerek jóak és relevánsak, és relevánsak, összehasonlítva az on-chip rendszerekkel Linux használatával? Ha felsorolja a beágyazott rendszerekre vonatkozó projekteket, amelyek a fejemben jönnek, akkor: Drones, Robotok, Home Automatizálás, Motorvezérlők, érzékelők, karórák, 3D-s nyomtatók stb. Ebben az esetekben a beépített Linux alkalmas több, mint a mikrokontrollerek? És miért? Úgy gondolom, hogy három helyzet van, amikor a mikrokontroller a legjobb választás: ahol az instant (valós idejű) fontos az események számára; ahol rendkívül alacsony energiafogyasztás szükséges; És ahol a lehető legalacsonyabb zsetonokat kell használni. Kezdjük, az olcsó chipek használatát, nem olyan fontos számomra. Én magamban vagyok a hobbijaimban, és nem fogok versenyképes termékeket gyártani. Nem kell gondolkodnom a termelés átadására a slave munkaerővel, hogy versenyképes árat kapjunk az általam vágyakozó kisebb projektek számára. Boldog lennék, ha tudnám, naponta több mint egy táblát kicsomagolhatok, köszönhetően a képességeimnek! Például egy intelligens otthon projektjére fejleszthetem, távolról vezérelt kapcsolót. Bekapcsolhatja / kikapcsolhatja a fényt vagy valami mást. Ugyanakkor el tudok menni a helyi üzlet villamosmérnöki és megvásárolhatom ugyanazt a 20 dollárt, amelyet Kínában gyártanak. Meg tudom ölni ezt az árat, megpróbálom eladni a saját kapcsolót? Nem hiszem, hogy lehetséges. Ha erre gondolsz, akkor az otthoni automatizáláshoz szükséges egyéb dolgokhoz is vonatkozik. Hőmérséklet-érzékelők, füst, mozgás stb., Nagyon képes vagyok ugyanazt csinálni, de nem valószínű, hogy pénzügyi előnyöket is kivonhat. Ki törődik az ilyen dolgokat 75 dollárért, amikor 20 dollárért kereshetik őket a háztartási cikkekben? Ha tükrözzük a hobbija valamilyen előnyeinek kitermelését, jobb figyelmet fordítunk a drágább és összetettebb termékekre. Például egy otthoni automatizálási vezérlő vagy termosztát, általában több mint 100 dollár, és több szabadságot hagy az egyéni kreativitás számára, építhet egy, eladhatja szomszédjait, és akár valamit is kereshet. De a végső eszköz jövedelmezőbb árának elérése, nem jelenti azt, hogy a legolcsóbb mikrokontrollert kell használnia a Földön. Valójában rossz ötlet, mert A fejlesztési idő ugyanazokat a költségeket, valamint az alkalmazott alkatrészeket használja. Talán egy mikrokontroller olcsó, de több időt igényel a vezérlő kód írásához. Az idő pénz, és ha gyorsabban dolgozol, akkor ideje lesz többé elérni. Mindezek a gondolatok, összefoglalják, hogy jövedelmezőbb olyan intelligens otthoni rendszer kialakítása a Linuxon, mint a mikrokontrollereknél, a személyes preferenciáim ellenére, ne használja a Linuxot (szeretem egy alacsony szintű programozást, mint a szkriptek, a Linux megfogja az unatkozik). Ha visszatér a téma témájához, a mikrokontrollerek ára, akkor fontos tényező lehet a nagyvállalatok számára, hogy kiadják az új terméket, de egyéni szinten, ha megpróbálsz üzleti tevékenységet folytatni a kickstarter stílusában, ez a tényező Már nem olyan jelentős, hogy a gyors fejlődési idő, ami fontosabb, mint az összetevők költsége. Másrészt a mikrokontrollerek lehetnek a legjobb választás, mint a rendszer-on-chip, ha alacsony energiafogyasztás szükséges. Ilyen rendszerekben két pont van: maga a diagram alacsony fogyasztása, működés közben és egy rövid kezdési idő. Egy tipikus módja az akkumulátornak a kis eszközök számára az önkiállítás (leállítás). Amikor kikapcsolja a számítógépet a Linuxon, akkor szükség van egy tisztességes időre, hogy visszatérjen a munkába, néha néhány percig. Ez az idő nem elfogadható a beágyazott rendszerekhez. Ha egy mikrokontroller MSP430-ot vesz, akkor évek óta dolgozhat egy akkumulátorból. Stellaris Launchpad és Arduino esedékes elvben ugyanez is képesek ilyen, több energiát fogyasztanak, mint az MSP430, de még mindig nagyon kevés, mint a Raspberry Pi. Emellett az MSP430, azonnal elindulhat, a leállítás után. Így teljesen biztos vagyok benne, hogy minden olyan helyzetben, ahol alacsony feszültségű műveletekre van szükség, érdemes mikrokontrollereket használni. Számos különböző eszköz van az akkumulátoroknál, ahol ilyen szükség van. A harmadik esetben, ahogy azt mondtam, a mikrokontroller használata értelmesebb, mint a Linux, az azonnali reakciót igénylő műveletekben (valós idejű válasz). Úgy értem olyan eszközöket, mint a 3D nyomtatók és CNC gépek, tudom, hogy miről beszélek, ahogy sok időt szenteltem tanulni. Természetben nagy pontosságot igényelnek a munkában, ami valamivel kisebb, mint teljesen, attól függ, hogy a válaszidő a parancsok. Például, ha van egy körfűrész, amely pillanatnyilag egy fát vagy fémet vág, akkor nem tudja megállítani a folyamatot, mivel az a tény, hogy szabályozza azt, szünetet tart, hogy eldobja az adatokat a memóriából lemez vagy valami más ugyanabban a vénában. Bárki, aki egy számítógépet használt, ismeri a véletlenszerű gördülést, rendszeresen a szokásos munka során. És most képzeljük el, hogy van egy nagy fúrógép, fut egy számítógépen, amely hirtelen kezdődik, hogy ellenőrizze frissítést a Windows működése során, és a fúró, fúró keresztül az asztal, amelyen megéri, mert A számítógép elvesztette az irányítást. A PC-k és a chip rendszerek nem valós időben dolgoznak, legalábbis az ablakokkal, még a Linux is, hanem önmagukban is közelebb kerülnek hozzá. Példaként egy valós idejű tapasz a Linux kernel számára, és egy speciális CNC szoftver létrehozott erre a fajta. Nem vagyok elég ez a tapasz Linux, és nem tudom, milyen rugalmas, hogy teljes időbeli események. De azt hiszem, ez csak egy lehetséges alternatíva, mert Linux, bármilyen foltok esett rá, soha nem fogják megverni a mikrokontrollereket ezen a területen, a megszakítási rendszerek miatt. Csak az alacsony feszültségű eszközök, a valós idejű műveletek és az alacsony költségű eszközök területei továbbra is mikrokontrollerek maradnak. Nem függ attól, hogy a mikrokontrollerek szórakoztatóbbnak tűnhetnek, mint a számítógép. Ez az, amit meg kell versenyeznie. Fordítás angol eredeti üzenet Void Task1 () (míg (1) (Portb.0 \u003d! Portb.0, várakozás (100););););
Create_task (feladat1, 1, aktív);
#Inlude.
Void Task2 (üresség) (míg (1) (ha (mute \u003d\u003d 0) // Ha megengedett, hogy játszhasson (IF_CH2 [n_n] \u003d\u003d 0) // Ha egy szünetet vársz, nem játszunk semmit (Portb.4 \u003d 0; várjon (5);) más (Portb.4 \u003d! Portb.4; // ha nem szünetel, húzza meg a lábat a kívánt frekvenciával Várjon (note_ch2 [n_n]); )))))
Void Task3 (Void) (Várjon (1) (várjon (1500); // lejátszani a jegyzetek minimális számát mert (néma \u003d 0; néma<
500
;
mute++
)
// Kattintson a jegyzetre, hogy ne egyesítse (Portb.3 \u003d 0, Portb.4 \u003d 0;); Néma \u003d 0; // Állítsa be a hangjelzést n_n ++; // Menjen a következő megjegyzésre ha (n_n \u003d\u003d n_max) // Ha mindent körben játszottak (n_n \u003d 0;))))))
Részben ezt a Stellaris Launchpad és az Arduino megjelenése okozza. Mindkettő 32 bites mikrokontrollereken alapul, és sok szempontból nagyon hasonló. Tanulmányoztam a specifikációt (adatlap) mindkettő számára, és bár azok tisztességesen különböznek az árban, azokat egy célközönségre tervezték. Arra gondoltam, hogy mit tudtam MSP430-ban mozogni a Stellaris-hoz, és még egy alapvetően különböző rendszerre is átkerülhet, hogy olyan, mint a málna pi, a mikrokontrollerek helyett.
Összefoglalva azt akarom mondani, hogy sok időt töltöttem arra, hogy olyan területeket találjak, ahol a mikrokontrollerek használata a projektjeimben előnye. És minden úgy néz ki, mint a világ uralomának korszaka, a Raspberry Pi és a BeagleBones. Ez a jelenlegi helyzet a DIY közösségben. A legtöbb esetben gyorsabban és könnyebben fejlődnek ezeken a rendszereken, így gyakran a legjobb választás a legtöbb projekt számára.
