Объединение в цепочку нескольких контроллеров USB-концентраторов для последовательного интерфейса

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

Мне нужно около 26, может быть, больше каналов со скоростью от 9600 до 115200 бод. Чтобы поместиться в ограниченном пространстве, я подумал о приобретении нескольких контроллеров USB-концентраторов и размещении их на печатной плате с USB-последовательными ASIC.

Хост-компьютер представляет собой мини-машину на базе Intel ITX.

Моя текущая концепция включает в себя этот 4-канальный контроллер концентратора USB 3: 4-портовый концентратор USB 3 и несколько микросхем 7-портового концентратора USB 2: 7-портовый концентратор USB 2. концепция 7-портовые концентраторы будут подключены к сверхскоростным 4-портовым концентраторам, таким образом конечные точки USB, которые мне нужны. USB-последовательные ASIC (FTDI или аналогичный продукт) будут напрямую подключены к каждому 7-портовому порту контроллера-концентратора. Я знаю, что FTDI, например, предлагает многоканальный USB для последовательных устройств, но я не знаю, перечисляется ли каждый USB-канал как отдельное устройство в Linux (как в отдельном устройстве /dev/usbttyx)

У меня вопросы: насколько сложно реализовать это оборудование? Раньше я уже делал дизайн дифференциального сигнала, но никогда не работал с быстрой скоростью USB. Я также рассматривал возможность отдельного управления питанием каждого контроллера-концентратора, чтобы при необходимости их можно было сбросить отдельно.

Есть ли какие-то ловушки, на которые мне нужно обратить внимание при работе с этими USB-чипами? Это будет моя первая плата, на которой есть USB.

Спасибо!

Обычно это решается не с помощью USB, а с помощью «полевой шины», поэтому были разработаны такие вещи, как CAN. Простое решение — это RS485 с одним мастером, который вы можете без проблем подключить последовательно (просто соблюдайте терминацию), нет причин использовать 28 отдельных последовательных хост-контроллеров.
Если вы хотите использовать USB, то, что вы предлагаете, должно работать. Насколько я знаю, USB имеет ограничение в 127 устройств, включая концентраторы, поэтому вы должны быть в пределах этого ограничения. Каждое из них должно создаваться как устройство /dev/ttyUSB, хотя вы можете не иметь никакого контроля над тем, какое устройство имеет какой номер. На самом деле, это может меняться от включения к включению!
@DoxyLover не проблема назначить один и тот же номер tty на основе серийного идентификатора (если он предоставлен) или, альтернативно, на основе номера физического порта с использованием UDev.
@crasic Все устройства используют разные типы последовательного интерфейса. Не то, что я могу контролировать. Некоторые из них - RS485, 422, 232 и TTL. Хотя наличие кучи CAN-устройств звучит значительно менее страшно. Часть того, что оттолкнуло меня от CAN, - это стоимость интерфейсных устройств несколько выше ... Но если это проще, это может стоить того. Кроме того, как мне назначить номера tty, чтобы решить проблему, на которую указал DoxyLover?
@alphasierra для любой полевой шины потребуется что-то эквивалентное вашему чипу FTDI для USB, CAN тяжелее для периферийных устройств, но есть и другие системы на выбор (например, на основе Ethernet). USB будет абсолютно работать, но у вас могут быть требования, которым он не будет удовлетворять, например, детерминированное время отклика и опрос сети.
Рассматривали ли вы возможность использования последовательного сервера? Типичный последовательный сервер предоставит вам 8-32 порта 232/422/485, подключенных к сети через сокеты TCP. По размеру 32-портовый последовательный сервер можно разместить в 1RU.
@crasic прав, вы можете настроить правила udev для сопоставления определенных единиц с номерами ttyUSB. Это требует довольно продвинутых знаний Linux udev.
@DoxyLover: Насколько сложно мы говорим? Это очень запутанно?
@uint128_t uint128_t Я считал, что, однако, по большей части мне нужно запускать только асинхронные последовательные протоколы. Кроме того, эти серверы, как правило, имеют громоздкие разъемы db9. Ищу что-то дешевое, компактное, с клеммниками.
@crasic Это хороший момент ... Мне нужно разобраться с этим. Частично мотивация для этого подхода заключалась в том, что он будет очень простым с точки зрения программного обеспечения, и это предназначено для студенческого проекта. Идея заключалась в том, что они могли просто вызвать существующее последовательное устройство. Но если мы сможем упростить адресацию сообщений по CAN, то это будет лучшим решением.
Не уверен, что вы имеете в виду под асинхронностью, 232/422/485 асинхронны. Последовательные серверы, с которыми я знаком, на самом деле имеют разъем RJ45, поэтому очень легко создавать собственные кабели, а разъемы относительно компактны. Тем не менее, они не очень дешевы, но 1500 долларов за 32 настраиваемых последовательных канала — неплохая сделка.
Я бы назвал udev умеренно сложным. По сути, вам нужно написать правила, основанные на некоторых критериях, чтобы назначить определенные имена устройств. Будем надеяться, что каждый серийный ключ будет сообщать уникальный серийный номер, который вы можете ввести. Я не очень квалифицирован, чтобы придумывать больше деталей. Предлагаем вам поискать в сети «правила udev».
Один потенциальный недостаток, который я вижу, это распределение мощности; некоторые нисходящие порты могут нуждаться в автономном питании (т. е. корневой порт может быть не в состоянии обеспечить всю необходимую мощность от своего USB-порта).

Ответы (1)

Не совсем ответ, я просто не могу комментировать...

Оценивали ли вы вариант использования простого Arduino/AVR? С Atmega128 TQFP64 вы сможете получить 26 серийных номеров программного обеспечения, аппаратные UART могут работать со скоростью до 2 Мбит/с (для подключения к хосту ПК), Atmega128 имеет 2.

Существует также ARM серии STM32F103 с тактовой частотой 72 МГц.

На стороне хоста ПК, если вам действительно нужны 26 отдельных COM-портов, есть возможность использовать виртуальные COM-порты ... потребуется некоторое программное обеспечение для «агрегирования» данных этих 26 портов в реальный 1. Или отредактируйте программное обеспечение вашего ПК. Создание специального протокола (похожего на Modbus) для адресации каждого последовательного порта не должно быть сложным. То же самое со стороны MCU.

Объединение в цепочку нескольких контроллеров USB-концентраторов для последовательного интерфейса
СпросиСетьПолитика конфиденциальности1y, 0v