roboforum.ru

Всем привет,

Тема автоматного программирования ( AP, АП) уже много лет занимает заметное место в научно-популярных СМИ. Однако, несмотря на это, АП не стало магистральным трендом. Главная причина здесь — недостаточный опыт использования, и как следствие, отсутствие популяризаторов. Нельзя сказать, что недостаточно статей посвященных АП, но круг обсуждаемых в статьях вопросов по большому счёту сводится к описанию FSM (, т.е. теории конечных автоматов, а не инструкциям по работе с ними, либо к вопросу «Как реализуются программные автоматы?». Это печально но факт, отсутствует обсуждение того, какие перспективы для разработчиков - широкого инженерного сообщества открываются при использовании данной технологии.

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

Итак IDE (Integrated Development Environment) на базе ПК x86 с минимальной конфигурацией:
Quad Core 1.8 GHz processor, 2-4GB RAM and 32-64GB onboard flash memory.
В моем случае это одноплатный SBC от китайского производителя LattePanda
Что не есть минимальный предел для того о чем пойдет дальше речь.
В качестве OC можно устанавливать финальную версию Win 10(LTSC x64) или одну из последних сборок Linux.

А речь пойдет о специально разработанной инструментальной IDE платформе, (период разработки 2017 - 2020г) в концепте которого заложена демократизация широкой аудитории
разработчиков - интеграторов, которые с одной стороны нуждаются в универсальной (не хоббийном) R&D софт программно аппаратной лаборатории, состоящей из ПК IDE, а так же механических узлов, электронных модулей, драйверов сенсоров, преобразователей, генераторов, сенсоров, приводов и т.п. для профессионального прототаипинга.
С другой стороны эта категория отраслевых специалистов, не владеющих навыками программирования, студентов, стартапов, инжиниринговых многоотраслевых фирм и т.п. все еще ждут свой заветный инструментарий c минимальными требованиями к PC архитектуре, в комплекте с I/O USB интерфейсом, с возможностью выбора на свой вкус OС.

Варианты решения:
Собственно такой сет для механиков создать задача не из сложных, важно скооперироваться с профессиональными автоматизаторами. Что касается аппаратного набора, скомплектовать и красиво уложить в зеленый с оранжевыми защелками кейс, скажем на 10 - 20 кг. на том же принципе что и предыдущий вполне реализуемо. Сегодня рынок модульных решений для прототаипинга на таких мега площадках как Али, кишит своим многообразием и ценовыми предложениями.

И наконец самый важный ключевой момент - в этом кейсе в отдельном отсеке положить инсталяционную флешку с фирменным наименованием продукта, а рядом I/O стартовый модуль к примеру 10/16. Так же и не исключаю еще 1 отсек для SBC одноплатника с предустановленной OС и IDE платформой, присутствует в виде инсталянта на флешке (но можно и через онлайн с сайта продукта), блок питания для одноплатника и поехали...

IDE, по своей парадигме, базируется на автоматном программировании и давно готова, больше того, она имеет одноименное название BEEPTOOLKIT, успешно провалидирована в коммерческих проектах (Медицина, Hi-Tech, научая сфера в области лазерной оптики, автомобилестроение) и на данном этапе ведется активный нетворкинг на онлайн площадках с целью масштабирования, популяризации и установления стратегического партнерства.
Что из себя представляет автоматное программирование, можно понять из этого видеоролика, где метод простыми словами раскрыт на примере машины Тьюринга:


С деталями проекта, ознакомительными и образовательными видеоматериалами можно ознакомиться на сайте продукта (англ).
BEEPTOOLKIT.

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

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

beep_beam писал(а):Эмпирические тесты платформы по Тьюрингу сразу отвергаю, т.к. на данном этапе в логическом ядре отсутствуют модульные процедуры и методы обращения к ним посредством консоли и алгоритмизации таких задач. В целом я не сторонник маркетинговых приемов маркетологов, которые направо и налево вешают на обывателей как собак свои понятия об "искусственном интеллекте". Кроме того я пока сам для себя еще не решил, а нужны ли такие математические перенасыщения в практической робототехнике и автоматике в актуальных многоотраслевых отраслевых потребностях соответствующих принципам RAD как по стоимости, так и по времени.

Я ничего сверхъестественного не прошу. Если вы выбрали язык визуальных абстракций, то в этом языке, как и в любом другом формальном языке, должны быть в обязательном порядке следующие составные части:
- словарь;
- языковые правила.
Можете ли вы представить нам словарь? Например, есть ли в нем такая сущность, как переменная?
И какие правила в этом языке существуют? Проще говоря, как можно комбинироать между собой сущности языка, чтобы можно было образовывать корректные выражения на этом языке?
Вот один из примеров - формальное описание языка Oberon: https://github.com/rcorcs/OberonC/blob/master/Oberon-0%20(BNF).pdf
Имеется ли что-то подобное для вашей системы?

Виктор Казаринов,
даже не знаю что цитировать из Ваших вопросов. Вы настойчиво ищете общие идиомы между классическим программированием и конечным автоматом (Finite State Machine).
Конечные автоматы позволяют построить модели систем параллельной обработки, однако, чтобы изменить число параллельных процессов в такой модели требуется внести существенные изменения в саму модель. Кроме того, разработки сложной модели реализованной конечным автоматом, объем и уровень выполняемых функций во многом зависит от числа закладываемых состояний автомата, что я здесь и демонстрирую. Как было отмечено выше, последнюю проблему можно решить, если использовать недетерминированный автомат.

Для конечного автомата можно определить язык (множество слов) в алфавите {\displaystyle V}V, который он допускает — так называются слова, чтение которых переводит автомат из начального состояния в одно из заключительных состояний.
Ответ дается теоремами Клини. Этот ответ точный, так как теоремы Клини устанавливают необходимые и достаточные условия представимости последовательности событий в автомате, а именно: выделяются особые множества последовательностей входных символов — регулярные множества. Факт появления входной последовательности из такого множества называется соответствующим регулярным событием. Теоремы Клини устанавливают, что в конечном автомате могут быть представлены регулярные события и только они. Таким образом, на языке представления событий ответ на вопрос, что может «делать» конечный автомат, дается однозначно: конечный автомат может представлять только регулярные события. Ряд важных множеств входных последовательностей, с которыми часто приходится иметь дело на практике, заведомо регулярны. Так, например, заведомо регулярно множество, состоящее из любого конечного числа входных последовательностей конечной длины; множество любых периодических входных последовательностей; множество бесконечных последовательностей, которое содержит заданные конечные последовательности на протяжении нескольких последних тактов, и т. д.
Хотя теоремы Клини и отвечают на вопрос о том, что может делать конечный автомат, но отвечают они на этот вопрос неэффективно. Сделаны первые попытки построения иных языков, на которых ответ может быть дан эффективно. Эта проблема языка, играющая кардинальную роль в получении эффективного ответа на вопрос, что может и что не может «делать» конечный автомат, имеет решающее значение и для первых этапов синтеза автомата, то есть для ответа на второй из сформулированных выше вопросов. Если расширить класс динамических систем, которые мы определили терминами «конечный автомат» и «последовательностная машина», включением бесконечной памяти (моделью бесконечной памяти может быть, например, бесконечная лента для хранения символов или бесконечное число состояний), то для динамических систем этого более широкого класса (абстрактные системы этого класса называют машинами Тьюринга) ответ на вопрос «что они могут делать?» значительно проще — они могут реализовать любой наперед заданный алгоритм.

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

Для перехода на состояние A нужно вызвать метод stateA, который выполнит нужную логику и вызовет setState(A).

Самым трудоемким в разработке логического ядра было разработать графическую консоль ввода инструкций обращения к набору инструкций в коде. Не поверите, у нас даже год назад был интерфейс в виде боарда STM32, думалось что так будет понятней выполнять алгоритмизацию, но это сильно выносило мозги хардверщикам, т.к. они искали возможность Си кодирования применительно к DSP и мы устали от бесконечных комментов, вернулись исходному варианту.

"Визуальное программирование подлежит проклятию во веки веков!" (с)

Конечно, линукс не пригоден для real-time.
Почему не была использована, какая-то ОС специально заточенная под real-time? Я не беру проприентарный QNX, но есть же и бесплатные.
Визуальное программирование - это полное дерьмо, в профессиональных целях.

Визуализровать годно аппаратную часть. Где что куда втыкать.

beep_beam писал(а):Для конечного автомата можно определить язык (множество слов) в алфавите {\displaystyle V}V, который он допускает — так называются слова, чтение которых переводит автомат из начального состояния в одно из заключительных состояний.

Хорошо. Тогда давайте подробнее рассмотрим автоматное программирование.
Какой из видов автоматов вы используете: Мура, Мили и какой из подвидов вы используете? Или можно выбирать разные виды автоматов?
И по-прежнему, остается вопрос:
Если пользователь общается с вашей RAD на языке автоматного программирования, то в нем также есть сущности и правила построения автоматной программы. Какими сущностями можно манипулировать в ваших автоматах? Можно ли в памяти завести переменную - целое число и его инкрементировать? Сделать простейший счетчик чего-либо с ее помощью? И затем добавить его анализ в условия перехода между состояниями автомата наряду с показаниями сенсоров?

beep_beam писал(а):Наш фреймворк определяет следующее соглашение:
У нас есть набор состояний...

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

beep_beam писал(а):Самым трудоемким в разработке логического ядра было разработать графическую консоль ввода инструкций обращения к набору инструкций в коде.

Вы не находите здесь логического противоречия? Ведь логическое ядро и графическая консоль - это две разные сущности. Но я вашу мысль понял.

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

Верю.

esisl писал(а):"Визуальное программирование подлежит проклятию во веки веков!" (с)

Конечно, линукс не пригоден для real-time.
Почему не была использована, какая-то ОС специально заточенная под real-time? Я не беру проприентарный QNX, но есть же и бесплатные.
Визуальное программирование - это полное дерьмо, в профессиональных целях.

Визуализровать годно аппаратную часть. Где что куда втыкать.

Не хочу Вас расстраивать, попробуйте угадать с 3 раз, на каком софте и под какими осями Илон Маск вывел в космос свой проект SpaceX?

beep_beam писал(а):Не хочу Вас расстраивать, попробуйте угадать с 3 раз, на каком софте и под какими осями Илон Маск вывел в космос свой проект SpaceX?

Даа... Много ереси в этом мире.
Много работы предстоит, для становления Прекрасного Светлого Будущего

Виктор Казаринов писал(а):Хорошо. Тогда давайте подробнее рассмотрим автоматное программирование.
Какой из видов автоматов вы используете: Мура, Мили и какой из подвидов вы используете? Или можно выбирать разные виды автоматов?[/code]
Применяются оба вида и их можно выбирать.

Да можно оба варианта автоматов.

И по-прежнему, остается вопрос:
Если пользователь общается с вашей RAD на языке автоматного программирования, то в нем также есть сущности и правила построения автоматной программы. Какими сущностями можно манипулировать в ваших автоматах? Можно ли в памяти завести переменную - целое число и его инкрементировать? Сделать простейший счетчик чего-либо с ее помощью? И затем добавить его анализ в условия перехода между состояниями автомата наряду с показаниями сенсоров?

В нашем случае можно вводить в память:
- таймерные значения для циклов;
- регистровые значения селективным управлением I/O портов и каналов;
- триггерные значения.
Мы можем запустить и проводить выборочную частичную симуляцию отдельных отрезков алгоритма и по результатам включать эти части в общий сценарий. Все показания сенсоров могут протоколироваться для удобства анализа с сохранением результатов в текстовом файле.

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

Здесь хотелось бы уточнить задачу на конкретном, не абстрактном, практическом примере.

beep_beam писал(а):В нашем случае можно вводить в память:
- таймерные значения для циклов;
- регистровые значения селективным управлением I/O портов и каналов;
- триггерные значения.

Можно ли считать количество булочек, которые в вашем одном из примеров сортировал автомат?

beep_beam писал(а):

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

Здесь хотелось бы уточнить задачу на конкретном, не абстрактном, практическом примере.

Самый простой пример. Создаем иерархию синхронных автоматов по принципу: каждый субавтомат выполняет по одному шагу, либо полностью отрабатывает все переходы до своего финиша и возвращает управление вызывающему автомату. Из таких иерархий (деревьев автоматов можно собрать лес автоматов, где каждое дерево управляет одним объектом управления, например, шаговым двигателем. Для чего нужна иерархия? Один из вариантов: все делать в виде одного многопараметрического автомата - громоздко. Это очень похоже на обычные языки программирования, где вместо огромной функции производится декомпозиция задачи и создается иерархия небольших, легко читаемых и отлаживаемых функций. Тут все аналогично, но вместо функций - автоматы. Еще конкретнее - можно рассмотреть задачу, когда нужно сортировать булочки не только по весу, но и по другим параметрам (цвет корочки, размеру и т.д.). Делаем субавтоматы детекции по этим параметрам, которые передают результаты в автомат окончательного принятия решений о сортировке. Такое у вас можно реализовать?

Виктор Казаринов писал(а):Можно ли считать количество булочек, которые в вашем одном из примеров сортировал автомат?

Для этого у нас есть функция генерирования отчетов по фиксируемым значениям веса и количествам взвешиваний.

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

... Еще конкретнее - можно рассмотреть задачу, когда нужно сортировать булочки не только по весу, но и по другим параметрам (цвет корочки, размеру и т.д.). Делаем субавтоматы детекции по этим параметрам, которые передают результаты в автомат окончательного принятия решений о сортировке. Такое у вас можно реализовать?

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

Кстати, коль затронут вопрос определения цвета, мы проводили эксперименты с аналоговыми RGB сенсорами и добивались достаточно большого разнообразия отклика на меняющиеся цветовые оттенки по каждому цвету. Юстировочная консоль позволяет производить калибровку в режиме отладки, т.е. мы имеем 10 канальный вольтметр с высоким классом точности 0,001V.

Можете немного подробнее остановиться на аппаратных портах, куда должно подключаться конечное оборудование? Это GPIO или что-то еще? Как,например, мне подключить обычный 3D сенсор магнитного поля через I2C?

Виктор Казаринов писал(а):Можете немного подробнее остановиться на аппаратных портах, куда должно подключаться конечное оборудование? Это GPIO или что-то еще? Как,например, мне подключить обычный 3D сенсор магнитного поля через I2C?

Конечное оборудование подключается посредством драйверов к нашему USB I/O модулю.
Двунаправленный I/O модуль (питание 5V) состоит из 2х субмодулей выходной (16 каналов селективно задаваемых каналов на 1 Порт - автомат). Активация номеров каналов указывается программно, формируется двоичная логика "1 = 4,5 - 5V" и "0 = 0,3V" (по умолчанию), 20 mA на канал, скорость реакции ответа 50 ms.
Входной субмодуль ADC - 12 bit на базе STM32, состоит из 10 каналов которые одновременно за 1 цикл (100 ms) или по указанному номеру на входах фиксируют напряжение 0 - 3.300V.
I/O модуль в зависимости от задач юзеров, на их выбор, может комплектоваться только выходным субмодулем или входным.
В процессе конфигурирования при первом подключении пользователь должен указать номер USB входного(ых) субмодулей. Их количество (теоретически) может составлять 256 (!2560 Каналов по 10 на каждый порт). Сейчас нет картинки под рукой, можно посмотреть на сайте, есть вариант в 1 корпусе на 1 шнур, есть вариант раздельный в акриловых корпусах.
Количество одновременно подключаемых входных USB субмодулей может составлять до 4 с привязкой к 1 номеру USB (расширение, при необходимости, количества коммутируемых драйверов нагрузок).
Теперь что касается считывания и преобразования I2C PWM сигналов в триггерные значения, мы на ряду с в.у. планируем такую возможность в дополнение к тем типам датчиков (сенсоров) которые уже реализованы.
Подбираем недорогой и вместе с тем популярный ADC, который предоставит возможность по работе и с 3D магнитным полем, Холла и т.п.
Если Вы можете порекомендовать такой, буду благодарен.

beep_beam писал(а):Конечное оборудование подключается посредством драйверов к нашему USB I/O модулю.
Двунаправленный I/O модуль (питание 5V) состоит из 2х субмодулей выходной (16 каналов селективно задаваемых каналов на 1 Порт - автомат). Активация номеров каналов указывается программно, формируется двоичная логика "1 = 4,5 - 5V" и "0 = 0,3V" (по умолчанию), 20 mA на канал, скорость реакции ответа 50 ms.
Входной субмодуль ADC - 12 bit на базе STM32, состоит из 10 каналов которые одновременно за 1 цикл (100 ms) или по указанному номеру на входах фиксируют напряжение 0 - 3.300V.
I/O модуль в зависимости от задач юзеров, на их выбор, может комплектоваться только выходным субмодулем или входным.

Все равно мне не очень понятно, что из себя представляет каждый выход в этом вашем I/O модуле. Это обычный GPIO? Например, в копеечной микросхеме I2C расширителя портов MCP23017 или в аналогичном SPI расширителе MCP23S017 таких выводов 16. Каждый (!) вывод можно настроить на вывод или ввод цифровой информации. Его можно питать как от 3,3 В, так и от 5 В. Но через такие порты крайне нежелательно передавать сигналы ШИМ для шаговиков. Т.к. возникает сильный джиттер. У вас джиттер усилит USB, если только ШИМ формирует основной процессор.

beep_beam писал(а):Теперь что касается считывания и преобразования I2C PWM сигналов в триггерные значения, мы на ряду с в.у. планируем такую возможность в дополнение к тем типам датчиков (сенсоров) которые уже реализованы.

Тут вовсе не нужен PWM и никаких триггерных значений. С устройствами I2C и SPI все гораздо не так.

beep_beam писал(а):Подбираем недорогой и вместе с тем популярный ADC, который предоставит возможность по работе и с 3D магнитным полем, Холла и т.п.
Если Вы можете порекомендовать такой, буду благодарен.

Я переписывл низкоуровневые драйвера на спецпроцессор только у нескольких магнетометров. Выяснилось, что существует как минимум два их типа: те, что чувствуют магнитное полке Земли и те, что к нему нечувствительны. Это удобно тогда, когда не нужны лишние магнитные помехи.
Все магнитометры, с которыми я имел дело, наделены собственным цифровым процессором и выдают на шину I2C или SPI готовые, чаще всего отфильтрованные значения.
Вот некоторые из них:
Infineon TLV493DA1B6 не чувствует поле Земли, но прекрасно подходит для целей автоматики.
QMC5883L - чувствителен к магнитному полю Земли.

Виктор Казаринов писал(а):Все равно мне не очень понятно, что из себя представляет каждый выход в этом вашем I/O модуле. Это обычный GPIO? ... Каждый (!) вывод можно настроить на вывод или ввод цифровой информации. Его можно питать как от 3,3 В, так и от 5 В. Но через такие порты крайне нежелательно передавать сигналы ШИМ для шаговиков. Т.к. возникает сильный джиттер. У вас джиттер усилит USB, если только ШИМ формирует основной процессор.

Вами описываемые проблемы, есть ключевой момент в концепте всего проекта и именно на нашей дизайнерской идее (разделяй и властвуй) выстраивалась дальнейшая наша стратегия RAD автомтики.
Так по замыслу, аппаратная реализация коммуникаций с I/O первичных сигналов должна была изначально нести на себе возможность недорогого аппаратного управления по выходным и считывания входных с на независимых ядрах (отдельные микроконтроллеры) с раздельными интерфейсными коммуникациями, что исключает какое либо джитирование.

Шаговиками у нас управляют аппаратные ШИМ генераторы, которые по питанию активируются программно (скорость вращения постоянная).

Таким образом мы элегантно 2-я микроконтроллерами решаем все те проблемы о которых Вы говорите.
Что касается архитектуры этих контроллеров, в Out случае это SPI китайский 8-канальный ADC собрат серии Intel 8051/8052/8751 с аналогичной GPIO портовой работой. Имеется два указателя DPTR вместо одного, порт UART можно использовать как 4 последовательных порта путем сдвига его данных на 4 группы выводов. На входные порты мы подаем внешние 4 bit сигналы, которые декодируются 16 каналов последовательного управления, так же фиксированием их состояния ON/OFF.

По формированию IN взят STM32 Коммуникационный модуль ADART ADC, интерфейс связи UART.

Я переписывл низкоуровневые драйвера на спецпроцессор только у нескольких магнетометров. Выяснилось, что существует как минимум два их типа: те, что чувствуют магнитное полке Земли и те, что к нему нечувствительны. Это удобно тогда, когда не нужны лишние магнитные помехи.
Все магнитометры, с которыми я имел дело, наделены собственным цифровым процессором и выдают на шину I2C или SPI готовые, чаще всего отфильтрованные значения.
Вот некоторые из них:
Infineon TLV493DA1B6 не чувствует поле Земли, но прекрасно подходит для целей автоматики.
QMC5883L - чувствителен к магнитному полю Земли.

Все 3D по магнитному полю, что выставлено в продажу для широких масс, до неприличия дорогое.

Извините, не понял.

Так ШИМы Вы для всех внешних исполнительных гоните непосредственно с контроллера? Сквозь USB -> I2C -> CAN ->etc...

P.S. Не то, чтобы это было "совсем плохо", просто серьёзно ограничивает применимость.

esisl писал(а):Извините, не понял.

Так ШИМы Вы для всех внешних исполнительных гоните непосредственно с контроллера? Сквозь USB -> I2C -> CAN ->etc...

P.S. Не то, чтобы это было "совсем плохо", просто серьёзно ограничивает применимость.

Аргументируйте ограничения.

Гоним так:
OUT - так PC (RAD)+ генраторы I2C>Драйвер устройства 1...4 USB>ADC>1...60 физических адреса двоичной логики
IN - так PC (RAD)> UART USB(COM2...256)>ADC>10 каналов на каждый ADC 0.001 - 3.000V.