Нам нужен был помехозащищенный, недорогой, многоточечный, многоканальный (в реальном времени и распределенный) протокол, и, кажется, только CAN-шина отвечает этим требованиям.
Поскольку для очень недорогих микроконтроллеров (таких как STM32F0) нет контроллеров can (аппаратного обеспечения уровня канала передачи данных) и простого в использовании API, который мы могли бы найти для начала, мы не можем рассматривать шину CAN в качестве коммуникационного стека по умолчанию в наших проектах. .
Поэтому я думаю, что могу реализовать действительно крошечный уровень, который позволит реализовать любой протокол (например, Modbus) через UART через физический уровень CAN, используя при этом обнаружение конфликтов данных, используя 1 начальный байт в качестве приманки.
Кроме того, я полагаю, что любое оборудование I2C или 1-Wire может напрямую использовать передатчик CAN для своего протокола шины с помощью простого взлома диода-резистора, аналогичного взлому диода-резистора 1-wire <-> uart.
Я подозреваю, что что-то упускаю, поскольку этот подход дает много преимуществ при относительно небольших усилиях, хотя для этой цели я не смог найти никакой реализации.
Есть ли какие-либо скрытые последствия этого опроса?
1-Wire (со взломом UART) не работает через приемопередатчик CAN MCP2551, так как приемопередатчик начинает питаться нулем (доминантным) в конечной точке (сторона 1-Wire), что не позволяет любому устройству записать «1» на шину. пока функция «постоянного обнаружения TXD» трансивера не возьмет на себя управление. Так что с точки зрения "простого 1-wire расширителя диапазона" он бесполезен. Это означает, что приемопередатчик RXD/ TXDконтакты CAN-шины не могут быть преобразованы в линию с открытым стоком с помощью простого взлома преобразователя 1-wire / uart, поэтому он также не будет работать с шиной I2C.
Использование 1 байта в качестве приманки неэффективно, поскольку мы должны использовать только 1 бит в качестве нуля, а это означает, что мы должны использовать 100 бит только для адресации, если мы планируем подключить 100 устройств на одной шине, потому что, хотя мы могли бы обнаружить, что кто-то еще говоря в то же время, но мы не можем определить приоритет (например, если node#0b101и node#0b011говорит одновременно, мы будем читать, 0b001что является одним и тем же ответом, когда node#0b011и node#0b001говорит. Таким образом, node#011мы никогда не узнаем, имеет ли он приоритет или нет.) Итак, это невозможно, если мы не используем технику битового удара и читаем RXпорт по крупицам. Что не имеет смысла, потому что это заново изобретает шину CAN, как уже упоминалось.
В общем, я бы всегда использовал CAN. Вам так или иначе понадобятся линейные драйверы/ресиверы. Трансиверы CAN так же хороши, как и любые другие, но тогда проще использовать остальную часть CAN. Основное отличие от CAN заключается в том, что нижние уровни протокола хорошо продуманы и доступны по низкой цене, интегрированы непосредственно во многие микроконтроллеры. RS-485 выдает вам электрические характеристики, а дальше вы сами.
Сделать все детали многоабонентской шины правильными и надежными намного сложнее, чем думает большинство людей. Используйте КАН. Это все было разработано и сделано для вас. Вы отправляете целые пакеты на уровне прошивки. Аппаратное обеспечение заботится об обнаружении коллизий, повторных попытках, генерации и проверке контрольной суммы CRC. Это все, что вы хотите, и с CAN вы получите их практически бесплатно.
Существуют дискретные контроллеры (MCP2515), для которых требуется SPI и несколько других GPIO.
Это неправда, что CAN недоступен на небольших деталях Cortex m0. Посмотрите на LPC11C22; он имеет встроенный приемопередатчик CAN. Или STM32F042. NXP стоит 3 доллара, STM32 около 2 долларов, но требует внешнего трансивера, что увеличивает стоимость.
Если дополнительные затраты на часть с контроллером CAN не вписываются в ваш проект, я предполагаю, что вы должны взимать очень большую плату за проектирование, чтобы изобрести собственную систему программного обеспечения CAN и быть в состоянии безубыточности. Создание тестовых примеров и доказательство того, что ваша собственная система шины данных надежна, защищена от помех, «свободна» от битовых ошибок, обнаружения коллизий, арбитра шины и т. д., — непростая задача.
Я сделал именно это один раз. Я не знаю, компилируется ли он до сих пор (сейчас я использую беспроводную связь), но он работает очень хорошо, если вы все сделаете правильно.
Раньше у Microchip был чип CAN, который часто выходил из строя, если было слишком большое синфазное напряжение или что-то в этом роде. Адаптеры переменного тока могут вызвать режим отказа из-за их дырявого дерьма переменного тока IIRC. Потом они выпустили новую версию. Я забыл номер детали, но поищите.
Однако I2C требует более сложного взлома. Приемопередатчик обычно не может работать в обе стороны без более умного чипа, сообщающего ему, какое направление используется (хотя такие действительно существуют). MCU UART не имеет этой проблемы, потому что микроконтроллер знает о отдельных выводах TX и RX приемопередатчика, I2C использует двунаправленные провода.
Дэйв Твид
церемония