Confiabilidade no pic

Software e Hardware para uC PIC

Moderadores: andre_luis, 51, guest2003, Renie

Re: Confiabilidade no pic

Mensagempor msamsoniuk » 13 Mai 2016 12:27

na realidade existe um problema inerente aos flip-flops que sao usados em qualquer microcontrolador: meta-estabilidade.

o conceito eh um pouco complexo para explicar, mas basicamente, se o sinal de entrada em um flip-flop (e os microcontroladores sao feitos com milhares deles) mudar de forma assincrona no instante do pulso de clock do flip-flop, ele entra em um estado em que nao consegue se decidir se vai comutar para 1 ou 0. a aterrorizante imagem abaixo mostra isso:

Imagem

o signal de entrada provavelmente comuta de 0 para 1 exatamente na borda de clock. o resultado eh que normalmente o flip-flop comuta de 0 para 1 sua saida, porem as vezes ele vai ateh metade do caminho e volta. umas poucas vezes, como se ve no grafico, ele vai ateh a metade do caminho, fica na duvida, mas decide ir adiante. isso eh diretamente relacionado com o sinal de entrada assincrono estar um pouco mais adiantado ou atrasado em relacao a borda de clock.

idealmente, o certo seria ele estar distante da borda de clock. isso eh didaticamente enfatizado na interface SPI, por exemplo:

Imagem

neste caso, os sinais mudam em uma borda do clock (descida) e sao amostrados na borda oposta (subida), de modo que o sinal fica perfeitamente estavel durante a janela de amostragem. mas a coisa eh um pouco mais complexa do que parece: no caso do master, o clock do microcontrolador eh usado para todo o bloco da SPI, de modo que este clock eh enviado para fora e todos os sinais estao sincronizados. mas no slave a coisa eh diferente: se ele possuir clock interno, provavelmente ele vai ter que amostrar os sinais da SPI passando por flip-flops duplos ou triplos de acordo com esse clock interno:

Imagem

no caso, o primeiro dominio de clock seria o master e o segundo dominio de clock seria o slave. eh facil ver que, se o sinal do master for muito rapido, o slave nao consegue amostrar corretamente: se o primeiro flip-flop falhar por meta-estabilidade, o sinal de entrada vai ser amostrado corretamente apenas no proximo clock. assim, se o sinal produzido pelo primeiro dominio for rapido demais, o segundo flip-flop do segundo dominio de clock nao pega ele! e ainda tem a possibilidade de, em condicao normal, o pulso ser curto demais pq os clocks estao com drift. assim, o pulso teria que ter largura de pelo menos 3 pulsos de clock do segundo dominio. em implementacoes boas, o pessoal coloca pelo menos 16 clocks para garantir.

assim, se vc tem dominios de clock diferentes, vc deve reduzir a taxa dos sinais, o que nesse caso seria equivalente a reduzir a velocidade da SPI. eh por isso que como master o microcontrolador consegue trabalhar com uma velocidade alta, mas como slave nao. entao, se vc for ligar dois microcontroladores, provavelmente vai ter que trabalhar com um clock SPI menor.

outra opcao para o slave seria trabalhar diretamente com o clock da SPI, sem amostrar. neste caso o clock pode ser maior, porem o slave nao pode operar em um dominio de clock proprio. essa opcao normalmente eh usada por perifericos, por exemplo, uma memoria SPI: neste caso, o clock da SPI que vem do master eh o clock da memoria, assim master e slave estao no mesmo dominio de clock e a SPI pode operar muito mais rapidamente.

a SPI eh ateh facil de resolver, mas e uma interface mais avancada?

lah no colegio, quando te ensinam a mexer com o 8080 ou Z80, vc vai lembrar que o pessoal ligando o Z80 em uma SRAM de forma assincrona. em certo aspecto, vale a explicacao do master/slave da SPI: como a conexao eh assincrona, varios clocks sao necessarios para transferir um byte entre o Z80 e as memorias. para um Z80 de 4MHz, uns 3 ou 4 clocks sao usados para cada transferencia e isso gera tempos suficientes para a memoria atuar corretamente. e mesmo assim, nao era facil ajustar o sistema para operar perfeitamente em sua velocidade maxima:

Imagem

no caso de um design mais avancado, utilizando SDRAM, as transferencias ocorrem com clocks de pelo menos 100MHz e uma palavra eh transferida a cada clock. isso soh eh possivel pq o processador tem uma linha de clock que sincroniza a SDRAM:

Imagem

resumindo: se o microcontrolador possui entradas nao-analogicas, ele estah sujeito a meta-estabilidade. provavelmente a meta-estabilidade nao vai causar problemas internos, mas os contornos para que isso nao ocorram causam outros problemas. as vezes o cara projeta a placa sem levar isso em consideracao e bingo: problemas inexplicaveis level "monstro" surgem o tempo todo e nem os caras da fabrica do microcontrolador conseguem explicar o motivo.

