[win32]COM-порт
это проявляется везде и всегда?
или на конкретной машине при подключение конкретной железки?
или на конкретной машине при подключение конкретной железки?
Не всегда, это проявляется только у моей проги 
Комбинированием волшебных флажков (CTS/DSR) один раз удалось считать из порта, но как воспроизвести - непонятно.

Комбинированием волшебных флажков (CTS/DSR) один раз удалось считать из порта, но как воспроизвести - непонятно.
Стандартные примеры на чтение из com-порта тоже теряют данные в твоем случае?
Бывает.
Порт сам не стандартный (Bluetooth).
Порт сам не стандартный (Bluetooth).
Бывает - это значит, всё происходит в зависимости от настроек блютусной проги.
Комбинированием волшебных флажков (CTS/DSR)А ты не думал почитать, что эти флажки означают? Очевидно, кто-то их использует зачем-то. Где-то, наверное, есть стандартный протокол, типа, принимающий должен выставить CTS (clear to send посылающий должен послать что-нибудь и выставить DTR (data ready потом что-нибудь ещё должно произойти.
ЗЫ: Я, кстати, не понял, кто пишет, а кто читает, и причём тут блютус =)
блютус через com ?
или com через блютус ?
или com через блютус ?
очевидно, драйвер для блютуфа эмулирует компорт номер 3, автор треда пытается с помощью своей программы писать/читать байты в/из COM3.
Вопрос: что пытается вычитать из КОМ3 программа? данные которые отправило другое блютуф устройство? или у устройства есть режим loopback и автор программы пытается вычитать из КОМ3 записанные туда байты?
Если потеря байт происходит только непосредственно после открытия порта (CreateFile то возможно драйвер производит асинхронный Flush через некоторое время после открытия порта и если WriteFile вызывается раньше, чем происходит этот Flush - потери байт могут происходить.
Вопрос: что пытается вычитать из КОМ3 программа? данные которые отправило другое блютуф устройство? или у устройства есть режим loopback и автор программы пытается вычитать из КОМ3 записанные туда байты?
Если потеря байт происходит только непосредственно после открытия порта (CreateFile то возможно драйвер производит асинхронный Flush через некоторое время после открытия порта и если WriteFile вызывается раньше, чем происходит этот Flush - потери байт могут происходить.
Я про режим loopback ничего не слышал, на самом деле, просто старался делать так, как делает hyperterminal.
Флажок rts control, установленный в ноль, даёт то, что было выше. Сейчас все окей.
Флажок rts control, установленный в ноль, даёт то, что было выше. Сейчас все окей.
Оставить комментарий
evgen5555
Вопрос - почему байты, записанные в порт сразу после открытия, "съедаются", т.е. Read не может прочитать то, что записано?0.00761214 PhoneConn.exe IRP_MJ_WRITE Serial3 SUCCESS Length 1: 54
0.00236427 PhoneConn.exe IOCTL_SERIAL_GET_COMMSTATUS Serial3 SUCCESS
5.00774177 PhoneConn.exe IRP_MJ_READ Serial3 TIMEOUT Length 0: