Encoder com pic

Charlie Harper · 30 de junho de 2015

Help mee ... então quero usar um pic para saber para qual lado o encoder esta, praticamente ter na saida 2 leds, para um lado pisco 1 led e para outro lado pisco outro led.. objetivo é que cada "clique" do encoder seja um pulso piscando o led respectivo. Não quero usar interrupção, porque quero usar o maximo de encoders em um pic

testei este programa que peguei da internet.. não consigo modificar para o sinal sair em dois pinos ( um para cada lado) depois da comparação eu usei

OUTPUT_BIT (PIN_B1);

OUTPUT_BIT (PIN_B0);

mas não da muito certo :$ ... e quando da certo os leds acendem fracos.. OBJETIVO É QUE CADA CLIQUE DO ENCODER PISQUE UM LED, não quero para contar, mas somente para pulsos OBRIGADO GENTE

codigo que peguei da internet

#include <16F628A.h>

#FUSES NOWDT, XT, PUT, NOPROTECT, NOBROWNOUT, NOLVP, NOCPD

#use delay(clock=4000000)

#byte porta = 0x05 // Asignamos PortA.

#byte portb = 0x06 // Asignamos PortB.

// ---------- Programa Principial ----------

void main()

{

port_b_pullups(FALSE); // Sin resistencias pullups a las salidas del puerto B.

setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1); // Al no usar el TIMER configuramos lo más básico.

setup_comparator(NC_NC_NC_NC); // Sin comparadores.

setup_vref(FALSE); // Al no usar comparadores no necesitamos Vref.

//---- Fin de la configuración del 16F628A ----

int8 x; // Declaramos el valor de X como byte, se corresponderá con los 8 LEDs de salida.

int8 enc; // Se almacenará el valor actual de RA0 y RA1, hasta la siguiente comparación.

int8 aux; // Se almacenará el valor anterior de RA0 y RA1, hasta la siguiente comparación.

set_tris_a(0b11111); // Puerto A como entradas. Sólo usamos RA0 y RA1.

set_tris_b(0b00000000); // Puerto B como salidas, para los 8 LEDs.

portb=0; // Inicialmente ponemos a cero el puerto B.

x=0; // Inicialmente ponemos a cero la variable que se usa para contar.

enc=0; // Inicialmente ponemos a cero la variable que tomará los valores de RA0 y RA1.

while (true)

{

aux=enc; // Igualamos 'AUX' y 'ENC' para luego comparar cuando cambie 'ENC'.

enc=porta & 3; // Aislamos RA0 y RA1 como un número de 2 bits y se carga en la variable 'ENC'.

if ((aux==2)&&(enc==3))// Si en la comparación hay flanco de subida,

{

x++; // entonces incrementar una unidad el valor de X.

}

if ((aux==3)&&(enc==2))// Si en la comparación hay flanco de bajada,

{

x--; // entonces decrementar una unidad el valor de X.

}

portb = x; // El valor de X sale por el puerto B, los 8 LED de salida.

}

.if · 30 de junho de 2015

Um sinal de encoder geralmente é defasado 90º um do outro . Essencialmente você vai ter que saber houve variação dos sinais (pinos) qual dos dois variou primeiro, guardar esta informação e comparar com o próximo evento. Tipo assim se um estava em 0 e mudou pra 1 e o outro estava em 0, então é direita, se estava em 1 é esquerda. Agora é só fazer as outras 3 análises...

Confusão? também acho. Vá tentando aí. Se não conseguir em menos de 3 meses e depois pedir com jeitinho te passo mais informações

Agora você pode usar seu fonte (que não analisei direito), basta guardar o valor de x em y numa iteração e na próxima comparar este valor y com x: se maior-->direita, se menor-->esquerda, se igual= parado... ou algo assim

test man*~ · 1 de julho de 2015

Você usou o output_bit assim:

