Альтернативы CAN для передачи с несколькими ведущими

Как обычно в эти дни я борюсь с нехваткой компонентов. Как и в случае полной переделки плат, поскольку они дают нам сроки выполнения заказа в 2023 году.

На данный момент у меня есть эта линейка продуктов, в которой платы общаются друг с другом через CAN по кабелю категории 5; по историческим причинам микроконтроллеры не имеют встроенного контроллера, и мы используем сочетание контроллеров CAN, подключенных к Microchip и TI SPI (кстати, последнее семейство Microchip и TCAN455x, по сути, представляет собой один и тот же IP-адрес Bosch, заключенный в SPI). Жаль, что они сейчас недоступны в значительных количествах, поэтому мне нужно перепроектировать всю архитектуру.

Моей первой идеей был бы RS485: практически тот же носитель, но без арбитража. Большая проблема заключается в том, что вся архитектура является мультимастерной, а не мастер-слейв, как, скажем, Modbus. У меня есть назначенный сетевой мастер для различных целей, но большая часть связи является одноранговой.

Как обсуждалось в разделе Можно ли считать RS485 шиной с несколькими ведущими? реальная проблема заключается в конкуренции за шину, которая может нанести непоправимый ущерб (в зависимости от типа приемопередатчика, хорошие просто ограничивают ток).

Ссылочный слой полностью под моим контролем. Я думаю о какой-то передаче токена, арбитрируемой мастером сети (если это не удается, допустимо остановить сеть).

Есть ли какая-то другая альтернатива? Другой идеей может быть использование приемопередатчиков CAN вместо приемопередатчиков RS485 для получения доминантных/рецессивных свойств и перехода на CSMA/CD (прослушивание результатов на линии). Трафик периодический, но есть свободная полоса пропускания, а шина короткая (менее 10 м), поэтому коллизии должны быть управляемыми. Ethernet кажется излишним и нуждается в концентраторе (ну, за исключением коаксиального Ethernet старого стиля: D). Я пропустил какую-то полезную технологию, которую можно здесь использовать?

Сколько досок в автобусе? Какие скорости должны поддерживаться?
Ваши мысли звучат правильно. Я думаю, вы можете обнаружить конкуренцию на RS485 за дополнительную плату. Но с CAN PHY это проще. Прежде всего, если у вас достаточно пропускной способности (она вам все равно нужна), вы сможете избежать сложности CSMA/CD. Если бы нам пришлось, я бы назвал это «назначенным мастером», который в конечном итоге устанавливает коммутатор P2P на BUS. Кстати, я на той же лодке, начал менять детали на доступные. В противном случае ждать около года без обещания. В конце концов, он остановился на совершенно новых печатных платах, продолжая конкурировать с другими инженерами из-за ограниченного запаса. Печально..., кого винить?
Немного стучит CAN с внешним дифом. усилители уже не звучат так безумно, да
ИМХО, вы должны придерживаться существующей проводки и приемопередатчиков CAN. Это упростит переход, когда проблемы с поставками закончатся. Отслеживайте состояние Rx перед началом передачи и используйте логический элемент XOR на Rx/Tx, направленный на дополнительный контакт с прерыванием, для обнаружения коллизий во время передачи. Таким образом, вы можете написать драйвер UART, который будет вести себя почти как контроллер CAN, поэтому ваш основной код не потребует много изменений. Вам не нужно сохранять точный формат кадра, но сделайте его выровненным по байтам и сохраните назначение идентификатора таким же.
@jay, ваш «назначенный мастер»… передача токена, только что сделанная центральной организацией. Фонд H1 делает это
Бит @AndrejsGasilovs было бы проще, вы не сказали, что он будет работать на килобитных скоростях: D безумие начнется, когда мы вернемся к токовой петле 60 мА.
Если вы перепроектируете, то, возможно, стоит рассмотреть лучший MCU со встроенным CAN-контроллером?
@LorenzoMarcantonio Это отличный момент. Я согласен, что «передача токена» тоже может сделать, или то же самое... Я говорю вам это искренне. Не исключайте этого уже и не думайте, что это абсурд. Вы поймете, вы тоже это поймете, в какой-то момент: шаг назад, а смотреть шире. Еще несколько шагов назад, и вы увидите, что все (или многие) различия исходят только от того, где вы находитесь в данный момент. С другой стороны, надеюсь, вам не придется продолжать рожать (оставаться в родах звучит странно для человека, не говорящего по-английски) до этого времени. :)

