Display 7 segmentos

[senso]

Como é que estragas o PIC a testar código?

[Dave]

Ele está a fazer o somatório dos números... mas demora muito mais que 250ms...... ronda o minuto de espera.

O display não apresenta o último segmento, ou seja o D, ligado a RB3.

Está complicado fazer algo simples  .


cumps

[senso]

Não tens que definir a frequência do oscilador nas propriedados do PIC no proteus?
Qual é a outra função do RB3 para além de pino digital?

[Dave]

Não tens que definir a frequência do oscilador nas propriedados do PIC no proteus?

Amigo, eu só usei o proteus à pouco para tirar as "teimas" e ver se era mesmo do código ou do PIC....

Agora, como dantes, estou a programar no PIC e a testar na placa.

Qual é a outra função do RB3 para além de pino digital?

RB3 - PGM - CCP1 é o indicado no datasheet.


Obrigado pelas respostas

[senso]

PGM, tem alguma coisa a ver com pino involvido no processo de programar o PIC?
O proteus pode pensar que o pino está noutro modo que não um pino digital.

[Dave]

PGM, tem alguma coisa a ver com pino involvido no processo de programar o PIC?
O proteus pode pensar que o pino está noutro modo que não um pino digital.

Amigo... eu não estou a utilizar o proteus!
Eu estou a usar o CCS para compilar e estou a testar nas placa e não no proteus.

cumps

[senso]

Mas não estavas a simular no proteus?

[Dave]

Mas não estavas a simular no proteus?

Eu apenas simulei uma única vez (como já disse num post anterior) para:
* Colocar aqui no fórum o circuito e a ligação;
* "para tirar as "teimas" e ver se era mesmo do código ou do PIC....";

Assim, vou reformular e fazer o ponta da situação.

Neste momento o PIC16F88 foi programado com o seguinte código:

#include <16f88.h>
#use delay (clock=4000000)
#fuses NOWDT, BROWNOUT, PUT, NOMCLR, INTRC_IO

byte const tabela[]={0b10111111,
                     0b10000110,
                     0b11011011,
                     0b11001111,
                     0b11100110,
                     0b11101101,
                     0b11111101,
                     0b10000111,
                     0b11111111,
                     0b11100111};

void main()
{
int8 valor;
set_tris_a(0b11111100);
valor=0;

while (true)
{
   valor++;
   if (valor>=10) valor=0; 
   output_b(tabela[valor]);
   delay_ms(250);
}
}

Problemas:
1) O delay "real" não é de 250ms. Demora cerca de 1 min até aparecer outro número no display.
2) Todos os números que necessitem do segmento "d" do display, estão a sair sem que o mesmo seja activo.

Notas:
1) Dos pinos A configurei tudo como saída, excepto os dois pinos onde está colocado o cristal... não sei se é esta a forma correcta de fazer...

2) Já testei usando apenas números ao invés da função if e do incremento de "valor" e  todos os segmentos ligaram correctamente. Com os código em cima, não está a resultar.



Uma vez mais obrigado pelo vosso tempo!

[senso]

Como é que ligas 7 segmentos a 6 pinos?
Depois, tens a certeza que o teu PIC está mesmo a funcionar a 4Mhz?
Se dizes que fazes um delay de 250ms e demora 1 minuto parece que o teu pic está na verdade a trabalhar a 1Mhz.
Já experimentas-te usar outro porto sem ser o porto A?

[Dave]

Como é que ligas 7 segmentos a 6 pinos?

Não entendi amigo...
Eu tenho 7 segmentos, ligados a 7 pinos.
Liguei aos pinos RB0 a RB6.

Depois, tens a certeza que o teu PIC está mesmo a funcionar a 4Mhz?
Se dizes que fazes um delay de 250ms e demora 1 minuto parece que o teu pic está na verdade a trabalhar a 1Mhz.
Já experimentas-te usar outro porto sem ser o porto A?

O cristal é de 4MHz... no código apresento " #use delay (clock=4000000) ", por isso penso que sim... de certo ele demora muito tempo talvez antes de chegar ao delay....


Cumps

[senso]

Mas não estavas a simular no proteus?

Eu apenas simulei uma única vez (como já disse num post anterior) para:
* Colocar aqui no fórum o circuito e a ligação;
* "para tirar as "teimas" e ver se era mesmo do código ou do PIC....";

Assim, vou reformular e fazer o ponta da situação.

Neste momento o PIC16F88 foi programado com o seguinte código:

#include <16f88.h>
#use delay (clock=4000000)
#fuses NOWDT, BROWNOUT, PUT, NOMCLR, INTRC_IO

