еще как канает - и не вы ли тут писали по поводу стойкости к борьбе с шумами?





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

вы начинаете выворачиваться с шумами на шине и тд
слив засчитан

Вообще это даже НЕ шум. Лишний стартовый бит означет дополнительный байт фрейма идущий БЕЗ паузы, попадающий MODBUS фрейм и ЛОМАЮЩИЙ его.
Если фреймер байтствффинговый, тогда это мусор, который тоже есть признак того, что "программист" засранец .

Вот уж точно с про Вас - с больной головы на здоровую.

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

так что про больную голову не надо

Это БЕЗ проблем. Именно так бывает делаю, если приемопередатчик позволяет принимать эхо, то есть он RS422 а не RS485, или тестовое закольцовывание внутри UART не блокирует передачу. Но только это не решает задачу держать ПУСТУЮ паузу отключив передатчик. Еще пробовать засирать форум негодными "идеями" будете?

Но речь шла вообще о ДРУГОМ, неработоспособном методе. Так что про больную голову все правильно.

P.S.
С 1984 года я познал множество извращений с UART и поначалу наступил на некоторое количество гараблей, так что дабы меня чем нибудь удивить, надо очень постараться.

спокойно сосчитайте до 1000 или сколько вам надо

метод отправки лишнего байта работает чтобы узнать ушел ли предыдущий байт

то что вы пользуетесь кривыми протоколами и у вас возникают проблемы это ваш выбор

так что про больную голову возвращаю

Мне не надо. А Вам учиться думать, прежде чем писать, очень надо. Мусора в интернете и без Вас достаточно . Ваши глупости уже перестают заслуживать ответов на них .

Коллеги я привёл реально работающий не один год алгоритм.
Что бы там ни говорили я обхожусь вообще без прерываний таймера.
Таймштамы принятых и посланных байт получаю с помощью вычисления разницы значений счётчика, заряженного на цикличный счёт таймера (например HPET под win, либо DWT->CYCCNT для Кортексов).
Никаких ложных стартовых битов никогда не возникает.
Да, это решение не универсальное и не применимо напрямую в устройствах без прерывания TXC и без возможности программного отсоединения функции UART-TX от пина.

я вам показал ответ на ваш глупый вопрос - что НЕВОЗМОЖНО узнать когда ушел байт
я вам показал, что лишним байтом этот вопрос решается
какой вопрос такой ответ


слив я вам засчитал
обидно - понимаю - но вы сами так сделали



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

лень разбираться. просто это надо учитывать

Не вопрос. Вопрос только в ОГРАНИЧЕНИЯХ такого исплользования.

Это только если делать нечего и можно ждать опрашивая счетчики. Обычно время есть деньги .

Естественно не возникает, если можно использовать честое имеющеюся "TXC".
Без него и попытка фокуса, с посылкой "дополнительного байта" с котрым здесь, как курица без головы носится net не помогает.



Не обидно. На убогих на руси обижаться не принято. А Вы демонстрируете именно убожество ума, даже в квадрате, поскольку считаете возможным еще и заявлять "слив я вам засчитал". Это уже плинтус .

не расстраивайтесь вы так.

Да ладно))) В прерываниях ТХ и RX ищем дырку 1,5T, а в фоновой задаче ищем дырку в 3,5Т или более - не критично ко времени, да и ещё и 1сек мониторим чтобы реплай таймаут не привысить.
Это решение пришло из-за нехватки таймеров в младших AVR-ках более 10 лет назад. Я тогда тоже не продувал))) Даже более того, умудрился CRC16 считать косячно - поменял по ошибке в modbus фрейме старший байт с младшим, подумал, что сетевой порядок байт во всём протоколе включая и CRC:(.
Конечно, всегда хочется универсальности и, думаю, что сяду, да переиграю всё и вся, но блин, время есть деньги)))

По хорошему и 3,5Т критично. У мастера есть полное право гнать бродкаст пакеты с таким разделителем. А уж другому слейву ответить через СРАЗУ после получения фрейма вообще никто запретить не может. Не поймали при опросе разделитель между бродкастами или между запростом и быстрым ответом и ага .
Фреймер MODBUS отличается дубовой простотой, но плата за нее НЕУКОСНИТЕЛЬНО-ЖЕСТКОЕ выполнение этих простых требований. Увы .

