Но мы же не знаем ТЗ на контроллер и его формат вывода. К тому же, почем-то, код ADEMCO или SURGARD не считаеют идиотизмом, а они фиксированной длины. [offtop]Думаю, тебе эти названия подскажут, в какой сфере деятельности я работаю[/offtop]

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

с признаком конца сообщения. И фиксированы они совсем по другой причине.

Эти коды, да, имеют конец сообщения.

Есть СПИ, где для связи с компом применяется строка переменной длины.
Tad, тебе не кажется, что ты пургу гонишь -- наш компонент COM без проблем может ловить строку пекременной длины, концом приема является пустая строка, если стоит циклический опрос, и данные идут не непрерывным потоком. Ни нахер там больше ничего не нужно, не надо усложнять себе жизнь и другим тоже, все прекрасно работает и без побайтового чтения. Мы не читаем порт напрямую, мы читаем системный буфер как файл.
Tad, это проверено, и это работает без всяких потерь данных на протяжениии уже нескольких лет.

nesco, "не надо кипятиться, не надо волноваться"
Пользователь не указал все параметры; СОМ не самый быстрый в компьютере; вполне может быть ситуация, когда в буфере только часть передаваемой информации и поступила команда на чтение Ваш алгоритм в этом случае пропустит часть информации

Не будет такого, если правильно рассчитать время опроса порта. Оно должно быть больше, чем макимально отведенное время на чтение всей предполагаемой посылки.
Леонид, я так полагаю, что тут портянки больше 255 байт читаться не будут, вот тогда, если будут, то и надо использовать накопитель и искать конец посылки.
------------ Дoбавленo в 20.24:

О Боже! Народ! Почитайте теорию. Система не дает нам читать порт напрямую, и никогда не даст. Она не работает в реальном времени с пользователем, да и устройствами тоже. Все контроллеры моста работают на аппаратном уровне через DMA (думаю, объянять не надо, что это такое). Драйвер устройства выдает контроллеру определенную команду и параметры команды, в которых и содержится необходимый адрес DMA, после чего переходит в режим ожидания прерывания от устройства. Это и дает возможность работать с реалтайм устройствами на больших скоростях обмена
------------ Дoбавленo в 20.31:
Короче, ну вас всех в пень. Делайте, что хотите. Я больше никогда не буду выступать по этой теме. Считайте что, вы все правы, а я сливаюсь

nesco,
Я не толковал о "чтении порта напрямую", везде буфер
Можно вводную?
Устройство передаёт с установленной скоростью 9600 бит пакеты данных по 20 символов, из них 13 -- стартовый ключ. Интервал между пакетами случайный в диапазоне от 10 до 1000 миллисекунд. Как часто (редко) надо считывать из буфера СОМ по 20 символов (без склейки прочитанного с предыдущими данными) чтобы не было ошибок?

nesco, у меня нет старых портов уже нет почти нигде, на практике сейчас не могу проверить, признаюсь честно, но есть смутное подозрение, что ни DMA, ни IRQ на современных системах физическому COM порту никто не даёт, а работает самый обыкновенный циклический опрос (у нас это называется поллингом). По крайней мере именно так мы работаем с более быстрым LPT. Если я прав, то теоретическая потеря данных вполне возможна. И я уже говорил в этой теме - почему. Если как-то умудриться переполнить аппаратный буфер контроллера до следующего цикла опроса, то контроллер снимает сигналы DTR и CTSна порте ПК, пытаясь сказать устройству, что пора бы и помолчать чуток. Вот только беда в том, что 99% устройств глубоко до лампочки на эти шины. Они тупо не распаяны. В итоге данные летят себе в никуда (кто-то тут говорил, что буфер циклический и улетают старые данные). Но чтобы такое произошло, нужно оочень маленький буфер (нулевой?), ооочень быструю передачу и при этом древний тормозной ПК с установленной NT6.x

да не должен никто ничего рассчитывать.
Я тебе уже говорил, что, к примеру, при обновлении Avast вся система блокируется ровно на 3-и секунды.
А COM-порт в это время работает. Так устроено железо.
Да а вот приём идет и буфер COM-порта заполняется. А когда нам система даст читать, то в буфере может быть сколько угодно посылок.
Второе - размер буфера приема.
То, что у нас в компоненте буфер 256 байт, разрешает применять скорость обмена не более 300 бод.
Для скорости обмена 1200 бод нужен буфер не менее 1kb.
Так когда-то было.

------------ Дoбавленo в 21.35:
Леонид, метод рассчета сегодня не работает. Работает метод научного тыка.

Вот именно, когда-то. На нашем несчастном компоненте я умудрялся читать 57600 без потерь, но не побайтово

Определяем длительность посылки одного пакета -- 20*10*1/9600~21 msec. Для твоего случая не пойдет, тк минимальное время между посылками у тебя равно 10 msec. Можно выбрать кратные пакеты, но время их опроса должна быть меньше 10 msec. И даже в случае, если ты не успеешь прочитать весь пакет сразу, то данные не пропадут, а новые приклеются к ним в хвост, но вот выудить начало хвоста с остатками предыдущих данных будет слегка проблематично.


Это только в случае аппартного управления потоком. В случае программного управления потоком, все это безобразие вешается на ПО

Мля, опять я влез, не хотел ведь
------------ Дoбавленo в 21.58:

Там система немного сложнее, чем я описал. С вводом в аппаратную часть хабовой структуры распределения потоков, нагрузка на обработку прерываний от контроллеров повешана на хаб, и для системы эти прерывания недоступны, но DMA работает всегда, иначе бы система не справилась бы с такой нагрузкой, даже при теперешнем быстродействии, тк существует не только один несчастный COM порт, но еще и куча USB, HDD и прочей повешенной лабуды

Именно про это я (и Tad) и говорим

Вот, на пальцах, то о чем я говорю.
code_26115.txt
можно обратить внимание на скорость порта.

Да тебя сам черт не поймет. На кой леший ты тогда писал про

------------ Дoбавленo в 11.43:
Tad, ты бы лучше свой вариант коммутатора команд показал. Мне что-то подсказывает, что из-за применения параллельного потока, он не будет совсем простым. Если ты хочешь иметь надежность, конечно

Tad, [flood] [/flood]

Не понял (видно ещё не проснулся) - расшифруй, что имеешь ввиду ?

Парсер команд + переключатель событий