Windows XP embedded - проблемы с RS485

Question

У нас есть система под управлением встроенной XP, а COM2 является аппаратным портом RS485.

В моем коде я настраиваю DCB с помощью RTS_CONTROL_TOGGLE.Я бы предположил, что это будет делать то, что там написано...отключите RTS в режиме ядра, как только произойдет прерывание write empty.Это должно произойти практически мгновенно.

Вместо этого мы видим в области видимости, что компьютер управляет шиной на 1-8 миллисекунд дольше, чем заканчивается сообщение.Устройство, с которым мы разговариваем, отвечает примерно через 1-5 миллисекунд.Итак...коррупция в коммуникациях изобилует.Нет, нет никакого способа изменить время отклика цели.

Теперь мы подключились к порту RS232 и подсоединили оптический прицел к линиям TX и RTS, и мы видим то же самое.Линия RTS остается высокой через 1-8 миллисекунд после отправки сообщения.

Мы также пытались отключить FIFO или установить глубину FIFO равной 1, но безрезультатно.

Есть какие-нибудь идеи?Я собираюсь попробовать вручную управлять строкой RTS из пользовательского режима с приоритетом в реальном времени во время цикла "Отправить файл, очистить RTS".У меня тоже не так много надежд на то, что это сработает.Это не должно быть сделано в пользовательском режиме.

Answer 1

RTS_CONTROL_TOGGLE не работает (имеет переменную задержку в 1-15 миллисекунд перед отключением после передачи) на нашей встроенной платформе XP.Возможно, я смог бы уменьшить это, если бы изменил квант времени на 1 мс, используя timeBeginPeriod (1) и т.д., Но я сомневаюсь, что это было бы надежно или достаточно важно.(Иногда устройство реагирует с интервалом в 1 миллисекунду)

Окончательное решение действительно уродливое, но оно работает на этом оборудовании.Я бы не стал использовать его ни на чем, где оборудование не закреплено в камне.

В основном:

1) установите значение FIFOs на странице диспетчера устройств последовательного порта в положение выкл. или глубиной в 1 символ

2) отправьте свое сообщение + 2 дополнительных байта используя этот код:

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;
}

Функция WriteFile() возвращается, когда последний или два байта были записаны в последовательный порт.Они еще НЕ вышли из порта, поэтому необходимо отправить 2 дополнительных байта.Один или оба из них будут уничтожены, когда вы будете выполнять CLRRTS.

Как я уже сказал...это некрасиво.

Answer 2

  

Есть идеи?

Вы можете обнаружить, что в DDK есть исходный код драйвера последовательного порта, который позволит вам увидеть, как предполагается реализовать эту опцию: то есть, на уровне прерывания, на уровне DPC или хуже.

Другие возможности включают переписывание драйвера; использование стороннего драйвера RS485, если вы можете его найти; или использование стороннего оборудования RS485 с его собственным драйвером (например, по крайней мере, в прошлых 3-х сторонах, использовавшихся для создания «интеллектуальных плат последовательных портов» с 32 портами, глубокими буферами и собственным микропроцессором; я полагаю, что проблема RS485 заключается в том, что была решена кем-то).

8 миллисекунд действительно удручающе долго; Я знаю, что XP не является ОСРВ, но я ожидаю, что она (обычно) будет лучше, чем эта. Еще одна вещь, на которую стоит обратить внимание, это наличие других высокоприоритетных потоков, которые могут создавать помехи. Если вы повышаете приоритеты некоторых потоков в своем собственном приложении, возможно, вместо этого вам следует уменьшить приоритеты других потоков.

  

Я собираюсь попробовать вручную управлять линией RTS из пользовательского режима с приоритетом REALTIME во время " SendFile, clear RTS " цикл.

Не позволяйте этому потоку выйти из-под контроля: IME такой поток может, если он глючит, вытесняет любой другой поток пользовательского режима навсегда.