Problema com comunicação serial no PIC18F2550 - UART Receiver Frame error

Fabiano.araujo · 24 de outubro de 2015

Olá pessoal, estou com uma problema para implementar a comunicação entre o PIC18F2550 e uma porta Serial RS-232. Fiz o esquema no Proteus simulei e funcionou perfeitamente, mas quando faço a montagem física recebo o erro "UART receiver framing error". Segue o código e o esquema. Se alguém puder ajudar agradeço desde já.

#include <18F2550.h>
#use delay (clock=20000000)
#use RS232(baud=9600, parity=N, bits=8, xmit=PIN_C6,rcv=PIN_C7)

void main()
{
char x;
short vlr_a0_ant = 1;
while(true)
    {
    printf("\n\r\n\rFabiano Araujo dos Santos\n\r");
    while(true)
      {
      if (kbhit())
         {
         x = getchar();
         switch(x)
           {
           case '1' : output_high(PIN_B6); printf("\n\rB6 ativado.\n\r"); break;
           case '2' : output_low (PIN_B6); printf("\n\rB6 Desativado.\n\r"); break;
           case '3' : output_high(PIN_B7); printf("\n\rB7 ativado.\n\r"); break;
           case '4' : output_low (PIN_B7); printf("\n\rB7 Desativado.\n\r"); break;
           }
         }
      if (input(PIN_A0) != vlr_a0_ant)
         {
         if (input(PIN_A0)) printf("\n\rA0 ativado.\n\r");
         else               printf("\n\rA0 desativado.\n\r");
         vlr_a0_ant = input(PIN_A0);
         }
      }
    }
}

test man*~ · 26 de outubro de 2015

Se não me engano os pinos 14 e 13 (do MAX232) foram ligados de forma incorreta.

Pino 14 do MAX232 (PIC TX) -> Pino 2 do conetor (Computador RX)Pino 13 do MAX232 (PIC RX) -> Pino 3 do conector (Computador TX)

Dê uma olhada no datasheet para confirmar...

Fabiano.araujo · 27 de outubro de 2015

Obrigado test man, já verifiquei essas informações que você passou, eu já tinha observado e corrigido, no Proteus, não sei o motivo os pinos são invertidos, mas fisicamente a ligação está correnta. Estou usando um adptador usb Serial, será esse o problema?

test man*~ · 27 de outubro de 2015

Entendo... Você pode postar uma foto/imagem desse adaptador USB<>Serial? Se ele for USB<>Serial TTL não há a necessidade de usar o MAX232.

Fabiano.araujo · 27 de outubro de 2015

Olá amigo, segue as fotos. Sobre o circuito sem o max232, fiz um teste sem utiliza-lo, mas o problema continuou. O firmware baixei na net, inclusive testei vários, mas todos apresentaram o mesmo problema. Estou utilizando o notebook com o cabo usb rs232, mas já testei também no meu PC, que possui entrada DB9, também não funcionou. Estou ficando sem ideias.

.if · 28 de outubro de 2015

isso é tão óbvio que quase não publico... veja se os baudrates estão coerentes

Isso, nem tanto... dê um curto nos pinos 2 e 3 do db9 com um minishunt e abra o hyperteminal (ou algum de sua preferência) e veja se o que tecla ecoa

Fabiano.araujo · 28 de outubro de 2015

Obrigado Isadora, já fiz esse teste, e funcionou perfeitamente. Inclusive com e sem o MAX232, funcionou em ambos os casos, agora estou focado no MCU.

.if · 29 de outubro de 2015

ok então foquemos no mc e max. Envie 0x55 num loop pelo mc e veja se tem uma onda quadrada +8...-8 no pino 14 do max. Do lado do pc, digite U e veja se tem uma onda quadrada +5...0 no pino 18 do pic. Não tem oscilo? Sem problema. Use led (verde jamais) nos pinos que indiquei mas programe um baudrate bem baixo <10Hz

Fabiano.araujo · 30 de outubro de 2015

Boa noite pessoal, então fiz um teste com outro microcontrolador o PIC16F887 e o software LDmicro, e consegui enviar os caracteres perfeitamente. Aproveitei para comparar as tensões em RX - TX do PIC ( 4,9v ) e RX - TX do PC ( -7,9v ). Nos dois MCUs esses parâmetros estavam iguais, no entanto, no PIC18F2550 os caracteres continuam "loucos", sendo que estou usando o mesmo circuito, acredito que o problema é no firmware, como sou novo no mundo dos MCUs acho que estou cometendo algum erro. Amanhã irei testar meu código no 16F887 já que o teste foi realizado com o firmware gerado pelo LDmicro.

test man*~ · 30 de outubro de 2015

Os FUSES do oscilador estão corretos? PLL/CPUDIV...

Fabiano.araujo · 30 de outubro de 2015

Olá pessoal, hoje venho só agradeçer a participação de vocês. o problema foi resolvido graças às informações que passaram. Especialmente essa última do teste man, sobre os fuses, se perceberem no primeiro código que postei não havia configurado os fuses, após a configuração dos mesmos consegui resolver 98% do problema. Precisei adicionar também um delay de 1 ms pois os primeiros caracteres ainda estavam estranhos, com esse delay estabilizou. Segue o código caso outras pessoas tenham o mesmo problema.

#include <18F2550.h>
#fuses HSPLL,NOWDT,NOPROTECT,NOLVP,NODEBUG,PLL4,VREGEN,MCLR,PUT
#use delay (clock=20000000)
#use RS232(baud=19200, parity=N, bits=8, xmit=PIN_C6,rcv=PIN_C7)

void main()
{
char x;
short valor_anterior_A0 = 1;

    while(true)
    {

      delay_ms(1);

      printf("\n\rPIC RS-232\n\r");

      while(true)
      {

         if (kbhit())
         {
         x = getchar();
         switch(x)
           {
           case '1' : output_high(PIN_B6); break; printf("\n\rLed 1 aceso.");
           case '2' : output_low (PIN_B6); break; printf("\n\rLed 1 Apagado.");
           case '3' : output_high(PIN_B7); break; printf("\n\rLed 2 aceso.");
           case '4' : output_low (PIN_B7); break; printf("\n\rLed 2 Apagado.");
           }
         }
       if (input(PIN_A0) != valor_anterior_A0)
         {
         if (input(PIN_A0)) printf("\n\rBotao Pressionado.");
         else               printf("\n\rBotao Solto.");
         valor_anterior_A0 = input(PIN_A0);
         }
      }
    }
}

Mais uma vez obrigado a todos.

test man*~ · 2 de novembro de 2015

@Fabiano.araujo talvez o delay foi necessário por causa do FUSE IESO Internal/External Oscillator Switchover bit... Aquele negócio de Two-Speed Start-up...