Добрый день. При попытке обмена по эмулированому COM порту получаю ошибку "WriteFile function failed (Error: 433)".
Не могу найти, что это за ошибка. Подскажите, пожалуйста, кто в курсе.
Уважаемые авторы вопросов! Большая просьба сообщить о результатах решения проблемы на этой странице. Иначе, следящие за обсуждением, возможно имеющие аналогичные проблемы, не получают ясного представления об их решении. А авторы ответов не получают обратной связи. Что можно расценивать, как проявление неуважения к отвечающим от автора вопроса.
26-02-2020 04:15 | Комментарий к предыдущим ответам
Вас задело? Извините. Просто устаю повторять, что СОМ-порт всего навсего СДВИГОВЫЙ РЕГИСТР. Причем тактовые импульсы на сдвиг подаются через ключ. ВСЕ АБСОЛЮТНО настройки работы железа прописываются в железо, которое (если указано) выставляет прерывания и не более того. Начиная с 32-х разрядов, API позволяет полностью контролировать работу СОМ-порта, добиваясь максимально того, на что он способен.
Программа-эмулятор, которая просто плюется в порт с заданным темпом и скоростью не взирая ни на что, и при этом переполняет свой буфер, НАПИСАНА НЕВЕРНО. Предполагаю, что методом тупого таймера. А должна использовать евент TX_EMPTY и отдельный поток обработки всех эвентов (из числа Вами же разрешенных). Обрабатывая этот эвент, Вы ОДНОЗНАЧНО НИКОГДА не забьете свой буфер передачи.
Что касается "15 лет ..." - то это очень даже повод, и даже больше того - обязанность не поучать, а объяснять, что Вы не первый и не последний, кто наступает на грабли. При том при сем, что железо за последние 25 лет точно не менялось, а с приходом 32-х разрядов не менялись и драйвера.
Если же Вы работаете с USB/COM, то по личному опыту из трех брендов конца прошлого века пришлось выкинуть два под конкретную задачу. Устойчиво работал только один. Но опять же... Задача была работать в темпе около 57600 и скорости 115200. Согласитесь, что мало железа, которое бы требовало таких скоростей.
To Василий. Видите ли какое дело... С чего это вы в своих сообщениях вы используете такой поучительный тон? нормальные программы все-таки не плюются как верблюд, а все-таки "общаются". Да? А вот программа, которая эмулирует поведение аппаратуры передающей телеметрию (аппаратуре не нужна, при этом, обратная связь), она как нормальная или нет? Настройки НЕ ждать DSR или CTS. Иногда возникает переполнение если программа "приемник" не принимает данные. При чем именно не всегда так, и не для всех эмуляторов. Драйвера то люди пишут, что там у них не так в драйвере смысла разбираться нет, просто такой факт имеет место быть. Если кто-тоза лет 15-ть активного программирования ПО с подобным железом НИ РАЗУ такой ошибки не получал это не повод тут других поучать.
18-12-2019 11:31 | Комментарий к предыдущим ответам
Видите ли какое дело... Как только Вы настройками порта указываете драйверу "наплевать на состояние приемника" (в переводе на нормальный язык программиста железа - не взирая на состояние модемных линий), то в драйвере никак не может переполнится буфер, если Вы конечно не будете тупо копипастить код откуда только можно. Допускаю единственную возможность некоего переполнения буфера, если при установленном размере буфера в 1 кб, Вы попытаетесь записать в порт 1 мб. Но это не будет переполнением буфера - API порта возвратив Вам фэлс, как бы скажет ... я думаю расшифровывать не нужно. При открытии же порта на приемной стороне и полном отсутствии желания читать принятое, не смотря на эвенты - буфер просто будет перезаписываться (правда помню такое только под 16-ти разрядными Виндами - там API был скуден до невозможности).
Все мои рассуждения касаются случаев, когда код автору понятен, не смотря на копи-паст, автор понимает механизм работы компонента обслуживающего порт...
Случаи кода типа
WriteFile(...);
while not ReadFile(...) do
Sleep(1000);
17-12-2019 23:42 | Комментарий к предыдущим ответам
To Василий.
Александр Малыгин высказал предположение о переполнении буфера в драйвере. Из вашего же первого комментария у задающего вопрос может сложится такое впечатление, что буфер никак не может переполнится, хотя бы потому, что за лет 15-ть активного программирования ПО с подобным железом НИ РАЗУ такой ошибки не получал.
Это конечно прекрасно, но смысл моего комментария был в том, что я лично с такой проблемой сталкивался (и это пока не важно как там настроены DSR и CTS), так что задающему вопрос все же я думаю полезно не сбрасывать эту версию со счетов и потом уже разбираться с DSR и CTS при необходимости. Что же касается моей программы, то я, естественно не настраиваю сом порт непосредственно, в том смысле что вызываю CreateFile(). Я использую компонент, у которого кстати в есть настраиваемое свойство FlowControl в котором соответствующие флаги OutCtsFlow и OutDsrFlow равны false, при этом сообщение о переполнении буфера для некоторых устройств может возникать.
18-11-2019 23:06 | Комментарий к предыдущим ответам
2 W0lt
Это каким образом на Вашем компе может переполняться буфер, если "железяка" не читает отправленное Вашей программой? Да очень просто. Ваша программа НИ ХРЕНА не отправляет ничего, это делает драйвер порта. Ваша программа настроила его так, чтобы он ждал DSR или CTS, которые просто некому выставить - "железяка" отсутствует физически, или у нее даже нет концов DTR или RTS. Ясен пень, что буфер переполнится. Можете еще открыть буфер в 1 кБ, а "плюнуть" пакет в 1 мБ. Правда тут варианты. Не знаю как работает драйвер порта в виндах старше 7-ки.
Проблема переполнения буфера совершенно точно может возникать, если со второй стороны данные не читаются. По своей работе имею немалый опыт работы с разными устройствами. Например такая проблема бывает с USB to RS-232 устройствами. В сообщении об ошибке правда так и пишут что то типа "outpt buffer is full".В чистых эмуляторах, кстати не сталкивался, наоборот в том эмуляторе, что использую сейчас когда создаю bridge COM2-COM3 (например) для обмена двух программ по COM, как раз можно не парится если принимающая не запущена, при использовании же USB to RS-232 обязательно проблема возникнет, поэтому для отладки как раз и использую эмулятор. Но что там у автора за эмулятор, мы же не знаем, вполне возможно, у него буфер и переполняется.
16-11-2019 08:11 | Комментарий к предыдущим ответам
Я пользовался сом0сом... Простенький сниффер на втором порту и СОМ1 (например) с реальной железкой. Фирменную программу вешаешь на первый порт, и дело в шляпе... Но мне даже в голову не приходило, не застартовав сниффер запускать фирменную программу. Опять же нормальные программы все-таки не плюются как верблюд, а все-таки "общаются".
15-11-2019 14:09 | Комментарий к предыдущим ответам
Василий, я по фразе автора "При попытке обмена по эмулированому COM порту" понял, что речь идёт о полной эмуляции компорта, т.е. когда за драйвером вообще никакого устройства нет. Как например, драйвер com0com.
Компорт, созданный таким драйвером, можно открыть, а спаренный с ним другой такой компорт - не открывать, и тогда со стороны первого возможно переполнение буфера, если программа плюётся в компорт.
Возможно, моя догадка неверна, но автор не соизволил объясниться.
15-11-2019 11:50 | Комментарий к предыдущим ответам
И причем тут другая сторона? Разве автор что-то сказал про модемные концы? Если в настройках ничего нет про DTR и RTS - вряд ли драйвер при передаче интересуется состоянием DSR CTS, поэтому он "плюется как верблюд" и ему глубоко ... на другую сторону. Типа как UDP - "у нас ушло, а у вас проблемы".
Без кода настройки порта и кода записи/чтения трудно что-то сказать... хотя бы потому, что за лет 15-ть активного программирования ПО с подобным железом НИ РАЗУ такой ошибки не получал.
Если вы заметили орфографическую ошибку на этой странице, просто выделите ошибку мышью и нажмите Ctrl+Enter. Функция может не работать в некоторых версиях броузеров.
