Потеря байт при работе с COM портом

[Borjomy_1]

Перед чтением делайте очистку буфера COM-порта(тем самым удалите мусор).

Не хочется быть резким, но это абсолютно некорректная рекомендация, призванная маскировать ущербный алгоритм обработки данных! При правильном приеме никакого мусора быть не может.
sirQWERTY, так как у нас уже есть подобная вашей система ( трехосевой гироскоп и трехосевой акселерометр ) с последовательным каналом по RS-422, то я могу вам рассказать, как это делается.
Формат посылки у нас примерно следующий:
0xFF
2 байта гироскопа X
2 байта гироскопа Y
2 байта гироскопа Z
2 байта акселерометра X
2 байта акселерометра Y
2 байта акселерометра Z
1 байт температура внутреннего температурного датчика чипа гироскопа
0xFE
итого 21 байт. На частоте передачи 115200 частота следования посылок до 500/с
Для начальной синхронизации вычитывается 42 байта (2 посылки) В них ищется комбинация начального и конечного байта посылки. Рассчитывается, сколько нужно вычитать из следующей посылки (если начальный байт не является первым) и далее просто запускается цикл по вычитыванию заданного количества посылок. Принятые посылки проверяются на начальный и конечный байты. При несоответствии запускается начальная синхронизация. Такая реализация массово работает без сбоев в десятке мест в режиме 7/24.

[Vitekkz88]

Borjomy_1 писал(а):Не хочется быть резким, но это абсолютно некорректная рекомендация, призванная маскировать ущербный алгоритм обработки данных! При правильном приеме никакого мусора быть не может.

А Вам и не надо быть резким. Вы просто не сталкивались с преобразователями, которые в момент старта(особенно по питанию) самостоятельно в порт выкидывают пачку данных. Отсюда и Ваша попытка выглядеть грамотнее чем есть на самом деле. Если не сделать clear(очистку буфера), то они и болтаются как мусор.
Ах да, я надеюсь Вы понимаете, что имелась ввиду очистка не перед каждым чтением?

Для начальной синхронизации вычитывается ... (2 посылки)

Я предложил тоже самое, описано в комментариях к коду.

[Borjomy_1]

Вы просто не сталкивались с преобразователями, которые в момент старта(особенно по питанию) самостоятельно в порт выкидывают пачку данных.

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

Я предложил тоже самое, описано в комментариях к коду.

Мы комментарии писали одновременно.

[Vitekkz88]

А вообще, для общего развития, просветите что это за такие интересные преобразователи?

Намедни работал с Prolific(номер микросхемы точный не скажу сейчас). Вот как раз она выплёвывала пачку данных при старте питания.
А по сабжу я так понял проблему: данные читаются, но почему-то со сдвигом или потерей байт. Протокола нет - что делать? Свои решения и ход мыслей я выше изложил. В целом логика совпадает с Вашей. У меня не было ситуаций, когда мы положили в порт пакет из 8-ми байт, а я читать начал со второго или третьего байта.

[Borjomy_1]

Prolific - это вообще ущербный какой-то производитель. Мы от него отказались, ибо он очень ненадежный. И порты разные выдает при разных моментах подключения через USB и повисает и драйвера какие-то раздутые.

У меня не было ситуаций, когда мы положили в порт пакет из 8-ми байт, а я читать начал со второго или третьего байта.

Такое бывает, когда датчик включен постоянно, и программа запускается при включенном датчике.

[dadreamer]

порты разные выдает при разных моментах подключения через USB

А другие адаптеры (FTDI, Silicon Labs) работают иначе? Вообще, виртуальный COM-порт создается исходя из параметров системы. Может быть назначен любой номер вне занятого диапазона. Драйвер адаптера сам решает, какой номер взять. Но, как правило, номер потом можно также поменять вручную. Да, и не проблема программно отыскать нужный порт по серийнику/vid/pid/...

[Vitekkz88]

Prolific - это вообще ущербный какой-то производитель.

