Projetos com Avr : Design, Programação em Basic e Assembly

aphawk · 24 de setembro de 2015

Está aberto, é este aqui :

http://forum.clubedohardware.com.br/forums/topic/1134300-esp8266-a-pequena-maravilha-para-comunica%C3%A7%C3%A3o-internet/

Valeu pela ajuda !

Paulo

xyko-2020 · 24 de setembro de 2015

Peço a todos que forem postar assuntos relacionados ao ESP8266, faça-o no tópico abaixo dedicado a ele. Assim, este Tutorial sobre Projetos com AVR fica dedicado ao assunto proposto no título.

E sendo um assunto de interesse de todos que querem fazer comunicação wireless WI-FI com microcontroladores em geral, e não apenas com AVR, o tópico foi destacado.

Agradeço a compreensão.

ESP8266 - A Pequena Maravilha para Comunicação Internet

aphawk · 27 de setembro de 2015

Projeto de um Analizador Lógico Portátil com Atmega1284P - Display NOKIA 3310 - UPDATE

Este é um update do post abaixo :

http://forum.clubedohardware.com.br/forums/topic/937085-tutorial-de-projetos-com-avr-design-programa%C3%A7%C3%A3o-em-basic-e-simula%C3%A7%C3%A3o-no-proteus/page-14#entry6219544

Naquele post, mostrei uma rotina que utiliza o modo de endereçamento vertical, e que transfere todos os pontos armazenados no buffer para o display.

Existe um outro modo de endereçamento, chamado de horizontal, que funciona da seguinte maneira :

Reparem que neste modo, selecionamos a linha e a coluna inicial, e mandamos todos os 84 bytes em sequência , sendo que só precisamos fazer isto 1 vez. No modo vertical, eu selecionava a coluna, e tinha de enviar apenas 6 bytes, mas tinha de repetir isso 84 vezes ! Acabava mandando muito mais comandos de posicionamento.

Portanto, se trabalhar da maneira horizontal, a nova rotina de enviar o buffer para o display deve ser mais rápida.

Eu postei estas pequenas rotinas no Fórum do Bascom, e um usuário reescreveu a rotina para usar esse modo de endereçamento horizontal, e a nova rotina ficou bem mais rápida :

Endereçamento VERTICAL - 18 milisegundos

Endereçamento HORIZONTAL - 12 milisegundos

Houve uma melhora de 33% no tempo, e vai permitir uma maior taxa de refresh do display.

Segue a nova rotina :

'------------------------------------------Sub Print_screen()
'Send all the buffer to display
'------------------------------------------
$asm  
push R16  
push R17  
push R26  
push R27  
Ldi r24,&H20  
Rcall _gwrite_cmd  
Ldi r24,&H40  
Rcall _gwrite_cmd
Ldi r24,&H80  
Rcall _gwrite_cmd  
ldi r16,6  
Loadadr Vidram , X
_buf_loop1:
Ldi r17,84
_buf_loop2:  
ld r24,X+  
rcall _gwrite_data  
Dec r17  
Brne _buf_loop2  
dec r16  
Brne _buf_loop1  
POP R27  
POP R26  
POP R17  
POP R16
$end Asm
End Sub

Que beleza, não é ?

Ficou mais simples, menor, usa menos registradores, e ficou mais rápida !

Paulo

aphawk · 5 de outubro de 2015

Projeto de um Analizador Lógico Portátil com Atmega1284P - Display NOKIA 3310 - UPDATE 2

Olha .... neste projeto estou usando tanto o Proteus que acabei de achar mais um erro num modelo !

E desta fez foi o modelo do Nokia3310 mesmo !!!!!!!! Melhor dizendo, o display usa o modelo do PCD8544.

Um amigo lá do Fórum do Bascom pegou minhas rotinas, e criou uma library prontinha para a gente usar !

Fiz um teste com elas, usando o endereçamento horizontal, e não funcionava....

Aí fizemos um programa de teste, em ASM, mandando todos os dados na mão, um a um, posicionando apenas a primeira vez a posição de RAM 0,0 e enviando todos os 504 bytes em sequência, e não funcionava.

Lí todo o Datasheet da Phillips, sobre o CI PCD8544, e lá está bem claro que posso mandar todos os dados em sequência, e o próprio CI faz os incrementos das posições de linha e coluna.

Depois de perder mais tempo simulando, percebí que no modo vertical funciona apenas se você enviar 6 dados, depois tem de mandar novamente o posicionamento.... e o mesmo acontece no modo horizontal, a cada 84 bytes ....

Resolvi pegar um display real, montei uma protoboard com um Atmega328P, e fiz um programa de teste .... advinhem só : no display real, a library funciona direitinho !!!!! O erro está apenas no modelo do display no Proteus 8 !

Passei isto para o pessoal do suporte do Proteus na semana passada, e hoje me retornaram, confirmando o bug, e já me enviaram uma nova .dll ~~com o erro corrigido~~ !

Update 07/10 : o erro continua ...... já comuniquei e aguardo a resolução novamente...

Vou modificar o programa que está quase pronto para apresentar aqui, que é o da parte do Analizador de I2C, para usar a nova library do Bascom, e já mandarei tudo em anexo, incluindo o novo modelo do PCD8544 para o Proteus 8.

Paulo

test man*~ · 6 de outubro de 2015

Já aconteceu isso umas três vezes comigo... Após quebrar a cabeça por uns 2 dois dias acabei descobrindo que o problema era no PROTEUS... Mas mesmo assim, ele é EXCELENTE

aphawk · 10 de outubro de 2015

@test man*~,

Pois é, não tem nada que chegue nem perto do Proteus em circuitos com microcontroladores !

E finalmente tenho ótimas notícias :

1 - Recebi a nova DLL corrigida do Proteus, e agora sim está totalmente funcional, idêntica ao chip PCD8544 !

