networking - Serial Comms muere en WinXP
windows-xp serial-port (4)
¿Está usando el código de serie estilo DOS o el enfoque Win32 CreateFile?
Si el primero, sospeche mucho: si es posible, me convertiría en este último.
Si es lo último, ¿sabe en qué tipo de sistema se llama suspensión? ¿Estás en una llamada de lectura bloqueante? o una llamada de E / S superpuesta? o esperando en un evento? (No estoy seguro de tener suficiente experiencia para ayudar, pero ese es el tipo de preguntas que se me ocurren)
También puede consultar el tamaño de la cola, que puede establecer con la función SetupComm .
No compro las cosas del "sistema de mensajes de Windows", suena a pescado; puede escribir un buen código de E / S serie Win32 que nunca utilice mensajes de Windows.
editar: ¿sus eventos de E / S superpuestos usan eventos? Parece que recuerdo algo acerca de los eventos de reinicio automático que a veces faltan en su desencadenador ... revise sus llamadas de E / S superpuestas con mucho cuidado para ver si está manejando los posibles resultados correctamente. Quizás haya una manera de hacer que su código sea más robusto cancelando automáticamente la E / S solapada y reiniciando otra lectura. (¿Supongo que el problema está en la mitad de lectura, no en la mitad de escritura?)
Edición 2: Una sugerencia: suponiendo que el lado win32 ha perdido un byte o paquete, y sus dispositivos están en un punto muerto porque ambos esperan respuesta el uno del otro, ¿puede ajustar el otro lado de la E / S en serie regularmente? ¿enviar algún tipo de paquete "ping" con un contador incremental? (y registre los paquetes de ping en el lado de la PC, de esa manera usted puede ver si se ha perdido alguno)
Un poco de historia: tenemos una aplicación, que fue escrita originalmente hace muchos años (1998 es la primera fecha en PVCS, pero la aplicación es unos 5 años mayor que eso, ya que originalmente era un programa de DOS). Esta aplicación se comunica con una pieza de hardware vía serial. Cuando llegamos a Windows XP comenzamos a recibir informes de que la aplicación se estaba agotando después de un corto tiempo de ejecución. Parece que las comunicaciones en serie simplemente ''murieron'' y la aplicación se quedó en un estado atascado. La única forma de recuperarse de esta situación era reiniciar la aplicación.
La única información que puedo encontrar con respecto a este problema aparentemente fue que el sistema de Mensaje de Windows perdería la información que se recibía, el búfer se llenaría y el sistema se quedaría atascado. Este fragmento de información quedó en un documento antiguo, pero no hay evidencia que respalde esto. También menciona que esto solo prevalece a altas velocidades en baudios (115200+).
La solución fue proporcionar a los clientes convertidores USB-> Serial junto con el hardware.
Hoy: estamos trabajando en una nueva versión del hardware que se ejecutará a través de una red y puertos serie. Entonces, para permitirme trabajar en el código de red, menos el hardware real, estamos usando un dispositivo VSCOM NetCom113 . También instala un puerto de comunicación virtual en la máquina de los usuarios (es decir, la mía).
Ahora que tengo el código de red integrado con la aplicación, parece que el dispositivo NetCom exhibe el mismo comportamiento que un commport físico. Esto es indeseable ya que necesito que la aplicación funcione durante más de ~ 30 segundos.
Google no presenta ningún problema que experimentemos.
Me preguntaba:
- Alguien ha experimentado esto antes? Si es así, ¿qué hiciste para arreglar / solucionar el problema?
- ¿Alguien tiene alguna sugerencia sobre si el autor original del documento es correcto y qué puedo hacer para probar la teoría?
Lamentablemente, no puedo publicar el código ya que el código de serie está estrechamente relacionado con el resto del sistema, aunque si tienes preguntas al respecto puedo responder preguntas al respecto.
Actualizaciones:
- El código está escrito usando rutinas de Comandos de Win32, entonces estoy usando CreateFile, ReadFile. También hay llamadas juiciosas a GetOverlappedResult.
- No está colgando per se, es solo que las comunicaciones se detienen. Puede acceder a los menús, hacer clic en los botones, pero nada puede interactuar con el hardware conectado. Al usar el término real , puede ver que no ingresan o salen datos.
- Creo que la referencia al mensaje de Windows es que el problema es interno a Windows. Los datos han llegado pero el Kernal no lo ha visto y por lo tanto no se lo contó al resto del sistema.
- El control de flujo no se usa.
- Escribir una prueba "simple" es difícil debido al hecho de que el código está estrechamente acoplado y el protocolo subyacente es bastante complejo y requeriría mucho trabajo.
¿Estás seguro de que tienes tu control de flujo configurado correctamente? DTR, RTS, etc ...
-Adán
He escrito aplicaciones que usan puertos serie usb / bluetooth y nunca he tenido un problema. con Bluetooth he visto velocidades de bits (sostenidas) de 800,000 bps durante largos períodos de tiempo. la mayoría de las personas no implementan correctamente el puerto.
No estoy seguro si esto es una posibilidad para usted, pero si pudiera volver a escribir el código usando C # .NET, tendría acceso a la clase SerialPort allí. Podría remediar tu problema. Sé que una gran cantidad de código heredado basado en la API Win32 para puertos de E / S de hardware tendía a fallar en XP debido a la temporización (tenía un poco de experiencia con MIDI).
Además, no sé si puede usar el método Win32 de acceso al puerto serie en Vista, por lo que podría impedir que futuros sistemas operativos MS puedan usar su código.