OUTPUT_BIT (PIN_B1);OUTPUT_BIT (PIN_B0);

E deveria ser assim:

OUTPUT_BIT (PIN_B1, valor);OUTPUT_BIT (PIN_B0, valor);

Sendo valor igual a zero (0) ou um (1) para saída em nível baixo ou alto.

Você também pode fazer assim:

#byte portb  = 0x06 #bit pino_b0 = portb.0#bit pino_b1 = portb.1::pino_b0=valor;pino_b1=valor;

.if · 1 de julho de 2015

Amigos perdão. Por desconhecer a sintaxe deste compilador não percebi que sua dúvida era tão simplória. Achei que queria saber os princípios de detecção de sentido de rotação do encoder. Peço que desconsidere o post e espero que a resposta do amigo @test man*~ seja a melhor.

Sucessos!

test man*~ · 1 de julho de 2015

Não... Não desconsidere a resposta do @Isadora Ferraz... Eu só percebi esse errinho no uso da instrução mas não sei como um Encoder funciona... Se houver dúvida sobre o Encoder siga a resposta do @Isadora Ferraz... (Eu também não analisei o código)

Meu @mention não funciona

Charlie Harper · 1 de julho de 2015

Ola boa noite Isadora e test man... obrigado por responderem ao topico.. eu havia percebido esse erro de digitação no programa e resolvi... testei e da certo.. o problema é que quando giro um pouco rápido, o led pisca normal a cada clique, mas o outro led (lado) pega um sinal.. EX: GIRO rápido, A CADA 15 "CLIQUE" DO ENCODER O OUTRO LED PISCA UMA OU MAIS VEZES, algo como interferencia... coloquei capacitores para o efeito debouncing, melhorou, mas não resolveu, vou ter q resolver na programação... As dicas da Isadora são boas em comparar as saidas.. mais informações ficarei grato, enquanto isso vou a luta aqui... Boa noite ;D

aphawk · 2 de julho de 2015

@test man*~,

Esses encoders trabalham com dois sinais em quadratura de fase. Normalmente os dois sinais tem nivel 1, e aquele que vai para 0 enquanto o outro permanece em 1 define o sentido da rotação. Mas existe um ciclo completo para que os sinais voltem para 1 em repouso. A maneira mais simples é utilizar uma interrupção por descída nos dois sinais, e ver a sequência deles.

Paulo

test man*~ · 2 de julho de 2015

@aphawk me fazendo engolir conhecimento a força HAHAHA ... Eu li o que você disse e fui procurar na net para terminar de entender o funcionamento, agora sei como ele funciona HEHE

aphawk · 2 de julho de 2015

@test man*~,

KKKKKK eu ????? Hehehe olha eu vou te falar uma coisa : o cara que fez o Bascom criou uma função só para tratar encoder .... você vai na página, o cara explica tudo tim tim por tim tim .....tem vários exemplos de uso desses encoders, desde 2004.

http://avrhelp.mcselec.com/encoder.htm

Aí , chegou a minha vez de usar um encoder num programinha, e nunca conseguí fazer o maldito funcionar direito !!!!! Sempre dava erro !

Resolví estudar a função que ele criou, vendo os diagramas de sinal dele, e no papel tudo deveria funcionar..... aí resolvi comprar um encoder na Farnell, paguei uma nota nele, e não é que com esse encoder caro a função funciona direitinho ?????

Resolvi procurar encoders aqui na Santa Ifigênia em SP, comprei três diferentes, um em cada lugar. Cheguei em casa, e .... nenhum dos três funcionou direito !!!!!

Moral da história : Existem ENCODERS e encoders ..... esses baratinhos são uma droga, geram sinais tudo esquisitos, um baita monte de ruídos... então resolví escrever uma rotina minha, tratando tudo o que pode dar de errado, e consegui uma que ficou confiável para todos os encoders que testei .

Se quiser dar uma olhada nela , está aqui :