2 - Achei um bug na nova library do Bascom para o Nokia3310, que funcionava perfeita para clocks até 10 Mhz, mas a 20 Mhz nada aparecia no display...

Para resolver o bug, precisei seguir o código em ASM, e achei uma instrução de delay que faltava. Aí resolvi olhar o datasheet do PCD8544 para verificar os tempos necessários para esse delay, e acabei descobrindo que a library usa delays de 1 microsegundo, 4 vezes maiores do que o necessário. Modifiquei a library, para colocar os novos delays, e advinhem só :

Agora o tempo necessário para atualizar todos os pontos do display, que eram 12 milisegundos, passou para pouco mais de 4 milisegundos !!!!!

Apenas para lembrar, a primeira versão do programa que fazia isso, escrito em puro Bascom, demorava 24 milisegundos. Depois, usando ASM, mas utilizando uma rotina interna do Bascom para enviar dados ao display, chegamos a 18 milisegundos. Depois, usando essa nova library feita pelo colega do Fórum do Bascom, totalmente em ASM, chegamos a 12 milisegundos, que já estava ótimo, e agora, atendendo os tempos minimos do datasheet e com tolerância de 20% , conseguimos baixar para incríveis 4 milisegundos !!!!!

Isto mostra que quando aprendemos bastante sobre o hardware que estamos utilizando, fazer as rotinas em Asm permitem que tiremos leite de pedra ! E neste caso em particular, foi uma grande surpresa a enorme diminuição dos tempos !

Só lembrando que o PCD8544 possui uma programação de refresh rate do LCD, se eu conseguir "casar" a atualização do buffer do display com esse Refresh do LCD, nem se perceberá a atualizaçao, não teremos nem uma simples piscada da tela ! Mas isto deixarei para o final de tudo.

Agora, vou terminar o Analizador de I2C para postar e já incluirei o novo modelo do Proteus e a nova library do Bascom. Resolví dar uma incrementada no Analizador, incluindo também a visualização de Ack e Nack , pois existem alguns CI's que são bem complicadinhos de se conversar, e esses dados ajudam muito para fazer o Debug.

Paulo

test man*~ · 10 de outubro de 2015

Mestre Paulo @aphawk eu estou com um problema, na verdade é uma situação estranha... Eu estava fazendo uns testes com os FUSES (nem encostei no SPIEN xD), erasing chip, gravando um blink led (feito no BASCOM) e regravando o bootloader de um ATmega2560...

O estranho é que todos os testes funcionaram mas na hora de regravar o bootloader da um erro em "verifying flash" porém o bootloader é gravado corretamente (sketch do blink led + serial funcionam normalmente). Achei que era o PROGISP então instalei o eXtreme Burner - AVR e nele quando eu vou gravar o bootloader não aparece erro algum mas o bootloader não é gravado corretamente...

Estranho isso, dá o erro na verificação da flash mas o bootloader gravado aparentemente funciona, isso é normal? Ou pode ser que em uma siuação o programa (sketch) não funcione corretamente por causa disso? Não usarei a IDE do Arduíno mas é só para saber mesmo. (Usei um arduino mega 2560 e o USBasp da imagem)

Ele possui uma chave para selecionar entre 3,3V e 5V mas não é possível fazer ele não alimentar o circuito... Tive que cortar o fio do VCC

(na época não encontrei aquele com o ZIF que você indicou no tutorial).

aphawk · 10 de outubro de 2015

@test man*~,

Primeiro, då uma olhada na tua assinatura porque tá aparecendo umas mensagens esquisitas.....

Olha, eu já tive alguns problemas de falha de verificação na gravação quando fazia a gravação, e resolví trocando o gravador.

Eu ainda uso aquele que eu indiquei no primeiro Tutorial, que tem um driver que ajuda muito a fornecer sinais com qualidade. Esses modelos mais simples, semelhantes a essa foto que você postou, são feitos mais para iniciantes, alguns não tem uma boa qualidade. Experimente trocar por um de outro fabricante.

O que importa é o seguinte : leia os Fuses gravados, e compare , veja se são os mesmos. Depois, compare novamente a Flash gravada com a original. Se os dois estão ok, ignore, e seja feliz kkkkk !

Curioso o que voce falou sobre o Extreme Burner , pois fazem uns dois anos que eu testei ele e também não gravou direito.....

O velho ProgIsp ainda é o meu preferido !

Paulo

test man*~ · 12 de outubro de 2015

O que você acha do Atmel-ICE (PCBA + cabo) @aphawk? Ele grava até os SAM, parece ser um bom negócio.

http://www.atmel.com/tools/atatmel-ice.aspx

-----

[...] O que importa é o seguinte : leia os Fuses gravados, e compare , veja se são os mesmos. Depois, compare novamente a Flash gravada com a original. Se os dois estão ok, ignore, e seja feliz kkkkk ! [...]

Eu estava fazendo um código para o TMP101 e o USBasp estava muito estranho (hora lia os FUSES corretamente hora não, hora dava erro hora não, etc.) daí resolvi dar uma lida pela internet e encontrei estes links:

http://blackstufflabs.com/2013/10/24/aggiornare-firmware-usbasp-con-arduino/?lang=en

http://openrcforums.com/forum/viewtopic.php?f=10&t=1363#p29615

Regravei o bootloader do Arduíno Mega e o usei como ISP (sketch Arduíno ISP), segui os passos do 1° link porém usando os pinos 50, 51, 52, 53 e o arquivo main.hex (firmware USBasp) do 2° link. Na primeira tentativa, após a gravação, tirei o jumper (self Prog) do USBasp e o conectei ao PC e ele nem deu sinal de vida, o PC não o reconheceu (achei que ele tinha morrido, que eu tinha matado ele)

