Да, приходится один раз нормаоьно настроить intelliSence, дальше хорошо работает. Сейчас он умеет использовать cmake или makefile для работы с проектом. Тогда все корректно подсказывает.
Хотелось бы ещё увидеть настройку SWV( serial wire viever) в связке openocd + vscode. Я долго мучился, но так и не смог поднять этот механизм, хотя он крайне полезен при разработке для отладки т.к. есть способ печати дебага из коробки и не надо занимать другие интерфейсы.
Ещё есть вопрос, почему rdimon, a не файл с заглушками для системных вызовов?
Читая такие статьи может пропасть страх изучения исходников kernel!
Было бы ещё интересно узнать о путях выгрузки драйверов и удаления устройства особенно в аварийном режиме. Все мы сталкивались с ситуацией когда переходник usb-serial вынужденно переподключался, и его физическое отключение и включение приводит к появлению нового /dev/ttyUSBx. Получается что регистрируется новый девайс с новым минорным номером драйвера, но старый остаётся висеть в нерабочем состоянии.
У вас очень интересный стек решений!
Привется написать эмулятор spi протокола для nrf и дальше к нему отладить прошивку самого мк. Да, это не так просто
Да, приходится один раз нормаоьно настроить intelliSence, дальше хорошо работает. Сейчас он умеет использовать cmake или makefile для работы с проектом. Тогда все корректно подсказывает.
Ответить на вопрос сложно. Этот форк давно не синхронизован с основным репозиторием. Если посмотреть в 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. Однако, для старой версии.
Хороший метод! когда процессы быстрые, однотипные и частые. Логи скорее для сложной логики внутри mcu
Хотелось бы ещё увидеть настройку SWV( serial wire viever) в связке openocd + vscode. Я долго мучился, но так и не смог поднять этот механизм, хотя он крайне полезен при разработке для отладки т.к. есть способ печати дебага из коробки и не надо занимать другие интерфейсы.
Ещё есть вопрос, почему rdimon, a не файл с заглушками для системных вызовов?
Читая такие статьи может пропасть страх изучения исходников kernel!
Было бы ещё интересно узнать о путях выгрузки драйверов и удаления устройства особенно в аварийном режиме. Все мы сталкивались с ситуацией когда переходник usb-serial вынужденно переподключался, и его физическое отключение и включение приводит к появлению нового /dev/ttyUSBx. Получается что регистрируется новый девайс с новым минорным номером драйвера, но старый остаётся висеть в нерабочем состоянии.
Очень круто. Редко кто задумывает использовать графический интерфейс из асм! Можно пользовать как обучалку для студентов вместо классического dosbox
Мы можем писать в SRAM, но теоретически сможем выполнить толькой 1-2 операции, а потом будем получать hard fault, т.к шина будет заблокирована
В описанном методе тоже используется вполне обычная лампа для экспозиции, однако даже не думал что можно рентгеном и ведь не придется снимать крышку!
Не узучал вопрос, но вероятно есть