Problema envío/recepción int16 PIC a PC

[tito melli]

Hola!

Necesito transmitir el valor de unas variables int16 de CCS por UART al PC. Sin embargo, hay algunos numeros que no se estan enviando bien. Por ejemplo, el 48785 lo envía y recibe bien, 48786 el PC lo interpreta como 2879, y 48787 lo vuelve a enviar y recibir bien. Estos numeros son solo ejemplos. No he tenido oportunidad de ver en qué valores exactamente falla.

Para el envío uso la siguiente funcion, para dividir el int16 en 2xInt8:

Código: [Seleccionar]

void SplitByteNWrite (int *chptr, int n) {
 int i = 0;
   for (i=1; i<=n; ++i) {
      putc(*chptr);
      *chptr++;
   }
}

La uso así porque también tengo que enviar variables float.

Una vez enviadas, en el PC las uno con la siguiente funcion, en Visual Studio:

Código: [Seleccionar]

        private UInt16 Byte2int16(Byte[] Array_buffer, int offset)
        {
            Byte[] newVar = new Byte[2] { 0, 0};

            newVar[0] = Array_buffer[0+offset];
            newVar[1] = Array_buffer[1+offset];

            UInt16 OutInt16 = System.BitConverter.ToUInt16(newVar, 0);

            return OutInt16;
        }

Asumo que el envío por parte del PIC es correcto, pues nunca he tenido problemas, y practicamente todo el tiempo lo envía correctamente.

Por lo tanto, me pregunto si el formato int16 de microchip no es el estandar, como pasa con los float, y cada vez que un determinado bit pasa a 1, me fastidia la conversión.

¿Qué creeis que puede estar pasando?

Gracias!

Saludos.

[tito melli]

Tengo identificado qué números se están enviando mal. Cada vez que pasa por el hexadecimal 0x1A, me invierte el orden.

Es decir, si tiene que enviar 0x001A, envía 0x1A - 0x00, en lugar de 0x00 - 0x1A, y el siguiente vuelve a enviarlo bien, es decir 0x00 - 0x1B.

Vuelve a hacer lo mismo cuando pasa por 0x011A, por 0x021A, por 0x031A, etc.

Sabéis por qué puede estar pasando esto? tiene que ver con el uso de punteros o el almacenamiento de las variables en la RAM del micro?

Saludos

[KILLERJC]

El problema esta en la funcion de recepcion de la PC, para sacarte de la duda si tenes un conversor UART/USB podrias probarlo, pero no creo que sea del micro.

Ademas... no es mas sencillo algo asi:

Código: C

1. void SplitByteNWrite (int *chptr, int n) {
2.  while (--n)
3.       putc(*chptr++);
4. }

[tito melli]

El problema esta en la funcion de recepcion de la PC, para sacarte de la duda si tenes un conversor UART/USB podrias probarlo, pero no creo que sea del micro.

Actualmente lo estoy probando con un conversor UART/USB. Que puede estar fallando en la función del PC? Es tan simple que no encuentro nada 

Ademas... no es mas sencillo algo asi:

Código: C

1. void SplitByteNWrite (int *chptr, int n) {
2.  while (--n)
3.       putc(*chptr++);
4. }

Te la copio 

[KILLERJC]

Actualmente lo estoy probando con un conversor UART/USB. Que puede estar fallando en la función del PC? Es tan simple que no encuentro nada 

Y lo estas viendo con un hyperterminal o algo asi?.

Es raro que plantees que el micro esta cambiando el orden, a no ser que el codigo dentro del PIC lo este realizando. Pero al menos los codigos que mostras no afectan en nada para que haga ese cambio.

PD: y en la PC no es mas simple:

Código: C

1. private UInt16 Byte2int16(Byte[] Array_buffer, int offset)
2.         {
3.              return System.BitConverter.ToUInt16(Array_buffer, offset);
4.         }

Me refiero a que estas creando un array mas siendo que tenes un Array que podes usar, y el offset es justamente eso, es el valor del segundo parametro del ToUint16

[tito melli]

PD: y en la PC no es mas simple:

Código: [Seleccionar]

        private UInt16 Byte2int16(Byte[] Array_buffer, int offset)
        {
             return System.BitConverter.ToUInt16(Array_buffer, offset);
        }


Lo estaba haciendo así porque no tenía claro qué bit se almacena primero en la RAM, y lo dejé así para poder invertir el orden y hacer pruebas. No obstante ya sobra

Ya se dónde está el problema. He usado el hyperterminal de CCS, y todo se envía perfectamente, por lo que el problema esta en el PC.

Investigando un poco, parece ser que para Windows "0x1A" significa EOFCHAR, lo que provoca que este caracter se pierda.

Aquí la web de donde he sacado la info, por si a alguien más le pasa lo mismo:

https://stackoverflow.com/questions/22745933/serialport-received-data-lost-at-high-baudrates-when-stream-contains-0x1a

Provaré con la solución que proponen.

Gracias KillerJC,

Saludos