Kysymys:
RTOS sulautetuille järjestelmille
Kortuk
2009-12-03 02:59:25 UTC
view on stackexchange narkive permalink

Olen nähnyt monia artikkeleita, joissa kerrotaan, että minun pitäisi käyttää RTOS: a ajanhallintaan ja resurssien hallintaan. Aikani ei ole sallinut omaa tutkimusta, joten käyn neuvoja hakkerin kanssa.

Käytän vähän resursseja käyttäviä mikrokontrollereita (MSP430, PIC) ja etsin RTOS: ita, joita voin käyttää.

Pisteeseen:

  1. Järjestelmän resurssikustannukset
  2. Järjestelmän edut
  3. Järjestelmän haitat
  4. Toteutusvinkit
  5. Tilanteet, joissa RTOS: ää ei pitäisi / ei tule käyttää.

En käytä järjestelmiä, kuten arduino, projektit, joissa työskentelen, eivät voi tukea tällaisen järjestelmän kustannuksia. p>

Olen hämmentynyt siitä, mihin tämä sai äänestyksen alaspäin. Jos äänestäjä voisi antaa minulle palautetta, yritän välttää tällaista toimintaa tulevaisuudessa.
sama. Se on hieno kysymys ....
Hyväksyin kysymyksen, koska vaikka ajattelin, että tämä on avointa, minulla oli useita hienoja vastauksia ja halusin palkita ainakin yhden kirjailijan ponnistelusta.
Yhdeksän vastused:
#1
+29
Jason S
2009-12-03 11:07:38 UTC
view on stackexchange narkive permalink

Minulla ei ole ollut paljon henkilökohtaista kokemusta muiden RTOS-laitteiden kuin QNX: n kanssa (mikä on kaiken kaikkiaan hienoa, mutta se ei ole halpaa, ja minulla on ollut todella huono kokemus tietyn korttimyyjän ja QNX: n välitön asenne muille kuin niiden yleisimmille järjestelmille), joka on liian suuri PIC- ja MSP430-järjestelmille.

Mistä hyötyä RTOS: sta on esimerkiksi

  • ketjujen hallinta / aikataulutus
  • ketjujen välinen viestintä + synkronointi
  • I / O järjestelmissä, joissa on stdin / stdout / stderr- tai sarjaportit tai ethernet-tuki tai tiedostojärjestelmä (ei suurimmaksi osaksi MSP430 tai PIC , lukuun ottamatta sarjaportteja)

PIC- tai MSP430-oheislaitteille: sarjaportteihin käytän rengaspuskuria + keskeytyksiä ... jotain, jonka kirjoitan kerran järjestelmää kohti ja käytän vain uudelleen ; muita oheislaitteita, en usko, että löytäisit paljon tukea RTOS: lta, koska ne ovat niin toimittajakohtaisia.

Jos tarvitset mikrosekunnin ajan kovaa ajoitusta, RTOS todennäköisesti voitti ' Ei apua - RTOS: t ovat rajoittaneet ajoitusta, mutta tyypillisesti ajoituksen värinää on aikataulussa kontekstinvaihtoviiveiden takia ... PXA270: llä käynnissä olevassa QNX: ssä oli värinää tyypillisissä kymmenissä mikrosekunnissa, enintään 100-200 us, joten en haluaisi käytä sitä tavaroihin, joiden on oltava nopeampi kuin noin 100 Hz tai jotka tarvitsevat ajoituksen paljon tarkempaa kuin noin 500 us. Tällaisia ​​asioita varten sinun on todennäköisesti toteutettava oma keskeytysten käsittely. Jotkut RTOS: t pelaavat hienosti sen kanssa, ja toiset tekevät siitä kuninkaallisen tuskan: ajoitus ja heidän ajoitus eivät välttämättä pysty olemaan rinnakkain.

Jos ajoitus / aikataulutus ei ole liian monimutkainen, saatat olla parempi käyttää hyvin suunniteltuja tilakoneita. Suosittelen lämpimästi lukemaan Practical Statecharts in C / C ++, jos et ole jo tehnyt niin. Olemme käyttäneet tätä lähestymistapaa joissakin projekteissani, joissa työskentelen, ja sillä on todellisia etuja perinteisiin valtion koneisiin verrattuna monimutkaisuuden hallintaan .... mikä on oikeastaan ​​ainoa syy, miksi tarvitset RTOS: n.

