Como você determina a quantidade de flash / RAM necessária para um microcontrolador?

24

Digamos que você esteja iniciando um projeto incorporado com algumas funcionalidades conhecidas. Quando você seleciona um microcontrolador, como seleciona a quantidade de RAM necessária?

Você usa uma placa de desenvolvedor e codifica seu projeto primeiro e depois vê quanta memória você usou e depois seleciona um microcontrolador apropriado que se encaixa nessa memória?

Você apenas escolhe um microcontrolador robusto para um protótipo e depois reduz o tamanho depois de ter um produto em funcionamento?

Você escolhe apenas algo que tem certeza de que será suficiente e, se ficar sem espaço, basta atualizar para uma densidade de memória mais alta, caso contrário, apenas manterá o microcontrolador existente?

O que é considerado uma boa prática?

— efox29
fonte

Parece-me que deve ser possível, do ponto de vista teórico da informação, estimar o requisito de RAM dentro de uma ordem de magnitude (estilo de raciocínio dimensional), a partir da especificação da tarefa. Hmmm ...

— Lyndon White

Se você usar bibliotecas, poderá pesquisar a área de cobertura de memória. Com seu próprio código, você precisa ter experiência. Compare o novo projeto com os antigos e determine se você espera que seja maior ou menor.

— jwsc

20

Pessoalmente, para projetos de hobby, costumo usar o microcontrolador mais poderoso da família, com a pegada correta. Em seguida, desenvolvo o PCB, escrevo um código e produzo um protótipo.

Isso tem a vantagem de eu conhecer bem o pequeno número de microcontroladores, para que eu possa prototipar rapidamente sem ter que ler uma folha de dados inteira. Eu também tenho quadros de fuga e modelos de código para eles.

Se funcionar e eu estiver ganhando mais do que um punhado, então comprarei o microcontrolador mais barato, com os periféricos certos e memória suficiente para o que eu codifiquei anteriormente. Isso pode ser irritante se os registros internos mudarem (acontece no PIC) ou se um microcontrolador tiver periféricos extras que precisam ser desativados para que o código funcione.

No entanto, para fins de produção, isso permitirá que você corte uma quantidade razoável de cada unidade.

— David
fonte

Para meus projetos pessoais, costumo usar uma abordagem semelhante. Esse mesmo método também entra no escritório comigo. Não está errado, funciona, mas existem maneiras melhores, etc. Aprecie a entrada!

— efox29

Definitivamente haverá maneiras melhores em um ambiente "real", vamos esperar por outras respostas!

— David

Absavelmente. Desenvolva em uma grande caixa de areia e reduza mais tarde. O tempo que você economizará cobrirá mais do que os US $ 4 extras gastos por microcontrolador para desenvolver. Isso funciona para mais do que coisas relacionadas ao hobby - e, de fato, é ainda mais importante. Figura 12 pessoas esperando a mudança para um controlador maior, em vez de um !!

— Scott Seidman

13

Obviamente, para um único protótipo caseiro, pode ser uma boa recomendação começar com o mais poderoso de todos os micros compatíveis e diminuir a escala posteriormente.

No entanto, se você deseja obter uma cotação, precisa informar um preço ao seu cliente antes de ter dinheiro para implementar qualquer coisa.

Portanto, a boa prática é anotar algum tipo de especificação antes de iniciar a programação. Você sabe o que quer fazer e deve escrever como vai fazê-lo.

Esse "como" também inclui pensar em um design de software, respondendo a perguntas como:

Você precisa de um sistema operacional? Qual? De que recursos ele precisa?
Deseja ter uma arquitetura em camadas? Isso requer interfaces, que podem consumir RAM
Quais bibliotecas já estão disponíveis e são úteis / necessárias para o seu objetivo e quanta memória elas precisam (uma boa documentação da biblioteca responde a isso com base em pelo menos uma construção de referência)?
Quais estruturas e variáveis você precisa implementar para seus próprios drivers e seu aplicativo?

Resumir todos esses valores fornece uma estimativa aproximada. Até que ponto você pode confiar, depende de quão detalhada é a sua análise e da sua experiência :-)
Adicionar uma margem de pelo menos 30 a 50% da sua estimativa é certamente uma boa ideia.

Depois que seu produto terminar e você tiver cerca de 80 a 90% de RAM em uso, poderá ter certeza de que sua seleção foi correta - pelo menos em relação à RAM.

— microfone
fonte

2

Re: "80..90% de RAM em uso". A prática padrão é garantir que você use apenas um máximo de 50% de utilização na CPU e na memória para poder acomodar futuras atualizações e correções de bugs.

— Dunk

11

@ Dunk: Depende do negócio. No setor automotivo, 80% de todos os recursos (CPU, RAM, Flash) no SOP são comumente aceitos. Por exemplo, em eletrônicos de consumo baratos, pode ser ainda mais: Qual a probabilidade de uma atualização em um sistema com uma vida útil de apenas 2 a 3 anos?

— mic

@ Dunk: Eu posso estar errado, mas parece que você está acostumado a softwares de desktop com memória dinâmica e todas as incertezas que acompanham isso. A grande maioria dos aplicativos incorporados aloca tudo estaticamente. Garantido sem vazamentos de memória. Então você pode usar exatamente 100% e ficar bem para sempre, desde que não o modifique. Obviamente, isso só funciona se você tiver uma pilha separada da sua RAM de trabalho ou se você souber exatamente como a pilha se comportará o tempo todo. É uma boa idéia deixar algum espaço para isso, mas 10 a 20% é fácil o suficiente para o que eu fiz.

— AaronD

