Лучшая электрическая шина микроконтроллера для высокоскоростной синхронизированной выборки с ведомых устройств

Я думаю, что для частоты дискретизации 0,25 Гц подойдет любая шина. CAN имеет больше «встроенных» функций приоритизации сообщений, арбитража и т. д., чем RS-485. Таким образом, у вас будет несколько более сложный, но несколько более высокий протокол уровня с CAN. Требования к электрическому сигналу и источнику питания для проводки будут практически одинаковыми в любом случае. Вы говорите, что требуется «синхронизированная» выборка, но не определяете, какая точность, точность и задержка «синхронизации» требуются.

Если бы вам нужно было выполнить выборку «одновременно» в течение наносекунд, у вас были бы некоторые значительные дополнительные проблемы, связанные с задержкой связи, задержками проводки и т. д. Но я подозреваю, что, поскольку вы не определили требование и считаете «относительно» низким шины производительности без упоминания какого-либо запускающего/тактирующего строба для триггера выборки, вы можете быть достаточно довольны синхронизацией до уровня нескольких микросекунд или дольше. Если это так, любая шина, вероятно, потенциально подходит для вас в зависимости от архитектуры вашей системы.

Выполняют ли узлы автономную выборку с заданной частотой и временем выборки? Если это так, это облегчает задачу, если тактовые импульсы выборки на узлах поддерживаются в достаточной синхронности. Если каждый из узлов ожидает команды «выборка сейчас» на коммуникационной шине, вы можете рассмотреть, что произойдет, если прием сообщения будет иногда задержан или потерян одним или несколькими узлами. В таком случае синхронизация выборки может быть потеряна или точка выборки может быть задержана.

Как насчет порядка передачи выборочных данных на контроллер? Если узлы используют общую последовательную шину, один из них должен отправить свой результат раньше других, поэтому будет вероятность конфликтов арбитража шины. Если нет параллельных независимых шин, идущих к каждому узлу, передача данных некоторых узлов будет задержана из-за того, что они будут переданы позже, чем другие узлы. Как будет работать автобусный арбитраж? Будет ли каждый узел опрашиваться по очереди или говорить по очереди? Как насчет повторной передачи сообщения, если подтверждение не получено из-за конфликтов на шине, ошибок передачи или других обстоятельств?

Если узлы имеют локальные часы, используемые для отметки времени выборки данных и, возможно, для определения времени выборки, как будет поддерживаться синхронизация часов? Итак, вы видите, что вы сталкиваетесь с одними и теми же потенциальными проблемами и потенциальными решениями/архитектурами, какую бы шину вы ни использовали. CAN предоставляет некоторые функции протокола более высокого уровня, помогающие структурировать некоторые аспекты конфликтов на шине, арбитража, приоритизации, повторной передачи, обнаружения ошибок и т. д. Вы можете реализовать аналогичные вещи в RS-485 с помощью собственного протокола. В конце концов, наиболее важными аспектами сети связи являются архитектурные решения и требования, относящиеся к таким вещам, как отказоустойчивость, синхронизация, обнаружение ошибок, обработка ошибок, проектирование сети и проводка и т. д.

Одна возможность, о которой вы не упомянули, — это Ethernet, который был дополнен в некоторых встроенных приложениях с помощью PTP, который помогает синхронизировать и отмечать события времени между распределенными узлами. Как правило, микросхемы и компоненты несколько дороже для реализации Ethernet по сравнению с CAN или RS-485, хотя это зависит от вашего выбора реализации, потребности в таких вещах, как высокий уровень электрической изоляции между проводкой и узлами (возможно с добавленной схемой в CAN). , RS-485 или Ethernet, но на самом деле ожидается только в качестве базового подхода к реализации в Ethernet). Ethernet дает вам возможные стандартизированные средства для подачи питания на узлы, хотя питание часто также передается вместе с CAN или RS-485.

Вы упомянули последовательную связь, а вот пара микросхем, которые отлично работают на очень высоких скоростях передачи данных. Вам не нужно передавать данные на таких высоких скоростях, но вам нужна минимальная тактовая частота 10 МГц:

Он имеет десять цифровых входов, затем они сериализуются для передачи по высокоскоростной сбалансированной витой паре, затем приемник (десериализатор) имеет десять цифровых выходов, которые соответствуют десяти входам, которые вы подали в сериализатор.

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

Без лишней суеты я подал на входы 10 последовательных потоков данных по 20 Мбит/с и отправил их на 25 метров по экранированной витой паре. Десериализация прошла идеально, и вы получаете восстановленный тактовый сигнал. XTAL на обоих концах не должны быть слишком точно согласованы — я помню, как тестировал установку с генератором сигналов на одном конце, и мы могли изменять частоту примерно на +/- 7% до того, как связь прервалась. Дешевой витой пары (50 Ом) должно хватить на несколько метров, но не забудьте подключить 50R.

Есть ли у ваших датчиков последовательный вывод данных? Если не использовать АЦП с последовательным выходом. Если вам требуется больше ввода-вывода, они также делают более крупные, но я не использовал эти более крупные, поэтому не могу говорить за них.