To RTOS or not to RTOS

[marko]

Živjo,

Z zamenjavo družine in št. bitov mikrokontrolerja (iz 8 bit AVR 8 na STM32) gledam prednosti in slabosti RTOS-a in se nekako ne morem odločiti ali grem v to ali ne. Prednosti bi hitro videl, slabosti zaenkrat še ne vidim, kar pa nisem prepričan čisto pa je do kakšnega nivoja naj s tem RTOS-om grem, torej katere dele vse bi s tem delal.

Da opišem kaj imam sedaj:
- merjenje frekvence
- merjenje A/D
- input/output komunikacija preko CAN
- zapisovanje na zunanji flash (spi)
- ogromna glavna znamka, ki ima 50+ razičnih eventov, ki so že sedaj schedulani po nekem razporedju, s timeouti in podobno (z neko globalno časovno spremenljivko, ki ne blokira delovanja). Nekako tako: če je aktivirano to, se sproži neka logika, ki ima potem spet N pogojev za delovanje in je v več fazah, če se ena od faz ne izvede v XY času T, se potem zažene v tem primeru faza 2, če ne gre na fazo 3 ipd. Skratka, zelo prepleteno.

Moje vprašanje torej je, do kakšne mere vpeljati RTOS.

Jasno mi je, da kar je periferije in komunikacije, idealno paše v ta koncept.
Kako pa je s to glavno zanko? Rad bi naredil stvar malo bolj pregledne, da bo to lažje updejtat in dodajat nove stvari, ker je sedaj že zelo nepregledna in imam napisanih preko 30 avtomatiziranih testov, da ob vsakem popravku pregleda, če ostalo še "pije" vodo. Ko dodam neko novo funkcionalnost, je velik rizik, da kaj ne bo delalo več tako kot mora.

- Bi moral biti vsak ta task svoj thread s svojimi pogoji in eventi? Bi jih grupiral po večjih blokih in znotraj tistega potem logiko delal?
- Ohranim veliko zanko in pač dodam samo periferijo v threade?
- Bi z glavno zanko real-time kreiral posamične threade glede na task, ki ga moram izvest, in jih potem ukinil? (če je sploh možno).

Hvala vsem za nasvete.

[s54mtb]

Vse, kar si nastel je mozno. Predlagam, da je vse, kar je povezano s periferijo narejeno preko interuptov. Ti potem posiljajo signale. Ali uporabiti samo en task je nesmisel. Ce spreminjas koncept na rtos, je potem smiselno uporabiti vec taskov. Koliko jih rabis je odvisno od aplikacije. Npr. komunikacijo za CAN das v svoj task, ki caka signal iz can isr ter potem pohendla podatke... Faze 1,2,3 das lahko v svoje taske, ki cakajo na semafor za nadaljevanje izvajanja. Semaforje postavljajo ostale faze in s tem si ustvaris algoritem izvajanja.
Vedi tudi, da se bo na armu vse zgidilo strasno hitro.

Ce vzames stm32 L0 ali F0 imas keilov uvision free do 256k kode (z vsemi dodatki, tudi kelov rtos).

[marko]

Je kakšna omejitev pri številu taskov? Predvidevam, da se s povečanjem povečuje poraba rama? Mi je pa všeč, da se bo strašno hitro izvajalo. Cant wait
Omenjaš keilov RTOS. Je bolj primeren/boljši od FreeRTOS, ki ga ima CubeMX?

[tilz0R]

Marko, danes je RTOS skoraj že nuja. Cortex-M0 pa je tudi narejen z mislijo po RTOS.

Glede tvojih zadev, recimo pri CAN-u bi naredil svoj task, kateri čaka message queue in se potem odloči kako naprej. Če imaš za poslat kakšen paket iz drugega thread-a, boš enostavno vpisal sporočilo v CAN-ov message queue, ki ga bo potem le-ta sprocesiral. Medtem, ko CAN task ne bo imel kaj delati, bo spal in CPU ne bo izvajal čekiranja če je kaj novega.

RAM se povečuje z številom taskov, seveda.

Priporočam ti FreeRTOS, ker je free, enostavno portabilen v Keilu (ali izven njega) in ni nič slabši od Keil RTX-a. Ko uporabljaš FreeRTOS, dodaj zraven še CMSIS-OS wrapper (dobiš v examplih pri STM32Cube) in že lahko začneš.

Slabosti RTOS sistema (razen če mora CPU spati, potem je malo več dela) ne vidim. Sam danes delam le še z RTOS, tudi na F0 ali L0.
Sicer zgubiš (bolj kot ne) realnočasnost, ampak imaš ves potreben hardware, ki je sposoben narediti zadeve, ki si jih opisal. Z dodatnim DMA-jem za le-te, si pa zmagal in bo sistem delal "sam od sebe".

[MitjaN]

RTOS je vsekakor fajn. Je pa prva stopnica nekoliko višja, ko začenjaš.

