Enviando vía PIC18F97J60 EUSART

0

Cuando intente enviar y recibir utilizando un PIC18F97J60 y MAX232 utilizando un programa escrito con el compilador C18, solo puedo transmitir datos. Para recibir, he intentado al menos 50 métodos pero ninguno está funcionando. Incluso probé el software en varias tarjetas de microcontrolador para detectar un problema de hardware, pero ninguna de las tarjetas recibe nada. Creo que los siguientes elementos son correctos:

  • Mi reloj es perfecto a 41.6667MHz
  • Mi generación de baudios es perfecta
  • Mi hardware está bien (otro código hexadecimal de la tercera parte puede recibir también)
  • Mi PC host, su puerto COM y el cable serie están bien

¿Alguien puede guiarme con áreas probables que pueda faltar?

------------------ OTRAS ACLARACIONES --------------------------- ----------------

Gracias Olin por ayudar, eres un gran hombre. Lo siento por no hacer mi pregunta correctamente. Tenga en cuenta:

Estaba tratando de hacer E / S en serie para escribir un cargador de arranque para el PIC18F97J60, ya que el cargador de arranque provisto por mi proveedor detiene el envío / recepción con el software PCloader después de una descarga hexadecimal de la aplicación parcial del usuario. También garantiza que el puerto RS232 pueda enviar y recibir. Por otra parte, el cargador de arranque de Microchip descrito en AN1310 también se apesta al recibir datos.

Mi aplicación de muestra (un gestor de arranque) puede transmitir pero nunca recibe nada. Estoy en la sopa: o necesito un nuevo cargador de arranque o mi aplicación debe funcionar. Nunca he enfrentado un problema así en mis 12 años de desarrollo y me siento como un tonto.

Otros detalles que solicitó son los siguientes:

  1. Tenía 10-12 tarjetas PIC18F97J60 con MAX232 en C6 / C7 para Serial I / O. El problema es el mismo para todos los tableros (de diferentes lotes).
  2. Deseo hacer 9600 baudios, 8 bits, sin paridad, 1 parada, sin apretón de manos, sin interrumpir el intercambio de datos con RealTerm ( Better Than Hypertermin - Displays HEX Code ).
  3. Los cálculos de mi reloj y velocidad de transmisión son perfectos para 41.6667MHz. He establecido OSCTUNE = 0x40 y BAUDCON = 1084 . Puedo recibir perfectamente en la PC con RealTerm.
  4. Mi programa no puede recibir nada en el PIC pero puede transmitir.
  5. Probé el sondeo y la interrupción, pero nada funciona.

El fragmento de código es el siguiente:

void putchar(unsigned char Char)
{
    //Wait for (TSR==1)
    while(TXSTA1bits.TRMT!=1);
    //Trasmit Current Data
    TXREG1= Char;
    //Wait for (TSR==1)
    while(TXSTA1bits.TRMT!=1);
}

void putstr(unsigned char *String)
{
     do
     {
         putchar((*String));
     }while(*String++);
    //CR
     putchar(CR);
    //LF
    putchar(LF);
}

void main(void)
{
    unsigned char RS232[] = "RS-232";
    OSCTUNE = 0x40;
    TXSTA1 = 0x24;
    RCSTA1 = 0x90;
    BAUDCON1=0x08;
    SPBRGH1=0x04;
    SPBRG1=0x3C;

while(1)
{
    putstr(RS232);
    Delay10KTCYx(200);
    if(PIR1bits.RC1IF == 1)
    {
            MYChar = RCREG1; //*** No OERR & FERR present, RC1IF never gets set ***
    }
}

}

    
pregunta Sachin Gupta

3 respuestas

2

