Windows XP integrado: problemas RS485

Question

Tenemos un sistema que ejecuta XP integrado, y COM2 es un puerto RS485 de hardware.

En mi código, estoy configurando el DCB con RTS_CONTROL_TOGGLE . Supongo que eso haría lo que dice ... apague RTS en modo kernel una vez que ocurra la interrupción de escritura vacía. Eso debería ser prácticamente instantáneo.

En cambio, vemos en un ámbito que la PC está conduciendo el bus en cualquier lugar de 1-8 milisegundos más que el final del mensaje. El dispositivo con el que estamos hablando responde en aproximadamente 1-5 milisegundos. Entonces ... la corrupción de las comunicaciones en abundancia. No, no hay forma de cambiar el tiempo de respuesta del objetivo.

Ahora nos hemos conectado al puerto RS232 y hemos conectado el osciloscopio a las líneas TX y RTS, y estamos viendo lo mismo. La línea RTS permanece alta de 1 a 8 milisegundos después de que se envía el mensaje.

También hemos intentado apagar el FIFO, o establecer las profundidades FIFO en 1, sin ningún efecto.

¿Alguna idea? Estoy a punto de intentar controlar manualmente la línea RTS desde el modo de usuario con prioridad REALTIME durante el "Enviar archivo", borrar RTS " ciclo. No tengo muchas esperanzas de que esto funcione tampoco. Esto no debe hacerse en modo de usuario.

Answer 1

RTS_CONTROL_TOGGLE no funciona (tiene un retraso variable de 1-15 milisegundos antes de apagarlo después de la transmisión) en nuestra plataforma XP integrada. Es posible que lo reduzca si altero el tiempo cuántico a 1 ms usando timeBeginPeriod (1), etc., pero dudo que sea confiable o suficiente para importar. (El dispositivo responde @ 1 milisegundo a veces)

La solución final es realmente fea pero funciona en este hardware. No lo usaría en nada donde el hardware no esté fijo en piedra.

Básicamente:

1) establezca los FIFO en la página del administrador de dispositivos del puerto serie en desactivado o con 1 carácter de profundidad

2) envíe su mensaje + 2 bytes adicionales utilizando este código:

int WriteFile485(HANDLE hPort, void* pvBuffer, DWORD iLength, DWORD* pdwWritten, LPOVERLAPPED lpOverlapped)
{
  int iOldClass = GetPriorityClass(GetCurrentProcess());
  int iOldPriority = GetThreadPriority(GetCurrentThread());
  SetPriorityClass(GetCurrentProcess(), REALTIME_PRIORITY_CLASS);
  SetThreadPriority(GetCurrentThread(), THREAD_PRIORITY_TIME_CRITICAL);

  EscapeCommFunction(hPort, SETRTS);

  BOOL bRet = WriteFile(hPort, pvBuffer, iLength, pdwWritten, lpOverlapped);

  EscapeCommFunction(hPort, CLRRTS);

  SetPriorityClass(GetCurrentProcess(), iOldClass);
  SetThreadPriority(GetCurrentThread(), iOldPriority);

  return bRet;
}

El WriteFile () regresa cuando el último byte o dos se han escrito en el puerto serie. Todavía NO han salido del puerto, por lo tanto, necesitan enviar 2 bytes adicionales. Uno o ambos serán destruidos cuando hagas CLRRTS.

Como dije ... es feo.

Answer 2

  

¿Alguna idea?

Puede encontrar que hay un código fuente para el controlador del puerto serie en el DDK, lo que le permitirá ver cómo se supone que se implementará esa opción, es decir, si está en el nivel de interrupción, en el nivel de DPC o peor.

Otras posibilidades incluyen reescribir el controlador; utilizando un controlador RS485 de terceros si puede encontrar uno; o el uso de hardware RS485 de terceros con su propio controlador (por ejemplo, al menos en el pasado, terceros fabricaban `` placas de puerto serie inteligentes '' con 32 puertos, buffers profundos y su propio microprocesador; espero que RS485 sea un problema sido resuelto por alguien).

8 milisegundos parece un tiempo decepcionantemente largo; Sé que XP no es un RTOS, pero espero que (generalmente) lo haga mejor que eso. Otra cosa a tener en cuenta es si hay otros subprocesos de alta prioridad en ejecución que pueden estar interfiriendo. Si ha estado aumentando las prioridades de algunos hilos en su propia aplicación, quizás debería reducir las prioridades de otros hilos.

  

Estoy a punto de intentar controlar manualmente la línea RTS desde el modo de usuario con prioridad REALTIME durante el " SendFile, borre RTS " ciclo.

No permita que ese hilo se salga de control: IME un hilo como ese si tiene errores para evitar cualquier otro hilo en modo de usuario para siempre.