Adicionei o AVRDUDESS à lista de permissão do firewall do windows, coloquei para executar como administrador, tirei os LEDs de status (Heartbeat, Error e Programming) que a sketch Arduíno ISP indica e tentei gravar novamente... Nesta tentativa o AVRDUDESS mostrou tudo certinho (porcentagem do processo, detectou o ATmega8 do USBasp, etc.) daí testei o USBasp e parece que os erros foram embora até aquele do sck... O bom é que há uma sketch para tudo no arduino!!! HEHE

Vou continuar o programa para o TMP101 se isso realmente tiver corrigido o problema eu confirmarei...

Vi que o PICkit 2 está na lista de programadores, depois vou tentar gravar o 2560 com ele...

Esse AVRDUDESS parece ser bom...

[...] Primeiro, då uma olhada na tua assinatura porque tá aparecendo umas mensagens esquisitas. [...]

EDIT > [...] Trecho apagado [...]

aphawk · 12 de outubro de 2015

@test man*~,

Pickit2 gravando AVR ???? Essa é nova prá mim !!!

Eu sempre atualizei o firmware do USBASP, eu uso um deles para atualizar o firmware de meu rádio-controle. Pode ser que o seu estivese com um firmware mais antigo.

Eu gravo os meus protótipos com ISP pelo Bascom, mas usando o AVRDUDE, e funciona muito bem. Aliás, até o Arduíno usa ele para gravar. Não conheço esse AVRDUDESS, vou procurar me informar.

Quanto ao toque que te dei da assinatura :

A sua assinatura deve sempre dizer algo sobre você, pois é pessoal. Não sobre outras pessoas, concorda ?

Nem sempre nos damos bem com todos que estão à nossa volta. No dia a dia, o que voce faz com essas pessoas é tratar as mesmas com respeito, pois pode ser que essa pessoa também não goste de voce !

Viver em sociedade implica em aceitar algumas regras. Aceitar que as pessoas podem pensar diferente da gente é uma delas. E evite levar as coisas para o lado pessoal, aqui é um Fórum público para troca de conhecimentos e experiências, e todos estão lendo o que escrevemos. Prá que deixar claro que temos algum tipo de problema com alguém ? Muitos podem se afastar ou evitar de ajudar por achar que somos "difíceis de se lidar" !

Um sábio ditado que eu sempre sigo : A gente acaba esqueçendo das pessoas em que batemos, mas quem apanhou nunca se esqueçe da gente !

Se teve alguma divergência, nada melhor do que trocar uma mensagem pessoal, esclarecendo as coisas, e voltando a ter uma atitude, no mínimo, de respeito e não de "enfrentamento" hehehe !

Eu também tenho de "pisar em ovos" com alguns membros mais antigos, e até com uns mais novos do que eu, e acho que nisso tenho reciprocidade deles também kkkkk , mas vou levando na boa, e eles também, senão não daria para vivermos todos aqui nos "enfrentando" !

Não entenda isto como uma recriminação, meu amigo, é apenas uma dica que pode sempre ajudar o convívio, ok ?

Paulo

test man*~ · 13 de outubro de 2015

E não é que funcionou! O PICkit 2 gravou o ATmega2560

, legal isso.

Agora sei para o que serve o pino AUX do PICkit 2

Mais um uso para o PICkit 2... Logic analyzer, USB <> Serial e agora gravador para AVR.

Eu já tinha visto o AVR Dragon gravar um PIC usando aquele stand alone do PICkit 3...

http://blog.zakkemble.co.uk/avrdudess-a-gui-for-avrdude/

http://www.expkits.com/?s=avrisp.htm

---

Você está certo... 100% certo HEHE. Valeu!

aphawk · 16 de outubro de 2015

Projeto de um Analizador Lógico Portátil com Atmega1284P - Parte 7 - VISUALIZADOR I2C

VISUALIZADOR DE COMUNICAÇÃO I2C

Hoje em dia encontramos uma grande variedade de sensores e displays que utilizam o padrão de comunicação I2C.

Esse padrão foi criado pela Phillips, e inicialmente designado para criar um padrão de comunicação entre vários componentes dentro de uma televisão ( pois é .... incrível ! ), usando apenas dois sinais para isso.

Assim, um microcontrolador poderia conversar com um Tuner de RF, para fazer a correta sintonia dos canais. E também poderia conversar com um controlador de áudio, permitindo todos os ajustes de forma digital.

Naquele início, a velocidade da comunicação foi estabelecida em 10 KHz. E conforme o tempo passou, logo surgiram mais dois padrões, que são os mais utilizados hoje, que estabeleceram as velocidades de 100 KHz e de 400 KHz. Mas este não é o limite, pois existem hoje também componentes que conversam em velocidades acima de 3 Mhz !

Para o nosso uso do dia a dia, a velocidade máxima será a de 400 Khz.

O que é exatamente uma comunicação I2C ?

Usamos dois fios apenas, um deles receberá um sinal de clock, e o outro fio é chamado de sinal de dados. Como temos clock, sabemos que é um padrão de comunicação serial, isto é, os bits são enviados de forma serial, um bit por vez.

Claro que existem várias regras , as quais eu chamo de Protocolo I2C. Assim, existem "maneiras" de se mudar o sinal nos dois fios, e desta maneira conseguimos qualquer tipo de conversa, seja gravar uma informação em algum periférico, ou ler essa informação de um periférico.

Para isso, existem alguns sinais básicos, que são os seguintes :

- START : determina que vai ter início uma conversa no bus I2C.
- STOP   : determina que uma conversa I2C chegou ao final.
- ACK      : Indica que o dado foi recebido corretamente.
- NACK   : Indica que o dado não foi recebido corretamente.

Na verdade, a função do sinal Ack e Nack foi alterada, e agora eles também são utilizados para que o transmissor saiba se tem de parar de transmitir ou se deve transmitir mais algum dado.

Alguns componentes I2C são bem simples de se utilizar, como por exemplo uma memória I2C, e outros já são bem mais complexos, como por exemplo um sensor triaxial de posição, tendo vários registros internos para serem gravados e também para serem lidos.

