LusoRobótica - Robótica em Português
Sistemas específicos => PIC => Tópico iniciado por: tretas em 22 de Novembro de 2009, 17:51
-
Ola pessoal,
estou a aprender a programar "µC pics" com o compilador ccs e estou aqui com um problema no seguinte código :
#include <16f877A.h>
#fuses NOWDT,XT, PUT, NOPROTECT, BROWNOUT, LVP, NOCPD, NOWRT, NODEBUG
//#device ADC=10 //CAN 10 bits
#use delay(clock=8000000)
#use rs232(baud=19200, parity=N, xmit=PIN_C6, rcv=PIN_C7, STOP=1, BITS=8)
#define saida_pistao14 PIN_A1
#define saida_pistao58 PIN_A2
unsigned int16 tempo_pistao14 =10000, tempo_pistao58=20000;
////////////////////////////////////////////////////////////////////////////////
// TIMER 0 //
////////////////////////////////////////////////////////////////////////////////
#INT_timer0
void trata_timer0 ()
{
static int conta;
// reinicia o timer0 em 6 mais a contagem que já passou
set_timer0 ( 6 + get_timer0() );
conta++;
// se já ocorreram 250 interrupções ( 256 - 6 = 250 )
if ( conta == 250 ) //
{
conta = 0;
// tempo_pistao14 -= tempo_pistao14 ;
tempo_pistao14 = tempo_pistao14 - tempo_pistao14;
}
}
////////////////////////////////////////////////////////////////////////////////
// MAIN //
////////////////////////////////////////////////////////////////////////////////
void main()
{
output_high(PIN_E0);
enable_interrupts ( GLOBAL ) ;
// configura o timer 0 para clock interno e prescaler dividindo por 32
setup_timer_0 ( RTCC_INTERNAL|RTCC_DIV_32 );
set_timer0 ( 6 ); // inicia o timer 0 em 6
// habilita interrupções
enable_interrupts ( INT_timer0 );
while(TRUE)
{
if (tempo_pistao14 >= 1)
output_high(saida_pistao14);
else
output_low(saida_pistao14);
if (tempo_pistao58 >= 1)
output_high(saida_pistao58);
else
output_low(saida_pistao58);
}
}
Queria que o PINO RA1 fica-se activo durante 10s e fica no máximo 1 ... penso que o meu erro esta na maneira como estou a gerir o timer0 mas não estou a ver onde.
pois todos os 4ms estou a ter uma INT mas depois
// se já ocorreram 250 interrupções ( 256 - 6 = 250 )
if ( conta == 250 ) //
{
conta = 0;
// tempo_pistao14 -= tempo_pistao14 ;
tempo_pistao14 = tempo_pistao14 - tempo_pistao14;
}
0.004 ms * 250 = 1s ... penso eu de que ... logo não vejo onde estou a errar
Cumprimento
Zé tretas
-
Olá
Vou ver se consigo ser util...
:)
Em primeiro julgo que o fuse XT é para frequencias abaixo de 4Mhz... confirmem, sff.
Depois podias usar um timer de 16 bits, penso que seria mais facil.
O teu pic a 8MHz tem ciclos de maquina a 2MHz o que quer dizer um periodo de 0,5us por incremento do timer.
Se corrigires o timer 0 para 6 quer dizer que ele estoura ao fim de cada (256-6) 250 instruções ou seja 250 * 0,5 = 125us. Cada vez que estoura entra na rotina e incrementa "conta". Para um valor de 10s conta devia ir até 10/125us=80.000.
Por isso é que acho que deverias usar um timer de 16 bits.
jagsilva
-
Boas,
cada vez percebo menos :(
em relação ao fuse XT tens razão ... ja alterei para HS
agora em relação ao estoiro do timer0 pensava que se usa-se um prescaler / por 32 que tinha uma Interrupção todos os 4 ms
// configura o timer 0 para clock interno e prescaler dividindo por 32
setup_timer_0 ( RTCC_INTERNAL|RTCC_DIV_32 );
e com o seguinte codigo
// reinicia o timer0 em 6 mais a contagem que já passou
set_timer0 ( 6 + get_timer0() );
iniciava o timer0 a cada estoiro a 6 logo ( 256-6 =250 )
e como tinha uma interrupção todos os 4 ms logo 0.004 ms * 250= 1s
logo a minha a variável tempo_pistao14 era decrementada a cada estoiro como cada estoiro era 1 segundo ... tinha realizado uma temporização ... mas pelos vistos estou ao lado da placa ... podes me indicar algo para ler sobre o funcionamento do timer0 ... pois o que li até agora pensava que funcionava da maneira que descrevi
cumprimentos
Zé Tretas
-
Mudar XT para HS não resolveu o problema?
Quanto à contas peço desculpa mas tens razao:
oscilador a 8.000.000 dá ciclos de maquina a 8.000.000/4=2.000.000Hz
com pre-escaler de 32, o timer0 é incrementado a cada (1/2.000.000) x 32 = 16uS.
com set_timer0 = 6 ele estoura a cada 256-6 = 250 * 16us = 4ms
O timer0 entra na interrupção a cada 4ms.
Com a variavel conta a ir até 250 fica 250 x 4ms= 1s.
Desculpa lá o meu erro.
Acho que deverias defenir conta como uma variavel global e = a zero.
agora não percebo é o que esta dentro de:
if ( conta == 250 ) //
{
conta = 0;
// tempo_pistao14 -= tempo_pistao14 ;
tempo_pistao14 = tempo_pistao14 - tempo_pistao14;
}
-
agora não percebo é o que esta dentro de:
if ( conta == 250 ) //
{
conta = 0;
// tempo_pistao14 -= tempo_pistao14 ;
tempo_pistao14 = tempo_pistao14 - tempo_pistao14;
}
O que eu queria fazer com esse codigo era que a cada estoiro do timer0 decrementar 1s a variavel tempo_pistao que é inicializada a 10000 __"unsigned int16 tempo_pistao14 =10000"__ mas que num estado normal deveria ser 10s mas como estava sempre a apagar eu meti a 10000s
mas não sei porque não esta a funcionar pois a saida RA1 so fica activa durante +/- 1s :(
ps: um muito obrigada desde já
cumprimentos
Zé Tretas
-
Deves começar por coisas mais simples.
tenta assim
#include <16f877A.h>
#fuses NOWDT,HS, PUT, NOPROTECT, BROWNOUT, LVP, NOCPD, NOWRT, NODEBUG
#use delay(clock=8000000)
#use rs232(baud=19200, parity=N, xmit=PIN_C6, rcv=PIN_C7, STOP=1, BITS=8)
#define led PIN_A1
int conta=0;
#INT_timer0
void trata_timer0 ()
{
set_timer0 ( 6 + get_timer0() );
conta++;
}
void main()
{
short blink=false;
setup_timer_0 ( RTCC_INTERNAL|RTCC_DIV_32 );
set_timer0 ( 6 ); // inicia o timer 0 em 6
enable_interrupts ( INT_timer0 );
enable_interrupts ( GLOBAL ) ;
while(TRUE)
{
if(conta>=250)
{
blink=!blink;
output_bit(led,blink);
}
}
}
-
Mais uma vez vou dizê-lo... e desculpem ser às vezes tão corrosivo...
Continuo a ver as pessoas a começar a casa pelo telhado!
Aprender uma arquitectura numa linguagem que não é a mãe, e num compilador que não se conhece... resulta no que estamos a ver.
Faltam as bases... todas as bases. As dúvidas e os erros que aqui vejo, resultam de não se saber as bases.
Arreliem-se comigo, vá.... :D eu insisto sempre em aprender primeiro ASM e depois o C....
hiihih
-
Arreliar? Porquê?
Nada como a voz da experiência para aconselhar os iniciantes! Tens toda a razão.
Este conselho aplica-se mesmo a quem já tenha experiência com outras linguagens, quer de baixo ou alto nível.
O ideal é sempre começar pelas bases ou pelo menos entender como tudo é feito "lá em baixo" ;)!
Tr3s
-
ASSEMBLER rulez ;)
hi
-
boas,
pessoal assember é muito lindo mas isso é para quem tem tempo e só se dedica a "brincar" com um µC, pois se para cada arquitectura se aprende todas as instruções, registos ... vai la vai ... e para o mais eu a muito tempo atraz tive uma m'a experiencia com o velhinho Z80 ... viva o C ao menos rola em tudo ou quase tudo ... apesar de a serie 16f não ser algo que foi c"desenvolvido" para ser programado em C ... mas para isso ja temos a série 18f ... Mas digo isto tudo ... mas la no fundo estou de acordo com vocês.
Cumprimentos
Zé Telhas
-
Desculpem o off-topicm as ja que falam disso! Eu acho que o maior problema até nem está na escolha da linguagem de programação, mas sim no programa usado compilador ccs ??? Acho que se perde mt a noção daquilo que se está a fazer, como realmente o hardware funciona...é a minha opinião, mas cada um sabe de si e usa aquilo que mais lhe agrada.
-
pessoal assember é muito lindo mas isso é para quem tem tempo e só se dedica a "brincar" com um µC,
Ora bem, sr. Tretas, antes de fazer tais comentários, deverá ver a quem os está a fazer, e se essa pessoa é brincalhona do hobby, ou profissional no ramo.
E se eu lhe disser que tenho clientes que me exigem o programa feito em ASM ? pois é....
Há quem reconheça que necessita do controle ao microsegundo.... coisa que o C não permite.
Quem desdenha de certo tipo de linguagem de programação, é porque normalmente não teve a coragem de gastar tempo a aprendê-la, porque achou que é completamente desinteressante.
Tenho a dizer-lhe que em certas áreas de sistemas-embebidos, a programação tem que ser feita em ASM, para se poder controlar ao ciclo de relógio o programa. Só assim se tem controlo total da situação.
ASM é excelente para comunicações e exigências de timings. (entre outras, tudo o que trabalha em background)
C é fantástico para o resto, especialmente para interfaces de utilizador.
Não pretendo colocar o ASM num basteão e dizer que é o melhor. Nada disso. Apenas digo que o prefiro, e é apenas uma opinião pessoal.
Mas também uso C quando o cliente pede, ou quando vejo que perco menos tempo.
o que defendo acérrimamente, é que devemos aprender o básico do ASM, para aprender uma arquitectura, pois aprendê-las com programação em C, vemos tudo aos blocos e não sabemos o que se passa lá em baixo, por isso é que há tanta dúvida e tanto problema que resulta da falta das bases.
-
Tenho a dizer-lhe que em certas áreas de sistemas-embebidos, a programação tem que ser feita em ASM, para se poder controlar ao ciclo de relógio o programa. Só assim se tem controlo total da situação.
Sena, muda para uma arquitectura mais rápida que o PIC (por exemplo AVR) que deixas de ter esse tipo de problema e passas a poder fazer tudo em C ;)
o que defendo acérrimamente, é que devemos aprender o básico do ASM, para aprender uma arquitectura, pois aprendê-las com programação em C, vemos tudo aos blocos e não sabemos o que se passa lá em baixo, por isso é que há tanta dúvida e tanto problema que resulta da falta das bases.
Concordo plenamente. Quem sabe assembly, mesmo que não a use, sabe ao detalhe como funciona um (nano/micro/mini)computador e facilmente domina qualquer outra linguagem, além de ficar apto a resolver qualquer tipo de problema relacionado com programação. Aprendam assembly, dá-vos uma visão completamente nitida e diferente do mundo.
-
Njay... tens razão! podia mudar de arquitectura.... mas não tenho tempo para me debruçar a outra!
tempo tempo tempo.... onde andas tu? :)
Mas a mudar, possivelmente mudava para a a Texas :D, principalmente por questões energéticas hehehe
-
Pois, a Texas sempre dominou no campo do baixo consumo... mas olha que a nova geração de AVR também já tem o cog-nome "pico(watt)"... Já programei (melhor dizendo, resolvi uns problemas) num MSP da Texas (um DSP) mas pelo menos na altura não fiquei muito impressionado, em particular por causa do ambiente de desenvolvimento da treta (problemas no download do código) e pago.
-
todos agora têem pico-nano-micro-treta-mili-watt...
É uma questão de escolher o mais bonito, porque em termos de arquitectura, agora todos fazem compativel com compiladores de C, o que acaba por tornar a vida do pessoal mais simples.
Deixo-me estar como estou, e faço os projectos rápidamente. Ja conheço as entranhas, resolvo os problemas rápidamente.
Tenho q conhecer mesmo, para dar formação e aparecerem os problemas mais bicudos, tenho q saber resolve-los ;D
-
Pois, mas o facto dos PIC oferecerem novamente samples dá uma vantagem à microchip ;)
-
Pois, mas o facto dos PIC oferecerem novamente samples dá uma vantagem à microchip ;)
off-topic: já é de graça outra vez?
-
(...) agora todos fazem compativel com compiladores de C, o que acaba por tornar a vida do pessoal mais simples.
Nem todos têm um bom compilador gratuíto...
(...) faço os projectos rápidamente. Ja conheço as entranhas, resolvo os problemas rápidamente.
Concordo que isso é muito importante para a vertente comercial. Sempre fui apologista de, entre uma coisa "da moda" ou até melhor e outra que já conhecemos muito bem, para um trabalho comercial o melhor é ficarmo-nos por aquilo que dá menos problemas.
Quanto ao serem de graça... muito sinceramente, acho a arquitectura do CPU tão má e arcaica que não os quero nem dados! Se fossem mais baratos que um AVR ainda podia ser um caso a pensar, mas nem isso. Voltar a fazer um programa para um PIC só mesmo se um dia tiver que o fazer profissionalmente, caso contrário fujo deles como o diabo foge da cruz :). Não sei se vocês sabem mas a Microchip já tentou comprar a ATMEL, não deve ter sido só para engrossar a fatia de mercado ;)
-
http://www.marketwatch.com/story/microchip-on-semi-make-joint-bid-for-atmel (http://www.marketwatch.com/story/microchip-on-semi-make-joint-bid-for-atmel)
Ai os malandros :)
-
Não sei se vocês sabem mas a Microchip já tentou comprar a ATMEL, não deve ter sido só para engrossar a fatia de mercado ;)
tótós não são :D