http://forum.clubedohardware.com.br/forums/topic/937085-tutorial-de-projetos-com-avr-design-programação-em-basic-e-simulação-no-proteus/page-10#entry6126320

Infelizmente não consigo passar esse programa para a linguagem C para usar nos Pics. Estou numa fase em que prefiro fazer tudo da maneira mais simples !!!

Mas sempre é interessante saber como as coisas funcionam, não é ? Pense sempre assim, melhor sobrar conhecimento do que faltar kkkkkk !

Um abraço !

Paulo

test man*~ · 2 de julho de 2015

Verdade =D @aphawk... Eu estou aproveitando que estou com bastante tempo (daqui a pouco ele acaba) para entender como os microcontroladores funcionam. Para isso estou aprendendo assembly, estou no PIC16 vou passar pelo PIC18, PIC24 e dsPIC...

Dai pretendo ir para os microcontroladores da ATMEL, vou começar pelo basic (usando o seu tutorial) e depois vou para o Assembly... Mas vai demorar um pouco, pois como eu disse, o tempo agora está extenso mas daqui a pouco vai ficar curtinho curtinho (tomara que não acabe) =D... Mas devagarzinho eu chego .

"Melhor sobrar conhecimento do que faltar kkkkkk!"

aphawk, 2015.

aphawk · 2 de julho de 2015

@test man*~,

Olha, sei que vão me criticar pelo que vou falar agora ..... experimente inverter, agora que você está nos Pic16 é uma excelente hora para mudar para os Avrs, em termos de hardware voce vai ver que é quase tudo igualzinho, vai perceber que sobram interrupções de hardware de monte nos AVR's...a migração é facílima, e veja o Assembly deles, porque é muito, mas muito mais fácil, tudo linear, nada de chaveamento de bancos, e tem muitas instruções a mais que os Pics. Eu sempre programei em Assembly para microprocessadores CISC ( 8080, Z-80, 6502, 8085, 8088, 80286.... ), escrevi um BIOS de IBM-XT em 1986...., e quando ví pela primeira vez o Assembly dos Pics, eu achei que tava em outro planeta... não era possível ser tão complicado, e resolví programar em Basic. Aliás, sempre integrei Basic e ASM em todos os micros que trabalhei ..... fiz muitos módulos TSR para os micros IBM na época sagrada do DOS.

Agora, hoje, usando o Basic com os AVR's, existem algumas raras situações onde a temporização é crítica, e resolvi aprender o Assembly dos AVR's, e olha, foi como se eu estivesse em casa o tempo todo !!!! Muito mais simples, muito mais poderoso em termos de instruções, a grande maioria faz em um ciclo de máquina, tudo linear, sem malditos bancos, eu simplesmente achei que estava programando de novo um 8080 !!! Me dei muito bem, e misturo fácilmente trechos de Basic com Assembly onde eu achar que é vantagem. Isso de mixar código em Basic e Assembly no meu programa, mesmo usando interrupções, me dá um poder que eu nunca achei que teria mesmo nos projetos mais críticos.

Pode ser que eu saia para os ARMs no futuro. Hoje, como posso usar um Atmega328 rodando a 32 Mhz ( embora no manual só vai até 20 Mhz ), é mais do que o suficiente para qualquer projeto meu. Na verdade, em quase todos uso o clock interno de 8 Mhz, que já me dá o mesmo desempenho de um Pic rodando a 32 Mhz.

Mas para os Pics, não vou mais de jeito nenhum. Quem anda prá trás é caranguejo.....

Paulo

.if · 2 de julho de 2015

@Charlie Harper poste o fonte comentado de como está identificando a direção do encoder. Pode ser alguma coisa como quando x++ ou x-- passa de 255...0 p.ex. Bom .. só chute.