Una mala característica molesta de la UART en cada PIC con el que he trabajado es que un error de desbordamiento de datos cerrará el receptor hasta que el código lo deshabilite y lo vuelva a habilitar. Por lo tanto, es imperativo tener un código que verifique periódicamente el indicador de error de saturación y, si está configurado, deshabilite y vuelva a habilitar la función de recepción de UART. De lo contrario, si el búfer de recepción se desborda, no perderá un byte recibido, perderá todos los datos para siempre.

No estoy realmente seguro de por qué Microchip diseñó sus UART de esta manera. Mi conjetura sería que en los PIC tempranos, una saturación de recepción causaría que la máquina de estado de recepción perdiera la sincronización de trama, y que la desactivación del receptor se consideraba preferible a recibir datos de trama aleatoriamente (podría estar de acuerdo con ellos en ese punto, aunque consideraría eliminando bytes enteros mientras se mantiene la sincronización para ser aún mejor); los PIC posteriores mantuvieron el comportamiento por compatibilidad, a pesar de los rediseños sustanciales del subsistema UART.

En cualquier caso, la implementación UART del PIC es lo que es. Compruebe que el receptor UART esté habilitado y que el desbordamiento de recepción no se active. Si no, deshabilite la función de recepción de UART y vuelva a habilitarla. Tenga en cuenta, por cierto, que en algunos PIC, la desactivación maestra de la función UART no desactivará el receptor; debe borrar y restablecer la habilitación del receptor.

    
respondido por el supercat
0

Un par de cosas vienen a la mente mirando el código:

¿Dónde está definido MyChar?
No puedo ver ninguna configuración de TRISC7 (aunque debería configurarse en el reinicio) para asegurarme de que sea una entrada. Además, intente eliminar los datos enviados (el putstr (RS232)) y borrar CREN y restablecerlos antes de cada comprobación de indicador de interrupción en caso de que exista una condición de error.

    
respondido por el Oli Glaser
0

Antes de que puedas encontrar cualquier error, debes llegar a la mentalidad de que los chips están funcionando correctamente y de que arruinaste en alguna parte. He hecho la comunicación UART en casi el mismo chip (18F67J60) e incluso la misma frecuencia de reloj. Estas cosas funcionan.

Primero, revisaría todas sus suposiciones. ¿Cómo sabes que tu reloj es realmente correcto? ¿Cómo sabes que tu velocidad de transmisión es correcta? ¿Ha comprobado el tiempo de bits individuales en un ámbito? Otro código puede recibir usando el mismo hardware, por lo que es un argumento convincente que está bien. Eso significa que es casi seguro que se trata de un error de firmware, que también es la suposición más probable incluso sin la información adicional.

La respuesta obvia es, por lo tanto, que arruinó algo en el controlador UART. No ha proporcionado ningún código, y no me gustaría verlo de todos modos, especialmente porque está en C. Sin embargo, ahí es donde está su problema.

Puedes ver mis ejemplos de código UART para un PIC 18. Uno de ellos es incluso en un proyecto de red para un 18F67J60. Vaya a enlace e instale la versión de las Herramientas de desarrollo PIC. En la FUENTE > En el directorio PIC encontrará una plantilla genérica de controlador de controlador UART. En la FUENTE > Directorio de la RED encontrará un proyecto completo que incluye un controlador UART. El nombre del archivo es NET1C_UARTT.ASPIC.

Añadido:

Ahora ha proporcionado un fragmento de código. Ya que puede recibir los bytes enviados por el PIC, la velocidad de transmisión y la configuración del reloj probablemente sean correctas. Sin embargo, todavía no has hecho algunas de las cosas básicas que te pidieron hace meses. Mire el pin de recepción de UART a la derecha en el PIC y vea si hay caracteres adecuados allí . El problema se divide en dos áreas: el envío incorrecto en la PC a través del hardware hasta el PIC y la mala recepción en el firmware del PIC. Sigue dividiendo el problema hasta que llegues a un área lo suficientemente pequeña para que puedas ver lo que está mal.

    
respondido por el Olin Lathrop

Lea otras preguntas en las etiquetas