[Resolvido]Atmega328 no Proteus - Laboratorio de Garagem (arduino, eletrônica, robotica, hacking)2024-03-28T14:50:27Zhttps://labdegaragem.com/forum/topics/atmega328-no-proteus?commentId=6223006%3AComment%3A667170&xg_source=activity&feed=yes&xn_auth=noboa tarde JRR.
Fico feliz que…tag:labdegaragem.com,2018-04-17:6223006:Comment:6672952018-04-17T18:21:47.195ZElcids Chagashttps://labdegaragem.com/profile/ElcidsChagas
<p>boa tarde JRR.</p>
<p>Fico feliz que tenha te ajudado, e espero que isso se estenda aos que se interessam por esses assuntos.</p>
<p>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 <strong>Proteus</strong> 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:</p>
<p></p>
<p><strong>1)</strong> sobre o "<strong>Fuse Low…</strong></p>
<p>boa tarde JRR.</p>
<p>Fico feliz que tenha te ajudado, e espero que isso se estenda aos que se interessam por esses assuntos.</p>
<p>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 <strong>Proteus</strong> 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:</p>
<p></p>
<p><strong>1)</strong> sobre o "<strong>Fuse Low Byte</strong>", que é mostrado na figura a seguir:</p>
<p><a href="http://storage.ning.com/topology/rest/1.0/file/get/1939723195?profile=original" target="_self"><img width="721" src="http://storage.ning.com/topology/rest/1.0/file/get/1939723195?profile=RESIZE_1024x1024" width="721" class="align-full"/></a></p>
<p> O seu problema principal era o bit "<strong>CKDIV8</strong>", que estava "<strong>programmed</strong>" (lembrando que para estas CPUs <strong>AVR</strong>, o estado "<strong>0</strong>" significa "<strong>programmed</strong>"). Com isto o CLK de 16 MHz <span style="text-decoration: underline;"><em>era dividido por 8</em></span>, resultand em um CLK da CPU efetivo de <strong>1 MHz</strong>, 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).</p>
<p> Note que quando vc faz um "<strong>Chip Erase</strong>", isto não afeta os "<strong>Fuse bits</strong>". Note também que eles devem ser programados antes dos "<strong>Lock bits</strong>" (por motivos óbvios). Salientei estas informações no retângulo laranja na figura acima.</p>
<p></p>
<p><strong>2)</strong> sobre o "<strong>Fuse High Byte</strong>", que é mostrado na figura a seguir:</p>
<p><a href="http://storage.ning.com/topology/rest/1.0/file/get/1939723218?profile=original" target="_self"><img width="721" src="http://storage.ning.com/topology/rest/1.0/file/get/1939723218?profile=RESIZE_1024x1024" width="721" class="align-full"/></a></p>
<p></p>
<p> O bit "<strong>SPIEN</strong>", habilita a <strong>interface SPI do ICSP</strong> (aquele conector header de 6 pinos do <strong>Arduino UNO</strong>). Mas esta interface pode ser desabilitada, caso o "<strong>SPIEN</strong>" seja programado como "<strong>1</strong>", e se isto ocorrer, não será mais possível acessar mais a <strong>CPU 328</strong> via <strong>ICSP</strong>, ou seja, não será mais possível gravar o "<strong>Bootloader</strong>" do <strong>Arduino</strong> no <strong>328</strong> (ou qualquer outro código via <strong>ICSP </strong>!!!). Caso isto ocorra (gravar <strong>SPIEN = 1</strong>), você terá praticamente perdido sua CPU, a não ser que tenha um gravador do tipo "<strong>paralelo</strong>", pois esta é a única forma de voltar a setar o <strong>SPIEN</strong> em "<strong>0</strong>" <span style="text-decoration: underline;"><em>após ele ter sido setado em "1"</em></span>. Estas CPUs <strong>AVR</strong> de 8 bits não tem <strong>JTAG</strong>, 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.</p>
<p></p>
<p>3) sobre os bits "<strong>CKSEL3..0</strong>", cujas opções são mostradas na figura a seguir:</p>
<p><a href="http://storage.ning.com/topology/rest/1.0/file/get/1939723286?profile=original" target="_self"><img width="721" src="http://storage.ning.com/topology/rest/1.0/file/get/1939723286?profile=RESIZE_1024x1024" width="721" class="align-full"/></a></p>
<p></p>
<p> Como vc estava utilizando no seu Sistema um <strong>Cristal</strong> de <strong>16 MHz</strong>, a melhor opção é selecionar o setting "<strong>Full Swing Crystal Oscillator</strong>" (padrão de bits "<strong>0111</strong>" ou "<strong>0110</strong>"). Veja que esta opção é a mais adequada, <span style="text-decoration: underline;"><em>analisando de forma genérica</em></span>. Mas caso alguém esteja fazendo algum projeto que tenha que ser submetido a algum ensaio de <strong>EMI</strong> em uma <strong>câmara semi-anecóica</strong>, então esta pode não ser a melhor opção, já que o <strong>EMI</strong> 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).</p>
<p></p>
<p><br/>Há nas configurações, outros bits mais óbvios (ex.: "<strong>RSTDISBL</strong>"), 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 <strong>Application Note</strong> da <strong>ATMEL</strong> (agora pertencente à <strong>Microchip</strong>), onde você encontrará todas estas informações (guie-se pelos captítulos):</p>
<p><a rel="nofollow noopener" href="http://ww1.microchip.com/downloads/en/devicedoc/atmel-8271-8-bit-avr-microcontroller-atmega48a-48pa-88a-88pa-168a-168pa-328-328p_datasheet_complete.pdf" target="_blank">ATMEL 8-BIT MICROCONTROLLER IN-SYSTEM PROGRAMMABLE</a></p>
<p></p>
<p>Abrçs,</p>
<p>Elcids</p>
<p></p> Caro Elcids,
Muito obrigado p…tag:labdegaragem.com,2018-04-17:6223006:Comment:6671702018-04-17T11:58:43.172ZJOSE ROBERTO REDIGOLOhttps://labdegaragem.com/profile/JOSEROBERTOREDIGOLO757
<p>Caro Elcids,</p>
<p>Muito obrigado pela sua resposta. Além de resolver minha dúvida, deu uma aula para todos nós...</p>
<p>Zé Roberto</p>
<p></p>
<p>Caro Elcids,</p>
<p>Muito obrigado pela sua resposta. Além de resolver minha dúvida, deu uma aula para todos nós...</p>
<p>Zé Roberto</p>
<p></p> bom dia JRR.
Teste seu…tag:labdegaragem.com,2018-04-16:6223006:Comment:6669652018-04-16T06:56:00.865ZElcids Chagashttps://labdegaragem.com/profile/ElcidsChagas
<p>bom dia JRR.</p>
<p></p>
<p> 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 <strong>8x</strong>, já me fez desconfiar que o "prescaler de 8" (bit "<strong>CKDIV8</strong>" no "<strong>Low Fuse Byte</strong>") estava "ligado" (cuidado aqui, pois "<strong>0</strong>" nos "<strong>fuse bits</strong>" <span style="text-decoration: underline;"><em>significa…</em></span></p>
<p>bom dia JRR.</p>
<p></p>
<p> 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 <strong>8x</strong>, já me fez desconfiar que o "prescaler de 8" (bit "<strong>CKDIV8</strong>" no "<strong>Low Fuse Byte</strong>") estava "ligado" (cuidado aqui, pois "<strong>0</strong>" nos "<strong>fuse bits</strong>" <span style="text-decoration: underline;"><em>significa ligado</em></span>!!!).</p>
<p> Então apenas reconfigurei os fuse bits ("<strong>High Fuse Byte</strong>", "<strong>Low Fuse Byte</strong>", e "<strong>Flash Fuse bits</strong>") conforme o que vc precisava, ou seja, para usar o <strong>Cristal externo de 16 MHz</strong>. Após isso executei novamente o programa "<strong>blink</strong>", e funcionou conforme esperado, ou seja, piscando a cada segundo.</p>
<p> No anexo, vc encontrará o projeto do Proteus modificado, além do próprio arquivo <strong>HEX</strong> para o "<strong>blink</strong>", caso deseje testar.</p>
<p></p>
<p> Apesar da nova configuração dos "<strong>fuse bits</strong>" ter funcionado mesmo com seu circuito original, depois eu o modifiquei e desconectei do <strong>GND</strong> o pino "<strong>AREF</strong>", pois não é aconselhável conectar o <strong>GND</strong> ao pino "<strong>AREF</strong>", caso você não esteja usando este pino. Se você montar fisicamente o circuito, e gravar um <strong>HEX</strong> compilado no <strong>Arduino</strong>, pode ter um grande problema: provavelmente seu ATmega328 vai aquecer muito acima do normal, e eventualmente poderá "queimar" em algum momento posterior.</p>
<p> Vou esclarecer porque isso poderá ocorrer. Mas antes, veja seu circuito original, onde o <strong>GND</strong> está conectado ao pino "<strong>AREF</strong>":</p>
<p></p>
<p><a href="http://storage.ning.com/topology/rest/1.0/file/get/1939721992?profile=original" target="_self"><img width="721" src="http://storage.ning.com/topology/rest/1.0/file/get/1939721992?profile=RESIZE_1024x1024" width="497" class="align-full" height="272"/></a></p>
<p> O circuito modificado é mostrado a seguir:</p>
<p><a href="http://storage.ning.com/topology/rest/1.0/file/get/1939724071?profile=original" target="_self"><img width="721" src="http://storage.ning.com/topology/rest/1.0/file/get/1939724071?profile=RESIZE_1024x1024" width="498" class="align-full" height="269"/></a></p>
<p></p>
<p> Como vc pode observar, se não for utilizar o pino "<strong>AREF</strong>", o ideal é conectar um <strong>Capacitor</strong> de <strong>100nF</strong> entre este pino e o GND do circuito. Inclusive, se vc observar o esquemático original do <strong>Arduino Uno</strong>, vai ver que é isso que é feito no mesmo. Fazendo isso, além de providenciar um "bypass" para a <strong>Referência do ADC</strong> (conversor A/D interno do 328), você evita que exista uma "<strong><em>impedância DC</em></strong>" baixíssima entre o "AREF" e o GND.</p>
<p> No seu circuito original esta "<strong>impedância</strong> <strong>DC</strong>" 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 <strong>Referência Interna do 328</strong>, ao se fazer esse setting, você praticamente estará aterrando o driver da <strong>Referência Interna do 328</strong>, forçando a drenagem de uma corrente bastante acima do normal, e provocando um aquecimento "moderado" (mas acima do normal) do 328. <strong><em>Ocorre que isso pode ser ainda muito pior</em></strong>: no 328 a referência pode ser selecionada para ser o próprio <strong>AVCC</strong> (normalmente <strong>+5V</strong>). Neste último caso, você estará conectando o próprio <strong>AVCC</strong> ao <strong>GND</strong>, através apenas da impedância interna de uma "<em><strong>chave ON/OFF</strong></em>" interna ao 328. Esta "<em>chave ON/OFF</em>" pode ser vista no diagrama do <strong>ADC</strong> interno do 328, mostrado a seguir:</p>
<p><a href="http://storage.ning.com/topology/rest/1.0/file/get/1939724000?profile=original" target="_self"><img width="721" src="http://storage.ning.com/topology/rest/1.0/file/get/1939724000?profile=RESIZE_1024x1024" width="653" class="align-full" height="758"/></a></p>
<p> No diagrama acima, a "<strong><em>chave ON/OFF</em></strong>" é 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).</p>
<p> Ocorre que o <em><strong>código nativo do Arduino</strong></em>, usa a <strong>Referência Interna</strong> para o <strong>ADC</strong>, e inclusive ele seleciona o <strong>AVCC</strong> para esta referência (veja a figura anterior). Então você já pode ver o tamanho do problema, caso vc aterre o "AREF". No <strong>Proteus</strong>, isso não será um problema já que é uma simulação e os circuitos "não queimam". Mas na prática...</p>
<p> 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 "<strong>AREF</strong>", 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 <strong>+5V</strong> do Arduino ali. Então, melhor não arriscar, né?</p>
<p></p>
<p> Apenas por curiosidade, na figura a seguir é possível ver a seleção do sinal "<strong>REFS0</strong>", que liga ou desliga a tal "<em><strong>chave ON/OFF</strong></em>":</p>
<p><a href="http://storage.ning.com/topology/rest/1.0/file/get/1939726135?profile=original" target="_self"><img width="721" src="http://storage.ning.com/topology/rest/1.0/file/get/1939726135?profile=RESIZE_1024x1024" width="625" class="align-full" height="361"/></a></p>
<p></p>
<p> 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 "<strong>AREF</strong>", 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 "<strong>REFS0</strong>". Mas não se esqueça, o <strong>Arduino</strong> normalmente usa a <strong>Referência Interna</strong> (no caso o <strong>AVCC</strong>), então é preciso ter atenção ao que conectamos ao pino "<strong>AREF</strong>".</p>
<p></p>
<p></p>
<p> Espero ter colaborado, e caso tenha algo que eu ainda possa ajudar, fique à vontade.</p>
<p> Abrçs</p>
<p> Elcids</p>
<p><a href="http://storage.ning.com/topology/rest/1.0/file/get/1939727877?profile=original" target="_self"></a></p>