ASM51

estou fazendo o pic se comunicar com a tela smart grafics e ela so trabalha a 115200 , mas no pic nunca chega esse valor o mais proximo foi com cristal 27mhz e deu 112500 um erro de 2.5% , sera q interfere na comunicaçao ??

o pic esta mandando os comandos corretamente mas nao ta recebendo

outra coisa, como a tela funciona a 3,6v vou alimentar o pic com 3,3v sera q vai melhorar ?




pic 18f252
mikroc pro
cristal 27mhz

Cris.
O 18F252, tem PLL com fundo de frequencia de 40mhz.
VocÊ vai colocar um cristal externo de 10mhz , e nos fuses vai simplesmente abilitar o PLL.
Fim que ele vai ter um clock de 10mhz * 4PLL = 40mhz.

Observe que para um cristal de 27mhz, até o consumo do pic é em tese maior que usar um de 10mhz e abilitar o PLL!!

Abraços

amanha vou comprar 1 ...

baixei a tensao do pic para 3,6v e ja reconheço o tochscreen , mas tem hora q ele trava...

Cristian... os experts dizem que um erro de até 5% no baud/rate é viável... sendo assim teus 2.5% estáo dentro do limite.

ta funionando aqui ...tem hora q dá uns paus , vou ver da onde vem isso

hehe 5% pra um byte..
E lá pra frente, ? como fica ?

Imagina assim, receber 35 bytes.. ou enviar 35bytes... Os primeiros vão certinho, ai depois ? O corte de teste de 1 ou zero, ja não vai mais cair no centro do bit.. e sim, no proximo ou sucessivo... O erro é cumulativo !!!

meu medo é este

tem hora q da erro ...mas parece impossivel conseguir 115200 ...

use cristal multiplo de 1.843,200 kHz tipo 7.372,8 kHz, ative o PLL e veja a configuração da serial para este valor.

[ ]'s
Sergio

fabim escreveu:hehe 5% pra um byte..
E lá pra frente, ? como fica ?

Imagina assim, receber 35 bytes.. ou enviar 35bytes... Os primeiros vão certinho, ai depois ? O corte de teste de 1 ou zero, ja não vai mais cair no centro do bit.. e sim, no proximo ou sucessivo... O erro é cumulativo !!!

Entendo Fabim... só que ninguém falou na utilizaçäo de buffer para que a comunicaçäo fösse mais contínua com o envio de diversos bytes. Neste caso, acho que o erro seria zerado a cada pacote transmitido... e näo cunulativo...

fabim escreveu:hehe 5% pra um byte..
E lá pra frente, ? como fica ?

Imagina assim, receber 35 bytes.. ou enviar 35bytes... Os primeiros vão certinho, ai depois ? O corte de teste de 1 ou zero, ja não vai mais cair no centro do bit.. e sim, no proximo ou sucessivo... O erro é cumulativo !!!

na verdade a UART resincroniza a cada start bit recebido, portanto o erro maximo acumulado corresponde ao start bit, ao byte transmitido, a paridade se houver e ao(s) stop bit(s). para uma 8N1 tipica, vc tem 10 bits e portanto o erro acumulado sera 10x a variacao do baudrate. no caso de 5%, vc totaliza 50% de desvio no stop bit. como as melhores UARTs usam um clock 16x maior que o baudrate para sincronizar a janela de amostragem, o deslizamento maximo da janela de amostrarem relativa ao inicio do start bit ateh chegar no stop bit nao pode exceder o 15/16, o que corresponde a uns 90% de desvio acumulado, ou seja, 9% de desvio no baudrate.

diferente das UARTs, as SCCs capazes de trabalhar de forma sincrona requerem um clock sincronizado, de modo que qq deslizamento no transmissor eh repassado diretamente ao receptor e nunca acumule erros. no caso da ethernet, por ex, um DPLL no receptor eh sincronizado por um preambulo no inicio do frame e entao o resto do frame segue aquele sincronismo.

Cristian,ja experimentou usar um cristal de 18.432 MHz ou implementar por SoftWare?
Na Farnell tem o cristal.