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:
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.
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.
st2000
DoxyLover
dave
miguel karas
oscuro
CL.
oscuro
dave
dave
oscuro
oscuro
dave
olin lathrop
dave
chris stratton
dave
chris stratton
dave
rdtsc
dave