Python su un Real-Time Operation System (RTOS)

Question

Sto pianificando di implementare un sistema di acquisizione dati su piccola scala su una piattaforma RTOS. (O su un sistema QNX o RT-Linux.)

Per quanto ne so, questi lavori vengono eseguiti utilizzando C / C ++ per ottenere il massimo dal sistema. Tuttavia sono curioso di conoscere e voler imparare alcune opinioni di persone esperte prima di saltare ciecamente nell'azione di codifica se sarebbe fattibile e più saggio scrivere tutto in Python (dallo strumento di basso livello che si interfaccia attraverso una lucida interfaccia utente grafica). In caso contrario, mescolando con parti critiche del tempo del progetto con "C", o scrivendo tutto in C e nemmeno inserendo una riga di codice Python.

O almeno racchiudendo il codice C usando Python per fornire un accesso più semplice al sistema.

In che modo mi consiglieresti di lavorare? Sarei felice se indichi casi di design simili e ulteriori letture.

Grazie

NOTA1: Il motivo dell'enfasi su QNX è dovuto al fatto che disponiamo già di un sistema di acquisizione dati basato su QNX 4.25 ( M300 ) per i nostri esperimenti di misurazione atmosferica. Questo è un sistema proprietario e non possiamo accedervi dall'interno. Esaminare ulteriormente QNX potrebbe essere vantaggioso per noi poiché 6.4 ha un'opzione di licenza accademica gratuita, viene fornita con Python 2.5 e una versione GCC recente. Non ho mai testato un sistema RT-Linux, non so quanto sia paragonabile a QNX in termini di stabilità ed efficienza, ma so che tutti i membri dell'habitat Python e strumenti non Python (come Google Earth) che il nuovo sistema potrebbe essere sviluppato su opere il più delle volte pronte all'uso.

Answer 1

Non posso parlare per ogni configurazione di acquisizione dati là fuori, ma la maggior parte di loro spende la maggior parte delle loro "quotazioni in tempo reale"; in attesa che arrivino i dati - almeno quelli su cui ho lavorato.

Quindi, quando arrivano i dati , è necessario registrare immediatamente l'evento o rispondere ad esso, quindi tornare al gioco in attesa. Questa è in genere la parte più critica in termini di tempo di un sistema di acquisizione dati. Per questa ragione, direi in generale attenersi a C per le parti I / O dell'acquisizione dei dati, ma non ci sono ragioni particolarmente convincenti per non usare Python nelle porzioni non temporali .

Se hai requisiti abbastanza ampi - forse hai bisogno solo di una precisione di millisecondi - questo aggiunge un po 'più di peso a fare tutto in Python. Per quanto riguarda i tempi di sviluppo, se ti senti già a tuo agio con Python, probabilmente avresti un prodotto finito significativamente prima se dovessi fare tutto in Python e refactoring solo quando compaiono i colli di bottiglia. Fare la maggior parte del tuo lavoro in Python renderà anche più semplice testare a fondo il tuo codice e, come regola generale, ci saranno meno righe di codice e quindi meno spazio per i bug.

Se devi specificamente multi- task (non multi- thread ), Stackless Python potrebbe essere utile. È come il multi-threading, ma i thread (o tasklet, nel linguaggio Stackless) non sono thread a livello di sistema operativo, ma Python / a livello di applicazione, quindi l'overhead del passaggio tra tasklet è significativamente ridotto. È possibile configurare Stackless per il multitasking in modo cooperativo o preventivo. Il più grande svantaggio è che il blocco di IO generalmente bloccherà l'intero set di tasklet. Ad ogni modo, considerando che QNX è già un sistema in tempo reale, è difficile ipotizzare se lo Stackless varrebbe la pena utilizzare.

Il mio voto sarebbe di prendere la strada il più possibile Python - la vedo come a basso costo e ad alto vantaggio. Se e quando devi riscrivere in C, avrai già un codice funzionante da cui iniziare.

Answer 2

Ho creato diversi sistemi soft real-time (RT) all-Python, con tempi di ciclo primari da 1 ms a 1 secondo. Ci sono alcune strategie e tattiche di base che ho imparato lungo la strada:

1. Usa il threading / multiprocessing solo per scaricare il lavoro non RT dal thread primario, dove le code tra i thread sono accettabili e il threading cooperativo è possibile (nessuna preventiva le discussioni!).

2. Evita il GIL. Ciò significa fondamentalmente non solo evitare il threading, ma anche evitare le chiamate di sistema nella massima misura possibile, specialmente durante le operazioni critiche nel tempo, a meno che non siano non bloccanti.

3. Usa i moduli C quando possibile. Le cose (di solito) vanno più veloci con C! Ma soprattutto se non devi scrivere il tuo: Resta in Python a meno che non ci sia davvero alternativa. L'ottimizzazione delle prestazioni del modulo C è una PITA, specialmente quando la traduzione attraverso l'interfaccia Python-C diventa la parte più costosa del codice.

