Pessoal, bom dia.

Estou começando a fuçar no Proteus com Atmega328. Não estou conseguindo fazer o Blink funcionar, ao invés do led piscar de 1 em 1 segundo, está piscando de 8 em 8 segundos. Já mexi nas configurações de clock e também ja tentei fazer ele funcionar com clock interno de 8 MHz. Ai piora, começa a piscar com 16 segundos.

Alguém tem idéia de como configurar isso?

Segue arquivo do meu teste:

Exibições: 5448

Anexos

Responder esta

Respostas a este tópico

bom dia JRR.

      Teste seu Projeto original, e realmente o LED pisca a cada 8 segundos conforme vc relatou. Como deveria ser de 1 em 1 segundo, essa diferença de taxa em 8x, já me fez desconfiar que o "prescaler de 8" (bit "CKDIV8" no "Low Fuse Byte") estava "ligado" (cuidado aqui, pois "0" nos "fuse bitssignifica ligado!!!).

      Então apenas reconfigurei os fuse bits ("High Fuse Byte", "Low Fuse Byte", e "Flash Fuse bits") conforme o que vc precisava, ou seja, para usar o Cristal externo de 16 MHz. Após isso executei novamente o programa "blink", e funcionou conforme esperado, ou seja, piscando a cada segundo.

      No anexo, vc encontrará o projeto do Proteus modificado, além do próprio arquivo HEX para o "blink", caso deseje testar.

      Apesar da nova configuração dos "fuse bits" ter funcionado mesmo com seu circuito original, depois eu o modifiquei e desconectei do GND o pino "AREF", pois não é aconselhável conectar o GND ao pino "AREF", caso você não esteja usando este pino. Se você montar fisicamente o circuito, e gravar um HEX compilado no Arduino, pode ter um grande problema: provavelmente seu ATmega328 vai aquecer muito acima do normal, e eventualmente poderá "queimar" em algum momento posterior.

      Vou esclarecer porque isso poderá ocorrer. Mas antes, veja seu circuito original, onde o GND está conectado ao pino "AREF":

      O circuito modificado é mostrado a seguir:

      Como vc pode observar, se não for utilizar o pino "AREF", o ideal é conectar um Capacitor de 100nF entre este pino e o GND do circuito. Inclusive, se vc observar o esquemático original do Arduino Uno, vai ver que é isso que é feito no mesmo. Fazendo isso, além de providenciar um "bypass" para a Referência do ADC (conversor A/D interno do 328), você evita que exista uma "impedância DC" baixíssima entre o "AREF" e o GND.

      No seu circuito original esta "impedância DC" era a mais baixa possível, já que o "AREF" estava conectado direto ao GND. Como o pino "AREF" pode ser configurado para ser a saída da Referência Interna do 328, ao se fazer esse setting, você praticamente estará aterrando o driver da Referência Interna do 328, forçando a drenagem de uma corrente bastante acima do normal, e provocando um aquecimento "moderado" (mas acima do normal) do 328. Ocorre que isso pode ser ainda muito pior: no 328 a referência pode ser selecionada para ser o próprio AVCC (normalmente +5V). Neste último caso, você estará conectando o próprio AVCC ao GND, através apenas da impedância interna de uma "chave ON/OFF" interna ao 328. Esta "chave ON/OFF" pode ser vista no diagrama do ADC interno do 328, mostrado a seguir:

      No diagrama acima, a "chave ON/OFF" é salientada na cor amarela, enquanto todo o sub-sistema de seleção da Referência do ADC é salientado na cor azul clara. Observe que uma vez fechada essa chave, se o pino "AREF" estiver aterrado, será quase um curto-circuito entre o AVCC e o GND, pois a impedância da chave normalmente da ordem das dezenas de mili-Ohms. Caso não ocorra um reset da CPU 328 devido ao "quase curto-circuito", ou até mesmo um desarme da fonte de alimentação do sistema, uma coisa é certa: a corrente irá para as alturas, provocando um aquecimento muito acima do normal do 328. Se ocorrer um reset do 328 ou desarme momentâneo da fonte, a alta corrente é momentaneamente interrompida, e então o sistema oscilará, pois assim que o 328 executar novamente o código ligando a chave, tudo voltará a se repetir (como consequência, a corrente terá um valor médio ainda acima do normal e provocará um aquecimento também anormal).

      Ocorre que o código nativo do Arduino, usa a Referência Interna para o ADC, e inclusive ele seleciona o AVCC para esta referência (veja a figura anterior). Então você já pode ver o tamanho do problema, caso vc aterre o "AREF". No Proteus, isso não será um problema já que é uma simulação e os circuitos "não queimam". Mas na prática...

      Eu não saberia te dizer, se a referência interna é selecionada sempre pelo código nativo do Arduino, ou se esse código apenas seleciona isso quando o ADC é utilizado (via funções de conversão A/D da biblioteca nativa). Claro que o código fonte da biblioteca nativa pode ser analisado pra se descobrir isso. Outra forma é se medir a tensão no "AREF", em um programa onde não se utiliza o ADC. Acho que medi isso uma vez, e se não me engano, acho sempre tem os +5V do Arduino ali. Então, melhor não arriscar, né?

      Apenas por curiosidade, na figura a seguir é possível ver a seleção do sinal "REFS0", que liga ou desliga a tal "chave ON/OFF":

      Veja, que o default após o reset da CPU 328, é esta chave estar desligada. E isso foi feito propositalmente, justamente caso você utilize uma referência externa conectada via pino "AREF", e assim evitar uma corrente anormal fluindo entre a referência interna e a referência externa. Logo, quem utiliza uma referência externa, jamais irá setar o bit "REFS0". Mas não se esqueça, o Arduino normalmente usa a Referência Interna (no caso o AVCC), então é preciso ter atenção ao que conectamos ao pino "AREF".

      Espero ter colaborado, e caso tenha algo que eu ainda possa ajudar, fique à vontade.

      Abrçs

      Elcids

Anexos

Caro Elcids,

Muito obrigado pela sua resposta. Além de resolver minha dúvida, deu uma aula para todos nós...

Zé Roberto

boa tarde JRR.

Fico feliz que tenha te ajudado, e espero que isso se estenda aos que se interessam por esses assuntos.

Mas acabei não salientando alguns detalhes sobre a programação dos bits que causaram seu problema, e que eu alterei no seu projeto do Proteus para alcançar o resultado que vc esperava. Por isso, segue uma complementação das informações, já que pode ajudar a esclarecer algumas dúvidas:

1) sobre o "Fuse Low Byte", que é mostrado na figura a seguir:

     O seu problema principal era o bit "CKDIV8", que estava "programmed" (lembrando que para estas CPUs AVR, o estado "0" significa "programmed"). Com isto o CLK de 16 MHz era dividido por 8, resultand em um CLK da CPU efetivo de 1 MHz, fazendo sua CPU executar 8 vezes mais lento que o esperado. Observe aqui, que estas CPUs saem de fábrica com a opção "programmed" para o "CKDIV8", então é necessário setar isto adequadamente quando vc utiliza uma  destas CPU de forma "solitária" (ou seja, desvinculada de alguma IDE que possa setar os bits de forma adequada).

     Note que quando vc faz um "Chip Erase", isto não afeta os "Fuse bits". Note também que eles devem ser programados antes dos "Lock bits" (por motivos óbvios). Salientei estas informações no retângulo laranja na figura acima.

