Если бы я решил вести детский робототехнический кружок (мне не нравится слово кружок), я бы так его никогда не назвал, т.к. в названии сидит противоречие будущему и вот почему - Детей нужно сразу погружать в мир взрослой робототехники с реально полезным концептом. Разработка программного обеспечения такого сообщества должна быть интуитивно доступна для генерации исходного кода (оркестрации) и аппаратно модульным, чтоб дети не концентрировали свое внимание на языковых абстракциях и схемотехнике, многие из них чисто физиологически в таком возрасте не могут себя заставить, не то что целеустремленно изучать, они не могут больше 30 минут вообще во что либо осмысленно погружаться, т.к. мозги еще умеют от природы и Лего не лучший пример перехода к реальной робототехнике. Лего это занимательный игровой конструктор с элементами взрослой игры в программистов и мехатроников. Если здесь есть присутствующие кто после Лего начал изучать реальный R&D, то поймут о чем я говорю. Мое мнение что процесс разработки будущего, это по большей части продумывание и оптимизация алгоритма мехатроники с минимальной нагрузкой требований к механике. При этом IDE такого концепта должна соответствовать в.с. порогу уровня подростка 10 - 16 лет.
Под паллетайзером в моём комментарии речь именно про самоходные тележки/штабелёры с автоматическим управлением, которые возят и устанавливают паллеты, то есть про тот же класс driverless industrial trucks, на который и ссылается ISO 3691‑4. Стандарты по роботам (ISO 10218‑2 и ISO/TS 15066) допускают совместную работу человека и робота только при ограничении энергии и силы до уровней, при которых даже контакт не приводит к травме; это реализуемо для лёгких коллаборативных манипуляторов, но никак не для многосоткилограммовой паллеты, особенно на высоте. Поэтому индустриальная практика для таких случаев - либо ограждённые ячейки, либо очень жёстко организованные общие зоны с ограничением скорости, зонами исключения для людей и системой обнаружения персонала, а не «свободное перемещение» в привычном смысле.
В этом контексте мой тезис был не про то, что «стандарты запрещают любую совместную работу», а про то, что конкретная конфигурация, где тяжёлый самоход с паллетой катается по полу буквально в общем проходе, а главным аргументом безопасности служит возможность ручного вмешательства оператора через кнопку - гриб, идёт вразрез как с ISO 3691‑4, так и с общими принципами риск‑ориентированного проектирования систем безопасности.
Вижу что полетаизеры выполняют работу в зонах со свободным перемещением людей, что категорически не допустимо из соображений техники безопасности, как бы разрабы не стучали себя в грудь кулаками, доказывая 100% безопаснось.
возможность ручного вмешательства оператора для устранения возможных неисправностей.
Полетайзер прет на рабочих и в это время оператор в прыжке нажимает на красную кнопку размером с ладонь? Причин запуска самохода может быть масса.
Ок, с этим проехали, для полного обзора линии чисто снования по полу полетайзеров не достаточно, это выглядит как новостная заметка, как это и есть на данном примере. Интересно что происходит когда поддон ( к слову он деревянный сколоченный гвоздями) с молоком на высоте 3 метра был неудачно установлен и произошел его перекос. Как система реагирует на такие ситуации? В мире есть немало других логистических технологий, начиная от автоматизированных XYZ гантри манипуляторов, до 3D рельсовых матриц хранения в куче с конвейерными треками и для каждого из таких алгоритмов есть экономически обоснованная целесообразность.
Бизнес‑заказчик хочет оценить, насколько эффективно роботизированные технологии смогут справиться с ключевыми процессами внутри склада, такими как перемещение готовых продуктов от конечной точки производственной линии до временных зон хранения (КБО) и последующий вывод продукции на дальнейшую обработку.
Чтоб оценить идею применения С1, в статье недостаточно реальных иллюстраций с зонами, от точки приема до точки выдачи. Можно много рассуждать, но пока все это выглядит очень абстрактно и не факт что экономически логично для клиента.
А я хожу кругами вокруг этих Timekettle W4 Pro с функцией Ai синхронного первеода, с активным шумоподалением и для аудио прослушки. На сегодня они считаютя флагманским по качеству Ai (0,2 с задержка) но честного обзора пока на них нет, возможно из за их стоимости $381 на амазоне
Тема востребована, т.к. направлена на решение вопросов, которые происходят из причин их важности когда идеи нуждаются в прокачке с минимальными затратами и усилиями.О важности MVP в любом стартапе уже давно все сказано, при этом мало кто обсуждает проблемы инициаторов в выборе той или иной среды построения кода, от которого зависит аппаратный дизайн и то, как это легко и доступно увидеть в динамике на этапе идеи с начальными алгоритмами. То о чем здесь пишу, это часть осмысленного и моего проекта создания онлайн лаборатории под свою IDE включая и работу с аппаратной частью и симуляции и много еще всего, что должно работать на всех. Увы я не смогу дальше здесь развивать в подкастах эту тему, т.к. получу бан за промоушинг. Если кому интересно обращайтесь в личке.
У нас несколько другая сфера применения low-code автоматика и робототехника, но подход аналогичный, кубики программистам, их сбор инженерам - архитекторам, на выходе рабочий код управления аппаратным сценарием и аппаратные спецификации всего проекта. Что характерно инструкции для визуального ввода может генерировать обученная модель ИИ, таким образом, что инженеру архитектору достаточно на вербальном уровне поставить задачу (запустить моторо на 10с и остановить, или запустить до момента триггерного срабатывания по значению со стороны датчика положения каретки и т.д.) К разработке программного ядра подход был на построение интерпретаторов команд бинарной логики, применяемых в системах автоматизированного логического управления.
Вообще-то правильным и логичным тоном в любой разработке считается применение встроенного в стенд такого источника питания, как и другой аппаратной части в виде уже существующих готовых модулей с требуемыми функциями и параметрами, которые в дальнейшем могут стать частью прототипа (репликация или как есть), при этом сегодня выбор таких готовых и выставленных на поток, как источников с в.у. характеристиками, так и других модулей, вполне позволяют вести их подбор в качестве универсальных компонентов к той архитектуре устройств, которые Вы разрабатываете сегодня или с идеями на завтра. Такой подход избавит Вас от дальнейших дополнительных затрат в создании прототипов или промышленных образцов.
Лучший интерфейс — тот, который делает жизнь проще, не заставляя задумываться, как он работает.
UX/UI - в свое время это для успеха был кусок работы чуть ли не самым главным в Data Sciense. Помню момент, когда клиенты просто визжали от удовольствия, когда в качестве интерфейса получали свой рабочий кабинет с видами столов и ящиками в которых они любили рыться, что-то находить, далее размещать в отдельные разноцветные папки и передавать их содержимое своим сотрудникам, те, в сою очередь принимали содержимое адресных папок к дальнейшим задачам, которые соответствовали их должности и инструкциям и т.д. и т.п. Ошибки исключались, т.к. в алгоритме были заложены запреты на ошибочные (человеческий фактор или нарушение последовательностей инструкций). Сейчас передо мной стоит более сложная задача - UX/UI IDE разработчика автоматики и робототехники где на ПК возлагаются задачи не только автоматизации процесса генерации исходного кода логического управления, но и функции логического контроллера под внешний I/O аппаратный интерфейс и здесь мне не совсем понятно, что в таком случае должен представлять из себя такой интерфейс(ы). Когда это кнопки с памятью вводимых состояний, дисплей часов для выставления там таймингов, селекторные кнопки для указания номеров USB портов и т.д. и т.п....
А еще практикуется такая фишка среди фрилансеров и всех их подопечных, когда они по договоренности с клиентами - крупными фирмами, демонстрируют другим потенциальным заказчикам "свои производственные площадки" которые по факту не являются ихними. Водят по цехам, IT отделам гостей как по зоопарку.
Почему бы и нет, спросите его, если это просто любопытство, а интерес к стороннему опыту все же продуктивней иметь из первоисточников, впрочем гигачат на данный момент дает вполне адекватное описание платформы и ее применение. :-
LV позволяет построить программную и аппаратную систему, которая выполняет те же функции, что и ОС, в условиях встраиваемых решений, промышленных контроллеров или систем реального времени. Это можно рассматривать как специализированную ОС-подобную среду, полностью разработанную в визуальной среде. Не полный перечень возможностей: Запуск кода на RT-контроллерах с детерминированным исполнением;
Управление потоками, приоритетами задач, прерываниями, синхронизацией и расписанием - то, что выполняет ядро RTOS;
Проектирование логического уровня "ядра" на уровне FPGA - реализация логики взаимодействия между устройствами, шин, интерфейсов; Разработка приложений с параллельными вычислениями, распределенной логикой и управлением событиями - по сути, имитация ядра ОС на прикладном уровне; Управление ресурсами, вводом/выводом, коммуникациями (Modbus, TCP/IP, CAN), памятью и задачами. Вы можете построить систему, где LabVIEW:
Управляет всеми задачами (как диспетчер процессов).
Имеет цикл реального времени с высоким приоритетом (как планировщик).
Реализует драйверы устройств (через FPGA или I/O Nodes).
Управляет прерываниями, вводом-выводом и хранением данных (как ядро).
Работает автономно на хардваре без традиционной ОС.
Важно понимать, что LabVIEW не создает ОС в классическом смысле, но позволяет построить программную и аппаратную систему, которая выполняет те же функции, что и ОС.
Как про "может быть сразу проверена на железе через стандартный USB GPIO.", думаю статья вышла бы не плохая.
здесь требуется конкретика, что проверять со стороны USB GPIO? Выше по ветке я дал описание решения которое применяется в программном контроллере, детали проекта обсуждаются здесь. Если у Вас возникнет желание выпустить авторскую публикацию на хабре с описанием платформы, окажу всяческое содействие. Я не писатель.
LabView это не ради "эмуляции ОС", а ради сокращения цикла "идея - исполнение" при разработке автономных логических систем.
Так что речь не про «берите любую IDE», а про осознанный выбор среды, в которой логика описывается так же наглядно, как монтируется схема — и может быть сразу проверена на железе через стандартный USB GPIO. Впрочем при желании на LV можно и OC создать, для чего, это уже другой вопрос.
Если вы имеете ввиду ПЛК, то с одной стороны мне абсолютно непонятно, как вы к этому внезапно пришли, а с другой стороны чем ПЛК принципиально отличается от микроконтроллера помимо того, что там зашит проприетарный софт ?
пришел не внезапно, а более чем 7 лет по озвученной Вами причине с уходом от проприетарности железа с его содержимым и того букета плюшек который он за собой тянет с клиента. Тема тянет не на одну статью, идея не из лучших отвлекать здесь кого либо на то, что здесь не предусмотрено к обсуждению. На данный момент это коробочное решение со всеми сопутствующими атрибутами и своим сообществом. Если интересно могу скинуть в личке.
Ваш подход тоже прекрасно эмулируется при наличии такого желания и точно так же при эмуляции потребует либо QMP либо решения подобного выше.
Любопытно узнать, возможна ли в QMP реализации или моделирования реального логического контроллера, исполняющего логику в потоке данных или по триггерам/флагам, как это делается в автоматных логических контроллерах? Насколько мне известно среда не дает таких средств разработки.
Логично, что эмуляторы вроде QEMU не моделируют экспандеры, в контексте статьи хотел лишь указать, что мой подход не заменяет эмуляцию, но показывает, что задачами управления можно заниматься на другом уровне абстракции — в зависимости от целей проекта.
Ни разу не встречал I2C GPIO расширителей интегрированных в SoC. И опять же если вы эмулируете в QEMU SBC с подключенным GPIO расширителем (неважно каким, главное, что вы его тоже эмулируете), перед вами встаёт та же самая проблема, что и с GPIO которые находятся непосредственно в SoC.
Как и Вы, в свое время я бился над такими задачами, у меня нет прямого ответа в плане - вот Вам SoC с интегрированным I2C GPIO-экспандером на базе PCF8574, MCP23017 и т.д., вместо этого я пришел к выводу - нет смысла искать I2C GPIO внутри SoC, когда можно построить работу ее логики вне SoC, взаимодействуя с периферией как в моем случае по USB + I2C, просто поменял стратегию когда это просто другой способ масштабирования ввода-вывода. Если интересно могу дать дисклеимер, но это выходит за рамки Вашей публикации.
некоторое время был одержим идеей «прозрачного» взаимодействия с устройствами внутри QEMU — использовать те же библиотеки
где в качестве host применили SBC + QEMU Я в нем не эмулировал ничего подобного, т.к. моя архитектурра CPUx86 и для подобных задач там больше пространства для творчества, вплоть до построения IDE. интеграция протокола I2C где для полноценной поддержки I²C GPIO-пины должны быть подключены к I²C-модулю внутри микроконтроллера (то есть быть назначены как SDA/SCL).
Это мой частный случай, в отличие от встроенных GPIO-контроллеров микроконтроллеров, в ПК-системах GPIOвозможныреализации через внешние модули, подключаемые по USB. Такие модули представляют собой интеллектуальные расширения, включающие в себя встроенные DAC/ADC, ARM-процессоры и интерфейсы связи (например, USB или RS-232, прочие конвертеры популярных протоколов). Управление осуществляется из основного программного обеспечения на ПК (хост) посредством программных микросервисов на базе FSM или API, обеспечивающие коммуникацию и логическое управление с каждым модулем. Если не понятно, конкретизируйте вопрос, как Вы указали x86, это не Ваш случай, отсюда и недопонимание.
Если бы я решил вести детский робототехнический кружок (мне не нравится слово кружок), я бы так его никогда не назвал, т.к. в названии сидит противоречие будущему и вот почему - Детей нужно сразу погружать в мир взрослой робототехники с реально полезным концептом. Разработка программного обеспечения такого сообщества должна быть интуитивно доступна для генерации исходного кода (оркестрации) и аппаратно модульным, чтоб дети не концентрировали свое внимание на языковых абстракциях и схемотехнике, многие из них чисто физиологически в таком возрасте не могут себя заставить, не то что целеустремленно изучать, они не могут больше 30 минут вообще во что либо осмысленно погружаться, т.к. мозги еще умеют от природы и Лего не лучший пример перехода к реальной робототехнике.
Лего это занимательный игровой конструктор с элементами взрослой игры в программистов и мехатроников. Если здесь есть присутствующие кто после Лего начал изучать реальный R&D, то поймут о чем я говорю.
Мое мнение что процесс разработки будущего, это по большей части продумывание и оптимизация алгоритма мехатроники с минимальной нагрузкой требований к механике. При этом IDE такого концепта должна соответствовать в.с. порогу уровня подростка 10 - 16 лет.
Под паллетайзером в моём комментарии речь именно про самоходные тележки/штабелёры с автоматическим управлением, которые возят и устанавливают паллеты, то есть про тот же класс driverless industrial trucks, на который и ссылается ISO 3691‑4.
Стандарты по роботам (ISO 10218‑2 и ISO/TS 15066) допускают совместную работу человека и робота только при ограничении энергии и силы до уровней, при которых даже контакт не приводит к травме; это реализуемо для лёгких коллаборативных манипуляторов, но никак не для многосоткилограммовой паллеты, особенно на высоте. Поэтому индустриальная практика для таких случаев - либо ограждённые ячейки, либо очень жёстко организованные общие зоны с ограничением скорости, зонами исключения для людей и системой обнаружения персонала, а не «свободное перемещение» в привычном смысле.
В этом контексте мой тезис был не про то, что «стандарты запрещают любую совместную работу», а про то, что конкретная конфигурация, где тяжёлый самоход с паллетой катается по полу буквально в общем проходе, а главным аргументом безопасности служит возможность ручного вмешательства оператора через кнопку - гриб, идёт вразрез как с ISO 3691‑4, так и с общими принципами риск‑ориентированного проектирования систем безопасности.
Вижу что полетаизеры выполняют работу в зонах со свободным перемещением людей, что категорически не допустимо из соображений техники безопасности, как бы разрабы не стучали себя в грудь кулаками, доказывая 100% безопаснось.
возможность ручного вмешательства оператора для устранения возможных неисправностей.
Полетайзер прет на рабочих и в это время оператор в прыжке нажимает на красную кнопку размером с ладонь? Причин запуска самохода может быть масса.
Ок, с этим проехали, для полного обзора линии чисто снования по полу полетайзеров не достаточно, это выглядит как новостная заметка, как это и есть на данном примере. Интересно что происходит когда поддон ( к слову он деревянный сколоченный гвоздями) с молоком на высоте 3 метра был неудачно установлен и произошел его перекос. Как система реагирует на такие ситуации?
В мире есть немало других логистических технологий, начиная от автоматизированных XYZ гантри манипуляторов, до 3D рельсовых матриц хранения в куче с конвейерными треками и для каждого из таких алгоритмов есть экономически обоснованная целесообразность.
Чтоб оценить идею применения С1, в статье недостаточно реальных иллюстраций с зонами, от точки приема до точки выдачи. Можно много рассуждать, но пока все это выглядит очень абстрактно и не факт что экономически логично для клиента.
А я хожу кругами вокруг этих Timekettle W4 Pro с функцией Ai синхронного первеода, с активным шумоподалением и для аудио прослушки. На сегодня они считаютя флагманским по качеству Ai (0,2 с задержка) но честного обзора пока на них нет, возможно из за их стоимости $381 на амазоне
Тема востребована, т.к. направлена на решение вопросов, которые происходят из причин их важности когда идеи нуждаются в прокачке с минимальными затратами и усилиями.О важности MVP в любом стартапе уже давно все сказано, при этом мало кто обсуждает проблемы инициаторов в выборе той или иной среды построения кода, от которого зависит аппаратный дизайн и то, как это легко и доступно увидеть в динамике на этапе идеи с начальными алгоритмами. То о чем здесь пишу, это часть осмысленного и моего проекта создания онлайн лаборатории под свою IDE включая и работу с аппаратной частью и симуляции и много еще всего, что должно работать на всех. Увы я не смогу дальше здесь развивать в подкастах эту тему, т.к. получу бан за промоушинг. Если кому интересно обращайтесь в личке.
У нас несколько другая сфера применения low-code автоматика и робототехника, но подход аналогичный, кубики программистам, их сбор инженерам - архитекторам, на выходе рабочий код управления аппаратным сценарием и аппаратные спецификации всего проекта. Что характерно инструкции для визуального ввода может генерировать обученная модель ИИ, таким образом, что инженеру архитектору достаточно на вербальном уровне поставить задачу (запустить моторо на 10с и остановить, или запустить до момента триггерного срабатывания по значению со стороны датчика положения каретки и т.д.)
К разработке программного ядра подход был на построение интерпретаторов команд бинарной логики, применяемых в системах автоматизированного логического управления.
Вообще-то правильным и логичным тоном в любой разработке считается применение встроенного в стенд такого источника питания, как и другой аппаратной части в виде уже существующих готовых модулей с требуемыми функциями и параметрами, которые в дальнейшем могут стать частью прототипа (репликация или как есть), при этом сегодня выбор таких готовых и выставленных на поток, как источников с в.у. характеристиками, так и других модулей, вполне позволяют вести их подбор в качестве универсальных компонентов к той архитектуре устройств, которые Вы разрабатываете сегодня или с идеями на завтра. Такой подход избавит Вас от дальнейших дополнительных затрат в создании прототипов или промышленных образцов.
UX/UI - в свое время это для успеха был кусок работы чуть ли не самым главным в Data Sciense. Помню момент, когда клиенты просто визжали от удовольствия, когда в качестве интерфейса получали свой рабочий кабинет с видами столов и ящиками в которых они любили рыться, что-то находить, далее размещать в отдельные разноцветные папки и передавать их содержимое своим сотрудникам, те, в сою очередь принимали содержимое адресных папок к дальнейшим задачам, которые соответствовали их должности и инструкциям и т.д. и т.п. Ошибки исключались, т.к. в алгоритме были заложены запреты на ошибочные (человеческий фактор или нарушение последовательностей инструкций).
Сейчас передо мной стоит более сложная задача - UX/UI IDE разработчика автоматики и робототехники где на ПК возлагаются задачи не только автоматизации процесса генерации исходного кода логического управления, но и функции логического контроллера под внешний I/O аппаратный интерфейс и здесь мне не совсем понятно, что в таком случае должен представлять из себя такой интерфейс(ы). Когда это кнопки с памятью вводимых состояний, дисплей часов для выставления там таймингов, селекторные кнопки для указания номеров USB портов и т.д. и т.п....
А еще практикуется такая фишка среди фрилансеров и всех их подопечных, когда они по договоренности с клиентами - крупными фирмами, демонстрируют другим потенциальным заказчикам "свои производственные площадки" которые по факту не являются ихними. Водят по цехам, IT отделам гостей как по зоопарку.
Почему бы и нет, спросите его, если это просто любопытство, а интерес к стороннему опыту все же продуктивней иметь из первоисточников, впрочем гигачат на данный момент дает вполне адекватное описание платформы и ее применение. :-
LV позволяет построить программную и аппаратную систему, которая выполняет те же функции, что и ОС, в условиях встраиваемых решений, промышленных контроллеров или систем реального времени. Это можно рассматривать как специализированную ОС-подобную среду, полностью разработанную в визуальной среде.
Не полный перечень возможностей:
Запуск кода на RT-контроллерах с детерминированным исполнением;
Управление потоками, приоритетами задач, прерываниями, синхронизацией и расписанием - то, что выполняет ядро RTOS;
Проектирование логического уровня "ядра" на уровне FPGA - реализация логики взаимодействия между устройствами, шин, интерфейсов;
Разработка приложений с параллельными вычислениями, распределенной логикой и управлением событиями - по сути, имитация ядра ОС на прикладном уровне;
Управление ресурсами, вводом/выводом, коммуникациями (Modbus, TCP/IP, CAN), памятью и задачами.
Вы можете построить систему, где LabVIEW:
Управляет всеми задачами (как диспетчер процессов).
Имеет цикл реального времени с высоким приоритетом (как планировщик).
Реализует драйверы устройств (через FPGA или I/O Nodes).
Управляет прерываниями, вводом-выводом и хранением данных (как ядро).
Работает автономно на хардваре без традиционной ОС.
Важно понимать, что LabVIEW не создает ОС в классическом смысле, но позволяет построить программную и аппаратную систему, которая выполняет те же функции, что и ОС.
здесь требуется конкретика, что проверять со стороны USB GPIO? Выше по ветке я дал описание решения которое применяется в программном контроллере, детали проекта обсуждаются здесь. Если у Вас возникнет желание выпустить авторскую публикацию на хабре с описанием платформы, окажу всяческое содействие. Я не писатель.
LabView это не ради "эмуляции ОС", а ради сокращения цикла "идея - исполнение" при разработке автономных логических систем.
Так что речь не про «берите любую IDE», а про осознанный выбор среды, в которой логика описывается так же наглядно, как монтируется схема — и может быть сразу проверена на железе через стандартный USB GPIO.
Впрочем при желании на LV можно и OC создать, для чего, это уже другой вопрос.
пришел не внезапно, а более чем 7 лет по озвученной Вами причине с уходом от проприетарности железа с его содержимым и того букета плюшек который он за собой тянет с клиента. Тема тянет не на одну статью, идея не из лучших отвлекать здесь кого либо на то, что здесь не предусмотрено к обсуждению. На данный момент это коробочное решение со всеми сопутствующими атрибутами и своим сообществом. Если интересно могу скинуть в личке.
Берите LabView, на нем можно делать всё.
Любопытно узнать, возможна ли в QMP реализации или моделирования реального логического контроллера, исполняющего логику в потоке данных или по триггерам/флагам, как это делается в автоматных логических контроллерах? Насколько мне известно среда не дает таких средств разработки.
Логично, что эмуляторы вроде QEMU не моделируют экспандеры, в контексте статьи хотел лишь указать, что мой подход не заменяет эмуляцию, но показывает, что задачами управления можно заниматься на другом уровне абстракции — в зависимости от целей проекта.
Как и Вы, в свое время я бился над такими задачами, у меня нет прямого ответа в плане - вот Вам SoC с интегрированным I2C GPIO-экспандером на базе PCF8574, MCP23017 и т.д., вместо этого я пришел к выводу - нет смысла искать I2C GPIO внутри SoC, когда можно построить работу ее логики вне SoC, взаимодействуя с периферией как в моем случае по USB + I2C, просто поменял стратегию когда это просто другой способ масштабирования ввода-вывода. Если интересно могу дать дисклеимер, но это выходит за рамки Вашей публикации.
Мне сразу в глаза ударило применение QEMU
где в качестве host применили SBC + QEMU
Я в нем не эмулировал ничего подобного, т.к. моя архитектурра CPUx86 и для подобных задач там больше пространства для творчества, вплоть до построения IDE.
интеграция протокола I2C где для полноценной поддержки I²C GPIO-пины должны быть подключены к I²C-модулю внутри микроконтроллера (то есть быть назначены как SDA/SCL).
Это мой частный случай, в отличие от встроенных GPIO-контроллеров микроконтроллеров, в ПК-системах GPIO возможны реализации через внешние модули, подключаемые по USB. Такие модули представляют собой интеллектуальные расширения, включающие в себя встроенные DAC/ADC, ARM-процессоры и интерфейсы связи (например, USB или RS-232, прочие конвертеры популярных протоколов). Управление осуществляется из основного программного обеспечения на ПК (хост) посредством программных микросервисов на базе FSM или API, обеспечивающие коммуникацию и логическое управление с каждым модулем.
Если не понятно, конкретизируйте вопрос, как Вы указали x86, это не Ваш случай, отсюда и недопонимание.