Ответы (2)

Можно ли считать RS485 шиной с несколькими ведущими?

В принципе да.

Конфликт на шине в этом контексте может быть выполнен с использованием двух приемопередатчиков RS485: один записывает данные, а другой читает и подтверждает или нет данные, записанные другим.

Это довольно дорого, особенно в наши дни нехватки чипов.

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

https://en.wikipedia.org/wiki/Carrier-sense_multiple_access_with_collision_avoidance

Зачем вам нужны два трансивера для работы, которая обычно выполняется с помощью одного трансивера?
Для обнаружения коллизий вы должны прочитать отправленный вами пакет. Это самый простой способ обнаружить конкуренцию на шине. Приемопередатчик RS485 обычно представляет собой полудуплексное устройство (либо RX, либо TX в любой момент).
8-контактные приемопередатчики в стиле MAX485 имеют отдельные контакты включения драйвера и приемника (второй часто активный низкий уровень), которые обычно связаны вместе с одним GPIO, потому что вы обычно либо передаете, либо принимаете. Ничто не мешает вам управлять ими независимо или привязать ресивер к постоянно низкому уровню. Одного трансивера должно быть достаточно :-)
нет необходимости во втором приемопередатчике, либо используйте полный дуплекс, либо просто привяжите для этого разрешение приема к 8-контактным частям!

Если ваша шина немного загружена, и вы можете смириться с некоторой задержкой, то я думаю, что это выполнимо с RS-485.

Несколько лет назад я сделал систему с несколькими мастерами на RS-485. Каждый пакет содержал адрес отправителя и получателя, а также «тип» пакета. Типы ниже 128 были отправной командой и должны были быть подтверждены узлом назначения с той же командой +128 (вы не можете предположить, что пакет был получен правильно, не так ли?).

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

  1. Если пакет должен быть подтвержден (целью команды является устройство), то шина свободна.

  2. Если пакет представляет собой команду, то некоторое время шина не будет свободна: ответит узел назначения.

  3. Если пакет является подтверждением, то шина (на мгновение) свободна.

«Мгновенно свободное» — это ситуация, когда каждое устройство потенциально может начать передачу. С этого момента каждое устройство ждет сотые доли секунды в зависимости от своего собственного адреса: чем меньше адрес, тем выше приоритет. Мастер (да, был узел важнее других), имевший адрес 1, всегда был свободен для отправки пакета. Устройство с адресом 12 всегда должно было ждать 12 секунд перед попыткой передачи, но это было вполне приемлемо.

Схема выше уменьшает возможность коллизий, но ее можно ослабить, например если время задержки разделить на 10, устройство с адресом 12 просто ждет 1 (ну 2) cs, а коллизия происходит только если другое устройство в диапазоне 10-19 пытается сделать то же самое.

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

В первой системе не было арбитража шины. В случае коллизии узел-отправитель просто повторно отправляет пакет до тех пор, пока не будет получено подтверждение. Неточность часов различных устройств, рано или поздно, давала каждому устройству возможность инициировать связь.

Однако иногда два устройства соревновались в течение нескольких секунд, мешая друг другу. Поэтому я увеличил время ожидания (подтверждения) для отправляющего узла, основываясь на его адресе, и это сработало достаточно хорошо. Но в последнее время я обнаружил, что лучше всего стараться избегать столкновений, насколько это возможно, и предпочел ввести эту фиксированную задержку. Все зависит от приложения.

Вы только что описали CSMA/CD; случайная отсрочка обычно решает ваши проблемы со временем
@LorenzoMarcantonio: я бы сказал нет, потому что в том, что я описал выше, нет мониторинга во время передачи . Это еще больше улучшит ситуацию, но я не уверен, что устройство на RS-485 может точно определить, что получают другие устройства, из-за задержек на линии. В любом случае, это тоже не должно быть больно.
Альтернативы CAN для передачи с несколькими ведущими
СпросиСетьПолитика конфиденциальности1y, 0v