Вот приобрёл себе Arduino, решил поиграться с аналоговым входом и COM портом... И тут замечаю что передаются данные с какими то неточностями, если в течении времени меняется время передачи и размер (количество символов) то события компонента выскакивают не правильно... И с обрезанными данными.
С настройками компонента игрался как мог... Скорость выставлена верно.
В HyperTerminal'е виндозном всё отлично выводится. На линухе ещё не тестил.
code_30990.txt

Если ни как не исправить события, придётся делать костыль с разделяющим символом в самом устройстве...

Любая ошибка передачи данных в этом компоненте воспринимается как конец передачи, и буфер чтения тут же передается на выход. Возможно, что Гипертерминал устанавливает большие задержки на чтение буфера, чем дефолтные для данной скрости, откуда ошибки будут гаситься. В первую очередь, надо посмотреть -- точно непрерывным потоком идут данные, ничего не вклинивается в передачу

Recosh, COMEX работает правильно, написанная программа с этим компонентом работает как часики.
Часто при наладке устройств с RS-232 и его производных нахожу следующий параметр "Время ожидания последнего байта".
Сделал следующим образом:
1. по приходу данных взвожу таймер;
2. Добавляю данные к буферу;
3.1. если пришли данные а таймер не сработал иду на п.1.
3.2. иначе если сработал таймер отправляю данные дальше на обработку, очищаю буфер.

P.S. почему то не дает залить файл
code_30992.txt

Судя по последовавшему алгоритму: временной интервал длиною больше одного символа - является разделителем пакетов.
Вот только даже на скорости 9600: один символ - около 1 мсек. Это, вроде, не очень то и время для таймера винды. И чем измеряешь то

И насчет "часто".
Сделаю следующее утверждение: физический протокол RS-232 (и ему подобных) таков, что при отсутствии интервалов молчания длиннее, чем один байт - НЕТ НИКАКИХ ГАРАНТИЙ, что ты вообще принимаешь осмысленные данные.
Вот тебе и "часто"

Galkov, во, а я репу чесал, как же байт от байта отличает машина, только по начальной синхронизации: легко может сбиться, и никаких "осмысленных данных"

Ну типа - ДА. У меня аналогичное чесание репы закончилось нетривиальными требованиями к программистам.

Ну типа, передал последний байт пакета - и выключил активность линии (по Transmit Complite).
И тут беда такая, что, когда все передатчики в 3-м состоянии - помехозащищенность линии не очень хорошая.
Следовательно, если помеха прилетит раньше допустимого времени - в пакет добавится какая-то фигня.
Требую: отключайте драйвер (физический на 485-й) только после паузы, предположим - 2 символа.

Аналогично на начале пакета. Если прилетит помеха перед активизацией передатчика, скажем, на микросекунду раньше - гробится вообще весь пакет. Синхронизация-то сбита.
Требую: включайте драйвер на один символ раньше начала передачи.

Они огорчались, и не хотели

Galkov, при всем моем уважении к Вам не согласен.
Может в риторике и диалектике у Вас и масса познаний, но насчет RS-232 по своему горькому опыту могу спорить.

Почему "около 1 мсек", надо намного больше для гарантированного приема, все зависит от каналов связи.
Смотрим:
Если у нас соединены 2 устройства между собой по RS-232 и идеально настроены устройства, описанный вами пример проходит, а теперь берем что UART наполняется на лету, производительности камню не хватает и куча прерываний (живой пример счетчик электрической энергии), то тогда стройная идеология тишины в 2 байта рушиться, рвет ее реальность как тузик грелку, а если мы устройства соединили через промежуточные устройства (например ШМР, PLC, модем, преобразователи Etehernet-Com, и наконец мой любимчик GPRS где пинг в 4 сек. то о какой последовательности выдачи байт в 2 слова мы говорим. Каждое устройство добавляет свои задержки и свою часть анархии в систему, а учитывая что прошивки для большинства девайсов пишут братья китайцы за миску риса в день, то вылазят такие баги, что у самого к концу дня глаза как у того дяди Ляо.

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

Уважаемый savt

Во-первых: я был бы Вам очень признателен, если бы Вы обходились без "при всем моем уважении", без "риторике и диалектике", и т.п.. Информационный мусор.

Во-вторых: это я Вам уже говорил

В-третьих: я не говорил, что надо около 1мс. Но говорил, что надо не менее одного символа, чтобы иметь какие-то гарантии. А один символ на 9600 это около 1мс. Это не очень то, что Вы про меня говорите

В-четвертых: Если Вы говорите что “значительно больше”, то как-то расскажите же про свою задачу, почему больше, наконец, как все-таки измеряете. Иначе, это просто лозунг какой-то...

Ну и последнее. Риторика - это не мой конек.
Потому что в результате того, что Вы называете "риторикой", у меня обязательно появится сеть (на 485-м интерфейсе) в шахте (косвенный показатель качества связи), растянутая на 4км, и работающая на 115200 (т.е., длительность символа - около 0.1мсек)
И не пропускающая пакетов. Никогда. И даже с хэминг-кодированием.
Мне зарплату за это платят - чтобы она появилась, с возможностью неограниченного тиражирования.
И мне не кажется, что некоторая логика, в результате которой все это и произойдет, называется "риторикой".

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

BTW: кстати говоря, меня несколько удивило, что для микроконтроллера 1мсек - это маленькое время. Это для винды оно маленькое...
А, даже для 8-битной Atmega-8-16МГц - это кошмарно большое время. Из моего предыдущего опыта.
Не говоря уже о 32-битных Кортексах

nesco, [flood]надо бы обезьянку на вершине холма изобразить, а в долине тигры спорят [/flood]

"Рогочи бамбула над разгэпнутым коханьем"

---

перевожу на всякий случай:"Смейся паяц над разбитой любовью"

Леонид,
[flood]
Без бананов смотреть на тигров не интересно, приход не тот [/flood]

Galkov,
1,2 Хорошо, забыл просто.
3. Согласен, чуть чуть перегнул палку.
4. Рассказываю:
АСКУЭ, удаленный счетчик общается с УСПД через коммуникаторы, где поднят GPRS канал связи. Как заметил Леонид, , с УСПД пошел запрос отдай свои данные что накопил ты неправедным путем, ждем ответа нет ответа, ок, по этому каналу связи отправляем второму отдай данные и тут о чудо приходит ответ от первого счетчика, беда в том что протокол не мы писали и поменять его не реально, и на второй запрос приходит ответ от первого.. почему.. ХЕЗ, так работает сеть GSM, инет трафик у нее не приоритетный, насколько неприоритетный что иногда диву даешься, что иногда длинный ответ (занимает 2 кадра) приходит сначала второй кадр а потом первый... Выход нашли что ставил задержки около 10 сек, при пинге 5 сек.(точнее от расположения звезд он меняется от 1,5 сек. до 7 сек.), переопрашиваем несколько раз данные (верификация) и т.д. Медленно но верно собираем данные. Аналогичная проблема, и при GSM-CSD связи наблюдается. Надеюсь ответ устроит.
Последний пункт, мне кажется это не реально, в жизни больше 1,5км линии RS-485 не видел больше чем на скорости 9600, обычно или повторители ставят, или оптику используют, может у Вас там свой там RS-485, как например у Сименса, может там нет мощных наводок электромагнитных...
Но главное программа с таким алгоритмом работает...

А че Рида-Соломона не прикрутили? Небольшая избыточность, зато восстановить можно