Vantaggi di RTOS vs Bare Metal per la programmazione MCU?

Nota: questa domanda menziona specificamente due RTOS ma è più generica e può probabilmente rispondere a chiunque abbia già scritto codice C per RTOS incorporati e abbia eseguito il proprio software direttamente su MCU.

Sono interessato a saperne di più sugli RTOS incorporati e scrivere applicazioni per loro. Attualmente sto guardando Embox e RIOT perché sono open source, moderni, attivi e sembrano avere un'ottima documentazione. Il mio obiettivo ha due fasi: la Fase 1 è capire come compilare e far lampeggiare questi SO su un MCU (probabilmente AVR o ARM). La fase 2 è quindi quella di scrivere un semplice programma C (sostanzialmente un demone senza testa), che si evolverà nel tempo come "app per hobby". Vorrei quindi eseguire il flashing / distribuire questo programma sullo stesso MCU, distribuendo con successo un appstack composto da Embox / RIOT e la mia app residente su di esso.

Prima di percorrere strade che alla fine portano a vicoli ciechi, mi sono imbattuto in questo articolo che fa un ottimo lavoro nel spiegare perché le app in tempo reale, scritte in C / assemblatore e trasmesse agli MCU, non hanno davvero bisogno di RTOS al di sotto di esse .

Quindi ora sono davvero confuso e sto mettendo in discussione alcune delle mie conoscenze fondamentali sulla teoria dell'informatica. Immagino che sto provando a decidere se utilizzare o meno Embox / RIOT in primo luogo:

• Segui il corso e scegli uno "stack app" sull'MCU di entrambe le app OS +; o
• Fai attenzione all'avviso dell'articolo e vai con un MCU che esegue la mia app "bare metal"

Ovviamente, il primo è più lavoro e quindi dovrebbe esserci un buon motivo / payoff per percorrere quella strada. Quindi chiedo: quali sono i reali vantaggi che questi (e simili) RTOS integrati offrono agli sviluppatori di app MCU / C? Quali funzionalità specifiche potrebbero trarre vantaggio dalla mia app C (forse non reinventando la ruota?) Utilizzando un RTOS? Cosa si perde abbandonando RTOS e diventando bare metal?

Sto chiedendo esempi concreti qui, non l'hype mediatico che ottieni quando vai alla voce di Wikipedia per RTOS ;-)

I programmi del microcontrollore consistono in una serie di attività . Diciamo che volevi realizzare un supporto per telescopio controllato da computer. I compiti sarebbero:

• Recupera un nuovo byte di input dal buffer seriale USB.
• Controlla se abbiamo ricevuto un comando completo.
• In tal caso, eseguire quel comando.
• Leggere i sensori per l'attuale posizione del telescopio.
• Impostare l'uscita corretta per controllare il passaggio successivo dei motori.

Questo è un insieme abbastanza tipico di attività per qualcosa per cui useresti un microcontrollore e sono abbastanza facili da gestire con un ciclo infinito, come:

while(TRUE) {
  uint8_t input = readUsbBuffer();
  parseCommand(input);
  readSensors();
  setMotors();
}

Se continui ad aggiungere e aggiungere funzionalità, alla fine inizi a riscontrare problemi comuni per cui vuoi creare astrazioni, come:

• Il buffer è in overflow, quindi si desidera assicurarsi che l'attività possa interrompere altre attività prima che trabocchi.
• Vuoi risparmiare la batteria dormendo quando non è necessario nulla.
• Vuoi assicurarti che tutte le attività abbiano un tiro giusto. Se readSensorsimpiega troppo tempo, vuoi essere in grado di interromperlo e tornare più tardi.
• Vuoi essere in grado di ripristinare solo un'attività senza influire sugli altri.
• Si desidera che una perdita di memoria o altri bug in un'attività non eliminino le altre attività.
• Vuoi essere in grado di assegnare a compiti diversi priorità diverse.
• Vuoi essere in grado di eseguire il sandbox di un'attività non attendibile.
• Vuoi essere in grado di eseguire attività a velocità diverse. Forse i tuoi sensori possono essere letti solo 10 volte al secondo, ma vuoi eseguire un passo del motore 100 volte al secondo.

Uno o due di questi articoli possono essere gestiti manualmente relativamente facilmente. Se hai abbastanza di questi tipi di problemi abbastanza frequentemente da iniziare a generalizzarli in librerie, hai sostanzialmente reinventato un RTOS. Se la gestione delle attività del tuo programma è abbastanza complessa, anche se non usi un RTOS standard, alla fine finirai per reinventarne uno male.

Tuttavia, nella mia esperienza, la linea in cui si desidera un RTOS è molto vicina alla linea in cui si desidera un microprocessore anziché un microcontrollore. Se prevedi che il tuo firmware diventi così complesso, di solito è meglio seguire il percorso del microprocessore dall'inizio.

Ho scritto la mia libreria multi-threading cooperativa per ARM Cortex-M0.

Era a malapena un paio di pagine di codice e la prima versione non impiegava più di un giorno a scrivere e eseguire il debug.

Il grande vantaggio di roll-your-own è che conosci il codice e puoi portarlo su chip che RTOS potrebbe non supportare. Inoltre, passi meno tempo a pensare a domande come "si bloccherà cercherò di utilizzare le funzioni A e B contemporaneamente?" Da quando hai scritto il codice, conosci la risposta.

Il threading è la cosa principale che ottieni da un RTOS, e risulta non essere un grosso problema da implementare. È raro che tu abbia bisogno di molte funzionalità di un RTOS. Ma se crunch le tue esigenze e si scopre che lo fai, quindi utilizzare un RTOS.