Вы использовали HAL от вендора? когда я смотрел мне показался сырым.
Немного смутил "Загрузчик (16 Кб)", может сложиться впечатление что там отдельная прошивка. Мне кажется тут не хватает описания режимов загрузки MIK32 и того что в зависимости от Boot0/Boot1 в эту Загрузочную область отображается EEPROM или SPIFI или SRAM.
не обсуждая целесообразность адресной арифметики в этом месте, что будет при Channel равным нулю? address явно улетит за допустимый диапазон.
Или в функции CalcTimPulseLength у вас будет деление на ноль при входном параметре Degree < 3.
По барьерам памяти - насколько я понимаю, есть не так много ситуаций на Cortex-M4 где они нужны, так как нет переопределения порядка операций с памятью или выполнения инструкций и из-за особенностей AHB Lite и APB протоколов. Те примеры что я видел решались скорее dummy read\write, а не dsb https://developer.arm.com/documentation/ka003795/ Поэтому мне кажется, стоит более подробно исследовать причины HardFault и сравнить вашу реализацию с STM32CubeF4. Например, там я видел dummy read после установки APB1ENR, у вас на похожем месте dsb.
Потом ДМА нужно использовать когда надо исключить прерывания
Не совсем согласен, мне кажется цель ДМА освобождение полезного времени работы процессора в общем смысле, не важно от прерываний или поллинга.
Например, в вашем псевдокоде сохранение данных во флеш происходит в основном цикле. То есть лишних прерываний нет, но есть лишний поллинг силами процессора. Это накладывает определенные ограничения на время операции вычислений. Что случится в вашей программе если условие Tsyst - Tcalc > Tsave не выполнялось более 256 раз подряд и новые данные записывать некуда? Пришлось бы переходить на прерывания, а так как данных много, прерываний было бы несколько.
Реализация на ДМА выглядит максимально просто:
По прерыванию таймера стартовали ДМА транзакцию чтения АЦП.
По прерыванию завершения ДМА транзакции проверили нужно ли записать данные, если да - стартовали ДМА транзакцию записи во флеш.
В основном цикле вычисления и проверка недопустимо большого времени.
Если не секрет, вы использовали шифрование и secure boot на проекте?
Насколько знаю, начиная с ESP32-D0WD-V3 espressif ввели Secure Boot V2 и добавили защиту от атаки по питанию. Так что взломать новые esp32 станет сложнее.
А почему не от нуля? Никто не умер - отрава в нулевой пробирке.
В варианте где надо погубить как можно меньше мышей тоже с 1 начинаете.
Спасибо за полезную статью!
Вы использовали HAL от вендора? когда я смотрел мне показался сырым.
Немного смутил "Загрузчик (16 Кб)", может сложиться впечатление что там отдельная прошивка. Мне кажется тут не хватает описания режимов загрузки MIK32 и того что в зависимости от Boot0/Boot1 в эту Загрузочную область отображается EEPROM или SPIFI или SRAM.
После этой фразы стало интересно глянуть код. На беглый взгляд показалось что там немало мест, где возможны ошибки. Например, в SetPWM:
не обсуждая целесообразность адресной арифметики в этом месте, что будет при Channel равным нулю? address явно улетит за допустимый диапазон.
Или в функции CalcTimPulseLength у вас будет деление на ноль при входном параметре Degree < 3.
По барьерам памяти - насколько я понимаю, есть не так много ситуаций на Cortex-M4 где они нужны, так как нет переопределения порядка операций с памятью или выполнения инструкций и из-за особенностей AHB Lite и APB протоколов. Те примеры что я видел решались скорее dummy read\write, а не dsb https://developer.arm.com/documentation/ka003795/ Поэтому мне кажется, стоит более подробно исследовать причины HardFault и сравнить вашу реализацию с STM32CubeF4. Например, там я видел dummy read после установки APB1ENR, у вас на похожем месте dsb.
Не совсем согласен, мне кажется цель ДМА освобождение полезного времени работы процессора в общем смысле, не важно от прерываний или поллинга.
Например, в вашем псевдокоде сохранение данных во флеш происходит в основном цикле. То есть лишних прерываний нет, но есть лишний поллинг силами процессора. Это накладывает определенные ограничения на время операции вычислений. Что случится в вашей программе если условие
Tsyst - Tcalc > Tsaveне выполнялось более 256 раз подряд и новые данные записывать некуда? Пришлось бы переходить на прерывания, а так как данных много, прерываний было бы несколько.Реализация на ДМА выглядит максимально просто:
По прерыванию таймера стартовали ДМА транзакцию чтения АЦП.
По прерыванию завершения ДМА транзакции проверили нужно ли записать данные, если да - стартовали ДМА транзакцию записи во флеш.
В основном цикле вычисления и проверка недопустимо большого времени.
Всю статью ждал когда на сцене появится DMA и освободит процессор от ненужной работы с периферией.
Насколько знаю, начиная с ESP32-D0WD-V3 espressif ввели Secure Boot V2 и добавили защиту от атаки по питанию. Так что взломать новые esp32 станет сложнее.