É muito importante que enviemos os dados e respondamos os Ack / Nack da maneira correta, conforme estabelecido no Datasheet de cada fabricante de componente I2C.

Isso costuma ser um empecilho considerável para quem está iniciando, pois não conseguimos nunca saber quais as informações reais que estão circulando em um Bus I2C. E sem ver isso, não dá para fazermos um debug correto de nosso programa.

Existem aparelhos para isso, todos muito caros, e o que existe de barato precisa que utilizaremos um computador para mostrar os sinais na tela. Convenhamos, isso é uma baita limitação.

Pensei o quanto seria bom se existisse um pequeno aparelho, com um display integrado, que pudesse nos facilitar a vida, mostrando não os níveis de cada sinal ( alto ou baixo ) , mas sim todos os sinais já decodificados, assim fica muito fácil localizar algum erro na conversa.

Por exemplo, algo assim :

S 00 A 21 A S 01 A 53 N P

Isso significa um START, depois uma escrita no endereço 00, seguido de um ACK, o valor 21 a ser gravado no endereço espeçificado antes, seguido de um ACK, a seguir um novo sinal de START, seguido de uma leitura no endereço 01, seguido por um ACK, e aí vem o dado 53, seguido pelo sinal de NACK e finalmente um STOP.

O que isso tudo significa : gravamos o dado 21 no componente cujo endereço no Bus i2c é 00, e a seguir queremos ler esse apenas uma vez esse componente, o qual nos devolveu o byte 53. Se fosse para lermos mais dados em sequência, teríamos de sinalizar um ACK logo ao final , em vez do Nack que enviamos.

Parece simples, mas sem a sequência correta de informações, poderíamos estar recebendo um byte que nada tem a ver com o que queremos.... porisso que ver toda a sequencia que aparece, e comparar com o datasheet, ajuda muito a encontrarmos o erro rápidamente.

Não tenho a intenção de explicar detalhadamente o funcionamento do Bus I2C, deixo isso para a internet !

Vou ilustrar o grande problema que enfrentamos neste programa : o tempo de execução !!!

Em um Bus I2C na velocidade de 400 KHz, o nível do sinal SCL alterna muito rapidamente, e permanece estável durante apenas 1,25 microsegundos. Neste tempo, mesmo um AVR rodando a 20 MHz consegue executar apenas 25 ciclos de máquina !

Isso significa que temos bem poucas instruções para serem executadas antes que o sinal SCL mude. Lembrando que temos de olhar o sinal SDA durante esses tempos pequenos e a partir daqui decodificar o que está sendo feito no Bus, é uma tarefa bem chatinha !

Portanto, temos de fazer em ASM mesmo !

Embora eu tenha partido de um programa de um livro do Bascom, o trecho em ASM não decodificava os sinais de ACK e NACK, e também apresenta um erro quando decodifica endereços de leitura. Tive de modificar bastante a rotina original, e isso custou mais de uma semana até ficar perfeito !

A simulação disto no Proteus também é meio complicada, tive de incluir um outro microcontrolador conversando com um sensor de temperatura I2C, para poder monitorar a conversa. E usei também o debugger I2C do Proteus para poder confirmar o tráfego de comunicação, e assim acertar o programa para pegar exatamente os mesmos dados.

Hoje à noite postarei a segunda parte deste aparelho.

Paulo

aphawk · 17 de outubro de 2015

Projeto de um Analizador Lógico Portátil com Atmega1284P - Parte 7 - VISUALIZADOR I2C

Continuando o projeto, nosso aparelho vai também poder mostrar a velocidade da comunicação do Bus I2C, bastando que se mantenha uma tecla apertada durante a monitoração do Bus I2C.

Outras funçoes serão apresentadas quando o aparelho estiver completo. Vou citar apenas uma delas aqui :

Para evitar que o aparelho fique preso esperando por algum sinal noBus I2C, usamos o famoso Watchdog dos Avrs. Ele foi configurado para 4 segundos, então caso o aparelho inicie uma monitoração e não tenha nenhum sinal , após 4 segundos ele irá reinicializar, e voltará para o menu principal.

Para que possam ver a simulação funcionando, é necessário fazer a seguinte alteração no Proteus : existe uma nova versão de um modelo, com o nome de LCDPIXEL.DLL, que terá de ser colocada no diretório de MODELS do Proteus 8. Pode reescrever a antiga sem nenhum problema.

E para utilizar o Bascom, também é necessário que a nova library de nome glcd-Nokia3310-M.lib seja colocada no diretório LIB do Bascom.

De qualquer maneira, eu estou postando em anexo todos os arquivos já compilados para que se possa brincar bastante , vendo o funcionamento do display, seguindo o programa, e aprender ainda mais sobre o Proteus !

O circuito a ser monitorado é um Atmega32 conversando com um sensor de temperatura DS1621, o qual possui endereço hexadecimal 90 no Bus I2C ( para escrita e 91 para leitura ).

Primeiro, uma ideia do que irá aparecer no display :

A seguir, o que aparece no Debugger do próprio Proteus :

No display, a primeira linha sempre vai mostrar o número da sequência inicial que está sendo mostrada, e as informações que queremos seguem nas próximas linhas. O sinal de START é mostrado por uma seta para cima. Existem dois sinais de START em sequência, o segundo START recebe o nome técnico de START Repeated ( o Proteus mostra Sr ), mas é exatamente o mesmo sinal, então mostro a seta para cima para os dois sinais.

Depois vem o byte hexadecimal 90 , que como é par significa uma ESCRITA no DS1621, seguido de um pequeno "A" minúsculo, que é o sinal de um ACK. O próximo byte é um EE, qu na prática é o byte que foi gravado no DS1621, e a seguir temos outro ACK. Finalmente, aparece o sinal de STOP, que eu mostro como uma letra "P" maiúscula. Com isto terminou a primeira sequência, e eu termino a escrita na linha e pulo para a próxima linha.