Työskentelen startup-yrityksessä, jossa kokeneimmat sulautettujen järjestelmien kaverit ovat vasta yliopistosta (eli itse ja toinen kaveri, joka on työskennellyt kanssani noin 2 vuotta). Vietän suuren osan ajasta opettaessani itselleni alan käytäntöjä työviikkoni aikana. Kuten olen lukenut, minua on informoitu kaikille, mutta halvin järjestelmämme, RTOS olisi suuri parannus.
PIC: iden ja MSP430: n kaltaisille asioille näyttää olevan hyvin vähän resursseja sisältävä RTOS-järjestelmä, joka voi auttaa luomaan deterministisen järjestelmän hyvin monimutkaisesta järjestelmästä, mikä myös puhdistaa huomattavasti moduulien erottamisen hallintaa. Olen ollut osa kahden miehen tiimiä, joka rakensi tehokkaasti kenttätiedonkeruu- ja reititysjärjestelmän. Nyt kun katson RTOS: ta, näen sen olevan täydellinen suunnittelemallemme.
Anteeksi kolmen postituspaikan käytöstä, vastauksestasi on hyötyä. Etsin hyvin vähän resursseja sisältävää ratkaisua, mutta nämä tiedot ovat arvokkaita, kiitos avusta.
älä huoli kommenttien määrästä (IMHO: sta yksi asia, josta StackExchange-kehys puuttuu, on tuki keskusteluille ... Q / A-muoto kattaa useimmat asiat, mutta ei joitain) ... kuulostaa siltä, ​​että sinulla on melko hyvä käsitys siitä, mitä olet etsimässä. En ole katsonut Stevein mainitsemia FreeRTOS: eja, mutta jos se on siirretty matalan luokan mikro-ohjaimille, se ehkä suorittaa tarvitsemasi aikataulutuksen hallinnan.
Se näyttää säästävän jokaisen ketjun tilan pinon kautta (jotain 50 push / pull-lauseketta) ja pystyy käsittelemään ajastettuja keskeytyksiä. Järjestelmäni käyttäisi normaalisti porttikeskeytystä langanvaihtoon, mutta tehtävä näyttää toteutettavalta. Toivon, että tämäntyyppinen sivustokäsitelty keskustelu olisi paremmassa muodossa.
#2
+26
Steve Melnikoff
2009-12-03 06:05:08 UTC
view on stackexchange narkive permalink

Oletko kokeillut FreeRTOSia? Se on ilmainen (T&C: n alainen), ja se on siirretty sekä MSP430: een että useisiin PIC-makuihin.

Se on pieni verrattuna joihinkin muihin, mutta tämä tekee siitä myös helppoa oppia, varsinkin jos et ole käyttänyt RTOS: ta aiemmin.

Saatavilla on (ei-ilmainen) kaupallinen lisenssi sekä IEC 61508 / SIL 3 -versio.

Kiitos paljon, tutkin sitä viikon sisällä, jätän kysymyksen avoimeksi muille vastauksille, mutta sinä olet suuri apu!
#3
+12
Jay Atkinson
2010-06-04 02:35:03 UTC
view on stackexchange narkive permalink

Sain juuri tietää NuttX RTOS: sta, joka voi toimia jopa 8052 (8-bittinen) järjestelmässä. Sillä ei ole paljon portteja, mutta se näyttää mielenkiintoiselta. POSIX voi olla plus, koska se voi tehdä joistakin koodistasi hieman kannettavampia, jos siirryt lievempään prosessoriin ja haluat käyttää reaaliaikaista linuxia tai QNX: ää.

En minulla on kokemusta kaupallisista RTOS: ista, mutta olen käyttänyt kotitekoisia vuosia! Ne auttavat sinua jakamaan koodikehityksesi monien ohjelmoijien kesken, koska he voivat olennaisesti kumpikin saada "tehtävän" tai "ketjun" omalle puolelleen. Sinun on vielä koordinoitava ja jonkun on valvottava koko projektia varmistaakseen, että jokainen tehtävä voi asettaa sen määräajan.

