Ha senso mescolare un RTOS e un dirigente ciclico?

Question

Su un piccolo progetto di sistema incorporato abbiamo del codice che vorremmo eseguire in un thread, quindi stiamo scegliendo di costruire in cima a un RTOS incorporato (eCos).

In precedenza, abbiamo utilizzato un dirigente ciclico in main () che guidava le attività implementate ciascuna come una macchina a stati. Per alcune attività abbiamo riscontrato problemi in cui l'attività avrebbe dovuto essere suddivisa in molti stati a grana fine rendendo il codice ancora più complesso.

Quando si passa a un RTOS abbiamo riscontrato che l'utilizzo della memoria per ogni stack di thread si somma rapidamente se assegniamo a ogni attività separata il proprio thread. (abbiamo solo 64k e abbiamo bisogno della memoria per i nostri buffer di comunicazione)

Stiamo pensando di utilizzare un battistrada per il nostro compito di comunicazione e un altro thread per un dirigente ciclico. L'esecutivo ciclico guiderà le altre attività logiche.

Ha senso mescolare un RTOS e un dirigente ciclico come questo?

Answer 1

Questo è un design perfettamente valido.
In uno dei nostri prodotti, abbiamo utilizzato un design simile, in cui i canali I / O asincroni (TCP / IP, 2 flussi seriali) avevano i loro compiti e avevamo un "main" compito che sarebbe responsabile di molteplici aree di funzionalità.

Pensa alle attività semplicemente come un meccanismo di partizionamento che ti consente di semplificare il tuo design.

Answer 2

Sì, avere un dirigente ciclico in un thread del sistema operativo che esegue più 'task' può avere senso. Infatti, a meno che due attività non siano in conflitto con le esigenze di pianificazione (una deve essere bloccata, una ha una priorità più alta dell'altra e quella a bassa priorità richiede molto tempo per l'esecuzione, ecc.), Consiglierei di inserirle nello stesso thread.

Ciò è particolarmente vero nel caso in cui si stia utilizzando un RTOS leggero senza protezione della memoria: i thread separati non sono più sicuri di un thread (nessuna protezione MMU degli spazi degli indirizzi), in realtà sono potenzialmente più pericolosi a causa della maggiore necessità di protezione della concorrenza. Anche se il tuo schema IPC è solido e non suscettibile di uso improprio da parte dei programmatori, il suo overhead è generalmente diverso da zero, quindi evitare la necessità di ciò può comportare un miglioramento delle prestazioni.

Answer 3

Se guardi FreeRTOS , eseguono effettivamente un altro programmatore in un'attività, una sorta di: )

E per fare eco agli altri, nulla sembra sbagliato nel design. Nessuna ragione (alcune delle) attività non può essere una macchina a stati se esiste un modo chiaro per esprimere qualcosa in quel modo.

Answer 4

È un progetto valido, ma penso di aver perso il motivo per cui il sistema operativo è stato utilizzato.

Quali servizi del sistema operativo si prevede di utilizzare?

Dalle informazioni disponibili sembra che finirai per spostare la complessità delle attività nel tuo nuovo ciclo principale.