Reparem na terceira sequência, ainda existe um último sinal a ser explicado, que é o sinal de NACK, ele aparece no display como um pequeno "N" minúsculo..

Parece feio vendo o display simulado... mas ficou bem legal no display real. Se voce quiser alterar o símbolo que aparece, é bem simples, basta alterar a fonte do caracter ASCII que eu escolhí.

A seguir, a tela do meu Proteus, usado no desenvolvimento....

Legal poder utilizar vários microcontroladores ao mesmo tempo numa simulação do Proteus, não é ???

Mais uma vez, o programa é meio grandinho para ser explicado passo a passo aqui, e eu documentei razoávelmente bem o programa fonte, que encontra-se em anexo.

Vou dar uma explicada nas partes principais.

O programa inicial, no qual eu me baseei para a captura e cálculo da velocidade da comunicação no Bus I2C foi feito por Vladimir Mitrovic, e postado no livro BASCOM AVR PROGRAMMING.

Mantive o cabeçalho original, pois o autor tem de receber os méritos ! Foi feito para um pequeno ATTINY2013 e usava um display de duas linhas por 16 caracteres cada, o que limitava bastante a visualização.

A rotina de captura dos dados é em ASM, e inicialmente não mostrava os ACK e NACK, o que eu considero um erro enorme, pois isso é muito útil na depuração. Assim, eu modifiquei e implementei a captura também para os ACK e NACK.

Logo percebí que o programa tinha algumas falhas, principalmente quando tinha de trabalhar com LEITURA ( numeros ímpares ! ) , e mostrava o valor errado. Isso foi complicado de descobrir o motivo.... e depois de alguns dias finalmente encontrei a falha, e resolví implementando duas pequenas subrotinas de teste. Ainda bem que foram necessárias apenas 3 instruções em cada subrotina para resolver, e desta maneira conseguí manter o limite de 25 ciclos de clock para o tratamento de cada período alto ou baixo do sinal SCL.

A rotina de captura armazena até 255 eventos I2C, que eu acho mais que suficiente para se fazer um Debug de algum problema.

Se , durante a captura, modificarmos a posição da chave 1 do Dip Switch, o programa pasa a medir a velocidade do Bus em vez de capturar os dados. Para isso, utilizamos o Timer3, e assim que detetarmos um sinal de START válido, contamos 8 variações de alto para baixo do sinal SCL. Após isto, paramos o Timer, e fazemos a conta da velocidade, simplesmente dividindo 160.000 pela contagem do Timer3 ( que na verdade contou ciclos de clock a 20 Mhz ! ) , o resultado já está em kHz, e é mostrado na tela.

Após a captura ter sido efetuada, utilizamos o BASCOM em todo o restante do programa, para podermos pegar os dados do Buffer de captura, interpretar e armazenar novamente em um outro local já no formato que iremos mostrar na tela.

O que é importante aqui : como neste projeto do aparelho eu utilizo um buffer em RAM de 8192 bytes, eu tenho sempre este espaço enorme para guardar qualquer informação que eu queira. Os dados que foram capturados sempre irão utilizar no máximo 255 bytes apenas, então eu uso o restante para facilitar o meu programa !!!!

No momento, estou mostrando apenas a primeira tela dos dados capturados. Quando o projeto estiver mais maduro, vai ser possível selecionar mediante alguns botões o avanço / retrocesso para a próxima tela, permitindo a visualização de toda a captura efetuada.

Seguem os arquivos para a simulação, bem como todos os programas fontes e também os mesmos compilados.

Paulo

I2C MONITOR.rar

alexandre.mbm · 17 de outubro de 2015

Seguem os arquivos para a simulação, bem como todos os programas fontes e também os mesmos compilados.

Não vou usá-los mas você esqueceu de anexá-los. Não vou usá-los porque não tenho o Proteus e o estudo de caso presente está muitíssimo além dos meus conhecimentos.

Parabéns! Não consigo imaginar onde mais eu encontraria, EM PORTUGUÊS, tamanha especialização.

Homi, se você gosta de ganhar dinheiro nessa área, por que já não criou site pessoal, com estratégias de lucro?!

De forma nenhuma eu quero incentivar você a deixar de compartilhar seus conhecimentos generosa e gratuitamente. Mas de algumas formas, com certeza, tem condições de fazer dinheiro a partir de conteúdos.

Sua redação está sensacional! (não me ative a gramática e ortografia, mas parece muito bom nisso também)

test man*~ · 17 de outubro de 2015

O esquema no proteus não está no anexo.

EDIT: Está lá...

[...] Finalmente, aparece o sinal de STOP, que eu mostro como uma letra "S" maiúscula. [...]

P,

No momento, estou mostrando apenas a primeira tela dos dados capturados. Quando o projeto estiver mais maduro, vai ser possível selecionar mediante alguns botões o avanço / retrocesso para a próxima tela, permitindo a visualização de toda a captura efetuada.

Vai dar para deslocar a tela para a direita?

Muito TOP, eu vou montar um pra mim... Muito show, você só conecta e vê o fluxo de dados no BUS... Nem precisa de um PC.

@alexandre.mbm, verdade...

Estou animando a aprender o assembly dos AVRs

aphawk · 17 de outubro de 2015

@alexandre.mbm,

Opa, é que voce foi mais rápido kkkk eu primeiro postei o texto, e estava lendo para ver se tava "apresentável", e depois postei os arquivos !

voce pode sim usar o Proteus ! Baixe a versão demo do site, voce pode abrir o projeto e simular, mas não vai poder alterar ! De qualquer maneira, pode aprender muito com isso !

Obrigado pelo incentivo !

