Errores al transmitir el número de 10 bits leído con Atmega328 vía serial y al leerlo con "od"

No puede empujar un valor de varios bytes a través de un canal serie de 8 bits en una sola operación. Como no está seleccionando varios campos de bits en el valor de origen, lo que realmente sucede es que está enviando los 8 bits menos significativos de lecturas sucesivas. Y luego malinterpretar 2 o 4 de ellos seguidos como valores falsos de varios bytes.

Si puede tolerar 256 valores distintos , puede modificar su código para cambiar a la derecha el valor de conversión (u operar en modo de 8 bits para comenzar) para que envíe una medida legítima de un solo byte sin firmar. Luego, deberá asegurarse de que el dispositivo serie de Linux esté funcionando en un modo completamente sin formato, de modo que no se den interpretaciones especiales a los códigos. Finalmente, deberá configurar su código de visualización para interpretar los valores como enteros sin signo de 8 bits.

Enviar medidas de mayor resolución es complicado

• Un enfoque ingenuo es escribir un código de envío que envíe cada byte del valor en secuencia, recordando asegurarse de que todos los bytes provengan de la misma lectura de ADC. Pero este enfoque es ingenuo porque no proporciona ningún mecanismo para sincronizar el transmisor y el receptor. Si el receptor aún no está escuchando antes de que se inicie el transmisor, o si alguna vez se pierde un byte debido a un error, entonces el receptor puede comenzar a combinar bytes de diferentes lecturas en orden desplazado para generar valores falsos. Es posible solucionar esto con códigos de inicio especiales prohibidos que luego se escapan si aparecen en los datos, encabezados periódicos de resincronización multibyte de valores mágicos, o de forma menos confiableintervalos de tiempo entre lecturas (lo que es especialmente imprudente si alguna vez se utilizan convertidores de serie USB).

  • En el caso específico en el que sus lecturas son de 10 bits, puede hacer algo como dividirlas en dos palabras de 5 bits y usar los bits altos de cada una como un código de campo, por ejemplo, y dónde hay un valor de 10 bits que 0b011mmmmmdesea 0b010nnnnnenviar 0bmmmmmnnnnn. . Sin embargo, esto necesitaría un software de recepción personalizado que busque un comienzo de lectura 0b011xxxxxy un siguiente comienzo 0b010xxxxxy recombinación de los bits apropiados de cada uno. (El bit 0x40 está activado en cada caso con la esperanza de dirigir los códigos al rango imprimible, tal vez preservando la posibilidad de usar herramientas de línea de comandos para manipular los datos)

Pero, en general, esto genera muchos dolores de cabeza, por lo que primero vale la pena ver si un enfoque no binario podría ser viable.

• Envíe cadenas legibles por humanos codificando la representación ASCII de dígitos con un espacio o delimitador de nueva línea. Debido a que el carácter delimitador no se puede confundir con un dígito numérico, proporciona una división fácil de las lecturas y una sincronización implícita. Incluso en el caso de un error, el impacto no persistirá sino que se limitará a una o dos lecturas sucesivas. El uso de una nueva línea suele ser la mejor opción, ya que muchos esquemas de procesamiento de secuencias tienen un búfer de línea natural, un comportamiento que puede tener que cambiarse explícitamente para evitar demoras cuando se usa un delimitador diferente.

  • Los valores decimales se interpretan más fácilmente a simple vista y pueden estar bien para su propósito, pero deberá rellenar con ceros o aceptar que la cantidad de caracteres por valor es variable.

  • Los valores hexadecimales (rellenados con ceros a la izquierda) producen una conversión limpia de tamaño fijo de los datos. El valor en sí será exactamente el doble de la longitud del valor binario, es decir, 16 bits se convierten en 4 caracteres de 8 bits o 32 bits, pero el delimitador también tomará un byte, por lo que un valor de 16 bits requiere cinco caracteres en total. Dado que la resolución de su fuente es de 10 bits, en realidad podría usar solo 3 dígitos hexadecimales y un delimitador, para un total de 4 caracteres por lectura. Por supuesto, el software que consume necesitará interpretar los valores hexadecimales, pero esto tiende a funcionar bien con la mayoría de las cosas que ejecutaría en Linux; aún así, resolverlo en algunos contextos puede ser un poco complicado, puede requerir inyectar un prefijo "0x" antes de interpretar la cadena recibida, etc.

Hay algunos problemas potenciales adicionales en el caso de que intente utilizar un retraso programático fijo pero nervioso para regular dos cosas que tienen condiciones de preparación explícitas más apropiadas.

• No puede verificar que el UART serial esté listo para nuevos datos antes de escribir en el registro de datos.

• debe consultar la hoja de datos para determinar si es legítimo leer el registro de conversión de ADC cuando una conversión no está completa; de lo contrario, debe esperar el indicador de conversión completa.

Está enviando bytes únicos sin firmar a través de la serie.

El comando correcto que necesitas es:

od -t u1 /dev/ttyACM3 -w1

lo que significa que el tipo de sus datos es un entero sin signo de un byte de ancho, mientras que w1 debería imprimir un byte por línea.

Además, en su línea:

UDR0 = (ADCW*100/1024)  ;

No está usando value, que lanzó correctamente a int sin firmar . No estoy seguro de lo que hace el compilador, pero usar valueen esa línea sería más claro.

Utilizar el

od -t d2 /dev/ttyACM3 -w2

o

od -s /dev/ttyACM3 -w2

comando en su lugar.

Según man od, el -dconmutador muestra enteros sin signo de 2 bytes . -so -t d2mostrará los firmados.

Cambiando la línea

UDR0 = ( ADCW * 100 / ( 1024 ) );

A

UDR0 = ( ADCW * 10 / ( 1024 ) );

Y llamando al comando:

od -t d4 /dev/ttyACM2 -w4 

Me dio el valor correcto en un rango de 0 a 50 529 027, donde 0 es oscuridad total. El único problema es que los 'pasos' se actualizan solo cada 4 cm, donde normalmente debería poder detectar la diferencia en un par de milímetros.