@test man*~ realmente a 'vantagem' do pic das "only 35 instructions to learn" acaba em si mesma. Como sugestão, entenda com relativa profundidade o hw do mc que está aprendendo e parta logo pra uma linguagem de mais alto nível. Sugiro também aguardar o momento certo pra incorporar algo como asm("nop") no meio do seu fonte. voce deve demorar um pouco pra chegar lá. Note que provavelmente pro amigo @aphawk não foi de imediato.

Mas enfim... sua alma, sua palma...

abç

test man*~ · 2 de julho de 2015

Malditos bancos... Nem me fala!!! HAHAHAHAHAHAAHAHA agora até que estou achando bem tranquilo essa tranqueira toda mas quando passei do 16F628A para o PIC16F877A além dos bancos surgiu a paginação da memória de programa com a instrução goto/call não possuindo bits suficientes para ir para todos os endereços da memória de programa, WHAT THE F*** IS THIS!?!? Pensei na hora... Foi nesse momento que vi vários posts criticando a arquitetura dos PICs de 8 bits e elogiando a dos ucs ATMEL... Há um tempo atrás comecei a ler o datasheet de um ATMEL (8 bits) e de cara vi que parecia ser uma coisa mais organizada, sei lá... Não sei explicar... Até a distribuição dos pinos tipo TX pino Y, RX pino X, SDA PINO Z me pareceu mais organizada...

Enfim, fui para o assembly para entender a operação do microcontrolador e assim saber o que está acontecendo quando escrevo um código em C (com o CCS)... Mas acabei achando muito interessante e resolvi aprofundar um pouco mais...

@test man*~ [...] Como sugestão, entenda com relativa profundidade o hw do mc que está aprendendo e parta logo pra uma linguagem de mais alto nível.

