mgleria
commented
6 years ago Una posible línea de trabajo podría ser que el padding introducido por el compilador tenga un valor conocido. Luego analizar la estructura byte a byte en busca de ese valor padding para removerlo del buffer final a enviar. Primero hay que ver si el compilador me ofrece esa posibilidad, y luego si existe algún valor que pueda utilizar sin que se confunda con un dato real. Se puede hacer la búsqueda luego de confirmar que la estructura asociada tiene padding, de esta forma se reduce la posibilidad de un falso positivo.
Al migrar código desde una arquitectura menor (8bits) a esta de 16bits surge una dificultad en cuanto a la definición de tipos de datos y uso de la memoria. Es sabido que en cualquier arquitectura acceder a una posición de memoria impar es un problema a sortear. De lograrse, requiere muchas más intrucciones de código lo que impacta de lleno en la performance, y depende cómo se resuelva puede derivar en excepciones en tiempo de ejecución. Por este motivo, el compilador se toma el trabajo de alinear al tamaño WORD de la arquitectura todos los tipos de datos menores a esta, agregando bytes de relleno (padding) para que no existan accesos de datos en direcciones que no sean múltiplos de WORD (direcciones impares). Esto trae como consecuencia un aumento en la utilización de la memoria, pero una ganancia importante en la performance y una reducción en la cantidad de código máquina compilado. El problema que surge es en la generación e interpretación de las tramas que deben enviarse a través del MODEM al servidor. Con las optimizaciones realizadas por el compilador, la trama es algunos bytes mayor (3 en el caso de _trama_muestrat) y eso desplaza los campos que parsea el server cuando interpreta los datos recibidos. Posibles soluciones:
El camino más directo a seguir desde mi perspectiva, es dejar al compilador que haga su trabajo, y adaptar del lado del servidor la interpretación de la nueva trama recibida. Esto podría llegar a ser compatible con el nuevo sistema que se está deslegando del lado del servidor.
La segunda alternativa es enfocar el esfuerzo en tratar de lograr la equivalencia de las tramas, en detrimento de la performance y a riesgo de provocar excepciones en runtime. La ventaja de este enfoque es que para el servidor es transparente. Punto de partida
Una tercera posibilidad podría ser, detectar los bytes de padding de alguna manera, y removerlos de bufferGPRS, que es el array donde codifico los datos en hexadecimal de la trama a enviar en ascii. De esta forma, desde el MCU gestiono la memoria de forma apropiada y no tengo que realizar cambios del lado del servidor. De ser viable la detección de los bytes de padding algoritmicamente sería el enfoque más apropiado.
Fuentes consultadas: