Parâmetros para seleção de sistema operacional, memória e processador para sistema embarcado?

Question

Estou desenvolvendo um software de sistema embarcado em tempo real (na linguagem C). Eu projetei a arquitetura s / w - nós conhecemos vários objetos necessários, interações necessárias entre vários objetos e comunicação IPC entre tarefas. Com base nessas informações, preciso decidir sobre os requisitos do sistema operacional (RTOS), do microprocessador e do tamanho da memória.

(Muito provavelmente eu estaria usando o Quadros, como foi sugerido pelo cliente com base em sua experiência anterior em projetos semelhantes)

Mas eu estou confuso sobre qual deles começar, já que a escolha de um poderia impactar a seleção de outro.

Você também poderia me orientar sobre os parâmetros a serem considerados para estimar os requisitos de memória a partir do design s / w (limite inferior e limite superior do requisito de memória)?

(O custo do (s) componente (s) pode (m) ser ignorado (s) para esta avaliação)

    

Answer 1

A memória é mais barata que o seu tempo, pelo menos nos primeiros sistemas produzidos. Encha o máximo de tudo que você puder no tabuleiro para o seu sistema protótipo e instrumentalize o heck fora do seu código. Você pode comprar placas menos bem povoadas para produção, mas agora você quer mega recursos.

• Aloque pilhas muito maiores do que você acha que precisará e preencha-as com um monte de texto repetido, como o nome do segmento que possui a pilha. Quanto disso será gravado, você mostrará quanto de pilha cada thread usou. Aplique um fator de segurança confortável a esse número para obter sua alocação final.
• Aloque muita pilha. Melhor ainda, em vez de usar o heap em tempo de execução, pré-aloque o heap no início para um (ou vários) conjuntos de memória de um (ou vários) tamanhos de bloco fixos. Alocar e desalocar somente daqueles em tempo de execução.
• Registre o uso de memória em um buffer grande (ou circular) ou registre a ID do solicitante em um preâmbulo distinto do espaço de dados real do bloco - qualquer coisa que deixe trilhas que você possa encontrar posteriormente para ajudar a analisar a demanda de memória, inanição de memória, ou falhas.
• Mantenha os buffers fora de suas pilhas, para que as ultrapassagens não levem a uma parada brusca ou, pior, causem grandes transferências de controle.
• Bata no sistema. Coloque em todos os cenários que você acha que vão estressar os requisitos de pilha e memória. Inscreva alguns usuários típicos e não típicos para fazer o mesmo. Alguns deles tentarão fazer coisas que você não previu. Incentive isso.

Quando você tiver feito tudo isso, terá um controle muito melhor dos requisitos de memória do que consegue obter agora.

(Editar; comentários não estão disponíveis para mim)

James:

'we would like to get rough estimate of the hardware and cost involved at this stage. Do you think this would be possible ?'

A resposta curta é sim, a RAM provavelmente é uma pequena parte do seu custo de hardware, então vá em frente e superestime - você ainda deve estar perto.

Como uma verificação aproximada, você pode obter uma estimativa grosseira para os requisitos de memória estática - código e dados estáticos - escrevendo e compilando algumas funções para obter uma razão aproximada entre linhas de origem e memória e extrapolando. Você precisará de uma contagem aproximada e algumas estimativas precisas sobre como seu design se expandirá em funções e linhas de código. Você pode fazer uma suposição sobre o uso de estruturas dinâmicas de seu projeto em tempo real - pilhas e pilhas ou piscinas? Eu provavelmente, pelo menos, dobraria ou quadruplicaria minhas estimativas.

