¿Cómo puede un convertidor USB-RS232 afirmar manualmente su pin TX?

Hice una PCB personalizada basada en PICAXE que integra todos los componentes necesarios para programar el microcontrolador. Asumí que todo estaba bien porque podía usarlo para programar bajo Windows sin problemas. Sin embargo, en Mac OSX no pude programarlo. Ah, y estoy usando el chip WCH CH340G USB-RS232 para reducir costos, ya que el FTDI FT232RQ cuesta más de 7 veces el precio y no necesito todas sus funciones.

Estaba completamente convencido de que había algo eléctricamente incorrecto en mi diseño que causaba que el CH340G se comportara mal en OSX... Había modificado mi placa para poder realizar una prueba de bucle invertido en Coolterm, y la transmisión se congelaba cada varios caracteres. Claramente, algo estaba mal y pensé que se trataba de un error en el controlador CH340G OSX. El soporte técnico de WCH me aseguró que no lo era y que podría ser un chip falsificado. Durante esta cacería de brujas, tomé un convertidor USB-RS232 listo para usar basado en el mismo chip y funcionó a la perfección. ¡Demasiado para un "error de controlador" que causa mi dolor de cabeza!

Luego construí otra unidad con la cantidad mínima de componentes necesarios para realizar la prueba de bucle invertido (es decir, sin PICAXE), y pude llevarla hasta el punto en que la prueba de bucle invertido era confiable y ya no se congelaba. Por lo tanto, es probable que algo esté pasando con el circuito que causó la congelación, pero por ahora, podría continuar conectando mi PCB a una placa de prueba y usando la variedad DIP para componentes externos para completar el circuito de programación.

Ahora vamos al meollo de mi pregunta...

Utilicé dos configuraciones de prueba: 1) mi PCB conectada a una placa de pruebas con el PICAXE y 2) una placa de pruebas con el PICAXE y el convertidor OTS USB-RS232. Conecté cada uno a mi computadora portátil con Windows y conecté las señales que pensé que eran más relevantes para mi Saleae Logic 8 Pro. Capturé las señales cuando programaba en Windows, luego moví el cable USB a mi iMac y capturé las señales nuevamente. Esto es lo que terminé viendo:

Programación PICAXE trabajando bajo Windows

ingrese la descripción de la imagen aquí

Entonces, la diferencia obvia aquí es que la señal "Serial In" no tiene un nivel lógico alto cuando comienza el proceso de programación. Esto es obligatorio porque así es como funciona el protocolo de programación PICAXE (o al menos, eso es lo que parece). Debe afirmar la línea TX sobre RS232, lo que pone al PICAXE en un modo en el que transmite una onda cuadrada, seguida de bits que identifican el tipo de chip.

Parece bastante claro a partir de la captura del analizador lógico que el controlador CH340G en OSX no puede afirmar su pin TX, pero la versión de Windows sí puede. Al tratar de recopilar la mayor cantidad de información posible para poder suplicar a WCH que me ayude con este problema, estoy tratando de entender cómo es posible afirmar TX en absoluto . En el mundo de Windows, creo que todo termina como una llamada WIN32API. Miré la documentación del controlador FTDI solo como un marco de referencia, y puedo ver que tiene funciones para configurar el estado de DTR y RTS, por ejemplo, pero no una forma de configurar el estado de TX. En el lado de la API de Windows, escribe datos fuera de TX llamando a WriteFile. No hay una forma que yo sepa que le permita simplemente decir "mantener TX bajo" o "mantener TX alto".

¿Alguien puede explicar cómo se puede lograr esto en Windows u OSX, para que pueda continuar con mi investigación y depuración? Debe haber una forma de hacerlo que me falta, o una prueba de que realmente falta algo en el controlador de WCH. Después de todo, también tengo el cable de programación PICAXE AXE027, y puede programar los chips cuando se ejecuta en OSX. Si sabe qué funciones se usan en Windows y/o OSX para lograr un control de nivel lógico sobre la línea TX, ¡eso también sería extremadamente útil!

