Microcontrolador sem bug

[Fábio Pereira]

Witt,

Até hoje eu não vi um MCU que não tenha erratas e isso inclui o STR711.

Acho que o que você quer não existe: MCU que não trave e não ressete ...

Em aplicações críticas, costuma-se usar um watchdog, checagem periódica de memória (através de CRC) e por aí vai.

Alguns MCUs possuem registradores específicos para apontar a causa do reset. Isso pode ajudar a sua aplicação a recuperar-se de uma falha inesperada, ou simplesmente paralisar a operação (e colocar os I/Os num estado conhecido e seguro).

Sobre a questão de CPUs antigas e novas, não acho que isso seja um fator para redução de BUGs, pois cada nova implementação de um chip em silício (use ele uma CPU recente ou antiga) está sujeita a bugs ou falhas de design da pastilha.

CPUs como Z-80 e 8051 possuem grande tradição sim, mas isto não garante que um chip da Silicon Labs, baseado no core 51, esteja totalmente isento de bugs na CPU (é claro que as chances são muito menores).

No caso dos ARMs, os bugs de CPU são menos prováveis pois cada fabricante que licencia uma CPU ARM recebe uma library para implementação do chip em silício (ou arquivos VHDL/Verilog). Ainda assim, como já foi dito, a interligação da CPU com os controladores de barramentos, interrupções e periféricos está sujeita a bugs de implementação ou até mesmo a falhas de interação ou temporização.

T+

[phophollety]

PIC 24 tem uart e can aliás, é padrão aqui na empresa e é muito bem..

pense nisso

[msamsoniuk]

o problema varia de fabricante para fabricante, mas certamente se a empresa nao tem capacidade de manter um core proprio, nao consegue atualizar ou nao consegue manter mais de uma linha, pq iriam ter capacidade para projetar perifericos que funcionam ?

[mastk]

Bem, ao meu ver toda CPU tem bug, vc que deu sorte de não ter se deparado com um ainda, mas que sabe um skynet seja livre de bug XD

[phophollety]

certeza, sempre tem um escondido

[guest2003]

Pessoal,

Desculpe minha inocencia... mas geralmente tenho mais problemas com os bugs que EU escrevo do que os que existem nos chips, que geralmente são bem conhecidos e em muitos casos com workarround...

Portanto seria mais importante se preocupar mais com o Firmware do que com o chip em si...

Da uma procurada sobre as normas de software em ambiente critico... [:)] depois que estiver fazendo ALGUMAS daquelas exigencias acho que deveria olhar pro chip...

Mas como sempre, eh minha modesta opnião [;)]

[]'s

[Witt]

Legal pessoal, acho que o Fábio englobou exatamente o que estou procurando. Não que não há bug que ocasione o reset, mas se o µC informar o motivo do reset, já ajuda.

E realmente guest, os meus bugs são muito superior que os de µC, comparar meus bug com os dos cores das máquinas vira covardia. hehehe

Dizem que não há sw sem bug, mas sw q não foi bem testado.

Obrigado aos que tem mais, ou diferentes, experiências das que eu tenho para me passar mais confiança na escolha desse componente.
Tenho estudado normas, como a IEC61508, que define normas de segurança no desenvolvimento de sw/fw/hw. São normas complexas e que, devido ao tamanho da equipe e tempo para o desenvolvimento, não são possíveis de serem aplicadas ao projeto.
Se alguém se interessar sobre esse assunto de confiabilidade no desenvolvimento eu tenho alguns documentos interessantes. É só mandar um email para <leonardowitt @ yahoo com br>

É a primeira vez que um tópico que abro tem mais de 2 ou 3 replays. Obrigado pela atenção e vou ver se dedico mais tempo pra responder a questões de outros colegas de profissão aqui pelo forum.

Assim que definir o µC posto a escolha. Imagino definir até o início do próximo mês.

Att.
Witt

[msamsoniuk]

tem um certo fabricante, nao vou citar nomes, mas fabrica mcus com core arm tb, q faz uns datasheetzinho muito porquinho e, pior, de uma revisao para outra do *mesmo* chip eles esquecem de colocar resistores de pullup q tinham mas revisoes anteriores, trocam pinos de lugar (em algo supostamente compativel pino a pino) e escrevem erratas na mesma noite que vc questiona se nao tem algo errado com o componente...

dae nao tem jeito neh ? hehehe

[helton]

marcelo...que cheiro de NXP !

[tcpipchip]

NXP,
Sempre aprontando...infelizmente...

[msamsoniuk]

hahaha eh um fabricante europeu ae

[mastk]

Ah guest, já vi:

PIC com ausimer (é assim que se escrever?), perde todo o conteudo da flash.

HCS08 hibernante, dorme e não acorda nem por reset.

Workaround, não é solução, afinal se seu prazo é 1 semana e demorar 3 meses para sair o workaround? e msm assim ele não te dar um solução aceitavel, o que vc faz?

Mas é isso, a gente pica os problemas, coloca farrofa pronta e comer com tubaina. Pena que dá uma gastura nas tripas depois...

[Witt]

Bom galera, conforme prometido, o processador escolhido foi o STM32.

Ele tem bug, mas são os bugs melhores documentados e menores que o da NXP. Consta que a proteção dele é tb melhor do que o dos LPCs. E se faltar memoria ou coisa parecida, é muito fácil migrar para o STR7.

Uma novidade no projeto é o ingresso de display TFT, ou seja, vai ser necessário muito mais processamento do que o imaginado inicialmente (display gráfico 128x128) e nesse ponto o STM32 supera o STR7, possibilitando operações bit a bit, como é em alguns registradores do 8051.

Uma coisa que não gostei nessa arquitetura, porém não vem ao caso para o atual projeto, é que a CAN e a USB não podem trabalhar juntas por compartilharem o mesmo banco de memória RAM. Como USB não vai ser utilizada, não terá problema.

Bom, os testes vão começar com uma evaluation board da própria ST. Um kit completo e muito interessante, inclusive já vem com o TFT e demais periféricos, contendo uma documentação muito rica de hadware e firmware.

Era isso pessoal.

Att.
Witt

[xultz]

Uma opção para começar a brincadeira, é comprar um STM32 Primer, que tem display de 128x128 colorido... eu tenho um

[Witt]

Esse kit é show de bola xultz, mas não tem a CAN.
Porém o preço dele é muito convidativo.

Você que testou ele, o debug dele é via Jtag?

Att.
Witt