Pitanje:
RTOS za ugrađene sustave
Kortuk
2009-12-03 02:59:25 UTC
view on stackexchange narkive permalink

Vidio sam mnogo članaka koji mi govore da bih trebao koristiti RTOS za upravljanje vremenom i upravljanje resursima. Moje vrijeme nije dopuštalo moja vlastita istraživanja, pa sam došao po savjet za chiphacker.

Koristim mikrokontrolere s malim resursima (MSP430, PIC) i tražio sam RTOS-ove koje mogu koristiti.

Do točke:

  1. Troškovi resursa sustava
  2. Prednosti sustava
  3. Nedostaci sustava
  4. Trikovi implementacije
  5. Situacije u kojima bi se RTOS trebao / ne bi smio koristiti.

Ne koristim sustave poput arduina, projekti s kojima radim ne mogu podnijeti troškove takvog sustava.

Zbunjen sam zbog čega je ovo dobilo negativan glas. Ako bi mi birač mogao dati povratne informacije, pokušat ću izbjeći takav postupak u budućnosti.
isto tako. Super je pitanje ....
Prihvatio sam pitanje jer sam, čak i misleći da je ovo otvoreno, imao niz izvrsnih odgovora i želio sam nagraditi barem jednog pisca za trud.
Devet odgovori:
#1
+29
Jason S
2009-12-03 11:07:38 UTC
view on stackexchange narkive permalink

Nisam imao puno osobnog iskustva s RTOS-om osim QNX-a (što je u cjelini sjajno, ali nije jeftino, a imao sam stvarno loše iskustvo s određenim dobavljačem ploče i stavom QNX-a koji nas ne brine) za sustave koji nisu njihovi najčešći) koji je prevelik za PIC-ove i MSP430-ove.

RTOS će vam koristiti u područjima kao što su

  • upravljanje niti / raspoređivanje niti
  • međusobna komunikacija + sinkronizacija
  • Ulazno-izlazni na sustavima sa stdin / stdout / stderr ili serijskim priključcima ili ethernet podrškom ili datotečnim sustavom (uglavnom MSP430 ili PIC) , osim za serijske portove)

Za periferne uređaje PIC-a ili MSP430: za serijske portove koristio bih međuspremnik prstena + prekida ... nešto što napišem jednom po sustavu i jednostavno ponovno upotrijebim ; ostale periferne uređaje mislim da ne biste pronašli veliku podršku od RTOS-a jer su toliko specifični za dobavljača.

Ako vam je potrebno vrijeme koje je čvrsto do mikrosekunde, RTOS će vjerojatno pobijediti ne pomaže - RTOS-ovi imaju ograničeno vrijeme, ali u rasporedu obično imaju vremensko podrhtavanje zbog kašnjenja prebacivanja konteksta ... QNX pokrenut na PXA270 imao je podrhtavanje u desecima mikrosekundi, maksimalno 100-200us, pa ne bih koristite ga za stvari koje moraju raditi brže od oko 100 Hz ili kojima je potrebno mjerenje vremena puno preciznije od oko 500us. Za takve stvari vjerojatno ćete morati primijeniti vlastito rukovanje prekidima. Neki će se RTOS-ovi lijepo igrati s tim, a drugima će to predstavljati kraljevsku bol: vaše vrijeme i njihovo vrijeme možda neće moći dobro suživjeti.

Ako vrijeme / raspoređivanje nije previše složeno, možda će vam biti bolje koristiti dobro dizajnirani državni stroj. Toplo bih preporučio čitanje Praktičnih dijagrama stanja na C / C ++ ako to već niste učinili. Ovaj smo pristup koristili u nekim našim projektima u kojima radim i on ima neke stvarne prednosti u odnosu na tradicionalne državne strojeve za upravljanje složenošću .... što je stvarno jedini razlog zbog kojeg trebate RTOS.

