LusoRobótica - Robótica em Português
Sistemas específicos => PIC => Tópico iniciado por: jbecg em 16 de Setembro de 2011, 23:44
-
Ando a tentar fazer uma pequena brincadeira com um microcontrolador PIC18F4550. Nesta fase pretendo transmitir dados para um computador através da porta serie, acontece que estou com um problema, já consigo comunicar mas o que recebo não corresponde exactamente àquilo que envio. Já confirmei várias vezes a taxa de transmissão, mas continuo sem obter sucesso. Deixo aqui a minha versão do código e espero sugestões.
Cumprimentos,
JBECG
#include <pic18.h>
#include <stdio.h>
void main (void)
{
//ports
TRISC6 = 1;
TRISC7 = 1;
//EUSART
SPBRGH = 0x00;
SPBRG = 0x81; // fOSC= 20 MHz
BRGH = 1;
BRG16 = 0;
SYNC = 0;
SPEN = 1;
//TX
TXCKP = 0;
TXIE = 0;
TX9 = 0;
TXEN = 1;
//Interrupts
PEIE = 1;
GIE = 1;
while(1)
{
asm("CLRWDT");
while(TRMT == 0);
TXREG = 'A';
while(TRMT == 0);
TXREG = 'Z';
}
}
-
Isso compila assim sem erros?
Normalmente os bitfields de cada registo não são acedidos assim dessa maneira, mas PIC não é bem a minha área e nem disseste que compilador usas.
-
eh la.. pergunto o mesmo, isso compila? por exemplo, nos registos, tens de meter INTCONbits.GIE em vez de GIE.. mas tambem nao sei que compilador usas.
depois, como tas a receber os dados no pc? no hiperterminal?
-
Sim realmente não disse e sim o código compila. Estou a utilizar o hi-tech. A configuração desses bits eu fiz directamente no MPLAB IDE através dos configurations bits.
Os caracteres que recebo não correspondem àqueles que envio, isto é, envio A e Z continuamente e recebo algo que não é uma sequência de A's e Z's.
Não estou a utilizar o hiperterminal estou a utilizar um pequeno programa que já usei noutras situações o RCOMSerial (está o link para os interessados em utilizar http://www.rogercom.com/ (http://www.rogercom.com/))
-
Sim realmente não disse e sim o código compila. Estou a utilizar o hi-tech. A configuração desses bits eu fiz directamente no MPLAB IDE através dos configurations bits.
Os caracteres que recebo não correspondem àqueles que envio, isto é, envio A e Z continuamente e recebo algo que não é uma sequência de A's e Z's.
Não estou a utilizar o hiperterminal estou a utilizar um pequeno programa que já usei noutras situações o RCOMSerial (está o link para os interessados em utilizar http://www.rogercom.com/ (http://www.rogercom.com/))
Boas
Se tens tudo correcto e nao estás a descobrir o problema podes sempre fazer isto.
Percorres todos os valores do registo da baudrate de certeza que vais ver os caracteres no terminal.
Tive uma vez esse problema, dava-me uma baudrate do genero 101kbps que nao é generica, tinha la uns erros nas contas, depois corrigi, logo se isso nao recebe certo tens erros nas contas.
unsigned char contador=0;
while(1)
{
asm("CLRWDT");
while(TRMT == 0);
TXREG = 'A';
while(TRMT == 0);
TXREG = 'Z';
SPBRG = contador++;
while(TRMT == 0);
TXREG = contador;
}
-
Assim de repente, vejo q falta o seguinte ::
# os FUSES devem ser postos no código e não nos menús do MPLAB
# os pinos não usados devem ser configurados como OUTPUT
# tens as interrupções ligadas, apesar de não estares a usar nenhuma, e não tens a função de interrupção presente. O compilador provavelmente faz-te logo o RETFIE assim que vê uma interrupção.
O facto do compilador não dar erros, é por si estranho.
Experimenta o programa terminal :: BRAY TERMINAL ou o HERCULES TERMINAL.
Tens acesso a osciloscópio? rapidamente vês, realmente, o q está a sair.
-
Agradeço a sugestão dada pelo FET_Destroyer, porque na verdade foi a única maneira de conseguir encontrar o valor correcto de SPBRG que possibilita o envio correcto dos caracteres pretendidos. A minha questão agora é a seguinte de acordo com a formula e as tabela de configuração do baud rate, com SYNC =0, BRG16=0, BRGH=1, o valor de SPBRG seria 129, no entanto e utilizando a dica do FET_Destroyer o valor que me permite transmitir o pretendido em condições é 44, conseguem explicar-me o porque disto?
Agradeço também à analise feita ao meu código pelo asena, sou um mero curioso destas andanças e com pouca experiência, por isso não sei o que são #FUSES, sempre fiz as configurações dos configurations bits directamente no MPLAB e nunca tive problemas. A questão das interrupções são para tratar da recepção de dados (ainda não a tenho implementada, mas é o passo seguinte).
Com a dica do FET_Destroyer foi possível obter uma comunicação através do RCOMSerial.
Relativamente, à situação dos pinos não usados terem a necessidade de ser configurados como OUTPUT já tinha essa ideia embora não o tenha feito.
Obrigado a ambos.
jbecg
-
o cristal q estás a usar é de qt, 20megas ?
-
Sim, 20 MHz.
-
Com esse valor de SPBRG, parece que tem o oscilador a trabalhar a 8 megas.
Será que com SPBRG a 129, a velocidade não é de ~27.7kbps ou de ~3.8kbps? estou a achar isso muito estranho. Mas como faltam tantas configurações no código, é impossivel o q o compilador está a fazer por trás.
Maravilhoso assembler !
-
Tenho um oscilador de 20 MHz e estou a comunicar à taxa de 9600 bits/s com o valor de SPBRG = 44. Relativamente às configurações será que o printscreen dos configuration bits ajudam? (seguem em anexo)
Não estou a conseguir adicionar anexos! O anexo respeita todas as restrições (.rar e 240KB)
Já arranjei solução, os ficheiro encontram-se disponíveis para download neste link: http://www.megaupload.com/?d=3XIC5ZQ3 (http://www.megaupload.com/?d=3XIC5ZQ3)
-
Pelas configurações, tens 48Mhz como Primary Clock.
Mas, o quadradinho que diz "Configuration bits set in code" está activado e não devia, pois não tens configurações feitas no programa.
-
Mas mesmo para 48MHz como Primary Clock o valor de SPBRG, para a taxa de transmissão de 9600 bits/s, não seria de 44. Já agora como é que eu posso mudar a frequência de primary clock para 20 MHz, já que é aquela que corresponde à frequência do meu oscilador.
-
DATASHEET, capítulo do Oscilador, está lá tudo explicado!
-
Sei que sim e esta configuração foi feita com base nisso. Para primary clock = 20MHz foi necessário atribuir a CPUDIV (oscillator prostscaler) = 00 e FOSC3:FOSC0 = 0 (Leitura feita através do diagrama de blocos)
-
Alguma sugestão de como resolver este problema?
-
caro jbecg,
Por favor confirme se de facto as "configuration bits" do MPLAB está definido com o pisco ou não.
Estar definido como a configuração é feita no código e nem uma linha existe sobre o mesmo, significa que cada vez que faz a programação do PIC não vai alterar os 'fuses' , vai sim utilizar os mesmos valores anteriores (da ultima vez que foram gravados).
Portanto a sugestão é retirar o pisco dos "configuration bits set on code", de certeza que o que funciona para SPBRG=44 vai deixar de funcionar.
-
Essa dica já me tinha sido dada e inclusivé já fiz essa alteração, contudo não se verificou qualquer alteração de funcionamento, isto é, continua a funcionar.
-
desse modo, pela as configurações que tem no MPLAB o FOSC é de 48MHz para um cristal de 20MHz.
com SYNC =0, BRG16=0, BRGH=1 o SPBRG teria que ter um valor de 311, mas sendo um registo de 8bits não pode.
Sendo assim sugiro mudar BRGH para 0 e usar SPBRG=77.
-
Para já muito obrigado pelos conselhos. A minha questão agora passar por como redefinir FOSC para 20 MHz através de um cristal de 20MHz.
-
DATASHEET, capítulo do Oscilador, está lá tudo explicado! RTFM...
vocês vêem práqui fazer perguntas que estão respondidas no papel à vossa frente.... aprendam a pesquisar por vocês próprios, pois nesta área é fundamental.
-
para ter um FOSC=20Mhz basta desactivar o PLL.
Se fazes as configurações no MPLAB, só é preciso mudar a 4ª linha de HS+PLL para HS ( o mesmo que HS-USB).
Saber a que velocidade o micro está a trabalhar é fundamental, caso contrario podemos estar a contar que ele está a fazer uma coisa e afinal é outra. Ter uma rotina com um led a piscar de 5 em 5 segundos é uma maneira de testar e saber se a velocidade está correcta.
-
Ok, obrigado pela dica, mas continua-se a passar algum problema, se estou a trabalhar com FOSC = 20MHz deveria ter SPBRG = 129 para ter uma comunicação a 9600bits/s através da EUSART, o que não acontece. Com SPBRG = 129 não acontece, isto é, os caracteres enviados não correspondem aos recebidos.
Outra questão que me leva pensar que realmente tenho um problema é precisamente na temporização do acender e apagar de LEDs. Defini para um segundo aceso e um segundo apagado cada um dos LEDs e não é isso que acontece, como não tenho acesso a nenhum osciloscópio não consigo verificar a minha suspeita, mas creio que permanecem 2s acesos e 2s apagados.
O código está em baixo.
unsigned int counter;
void interrupt handler (void)
{
//TIMER 0
if(T0IF == 1)
{
T0IF = 0;// clear timer 0 interrupt flag
++counter;
}
}
void main (void)
{
TRISE = 0x00;//porto E como saida
PORTE = 0x00;// iniciam-se a 0
//TIMER 0//
T0CS = 0;
PSA = 1;
T0IE = 1;
T0IF = 0;
RE0 = 1;
RE1 = 0;
while(1)
{
asm("CLRWDT");
if(counter >= 19531)
// 1s em contagens : 1s/(256*(1/20E6)) = 19531 contagens
{
RE0 = 0;
RE1 = 1;
}
if(counter >= 39062)
//2s = 2*19531 contagens = 39062 contagens
{
counter = 0;
RE0 = 1;
RE1 = 0;
}
}
}
-
Boas
Tenta este código ou compara com o teu.
Oscilador de 20Mhz e o SPRG = 129;
Cumps
//#include <htc.h>
#include <p18cxxx.h>
#include <string.h>
#include <stdio.h>
#include <usart.h>
#include "pff.h"
#define _XTAL_FREQ 48000000
#define LED7 LATBbits.LATB7
#define LED6 LATBbits.LATB6
#define LED5 LATBbits.LATB5
#pragma config OSC = HS_HSPLL
#pragma config PLLDIV = 5 // (20 MHz crystal on PICDEM FS USB board)
#pragma config CPUDIV = OSC1_PLL2 // Clock source from 96MHz PLL/2
void main(void)
{
BYTE res, i;
TRISB = 0x00;
// configuração USART
OpenUSART( USART_TX_INT_OFF & USART_RX_INT_OFF & USART_ASYNCH_MODE & USART_EIGHT_BIT & USART_CONT_RX & USART_BRGH_HIGH, 129 );
// Baudrate = Fosc / (16 * (spbrg + 1))
//spbrg = 64 para 10mhz para 9600
//spbrg = 255 para 10mhz com PLL para 9600
//spbrg = 21 para 10mhz com PLL para 19200
//spbrg = 25 para 4mhz int osc para 9600
printf("inserir cartao\n\r");
LED7 = 1;
printf("inicializado\n\r");
while(1);
}
-
se colocares os leds a piscar durante mais tempo melhor. por exemplo se for de 5 em 5 segundos e ao olhar contarmos 6 segundos o erro é menor do que estar a contar um led a piscar 1 em 1 segundo.
o modo de programação também não é o mais correcto.
Por exemplo, na configuração do TIMER0, porquê colocar o PSA=1 se nem sequer colocaste o TMR0ON=1?! Activas primeiro a interrupção do timer e depois é que limpas a flag?!
confirmei que por defeito T0CON=0xFF mesmo num reset, mas não deixa de ser um bocado estranho porque se fosse o TMR1 já não funcioava.
Partilha o teu projecto para fazer download e dar uma vista de olhos(dropbox,etc)
No MPLAB na tab project, faz um 'Package in .zip' e põe na net.
-
Ok, já fiz o upload no megaupload. Obrigado pela ajuda.
link: http://www.megaupload.com/?d=0X0RUP70 (http://www.megaupload.com/?d=0X0RUP70) (este link já n corresponde ao meu projecto)
-
vi o teu projecto em MPLAB, tens tudo na mesma!!!
1) configuration bits tens a dizer que são definidos no codigo (pisco activo), mas no codigo nao tens nada?!
2) mesmo considerando os configuration bits do MPLAB, tens definido o oscilador do tipo clock externo?! o que aconteceu ao cristal de 20MHz? clock externo é diferente de cristal.
3) o meu compilador Hi-tech nao reconhece o T0IE e afins.... só reconhece TMR0IE. Como é que compila sem dar erro?!
-
Não sei o que se passou, mas esse projecto não corresponde ao meu. O meu projecto (agora correcto) esta no link abaixo. De qualquer modo nunca tive problemas por itilizar T0IE e afins.
http://www.megaupload.com/?d=R4ABRJH7 (http://www.megaupload.com/?d=R4ABRJH7)
-
boas,
primeiro de tudo, dei uma vista de olhos no ficheiro HEX que tinhas no projecto e não tem configurações dos fuses, logo cada vez que programas o pic não alteras os fuses e fica sempre o que está gravado anteriormente. O melhor é começares a definir os fuses no código, assim o compilador introduz automaticamente.
segundo, para gravar o pic que software usas? MPLAB directamente? software do PICKIT2? nao é que seja relevante mas pode estares a fazer export do HEX no MPLAB para gravar com o PICKIT Programmer e não tens a opção de fazer export com configuration bits.
terceiro como é que ligas o pic ao PC? ligando directamente á porta RS232 propria ou algum dongle rs232-usb? se for este o caso para além de definires a velocidade da porta no hyperterminal, tambem tens q definir nos dispositivos do windows.
por ultimos se nao usas nenhum chip rs232 entre o pic e a porta do PC tens q inverter o sinal dos pinos
TXCKP=1; //sem max232
RXDTP=1; //sem max232
alterei o teu codigo minimamente, compilei e deu com cristal 20mhz.
usei um dongle rs232-usb e o pic ligado directamente á porta.
http://dl.dropbox.com/u/19843563/18f4550alterado.zip (http://dl.dropbox.com/u/19843563/18f4550alterado.zip)
-
Ok, obrigado. Bem tive a tentar ver como se poderia fazer para activar a definição dos fuses no ficheiro .hex para programar o pic e não vi nada ao nível do software do PICKIT2 para o fazer. E sim para programar o utilizo o software do PICKIT2 faço Auto Import Hex+Write File e programo o pic. Relativamente à ligação com o computador faço a directamente através da com de um pc desktop que tenho e de um max 233.
Programei e testei o funcionamento. Ao nível do tempo do piscar do LED isto é para dez segundo? (tentei medir assim a olho com um cronometro e contei perto de 12 s). Ao nível da porta serie com as definições feitas os caracteres enviados não correspondem aos recebidos.
Será um problema do meu PC? Será que tenho algum problema nesta porta? Ou será ao nível do meu hardware? Sera que tenho algo queimado?
Cumprimentos
-
Estás a configurar bem o terminal?
Tens o cristal certo com os condensadores adequados no mesmo?
-
Sim acho que sim. Aquele terminal que uso nunca me deu problemas. Tenho condensadores de 22 pF no terminais os cristal.
-
o led está para 4 segundos (4s ligado. 4s desligado)
se usas o PICKIT Programmer então tens sempre que fazer no MPLAB ->File->Export (confirmar pisco configuration bits).
Tenta programar com o próprio MPLAB. é mais facil se não queres configurar os fuses no código.
Sempre que fases import no PICKIT ele avisa se tem os fuses ou não, diz:
Warning: No configuration words on HEX file.
experimenta este (igual ao anterior mas neste caso para usares no PICKIT2 Programmer, já com fuses). Clicka em baixo com botao direito e faz save as, senão ele abre o HEX no browser.
http://dl.dropbox.com/u/19843563/18f4550_pickit2.hex (http://dl.dropbox.com/u/19843563/18f4550_pickit2.hex)
-
Antes de mais aproveito para agradecer todo o apoio dado por parte do ntrindade e por parte dos restantes que por ai têm dado o seu contributo. Isto de dar dicas a principiantes eu compreendo que nem sempre é fácil.
Relativamente ao meu projecto já consegui através das dicas que foram sendo dadas programar as definições dos configurations bits e relativamente ao piscar do LED (através de umas medições a olho com um cronometro contabilizei perto de 4s, o que corresponde ao programado). Contudo relativamente à transmissão e recepção de dados pela EUSART as coisa ainda não estão famosas e agora (mais uma vez) estou mesmo sem saber qual é o problema, consigo estabelecer comunicação, mas os dados enviado não correspondem aos dados recebidos.
Mais uma vez, obrigado.
-
como te disse antes o HEX que enviei, utilizei o pic sem nenhum MAX232 (porque uso um dongle rs232-usb). No teu caso tens que alterar codigo e retirar as linhas:
TXCKP=1; //sem max232
RXDTP=1; //sem max232
se pisca 4s, então o oscilador está correctamente configurado, não há motivos para o SPBRG ter valores errados. Retira as linhas que eu disse, compila no MPLAB, faz file export, confirma no PICKIT2 Programmer , os fuses estão a ser gravados e de certeza que funciona.
-
Ok, mais uma vez muito obrigado por tudo. Fiz isso e funcionou na perfeição.
Cumprimentos
-
Boa tarde! Onde vc encontrou o bootloader pra este pic, 18f4550? Vc tem ele?
-
Não sei bem o que isso, mas creio que não usei. Como já disse várias vezes sou um mero curioso e estou agora a iniciar me nestas andanças. Creio também que muitos dos pic da famila 18F já trazem o bootloader previamente instalado.
-
Não sei bem o que isso, mas creio que não usei. Como já disse várias vezes sou um mero curioso e estou agora a iniciar me nestas andanças. Creio também que muitos dos pic da famila 18F já trazem o bootloader previamente instalado.
Nenhum PIC traz Bootloader instalado.
Um bom Bootloader é o TINY. Uma procura no GOOGLE devolve muita informação.
O site www.microchipc.com (http://www.microchipc.com) também.