2) sobre o "Fuse High Byte", que é mostrado na figura a seguir:

    O bit "SPIEN", habilita a interface SPI do ICSP (aquele conector header de 6 pinos do Arduino UNO). Mas esta interface pode ser desabilitada, caso o "SPIEN"  seja programado como "1", e se isto ocorrer, não será mais possível acessar mais a CPU 328 via ICSP, ou seja, não será mais possível gravar o "Bootloader" do Arduino no 328 (ou qualquer outro código via ICSP !!!). Caso isto ocorra (gravar SPIEN = 1), você terá praticamente perdido sua CPU, a não ser que tenha um gravador do tipo "paralelo", pois esta é a única forma de voltar a setar o SPIEN em "0" após ele ter sido setado em "1". Estas CPUs AVR de 8 bits não tem JTAG, então só mesmo com um gravador do tipo "paralelo" pra reverter o estrago. Claro, embora óbvio, não custa lembrar: o gravador "paralelo" só será possível de se utilizar, se sua CPU não estiver soldada em uma placa.

3) sobre os bits "CKSEL3..0", cujas opções são mostradas na figura a seguir:

    Como vc estava utilizando no seu Sistema um Cristal de 16 MHz, a melhor opção é selecionar o setting "Full Swing Crystal Oscillator" (padrão de bits "0111" ou "0110"). Veja que esta opção é a mais adequada, analisando de forma genérica. Mas caso alguém esteja fazendo algum projeto que tenha que ser submetido a algum ensaio de EMI em uma câmara semi-anecóica, então esta pode não ser a melhor opção, já que o EMI pode ser mais alto nesta configuração (e uma falha desse tipo em um ensaio de EMI pode resultar em custo adicional de algumas dezenas de milhares de reais, dependendo do seu Sistema e do Laboratório contratado).


Há nas configurações, outros bits mais óbvios (ex.: "RSTDISBL"), mas que também são importantes, e que eu não abordei já que não era o foco da sua questão. Mas caso vc precise de algum esclarecimento sobre qualquer um deles, fique à vontade para perguntar. Mas segue o link com o Application Note da ATMEL (agora pertencente à Microchip), onde você encontrará todas estas informações (guie-se pelos captítulos):

ATMEL 8-BIT MICROCONTROLLER IN-SYSTEM PROGRAMMABLE

Abrçs,

Elcids

RSS

© 2024   Criado por Marcelo Rodrigues.   Ativado por

Badges  |  Relatar um incidente  |  Termos de serviço