Radim u startup tvrtki u kojoj su najiskusniji momci s ugrađenim sustavima tek na fakultetu (tj. Ja i drugi koji sa mnom surađujem otprilike 2 godine). Tijekom radnog tjedna provodim vrlo velik dio podučavajući se industrijskoj praksi. Kako sam čitao, informiran sam za sve, osim za naš sustav s najnižom cijenom, RTOS bi bio veliko poboljšanje.
Čini se da postoji RTOS sustav s vrlo malim resursima za stvari poput PIC-a i MSP430-a koji mogu pomoći u stvaranju determinističkog sustava od vrlo složenog, što također uvelike čisti naše upravljanje držanjem odvojenih modula. Bio sam dio dvočlanog tima koji je učinkovito izgradio terenski sustav za prikupljanje i usmjeravanje podataka. Sad kad pogledam RTOS, vidim da je savršen za ono što smo dizajnirali.
Žao nam je što koristim tri mjesta za pošta, vaš je odgovor vrlo koristan, tražim rješenje s vrlo malo resursa, ali ove su informacije dragocjene, hvala na pomoći.
ne brinite zbog broja komentara (IMHO jedna stvar koja nedostaje okviru StackExchange je podrška za rasprave ... Q / A format pokriva većinu stvari, ali neke ne) zvuči kao da se prilično dobro snalazite u tome što tražite. Nisam gledao FreeRTOS koji je Steve spomenuo, ali ako je prebačen na mikrokontrolere niske klase, možda će izvršiti upravljanje raspoređivanjem koje vam treba.
Čini se da sprema stanje svake niti kroz stog (nešto poput 50 naredbi push / pull) i može obraditi vremenske prekide. Moj bi sustav obično koristio prekid priključka za prebacivanje niti, ali zadatak izgleda izvedivo. Želim da se ova vrsta stranice vodi u boljem formatu.
#2
+26
Steve Melnikoff
2009-12-03 06:05:08 UTC
view on stackexchange narkive permalink

Jeste li probali FreeRTOS? Besplatno je (podložno T&C), a prenijeto je i na MSP430 i na nekoliko ukusa PIC-a.

Mali je u usporedbi s nekim drugima, ali to ga također olakšava naučiti, pogotovo ako prije niste koristili RTOS.

Dostupna je (neslobodna) komercijalna licenca, kao i verzija IEC 61508 / SIL 3.

Hvala vam na toni, razmotrit ću je kroz tjedan dana, pitanje ću ostaviti otvorenim za druge odgovore, ali vi ste od velike pomoći!
#3
+12
Jay Atkinson
2010-06-04 02:35:03 UTC
view on stackexchange narkive permalink

Upravo sam saznao za NuttX RTOS, koji može raditi čak i na 8052 (8-bitnom) sustavu. Nema puno luka, ali izgleda zanimljivo. POSIX može biti plus, jer može učiniti neki vaš kod malo prenosivijim ako prijeđete na bolji procesor i želite pokrenuti Linux ili QNX u stvarnom vremenu.

Ne znam i ja imam iskustva s komercijalnim RTOS-ovima, ali već godinama koristim domaće! Sjajni su u tome što vam pomažu podijeliti razvoj koda među mnogim programerima, jer u osnovi svaki od njih može dobiti "zadatak" ili "nit". I dalje se morate koordinirati i netko mora nadgledati cijeli projekt kako bi bio siguran da svaki zadatak može odrediti krajnji rok.

Također vam preporučujem da istražite Ocijenite monotonu analizu ili RMA kada koristite RTOS. To će vam pomoći da zajamčite da će vaši kritični zadaci ispuniti svoje rokove.

Također bih pogledao i programski okvir QP-nano Mire Sameka koji može raditi sa ili bez RTOS i dalje vam pružaju mogućnost u stvarnom vremenu. Pomoću nje dijelite svoj dizajn na hijerarhijske automate umjesto tradicionalnih zadataka. Jason S spomenuo je Mirovu knjigu u svom postu. Izvrsno štivo!

#4
+9
supercat
2011-03-16 09:06:07 UTC
view on stackexchange narkive permalink

Jedna stvar koju sam smatrao korisnom na većini strojeva je jednostavan prebacivač stogova. Zapravo nisam napisao niti jedan za PIC, ali očekivao bih da će pristup dobro funkcionirati na PIC18 ako obje / sve niti koriste ukupno 31 ili manje razina sloga. Na 8051 je glavna rutina:

 _taskswitch: xch a, SP xch a, _altSP xch a, SP ret 

Na PIC-u zaboravljam ime pokazivača stoga , ali rutina bi bila nešto poput:

 _taskswitch: movlb _altSP >> 8 movf _altSP, w, b movff _STKPTR, altSP movwf _STKPTR, c return 

Na početku vašeg program, pozovite rutinu task2 () koja učitava altSP s adresom zamjenskog steka (16 bi vjerojatno dobro funkcioniralo za PIC18Fxx) i pokreće petlju task2; ova se rutina nikada ne smije vratiti, inače će stvari umrijeti bolnom smrću. Umjesto toga, trebao bi nazvati _taskswitch kad god želi dati kontrolu nad primarnim zadatkom; primarni zadatak bi tada trebao nazvati _taskswitch kad god želi popustiti sekundarnom zadatku. Često će netko imati slatke male rutine poput:

 void delay_t1 (nepotpisani kratki val) {do taskwitch (); while ((nepotpisani kratki) (milisekunda_takta - val)> 0xFF00); } 

