produttore-consumatore con architettura di segnalazione in un sistema operativo in tempo reale (RTOS)

2

Sto sviluppando un sistema in tempo reale facendo uso di un mbed-OS (RTOS per l'architettura ARM). Non sono un ingegnere del software e voglio sapere se la seguente soluzione è pratica o meno e come migliorarla.

Come mostrato nella figura, gli elementi del software sono i seguenti:

Tre classi diverse (ClassA, ...) descrivono periferiche di basso livello per la raccolta di dati da tre diversi moduli che le loro istanze vengono passate per riferimento a tre diversi Thread (Thread a, ...). Usando tre code (codaA, ...), sto inviando dati al thread d che sta raccogliendo dati dagli altri 3 thread per combinarli in modo da formare una stringa in un formato desiderato (sintesi). I dati combinati vengono accodati alla Thread e, se alcuni scenari (Happening nei primi tre Thread) sono soddisfatti, tali dati vengono inviati alla Thread g. Ora le domande sono:

Tre primi thread raccolgono dati con tassi di aggiornamento diversi; Come sincronizzarli nel thread d? Qual è la migliore soluzione di segnalazione per conoscere gli altri thread (Event o Signal ?!) L'architettura menzionata è pratica? Grazie.

Schema a blocchi:

    
posta sohaami 08.07.2018 - 06:11
fonte

2 risposte

0

Ho capito che l'interrogante non è un ingegnere del software, ma rispondere alla domanda richiede informazioni aggiuntive e diverse che potrebbero essere apprezzate solo da un ingegnere in tempo reale.

I problemi che riguardano una prospettiva di architettura in tempo reale sono le velocità dei dati in entrata e le dimensioni dei dati e i problemi correlati nella manutenzione dei componenti che forniscono al sistema dati (hanno buffer e scadenze?); caratteristiche di schedulazione dell'hardware della CPU; il modo in cui il SO gestisce le priorità; tolleranza per la perdita di dati; eventuali scadenze di aggregazione che questo sistema deve soddisfare, ecc.

Nel contesto in tempo reale, "thread" e "code" sono di gran lunga troppo alti, occorrono numeri e componenti concreti.

    
risposta data 08.07.2018 - 23:17
fonte
0

C'è un livello di priorità che sento come se avessi invertito.

In genere, il software che comunica con la periferica è il livello di driver ed è il livello più basso di astrazione. I driver non hanno bisogno di sapere nulla sulla logica o sui dati al di sopra del loro livello, solo come comunicare con le periferiche e dove mettere i dati.

Avanti sopra di loro è più di un livello manageriale. Questo livello comunica con i driver per acquisire i dati e fare formattazione, eseguire l'ordinamento o qualsiasi altro tipo di algoritmo.

Sopra di loro, c'è il livello dell'applicazione. Questo livello viene in genere utilizzato come gestore di stato dominante o qualsiasi logica "aziendale".

Gliinterrupthardwaresonomeglioequipaggiatipergestireperiferichedibassolivello,comeunADCoundispositivodicomunicazione,invecediavereunthread/attivitàRTOS.Lagestioneelamanutenzionediquestiinterruptègestitaalmeglioallivellodelconducente.Quindii"thread" A, B, C sarebbero interrotti da interruzioni hardware.

Inoltre, voglio sottolineare che penso che tu intenda attività RTOS, che i thread b / c possano essere eseguiti contemporaneamente e che non siano tipici nello sviluppo integrato.

Mentre arrivano i tuoi dati, dovresti avere un evento / messaggio / flag / segnale dal contesto di interruzione per informare l'attività manageriale D, che i dati sono pronti per quel tipo di dati specifico. Ciò manterrà l'elaborazione dell'interrupt al minimo e ridurrà la complessità di mantenere il tuo codice sincrono sicuro.

Una coda di messaggi sarebbe la migliore, quindi hai meno paura di perdere un messaggio da una delle tue altre periferiche mentre raccogli i dati da un'altra.

Un'altra cosa da tenere a mente, è che si desidera disabilitare l'interrupt per la periferica / driver a cui si sta accedendo per i dati. Altrimenti, è possibile spostare / copiare dati, quando si riceve un'interruzione, che manipola i dati a cui si sta tentando di accedere, che potrebbero corromperli. Oppure devi configurare un buffer circolare FIFO nel driver, dove l'interrupt scrive solo su di esso, mentre il gestore legge solo da esso.

L'attività E sarebbe a livello di applicazione, in attesa che un'applicazione esterna richieda i dati o fornisca un servizio per trasmettere / trasmettere i dati a chiunque sia il consumatore.

Non sono sicuro di aver capito perché avresti bisogno del compito F o G.

Scusa se questa è una risposta prolissa, ma l'architettura software incorporata è uno spazio di conoscenza molto ampio.

    
risposta data 09.11.2018 - 01:08
fonte

Leggi altre domande sui tag