Hola, con que herramienta estas verificando eso ? Porque me llama la atención que envías un 10 que es el caracter line-feed y justamente el 13 es el Carriage return, que son los dos caracteres de próxima linea y retorno de carro, posiblemente la herramienta te los este convirtiendo.
Saludos !
El pic24f me los envia por usb_cdc al pc y los veo con slow de ccs. Esto ya funcionó con un 18f2550, así que descarto que sea del programa terminal.
Tiene que ser "algo" en el pic24f, por que el 16f hace lo que tiene que hacer por que como ya digo esto ya funcionaba antes.
esta es la interrupcion por recepcion de la uart:
void __attribute__((interrupt,no_auto_psv)) _U1RXInterrupt(void)
{
//rcvchar=0x00; // Inicializo carácter recibido
if(DataRdyUART1()){ // Si hay algo pendiente de recibir ...
rcvchar=ReadUART1(); // lo descargo y ...
addcbuff(rcvchar); // lo añado al buffer
}
if(U1STAbits.OERR) U1STAbits.OERR=0;//si hay error de overflow es borrado
IFS0bits.U1RXIF = 0; //Ponemos a 0 el flag de la interrupcion de recepcion
}
Esta es la rutina para incluir el caracter recibido en un buffer:
void addcbuff(unsigned char c){
cbuff[xbuff++]=c; // Añade carácter recibido al Buffer
if (c==end_of_transmit){ // Si el caracter en el indicador de final
flag_buffer = 1; // ya se puede procesar
}
}
Esta el la funcion de envio al esclavo (16f1525). 'i' es un número decimal que se va incrementando en un bucle for desde 1 hasta 125
y justo en 10 tengo el problema
putsUART1(printf("%c%c%c%c%c",RS485_D,RS485_ID,command_test,i,end_of_transmit));
Esta es la porción de código que recoge el byte de un buffer y lo envía por usb_cdc:
case 0x74: //"t"
cTest = arg[0];
while(!USBUSARTIsTxTrfReady()){
CDCTxService();
}
sprintf(iText,"Recibido %u \n\r",cTest);
putsUSBUSART(iText);
CDCTxService();
break;
Como comprobarás es un código sencillo y ahora me pregunto si puede haber un problema con char, int o unsigned.
No debería, porque para eso utilizo hasta un valor máximo de 125.
Voy a probar con hiperterminal haber que pasa
