Чтение из COM порта

@d7d1cd · Регистрация: 30.06.2011

Студворк — интернет-сервис помощи студентам

Приветствую всех! Для чтения из COM порта использую функцию ReadFile. Третьим параметром в данной функции указывается число байт для чтения. Ранее работая с COM портом я точно знал какое количество байт мне нужно читать из порта. Сейчас в проектируемом приложении я не могу знать сколько байт придет.

Возможно ли выполнить чтение из порта так, что если в порт совсем не придут данные, то функция ReadFile ждет какое-то время (я так понимаю, оно настраивается через таймауты порта) и прекращает работу. Если же в порт приходят данные, то чтение продолжается до тех пор, пока данные приходят. Как только поступление данных прекращается, функция должна завершить свою работу.

@d7d1cd · 22.08.2016, 14:59 **[ТС]**

c0rvax, после долгих раздумий решил попробовать реализовать чтение по Вашему совету. Сейчас компилятора под рукой нет, поэтому пока напишу код здесь для оценки его специалистами

. Контроль ошибок опускаю.

C++
1
2
3
4
5
6
7
8
9
10
11
PurgeComm(... // Сбрасываю буфер ввода-вывода COM порта
WriteFile(...  // Отправляю запрос в COM порт
 
// Жду поступления данных в COM порт 1 секунду:
for(DWORD time = GetTickCount(); GetTickCount() - time < 1000;)
 {
  ClearCommError(COMPort, &Errors, &ComState);
  if(ComState.cbInQue == expect) break; // Поступило ожидаемое число байт - прерываю цикл ожидания
 }
 
if(ComState.cbInQue) ReadFile(... // Если есть принятые байты, то читаю их

Прокомментируйте или укажите на ошибки, если таковые имеются.

@c0rvax · 22.08.2016, 16:11

d7d1cd, не совсем то, чтоб мне понравилось.

1) Нужен отдельный поток, чтоб не тормозил интерфейс, даже на секунду. Причём, Sleep(1) в цикле будет не лишним.
2) На момент чтения нужно обязательно знать, сколько байт ожидать в ответ. Опять не универсально. Например, есть устройства, которые шлют данные постоянно, и ожидать, что в СОМ-порт поступит чётко определённое количество байт неправильно. Ждём 5, пришло 4, а потом ещё 6, например.
3) Придётся после ReadFile разбираться, что же мы считали. Один пакет, полтора, ноль-пять или ещё что-то...

Нет, конечно, для конкретной реализации потянет, но подход тот же, только другой способ.

Мой вариант: крутим отдельный поток, проверяем, есть ли что на входе. Т.е., постоянно читаем из порта. Есть чё? Читаем всё в какой-нибудь контейнер. Вторая часть балета этот контейнер проверяет, вырезает распознанный пакет, оставляя "лишнее" для дополнения и выполняет необходимые действия над данными и отправляет очередную команду при необходимости. Естественно, контейнер должен быть потоконезависимым. Соорудить такой из стандартного, добавив критическую секцию труда не составит. Это будет практически универсально для любого обмена, с любой скоростью порта, с любыми устройствами.

@vxg · 22.08.2016, 16:34

Сообщение от c0rvax

Мой вариант

и сколько байт вы будете вычитывать за один вызов?

@c0rvax · 22.08.2016, 17:15

vxg, все, что есть (ComState.cbInQue)

@vxg · 22.08.2016, 17:22

c0rvax, а где у вас в коде получение этого значения? Во время очистки?

@c0rvax · 22.08.2016, 17:29

vxg, да. ClearCommError возвращает количество байт в буфере.

@vxg · 22.08.2016, 17:41

c0rvax, но в этом ли её назначение? Ошибку таким образом не пропустите?

@c0rvax · 22.08.2016, 17:58

vxg, эта функция так же и ошибки возвращает. Да и ReadFile так же вернёт ошибку. Думаю, что с этими ошибками программно не поборешься. Естественно, можно предусмотреть корректный выход и завершение работы.

@vxg · 22.08.2016, 18:01

c0rvax, Read после вызова этой функции не вернёт ошибку если она произошла до очистки поэтому кроме результата Read надо дополнительно проверять возврат из Clear

@c0rvax · 23.08.2016, 09:48

vxg, Read вернёт ошибку, если она произойдёт уже после "холостого" Clear. Или, если Clear реально только сбросит признак, но не решит проблему [что скорее всего и будет]. ТС уточнил, что контроль ошибок опускает, поэтому я не углубляюсь в детали. Разобраться бы с общим подходом к обмену...

@d7d1cd · 23.08.2016, 11:28 **[ТС]**

Вопрос. Если при приеме происходит какая-то ошибка, и была сначала вызвана функция ClearCommError, а потом ReadFile, то последняя завершится не удачно?

