VladislavS

+1. Что 150 мкс, что 150 мс - суть одно и то же. При внутрисхемной прошивке вообще секунды контроллер в ауте. Схемотехника должна это предусматривать.

А где отладка то? Регистры процессора и периферии, дизасм?

Чисто в педагогических целях стоит решить задачу самому.

J-Link это всего лишь адаптер, он ничего сам не делает. Делает программа, которая с его помощью прошивает. Программ этих чуть больше чем дофига и каждая делает посвоему. Собственно и OpenOCD через J-link шить умеет.

На время отладки все остальные прерывания отключить, колбэки убрать. Добиться отсутствия пропусков и понемногу возвращать функционал.

Вообще-то, Кернигана и Ритчи 🙂 Это никому не повредит. Но что-то мне подсказывает, что там ни про работу с volatile сущностями, ни про оптимизирующий компилятор, ни про то как данные с задержками по шинам бегают, ни вообще про эмбэдд ни слова не будет. А до Страуструпа ещё надо дорасти.

Тут, кстати, "они там все" запросто получат двойной вход в одно и то же прерывание. Но об этом хомячкам не расскажут.

Между чтение для обработки и повторным чтением для очистки могло произойти что угодно. Это Секрет Полишинеля. Впрочем, тот код что для них индусы пишут, ещё ничего. :)))

А потом у вас прерывания теряются. Тут вы очистили флаги, которые "вскочили" во время обработки текущего прерывания, не обработав. Смотреть прямо в регистре периферии микроконтроллер не может. Он сначала считывает в регистр процессора, а затем смотрит. Локальная переменная будет расположена в регистре процессора. Не нужно много раз читать регистр статуса в регистр процессора, это напрасная трата времени в прерывании.

Искать надо там где потерял, а не там где лучше видно. Вроде это очевидно.

Да там много, на первых страницах разделела ARM, RISC-V читать.

Теоретически да. Несколько тактов "под угрозой". Безопаснее будет TIMER_INTF(TIMER1) = ~i;

А я бы вообще вот так сделал u32 i = TIMER_INTF(TIMER1); TIMER_INTF(TIMER1) = 0; if (i & TIMER_INTF_CH0IF) { ... } if (i & TIMER_INTF_CH1IF) { ... }

Никак оно не будет работать. Сто раз уже писали - нужен DDS - возьми DDS и не сношай людям мозги.

Это совсем про другое. В исполняемый файл добавляется исходный код. Browse information в настройках среды включается.

После макросов min и max деже читать этот ахтунг неохота.

Что-то мне подсказывает, что переход в double будет дешевле делений/умножений/приведений.

Какая разница, будет у вас там 2e-8 или 1e-3 ошибка, если вы на всё что меньше 0.1 в итоге чихаете? PS: Как писали раньше, принимаем младший разряд int за 0.1 и работаем в целых числах.

Мои глаза!!! Что это изменит? Значение 1.1 во float не представимо точно.

У меня для совместимости с разными компиляторами (тулчейнами) вот такая конструкция используется #ifdef __cplusplus extern "C" { #endif #ifdef __ICCARM__ int __low_level_init(void) #else void SystemInit() #endif { // Код инициализации железа #ifdef __ICCARM__ return 1; #endif } #ifdef __cplusplus } #endif А с чего вы взяли что там одиночная переменная? Ясно же, что пример тестовый, что там реально в куче ХЗ.

Да вроде всё работает. Настройки по умолчанию. Память под кучу выделена?

Это только японские бракоделы свои машины постоянно отзывают. ВАЗ себе такого не позволяет.

Чувствуется инженерный подход :))) Незначительно! Результат ничто - процесс всё!

Не знаю это ли вы имеете в виду. Вот у меня в одной из библиотек обработчик прерываний USB. В нём IRQHandlers это список типов. Для каждого элемента списка выполняется лямбда. А сам список зависит от реализуемого класса. Например, для CDC обработчики двух конечных точек. Вообще-то переменная. Изменять нельзя, правда. :))) Это и в православном С так было со статическими локальными переменными.

И при написании своих библиотек. В рядовом коде они, действительно, выглядят не очень уместно. Но когда с ними на ты, то так и подмывает применить. В смысле? auto constexpr X = 100; auto Y = 100; auto func() { int constexpr i = X<<2; // Компайлтайм, Ok int constexpr I = Y<<2; // Рантайм, ошибка } Ни в коем случае, это сделает локальную переменную фактически глобальной для данной функции, но она всё так же должна быть инициализирована вычисленным на этапе компиляции значением. и это не зависит от оптимизации. При любой оптимизации должно быть вычислено на этапе компиляции. Да вроде всё просто: 1. constexpr переменные (читай константы). Они всегда должны быть инициализированы значением вычисленным на этапе компиляции. 2. constexpr функции. Они могут работать как в компайлтайме, так и в рантайме. В первом случае (когда все условия сложились) их значения можно использовать там где подразумевается константа этапа компиляции: параметры шаблонов, инициализация constexpr переменных, if constexpr()... Если значение нельзя в компайлтайме вычислить, то работает как обычная функция в рантайме. В С++20 появилось более жёсткое consteval, которое не пускает функцию в рантайм. 3. if constexpr() Тут всё просто. Выражение "под условием" должно быть вычислено на этапе компиляции.