Comments 29
Опубликовано логическое продолжение "прозрачного" взаимодействия с устройствами внутри QEMU - QEMU: как организовать прозрачное взаимодействие с I2C-устройствами, которая является более удачным применением CUSE.
У Вас на главной картинке светодиод к ноге МК без резистора приставлен. Жуть жуткая :-)
Возможно вопрос не в тему но все же. Вы пробовали вместо qemu использовать renode или какой-либо другой фреймворк, если да можете поделиться опытом, лучше хуже.
Вообще говоря вопрос в тему, поскольку не вы один его задаёте. Я смотрел renode и он, если я не ошибаюсь, является не функциональным, а так называем точным эмулятором, как например spike. То есть сравнивать их уже не очень корректно.
А именно прямых аналогов QEMU, я назвать не могу. Разве что Bochs, VirtualBox но они ограничены x86 архитектурой, что делает их для меня неинтересными.
Помимо этого, renode:
мне показался несколько более бедным по количеству модулей (периферии);
в большой степени написан на C#, который я изучать просто не хочу;
Берите LabView, на нем можно делать всё.
Разве LabView является средой эмуляции для для запуска ОС?)) Это всё равно что сказать "берите свою любимую IDE, там можно делать всё"
LabView это не ради "эмуляции ОС", а ради сокращения цикла "идея - исполнение" при разработке автономных логических систем.
Так что речь не про «берите любую IDE», а про осознанный выбор среды, в которой логика описывается так же наглядно, как монтируется схема — и может быть сразу проверена на железе через стандартный USB GPIO.
Впрочем при желании на LV можно и OC создать, для чего, это уже другой вопрос.
Можете поделиться таким опытом? Как про "может быть сразу проверена на железе через стандартный USB GPIO.", думаю статья вышла бы не плохая.
НУ и отдель про "LV можно и OC создать". Я бы не писал скрипты, да и остальные не изобретали бы автотесты всякие для ОС. Было бы круто
LV позволяет построить программную и аппаратную систему, которая выполняет те же функции, что и ОС, в условиях встраиваемых решений, промышленных контроллеров или систем реального времени. Это можно рассматривать как специализированную ОС-подобную среду, полностью разработанную в визуальной среде.
Не полный перечень возможностей:
Запуск кода на RT-контроллерах с детерминированным исполнением;
Управление потоками, приоритетами задач, прерываниями, синхронизацией и расписанием - то, что выполняет ядро RTOS;
Проектирование логического уровня "ядра" на уровне FPGA - реализация логики взаимодействия между устройствами, шин, интерфейсов;
Разработка приложений с параллельными вычислениями, распределенной логикой и управлением событиями - по сути, имитация ядра ОС на прикладном уровне;
Управление ресурсами, вводом/выводом, коммуникациями (Modbus, TCP/IP, CAN), памятью и задачами.
Вы можете построить систему, где LabVIEW:
Управляет всеми задачами (как диспетчер процессов).
Имеет цикл реального времени с высоким приоритетом (как планировщик).
Реализует драйверы устройств (через FPGA или I/O Nodes).
Управляет прерываниями, вводом-выводом и хранением данных (как ядро).
Работает автономно на хардваре без традиционной ОС.
Важно понимать, что LabVIEW не создает ОС в классическом смысле, но позволяет построить программную и аппаратную систему, которая выполняет те же функции, что и ОС.
Как про "может быть сразу проверена на железе через стандартный USB GPIO.", думаю статья вышла бы не плохая.
здесь требуется конкретика, что проверять со стороны USB GPIO? Выше по ветке я дал описание решения которое применяется в программном контроллере, детали проекта обсуждаются здесь. Если у Вас возникнет желание выпустить авторскую публикацию на хабре с описанием платформы, окажу всяческое содействие. Я не писатель.
ОС - подобная среда это всё же не эмуляция. Про не писателя - заметил, жаль что такой бесценный личный опыт не передается в виде некого руководства. Просто список возможностей можно и у гигачата спросить :-D
Это же просто копи-паста из какой-нибудь LLM. Набор общих слабосвязанных фраз без какой-либо конкретики.
Вы осознаёте, что слепо копируя, вы похожи на двоечника, который списывает материал, который не понимает ?
То что GPIO это интерфейс совершенно очевидно. А если копнуть чуть глубже то это просто область памяти.
Как то все сложно трактуется автором. По сути GPIO - это DAC или ADC с разведеными I/O пинами которые по дизайну могут быть как онбоард контроллере, так и виде его внешних расширений, соответственно с интерфейсом коммуникаций, к примеру в моем случае выходной USB GPIO это ADC который конвертирует частотный пакет сигналов со стороны контроллера в бинарные логические уровни в пределах 0,5 - 5V на 16 каналов с подтяжкой к земле. Что касается входного USB GPIO (у меня это целевой USB-RS232, отдельный модуль) ADC на 16 каналов который 12 bit обеспечивает счет напряжений в пределах от 0,001 - 3,300V.
Оба модуля несут на себе ARM 32 и все управление ими происходит на внешних микросервисах.
Как-то так.
Развейте пожалуйста мысль, у меня никак не сочетается ваш комментарий с тематикой статьи.
Это мой частный случай, в отличие от встроенных GPIO-контроллеров микроконтроллеров, в ПК-системах GPIO возможны реализации через внешние модули, подключаемые по USB. Такие модули представляют собой интеллектуальные расширения, включающие в себя встроенные DAC/ADC, ARM-процессоры и интерфейсы связи (например, USB или RS-232, прочие конвертеры популярных протоколов). Управление осуществляется из основного программного обеспечения на ПК (хост) посредством программных микросервисов на базе FSM или API, обеспечивающие коммуникацию и логическое управление с каждым модулем.
Если не понятно, конкретизируйте вопрос, как Вы указали x86, это не Ваш случай, отсюда и недопонимание.
Недопонимание возникло из-за того, что всё что вы говорите безусловно верно, но к тематике статьи отношения не имеет. Ещё раз - мы хотим управлять тем, что есть на SoC, не подключать НОВЫЙ контроллер, не прокидывать из основной системы через USB или PCI (которых вообще говоря может и не быть). Например мы хотим управлять и считывать GD32_GPIO_A 0x40010800 в QEMU из основной системы.
Вот например в первой статье описаны два "чужеродных" GPIO контроллера https://habr.com/ru/companies/yadro/articles/925860/ и описано почему они не всегда подходят.
Мне сразу в глаза ударило применение QEMU
некоторое время был одержим идеей «прозрачного» взаимодействия с устройствами внутри QEMU — использовать те же библиотеки
где в качестве host применили SBC + QEMU
Я в нем не эмулировал ничего подобного, т.к. моя архитектурра CPUx86 и для подобных задач там больше пространства для творчества, вплоть до построения IDE.
интеграция протокола I2C где для полноценной поддержки I²C GPIO-пины должны быть подключены к I²C-модулю внутри микроконтроллера (то есть быть назначены как SDA/SCL).
где в качестве host применили SBC + QEMU
Нет - только QEMU, SBC внутри QEMU =), мы эмулируем ast2600 полностью, хост вообще говоря может быть любым, если на нём Linux (ну в некоторых случаях можно и Windows), конкретно я делал на amd64, но опять же годится практически всё, так как мы используем QEMU System TCG, а не KVM.
интеграция протокола I2C где для полноценной поддержки I²C GPIO-пины должны быть подключены к I²C-модулю внутри микроконтроллера (то есть быть назначены как SDA/SCL).
Ни разу не встречал I2C GPIO расширителей интегрированных в SoC. И опять же если вы эмулируете в QEMU SBC с подключенным GPIO расширителем (неважно каким, главное, что вы его тоже эмулируете), перед вами встаёт та же самая проблема, что и с GPIO которые находятся непосредственно в SoC.
Ни разу не встречал I2C GPIO расширителей интегрированных в SoC. И опять же если вы эмулируете в QEMU SBC с подключенным GPIO расширителем (неважно каким, главное, что вы его тоже эмулируете), перед вами встаёт та же самая проблема, что и с GPIO которые находятся непосредственно в SoC.
Как и Вы, в свое время я бился над такими задачами, у меня нет прямого ответа в плане - вот Вам SoC с интегрированным I2C GPIO-экспандером на базе PCF8574, MCP23017 и т.д., вместо этого я пришел к выводу - нет смысла искать I2C GPIO внутри SoC, когда можно построить работу ее логики вне SoC, взаимодействуя с периферией как в моем случае по USB + I2C, просто поменял стратегию когда это просто другой способ масштабирования ввода-вывода. Если интересно могу дать дисклеимер, но это выходит за рамки Вашей публикации.
Вы путаете тёплое с мягким PCF8574, MCP23017 это и есть I2C GPIO-экспандеры они никуда не интегрированы, они сами по себе.
Никто в здравом уме не будет интегрировать SPI, I2C расширители, RTC и прочие устройства на кристалл, то есть в SoC.
вместо этого я пришел к выводу - нет смысла искать I2C GPIO внутри SoC
Потому что их не существует в природе.
когда можно построить работу ее логики вне SoC, взаимодействуя с периферией как в моем случае по USB + I2C
Вы упорно не желаете замечать проблематики и мешаете всё в кучу.
Вот эти ваши
когда можно построить работу ее логики вне SoC, взаимодействуя с периферией как в моем случае по USB + I2C
Они откуда в QEMU возьмуться - от сырости заведутся ?
Постарайтесь структурированно ответь - "Вы что собственно хотите то ? Какие ваши конкретные предложения или замечания ?"
Логично, что эмуляторы вроде QEMU не моделируют экспандеры, в контексте статьи хотел лишь указать, что мой подход не заменяет эмуляцию, но показывает, что задачами управления можно заниматься на другом уровне абстракции — в зависимости от целей проекта.
эмуляторы вроде QEMU не моделируют экспандеры
Моделируют.
в контексте статьи хотел лишь указать, что мой подход не заменяет эмуляцию, но показывает, что задачами управления можно заниматься на другом уровне абстракции — в зависимости от целей проекта.
А никто никого не заменяет. Ваш подход тоже прекрасно эмулируется при наличии такого желания и точно так же при эмуляции потребует либо QMP либо решения подобного выше.
Ваш подход тоже прекрасно эмулируется при наличии такого желания и точно так же при эмуляции потребует либо QMP либо решения подобного выше.
Любопытно узнать, возможна ли в QMP реализации или моделирования реального логического контроллера, исполняющего логику в потоке данных или по триггерам/флагам, как это делается в автоматных логических контроллерах? Насколько мне известно среда не дает таких средств разработки.
Я вас прошу прочитайте всё таки материал, прежде чем задавать вопросы.
Любопытно узнать, возможна ли в QMP
QMP это просто протокол основанный на JSON, чтобы управлять и получать информацию о запущенном экземпляре QEMU.
реализации или моделирования реального логического контроллера
Не ясно, что значит реального и логического контроллера, но можно создать функциональную модель практически любого устройства или, в некоторых случаях, прокинуть внутри эмуляции физическое или реализованное на ПЛИСе.
Если вы имеете ввиду ПЛК, то с одной стороны мне абсолютно непонятно, как вы к этому внезапно пришли, а с другой стороны чем ПЛК принципиально отличается от микроконтроллера помимо того, что там зашит проприетарный софт ?
Если вы имеете ввиду ПЛК, то с одной стороны мне абсолютно непонятно, как вы к этому внезапно пришли, а с другой стороны чем ПЛК принципиально отличается от микроконтроллера помимо того, что там зашит проприетарный софт ?
пришел не внезапно, а более чем 7 лет по озвученной Вами причине с уходом от проприетарности железа с его содержимым и того букета плюшек который он за собой тянет с клиента. Тема тянет не на одну статью, идея не из лучших отвлекать здесь кого либо на то, что здесь не предусмотрено к обсуждению. На данный момент это коробочное решение со всеми сопутствующими атрибутами и своим сообществом. Если интересно могу скинуть в личке.
Опубликовано логическое продолжение "прозрачного" взаимодействия с устройствами внутри QEMU - QEMU: как организовать прозрачное взаимодействие с I2C-устройствами, которая является более удачным применением CUSE.
GPIO — тоже интерфейс, а также QEMU GPIODEV и GUSE