Перейти к содержанию
    

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Коллеги я привёл реально работающий не один год алгоритм.

Что бы там ни говорили я обхожусь вообще без прерываний таймера.

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

Никаких ложных стартовых битов никогда не возникает.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

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

я вам показал, что лишним байтом этот вопрос решается

какой вопрос такой ответ

 

 

слив я вам засчитал

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

 

 

Коллеги я привёл реально работающий не один год алгоритм.

Что бы там ни говорили я обхожусь вообще без прерываний таймера.

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

Никаких ложных стартовых битов никогда не возникает.

Да, это решение не универсальное и не применимо напрямую в устройствах без прерывания TXC.

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

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

 

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

:biggrin:

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Коллеги я привёл реально работающий не один год алгоритм.

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

Что бы там ни говорили я обхожусь вообще без прерываний таймера.

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

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

Никаких ложных стартовых битов никогда не возникает.

Да, это решение не универсальное и не применимо напрямую в устройствах без прерывания TXC.

Естественно не возникает, если можно использовать честое имеющеюся "TXC".

Без него и попытка фокуса, с посылкой "дополнительного байта" с котрым здесь, как курица без головы :( носится net не помогает.

 

 

слив я вам засчитал

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

 

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

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Это решение пришло из-за нехватки таймеров в младших AVR-ках более 10 лет назад. Я тогда тоже не продувал))) Даже более того, умудрился CRC16 считать косячно - поменял по ошибке в modbus фрейме старший байт с младшим, подумал, что сетевой порядок байт во всём протоколе включая и CRC:(.

Конечно, всегда хочется универсальности и, думаю, что сяду, да переиграю всё и вся, но блин, время есть деньги)))

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Да ладно))) В прерываниях ТХ и RX ищем дырку 1,5T, а в фоновой задаче ищем дырку в 3,5Т или более - не критично ко времени

По хорошему и 3,5Т критично. У мастера есть полное право гнать бродкаст пакеты с таким разделителем. А уж другому слейву ответить через СРАЗУ после получения фрейма вообще никто запретить не может. Не поймали при опросе разделитель между бродкастами или между запростом и быстрым ответом и ага :(.

Фреймер MODBUS отличается дубовой простотой, но плата за нее НЕУКОСНИТЕЛЬНО-ЖЕСТКОЕ выполнение этих простых требований. Увы :(.

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Это понятно и учитывается.

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Вот именно по этому методу окончание передачи и НЕ работает, если, как уже писал, нет прерывания по окончанию передачи. И прерывание по загрузки регистра хранения в регистр сдвига, как у 8250 совместимых чипов никак не канает.

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

А уж выкручиваться после этого вообще некрасиво. Все же всё видят и понимают.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

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

А уж выкручиваться после этого вообще некрасиво. Все же всё видят и понимают.

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

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

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

 

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

После извинений могу Вам еще раз обьяснить, то, что Вам непонятно.

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

У меня к Вам один вопрос - извиняться будете?

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Так что ошибку признаю.

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

 

 

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

День добрый всем.

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

День добрый всем.

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

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

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

Поделиться сообщением


Ссылка на сообщение
Поделиться на другие сайты

Присоединяйтесь к обсуждению

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

Гость
К сожалению, ваш контент содержит запрещённые слова. Пожалуйста, отредактируйте контент, чтобы удалить выделенные ниже слова.
Ответить в этой теме...

×   Вставлено с форматированием.   Вставить как обычный текст

  Разрешено использовать не более 75 эмодзи.

×   Ваша ссылка была автоматически встроена.   Отображать как обычную ссылку

×   Ваш предыдущий контент был восстановлен.   Очистить редактор

×   Вы не можете вставлять изображения напрямую. Загружайте или вставляйте изображения по ссылке.

×
×
  • Создать...