No sabía acerca de la función de descanso . Parece que esto podría ser lo que le falta al controlador WCH en OSX.

En mi búsqueda continua para descubrir cómo hacer que este chip funcione, cargué Ubuntu 16.04 LTS, que tiene el controlador WCH incorporado (al menos, creo que es de WCH). Ejecuté la herramienta de programación en Ubuntu y tampoco funciona. La fuente WCH no se compila bajo 16.04 debido a la diferencia en la versión del kernel. Intenté cargar la versión que construí en 12.04, pero no se carga. No puedo probar con 12.04 porque Chrome ya no es compatible con ese sistema operativo.

No hay ayuda directa aquí, solo preguntas: ¿Qué controladores está usando en Windows? ¿Bajo OSX? ¿Son los fabricados por el OEM de su chip? ¿Ha leído/comprendido el protocolo USB utilizado para emular la comunicación serie? (La mayoría no sabe que USB puede contener muchos protocolos diferentes). OSX es Unix en esencia, ¿verdad? ¿Qué devuelve "lsusb" cuando lo escribes en una consola OSX? ¿Llamó a la aplicación utilizada en las cajas Win / Mac? ¿Son lo mismo? ¿Son productos comerciales de PICAXE? ¿De Microchip.com?
La forma en que normalmente establecería una "afirmación" larga en la transmisión desde un UART es "enviar un descanso" que, en una PC, se haría mediante una llamada al sistema (no sé qué en Windows). Sin embargo, no conozco ninguna forma de hacer esto con una escritura de puerto serie normal.
Gracias por los comentarios, a todos. Los controladores bajo Windows y OSX son del OEM del CH340G. No me meto con nada en la capa USB ni en el propio protocolo. Estoy usando la herramienta de programación PICAXE (de Revolution Education, creador de PICAXE) para hacer todo. Solo necesita una conexión de puerto serie simple y antigua y maneja el protocolo de programación (que es propietario). @DoxyLover gracias por el consejo sobre el envío de un descanso. Hay una función de coincidencia en los documentos de FTDI, así que tal vez esta sea la clave.
La función de interrupción establecida se incluyó en los UART originales utilizados en las PC desde el principio de los tiempos. Parece probable que FTDI haya emulado completamente el UART en su hardware y haya brindado soporte API para esas funciones en sus controladores. Es posible que al otro proveedor le falte esa característica en algún lugar de su ecosistema compatible con MAC.
Solo para información, lo que encontré con respecto a generar el descanso en Windows: stackoverflow.com/questions/4585661/…
Nadie se molestaría en falsificar basura barata como el CH340.
En Mac OS X, la llamada es tcsendbreak . Pero parece que su disponibilidad depende del controlador, y algunos adaptadores USB a serie baratos no lo implementan. Otro ejemplo de alguien que luchó con esto también (pero con un chip pl2303): aaronkondziela.com/2015/04/…
@CL, el CH340G es definitivamente barato, pero cuando estás ahorrando centavos para el proyecto educativo de un niño, cada centavo cuenta. ¡$0,40 por CH340G frente a $3,50 por el equivalente de FTDI (más de) es un gran problema! Lo curioso es que Prolific tiene más o menos una parte equivalente que cuesta poco más de $1, e incluso han reportado chips falsificados.
@dim ¡Gracias por esa información! Definitivamente investigaré esto un poco más. El problema ahora es que el soporte técnico de WCH básicamente comenzó a ignorar todas las solicitudes que envié desde el ida y vuelta inicial... lo cual es muy desafortunado si su información es correcta y si es algo que podrían arreglar fácilmente en su controlador.
Buena suerte con su apoyo. Desafortunadamente, aquí puede ser donde vea por qué es tan barato.
@Dave tal vez deberías escribir tu propia respuesta ahora. No siento que tenga legitimidad para hacerlo, porque la información principal fue proporcionada por DoxyLover, solo seguí con algunas búsquedas en Google. Pero dejar esto sin respuesta tampoco tiene sentido.
Todos, gracias por su aporte. Estoy bien de cualquier manera: puede publicar una respuesta y puedo aceptarla, o puedo publicar lo que encuentre. Todavía no me doy por vencido. Voy a seguir molestando a WCH una vez que tenga información más concreta. Mi tarea actual es reproducir el problema con su controlador de Linux, luego intentaré solucionarlo y proporcionarles la fuente... ya veremos...
El título hizo que pareciera que podría ser una buena pregunta, pero es demasiado larga. Leí el primer párrafo, pero eso fue toda una pelusa introductoria que me hizo perder el tiempo, así que me detuve ahí. Seguramente puede resumir su pregunta en tres párrafos. Hasta entonces, seguir adelante.
@OlinLathrop Me doy cuenta de que eres bueno en esta área, pero, hombre, estás seguro de que eres grosero en tus comentarios. ¿Trabajas con personas reales o te sientas detrás de una pantalla todo el día?
Parece que su objetivo es usar el convertidor de una manera que no sea realmente parte de la conversión serial USB ordinaria, por lo que es comprensible si el proveedor no está interesado. En términos de autoayuda, puede usar la captura de paquetes USB basada en software (la última vez que tuve que lidiar con esto, Microsoft estaba ofreciendo la suya propia) para ver qué está haciendo realmente el controlador de Windows al hablar con el chip y compararlo con la fuente del controlador de Linux.
@ChrisStratton gracias por la sugerencia, pero esto probablemente supere mi capacidad. Desde el analizador lógico, realmente parece que es el descanso en el que se basa el PICAXE para poner en marcha la secuencia de programación. Creo que probablemente tengo una mejor oportunidad de hacer que el controlador de Linux funcione y luego presentar mis hallazgos a WCH para ver si pueden aplicar el cambio a su controlador OSX. Entiendo su punto sobre la postura del proveedor sobre esto. Una vez que me dijeron que saben que el loopback funciona en el chip, no estaban interesados ​​en saber nada más de mí. Veremos cómo va esto.
Bueno, buena suerte. Mi punto era que si estaba tratando de depurar la funcionalidad de interrupción en el controlador de Linux que parece que cree que es defectuosa, comparar lo que hace con los paquetes que el controlador de Windows pone en el cable cuando realmente lo logra podría ser lo más fácil. manera. Por supuesto, también puede buscar la última versión del controlador de Linux en git upstream y asegurarse de que alguien no haya identificado y solucionado su problema aparente.
@ChrisStratton Lo entiendo. Dado cualquiera que sea mi conjunto de habilidades en este momento, creo que modificar el controlador de Linux para que se comporte correctamente y resulte en un seguimiento lógico que coincida con el que funciona en Windows es mi mejor opción. Creo que acabo de obtener el controlador CH340 incompatible de github trabajando en el nuevo kernel de Linux reemplazando las llamadas obsoletas según sea necesario y recompilando. Así que ahora trataré de manejar el comportamiento de ruptura... cruzando los dedos. Sin embargo, entiendo totalmente lo que dices sobre la captura de paquetes USB, así que eso será algo que necesito aprender. :)
¿Alguna resolución sobre este @Dave?
Aún no. Compré el controlador OSX CH340 de la compañía que supuestamente tiene la función de interrupción funcionando... y no funciona. Probablemente tendré que hacer el sniffing USB, pero también he decidido hacer un nuevo PCB basado en el MCP2200 para ver si su controlador OSX funciona correctamente.

Respuestas (1)

Envía un descanso para afirmar el pin TX, pero algunos controladores/chipsets mal implementados no pueden hacer esto durante largos períodos de tiempo (más de uno o dos caracteres).

En win32api, usa SetCommBreak() y ClearCommBreak() para afirmar y liberar el pin TX.