Hice un PCB basado en PICAXE personalizado que integra todos los componentes necesarios para programar el microcontrolador. Asumí que todo estaba bien porque podría usarlo para programar bajo Windows muy bien. Sin embargo, bajo Mac OSX no pude programarlo. Ah, y estoy usando el chip WCH CH340G USB-RS232 para reducir los costos, ya que el FTDI FT232RQ es más de 7 veces el precio, y no necesito todas sus funciones.
Estaba completamente convencido de que había un problema eléctrico en mi diseño que causó 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 congelaría cada uno de los caracteres. . Claramente, algo estaba mal y pensé que se trataba de un error en el controlador OSX de CH340G. El soporte técnico de WCH me aseguró que no lo era, y que podría ser un chip falsificado. Durante esta búsqueda de brujas, tomé un convertidor USB-RS232 estándar, basado en el mismo chip, y funcionó a la perfección. ¡Tanto 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 llegar al punto donde la prueba de bucle invertido era confiable y ya no estaba congelada. Por lo tanto, es probable que haya algo en el circuito que causó la congelación, pero por ahora, podría continuar conectando mi PCB a una placa de pruebas y utilizando la variedad DIP para componentes externos para completar el circuito de programación.
Ahora vamos a la carne de mi pregunta ...
Utilicé dos configuraciones de prueba: 1) mi PCB conectada a una placa con el PICAXE, y 2) una placa 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 consideré más relevantes para mi Saleae Logic 8 Pro. Capturé las señales al programar en Windows, y luego moví el cable USB a mi iMac y capturé las señales nuevamente. Esto es lo que acabé viendo:
Porlotanto,ladiferenciaobviaaquíesquelaseñal"Serial In" no tiene una lógica alta cuando se inicia el proceso de programación. Esto es obligatorio porque así es como funciona el protocolo de programación PICAXE (o al menos, así es como se ve). Tiene que hacer valer la línea TX a través de RS232, que coloca el PICAXE en un modo en el que transmite una onda cuadrada, seguida de bits que identifican el tipo de chip.
De la captura del analizador lógico parece bastante claro que el controlador CH340G en OSX no puede hacer valer su pin TX, pero la versión de Windows sí. 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 comprender 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 del DTR y RTS, por ejemplo, pero no una manera de establecer 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 bajo TX" o "mantener alto TX".
¿Alguien puede explicar cómo se puede lograr esto en Windows u OSX, para poder continuar con mi investigación y depuración? Debe haber una forma de hacerlo que me esté faltando, o una prueba de que realmente hay algo que falta en el controlador de WCH. Después de todo, también tengo el cable de programación PICAXE AXE027, y es capaz de programar los chips cuando se ejecuta bajo OSX. Si sabe qué funciones se usan en Windows y / o OSX para lograr un control de nivel lógico sobre la línea de transmisión, ¡eso también sería extremadamente útil!
No sabía sobre característica de ruptura . Parece que esto podría ser lo que falta el controlador WCH en OSX.
En mi búsqueda en curso para descubrir cómo hacer funcionar este chip, 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 cargará. No puedo realizar pruebas bajo 12.04 porque Chrome ya no es compatible con ese sistema operativo.