Проверяю UART некоторого устройства через компьютер. Программа написана на C++ билдере под ХР. Прием - передача в принципе работает. Компьютер посылает блок данных, устройство в ответ шлет свой блок, комп его принимает. Программа при этом работает исключительно в синхронном режиме: пошлет пакет, ожидает ответного пакета.

Но есть еще отдельный режим, когда устройство посылает поток байт, а компьютер ничего с ними не делает. После этого программа перестает работать. Выяснил что это происходит из за переполнения приемного буфера, но вылечить это не могу. Не помогает ни вызов ClearCommError, ни закрытие-открытие порта. Да и не может помочь, т.к. в пошаговой отладке выяснилось что переменная в которой хранился дескриптор порта (полученный вызовом CreateFile) - затирается. Т.е. я в принципе не могу работать с портом. Пробовал устранить переполнение присвоением false в переменной dcb->fAbortOnError - не помогло.
Что еще посоветуете?

Посоветую увеличить размер буфера (можно входного и выходного сразу).

Делается это фукцией API:
SetupComm(COMhandle, InBufSize, OutBufSize);
Только, чур, нечетных размеров не задавать, и длиннее, чем 65634 тоже поостеречься (нет у меня уверенности, что третий байт не откусит).

Нет, не годится. Количество мусора, который может прийти неограничено. Буфер любого размера все равно когда то переполнится.

Буфер (тот, который по SetupComm заводится) самоочищается на столько байт, сколько вы читаете из COM-порта.

Ну, а если вы открыли COM-порт, как файл, и погнали в него с внешнего устройства информацию, а средства оперативного чтения (хотя бы раз в секунду) не предусмотрели, то вы сами себе злобный Буратино .

Обычно на таймер (ПК-шный) нагружают процедуру, которая периодически с каким-то постоянным периодом читает из СОМ-порта и хотя бы на диск эти данные пишет, если сама не знает, что с ними делать. Буфер не хранилка данных, а лишь средство, чтобы продержаться (не потерять данные) между их поступлением в ПК и чтением их из программы.

Таймер там не нужен потому что алгоритм работы предельно простой: программа послала блок и тут же приняла ответный блок уже известной длины.
Ввести таймер можно, но это мне кажется слишком тяжеловесным решением. Надо еще следить чтоб таймер не вмешался в прием нужных данных.
Можно между посылками закрывать порт и открывать когда нужно послать очередной раз. Но это тоже много лишних действий - после очередного открытия надо настраивать таймауты, режимы через dcb. Вот если бы можно было переводить порт как бы в спячку, чтоб он временно ничего не принимал. Но как это сделать я не знаю.
И еще я не понимаю почему простое переполнение приводит к таким последствиям что забиваются переменные. Может это тоже можно как то устранить?

1. Попробуйте всегда перед началом работы с портом выполнить PurgeComm.
2. Не думаю что виндовский буфер может что то затирать кроме себя. Неужели Вы думаете что винда может не контролировать переполнение буфера и что то там затирать?

Мне не понятно ваше возражение о том, что "Буфер любого размера все равно когда-то переполнится". С чего бы ему вдруг переполняться, если вы посылки регулярно забираете? Этот буфер FIFO, и переполниться он может только если посылки будут приходить, а получать вы их не будете. Если вы наотрез отказываетесь использовать SetComm для установки размера буфера, то буфер все равно будет, только по умолчанию в 16 байт. Влезает в них ваша посылка?

На ваш вопрос я уже ответила (или попыталась ответить) советом увеличить размер буфера. Если вы знаете размер посылки, то сделайте размер приемного буфера раз в 10 больше, чем этот размер. А еще лучше, поставьте 30000 и проверьте, пропал ваш синдром или нет.



Винда не обязана заполнять всю свою память или писать на диск всю ту муру, что приходит на СОМ-порт. Она складирует "неполученные отправления" до тех пор, пока не кончится место в заказанном программой (которая тот СОМ-порт открыла) буфере. Эти данные уже не пропадут, но попадут те, которые пришли вслед за ними, и которым места в буфере нехватило.

Это Вы к чему???
Я с Вами полностью согласен.
Но ТС пишет :

Т.е. ТС считает что в программе что то "забивается", "затирается" именно из за переполнения буфера.

Не получится. После переполения теряется дескриптор, а он нужен в том числе и для PurgeComm.

Честно - совсем так не думал. Но это происходит и я не могу понять почему.



Забираю я из буфера не регулярно. А ненужные посылки идут непрерывно.
Ситуация такая. Есть посылки которые шлет компьютер по нажатию мышкой, и получает тут же ответ. Это все работает. А можно переключить пульт в автономный режим. И в этом режиме в компьютер непрерывно шлется мусор. Компьютер в это время ничего не делает, но буфер его наполняется мусором. И количество мусора ничем не ограничено.


Да хоть в 1000 раз, все равно он теоретически может переполниться, я уже сказал что такой вариант мне не подходит.

НЕ ВЕРЮ. Как такое возможно!!! Не должно такого быть!!!

Но подумайте, что вы такое пишете? Дескриптор в винде - это указатель, которая винда дает вам при открытии прота. Вы его храните у себя, как он может потеряться? Разве что ваша программа неловким движением что-то пишет в ту ячейку, куда вы положили этот указатель.

Ну не знаю, просто говорю что вижу в отладчике. А я этот дескриптор не трогаю. Да и происходит это во время когда моя программа ничего не делает, но в порт летит мусор. Завтра еще перепроверю.
Ну а как бы временно приостановить прием есть варианты?

дубль. сорри.

Прием останавливается сам, как раз при переполнении буфера (при этом порт переходит в состояние ошибки). Затираться ничего нигде не должно.
Ищите ошибку у себя в программе. Скорее всего вы не обрабатываете ошибки, которые функции работы с портом будут возвращать после переполнения буфера.

Открыли порт - на куче появился дескриптор. Задали буфер - он лег рядом. Пошли писать - вышли за пределы и затерли соседние данные.
Никто за вас не обязан отслеживать границы массивов.


У себя - это где?
А буфер где?