не обсуждая целесообразность адресной арифметики в этом месте, что будет при 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 станет сложнее.
После этой фразы стало интересно глянуть код. На беглый взгляд показалось что там немало мест, где возможны ошибки. Например, в 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 станет сложнее.