@vxg · 23.08.2016, 11:33

d7d1cd, нужно уточнить что значит при приеме. если ошибка будет во время работы ReadFile то ReadFile вернет ошибку. а если ошибка сама по себе безотносительно работы программы произошла до вызова ClearCommError то вызов ClearCommError ее очистит. были ли ошибки на момент вызова ClearCommError надо глядеть по возвращаемым этой функцией параметрам.

@d7d1cd · 23.08.2016, 13:14 **[ТС]**

Чувствую, что я не допонимаю работу COM порта...
Как я понимаю, когда какое-либо устройство передает данные в COM порт, это совершенно не зависит ни от каких функций. Данные просто поступают в буфер порта. Если при этом поступлении возникла ошибка, то тут все зависит от флага fAbortOnError структуры DCB. Если он true, то COM порт перестает принимать данные до тех пор, пока функция ClearCommError не очистит эту ошибку. Если же fAbortOnError = false, то прием продолжится. Если после этого не вызвать функцию ClearCommError, а сразу прочитать данные функцией ReadFile, то она завершится ошибочно. Все так или нет?

@c0rvax · 23.08.2016, 15:48

d7d1cd, трудно сказать. И поэкспериментировать вряд ли удастся. Слишком уж эти ошибки "аппаратные", вряд ли их удастся эмулировать. Мне кажется, что если очистить ошибку, а потом пробовать выполнить какие-то телодвижения, то Read вернёт ошибку, а Clear опять установит флаги. Я к тому, что если вдруг что-то перестало работать, то уже ничего не сделаешь, кроме как чинить оборудование, поэтому логичнее прекратить весь обмен и сделать выход.

@vxg · 23.08.2016, 16:48

d7d1cd, ну если верить фразе

No new read or write operations will be accepted until the application acknowledges the communications error by calling the ClearCommError function.

то после вызова ClearCommError попытки чтения могут быть удачными... если там конечно чип не расплавило)

@c0rvax · 23.08.2016, 17:43

Если так прикинуть, то

CE_BREAK (The hardware detected a break condition.) - аппаратная, ничего не сделаем
CE_DNS (Windows 95 only: A parallel device is not selected.) - исключена уже
CE_FRAME (The hardware detected a framing error) - аппаратная, ничего не сделаем
CE_IOE (An I/O error occurred during communications with the device) - аппаратная, ничего не сделаем
CE_MODE (The requested mode is not supported, or the hFile parameter is invalid. If this value is specified, it is the only valid error) - исключена по определению. Открываем СОМ-порт в правильном режиме.
CE_OOP (Windows 95 only: A parallel device signaled that it is out of paper) - старьё
CE_PTO (Windows 95 only: A time-out occurred on a parallel device) - старьё.
CE_OVERRUN (A character-buffer overrun has occurred. The next character is lost) - теряем часть информации, но можем её отбросить и заново запросить.
CE_RXOVER (An input buffer overflow has occurred. There is either no room in the input buffer, or a character was received after the end-of-file (EOF) character) - то же самое, повторный запрос.
CE_RXPARITY (The hardware detected a parity error) - аппаратная, ничего не сделаем, только повторный запрос.
CE_TXFULL (The application tried to transmit a character, but the output buffer was full) - маловероятно, так как количество выходных данных регулируется протоколом и настройками СОМ-порта.

Суммирую: наиболее интересны CE_OVERRUN, CE_RXOVER и CE_RXPARITY. Решается проверкой целостности пакета в алгоритме.