Suosittelen myös, että tutkit Rate Monotonic Analysis: n tai RMA: n käyttäessäsi RTOS: ää. Tämä auttaa sinua takaamaan, että kriittiset tehtävät noudattavat niiden määräaikoja.

Tutkisin myös Miro Samekin tapahtumapohjaista QP-nano -ohjelmointikehystä, joka voi toimia joko ilman tai RTOS ja silti antaa sinulle reaaliaikaisen mahdollisuuden. Sen avulla jaat suunnittelun hierarkkisiin tilakoneisiin perinteisten tehtävien sijaan. Jason S mainitsi Miron kirjan postissaan. Erinomainen luku!

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

Yksi asia, jonka olen löytänyt hyödylliseksi useille koneille, on yksinkertainen pinonvaihtaja. En ole itse kirjoittanut yhtä PIC: lle, mutta olettaa, että lähestymistapa toimisi hienosti PIC18: lla, jos molemmat / kaikki säikeet käyttävät yhteensä 31 tai vähemmän pinotasoja. 8051: n päärutiini on:

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

PIC: ssä unohdan pinon osoittimen nimen , mutta rutiini olisi jotain:

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

soita rutiini task2 (), joka lataa altSP: n vaihtoehtoisen pinon osoitteella (16 toimisi todennäköisesti PIC18Fxx: lle) ja suorittaa task2-silmukan; tätä rutiinia ei saa koskaan palata, muuten asiat kuolevat tuskallisessa kuolemassa. Sen sijaan sen tulisi kutsua _taskswitch aina, kun se haluaa ohjata ensisijaista tehtävää; ensisijaisen tehtävän tulisi sitten kutsua _taskswitch aina, kun se haluaa antaa periksi toissijaiselle tehtävälle. Usein on pieniä söpöjä rutiineja, kuten:

 void delay_t1 (allekirjoittamaton lyhyt val) {do taskwitch (); while ((allekirjoittamaton lyhyt) (millisekunnin kello - val)> 0xFF00); } 

Huomaa, että tehtävänvaihtajalla ei ole mitään keinoa odottaa ehtoa; kaikki se tukee on spinwait. Toisaalta tehtäväkytkin on niin nopea, että tehtäväkytkimen () yrittäminen toisen tehtävän odottaessa ajastimen päättymistä vaihtaa toiseen tehtävään, tarkistaa ajastimen ja vaihtaa takaisin nopeammin kuin tyypillinen tehtävänvaihtaja määrittäisi, että sen ei tarvitse vaihtaa tehtäviä.

Huomaa, että yhteistyöhön perustuvassa monitoiminnossa on joitain rajoituksia, mutta se välttää paljon lukitusta ja muuta mutexiin liittyvää koodia tapauksissa, joissa väliaikaisesti häiriintyneet invariantit voidaan palauttaa nopeasti.