O maior problema no software incorporado são ponteiros desonestos, saturação de buffer, divisão por zero e coisas assim. Alguns MCUs podem gerar exceções em hardware, semelhantes a interrupções, mas tudo que eu usei continuará alegremente como se nada tivesse acontecido. Haverá algum tipo de resultado, mas provavelmente não é o que você esperava e, portanto, terá que verificar isso. Algumas coisas, como aritmética excedente / insuficiente, são fáceis de verificar e corrigir imediatamente; outras coisas, como indicadores desonestos, podem passar completamente despercebidas até que uma função que funcionou por anos decida explodir.

— AaronD

3

Se você deseja atingir uma meta de 80% ou 50%, isso dependerá do seu cliente. Com uma especificação fixa e apenas correções de bugs necessárias, 80% é bom. Especificações não confiáveis, fluência esperada de recursos e uma margem grande o suficiente para permitir que você pague o extra por mais espaço. Certa vez, acabamos comprando 2x o número de microcontroladores que precisávamos e selecionamos aqueles com overclock o suficiente para nos fornecer o desempenho que precisávamos, que era muito mais barato que um redesenho de PCB para um chip mais poderoso.

— Mark Booth

3

Se ao menos fosse possível codificar seu sistema incorporado primeiro e depois construir o hardware. Isso facilitaria a vida de todos. Infelizmente, isso também significa que seus prazos estão fora da janela. Normalmente, o hardware precisa ser projetado muito antes de o software ser concluído, porque as peças de hardware frequentemente têm longos prazos de entrega.

Assim, os desenvolvedores de software embarcado geralmente precisam estimar as necessidades de memória e CPU do programa. Seu primeiro passo deve ser convencer o pessoal do hardware a fornecer o microcontrolador / CPU mais poderoso com o máximo de RAM possível. Isso raramente funciona porque eles têm objetivos próprios, mas de vez em quando você tem sorte.

Se isso não funcionar, a próxima coisa a fazer é criar um software de alto nível e dividir os módulos em funcionalidade. Você estimaria as linhas de código de cada função para cada módulo no sistema. Você pode usar uma fórmula para converter linhas de código em uma estimativa aproximada da memória de código. Você também investigaria quaisquer requisitos de memória incomuns (como matrizes grandes) e adicionaria algumas estimativas para acomodar isso. Em seguida, adicione uma porcentagem acima desse total para cobrir tudo o que você perdeu. Em seguida, dobre isso para atender aos requisitos típicos de utilização de 50%.

Sim, isso leva tempo. Sim, é necessário pular todos os bastidores, pois a troca do hardware é realmente difícil depois de construída.

— Dunk
fonte

Onde podemos encontrar a fórmula para converter linhas de código em memória de código?

— EasyOhm 26/11/14

Esse depende do idioma e compilador que você usa. Se você usar o Assembler, uma linha equivale aproximadamente a uma palavra de memória (seja qual for o tamanho da palavra do seu chip). Se você usa C, pode haver cerca de 3 a 5 palavras por linha e, se você usa C ++ ou algo ainda mais complexo, ainda pode ser muito mais. A melhor coisa a fazer é compilar alguns programas escritos nesse idioma e comparar as linhas de código com a memória de código para obter uma média.

— Dakkaron

2

Geralmente, os fornecedores de microcontroladores colocam em seus dispositivos uma gama de memória adequada para aplicações típicas. Portanto, se você precisar apenas de alguns pinos de E / S e um SPI em um dispositivo pequeno, provavelmente não encontrará nada que seja fornecido com 500 kBytes de Flash e 64 kBytes de RAM. Com dispositivos maiores, que estão mais próximos dos pacotes SoC, até o menor é quase certamente grande o suficiente, a menos que você esteja planejando fazer um processamento sério de números, como o processamento de imagens.

Em um ambiente profissional, a chave para escolher o microcontrolador certo é usar dados históricos. Você terá um registro dos outros projetos que desenvolveu e saberá que memória e outros recursos de silício são necessários para implementar cada recurso. Você saberá o que o produto deve fazer e, portanto, possui uma boa lista de recursos e pode calcular com rapidez e precisão os recursos que o microcontrolador precisará fornecer. Tentar adivinhar os requisitos de recursos de uma especificação de projeto inicial (desenvolvida no início do projeto quando houver menos informações sobre o sistema) não é confiável o melhor dos tempos e apenas engenheiros muito experientes, que construíram uma ampla banco de dados de dados históricos em suas próprias cabeças, terá algum tipo de sucesso ao usar esse método.

Muitas empresas adotaram uma abordagem 'Ágil' ao design de software e eletrônico, que envolve a construção de uma 'biblioteca' de pequenas placas de recursos (por exemplo, placas RS-485, placas ADC, etc.) junto com placas de plataforma genéricas que hospedam os microcontroladores , de maneira semelhante ao uso de um kit de desenvolvimento e plug-ins. Um produto pode ser prototipado rapidamente (em poucas horas), selecionando e conectando o conjunto de placas necessário para os recursos. O software é montado de forma semelhante a partir de módulos de biblioteca e pode ser portado e testado rapidamente. Uma vez que o tamanho da parte específica do hardware do código é conhecido, geralmente é suficiente selecionar a menor parte que o conterá. A exceção é a mencionada acima, onde a funcionalidade do dispositivo envolve big data ou algoritmos muito complexos. Este método fornece uma precisão,

(Outra vantagem da abordagem Agile é que ela permite o desenvolvimento de software e eletrônico em paralelo, com o design da elctronics sendo um exercício para integrar o conjunto de placas de recursos e executar a EMC relevante e outras coisas difíceis ao mesmo tempo que o O software do aplicativo está sendo desenvolvido nos conjuntos protoype. Ainda é necessária alguma portabilidade e integração, mas isso é feito quando o software e a eletrônica de trabalho estão disponíveis.)

— Torta má do cão
fonte