Misteriosos pulsos RX en UART se conectan en OS X Arduino Due

Arduino IDE 1.6.8, Arduino Due, Mac OS 10.11.3

Veo ocho pulsos misteriosos en la línea RX cuando me conecto al puerto serie usando múltiples bibliotecas de clientes (Python, JavaScript, así como el monitor serie incorporado en el IDE). Aproximadamente 78-79us cada uno, muestreado a 1MS / s con un Logic Pro 16.

Estos ocho pulsos cuando se interpretan a 57600 baudios atascarán el firmware de Firmata. Y suceden en cada conexión.

Esto está usando una nueva instalación del Arduino 1.6.8 IDE y con múltiples bocetos (el boceto normal "Blink" también reproducirá esto).

Repro pasos en mi máquina:

Instalar cualquier boceto
Inicie un analizador lógico si quiere atraparlo
Vaya a Monitor de serie. Tengo el mío configurado para 57600 baudios, final de línea de Newline, pero no importa
Si lo desea, cierre y repita el paso 3
Tenga en cuenta los pulsos cada vez que se conecte al puerto serie

¿Alguna sugerencia para diagnosticar esto? Suena como si fuera un controlador de serie de alguna manera.

arduino-due uart osx

— Blake Ramsdell
fuente

Independientemente de su procedencia, tenga en cuenta que le ha hecho un favor al indicar un error crítico en el firmware que está ejecutando; esto no debería ser capaz de ponerlo en un estado irrecuperable. ¿Es un error de lógica de programa o el código de manejo de UART no trata adecuadamente con un indicador de error?

— Chris Stratton

En términos de rastrear la fuente, sería útil probar otro programa de cliente en serie, otra computadora / sistema operativo, otro dispositivo en serie USB, etc.

— Chris Stratton

En cuanto a probar otros programas en serie, existen múltiples bibliotecas que interactúan con el protocolo Firmata y utilizan diferentes implementaciones en serie subyacentes (Python, JavaScript y el Monitor en serie Arduino IDE incorporado) que exhiben el mismo comportamiento. Mi próximo plan es probar esto en una máquina Linux y ver si veo el mismo comportamiento, que esperamos aislar si esto es específico de OS X.

— Blake Ramsdell

También obtienes uno cuando te desconectas. La velocidad de transmisión de la conexión no tiene efecto sobre la duración del pulso. Mi sospecha es que es el firmware del ATMega16U2 el que lo está haciendo (o cualquier chip que tenga en cualquier versión).

— Majenko

Cuando inicia el monitor en serie, el software restablece el módulo arduino. Si el módulo Arduino tiene un gestor de arranque, creo que estas son las señales del protocolo STK500.

— Mert Gülsoy

Corto:

Mirando el firmware ATMEGA16U2 ( https://github.com/arduino/ArduinoCore-sam/blob/master/firmwares/atmega16u2/arduino-usbserial/Arduino-usbserial.c ) Lo encuentro, cuando configuras / cambias la configuración del Puerto serie emulado USB, el USART se reinicia. Esto sucede incluso cuando abre el monitor serie Arduino (debe configurar la velocidad de serie, etc.). Esto causa tu pico.

Largo:

Mira la función:

void EVENT_CDC_Device_LineEncodingChanged(USB_ClassInfo_CDC_Device_t* const CDCInterfaceInfo)

Allí verá que después de algunas líneas, restablece el USART, poniendo a cero sus registros:

/* Must turn off USART before reconfiguring it, otherwise incorrect operation may occur */
    UCSR1B = 0;
    UCSR1A = 0;
    UCSR1C = 0;

En la página 168, de la hoja de datos ATMEGA16U2 actual, encontrará que, al configurar el bit 3 de UCSR1B (TXEN1), habilita el transmisor, anulando el funcionamiento normal del puerto (es decir, se convierte en salida). Citando la hoja de datos:

Escribir este bit en uno habilita el transmisor USART. El transmisor anulará la operación del puerto normal para el pin TxDn cuando esté habilitado. La desactivación del transmisor (escribiendo TXENn a cero) no será efectiva hasta que se completen las transmisiones en curso y pendientes, es decir, cuando el registro de desplazamiento de transmisión y el registro de búfer de transmisión no contengan datos para ser transmitidos. Cuando está deshabilitado, el transmisor ya no anulará el puerto TxDn.

Por lo tanto, al escribir UCSR1B = 0;, ya no anulará el pin TXD1, que actuará como entrada.

El ATMEGA16U2 TXD está conectado a la línea RX del ATSAM3X8E. En funcionamiento normal, con el UART habilitado, esa línea permanece alta si no se transmiten datos. Si deshabilita el UART, esa línea en particular ya no es un controlador para 1. Dado que el código de inicialización no establece el pull-up en ese pin (y tampoco está configurado como salida), el pin se convierte en una entrada flotante y cualquier fuga a GND o incluso la impedancia de entrada de su sonda (que está entre su pin y GND), llevará lentamente el nivel lógico a 0.

Para anular este problema, debe: 1) Modificar el firmware ATMEGA16U2, estableciendo ese PIN como SALIDA, con el valor 1. 2) Modificar el firmware ATMEGA16U2, habilitando el pull-up en ese pin. 3) (sugerido) Habilite el pull-up en la línea RX en el ATSAM3X8E.

— siguiente truco
fuente