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.

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.

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!

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.

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!

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.

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.

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

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.