mas isso eh soh a pontinha do iceberg: se vc comecar a estudar logica NMOS e CMOS, vc fica de cabelo em peh e comeca seriamente a pensar em largar tudo e ir criar galinhas! :v hahaha
Avatar do usuário
msamsoniuk
Dword
 
Mensagens: 2935
Registrado em: 13 Out 2006 18:04

Re: Confiabilidade no pic

Mensagempor RobL » 14 Mai 2016 22:12

Se o produto final é exigente, usar um PIC fica muito difícil, mas não impossível, porém quase.
Um simples ARM ou outro(PIC32 não conheço) que monitore exceções lhe mostra onde está o problema. São diversas interrupções, uma para cada problema. Fica fácil tomar decisão diante da falha.
Aliás, noto pouca gente usando esse poderoso recurso disponível nos ARMs.
RobL
Dword
 
Mensagens: 1546
Registrado em: 20 Fev 2007 17:56

Re: Confiabilidade no pic

Mensagempor tcpipchip » 15 Mai 2016 09:25

O pessoal da http://www.4dsystems.com.au usava o PIC em vários produtos
------------------------------------------
http://www.youtube.com/tcpipchip
Avatar do usuário
tcpipchip
Dword
 
Mensagens: 6560
Registrado em: 11 Out 2006 22:32
Localização: TCPIPCHIPizinho!

Re: Confiabilidade no pic

Mensagempor KrafT » 15 Mai 2016 14:35

Quando fala em redundância sempre me pergunto: "Quis custodiet ipsos custodes?"
"..."Come to the edge," he said. And so they came. And he pushed them. And they flew."― Guillaume Apollinaire
Avatar do usuário
KrafT
Dword
 
Mensagens: 2228
Registrado em: 11 Out 2006 14:15
Localização: Blumenau -SC

Re: Confiabilidade no pic

Mensagempor RobL » 15 Mai 2016 20:11

Se os PICs usados forem os da linha 16 ou 18 fica difícil para criar um sistema confiável, mas não impossível. Esses chips não são para esse fim.
Já os PIC32 que não conheço certamente deve ter tratamento por exceções.

Quando fala em redundância sempre me pergunto: "Quis custodiet ipsos custodes?"


Quanto a redundância que não é minha sugestão, é similar a precisão de uma medida.
Se A1 fiscaliza a falha x causada por A0, tem-se certa probabilidade de sucesso, caso A0 falhe.
Se A2 fiscaliza a falha de A1 caso A1 falhe vigiando A0, tem-se uma menor chance de erro. E assim por diante A3 -> A2 -> A1-> A0 e vai doer minha cabeça e o bolso do comprador.
É como uma medida, você chegará a um instrumento de medida no qual n casas decimais lhe satisfaz e o custo com este instrumento.
Da mesma forma que continuará havendo um erro na medida, cada vez menor, haverá também uma probabilidade de erro cada vez menor no sistema.

Usando as interrupções já contidas em um ARM, poupa-se um bom dinheiro com hardware e pode-se criar software bem sofisticados para responder a falhas diversas, tanto em hardware como em software. Claro, isto pode não atender a certos riscos. Aí pode até entrar sistemas em paralelo.
RobL
Dword
 
Mensagens: 1546
Registrado em: 20 Fev 2007 17:56

Re: Confiabilidade no pic

Mensagempor Vonnilmam » 26 Mai 2016 11:51

Olá lucas,

Caso eu tenha compreendido corretamente sua preocupação, posso te assegurar que o pic funciona muito bem, sua arquitetura é muito boa e confiável.

Veja se você esta tendo bugs, com certeza deva ser algum erro no seu software, veja eu programo em assembler a mais de 25 anos, me sinto avontade para saber o que acontece no MCU, e também pela comodidade que já adiquiri. Se bem que não descarto nenhuma outra linguagem, inclusive o C, que dou umas arranhadas de vez em quanto.

Eu já fiz programas muito extensos e utilizando praticamente todos os periféricos do pic.

No decorrer do sistema que tenho desenvolvido e o utilizo para praticamente tudo, alterando apenas as libs para cada aplicação. Eu notei que em alguns casos apareciam bugs, porém não ao ponto de travar o software (nunca utilizei wotdog). Sempre que fazia uma atualização do software, notava e encontrava algum erro "MEU" de escrita no programa, coisas que passam batido, por exemplo, erros comuns, ESQUECER DE MUDAR DE BANCO DE RAM, outro erro comum, ESTOURAR OU COLOCAR AS TABELAS FORA DO NIBLE DE ALCANCE DA MEMÓRIA...coisas que facilmente passam batido, por isso seja num pic, 8051, avr ou outro MCU, temos que prestar muita atenção na hora de elaborar o software.

Essa é minha dica, com base nas experiências que tive ao longo dos anos.

Espero ter contribuido,
VonNilmam "Assembler" e agora "C"
Avatar do usuário
Vonnilmam
Byte
 
Mensagens: 446
Registrado em: 19 Out 2006 14:25
Localização: espacial

Anterior

Voltar para PIC

Quem está online

Usuários navegando neste fórum: Nenhum usuário registrado e 1 visitante

cron

x