см. "многозадачность" в конце #82
см. "многозадачность" в конце #82
а если на секунду забыть несколько размытое требование в стандарте, которое по моему скромному мнению, определяет именно тот интервал, через который начинает отвечать именно ведомый. После приема ответа мастером, зачем ему выдерживать паузу, если ведомые уже готовы принять телеграмму?Сообщение от capzap
вот какие-то диаграммы, и что с ними делают программисты микроконтроллеров в slave-устройствах ввода-вывода - одним программистам известно. Сомневаюсь что у кого-то "ума хватило" при написании алгоритма ведомого устройства задать "мертвую зону" длиной 3,5 символа после ответа мастеру, в течение которой запросы игнорируются/входной буфер очищается.
т.е. Вы вобще не верите что прерывания в любых устройствах могут задержать ответ по последовательному порту. Эта пауза ни как не связана с обработкой. Она нужна, как и написано, для того чтоб в сети была тишина и все кто хотел что то сказать (мастер или ведомые) вытолкали свой передающий буфер и не создали помех для очередного запроса/ответа
а по поводу всего остального, еще раз обозначу: по физической линии на одной и той же скорости запрос/ответ по времени проходит за одно и тоже значение плюс некоторая составляющая из-за какого нибудь прерывания, эта составляющая на столько мала, что на неё отводят 1,5 символа между фреймами. Появление результата запроса конечно же зависит от времени цикла, первое что приходит в голову это вывести опрос в отдельную задачу. Для меня есть одно но, во первых не попадался мне плк двух и более ядерный, чтоб была настоящая многозадачность, во вторых в таких системах нет понятий как volatile и synchronized, что будет происходить, если опросная задача захватила буфер,а в это время основная задача по прерыванию начала его читать. Остается держать в ОЗУ два дублирующих буфера (в случае одного опрашиваемого ведомого), а избыточная трата ресурсов может привести к нестабильности системы в целом, а не только обмена
Bad programmers worry about the code. Good programmers worry about data structures and their relationships
среди успешных людей я не встречала нытиков
Барбара Коркоран
Для нормального обмена линия RS-485 должна быть захвачена как минимум с одной стороны. По этой причине после приема пакета от Master Slave должен сразу захватить линию. Master после передачи пакета какое-то время (время тишины) тоже удерживает линию. Далее Master отпускает линию и Slave начинает передачу пакета отклика.
смысл паузы, я понимаю так же как и Вы. Но приведите раумное обоснование необходимости паузы после того, как ведомый ответил и мастер принял ответ полностью
а смотрите, какая прелесть:
https://youtu.be/D6aOwL4Km98?list=PL...r-2PC0-F6-duWi
особенности работы полупроводниковых драйверов RS-485.
Если кто писал свой вариант библиотеки modbus, выдерживаете ли вы паузу после ответа ведомого, используя таймеры? Интересен ваш опыт.
Затем, чтобы другие слейвы подготовились.
В этой теме уже ответили все ветераны форума)) Как именно слейвы должны подготовиться? Есть ли у кого-нибудь пример программы микроконтроллера (ну мало ли откуда)
Я в своем посте ответил на ваши вопросы. Полупроводниковые драйверы RS-485 тут не при чем, все делается на программном уровне.
Ваши права
Ответить с цитированием