byte const tabela[]={0b10111111,
                     0b10000110,
                     0b11011011,
                     0b11001111,
                     0b11100110,
                     0b11101101,
                     0b11111101,
                     0b10000111,
                     0b11111111,
                     0b11100111};

void main()
{
int8 valor;
set_tris_a(0b11111100);    //Configuras o teu porto A
valor=0;

while (true)
{
   valor++;
   if (valor>=10) valor=0; 
   output_b(tabela[valor]);   //usas o porto B como saida?
   delay_ms(250);
}
}

Problemas:
1) O delay "real" não é de 250ms. Demora cerca de 1 min até aparecer outro número no display.
2) Todos os números que necessitem do segmento "d" do display, estão a sair sem que o mesmo seja activo.

Notas:
1) Dos pinos A configurei tudo como saída, excepto os dois pinos onde está colocado o cristal... não sei se é esta a forma correcta de fazer...

2) Já testei usando apenas números ao invés da função if e do incremento de "valor" e  todos os segmentos ligaram correctamente. Com os código em cima, não está a resultar.



Uma vez mais obrigado pelo vosso tempo!

Tens que decidir se queres usar o porto A ou o porto B, muda lá o set_trisa para b, mete tudo como deve ser, deixa lá o porto A descansado e configura bem o B.
Depois mete um led a piscar, por exemplo 1 segundo ligado e 1 segundo desligado para teres a certeza que tens o cristal a funcionar á frequência esperada, não sei se esse pic tem oscilador interno, mas se tiver podes estar a correr do oscilador interno e não do cristal como pensas.

[Dave]

Já coloquei o led a piscar de 1s em 1s e está operacional.

De momento estou a testar o PIC com o código abaixo e continuo a verificar o mesmo problema...

#include <16f88.h>
#use delay (clock=4000000)
#fuses NOWDT, BROWNOUT, PUT, NOMCLR, INTRC_IO



byte const tabela[]={0b10111111,
                     0b10000110,
                     0b11011011,
                     0b11001111,
                     0b11100110,
                     0b11101101,
                     0b11111101,
                     0b10000111,
                     0b11111111,
                     0b11100111};

void main()
{

int8 valor;

   setup_adc_ports(NO_ANALOGS|VSS_VDD);
   setup_adc(ADC_OFF);
   setup_spi(FALSE);
   setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
   setup_timer_1(T1_DISABLED);
   setup_timer_2(T2_DISABLED,0,1);
   setup_comparator(NC_NC_NC_NC);
   setup_vref(FALSE);

set_tris_b(0b11111111);

valor=0;

while (true)
{
   valor++;

   if (valor>=10) valor=0;

   output_b(tabela[valor]);

   delay_ms(250);
}
}

[senso]

Talvez sejam manias do compilador e porque nem sequer tens acesso directo ao porto, tenta assim:

Código: [Seleccione]

#include <16f88.h>
#use delay (clock=4000000)
#fuses NOWDT, BROWNOUT, PUT, NOMCLR, INTRC_IO



byte const tabela[]={0b10111111,
                     0b10000110,
                     0b11011011,
                     0b11001111,
                     0b11100110,
                     0b11101101,
                     0b11111101,
                     0b10000111,
                     0b11111111,
                     0b11100111};

void main()
{

int8 valor = 0;
int8 tab = 0;

   setup_adc_ports(NO_ANALOGS|VSS_VDD);
   setup_adc(ADC_OFF);
   setup_spi(FALSE);
   setup_timer_0(RTCC_INTERNAL|RTCC_DIV_1);
   setup_timer_1(T1_DISABLED);
   setup_timer_2(T2_DISABLED,0,1);
   setup_comparator(NC_NC_NC_NC);
   setup_vref(FALSE);

set_tris_b(0b11111111);


while (true)
{

   if (valor>9){
      valor=0; }
   tab = tabela[valor];
   output_b(tab);
   valor++;
   delay_ms(250);
}
}
Atenção que um array de tamanho 10 só podes ler de 0 a 9 e não de 1 a 10, lês sempre a começar do 0 e acaba sempre uma posição a menos que o tamanho com que o declaras, porque a declarar contas de 1 até onde queres e a ler, lês a partir de 0 e não do 1.

[Dave]

Amigo, infelizmente o problema mantém-se.....

Encontrei um código na net que faz exactamente o mesmo. Vou testa-lo e já dou por cá feedback.

Se continuar na mesma já não pode ser erro meu....


cumps

[Dave]

Nada... tudo na mesma....