Če je teh 50 dogodkov med seboj dobro razklopljenih jih lahko daš v svoj task. Ampak predvidevam, da temu ni tako. Potem drži stvari, ki so tesno sklopljene v svojem tasku, bo najbrž lažje. Če pa so vsi dogodki približno enako sklopljeni pa to mogoče kliče po hiearhičnemu avtomatu stanj.

Tisto kar najbrž najbolj boli je, da preden začneš migrirati temeljito dokumentiraj trenutni sistem. Potem pa na podlagi dokumentacije osnuj okvirno arhitekturo novega sistema. In šele potem se loti migracije. In ker boš boš hkrati z migracijo se učil še RTOS konceptov, konfiguracije RTOS-a in orodji za analizo delovanja priporočam, da za prvo aplikacijo z RTOS-om narediš samo minimalen subset obstoječe aplikacije.

[s54mtb]

Marko, danes je RTOS skoraj že nuja. Cortex-M0 pa je tudi narejen z mislijo po RTOS.

Glede tvojih zadev, recimo pri CAN-u bi naredil svoj task, kateri čaka message queue in se potem odloči kako naprej. Če imaš za poslat kakšen paket iz drugega thread-a, boš enostavno vpisal sporočilo v CAN-ov message queue, ki ga bo potem le-ta sprocesiral. Medtem, ko CAN task ne bo imel kaj delati, bo spal in CPU ne bo izvajal čekiranja če je kaj novega.

RAM se povečuje z številom taskov, seveda.

Priporočam ti FreeRTOS, ker je free, enostavno portabilen v Keilu (ali izven njega) in ni nič slabši od Keil RTX-a. Ko uporabljaš FreeRTOS, dodaj zraven še CMSIS-OS wrapper (dobiš v examplih pri STM32Cube) in že lahko začneš.

Slabosti RTOS sistema (razen če mora CPU spati, potem je malo več dela) ne vidim. Sam danes delam le še z RTOS, tudi na F0 ali L0.
Sicer zgubiš (bolj kot ne) realnočasnost, ampak imaš ves potreben hardware, ki je sposoben narediti zadeve, ki si jih opisal. Z dodatnim DMA-jem za le-te, si pa zmagal in bo sistem delal "sam od sebe".

RTOS2 podpira tickless režim:
https://www.keil.com/pack/doc/CMSIS/RTO ... l#lowPower

Sila enostavno z nekaj dodatnimi vrsticami v idle tasku.

[tilz0R]

Tudi FreeRTOS ga, že nekaj časa. Še vedno je treba biti smart, da to dobro izpelješ. Napačna uporaba RTOS-a naredi več škode kot koristi pri LP aplikacijah.

[Proteus]

Samo moj pogled. Če se že grem razvoj na mikrokontrolerju potem hočem imeti stvari 100% pod svojim nadzorom oziroma vsaj težim k temu.

RTOS in STM32Cube mi zaradi tega nikakor ne sedejo. Cube uporabljam samo za to, da iz njega skopiram dele kode, ki mi pohitrijo delo in pri tem se konča.

Tako kot s54mtb, za vse kar je povezano s periferijo uporabljam interupte. Podatke med perifirijo in programom si nato izmenjujem preko vmesnih podatkovnih struktur, s čimer si v maksimalni možni meri zagotovim prenosljivost med CPU-ji.

Za samo programiranje pa uporabljam cooperative multitasking in finite-state machine. Vse skupaj zahteva nekaj specifike pri programiranju a je zato dokaj enostavno za debagiranje. Z lahkoto dodajaš nove taske in z eno samo LED diodo lahko opazuješ zasedenost procesorja v glavni zanki.

[s54mtb]

Samo moj pogled. Če se že grem razvoj na mikrokontrolerju potem hočem imeti stvari 100% pod svojim nadzorom oziroma vsaj težim k temu.

RTOS in STM32Cube mi zaradi tega nikakor ne sedejo. Cube uporabljam samo za to, da iz njega skopiram dele kode, ki mi pohitrijo delo in pri tem se konča.

Tako kot s54mtb, za vse kar je povezano s periferijo uporabljam interupte. Podatke med perifirijo in programom si nato izmenjujem preko vmesnih podatkovnih struktur, s čimer si v maksimalni možni meri zagotovim prenosljivost med CPU-ji.

Za samo programiranje pa uporabljam cooperative multitasking in finite-state machine. Vse skupaj zahteva nekaj specifike pri programiranju a je zato dokaj enostavno za debagiranje. Z lahkoto dodajaš nove taske in z eno samo LED diodo lahko opazuješ zasedenost procesorja v glavni zanki.

Moja današnja aplikacija ima tak main() - brez rtosa:

Koda: Izberi vse

int main( void )
{
  HAL_Init();
  HW_Init();   
  LORA_Init( &LoRaMainCallbacks, &LoRaParamInit);
  LORA_Join();
  while( 1 )
  {
    DISABLE_IRQ( );
     LPM_EnterLowPower( );
    ENABLE_IRQ();
  }
}



[zanka]

Jaz v ISR poskrbim le za ključne stvari, za vse ostalo postavim zastavice, ki jih obdeluje main.