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

    

net

Свой
  • Публикаций

    858
  • Зарегистрирован

  • Посещение

Репутация

0 Обычный

Информация о net

  • Звание
    Знающий
  1. сниффер ком порта

    QUOTE (zltigo @ Sep 28 2016, 17:21) Не обидно. На убогих на руси обижаться не принято. А Вы демонстрируете именно убожество ума, даже в квадрате, поскольку считаете возможным еще и заявлять "слив я вам засчитал". Это уже плинтус . не расстраивайтесь вы так.
  2. сниффер ком порта

    QUOTE (zltigo @ Sep 28 2016, 17:06) Мне не надо. А Вам учиться думать, прежде чем писать, очень надо. Мусора в интернете и без Вас достаточно . Ваши глупости уже перестают заслуживать ответов на них . я вам показал ответ на ваш глупый вопрос - что НЕВОЗМОЖНО узнать когда ушел байт я вам показал, что лишним байтом этот вопрос решается какой вопрос такой ответ слив я вам засчитал обидно - понимаю - но вы сами так сделали QUOTE (demiurg_spb @ Sep 28 2016, 17:11) Коллеги я привёл реально работающий не один год алгоритм. Что бы там ни говорили я обхожусь вообще без прерываний таймера. Таймштамы принятых и посланных байт получаю с помощью вычисления разницы значений счётчика, заряженного на цикличный счёт таймера (например HPET под win, либо DWT->CYCCNT для Кортексов). Никаких ложных стартовых битов никогда не возникает. Да, это решение не универсальное и не применимо напрямую в устройствах без прерывания TXC. нужно конкретно разбираться с тем когда у вас возникают прерывания - очень много контролеров имеют массу всяких прерываний по разному поводу и вопрос здесь выскочил о вполне конкретном прерывании которое возникает когда освобождается буферный регистр на передачу. при этом в сдвиговом регистре есть те самые данные которые еще передаются. ничего страшного в этом нет. все вопросы решаются возможно и у вас все правильно если прерывания возникают в правильный для вашего алгоритма момент лень разбираться. просто это надо учитывать
  3. сниффер ком порта

    QUOTE (zltigo @ Sep 28 2016, 16:59) Это БЕЗ проблем. Именно так бывает делаю, если приемопередатчик позволяет принимать эхо, то есть он RS422 а не RS485, или тестовое закольцовывание внутри UART не блокирует передачу. Но речь шла о ДРУГОМ, неработоспособном методе. Так что про больную голову все правильно. P.S. С 1984 года я познал множество извращений с UART и поначалу наступил на некоторое количество гараблей, так что дабы меня чем нибудь удивить, надо очень постараться. спокойно сосчитайте до 1000 или сколько вам надо метод отправки лишнего байта работает чтобы узнать ушел ли предыдущий байт то что вы пользуетесь кривыми протоколами и у вас возникают проблемы это ваш выбор так что про больную голову возвращаю
  4. сниффер ком порта

    QUOTE (zltigo @ Sep 28 2016, 16:23) Вообще это даже НЕ шум. Лишний стартовый бит означет дополнительный байт фрейма идущий БЕЗ паузы, попадающий MODBUS фрейм и ЛОМАЮЩИЙ его. Если фреймер байтствффинговый, тогда это мусор, который тоже есть признак того, что "программист" засранец . Вот уж точно с про Вас - с больной головы на здоровую. я уж не говорю о том, что слушая что передаете вы спокойно отследите уход своего байта так что про больную голову не надо
  5. сниффер ком порта

    QUOTE (zltigo @ Sep 28 2016, 16:13) Вот именно по этому методу окончание передачи и НЕ работает, если нет прерывания по окончанию передачи. И прерывание по занрузки регистра в регистр сдвига, как у 8250 совместимых чипов никак не канает. еще как канает - и не вы ли тут писали по поводу стойкости к борьбе с шумами? QUOTE (zltigo @ Sep 28 2016, 16:13) вы нагадили тем, что сказали что метода получить, что байт ушел нет!!! я вам привел метод как можно узнать что байт ушел, разговор шел именно о том как узнать что байт ушел!!! вы начинаете выворачиваться с шумами на шине и тд слив засчитан
  6. сниффер ком порта

    QUOTE (zltigo @ Sep 28 2016, 15:33) Меня волнует мусор, которого могло-бы и не быть. Не люблю грязную работу и сам НЕ делаю свою работу грязно. ну тогда считаем что этого мусора нет - посколькку после него будет пауза и этот сигнал никому не помешают, и он строго детерменирован и не представляет никакой опасности и совершенно чист перед протоколом и в от личии от вашего невозможно - это все решает без проблем
  7. сниффер ком порта

    QUOTE (zltigo @ Sep 28 2016, 14:52) Не реализуемо. Прерывание отработает с задержкой, да и само прерывение будет выдано с задержкой на один бит в большинстве случаев. Так что получите, как минимум, лишний стартовый бит до того, как отключите передатчик. реализуемо и кого волнует мусор на шине? QUOTE (_Pasha @ Sep 28 2016, 14:24) при чем тут... чуждый православию модбас появился эволюционным путем. Всё. путем деградации
  8. сниффер ком порта

    QUOTE (demiurg_spb @ Sep 28 2016, 13:55) Не всё так просто. В АСУТП и КИП на базе интерфейса RS485 протокол Modbus-RTU является стандартом де-факто. И считается, что помимо любых других он должен быть обязательно. Реже используется Modbus-ASCII и DCON. Остальные протоколы вообще крайне редки. В Росии тот-же ОВЕН долгое время продвигал свой собственный, весьма не плохой протокол, ну а в последнее время сдался и тоже реализовал во всех своих изделия Modbus-RTU. конечно не просто - мы же всегда любим делать все через одно место сделать(принять как вы написали дефакто) стандарт который очень неудобный и потом им пользоваться - хотя между BSC(1968 год) и MODBUS-RTU (2006) пропасть времени сделать растяжки гробящие шину проДУВАТь канал (хотя хоть какойто смысл есть) использовать приемо передатчики без сдвига - хотя даже отечественные драйвера все уже правильные - где вы только неправильные достаете ;-) сначала угробить промышленность - а потом запеть про импорто замещению когда уже все угроблено- начать делать страховые запасы зашибись дефакто правда потом начинаем покупать все иностранное и при этом качать права чтобы все соответсвовало нашим стандартам типа а какого хрена у вас мерседес с винтиками не по госту? или почему печатная плата в дюймах? помните проблему псведо дюймов? - которые 2.5 вместо 2.54? вот этот дефакто из этой же серии и еще раз ТС дали четкий ответ - хочешь снифер = делай(тем более они делают свои железки как я понял) МК приблуду. под WIN по честному не получится что еще обсуждать?
  9. сниффер ком порта

    QUOTE (_Pasha @ Sep 28 2016, 13:25) как Вы себе это представляете для случая, когда прибору требуется модбас как стд интерфейс? я представляю это себе так 1 сначало люди придумали проблему 2 а потом извращаются чтобы ее решить ТС предложили поставить МК на котором перевести идиотский модбас в нормальный поток RS232 (для примера - а то сейчас опять налетите USB CAN и тд и тп) либо со штампами времени либо ... не буду дальше причем народ поделился опытом, что не получается честно отработать даже минимальные скорости этого идиотского протокола на win все !!! о чем еще говорить? более того он использует переходник USB-RS232 это и есть фактически такое устройство которое ему и прделагали сделать самому только с его функционалом
  10. сниффер ком порта

    QUOTE (AHTOXA @ Sep 28 2016, 13:07) Но если у вас появится конкурент, который сделает устройство, способное работать в сети без растяжек, то его устройство будет лучше. И, весьма вероятно, что заказчики предпочтут его. а если банально сменить протокол modbus RTU на протокол использующий byte stuff - то все обсуждаемые проблеммы данного топика просто исчезнут сами собой - включая начальную тему про сниффер ;-)
  11. сниффер ком порта

    QUOTE (_Pasha @ Sep 28 2016, 10:42) да модбас RTU, что там оговаривать вот нефига я его не понимаю - поэтому обсуждать его не могу ;-)
  12. сниффер ком порта

    QUOTE (zltigo @ Sep 27 2016, 23:46) 2) На многих чипах нереализуемый, ибо прерывания окончания передачи просто нет, а есть только освобождение буферного регистра. В том, что Ваше утверждение "будет принят битый пакет" ошибочное. Это из мусора будет сформирован битый пакет, а передаваемый пакет пойдет очищенным от мусора. 2) легко реализуемо путем пердачи лишнего байта - и как только лишний байт уйдет из регистра значит передача нужного байта выполнена по вопросу битый пакет надо договориться о терминах и о каком протоколе мы говорим после этого эту тему можно обсуждать - а то у нас тут уже все в одну кучу смешалось и модбас и байт стаффиг и растяжки и особенности прерываний и тд и тп и понять о чем идет речь весьма затруднительно а тут важна совокупность того о чем мы говорим - типа синегирия в полном виде ;-) и уж если придераться к словам - из мусора будет сформирован битый пакет - он что не будет никем принят? хотя тут опять возникает вопрос что значит ПРИНЯТЬ быитый пакет ;-)
  13. сниффер ком порта

    QUOTE (demiurg_spb @ Sep 27 2016, 17:45) А линию продуваю действительно так, как вы предположили. Поясню на примере STM32. возникает вопрос смысл продувки? если помехи не было - то и продувать то особенно нечего - бит синхронизация и так есть если же была помеха то продувай не продувай будет принят битый пакет в чем смысл?
  14. сниффер ком порта

    QUOTE (juvf @ Sep 27 2016, 09:49) QUOTE (AHTOXA @ Sep 26 2016, 00:10) есть такое... но в модбас такое не прокатит... если только в 4 раза скорость понизить, вдунуть 0хфф, потом поднять скорость и слать пакет. извиняюсь перед ТС за офтоп. очень много букв но вы даже не удосужились прочитать о чем пишет Антоха !! он же написал о стаффинг протоколах !!! а вы это приписываете, что для модбас не прокатит естественно потому что это для другого случая он написал !!! что вобщемто и подтвеждает мысль, что с модбас не все нормально более того например BSC известен ( применен метод байт стаффинга) с 68 года прошлого века и каким образом вылез модбас со своей временной паузой для синхронизации которые с трудом можно реализовать - не дай бог еще и скорость поднять то вообще труба будет, монотонность потока и дурацкими растяжками гробящие сигнал и ничего не дающие не очень понятно
  15. сниффер ком порта

    QUOTE (zltigo @ Sep 26 2016, 14:47) ктож спорит то? все дело в том - что зачастую даже когда приводят 2+2=4 нужно не только увидеть - но и прочувствовать а это не всем дано бывает, и бывает очень долго приходится с этим свыкаться особенно когда типа ты был молодцом ;-) а тут вдруг раз и валенком по голове терпимее надо быть - это я и себе говорю тоже ;-)