Что есть, с тем работаем. Есть FTDI - работаем с ним, есть Prolific - узнаём как может быть. В целом не все подряд чипы Prolific странно себя вели. У FTDI, например, тоже есть недостаток(на Prolific такого пока не встречал): если ПК уходит в сон - то с "пробуждением" оживить преобразователь можно только с помощью реконекта по питанию(usb-кабель выкл/вкл). И не только на конверторах, но и на программаторах Xilinx такая фишка есть.
Silicon Labs - был один, за 700 рублей купленный. Использовался немного, его быстро забрали. Работал и хорошо.

[dadreamer]

Vitekkz88, вырубить режим сна в винде?.. ) Я всегда его отключаю, как и экранную заставку, ибо не пользуюсь.

[Vitekkz88]

dadreamer, ну дк уже давно вырублено все Еще была такая фишка с программатором, если у ноутбука батарея садится. Флешку воспринимает, мышку тоже, клавиатуру тоже, даже отладочную плату с PLL заводит без проблем - а программатор не в какую.

[dadreamer]

Vitekkz88, может быть, много мощности потребляет, вот питание по USB шине просаживается. Обычно такое бывает, когда кучу устройств на один USB хаб посадить. Что-то да не определится в системе. Или когда кабель USB длинный, особенно больше 5 метров, тогда не хватает питания.

[Borjomy_1]

А другие адаптеры (FTDI, Silicon Labs) работают иначе? Вообще, виртуальный COM-порт создается исходя из параметров системы. Может быть назначен любой номер вне занятого диапазона. Драйвер адаптера сам решает, какой номер взять. Но, как правило, номер потом можно также поменять вручную. Да, и не проблема программно отыскать нужный порт по серийнику/vid/pid/...

При FTDI с таким не сталкивались. Prolific такое выдает через раз (т.е подключил - получил COM3, отключил, снова подключил, в тот же порт - получил COM4). Я этого категорически не понимаю. Все программы, работающие с последовательными портами не допускают такой вольности, последовательный порт вещь аппаратная и он не может так просто бегать. А делать костыли, занимаясь поиском vid - это извращение. Конкретному устройству должен соответствовать конкретный порт, как и прописано в настройках. FTDI же сделал.

[dadreamer]

При FTDI с таким не сталкивались. Prolific такое выдает через раз (т.е подключил - получил COM3, отключил, снова подключил, в тот же порт - получил COM4). Я этого категорически не понимаю. Все программы, работающие с последовательными портами не допускают такой вольности, последовательный порт вещь аппаратная и он не может так просто бегать. А делать костыли, занимаясь поиском vid - это извращение. Конкретному устройству должен соответствовать конкретный порт, как и прописано в настройках. FTDI же сделал.

Аппаратный COM-порт существует физически на мат. плате и потому имеет постоянный базовый адрес ввода-вывода. Загляните в BIOS, увидите там адреса 3F8 / 2F8. При желании их можно поменять вручную. Виртуальный COM-порт аппаратно не существует, пока драйвер не внесёт определённые модификации в ОС, чтобы она думала, что у неё есть дополнительный порт. Базовый адрес выбирается из свободного адресного пространства шины PCI. Если какой-то диапазон адресов занят, то естественно он не будет использоваться.
Точно не знаю, как FTDI и как Prolific назначают адреса (скорее, это дело зарыто в коде драйвера и без реверсинга не понять). Но, вполне возможно, что FTDI взял первый свободный адрес, сопоставил его номеру порта, забил в параметры и использует. Prolific же рандомно выбирает каждый раз новый адрес и номер порта. Я веду к тому, что и FTDI может поменять номер порта, если что-то займет адрес, которому он назначил свой порт. Это может произойти при установке новых плат ISA/PCI или при установке каких-то других виртуальных устройств. Легко проверить: поставьте эмулятор COM-порта (например, com0com) и пропишите в нём порт, который обычно берёт FTDI-адаптер. Потом вставьте адаптер и посмотрите. Он должен увидеть, что его порт занят, и переназначить адрес и порт.

А делать костыли, занимаясь поиском vid - это извращение.

VID/PID известен, можно подсмотреть в диспетчере устройств Windows. Ищется номер порта по VID/PID устройства. Ну, для стандартных устройств ввода-вывода может и извращение. Но для виртуальных, которые сами по себе являются извращением, это уже не важно. Тем более что VI написаны.

[Borjomy_1]