Новые блоги и статьи Все статьи Все блоги /
Эксперимент с картинкой-обложкой на CodinGame Adler 10.07.2026 Решил на днях провести эксперимент. У меня есть аккаунт на CodinGame, ТОП-3 по РФ среди 2200 участников (в разделе соревнования по программированию ИИ-ботов). Там есть обложка, куда можно влепить. . .	После бана на Пикабу не работает авторизация аккаунта с Яндекса. Hrethgir 09.07.2026 В частности https:/ / auto. ru/ logbook/ zapret-na-vozhdenie-posle-65-let_1cf28789-07b4-4c75-a2f7-4cd4edf9deeb тут хотел оставить комментарий такой Зрите в корень - монополизация на разработку программ. . .	GitDOS: Когда я решил скрестить MS-DOS, GitHub и Claude MaGz GoLd 08.07.2026 Привет, Киберфорум! Хочу поделиться своим проектом, который, надеюсь, вас заинтересует. GitDOS — это веб-приложение, которое позволяет запускать DOS в браузере с тремя крутыми фичами: диски живут в. . .	Учебный мини "цифровой двойник" = (Сервер = Java + Flask_питон )+(3D = Гугловскаая 4T nvideo + google colab) +( WMS = Odoo на Docker) anaschu 07.07.2026 Увидел в требованиях к вакансии создателя имитационных моделей связку (REst + Api + WMS + Anylogic + питон + 3D Nvideo), и решил посмотреть, что это такое. Из этого всего я работал более менее. . .
Море в объективе kumehtar 06.07.2026 Хотел написать много проникновенных слов, но передумал. Оно само - говорит. Кто слышит тот слышит.	Doom для терминала без стрельбы и монстров. 3D Raycasting на ascii. dcc0 05.07.2026 Попросил нейронную сеть deepai. org написать рейкастинг 3D с библиотекой ncurses для Linux. Чтобы можно было ходить на стрелочки. Чтобы стены были отрисованы символами. Справилась. Первый вариант. . .	Установка статуса документа по условию Maks 05.07.2026 Алгоритм из решения ниже реализован на нетиповом документе "НарядПутевка" разработанного в КА2. Задача: в табличной части "Материалы" документа при записи автоматически устанавливать статус. . .	Сезонность и суточность закисления почв anaschu 04.07.2026 200 часов это все равно моловато. Есть ситуации, но нестандартные, когда смена происходит за 5 лет. Но обычно это 50 лет и более. Наверное, закисление почвы происходит сезонно в средней. . .

@d7d1cd 279 / 156 / 52 Регистрация: 30.06.2011 Сообщений: 1,712

	Чтение из COM порта 25.07.2016, 13:38. Показов 12433. Ответов 35 Метки нет (Все метки) Приветствую всех! Для чтения из COM порта использую функцию ReadFile. Третьим параметром в данной функции указывается число байт для чтения. Ранее работая с COM портом я точно знал какое количество байт мне нужно читать из порта. Сейчас в проектируемом приложении я не могу знать сколько байт придет. Возможно ли выполнить чтение из порта так, что если в порт совсем не придут данные, то функция ReadFile ждет какое-то время (я так понимаю, оно настраивается через таймауты порта) и прекращает работу. Если же в порт приходят данные, то чтение продолжается до тех пор, пока данные приходят. Как только поступление данных прекращается, функция должна завершить свою работу. 0

@c0rvax 91 / 91 / 22 Регистрация: 02.07.2013 Сообщений: 332
	22.08.2016, 16:11
	d7d1cd, не совсем то, чтоб мне понравилось. 1) Нужен отдельный поток, чтоб не тормозил интерфейс, даже на секунду. Причём, Sleep(1) в цикле будет не лишним. 2) На момент чтения нужно обязательно знать, сколько байт ожидать в ответ. Опять не универсально. Например, есть устройства, которые шлют данные постоянно, и ожидать, что в СОМ-порт поступит чётко определённое количество байт неправильно. Ждём 5, пришло 4, а потом ещё 6, например. 3) Придётся после ReadFile разбираться, что же мы считали. Один пакет, полтора, ноль-пять или ещё что-то... Нет, конечно, для конкретной реализации потянет, но подход тот же, только другой способ. Мой вариант: крутим отдельный поток, проверяем, есть ли что на входе. Т.е., постоянно читаем из порта. Есть чё? Читаем всё в какой-нибудь контейнер. Вторая часть балета этот контейнер проверяет, вырезает распознанный пакет, оставляя "лишнее" для дополнения и выполняет необходимые действия над данными и отправляет очередную команду при необходимости. Естественно, контейнер должен быть потоконезависимым. Соорудить такой из стандартного, добавив критическую секцию труда не составит. Это будет практически универсально для любого обмена, с любой скоростью порта, с любыми устройствами. 0

@c0rvax 91 / 91 / 22 Регистрация: 02.07.2013 Сообщений: 332
	22.08.2016, 17:15
	vxg, все, что есть (ComState.cbInQue) 1

@vxg Модератор 3410 / 2182 / 354 Регистрация: 13.01.2012 Сообщений: 8,469
	22.08.2016, 17:22
	c0rvax, а где у вас в коде получение этого значения? Во время очистки? 0

@c0rvax 91 / 91 / 22 Регистрация: 02.07.2013 Сообщений: 332
	22.08.2016, 17:29
	vxg, да. ClearCommError возвращает количество байт в буфере. 1

@vxg Модератор 3410 / 2182 / 354 Регистрация: 13.01.2012 Сообщений: 8,469
	22.08.2016, 17:41
	c0rvax, но в этом ли её назначение? Ошибку таким образом не пропустите? 0

@c0rvax 91 / 91 / 22 Регистрация: 02.07.2013 Сообщений: 332
	22.08.2016, 17:58
	vxg, эта функция так же и ошибки возвращает. Да и ReadFile так же вернёт ошибку. Думаю, что с этими ошибками программно не поборешься. Естественно, можно предусмотреть корректный выход и завершение работы. 1

