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

Коллеги я привёл реально работающий не один год алгоритм.
Что бы там ни говорили я обхожусь вообще без прерываний таймера.
Таймштамы принятых и посланных байт получаю с помощью вычисления разницы значений счётчика, заряженного на цикличный счёт таймера (например 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мс возникал с периодом менее секунды.