Это понятно, что если порт занят, будет назначен другой. Но проблема с Prolific в том, что драйвер виснет при отключении модуля. И это глюкалово нельзя использовать, когда требуется оборудование, с которым работает непродвинутый заказчик.

VID/PID известен, можно подсмотреть в диспетчере устройств Windows.

ЗАЧЕМ искать его, если заранее известно, что оборудование подключается одно и тоже в один и тот-же разъем??????? Короче, Prolific в топку. Я уже не говорю, что программное обеспечение как-то должно знать, с каким модулем работает. И если будет использован другой аналог, то программа перестанет работать.

[Vitekkz88]

Но проблема с Prolific в том, что драйвер виснет при отключении модуля

Эммм...а в чем проявлялось это зависание? У меня не зависал ниразу А еще Prolific - это пока единственная микросхема, которая не потребовала драйверов для работы в системе(разумеется из тех, с которыми я работал). В то время как и силикон лабс и ftdi требовали драйверов и LabVIEW с ними "на горячую" не работает(по принципу подключил и начал работать).
Еще в копилку общего развития специально для Borjomy_1: пришла партия преобразователей на базе FT232R - FTDI. Среди рабочих были и такие, которые не обеспечивали даже 115200(частота была в гораздо меньшую сторону). Проверяли осциллографом. Отправили на замену.
Я к тому, что не надо быть настолько категоричным и делать выводы опираясь на свой исключительный опыт. Одно отправлять в топку, а про второе молчать до поры до времени.
Очень здорово объяснил dadreamer про то, как в системе виртуальный порт определяется. У меня бы так лаконично не получилось. И решение поиска по вендору - это скорее следующая ступень развития и становления, нежели бесполезные действия. А-ля "порт определился под номером 5 и иначе быть не может. И usb другой не используйте - а то сломается. Если что не так - все претензии к производителю микросхемы, а нам позвоните и мы будет "править софт" и т.д." Это не лучший способ показывать собственную значимость при сопровождении проекта, Вам ли не знать.

[dadreamer]

Но проблема с Prolific в том, что драйвер виснет при отключении модуля. И это глюкалово нельзя использовать, когда требуется оборудование, с которым работает непродвинутый заказчик.

Я что-то такого тоже не встречал. Хотя я, может, и не так много работал с Prolific'ом. Отключаете модуль, тупо выдергивая из USB-порта? Или до этого программно закрываете все сеансы, потом выдёргиваете? И когда снова вставляете, то ... устройство не определяется / к нему нельзя подключиться / пакеты пропадают / ?..

ЗАЧЕМ искать его, если заранее известно, что оборудование подключается одно и тоже в один и тот-же разъем???????

Ну, допустим, если используется всё время FTDI, разъём один и тот же и COM-порт получаем один и тот же, то можно ничего не искать. Однако не будет гибкости и универсальности. Получается, что с другим адаптером прога уже работать не сможет. C другим USB и COM портом не сможет. Я не говорю, что это обязательная процедура. Это скорее рекомендация, чтобы перестраховаться, а мало ли. Тем более, что неизвестно, как работают драйвера для других адаптеров, коих довольно много. А задача определения COM-порта по серийнику всплывала уже несколько раз на этом форуме как раз из-за того, что меняются порты у пользователей.

Короче, Prolific в топку.

Взял сейчас PL2303HX. Если USB-порт не менять, то всегда создаётся один и тот же COM-порт. В другом USB-порту COM-порт становится другим, но сохраняется при переподключениях. COM-порт даже не захотел меняться, когда я на него назначил другое виртуальное устройство. Так что в этом плане драйвер работает корректно. Может быть, вам стоило переустановить/обновить драйвер или вычистить фантомные порты из базы.

Я уже не говорю, что программное обеспечение как-то должно знать, с каким модулем работает. И если будет использован другой аналог, то программа перестанет работать.

Ну, смотря что за программа. Если к USB-UART мосту подключено какое-то устройство, то программе параллельно должно быть, что за мост такой. Ей лишь бы с самим устройством поработать (открыть, прочитать/записать данные, закрыть). И по идее можно было бы заменить один адаптер на другой (с теми же настройками порта) и разницы не почувствовать.