[demiurg_spb 0]

а если банально сменить протокол modbus RTU

Не всё так просто. В АСУТП и КИП на базе интерфейса RS485 протокол Modbus-RTU является стандартом де-факто. И считается, что помимо любых других он должен быть обязательно.

Реже используется Modbus-ASCII и DCON. Остальные протоколы вообще крайне редки. В Росии тот-же ОВЕН долгое время продвигал свой собственный, весьма не плохой протокол, ну а в последнее время сдался и тоже реализовал во всех своих изделия Modbus-RTU.

[net 0]

Не всё так просто. В АСУТП и КИП на базе интерфейса RS485 протокол Modbus-RTU является стандартом де-факто. И считается, что помимо любых других он должен быть обязательно.

Реже используется Modbus-ASCII и DCON. Остальные протоколы вообще крайне редки. В Росии тот-же ОВЕН долгое время продвигал свой собственный, весьма не плохой протокол, ну а в последнее время сдался и тоже реализовал во всех своих изделия Modbus-RTU.

 

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

сделать(принять как вы написали дефакто) стандарт который очень неудобный и потом им пользоваться - хотя между BSC(1968 год) и MODBUS-RTU (2006) пропасть времени

 

сделать растяжки гробящие шину

проДУВАТь канал (хотя хоть какойто смысл есть)

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

сначала угробить промышленность - а потом запеть про импорто замещению

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

зашибись дефакто

 

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

 

типа а какого хрена у вас мерседес с винтиками не по госту?

 

или почему печатная плата в дюймах? помните проблему псведо дюймов? - которые 2.5 вместо 2.54?

вот этот дефакто из этой же серии

 

и еще раз ТС дали четкий ответ - хочешь снифер = делай(тем более они делают свои железки как я понял) МК приблуду. под WIN по честному не получится

что еще обсуждать?

 

[_Pasha 0]

Реже используется Modbus-ASCII и DCON.

вот мне лично ASCII нравится и я предпочтения ему отдаю, если нужно построить сеть из несложных девайсов.

 

В Росии тот-же ОВЕН долгое время продвигал свой собственный, весьма не плохой протокол, ну а в последнее время сдался и тоже реализовал во всех своих изделия Modbus-RTU.

А там еще было какое-то решение на базе Modbus-ASCII с заменой множества символов, так что они были прозрачны для остальных девайсов с "фирменным модбасом" с точностью до фрейма. причем, непонятно для чего сие вообще, если мастер один :rolleyes:

 

 

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

...

что еще обсуждать?

при чем тут... чуждый православию модбас появился эволюционным путем. Всё.

[zltigo 0]

1. Нет. Речь шла о продувке физ. канала. Совершенно закономерно, что мысль дошла до того, чтобы сделать продувку равную Т35 или Т15, но делать ее по максимуму, ессно, необязательно.

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

2. Нет! "на многих чипах" -это х51?

Абсолютно на всех, котрые ведут совместимость от 8250 чипа. Среди микроконтроллеров это, например все NXP включая ARМ. Ну и само собой все IBM-PC.

3. Да )) но не совсем. при Т15 остальной парк девайсов примет все что идет вплоть до Т35. Т.е. после продувки Т15 можно запросто потерять пакет. А после Т35 - нет.

Понятие правильности оно абсолютное и не надо называть "правильными" нарушения пртокола под устройства сделанные кем то с нарушением.

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

 

 

 

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

Не реализуемо. Прерывание отработает с задержкой, да и само прерывение будет выдано с задержкой на один бит в большинстве случаев. Так что получите, как минимум, лишний стартовый бит до того, как отключите передатчик.

 

 

[net 0]

Не реализуемо. Прерывание отработает с задержкой, да и само прерывение будет выдано с задержкой на один бит в большинстве случаев. Так что получите, как минимум, лишний стартовый бит до того, как отключите передатчик.

 

реализуемо

и кого волнует мусор на шине?

 

 

 

 

при чем тут... чуждый православию модбас появился эволюционным путем. Всё.

путем деградации

 

 

[AHTOXA 14]

Не реализуемо. Прерывание отработает с задержкой, да и само прерывение будет выдано с задержкой на один бит в большинстве случаев. Так что получите, как минимум, лишний стартовый бит до того, как отключите передатчик.

Стартового бита не будет, потому что ножка передатчика отключена. Так что нормуль.

[zltigo 0]

Стартового бита не будет, потому что ножка передатчика отключена. Так что нормуль.

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

 

 

 

реализуемо

и кого волнует мусор на шине?

Меня волнует мусор, которого могло-бы и не быть. Не люблю грязную работу и сам НЕ делаю свою работу грязно.

[net 0]

Меня волнует мусор, которого могло-бы и не быть. Не люблю грязную работу и сам НЕ делаю свою работу грязно.

 

ну тогда считаем что этого мусора нет - посколькку после него будет пауза и этот сигнал никому не помешают,

и он строго детерменирован и не представляет никакой опасности и совершенно чист перед протоколом

 

и в от личии от вашего невозможно - это все решает без проблем

 

[AHTOXA 14]

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

Нет, это вы влезли посреди обсуждения, и, как выясняется, совершенно НЕ понимаете, о чём речь. Но осуждать это вам не мешает.

На всякий случай, речь шла об вот этом методе:

А линию продуваю действительно так, как вы предположили. Поясню на примере STM32.

Отключаю функцию UART на ноге ТХ (перевожу в GPIO) и отправляю один байт на заранее рассчитанной скорости чтобы получилась пауза 3,5T (при этом нога TX вообще не дёргается).

Потом в прерывании TXC перевожу ногу обратно в режим UART-TX, меняю на правильный бодрейт и отправляю пакет, потом снова продуваю прежним способом.

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

Прерывания от таймера вообще не использую.

 

[zltigo 0]

Нет, это вы влезли посреди обсуждения, и, как выясняется, совершенно НЕ понимаете, о чём речь. Но осуждать это вам не мешает.

На всякий случай, речь шла об вот этом методе:

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

 

 

ну тогда считаем что этого мусора нет

Понял. Насрать соседу под дверь, насрать не считается, ибо дверь чужая и проблемы соседа - пусть чистит.

[net 0]

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

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

 

 

 

 

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

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

 

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

слив засчитан

 

[zltigo 0]

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

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

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

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

слив засчитан

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

[net 0]

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

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

 

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

 

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

 

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

 

[zltigo 0]

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

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

 

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

 

P.S.

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

[net 0]

Это БЕЗ проблем. Именно так бывает делаю, если приемопередатчик позволяет принимать эхо, то есть он RS422 а не RS485, или тестовое закольцовывание внутри UART не блокирует передачу.

 

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

 

P.S.

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

 

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

 

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

 

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

 

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