Depuración RS232: Adaptador USB Vitrual para PC vs puerto COM verdadero

1

Quiero comparar el tráfico RS232 entre dos escenarios. Siéntase libre de omitir el fondo y saltar directamente a los registros de tráfico. ¿Alguien puede explicarme por qué puedo ver las diferencias en estos escenarios?

Historial
He estado tratando de depurar algunos problemas de comunicación RS232 entre un dispositivo de hardware muy heredado y una aplicación que se ejecuta en una PC con Win98. Las comunicaciones entre esta PC y el dispositivo funcionan perfectamente, pero no he podido obtener éxito con ninguna otra configuración (virtualización, adaptador de puerto USB Com).

Voy a recortar la mayor parte de la historia como sea posible. Tengo una aplicación que se ejecuta en una PC virtual Win98SE (Microsoft) y en un hardware físico que ejecuta Win98SE.

En el lado de Virtual PC, estoy reenviando el tráfico COM2 a un puerto COM físico, que es un adaptador de puerto COM USB.

Después de deshabilitar los buffers FIFO, el puerto parece funcionar sin problemas. Puedo transferir archivos entre la PC con Win98SE real y la Máquina Virtual a través del puerto COM usando HyperTerminal.

Hice un análisis de PortMon y descubrí que la aplicación envía repetidamente un conjunto particular de bytes, al enviar esta secuencia de bytes al hardware, recibo cantidades variables de datos que me envían de vuelta.

Sin embargo, cuando ejecuto la aplicación en Virtual PC, observo que la aplicación no se comunica con el hardware, informa errores de comunicación, no actualiza datos, etc.

Registros de tráfico
Al ejecutar PortMon en la PC real, obtengo esta secuencia de comunicación típica (esto funciona):

19  2:17:20 PM  COMAPP  VCOMM_WriteComm COM2    SUCCESS Length: 4: 81 02 00 7E  
20  2:17:20 PM  COMAPP  EventNotifyProc COM2    VOID    : TXEMPTY   
21  2:17:20 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS EVENT   
22  2:17:20 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
23  2:17:20 PM  COMAPP  EventNotifyProc COM2    VOID    : RXCHAR    
24  2:17:20 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS RECEIVE     
25  2:17:20 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
26  2:17:20 PM  COMAPP  VCOMM_ReadComm  COM2    SUCCESS Length: 1: 06   
27  2:17:20 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS NONE    
28  2:17:20 PM  COMAPP  VCOMM_WriteComm COM2    SUCCESS Length: 4: 80 02 00 7F  
29  2:17:20 PM  COMAPP  EventNotifyProc COM2    VOID    : TXEMPTY   
30  2:17:20 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS EVENT   
31  2:17:20 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
32  2:17:20 PM  COMAPP  EventNotifyProc COM2    VOID    : RXCHAR    
33  2:17:20 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS RECEIVE     
34  2:17:20 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
35  2:17:20 PM  COMAPP  VCOMM_ReadComm  COM2    SUCCESS Length: 1: 06   
36  2:17:20 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS NONE    

Al ejecutar PortMon en la PC virtual, obtengo esta secuencia de comunicaciones (esto no funciona):

21  4:56:30 PM  COMAPP  VCOMM_WriteComm COM2    SUCCESS Length: 4: 81 02 00 7E  
22  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
23  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
24  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
25  4:56:30 PM  COMAPP  EventNotifyProc COM2    VOID    : TXEMPTY   
26  4:56:30 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS EVENT   
27  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
28  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
29  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
30  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
31  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
32  4:56:30 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
33  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
34  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
35  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
36  4:56:32 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS NONE    
37  4:56:32 PM  COMAPP  VCOMM_WriteComm COM2    SUCCESS Length: 4: 80 02 00 7F  
38  4:56:32 PM  COMAPP  EventNotifyProc COM2    VOID    : TXEMPTY   
39  4:56:32 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS EVENT   
40  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
41  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
42  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
43  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
44  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
46  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
47  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
48  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
49  4:56:32 PM  COMAPP  VCOMM_ClearCommError    COM2    SUCCESS NOERROR 
50  4:56:32 PM  COMAPP  VCOMM_GetCommEventMask  COM2    SUCCESS NONE    

Hay algunas diferencias obvias: 1. La aplicación virtualizada borra excesivamente los errores de comunicación, cuando no parecen existir. 2. La aplicación virtualizada nunca recibe RXCHAR y, por lo tanto, nunca lee el 06.

Soy muy nuevo en este tipo de análisis, pero inmediatamente se me ocurre que algunas de las señales (CTS, RTS, DSR, DTR, etc.) pueden no funcionar con un adaptador COM USB, y quizás La aplicación requiere estas señales. Nuevamente, no soy un experto, tal vez estas señales siempre sean necesarias.

Si utilizo IONinja para conectarme al hardware y envío los mismos bytes que estoy capturando arriba, obtengo la respuesta 06 (entre otras respuestas), pero la aplicación no reconoce esto.

Encontré esta pregunta, pero no responde a mi pregunta:
Desventajas de USB a RS232 dongles

Actualizar
En la sugerencia / dirección de @Chris Knudsen, he creado un pequeño detector de hardware:

Resulta que Chris estaba en lo cierto. Portmon no me hablaba de todo el tráfico.

Mirando la comunicación Rx, luego la comunicación Tx, puedo ver que toda la comunicación se está produciendo como se esperaba. Sin embargo, el tiempo puede estar comprometido. Parece que para funcionar lo más rápido posible, se codificó para rechazar la información entregada fuera de sincronía de las solicitudes de sondeo.

En una inspección más cercana, veo que el software funciona parcialmente, con un estado de comunicación que alterna entre "error" y "no error" y algunos datos son parcialmente visibles.

En conclusión, el adaptador USB es lo que está cayendo aquí.
Consolación: ¡Me encanta mi nuevo sniffer COM de hardware!

    
pregunta Gorchestopher H

1 respuesta

0

En la sugerencia / dirección de @Chris Knudsen, he hecho un pequeño rastreador de hardware:

ResultaqueChrisestabaenlocierto.Portmonnomehablabadetodoeltráfico.

MirandolacomunicaciónRx,luegolacomunicaciónTx,puedoverquetodalacomunicaciónseestáproduciendocomoseesperaba.Sinembargo,eltiempopuedeestarcomprometido.Parecequeparafuncionarlomásrápidoposible,secodificópararechazarlainformaciónentregadafueradesincroníadelassolicitudesdesondeo.

Enunainspecciónmáscercana,veoqueelsoftwarefuncionaparcialmente,conunestadodecomunicaciónquealternaentre"error" y "no error" y algunos datos son parcialmente visibles.

En conclusión, el adaptador USB es lo que está cayendo aquí. Consolación: ¡Me encanta mi nuevo sniffer COM de hardware!

    
respondido por el Gorchestopher H

Lea otras preguntas en las etiquetas