Eu hoje trabalho com importação, o que já me garante meu sustento. Isso aqui é apenas o meu hobby, faço porque mantém minha mente ativa, e me obriga a estar sempre atualizado. Estou com quase 56 anos, nem sei como ainda consigo fazer estas coisas, pois é notório que quando envelheçemos perdemos a "facilidade" em programar, em manter todas as partes do projeto juntas enquanto bolamos o programa.

De vez em quando, antigos clientes me procuram para fazer um projeto específico para eles, que são provedores via Rádio, e então ganho mais um dinheirinho, que invisto em meu próprio laboratório para a minha diversão !

Mas gosto de fazer isto que eu faço aqui. É uma pena que poucos tem o interesse de aprender, pois no Brasil só falam de PIC, PIC, PIC, parece que em 2015 os professores pararam na tecnologia dos anos 1990 ... se incentivassem o aprendizado dos Avrs, teriam muito mais capacidade de fazerem projetos bem interessantes, e também lucrativos !

Este projeto que estou fazendo, aos poucos, no final vou disponibilizar gratuitamente para que as escolas técnicas e faculdades possam equipar seus laboratórios com um aparelho deste para cada aluno !

É muito importante que o aluno tenha na mão seu próprio osciloscópio ( simples, mas funcional ! ) , seu próprio analizador lógico, seu frequencímetro, enfim, quanto mais funções conseguir colocar aqui neste aparelho, mais útil vai ficar, concorda ?

Hoje os alunos tem de compartilhar bancadas, 3 ou até mais usam os poucos aparelhos, e isso não é a melhor maneira de aprender !

Quanto a um site pessoal, não penso nisso, prefiro ficar aqui, onde posso ajudar outros assuntos também. Não viso lucro, não recebo nada pelo que faço aqui, apenas desejo que com minha contribuição alguém possa melhorar de vida !

Já tive algumas surpresas aqui, vou te contar uma : Fazem alguns anos, eu ajudei um aluno iniciante, que estava tentando montar um circuito e não funcionava. FuI trocando mensagens com ele, até conseguir fazer o circuito funcionar. Depois de alguns meses, ele me procurou novamente, estava montando seu primeiro circuito com microcontrolador, e eu também ajudei. O tempo passou, e no inicio deste ano recebí uma mensagem dele, ele acabara de se formar Engenheiro Eletrônico, e me agradeçeu pelo incentivo que eu dei e que ele devia a sua formatura não aos professores, e sim a mim, porque eu sempre estive perto quando ele precisou. E pediu para eu continuar a ensinar !

Essa mensagem me encheu os olhos de lágrimas, e senti um orgulho que não sentia faziam muitos anos !

São essas pessoas que me motivam a estar aqui, bolando novidades, tentando passar o conhecimento que logo vou perder, quem sabe aparece alguém para continuar este trabalho ?

@test man*~,

Opa valeu, já corrigí o texto.

Olha, para manter este aparelho bem barato, eu escolhi usar o display mais barato que existe ! E claro que tem pouca resolução, apenas 84 colunas por 48 linhas. Devido a isto, eu só consigo mostrar 14 caracteres por linha, então se tiver de mostrar uma linha com mais caracteres, eu tenho de cortar ela e mostrar o restante na linha de baixo.

Para deslocar a tela para a direita, vai dar um baita trabalho de programação...... melhor poder mudar a tela para a próxima !

Mas fique tranquilo porque eu sempre termino a linha sem cortar algum hexadecimal no meio kkkk sempre vai terminar com um sinal tipo Stop, Nack ou Ack.

Eu poderia mudar o display para um mais completo, tipo o ILI9341, mas dá para comprar uns 4 desses NOKIA3310 pelo preço dele....

A ideia é justamente ser um aparelho barato, que voce possa montar pelo preço de duas pizzas !!!!! O fato de não precisar de um PC é que faz toda a diferença, ajuda muito !

Para isso, contei com a ajuda de muitos amigos, como o Mrshilov ( pegou o meu código do Nokia3310 e criou uma library ainda bem mais rápida e corrigiu os bugs que apareceram na hora ! ) , o próprio Mark ( criador do Bascom, e que me mandou o .DEF corrigido do Atmega1284P ) , e o pessoal do suporte do Proteus, por corrigir o funcionamento do modelo do Nokia3310. Todos ajudaram para que estejamos chegando neste ponto de hoje, fazendo milagres com o display gráfico mais barato que existe !

Eu penso que é incrível eu ter encontrado os problemas que tive, pois significa que poucos estão usando esse hardware hoje em dia, talvez pela sua pouca resolução. Mas se isto o torna barato, é ideal para quem não pode gastar muito !

Sobre o Assembly, conseguir fazer algo que visualize I2C a até 400 Khz é muito complicado sem um ARM.... estou tirando leite de pedra com ele usando os Avrs !

Mas é util apenas para esses projetos cuja temporização é crítica.

Se escrevesse em C ou em Bascom, não seria possível este aparelho. Porisso que eu insisto que os iniciantes aprendam o Bascom, por tornar muito mais lógico todo o programa, devido a já inicializar os hardwares internos e permitir um controle excepcional, com um código bem claro.

Onde o Bascom não é suficiente, entra o ASM !

Paulo

alexandre.mbm · 17 de outubro de 2015

@aphawk, você teria condições de — e quereria — acrescentar ao projeto que está compartilhando conosco uma estimativa básica de custos? Preços aproximados dos principais itens de "matéria prima".

aphawk · 17 de outubro de 2015

@alexandre.mbm,

Olha, os principais componentes ( e mais caros ) são um Atmega1284P, que comprei na Farnell por cerca de R$ 35,00 , um display Nokia 3310 ( que não faço nenhuma ideia o motivo de ser vendido no Mercado Livre como Nokia 5110 embora seja compatível totalmente ) custando cerca de R$ 18,00 , um Rotary Encoder que custa cerca de R$ 12,00, e mais algumas peças baratas como um regulador 7805 e um regulador de 3,3 Volts tipo LM1117, mais alguns resistores, capacitores , quatro teclas tipo push-buttom , um soquete de baterias de 9 Volts, e uma chavinha tipo liga/desliga.

