Python em um sistema operacional de tempo real (RTOS)

StackOverflow https://stackoverflow.com/questions/1402933

Pergunta

Estou planejando implementar um sistema de aquisição de dados de pequena escala em uma plataforma RTOS. (Quer numa QNX ou um sistema de RT-Linux.)

Tanto quanto eu sei, estes postos de trabalho são realizadas utilizando C / C ++ para obter o máximo proveito do sistema. No entanto, estou curioso para saber e querem aprender opiniões de algumas pessoas experientes antes de eu cegamente saltar para a ação de codificação se seria viável e mais sábio para escrever tudo em Python (de instrumento de baixo nível interface através de uma interface gráfica do usuário brilhante). Se não, misturando com peças de temporização crítica do projeto com "C", ou escrever tudo em C e nem mesmo colocar uma linha de código Python.

Ou pelo menos embrulho o código C usando Python para fornecer um acesso mais fácil ao sistema.

Qual o caminho que você me aconselha a trabalhar em? Eu ficaria feliz se você apontar alguns casos de design semelhantes e outras leituras também.

Obrigado

NOTA 1: A razão da ênfase na QNX é devido a que já temos um QNX 4.25 com base sistema de aquisição de dados ( M300 ) para nossas experiências de medição atmosféricas. Este é um sistema proprietário e não podemos acessar a parte interna da mesma. Olhando mais adiante QNX pode ser vantajoso para nós desde 6.4 tem uma opção de licenciamento acadêmico livre, vem com Python 2.5 e uma versão recente do GCC. Eu nunca ter testado um sistema RT-Linux, não sei como comparável para QNX em termos de estabilidade e eficiência, mas eu sei que todos os membros do Python habitat e ferramentas não-Python (como o Google Earth) que o novo sistema poderia ser desenvolvido em obras mais do tempo out-of-the-box.

Foi útil?

Solução

Eu não posso falar para o todas Configuração de aquisição de dados lá fora, mas mais deles passam a maior parte de suas "operações em tempo real" esperando para que os dados vêm em -., pelo menos os que eu já trabalhei

Então, quando os dados faz entrar, você precisa gravar imediatamente o evento ou responder a ele, e então de volta para o jogo de espera. Isso é geralmente a parte mais crítica de tempo de um sistema de aquisição de dados. Por essa razão, eu geralmente dizer vara com C para as partes de I / O da aquisição de dados, mas não há razões qualquer particularmente imperiosas para não usar Python nas porções não-tempo crítico .

Se você tem exigências bastante soltas - só precisa de uma precisão de milissegundos, talvez - que acrescenta mais algum peso para fazer tudo em Python. Na medida em que o tempo de desenvolvimento vai, se você já está confortável com Python, você provavelmente tem um produto acabado significativamente mais cedo se você tivesse que fazer tudo em Python e refatorar apenas como gargalos aparecer. Fazendo a maior parte do seu trabalho em Python também irá torná-lo mais fácil de testar exaustivamente o seu código e, como regra geral, haverá menos linhas de código e, portanto, menos espaço para erros.

Se você precisar especificamente multi- tarefa (não multi- fio ), Stackless Python pode ser benéfico também. É de como multi-threading, mas os tópicos (ou tasklets, em Stackless linguagem) não são tópicos de nível de sistema operacional, mas / em nível de aplicativo Python, então a sobrecarga de comutação entre tasklets é significativamente reduzida. Você pode configurar Stackless de multitarefa cooperativa ou preventivamente. A maior desvantagem é que o bloqueio IO geralmente bloquear todo o seu conjunto de tasklets. De qualquer forma, considerando que QNX já é um sistema em tempo real, é difícil especular se Stackless seria vale a pena usar.

Meu voto seria para levar o como-muito-Python-como-possível rota - Eu vejo isso como baixo custo e alto benefício. Se e quando o fizer necessidade de reescrever em C, você já código para começar a partir de trabalhar.

Outras dicas

