Комментарии 20
Спасибо за статью!
Не могли бы вы пояснить расхождения использованной версии QEMU с официальной, чтобы всем было понятнее ? Насколько там всё сильно в итоге разошлось ?
Я вижу, что в официальном репозитории реализованы только UART, SPI:
https://elixir.bootlin.com/qemu/v9.2.0-rc3/source/hw/arm/stm32f100_soc.c#L152
Ответить на вопрос сложно. Этот форк давно не синхронизован с основным репозиторием. Если посмотреть в https://github.com/qemu/qemu/blob/master/hw/arm/stm32f100_soc.c, то можно найти определение для f100_soc, в котором почти ничего не реализовано кроме самого cortex ядра. Те использованная версия это старый qemu c доработками конкретно для stm32 периферии.
Например, тут добавляются gpio и uart https://github.com/beckus/qemu_stm32/blob/stm32/hw/arm/stm32_f103c8.c. А здесь можно найти имплементацию других функций. https://github.com/beckus/qemu_stm32/tree/stm32/hw/arm.
Те, расхождения только в том, что добавлена реализации периферии stm32 и добавлены несколько soc. Однако, для старой версии.
Не понял, как эмулировать внешнее по отношению МК окружение? В постейшем виде - зашумленный сигнал АЦП. В более сложном - обмен через NRF24L01 или динамическая графика хотя бы на ST7735
Привется написать эмулятор spi протокола для nrf и дальше к нему отладить прошивку самого мк. Да, это не так просто
В случае STM32 QEMU это просто программа в userspace не более. Зашумленный сигнал АЦП вы можете смоделировать, в принципе, любой. Остальное тоже можете смоделировать, можете реальное устройство подключить. А нужно ли оно вам это другой вопрос.
Зашумленный сигнал АЦП вы можете смоделировать, в принципе, любой
Смоделировать то я смогу. Вот только будет ли он эмулирован так же как в железе? И не будет ли проще использовать синтезатор (генератор) и МК в железе.
можете реальное устройство подключить
Подключать тот же ST7735 через FT2232H и пробрасывать его в QEMU - боюсь еще тот квест.
А нужно ли оно вам это другой вопрос.
Вот как раз на этот вопрос я ищу ответ. С одной стороны, обвешиваться осликами, мультиметрами, логическим анализатором и синтезатором сидя в консоли - муторно. Но будет ли проще в QEMU?
Всё же в JTAG сидеть приходится редко, так как основные алгоритмы можно отладить и на ПК, а тесно связанные с железом - требуют соблюдения жесткой времянки, что не позволяет отлаживать их пошагово.
Вы правильные вопросы задаёте,
Вот только будет ли он эмулирован так же как в железе?
Конечно не будет, модель процесса это не сам процесс.
И не будет ли проще использовать синтезатор (генератор) и МК в железе.
Может будет, а может и не будет. Если у вас всё "под паром", вы владеете хорошо владеете инструментом, то конечно быстрее воспользоваться тем, что есть.
А вот если вы это действие повторяете из раза в раз с тем же самым набором компонентов, тогда чисто "программное" решение, возможно будет выгоднее.
Подключать тот же ST7735 через FT2232H и пробрасывать его в QEMU - боюсь еще тот квест.
Ну как раз USB очень просто пробросить.
Вот как раз на этот вопрос я ищу ответ. С одной стороны, обвешиваться осликами, мультиметрами, логическим анализатором и синтезатором сидя в консоли - муторно. Но будет ли проще в QEMU?
Не зная железа, которое вы используете сложно сказать. Но если брать самый плохой вариант то было бы проще, если бы всё что вам нужно уже было из "коробки". В противном случае это превращается в долгий проект, где вам самому необходимо написать недостающие компоненты.
В QEMU использованном в статье нет и половины всей периферии stm32f103, а в официальном репозитории её еще меньше - но тем не менее того что есть автору для решения своей задачи хватило.
Ну как раз USB очень просто пробросить
Так для ST7735 пробрасывать надо не USB, а SPI с тремя сигнальными линиями GPIO. У ST7735 странный SPI с одной двунаправленной шиной для данных. Так что управлять надо CS, R/W и Reset через GPIO. А то, что FT2232H предоставляет к этому интерфейс через USB, в данном случае, лишь усложняет задачу.
К тому же, мне чаще приходится работать не с STM32, а с ESP32. А с последним в QEMU может оказаться даже тяжелей, чем с STM32. Но тут уже надо пробовать и разбираться. Начну с ESP32-C3 (RISC-V). Если что накопаю - отпишусь.
а SPI с тремя сигнальными линиями GPIO. У ST7735 странный SPI с одной двунаправленной шиной для данных.
А вот это большая проблемка, соблюсти времянку тут тяжело будет (если именно прокидывать, а не делать эмуляцию целиком).
Но тут уже надо пробовать и разбираться. Начну с ESP32-C3 (RISC-V). Если что накопаю - отпишусь.
С такими вещами всегда готов помочь ! Пишите - буду рад ответить.
Гораздо проще и правильнее научиться, наконец, писать юнит-тесты https://pragprog.com/titles/jgade/test-driven-development-for-embedded-c/
Все эти "обмены с внешним окружением" - лишь передача данных, не более
VS Code пользоваться нормально сложно, постоянно какие-то проблемы с IntelliSense были и отладка это боль. Сам пользуюсь Visual Studio, SEGGER Embedded Studio, CLion.
Спасибо за статью. Не знал, что в QEMU есть эмулятор периферии. Хотя как понял, он довольно неполный
Работаю примерно тем же путем, но собираю прошивку просто под десктоп.
Железноспецифичные вещи меняю на аналоги, типа флешку на файл, вход концевика значение в файле. Внешние скрипты просто пишут в файлы эмулируя работу внешних устройств.
Эмуляцию окружения и его детализированность делаю в разумных пределах, где-то чуть подробнее, где-то просто затычка
Подобными способами отлаживаю и проверяю "бизнес" логику. Для железа отдельный hw тесты
Графику просто вывожу фрейм буфер в файлы картинок, с довольно низким ФПС. Можно наверное и с высоким, но не вижу для себя смысла. Все что нужно вижу)
Всю эту требуху держу на tmpfs. Если надо сдампить стейт, то отдельными скриптами сохраняю состание всех нужных файлов, потом также делаю рестор.
Здесь можно посмотреть обычную эмуляцию используя только Qemu.
Отладчик GDB - это очень мощный инструмент для отладки, но им надо уметь пользоваться. Здесь ссылка по работе с отладчиком, а здесь ссылка как можно отлаживать разные архитектуры на одном компьютере (в Linux в основном, но я думаю если использовать WSL, то тоже можно).
Просто как дополнительная информация. )))
Не проще ли реальное окружение чем настройка qemu?. Плюс совершенно не факт что баги отлаженные в эмуляторе не появятся потом в железе. Девборды доступные и недорогие. Например сейчас проект с TCP стеком. Устройство приемное в нем стек реализован некорректно. Такое в quemu вряд ли повторишь. А так получается двойное время тратить. Отладил в эмуляторе и потом по новому в железе
Так это каждый для себя сам решает,
Девборды доступные и недорогие.
Это правда.
Устройство приемное в нем стек реализован некорректно. Такое в quemu вряд ли повторишь. А так получается двойное время тратить. Отладил в эмуляторе и потом по новому в железе
А вот это не факт. В QEMU вполне себе повторишь, может даже оказатся, что в одной ревизии кривой, а в новой уже поправили, такое тоже можно учесть.
Возможно, выгоднее иметь какой-никакой смоук-тест на куче QEMU и небольшое кол-во реальных установок.
Использую для работы с МК среды на базе Eclipse. Да не фонтан, но пока что для меня это оптимальный вариант. Тормозит иногда, но работает стабильно, предсказуемо, просто и быстро всё настраивается. Отладкой в эмуляторе думаю стоит заниматься на этапе учёбы, в реальном же проекте проще и быстрее заказать отладку или вообще собирать на конечном устройстве
Тестирование и отладка встраиваемых систем STM32 с использованием QEMU эмулятора и Docker