Vantaggi di RTOS rispetto a Bare Metal per la programmazione MCU?

I programmi di microcontrollore consistono in un certo numero di attività . Diciamo che volevi creare un supporto per telescopio controllato dal computer. Le attività sarebbero:

• Recupera un nuovo byte di input dal buffer seriale USB.
• Controlla se abbiamo ricevuto un comando completo.
• In tal caso, esegui il comando.
• Leggi i sensori per la posizione corrente del telescopio.
• Imposta l'uscita corretta per controllare il prossimo passo dei motori.

Questo è un insieme di compiti abbastanza tipico per qualcosa che utilizzeresti un microcontrollore, e sono piuttosto 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 desideri creare astrazioni, ad esempio:

• Il buffer sta traboccando, quindi vuoi assicurarti che l'attività possa interrompere altre attività prima che trabocchi.
• Vuoi risparmiare la batteria dormendo quando non serve nulla.
• Vuoi assicurarti che tutte le attività siano corrette. Se readSensors impiega troppo tempo, vuoi essere in grado di interromperlo e tornare più tardi.
• Vuoi essere in grado di ripristinare un'attività senza influire sugli altri.
• Vuoi una perdita di memoria o un altro bug in una sola attività per non eliminare le altre attività.
• Vuoi essere in grado di attribuire a compiti diversi priorità diverse.
• Vuoi essere in grado di eseguire il sandbox su un'attività non sicura.
• Vuoi essere in grado di eseguire attività a velocità diverse. Forse i tuoi sensori possono essere letti solo 10 volte al secondo, ma tu vuoi eseguire un passo motore 100 volte al secondo.

Uno o due di questi articoli possono essere gestiti manualmente in modo relativamente semplice. Se hai abbastanza di questi tipi di problemi abbastanza frequentemente da iniziare a generalizzarli in librerie, hai praticamente reinventato un RTOS. Se la gestione delle attività del tuo programma è abbastanza complessa, anche se non utilizzi un RTOS disponibile in commercio, finirai per reinventarne uno in modo scadente.

Tuttavia, secondo la mia esperienza, la linea in cui si desidera un RTOS è molto vicina alla linea in cui si desidera un microprocessore anziché un microcontrollore. Se anticipi che il tuo firmware sta diventando così complesso, solitamente è meglio seguire la rotta 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, trascorri meno tempo a pensare a domande del tipo "se si blocca, provo a utilizzare le funzioni A e B contemporaneamente?" Dato che hai scritto il codice, conosci la risposta.

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