Это понятно и учитывается тем, что фоновая задача выполняется с требуемой интенсивностью.

Каким образом? Работа только со своим оборудованием? Нет способа заставить ЧУЖОЕ учитывать требования ВАШЕГО оборудования к возможному ЗНАЧИТЕЛЬНОМУ превышению 3,5Т интервала .

Какие нафиг "если"? Один коллега поделился рабочим методом для конкретного контроллера, другой коллега сказал, что метод годный, и тут вы такой с капс-локом наперевес "это НЕ работает", "вы НЕ понимаете" и всё такое. А оказывается, не понимаете-то как раз вы.
А уж выкручиваться после этого вообще некрасиво. Все же всё видят и понимают.

Очевидно, что "видят и понимают" Вы к себе не относите. Ибо я четко написал, когда не реализуемый. Цитирую http://electronix.ru/forum/index.php?showt...t&p=1452121 :

После чего некто начал "доказывать", что запихнув лишний байт "заработает" и без такого прерывания. Почему НЕ заработает и будет стартовый бит не отсечь и соответственно лишний мусорный байт и хана MODBUS фреймеру, я, потратив время, дополнительно разжевал.

У меня к Вам один вопрос - извиняться будете? или уподобитесь любителям обделавшись уходить в несознанку со словами "слив вам защитан"?
После извинений могу Вам еще раз обьяснить, то, что Вам непонятно.

Перечитал сейчас ещё раз цепочку, увидел, что ваше "не реализуемо", на которое я отреагировал, относится не к методу от demiurg_spb, а к высказыванию net. А ваше "не реализуемо" про метод, описанный demiurg_spb, выскаэано с оговорками. Так что ошибку признаю. Но извиняться не намерен. Ваш тон и ваши дурные манеры лишают всякого желания даже попытаться наладить с вами нормальный диалог.

Мне этого вполне достаточно. Так что какой-никакой, но диалог теперь возможен.

День добрый всем.
У меня появилась возможность вернуться к решению задачи о построении сниффера и частично я её решил. 2 мс между посылками в компьютерной программе ловлю на ура. Причём не пришлось повышать приоритеты ни процесса, ни потока. Теперь хочу закрепить результат и поймать паузы менее 2 мс. В связи с чем вопрос - с функцией DeviceIoControl применительно к виртуальному порту кто-нибудь упражнялся. А то на всех ресурсах описание её очень скудное. В выходные попробую реализовать и посмотреть её результат. Но может кто что скажет из опыта работы с ней.

юез работы с приоритетами - ваше разрешение 2мс весьма нестабильным становится. возможно венда на мощной машине такое разрешение даст, но и то время от времени будут получаться пропадания.
на лине с ядром версии2 у меня вообще были большие траблы со стабильностью пауз, так что слип в 15-30мс возникал с периодом менее секунды.

В моём случае пауза определяется временем опроса драйвера виртуального порта системой. Это время составляет 1 мс. Вот 2 мс это и есть граница. Если система будет загружена выполнением большого количества дополнительных задач, то в таком случае спайки и на 30 мс неожиданностью не станут.
Особенность в том, что DeviceIoControl позволяет добавлять в поток дополнительные данные о статусе устройства. Делается это на уровне драйвера, как мне удалось понять. Но повторюсь, информация очень скудная и будет ли в ней прок, хотел посоветоваться со знающими людьми. Может быть и другим интересно будет. Упоминания об использовании этой функции в связке с IOCTL_SERIAL_LSRMST_INSERT находил преимущественно на зарубежных сайтах. У нас как-то об этом не упоминают или ни кто не пробовал с ней работать.

Попробовал DeviceIoControl попользовать. Ожидаемого результата не увидел. Видимо не реализована она на уровне драйвера или чтобы она работала правильно, надо что то ещё допилить, но пока не нашёл.
А можно ли запрячь драйвер, чтобы он возвращал явном виде о событии Idle в линии данных. То есть об отсутствии данных судить не по отсутствию Rxchar, а чтоб драйвер об этом сообщил.

Есть такая программка - Modbus Poll. Вот она как-то умудряется по паузам между сообщениями работать, причём при обработке сообщений, не являющимися в чистом виде Модбасовскими. Вот как она это делает, мне очень интересно.