(Muokkaa): Pari varoitusta automaattisista muuttujista ja vastaavista:

  1. jos tehtävänvaihtoa käyttävä rutiini kutsutaan molemmista säikeistä, on yleensä tarpeen koota kaksi rutiinin kopiota (mahdollisesti # sisällyttämällä sama lähdetiedosto kahdesti eri #define -käskyillä). Mikä tahansa annettu lähdetiedosto joko sisältää koodin vain yhdelle säikeelle tai sisältää koodin, joka käännetään kahdesti - kerran jokaiselle säikeelle - joten voin käyttää makroja, kuten "#define delay (x) delay_t1 (x)" tai #define delay (x) delay_tx (x) "riippuen siitä, mitä ketjua käytän.
  2. Uskon, että PIC-kääntäjät, jotka eivät" näe "kutsuttavaa toimintoa, olettavat, että tällainen funktio saattaa roskakoriin kaikki Suoritinrekisterit välttäen siten tarvetta tallentaa rekistereitä tehtävänvaihtorutiiniin [mukava etu ennalta ehkäisevään monitoimityöhön verrattuna] .Kaikkien, jotka harkitsevat samanlaista tehtäväkytkintä muille keskusyksiköille, on oltava tietoisia käytössä olevista rekisterikäytännöistä. Ennen tehtävänvaihtoa ja niiden avaamista on helppo tapa hoitaa asiat olettaen, että pinotilaa on riittävästi. yksinkertaistaa asioita huomattavasti: ennaltaehkäisevässä RTOS: ssa, jossa on tiivistävä roskakoko Esimerkiksi r on tarpeen sallia esineiden kiinnittäminen. Kun käytetään osuuskytkintä, tämä ei ole välttämätöntä, jos koodi olettaa, että GC-objektit voivat liikkua milloin tahansa tehtäväkytkintä () kutsutaan. Tiivistävä keräilijä, jonka ei tarvitse huolehtia kiinnitetyistä esineistä, voi olla paljon yksinkertaisempi kuin se.
Mahtava vastaus. Mielestäni olisi mielenkiintoista saada joitain linkkejä resursseista, jotka koskevat omaa RTOS: ääni. Keskityin täällä todella saamaan korkealaatuisen RTOS: n myyjältä, joka on tehnyt kovan reaaliaikaisen työn, mutta tämä saattaa olla hauska harrastajaprojekti itselleni.
Viileä, ei koskaan ajatellut tehtäviä vain SP: n vaihtamisesta ...
@JGord: Olen tehnyt pieniä tehtävänvaihtimia 8x51: ssä ja TI DSP: ssä. Yllä esitetty 8051 on suunniteltu tarkalleen kahteen tehtävään. DSP: tä käytetään neljän kanssa ja se on hieman monimutkaisempi. Minulla oli kuitenkin vain hullu idea: voisi hoitaa neljä tehtävää yksinkertaisesti käyttämällä kolmea tehtäväkytkintä. Aina kun toinen kahdesta ensimmäisestä tehtävästä haluaa vaihtaa tehtävää, sen tulisi kutsua TaskSwitch1 ja TaskSwitch2. Kun toinen kahdesta tehtävästä haluaa tehtäväkytkimen, sen tulisi kutsua Taskswitch1 ja Taskswitch3. Oletetaan, että koodi alkaa pinosta0, ja jokainen tehtävänvaihtaja asetetaan vastaavalla pinonumerolla.
@JGord: Hmm ... se ei aivan toimi; se näyttää tuottavan 3-suuntaisen edestakaisen robinin ja jättää huomiotta kolmannen kytkimen. No, kokeile ja luulen, että löydät todennäköisesti hyvän kaavan.
#5
+7
uɐɪ
2009-12-08 22:16:22 UTC
view on stackexchange narkive permalink

Olen käyttänyt Salvoa MSP430: ssa. Tämä oli erittäin vähäistä prosessoriresursseissa, ja edellyttäen, että noudatat täytäntöönpanosääntöjä, erittäin helppokäyttöinen ja luotettava. Tämä on osuustoiminnallinen käyttöjärjestelmä ja edellyttää, että tehtäväkytkimet suoritetaan tehtäväfunktioiden ulomman toimintakutsun tasolla. Tämän rajoituksen ansiosta käyttöjärjestelmä voi toimia hyvin pienissä muistilaitteissa käyttämättä valtavia määriä pinotilaa ylläpitää tehtäväkonteksteja.

AVR32: ssä käytän FreeRTOSia. Jälleen erittäin luotettava toistaiseksi, mutta minulla on ollut joitain kokoonpano- / versioeroja FreeRTOS: n julkaiseman version ja Atmel-kehyksen mukana toimitetun version välillä. Tällä on kuitenkin se etu, että se on ilmainen!

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

Joulukuussa julkaistussa Everyday Practical Electronics -lehdessä on osa PIC: n reaaliaikaisia ​​käyttöjärjestelmiä koskevasta sarjassa (PIC n 'Mix -sarakkeessa), ja siinä on yksityiskohtia FreeRTOS: n määrittämisestä MPLAB: n ja PICKit 2. Kahdessa edellisessä artikkelissa (joita en ole nähnyt) näyttää olevan keskusteltu erilaisten RTOS-tiedostojen ansioista ja ratkaistu FreeRTOS: lla. Kun nykyinen artikkeli on määrittänyt kehitysympäristön, he jatkavat binaarisen digitaalisen kellon suunnittelua. Näyttää siltä, ​​että tässä aiheessa on vielä ainakin yksi osa.

En ole varma, kuinka EPE on saatavilla Yhdysvalloissa, mutta näyttää siltä, ​​että heidän sivustoiltaan on linkitetty Yhdysvaltain myymälä, ja sähköisiä kopioita saattaa olla saatavilla.

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

PIC: n CCS-kääntäjä toimittaa yksinkertaisen RTOS: n. En ole kokeillut sitä, mutta jos sinulla on tämä kääntäjä, sen kanssa on helppo kokeilla.

Yritin itse asiassa tätä ensimmäisenä. Se ei ole RTOS missään sanan todellisessa merkityksessä. Se ei ole millään tavalla ennakoiva. Se vaatii säännöllistä tuottokomentojen käyttöä, jotta RTOS voi päättää kuka seuraavaksi juoksee, sinun on laitettava ne tarkoituksellisesti jatkuvasti, jos jokin toinen ohjelma tarvitsee ottaa ohjat.
Luulen, että sitä kutsutaan edelleen RTOS: ksi. Kuulostaa siltä, ​​että sillä on osuuskunnallinen ajastin täysin ennakoivan aikataulun sijasta.
Kyllä, se on edelleen teknisesti RTOS, mutta minulla oli ja on edelleen hyvin vähän arvoa sille. Tiedän, että se on henkilökohtainen asia, mutta minulle sen on oltava ennakoiva ollakseen arvokas. Olen edelleen +1, koska se oli hyvä vastaus ja arvokas.
#8
+3
davidcary
2010-06-10 02:28:42 UTC
view on stackexchange narkive permalink

Läheisesti liittyvä kysymys: https://stackoverflow.com/questions/1624237/multithreading-using-c-on-pic18

Kiitos! Näyttää siltä, ​​että useimmat ihmiset eivät saaneet kysymystä, mutta se on silti mielenkiintoinen.
Kirjoitin kysymykseen SO: sta, jossa kutsun käyttäjän tulemaan E&R: lle apua varten!
Luulen, että "saimme" kysymyksen SO: lla, se kysyi jotain muuta, mutta liittyi tähän kysymykseen. Mitä tulee kommenttisi sertifioinnista; se riippuu monista asioista. Katsomalla vastauksia tykkään DoxaLogosin vastauksesta, joka viittaa QP-nanoon; Kokemukseni johdattaa minua suosimaan tapahtumavetoista koodia ketjujen sijaan ja ketjujen implisiittistä kontekstivaihtoa.
#9
+2
Rocketmagnet
2011-01-25 04:32:27 UTC
view on stackexchange narkive permalink

Et ole sanonut paljoakaan hakemuksestasi. RTOS: n käyttö riippuu paljon siitä, mitä sinun on tehtävä PIC: ssä. Ellet tee useita erilaisia ​​asynkronisia asioita, jotka edellyttävät tiukkoja aikarajoja tai sinulla on useita ketjuja, RTOS saattaa olla ylitön.

On monia tapoja järjestää aika mikro-ohjaimessa sen mukaan, mikä tärkein:

  1. Jatkuva kehysnopeus: PIC: lle, joka käyttää servo-ohjainta, jonka on toimittava esimerkiksi taajuudella 1000 Hz. Jos PID-algoritmin suorittaminen vie alle 1 ms, voit käyttää lopun millisekuntia muihin tehtäviin, kuten CAN-väylän tarkistamiseen, antureiden lukemiseen jne.

  2. Kaikki keskeytykset: Keskeytys laukaisee kaiken PIC: ssä tapahtuvan. Keskeytykset voidaan priorisoida tapahtuman tärkeyden mukaan.

  3. Kiinnitä se silmukkaan ja tee kaikki niin nopeasti kuin pystyt. Saatat löytää tämän tarjoavan sopivat aikarajat.

Ymmärrän muita menetelmiä, mutta haluan laajentaa RTOS: iin. Suoritan useita tehtäviä ja minulla on kova reaaliaikainen järjestelmä, mutta olen valmis aloittamaan ilman kovan reaaliajan vaatimuksia. Kiitos vastauksestasi, mutta haluan oppia RTOS: n, jotta voin käyttää sitä suuressa kysyntätilanteessa.


Tämä Q & A käännettiin automaattisesti englanniksi.Alkuperäinen sisältö on saatavilla stackexchange-palvelussa, jota kiitämme cc by-sa 2.0-lisenssistä, jolla sitä jaetaan.
Loading...