@vxg Модератор 3410 / 2182 / 354 Регистрация: 13.01.2012 Сообщений: 8,469
	22.08.2016, 18:01
	c0rvax, Read после вызова этой функции не вернёт ошибку если она произошла до очистки поэтому кроме результата Read надо дополнительно проверять возврат из Clear 0

@c0rvax 91 / 91 / 22 Регистрация: 02.07.2013 Сообщений: 332
	23.08.2016, 09:48
	vxg, Read вернёт ошибку, если она произойдёт уже после "холостого" Clear. Или, если Clear реально только сбросит признак, но не решит проблему [что скорее всего и будет]. ТС уточнил, что контроль ошибок опускает, поэтому я не углубляюсь в детали. Разобраться бы с общим подходом к обмену... 1

@d7d1cd 279 / 156 / 52 Регистрация: 30.06.2011 Сообщений: 1,712
	23.08.2016, 11:28 [ТС]
	Вопрос. Если при приеме происходит какая-то ошибка, и была сначала вызвана функция ClearCommError, а потом ReadFile, то последняя завершится не удачно? 0

@vxg Модератор 3410 / 2182 / 354 Регистрация: 13.01.2012 Сообщений: 8,469
	23.08.2016, 11:33
	d7d1cd, нужно уточнить что значит при приеме. если ошибка будет во время работы ReadFile то ReadFile вернет ошибку. а если ошибка сама по себе безотносительно работы программы произошла до вызова ClearCommError то вызов ClearCommError ее очистит. были ли ошибки на момент вызова ClearCommError надо глядеть по возвращаемым этой функцией параметрам. 0

@d7d1cd 279 / 156 / 52 Регистрация: 30.06.2011 Сообщений: 1,712
	23.08.2016, 13:14 [ТС]
	Чувствую, что я не допонимаю работу COM порта... Как я понимаю, когда какое-либо устройство передает данные в COM порт, это совершенно не зависит ни от каких функций. Данные просто поступают в буфер порта. Если при этом поступлении возникла ошибка, то тут все зависит от флага fAbortOnError структуры DCB. Если он true, то COM порт перестает принимать данные до тех пор, пока функция ClearCommError не очистит эту ошибку. Если же fAbortOnError = false, то прием продолжится. Если после этого не вызвать функцию ClearCommError, а сразу прочитать данные функцией ReadFile, то она завершится ошибочно. Все так или нет? 0

@c0rvax 91 / 91 / 22 Регистрация: 02.07.2013 Сообщений: 332
	23.08.2016, 15:48
	d7d1cd, трудно сказать. И поэкспериментировать вряд ли удастся. Слишком уж эти ошибки "аппаратные", вряд ли их удастся эмулировать. Мне кажется, что если очистить ошибку, а потом пробовать выполнить какие-то телодвижения, то Read вернёт ошибку, а Clear опять установит флаги. Я к тому, что если вдруг что-то перестало работать, то уже ничего не сделаешь, кроме как чинить оборудование, поэтому логичнее прекратить весь обмен и сделать выход. 0

@c0rvax 91 / 91 / 22 Регистрация: 02.07.2013 Сообщений: 332
	23.08.2016, 17:43
	Если так прикинуть, то CE_BREAK (The hardware detected a break condition.) - аппаратная, ничего не сделаем CE_DNS (Windows 95 only: A parallel device is not selected.) - исключена уже CE_FRAME (The hardware detected a framing error) - аппаратная, ничего не сделаем CE_IOE (An I/O error occurred during communications with the device) - аппаратная, ничего не сделаем CE_MODE (The requested mode is not supported, or the hFile parameter is invalid. If this value is specified, it is the only valid error) - исключена по определению. Открываем СОМ-порт в правильном режиме. CE_OOP (Windows 95 only: A parallel device signaled that it is out of paper) - старьё CE_PTO (Windows 95 only: A time-out occurred on a parallel device) - старьё. CE_OVERRUN (A character-buffer overrun has occurred. The next character is lost) - теряем часть информации, но можем её отбросить и заново запросить. CE_RXOVER (An input buffer overflow has occurred. There is either no room in the input buffer, or a character was received after the end-of-file (EOF) character) - то же самое, повторный запрос. CE_RXPARITY (The hardware detected a parity error) - аппаратная, ничего не сделаем, только повторный запрос. CE_TXFULL (The application tried to transmit a character, but the output buffer was full) - маловероятно, так как количество выходных данных регулируется протоколом и настройками СОМ-порта. Суммирую: наиболее интересны CE_OVERRUN, CE_RXOVER и CE_RXPARITY. Решается проверкой целостности пакета в алгоритме. 0