Комментарии 20
я правильно понимаю, что мк работает в режиме отладки, т.е. прошивки на нем лучше не иметь? И что получается по задержке и джиттеру, если, например, ногой дрыгать?
Если мы про первый случай с PinTool, там МК находится под отладкой
Если вы про второй случай, где инструментируются код драйверов, то по умолчают там тоже все процедуры выполняются под отладкой. Но вы можете написать свой клиент в REMCU и сделать выполнение операций через любой протокол, хоть сеть хоть последовательный
прошивки на нем лучше не иметь?
Можно и иметь, через отладчик можно сбросить чип в режим halt и прошивка не будет выполняться
И что получается по задержке и джиттеру, если, например, ногой дрыгать?
Все сильно зависит от конфигурации вашего ПК железа, отладчика и софта отладчика
Максимум что мне пока удалось вытянуть это пару КГц переключения пина
Обычная настольная система Windows/Linux/MacOs это не реалтаймовые системы, поэтому задержка и джиттер не регламентированы, ну а так стоит готовиться скорее всего к паре миллисекунд
Название статьи довольно расплывчатое. Можно подумать, что в статье будет разбор проброса железа в виртуальную машину
Выглядит очень красиво. Какой-нибудь сложный код, лениво дрыгающий ножкой, отлаживать должно быть сильно удобнее.
Вот только я одно не понял - у вас там ведь нет прерываний? А идеи, как их поддержать, есть? Иначе вообще непонятно, зачем это всё - любой сколь сложный код 1-в-1 на ПК перенести не получится...
Прерываний нет, но тем не менее их поддерживать можно. Конечно такой скорости реакции не дождешься, но переносимость обеспечить можно.
Если переходить на polling(опрос) не хочется, то он все равно выручит с прерываниями. Можно сделать в отдельном потоке примерно такой код:
while(true){
if(check(IRQ_flag_UART))
IRQ_UART_Handler();
else if(check(IRQ_flag_TIM1))
IRQ_TIM1_Handler();
else if(check(IRQ_flag_DMA1))
IRQ_DMA1_Handler();
...
}Вот так банально можно сделать иммитатор. Есть более сложные схемы, в зависимости от микроконтроллера и его системы прерываний.
Выглядит очень красиво. Какой-нибудь сложный код, лениво дрыгающий ножкой, отлаживать должно быть сильно удобнее.
Да ножку можно и заMock'aть у себя в коде)
А вот аналоговую часть или что-то по шине гоняется(не быстро) вот тут помогает (мое субъективные мнение)
По идее, можно в первом случае не проверять каждое обращение к памяти. Достаточно через userfaultfd() ловить page fault. Возможно, иногда ещё потребуется исключить диапазон адресов регистров МК из доступных в user space. Но это тоже решаемо.
В случае записи в регистр, можно ловить и делать через userfaultfd, а если чтение из регистра требуется, то как в этом случае возвращать значение в то место где оно запрашивалось?
К примеру:
int pin_PC0_value = GPIOC->IDR & 0x1;что бы стало в рантайме
int pin_PC0_value = 0xA5 & 0x1;https://docs.kernel.org/admin-guide/mm/userfaultfd.htmlUFFDIO_CONTINUE maps an existing, previously-populated page."
То есть в обработчике userfaultfd Вы просто подменяете страницу, вызвавшую page fault страницей, которую заранее аллоцировали. И в которую по нужному адресу Вы можете предварительно поместить все, что желаете.
Спасибо за документацию. Судя по написанному в режимеUFFDIO_REGISTER_MODE_MINOR можно такое провернуть
For
UFFDIO_REGISTER_MODE_MINORfaults, there is an existing page (in the page cache). Userspace has the option of modifying the page's contents before resolving the fault. Once the contents are correct (modified or not), userspace asks the kernel to map the page and let the faulting thread continue withUFFDIO_CONTINUE.
В 2018-ом такой штуки еще не было, исходя из этого поста https://lwn.net/Articles/844443/ это явилось в начале 21-ого
Эта технология, когда PC является кукловодом для микроконтроллера-марионетки, идеальна для тестов на пропай при массовом производстве электронных плат.
Можно на NetTop PC прокручивать хитрый алгоритм Cross-Detect
https://habr.com/ru/articles/762142/
и протестировать на PCB до того как на MCU накатят первую прошивку.
Согласен, можно и для таких тестов гонять, но я в основном использовал для тестирования сторонних чипов на плате на их работоспособность(акселерометры, езернет, звуковые синтезаторы и проч)
Кстати, спасибо за добрые слова из вашей статьи)
Суть этой технологии изложена в культовом тексте
Как перестать писать прошивки для микроконтроллеров и начать жить https://habr.com/ru/articles/433504/
Листинг 1 - пошаговая инструкция по отстрелу ноги.
DjDjghj
Вопрос знатокам: что будет, если повторить чтение?
Где, блин, volatile дели?
Глаз алмаз... Поэтому тут и нет второго чтения =)
Я почему-то поленился скопировать полностью структуру GPIO_TypeDef
typedef struct
{
__IO uint32_t CRL;
__IO uint32_t CRH;
__IO uint32_t IDR;
__IO uint32_t ODR;
__IO uint32_t BSRR;
__IO uint32_t BRR;
__IO uint32_t LCKR;
} GPIO_TypeDef;
Там __IO - это и есть volatile
#define __IO volatile /*!< defines 'read / write' permissions */Для одного раз это норм отработает, дальше никто не обязан лезть еще раз в память(при определенном уровне оптимизации, разумеется!)
Спасибо что заметили, грамотное замечание
Хардварный проброс