Мне нужно передавать сигналы примерно на пять метров. Мои входные сигналы совместимы с I2C или SPI, но, к сожалению, не стоит передавать их на такое большое расстояние. Поэтому я думал о преобразовании сигнала I2C или SPI в сигнал CAN (и обратно). Каков наилучший подход к преобразованию этих сигналов друг в друга без использования (слишком много) внешних компонентов? Мой первый подход заключался в использовании MCP2515, но там уже нужны внешние часы. Есть ли более дешевый способ сделать это?
Если у вас есть проблемы с последовательными протоколами, такими как SPI, на расстоянии более 5 метров, то простой ответ — снизить тактовую частоту для получения данных от удаленных устройств. Переход на что-то вроде CAN не является простым решением, на мой взгляд, но, конечно, это может потребоваться, если расстояния оправдывают это, и вы не можете снизить скорость, НО подумайте об этом ....
Размещение микро на обоих концах (или на удаленном конце) для обеспечения связи типа CAN означает, что ваша общая пропускная способность при получении данных с удаленного устройства будет ограничена без значительно более высокой скорости передачи данных по каналу CAN, и у вас будет чтобы настроить вашу текущую основную передачу SPI для совместимости с CAN, и это может означать, что вместо простой отправки часов SPI и CE вам придется отправить более формальный запрос на передачу удаленных данных вам.
Самый простой способ - уменьшить тактовую частоту в соответствии с кабелем и, при необходимости, использовать сбалансированные драйверы и приемники, т.е. заставить все работать с задержкой, которую вы получите, введя 5 метров кабеля. Это легко при отправке данных на удаленное устройство - и часы, и данные поступают в основном синхронно, но попытка вернуть данные является реальной проблемой на больших расстояниях - принимающее устройство получает часы и синхронизирует свои данные с входящим сигналом, но через к тому времени, когда он возвращается к мастеру, вещи смещаются по отношению друг к другу.
Именно поэтому я предлагаю подумать о снижении тактовой частоты - перекосы будут не такими большими (в процентах) и меньше шансов выдавать ошибки.
Если вы можете сэкономить дополнительную витую пару, вы можете использовать RS485. Вы бы использовали две витые пары, одну для данных и одну для управления направлением, или вы могли бы использовать полудуплексную пару для каждого направления.
В случае данных/направления вы должны использовать линию управления направлением, чтобы отключить вывод на ведомом конце при передаче на него, и отключить главный выход, когда ожидается, что ведомый будет передавать.
Я был в похожей ситуации, пытаясь отправить сигнал по i2c, но мое расстояние было намного дальше. Я использовал кабель CAT5. У меня была довольно дурацкая установка, чтобы проверить идею. Я настроил схему для использования чипа расширения i2c (это должно было заставить 2 Arduino общаться друг с другом). Я думаю, что в какой-то момент я поджарил одну или обе микросхемы, поэтому я просто подключил их к цепи (я вытащил микросхемы из их разъемов и проложил очень короткие перемычки, в основном пересекая линии LxSy и SxLy). Во всяком случае, не вдаваясь в подробности, я смог получить сигнал примерно через 100 футов CAT5. Возможно, вы захотите попробовать, прежде чем сдаться или предположить, что это не сработает. В противном случае вы можете попробовать различные чипы расширения шины i2c. Схемы просты, а чипы недорогие (TI и NXP делают их P82B715PN).Схема расширителя шины i2c
швебер
Ложка
arc_lupus
станри
Питер Мортенсен
arc_lupus
Синхрондин