Imajte na umu da prebacivač zadataka nema nikakvih mogućnosti 'čekati uvjet'; sve što podržava je spinwait. S druge strane, prebacivanje zadataka je toliko brzo da će se pokušaj prebacivanja zadataka () dok drugi zadatak čeka da istekne tajmer prebaciti na drugi zadatak, provjeriti tajmer i vratiti se brže od tipičnog prebacivača zadataka utvrdio bi da ne treba prebacivati ​​zadatke.

Imajte na umu da kooperativno višezadaćnost ima određena ograničenja, ali izbjegava potrebe za puno zaključavanja i drugog koda vezanog uz mutex u slučajevima kada invarijante koji su privremeno poremećeni mogu se brzo uspostaviti.

(Uredi): Nekoliko upozorenja u vezi sa automatskim varijablama i slično:

  1. ako se rutina koja koristi prebacivanje zadataka poziva iz obje niti, općenito će biti potrebno sastaviti dvije kopije rutine (moguće #uključivanjem iste izvorne datoteke dva puta, s različitim #define izrazima). Svaka zadana izvorna datoteka sadržavat će kôd samo za jednu nit ili će sadržavati kod koji će se kompajlirati dva puta - jednom za svaku nit - pa mogu koristiti makronaredbe poput "#define delay (x) delay_t1 (x)" ili #define delay (x) delay_tx (x) ", ovisno o tome koju nit koristim.
  2. Vjerujem da će sastavljači PIC-a koji ne mogu" vidjeti "pozvanu funkciju pretpostaviti da takva funkcija može zbrisati sve i sve CPU registri, izbjegavajući tako potrebu za spremanjem bilo kakvih registara u rutinu prebacivanja zadataka [lijepa prednost u usporedbi s preventivnim multitaskingom]. Svatko tko razmišlja o sličnom prebacivaču zadataka za bilo koji drugi CPU mora biti upoznat s konvencijama registara koje se koriste. prije prebacivanja zadatka i iskakanja nakon njih jednostavan je način za brigu o stvarima, pod pretpostavkom da postoji odgovarajući prostor za stog.

Zajedničko multitasking ne dopušta potpuno izbjegavanje problema zaključavanja i slično, ali stvarno uvelike pojednostavljuje stvari. U preventivnom RTOS-u s kompaktnim skupljanjem smeća r, na primjer, potrebno je dopustiti da se objekti prikvače. Kada se koristi kooperativni prebacivač, to nije potrebno pod uvjetom da kod pretpostavlja da se GC objekti mogu pomicati svaki put kad se pozove taskwitch (). Sakupljač za zbijanje koji se ne mora brinuti zbog prikvačenih predmeta može biti puno jednostavniji od onog koji to čini.

Strašan odgovor. Mislim da bi bilo zanimljivo dobiti neke poveznice na resursima za pristupanje vlastitom RTOS-u. Ovdje sam se stvarno fokusirao na dobivanje visokokvalitetnog RTOS-a od dobavljača koji se trudio osigurati stvarno vrijeme, ali ovo bi za mene možda bio zabavan hobistički projekt.
Super, nikada na zadatke nisam mislio kao na samo prebacivanje SP-a ...
@JGord: Radio sam malene prebacivače zadataka na 8x51 i na TI DSP-u. Gore prikazani 8051 dizajniran je za točno dva zadatka. DSP se koristi s četiri i malo je složeniji. Upravo sam imao ludu ideju: čovjek je mogao riješiti četiri zadatka jednostavnim korištenjem tri prekidača zadataka. Svaki put kad se jedan od prva dva zadatka želi prebaciti na jedan zadatak, trebao bi nazvati TaskSwitch1 i TaskSwitch2. Kada jedan od druga dva zadatka želi prebacivanje zadataka, trebao bi nazvati Taskswitch1 i Taskswitch3. Pretpostavimo da kôd započinje u stogu0, a svaki prekidač zadataka postavlja se s pripadajućim brojem stoga.
@JGord: Hmm ... to baš i ne uspijeva; čini se da daje trosmjernu kružnu kombinaciju i ignorira treću sklopku. Pa, eksperimentirajte i mislim da ćete vjerojatno pronaći dobru formulu.
#5
+7
uɐɪ
2009-12-08 22:16:22 UTC
view on stackexchange narkive permalink

Koristio sam Salvo na uređaju MSP430. Ovo je bilo vrlo malo za resurse procesora i, pod uvjetom da poštujete pravila implementacije, vrlo je jednostavno za upotrebu i pouzdano. Ovo je suradnički OS i zahtijeva da se prebacivači zadataka izvode na razini poziva vanjske funkcije funkcija zadataka. Ovo ograničenje omogućuje OS-u rad na vrlo malim memorijskim uređajima bez korištenja ogromne količine prostora stoga za održavanje konteksta zadataka.

Na AVR32 koristim FreeRTOS. Ponovno vrlo pouzdan do sada, ali imao sam nekih odstupanja u konfiguraciji / verziji između verzije koju FreeRTOS objavljuje i verzije isporučene s Atmel okvirom. To, međutim, ima prednost što je besplatno!

#6
+5
Amos
2009-12-09 17:09:18 UTC
view on stackexchange narkive permalink

Prosinačko izdanje Svakodnevne praktične elektronike ima dio 3 serije o operativnim sustavima u stvarnom vremenu za PIC-ove (u stupcu PIC n 'Mix) i sadrži detalje o postavljanju FreeRTOS-a s MPLAB-om i PICKit 2. Čini se da su prethodna dva članka (koja nisam vidio) raspravljali o zaslugama različitih RTOS-a i stavili se na FreeRTOS. Nakon što trenutni članak postavi razvojno okruženje, oni počinju s dizajniranjem binarnog digitalnog sata. Čini se da postoji još barem jedan dio o ovoj temi.

Nisam siguran koliko je EPE dostupan u SAD-u, ali čini se da postoji američka trgovina na koju se vodi njihova web stranica i možda postoje dostupne elektroničke kopije.

#7
+4
Jeanne Pindar
2010-06-04 07:36:57 UTC
view on stackexchange narkive permalink

CCS kompajler za PIC dolazi s jednostavnim RTOS-om. Nisam probao, ali ako imate ovaj kompajler, bilo bi lako eksperimentirati.

Zapravo sam ovo probao kao prvi. To nije RTOS u bilo kojem stvarnom značenju riječi. Ni na koji način nije preventivno. Potrebna je redovita upotreba naredbi yield, tako da RTOS može odlučiti tko slijedi, a morate ih stalno namjerno stavljati u slučaju da drugi program treba preuzeti.
Mislim da se i dalje zove RTOS. Samo zvuči kao da ima kooperativni rokovnik umjesto potpuno preventivnog planera.
Da, to je još uvijek tehnički RTOS, ali imao sam i još uvijek imam vrlo malu vrijednost za njega. Znam da je to osobna stvar, ali meni to treba biti preventivno da bi bilo vrijedno. Još uvijek +1, jer je to bio dobar odgovor i vrijednost.
#8
+3
davidcary
2010-06-10 02:28:42 UTC
view on stackexchange narkive permalink

Usko povezano pitanje: https://stackoverflow.com/questions/1624237/multithreading-using-c-on-pic18

Hvala! Čini se da većina ljudi nije dobila pitanje, ali svejedno je zanimljivo.
Objavio sam pitanje na SO pozivajući korisnika da pomogne E&R-u!
Mislim da smo pitanje "dobili" na SO-u, postavljalo je nešto drugo, ali vezano uz ovo pitanje. Što se tiče vašeg komentara o certifikaciji tamo; to ovisi o mnogim stvarima. Gledajući ovdje odgovore, sviđa mi se odgovor DoxaLogosa koji se odnosi na QP-nano; moje me iskustvo navodi da preferiram kod upravljan događajima nad nitima i implicitno prebacivanje konteksta niti.
#9
+2
Rocketmagnet
2011-01-25 04:32:27 UTC
view on stackexchange narkive permalink

Niste rekli puno o svojoj prijavi. Hoćete li koristiti RTOS, puno ovisi o tome što trebate učiniti u PIC-u. Ako ne radite nekoliko različitih asinkronih stvari, koje zahtijevaju stroge vremenske granice ili ako se pokreće nekoliko niti, tada bi RTOS mogao biti pretjeran.

Postoji mnogo načina za organiziranje vremena na mikrokontroleru, ovisno o tome što najvažnije:

  1. Stalna brzina sličica: Za PIC koji pokreće servo kontroler koji na primjer mora raditi na 1000Hz. Ako za izvršavanje PID algoritma treba manje od 1 ms, ostatak milisekunde možete koristiti za obavljanje drugih zadataka, poput provjere CAN sabirnice, očitavanja senzora itd.

  2. Svi prekidi: Sve što se događa u PIC-u pokreće se prekidom. Prekidi se mogu odrediti prema važnosti događaja.

  3. Zalijepite ga u petlju i učinite sve što je brže moguće. Možda ćete otkriti da ovo pruža odgovarajuće vremenske okvire.

Razumijem druge metode, ali želim se proširiti na RTOS. Izvodit ću više zadataka i imati tvrdi sustav u stvarnom vremenu, ali spreman sam započeti bez zahtjeva za tvrdim vremenom. Hvala vam što ste odvojili vrijeme za odgovor, ali želim naučiti RTOS kako bih ga mogao koristiti u situaciji velike potražnje.


Ova pitanja su automatski prevedena s engleskog jezika.Izvorni sadržaj dostupan je na stackexchange-u, što zahvaljujemo na cc by-sa 2.0 licenci pod kojom se distribuira.
Loading...