4. Usa gli acceleratori di Python per velocizzare il tuo codice. Il mio primo progetto RT Python ha beneficiato molto di Psyco (sì, lo sto facendo da un po '). Uno dei motivi per cui sto con Python 2.x oggi è PyPy: le cose sempre vanno più veloci con LLVM!

5. Non abbiate paura di aspettare indaffarati quando è necessario un tempismo critico. Utilizzare time.sleep () per "passare di soppiatto" all'ora desiderata, quindi attendere fino agli ultimi 1-10 ms. Sono stato in grado di ottenere prestazioni ripetibili con l'autoscatto nell'ordine di 10 microsecondi. Assicurati che l'attività di Python sia eseguita con la massima priorità del sistema operativo.

6. Numpy ROCKS! Se stai eseguendo analisi "in tempo reale" o tonnellate di statistiche, esiste un modo NO per fare più lavoro più velocemente e con meno lavoro (meno codice, meno bug) rispetto all'utilizzo di Numpy. Non in nessun altra lingua che conosca, incluso C / C ++. Se la maggior parte del tuo codice è costituito da chiamate Numpy, sarai molto, molto veloce. Non vedo l'ora che la porta Numpy sia completata da PyPy!

7. Sii consapevole di come e quando Python esegue la garbage collection. Monitora l'utilizzo della memoria e forza GC quando necessario. Assicurati di disabilitare esplicitamente GC durante le operazioni temporali. Tutti i miei sistemi RT Python funzionano ininterrottamente e Python ama fare memoria. Una codifica accurata può eliminare quasi tutta l'allocazione dinamica della memoria, nel qual caso è possibile disabilitare completamente GC!

8. Prova a eseguire l'elaborazione in batch nella massima misura possibile. Invece di elaborare i dati alla velocità di input, prova a elaborare i dati alla velocità di output, che è spesso molto più lenta. L'elaborazione in batch rende inoltre più conveniente la raccolta di statistiche di livello superiore.

9. Ho già parlato di PyPy? Bene, vale la pena menzionarlo due volte.

Ci sono molti altri vantaggi nell'uso di Python per lo sviluppo di RT. Ad esempio, anche se sei abbastanza sicuro che la tua lingua di destinazione non può essere Python, può pagare enormi vantaggi per lo sviluppo e il debug di un prototipo in Python, quindi utilizzarlo come modello e strumento di test per il sistema finale. Stavo usando Python per creare prototipi rapidi delle "parti dure" di un sistema per anni e per creare GUI di test veloci e precoci. È così che è nato il mio primo sistema RT Python: il prototipo (+ Psyco) è stato abbastanza veloce, anche con la GUI di test in esecuzione!

-BobC

Modifica: ho dimenticato di menzionare i vantaggi multipiattaforma: il mio codice funziona praticamente ovunque con a) nessuna ricompilazione (o dipendenze del compilatore o necessità di cross-compilatori) eb) quasi nessun codice dipendente dalla piattaforma (principalmente per cose varie come la gestione dei file e l'I / O seriale). Posso sviluppare su Win7-x86 e distribuire su Linux-ARM (o qualsiasi altro sistema operativo POSIX, che hanno tutti Python in questi giorni). PyPy è principalmente x86 per ora, ma la porta ARM si sta evolvendo a un ritmo incredibile.

Answer 3

Generalmente il motivo avanzato contro l'uso di un linguaggio di alto livello in un contesto in tempo reale è incertezza - quando si esegue una routine una volta potrebbe volerci 100us; la prossima volta che eseguirai la stessa routine, potrebbe decidere di estendere una tabella hash, chiamando malloc, quindi malloc chiede al kernel più memoria, il che potrebbe fare qualsiasi cosa dal ritorno istantaneo al ritorno dei millisecondi successivi al ritorno secondi successivamente a errori, nessuno dei quali è immediatamente evidente (o controllabile) dal codice. Considerando che teoricamente se scrivi in ??C (o anche più in basso) puoi provare che i tuoi percorsi critici saranno sempre "sempre"; (escluso il colpo di meteorite) eseguito nel tempo X.

Answer 4

Il nostro team ha lavorato un po 'combinando più lingue su QNX e ha avuto molto successo con l'approccio. L'uso di Python può avere un grande impatto sulla produttività e strumenti come SWIG e i tipi rendono molto semplice l'ottimizzazione del codice e combina funzionalità delle diverse lingue.

Tuttavia, se stai scrivendo qualcosa di critico, dovrebbe quasi sicuramente essere scritto in c. In questo modo si evitano i costi impliciti di una lingua interpretata come la GIL ( Global Interpreter Lock ) e contesa su molte allocazioni di memoria di piccole dimensioni. Entrambe queste cose possono avere un grande impatto sul rendimento dell'applicazione.

Anche Python su QNX tende a non essere compatibile al 100% con altre distribuzioni (cioè / a volte mancano dei moduli).

Answer 5

Una nota importante: Python per QNX è generalmente disponibile solo per x86.

Sono sicuro che puoi compilarlo per ppc e altri arch, ma non funzionerà immediatamente.