Это не сильно страшно, все трансиверы, по крайней мере которые используем мы имеют защиты и ограничения по выходному току. Такчто самое страшное что может произойти это потеря данных на шине.
Расширение как раз таки позволяет устройствам решить что они хотят уведомить систему о произошедшем событии, а арбитраж позволяет разрулить при этом коллизии. Проблема в другом. Что делать с сообщением дальше ? где-то должно быть правило, как реагировать на такое сообщение. На данный момент всем дирижирует мастер с линуксом, потомучто на нем есть сервис wb-rules, который позволяет написать и обработать любой сценарий реакции на событие.
во втором разделе "Поиск решения" был ответ на ваш вопрос, звучит он так:
Мы хорошо умеем делать устройства с Modbus RTU и RS-485 — под это заточены наши процессы в разработке и производстве.
Поэтому нам было важно сохранить наш основной протокол Modbus RTU, а значит единственное решение — разработка расширения протокола, используя заложенные разработчиками протокола Modbus возможности.
Мы прекрасно понимаем физические и схемотехнические особенности шины RS485 и спроектировали протокол в соответствии с этим. Отвечает всегда одно устройство. Для того чтобы решить кто отвечает проводится арбитраж. В том же CAN рецессивный бит это ни что иное как молчание в течение одного периода. В качестве рецессивного бита арбитража мы используем молчание в течении передачи одного БАЙТА. А в качестве доминантного собственно включение передатчика и отправку одного байта со значением 0xFF (только стартовый бит отличается от IDLE состояния шины) если желающих передать доминантное состояние несколько, они делают это синхронно. Все активные передатчики на линии передают одно и тоже состояние. Следовательно нет перетекания тока между передатчиками.
нет не пробовали. у линукса (который выступает мастером) очень сложно делать вещи вроде 'мастер переводит пин UART_RX в GPIO input', мы старались сделать так чтобы мастер оперировал лишь уартом. ито не критичным ко времени.
Когда количество произведенных устройств перевалит за 4млрд мы будем вопервых очень рады. А во вторых просто сделаем новую команду сканирования в которой арбитраж будет происходить по еще более длинному серийнику.
Достаточно очевидная идея. С таймером пришлось конечно заморочится. Однако с GPIO мы поступили проще. В качестве доминантного/рецессивного слота используется сам USART фрейм который просто передает FF в случае доминантного бита или молчит в случае рецессивного. Немножко теряем время, зато используем все аппаратное и не морочим голову приемнику на стороне линукса. несколько фреймов FF в начале он без проблем отфильтрует.
Технически это коллизия и будет. Но изза того что несколько устройств почти одновременно передают один и тотже байт с точки зрения электричества это не страшно. А с точки зрения протокола все передачи доминантные. Все молчания рецессивные. К томуже если устройство желает передать данные, но произошел рассинхрон и приемник обнаружил чужой стартбит, то передачи даже не будет. Зато все кто передавать не планировал точно узнают была в этот момент передача другими устройствами или нет.
Это не сильно страшно, все трансиверы, по крайней мере которые используем мы имеют защиты и ограничения по выходному току. Такчто самое страшное что может произойти это потеря данных на шине.
вышла новая статья в которой в том числе описана физика работы шины 485 и там объяснено что такое увы не работает. физика не позволяет "прижать шину"
Расширение как раз таки позволяет устройствам решить что они хотят уведомить систему о произошедшем событии, а арбитраж позволяет разрулить при этом коллизии. Проблема в другом. Что делать с сообщением дальше ? где-то должно быть правило, как реагировать на такое сообщение. На данный момент всем дирижирует мастер с линуксом, потомучто на нем есть сервис wb-rules, который позволяет написать и обработать любой сценарий реакции на событие.
во втором разделе "Поиск решения" был ответ на ваш вопрос, звучит он так:
Мы хорошо умеем делать устройства с Modbus RTU и RS-485 — под это заточены наши процессы в разработке и производстве.
Поэтому нам было важно сохранить наш основной протокол Modbus RTU, а значит единственное решение — разработка расширения протокола, используя заложенные разработчиками протокола Modbus возможности.
Мы прекрасно понимаем физические и схемотехнические особенности шины RS485 и спроектировали протокол в соответствии с этим. Отвечает всегда одно устройство. Для того чтобы решить кто отвечает проводится арбитраж. В том же CAN рецессивный бит это ни что иное как молчание в течение одного периода. В качестве рецессивного бита арбитража мы используем молчание в течении передачи одного БАЙТА. А в качестве доминантного собственно включение передатчика и отправку одного байта со значением 0xFF (только стартовый бит отличается от IDLE состояния шины) если желающих передать доминантное состояние несколько, они делают это синхронно. Все активные передатчики на линии передают одно и тоже состояние. Следовательно нет перетекания тока между передатчиками.
нет не пробовали. у линукса (который выступает мастером) очень сложно делать вещи вроде 'мастер переводит пин UART_RX в GPIO input', мы старались сделать так чтобы мастер оперировал лишь уартом. ито не критичным ко времени.
Когда количество произведенных устройств перевалит за 4млрд мы будем вопервых очень рады. А во вторых просто сделаем новую команду сканирования в которой арбитраж будет происходить по еще более длинному серийнику.
Все верно. Вопросы фактически звучат как "Кто еще здесь ?" и "Что еще нового ?"
Достаточно очевидная идея. С таймером пришлось конечно заморочится. Однако с GPIO мы поступили проще. В качестве доминантного/рецессивного слота используется сам USART фрейм который просто передает FF в случае доминантного бита или молчит в случае рецессивного. Немножко теряем время, зато используем все аппаратное и не морочим голову приемнику на стороне линукса. несколько фреймов FF в начале он без проблем отфильтрует.
Технически это коллизия и будет. Но изза того что несколько устройств почти одновременно передают один и тотже байт с точки зрения электричества это не страшно. А с точки зрения протокола все передачи доминантные. Все молчания рецессивные. К томуже если устройство желает передать данные, но произошел рассинхрон и приемник обнаружил чужой стартбит, то передачи даже не будет. Зато все кто передавать не планировал точно узнают была в этот момент передача другими устройствами или нет.