Sem o circuito impresso, não passa de uns R$ 90,00 . Posso até fazer o projeto do lay-out, mas para fabricar eles tem de ser um lote mínimo de 100 peças para ter um custo baixo, senão fica caro. Isso eu vou pensar mais à frente.

Agora, comprando as peças mais caras no Ebay, custaria cerca da metade !!!!

Também seria legal usar algum tipo de caixa padrão para a montagem. Pensei em fazer uma caixinha sob medida com uma impressora 3D, eu tenho alguns produtos que comprei no Ebay que possuem uma caixa desse tipo, e ficou muito bom !

Tenho de usar componentes comuns e baratos, para que todos possam montar sem sentir no bolso !

Paulo

alexandre.mbm · 17 de outubro de 2015

Sem o circuito impresso, não passa de uns R$ 90,00 . Posso até fazer o projeto do lay-out, mas para fabricar eles tem de ser um lote mínimo de 100 peças para ter um custo baixo, senão fica caro. Isso eu vou pensar mais à frente.

Como projetista com as inspirações que você já nos explicou, você poderia procurar parcerias e desenvolver isso para universidades. Como meio de facilitar, pode ir primeiro às particulares.

Também seria legal usar algum tipo de caixa padrão para a montagem. Pensei em fazer uma caixinha sob medida com uma impressora 3D, eu tenho alguns produtos que comprei no Ebay que possuem uma caixa desse tipo, e ficou muito bom !

Você já encomendou impressão 3D? Ou tem uma impressora?

Por quanto será que sai uma caixinha impressa por terceiro?

Por quanto será que sai a caixa que a própria pessoa imprime com sua impressora?

aphawk · 17 de outubro de 2015

@alexandre.mbm,

Sim, eu ainda estou esperando terminar tudo primeiro, ter um protótipo funcional, e aí sim vou ver se encontro interessados.

Eu ainda não comprei a minha impressora, fico sempre confuso na hora de escolher uma. Mas tenho um amigo que montou uma, e ele está conseguindo fazer coisas bem legais com ela.

Ainda não fiz nenhuma cotação , mas sei que o custo de fazer uma em sua própria impressora é muito baixo, os filamentos de plástico são bem baratos. Num chute, eu diria que fazer as partes para montar uma caixinha sob medida custaria menos de R$ 4,00 , mas demoraria cerca de duas horas para isto.

Paulo

aphawk · 18 de outubro de 2015

Projeto de um Analizador Lógico Portátil com Atmega1284P - Parte 8 - GERADOR DE FREQUÊNCIAS POR HARDWARE

Não sei se repararam, mas eu deixei dois Timers sem uso até agora : o Timer2 e o Timer1. Em todos os programas, usei apenas os Timers0 e o Timer3. A minha insistência em usar apenas esses até agora vai ser recompensada e com juros !

Podemos aproveitar o hardware do Atmega1284P para que ele forneça, de forma automática e sem precisar de nenhuma rotina de software ou de interrupção, uma frequência desejada em uma de suas saídas ! Pode ir de 1 Hz até 5 Mhz.

Assim, caso precisemos gerar alguma frequência para ser aplicada no circuito que desejamos medir alguma coisa com nosso aparelho, basta selecionar este pequeno programa, informar qual é a frequência desejada, e o programa vai procurar configurar os dois Timers para que seja gerada a frequência mais próxima possível !

Nem sempre vamos conseguir gerar o valor que queremos, mas sempre podemos quebrar um galho com uma frequência bem próxima.

Qual o truque que usei para isto ?

Simples : Usei o Timer2 como Timer, e o Timer1 como Counter, e liguei a saida do Timer2 à entrada de contagem do Timer1 !

Usando o Timer2 com prescaler=1 , posso dividir a frequencia de clock por qualquer valor entre 2 e 256 , obtendo assim diversos valores possíveis de serem aplicados como frequência de entrada do Timer1, o qual também permite dividir essa frequência por um valor entre 2 e 65536 !!!!

O programa testa todas as possíveis divisões do Timer2, lê as frequências que serão geradas, e usa a fórmula do Datasheet do Atmega1284 para calcular o valor de OCR que seria necessário para gerar a frequência. Depois faz o cálculo dos divisores do Timer1 necessários para gerar a frequência que queremos. Mas quase sempre esse numero vai ser um numero fracionário, então eu arredondo ele e recalculo qual seria a frequência gerada, tanto para cima como para baixo. Calculo o erro entre as frequências, e armazeno para comparar com os outros valores. Sempre que tenho um erro menor, armazeno os novos valores.

Ao final do processo, pego os valores selecionados, mostro no display, e programo os dois Timers para gerar a frequência !

Seguem duas telas para as frequências de 13400Hz e de 60 Hz :

O mais legal é que uma vez configurados , os Timers fazem todos o trabalho de forma automática, não interferindo em nenhum outro programa que desejarmos rodar em nosso aparelho !

Segue em anexo tudo o necessário para rodar a simulação, bem como os fontes do programa. Agora, faltam agora poucos módulos para serem apresentados !

( E também estão acabando os coelhos de dentro da cartola ... ! )

Boa diversão !

Paulo

frequency generator.rar

Intrudera6 · 18 de outubro de 2015

5 Ghz ? Não seria 5Mhz ?

aphawk · 18 de outubro de 2015

@Intrudera6,

Heheh voce leu o que eu escreví de manhã, mas eu já havia corrigido logo depois do almoço para 5 Mhz !

Sim, 5 Mhz, eu até poderia mexer no programa e conseguir os 10 Mhz, fazendo o Timer1 virar Timer em vez de Counter, e poderia gerar os 10 Mhz. Talvez coloque isso na versão final.