Você pode implementar o sistema em um computador existente, funções de curto-circuito (compilando o código com um retorno curto em vez de # ifdef'ing out) que não fazem sentido nesse ambiente?

Se você realmente precisa estimar sem implementar muito, eu acho que você vai ficar extrapolando.

    

Answer 2

Parece que você já fez algumas escolhas de design.

we know various objects required, interactions required between various objects and IPC communication between tasks.

você precisa de um sistema operacional multi-threaded e um uC que irá rodá-lo, geralmente significando que você quer apontar para um processador com uma MMU. Opções de SO são coisas como Quadros, QNX, Linux, wince, etc.

Com base no que seus "objetos" (módulos é o melhor termo para C :)) estão fazendo, é possível determinar que tipo de arquitetura você precisa. Um arco de 16 bits é suficiente? precisa de mais memória ou trabalhar com números maiores, então 32 bits é a resposta certa? muitos trabalhos de ponto flutuante? então você provavelmente precisará de um processador com um FPU. Fazendo muito DSP como o trabalho? talvez você precise de um DSP ou de um uC com instruções de DSP ou um co-proc. Executando um display gráfico? precisa de um SoC com um controlador LCD embutido ou espere fazê-lo externamente. Fazendo gráficos 2D pesados? precisa de um SoC com alguma aceleração gráfica.

Faça uma lista dos recursos que você precisa e estime quanto de seu código se enquadra nas categorias como operações de número inteiro, looping, operações de ponto flutuante, operações gráficas, operações de DSP, etc.

Isso deve permitir que você classifique o nível de dispositivo necessário. Para algumas arquiteturas você poderia cruzar compilar algum código usando o GCC e emulá-lo usando o qemu no topo do linux. Isso provavelmente só vale a pena se você precisar testar o desempenho de um algoritmo crítico em uma arquitetura específica. Isso pode ajudá-lo a dimensionar a velocidade que você precisa para o seu aplicativo.

A segunda consideração deve ser o uso de energia e suporte para gerenciamento de energia. Combinado com o desempenho requerido, você pode escolher entre DSP, uC, processador de aplicativos, etc.

Como outros já disseram, eu não me preocuparia com o uso da memória, apenas vise tamanhos de ram grandes e muitas vezes diferentes, eles são compatíveis com pinos, então você pode simplesmente cortar o ram para produção. As únicas perguntas reais a serem respondidas aqui são:

* Qual é o tamanho de um espaço de endereçamento de que preciso? 16bit? 32 bits? etc

* Preciso de memória RAM externa ou será que um RAM interno do uC será suficiente? < - responda isso depois que você escolher uma arquitetura e puder ir caçar SoC.

Na maioria das vezes, escolher entre processadores da mesma classe é uma "guerra santa", também conhecida como mercado de risc de 32 bits. Alguns apostam no ARM, alguns apostam no coldfire, outros até no PIC32. No final do dia, provavelmente qualquer um funcionaria. Você tem que escolher com base nos SoCs disponíveis com os periféricos necessários, facilidade de desenvolvimento (quão boa é a cadeia de ferramentas) e custo.

O mesmo pode ser verdade para a escolha do SO, o linux vs o QNX vs frames é um desafio para a maioria das aplicações, geralmente a melhor resposta é aquela com a qual você tem mais experiência. Mesmo que acabe sendo um pouco mais caro, a redução no tempo de desenvolvimento geralmente compensa o custo de construção. Certifique-se de que o SO tenha os recursos necessários, bibliotecas compartilhadas, comunicação entre processos, canais, o que você precisar.

Como regra geral, eu selecionaria sua arquitetura primeiro. Isso terá um impacto muito maior no desempenho do seu dispositivo do que o sistema operacional. Além disso, os sistemas operacionais neste espaço geralmente são suportados em muitas arquiteturas. Além disso, os melhores SO's são compatíveis com POSIX, escritos corretamente, a maior parte do seu código deve ser capaz de rodar em múltiplos sistemas operacionais.

Não se sinta mal se você tiver que fazer várias tentativas para fazer a escolha correta. Você pode encontrar um núcleo que se adapte perfeitamente às suas necessidades de código, mas depois de alguma pesquisa achar que ele não suporta algum recurso secundário que você precisa, ou não há um SoC disponível com os periféricos que você precisa, ou mesmo que a coisa esteja de volta ordenada por 6 meses. Apenas certifique-se, depois de fazer a escolha inicial, que você pesquisará como o design se unirá com base nessa parte, de modo que você veja o obstáculo agora, em vez de estar na metade do desenvolvimento.