Ошибка виртуальной COM-связи

Question

Я работаю над драйвером класса коммуникационных устройств (CDC) для встроенного устройства, Полная скорость реализация USB 2.0. Настройки COM-порта: 115200, 8 бит, без контроля четности, 1 стоповый бит, без управления потоком. Наше приложение для ПК (32-разрядное, Windows 7, .NET 2.0) взаимодействует с целевым устройством через виртуальный COM-порт, который на целевом устройстве может подключаться либо к микросхеме FTDI (USB-to-SCI bridge), либо к встроенному USB-интерфейсу периферийного в микроконтроллере, в зависимости от того, какой порт выбран приложением.

Оба виртуальных COM-порта работают без проблем с помощью Realterm. Однако, хотя наше настольное приложение работает с использованием виртуального COM-порта, подключенного через чип FTDI, он зависает при попытке использовать виртуальный COM, подключенный через встроенную периферийную периферию USB микроконтроллера.

При подключении через виртуальный COM-порт с использованием встроенного USB приложение последовательно зависает при втором вызове SerialPort.Write(...). Используя Serial Monitor from HHD Software, я вижу, что данные передаются при первом вызове SerialPort.Write(...). Однако эти данные никогда не принимаются целевым устройством.

Это странно, потому что единственный раз, когда я видел подобные проблемы в предыдущих проектах, было когда несоответствие настроек управления потоком по каждой стороне шины.

Дополнительная информация ...

---

Вот данные, захваченные из различных портовых средств мониторинга во время работы нашего приложения ПК, подключенного к целевому устройству с помощью интегрированной USB периферии. Любое понимание было бы оценено.

• Sysinternals Portmon
• Advanced USB Port Monitor
• Device Monitoring Studio - Request View
• Device Monitoring Studio - Packet View

Для тех, кто заинтересован, я использую CodeWarrior 10.2 с MCF51JM128 от Freescale.

---

Любые идеи или предложения будут оценены. Благодарю.

Answer 1

Из журналов видно, что вы делаете классическую ошибку, не заботясь об аппаратных сигналах подтверждения. Это когда-либо срабатывает случайно, эмулятор терминала, такой как Realterm, никогда не допустит этой ошибки.

Вы должны установить для свойства DtrEnable значение true. Это включает сигнал готовности терминала данных. Это важно, потому что RS-232 - это неиспользуемая шина, поэтому при отключении кабеля или отключении питания возникают электрические помехи. DTR убеждает устройство в том, что он фактически подключен к устройству с питанием. Это, конечно, эмулируется в вашем случае, но драйвер или прошивка по-прежнему будут обычно выполнять поведение RS-232.

И свойство RtsEnable важно, используется для установления связи с устройством и предотвращения переполнения буфера приема, когда приложение не опорожняет буфер своевременно. Вы действительно должны установить свойство Handshake в Handshake.RequestToSend, наиболее распространенный способ его реализации. Который тогда также заботится о том, чтобы включить RTS. Если вам нужно использовать Handshake.Нет по какой-то причине, то у вас есть, чтобы включить его, установив RtsEnable в true.

Это должно решить проблему. Если у вас все еще есть проблемы, используйте PortMon, чтобы следить за тем, как Realterm инициализирует драйвер. Сравните команды, которые вы видите, с командами, которые отправляет класс SerialPort. Убедитесь, что они одинаковые. В значении не в последовательности.