Eu construí vários all-Python macios sistemas em tempo real (RT), com tempos de ciclo primário de 1 ms a 1 segundo. Existem algumas estratégias e táticas básicas que eu aprendi ao longo do caminho:

  1. Uso de enfiar / multiprocessamento única para o descarregamento de não-RT trabalho a partir do segmento principal, em que as filas entre segmentos são rosqueamento aceitável e cooperativo é possível (sem preferência threads!).

  2. Evite o GIL. O que basicamente significa não só evitar threading, mas também evitar as chamadas do sistema, na medida do possível, especialmente durante as operações de tempo crítico, a menos que sejam non-blocking.

  3. módulos Use C quando prático. Coisas (geralmente) ir mais rápido com C! Mas, principalmente se você não tem que escrever o seu próprio: Mantenha-se em Python, a menos que não há realmente nenhuma alternativa. Optimizar o desempenho do módulo C é um PITA, especialmente quando a tradução através da interface Python-C torna-se a parte mais cara do código.

  4. Use Python aceleradores para acelerar o seu código. Meu primeiro projeto RT Python beneficiaram com Psyco (sim, eu venho fazendo isso há algum tempo). Uma razão que eu vou ficar com o Python 2.x hoje é PyPy:! As coisas sempre ir mais rápido com LLVM

  5. Do not ter medo de ocupado-aguardar quando momento crítico é necessário. Use time.sleep () para 'deslocar-se' no tempo desejado, então ocupado-aguardar durante os últimos 1-10 ms. Eu tenho sido capaz de obter um desempenho repetível com a auto-timing da ordem de 10 microssegundos. Certifique-se de sua tarefa Python é executado em prioridade OS max.

  6. Numpy rochas! Se você estiver fazendo analytics 'ao vivo' ou toneladas de estatísticas, há NÃO maneira de obter mais trabalho feito mais rapidamente e com menos trabalho (menos código, menos bugs) do que usando Numpy. Não em qualquer outra língua que eu conheço, incluindo C / C ++. Se a maioria de seu código consiste em chamadas Numpy, você vai ser muito, muito rápido. Eu não posso esperar para a porta Numpy para PyPy para ser concluída!

  7. Esteja ciente de como e quando Python faz coleta de lixo. Monitorar seu uso de memória, e forçar GC quando necessário. Certifique-se explicitamente desativar GC durante as operações de tempo crítico. Todos os meus sistemas RT Python funcionar continuamente, e Python gosta de memória porco. codificação cuidadosa pode eliminar a quase totalidade alocação dinâmica de memória, caso em que você pode desativar completamente o GC!

  8. Tente executar o processamento em lotes, na medida do possível. Em vez de processar os dados no débito de entrada, tentar processar os dados à taxa de saída, que é muitas vezes muito mais lentos. Processamento em lotes também torna mais conveniente para reunir estatísticas de nível superior.

  9. Eu mencionei usando PyPy? Bem, vale a pena mencionar duas vezes.

Existem muitos outros benefícios a usar Python para o desenvolvimento RT. Por exemplo, mesmo se você está bastante certo de sua língua-alvo não pode ser Python, pode pagar enormes benefícios para desenvolver e depurar um protótipo em Python, então usá-lo tanto como ferramenta de teste para o sistema final de um modelo e. Eu tinha vindo a utilizar Python para criar protótipos rápidos das "partes duras" de um sistema por anos, e para criar quick'n'dirty GUIs teste. Isso é como o meu primeiro sistema RT Python entrou em existência: O protótipo (+ Psyco) foi rápido o suficiente, mesmo com o teste de GUI em execução

!

-BobC

Edit: Esqueci de mencionar os benefícios de plataforma cruzada: Meu código é executado praticamente em todos os lugares com a) sem recompilação (ou dependências do compilador, ou necessidade de cross-compiladores), e b) quase nenhum código dependente de plataforma (principalmente para material variado, como manipulação de arquivos e de série I / O). Eu posso desenvolver em Win7 x86 e implantar no Linux-ARM (ou qualquer outro POSIX OS, todos os que têm Python estes dias). PyPy é principalmente x86, por agora, mas a porta ARM está a evoluir a um ritmo incrível.

Geralmente a razão avançou contra o uso de uma linguagem de alto nível em um contexto em tempo real é incerteza - quando você executa uma vez que uma rotina pode levar 100us; a próxima vez que você executar a mesma rotina pode decidir prorrogar uma tabela hash, chamando malloc, em seguida, malloc pede ao kernel para mais memória, o que poderia fazer qualquer coisa de retornar instantaneamente para voltar milissegundos mais tarde para retornar segundos mais tarde para erroring, nenhum dos quais é imediatamente aparente (ou controlável) a partir do código. Considerando teoricamente, se você escrever em C (ou até mesmo inferior) você pode provar que seus caminhos críticos "sempre" (com exceção de ataque de meteoros) executar em X tempo.

A nossa equipa tem feito algum trabalho combinando vários idiomas em QNX e teve bastante sucesso com a abordagem. Usando python pode ter um grande impacto na produtividade, e ferramentas como SWIG e ctypes torná-la realmente fácil de código de otimizar e combinam características dos diferentes idiomas.

No entanto, se você estiver escrevendo vez que algo crítico, ele deve quase certamente ser escrito em c. Fazer isso significa que você evitar os custos implícitos de um langauge interpretado como o GIL ( Bloqueio intérprete global ) e contenção em muitas alocações de memória pequenos. Ambas estas coisas podem ter um grande impacto em como seu aplicativo executa.

Também o pitão no QNX tende a não ser 100% compatível com outras distribuições (isto é / não são, por vezes, os módulos em falta).

Uma nota importante:. Python para QNX é geralmente disponível apenas para x86

Eu tenho certeza que você pode compilá-lo para ppc e outras arquiteturas, mas isso não vai funcionar fora da caixa.

Licenciado em: CC-BY-SA com atribuição
Não afiliado a StackOverflow
scroll top