Spiegato così non si può capire nel dettaglio quali sono le necessità. Io ho pensato che il problema non fosse superabile senza un RTOS, ma ciò non è detto.
Se prendiamo come esempio il convertitore usb to serial di Arduino vediamo che senza RTOS esso legge da
seriale e spedisce via usb e viceversa. Si dovrebbe sapere che non devono arrivare tutti i dati prima di iniziare a spedire, anche perché non si conosce a priori quanti dati si inviano via seriale, per cui c'è un buffer di dati di mezzo.
Solitamente si tratta di un ring buffer ciclico (i dati rimangono nel buffer rimangono ciò che cambia sono HEAD e TAIL). Un (ISP) interrupt in hardware buffer fa saltare il puntatore ad eseguire la isr che legge il dato e lo spinge nel buffer, la isr termina e viene eseguito codice in background che prende il dato nel buffer (se c'è) e lo invia sulla seriale. La velocità tra lettura ISP e scrittura su seriale determina la dimensione del buffer, un meccanismo può legare ISP e seriale in modo busy/ready. Però questo è semplice e codice da prendere in prestito c'è per cui forse non è questa la soluzione cercata, del resto anche arduino legge e scrive in seriale continuando a fare altre cose.
Con gli RTOS e la gestione delle risorse ci si può incasinare anche tanto a causa del fatto che una risorsa risulta bloccata da un task che la usa e se un altro task la vuole usare non può fintanto che risulta bloccata, ma ci sono le code e un gestore come il sistema di stampa che si riserva il diritto di usare la stampante e tutti i task (processi) stampano in area gestore di stampa.
Si potrebbe dire di più se si avesse un diagramma a blocchi funzionale o anche un descrizione complessiva di cosa deve fare il sistema oltre a leggere da ISP e inviare su seriale.
Ciao.