A ideia de procurar automáticamente no loop principal é a principal inovação desse projeto. Já havia visto vários projetos que geravam várias frequências, mas todos usavam tabelas pré-programadas. Este aqui acha os valores "na marra", podendo pesquisar mais de 500 combinações dos divisores, e achar a melhor delas.

Paulo

test man*~ · 18 de outubro de 2015

[...] então se tiver de mostrar uma linha com mais caracteres, eu tenho de cortar ela e mostrar o restante na linha de baixo[...]

Entendi, eu estava achando que os dados eram perdidos mas eles continuam na próxima linha . (mesmo com os arquivos substituídos não consigo simular, mas não há problema algum...)

[...] Se escrevesse em C ou em Bascom, não seria possível este aparelho. Porisso que eu insisto que os iniciantes aprendam o Bascom, por tornar muito mais lógico todo o programa, devido a já inicializar os hardwares internos e permitir um controle excepcional, com um código bem claro.

Onde o Bascom não é suficiente, entra o ASM !

Saquei, vou aprender só o basicão mesmo (botão + led, pisca led + timer, contador + 7 seg., etc.) só para conhecer mesmo!

Beginner's introduction to AVR assembler language: http://www.avr-asm-tutorial.net/avr_en/

---

Terminei o código para o TMP101 (sensor de temperatura 9~12 bits I2C com função de alerta), não sei... Mas acho que ele não é um componente famoso (um amigo que me deu) mas vou postar o código aqui, quem sabe? Talvez um dia pode ser útil para alguém. O bom dele é que a temperatura não fica variando constantemente, às vezes até parece que ele estragou e está medindo sempre a mesma temperatura hehe... Obrigado por me apresentar os AVR's Paulo @aphawk e também pelo tutorial...

PS.: Perto do que você está fazendo (osciloscópio/logic analyzer/) este código não é nada (dá até vergonha de postar, mas é a vida né?)

Código:

'$sim$regfile = "m2560def.dat"$crystal = 16000000 $hwstack = 40$swstack = 22                                               ' Pior caso é a função "Configura_limites_tmp1                                                            ' 01" são passados 3 parâmetros + 6 variáveis                                                             ' locais = 9 | 9*2=18 | 18+4=22 (Help).$framesize = 43                                             ' Pior caso função é a função "Configura_                                                            ' limites_tmp101" 24 bytes conversion buffer                                                             ' + 8 bytes (4 integer) + 3 bytes + 8 bytes                                                             ' (2 single) total de 43. '----------------------------- Configurando periféricos ------------------------------'$lib "I2C_TWI.LBX"                                          ' Será usado I²C por hardwareConfig Twi = 400000                                         ' 400KHz SCL (Fast I2C) Config Com1 = 9600 , Synchrone = 0 , Parity = None , Stopbits = 1 , Databits = 8 , Clockpol = 0Open "com1:" For Binary As #1                               ' Será usado USART 0 (Pinos TXD0 e RXD0) '------------------------------ Declaração de variáveis ------------------------------'Dim Temperatura As Single , Temperatura_string As String * 7       ' -XXX.X\0 '---------------------------- Inicialização de variáveis -----------------------------' '------------------------- Configuração da direção dos pinos -------------------------'Config Pinb.7 = Output                                      ' Pino B7 como saída '----------------------------------- Nomeando pinos ----------------------------------'Led0 Alias Portb.7                                          ' Led0 conectado ao PB7 '------------------------ Inicialização dos estados dos pinos ------------------------'Led0 = 0                                                    ' Inicializa o pino do Led0 com 0 '----------------------------- Declaração de constantes ------------------------------' '------------------------------------ Sub-rotinas ------------------------------------'Config Submode = New$include "tmp101.bas" '--------------------------------- Código principal ----------------------------------'' Inicializa o TMP no modo 12 bits (0,0625°C resolução), Alerta_ativo_alto / Modo_interrupção figura 11' datasheet (TI), Shutdown desligado assim que uma medição termina o TMP inicia outra, Add0_ground ' operação realizada no TMP que está com o pino Add0 ligado ao GND. Call Inicializa_tmp101(tmp_12_bits , Faltas_consecutivas_2 , Alerta_ativo_alto , Modo_interrupcao , Shutdown_desligado , Add0_ground) ' Seta como limite inferior -19.2 e superior 31.5°C, tmp Add0_ground operação realizada no TMP que ' está com o pino Add0 ligado ao GND.Call Configura_limites_tmp101( -19.2 , 31.5 , Add0_ground) ' Iniciar a conversão, deve ser usado quando o Shutdown está ligado.'Call Inicia_conversao(add0_ground)                         ' Inicia a conversão'Waitms 321                                                 ' Espera o término da conversão 12 bits'Call Ler_temperatura_tmp101(temperatura , Add0_ground)     ' Lê o resultado da conversão Do  Led0 = Not Led0  Waitms 320                                                ' No modo 12 bits o TMP realiza uma                                                             ' leitura a cada 320mS.  Call Ler_temperatura_tmp101(temperatura , Add0_ground)    ' Ler a ultima temperatura medida pelo                                                             ' TMP que está com o pino Add0 no GND.   Temperatura_string = Fusing(temperatura , "#.#")          ' Apenas um número após a vírgula.                                                 Print #1 , Chr(12) ; "T: " ; Temperatura_string ; "gC" ;  ' Chr(12) Form feed \f - Limpa o                                                             ' hyperterminal -> "\fT: XXX.XgC".  nopLoop '-------------------------------------------------------------------------------------'End

As palavras de configuração para serem usadas nas chamadas das funções estão definidas no arquivo "tmp101.bas".

Código com o arquivo tmp101.bas: http://www.4shared.com/rar/16kGjj66ba/TMP101_ATmega2560_CCO.html?