Sim, no meio dos estudos eu pensei nisso, não vale a pena continuar com assembly apesar dele ser extremamente interessante e você saber exatamente o que está acontecendo. Quando eu terminar com o livro "Desbravando o mocrocontrolador PIC16F628A" vou voltar para o CCS mas não usarei algumas funções dele (como spi_write, i2c_write, setup_spi, #use i2c...), sempre que der criarei as minhas (para saber o que está acontecendo)...

[...] Experimente inverter, agora que você está nos Pic16 é uma excelente hora para mudar para os Avrs, em termos de hardware voce vai ver que é quase tudo igualzinho, vai perceber que sobram interrupções de hardware de monte nos AVR's...a migração é facílima, e veja o Assembly deles, porque é muito, mas muito mais fácil, tudo linear, nada de chaveamento de bancos, e tem muitas instruções a mais que os Pics.

@aphawk Você me convenceu... Acabei de abrir o datasheet do ATmega328P e P%@& Q$@ P%#&$ (desculpe-me pela expressão) o vetor de interrupção dele é brilhante... É separadinho um endereço para cada interrupção... O PIC possui 1 endereço para todas as interrupções e quando uma ocorre você deve fazer um tratamento para ver qual foi (eu imagino que seja assim, ainda não cheguei nessa parte do livro). Bem... Vou terminar com o livro e ir para o seu tutorial (Basic) e dele vou para o assembly...

aphawk · 3 de julho de 2015

@test man*~,

Sim, até nos vetores eu me sentí em casa, parece um Z-80 !!!! Repare que se você comparar os hardwares do Pic16 e do AVR, os módulos são muito parecidos, timers, A/d, PWM, ah os Avrs tem alguns modos de baixo consumo que são muito interessantes de se usar, consumindo cerca de 60 uA em repouso. Não é algo igual à familias como MSP, que consomem bem menos, mas já dá para fazer projetos com baterias e ter uma longa duração !

Uma coisa legal no Atmega328 : dá para gerar interrupção de mudança de nível em quase qualquer pino, e fica fácil identificar qual pino gerou a interrupção.

Como a @Isadora Ferraz advinhou, primeiro fiquei um bom tempo só no Basic, pois ele me permite fazer tudo o que eu quero !

Eu fiquei tão desesperado quando olhei o Assembly dos Pics que nem quis saber como funcionava o Assembly dos Avrs, então partí para o Bascom, apoiado pela excelente compatibilidade dele com o Proteus, fica fácil simular, testar, acertar todo o projeto ANTES de partir para a montagem ! E fui indo alguns anos só com o Basic, até que eu tentei fazer um analisador lógico que capturasse eventos a pelo menos 1 Mhz em 4 entradas simultâneas, e aí que o Basic não deixou eu atingir essa performance. Mas também se usasse o C também não daria, e foi só nessa hora que eu resolvi baixar um bom tutorial de Assembly para AVRs. E em menos de meia hora, já estava codificando a minha rotina de captura em Assembly, e consegui até passar de 1 MHZ na captura dos eventos !

E me sentí um tolo.... esse Assembly é tão natural para mim que não me conformo que fiquei anos sem sequer ver como funcionava !

Mas continue, dá uma olhada no tutorial, veja as montagens todas, os programas, e dê uma olhada no tópico completo destacado acima, sempre coloquei montagens interessantes que ainda não constam no tutorial.

Vai ver que é bico usar I2C, SPI, PWM, low power modes, watchdog, serial, Ints, tudo está previsto no Bascom !

Paulo

Charlie Harper · 6 de julho de 2015

@aphawk seus argumentos são bem convincentes, obrigado por responder ao topico, mas agora quero usar o que eu tenho em mãos, vou pensar seriamente em suas dicas e sugestões.

@Isadora Ferraz aqui esta o codigo q estou usando, quando o pic percebe uma troca de 10 para 11 (do encoder) o led ficar acende durante 30 ms, e de 11 para 10 o outro led acende 30 ms também.. deu certo aqui mas acontece que se eu giro rápido o led do outro lado "pega" sinal as vezes (pisca led) .. aqui vai o codigo

#include <16F628A.h>

#FUSES NOWDT, NOPROTECT, NOBROWNOUT, NOLVP, NOCPD

#FUSES INTRC_IO

#FUSES NOPUT

#FUSES NOMCLR

#use delay(clock=4000000)

#byte porta = 0x05

#byte portb = 0x06

void main()

{

port_b_pullups(FALSE);

setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);

setup_comparator(NC_NC_NC_NC);

setup_vref(FALSE);

//---- Fim da configuração

int8 enc1; // armazena valor atual de ra0 e ra1

int8 aux1; // armazena valor antigo de ra0 e ra1.

set_tris_a(0b11111111);

set_tris_b(0b00000000);

portb=0;

enc1=0; // zeramos a variavel q le os valores de ra0 e ra1

while (true)

{

portb=0;

aux1=enc1; // Igualamos 'AUX1' e 'ENC1'

enc1=porta & 3; // direcionamos entrada para ra0 e ra1

delay_us(80);

if ((aux1==2)&&(enc1==3))// se houve mudança de 10 p 11

{ delay_ms(12);

output_bit(pin_b0, true);// então acende o led q esta em b0

//delay_ms(15);

output_bit(pin_b1, false);

delay_ms(30);

portb=0;

}

if ((aux1==3)&&(enc1==2))// se houve mudança de 11 p 10

{ delay_ms(12);

output_bit(pin_b1, true); //acende led b1

//delay_ms(15);

output_bit(pin_b0, false);

delay_ms(30);

portb=0; // zera as saidas

}

aphawk · 6 de julho de 2015

@Charlie Harper,

Hehehe os argumentos não foram para voce... você já tá enfrunhado nos Pics, e tem de terminar o que começou. Mas sempre é bom pensar em sofrer menos no futuro, eu costumo indicar os caminhos, mas seguir é decisão que não cabe a mim. De qualquer maneira, eu não consigo te ajudar na linguagem C, e só posso ficar acompanhando aqui os colegas, ok ?

Paulo