STM32 новичку в ARM что к чему

[ARV]

вопрос о том, что я упускаю.

сделал измерение загрузки ОS следующим способом:
1. сразу после инициализации периферии, до запуска ОС и до создания задач измеряю длительность работы функции задержки:

Код: Выделить всё

  // инициализация измерения загрузки
  HAL_TIM_Base_Start(&htim22);
  __HAL_TIM_GET_COUNTER(&htim22) = 0;
  load_check();
  FreeRunLoadTime = __HAL_TIM_GET_COUNTER(&htim22);
  HAL_TIM_Base_Stop(&htim22);

2. в Idle-задаче снова измеряю время этой задержки и вычисляю процент загрузки:

Код: Выделить всё

void vApplicationIdleHook(void) {
	uint32_t time = xTaskGetTickCount();

	load_check();
	time = xTaskGetTickCount() - time;

	DEV_REGS.CPU_Load = 100.0 - (100.0 * FreeRunLoadTime) / time;
	SWAP32(&DEV_REGS.CPU_Load);
}

и после перепрошивки МК получаю отрицательную величину загрузки - почему? вроде ж после перепрошивки происходит пересброс МК, и, значит, все мои переменные должны заново переинициализироваться...

очевидно, что я чего-то не понимаю... чего именно?

именно после перепрошивки, т.к. после сброса показания положительные.

[Аlex]

__HAL_TIM_GET_COUNTER(&htim22) = 0;

Это как ?
Функция возвращает какое-то значение. Как ему (возвращаемому значению) можно что-то присвоить ?
Наверное, подразумевалось - установка значения таймера (CNT) равным нулю ?
Нужно делать что-то приблизительно такое :
hTim->Instance.CNT = 0;
Не помню точно, как на Хале вытаскивать таймер. Можно подсмотреть в реализации __HAL_TIM_GET_COUNTER.

И второй момент. Вначале для измерения используется таймер, а в Idle таске - Tick Counter (счётчик системных тиков ОСьки). Что-то не клеется

Добавлено after 13 minutes 41 second:
PS: Помнится, я как-то заморачивался с подобной задачей. Мне потребовалось создавать отдельный таск с высоким приоритетом, в котором обрабатывался счётчик, который инкрементируется в Idle. При старте мы сначала подсчитываем кол-во инкрементов счётчика, а затем используем это значение как эталонное. Время для всех расчётов - 1 сек.
Только стартовый подсчёт эталона необходимо производить до запуска всех рабочих тасков. Подсчитали, затем запускаем все остальные таски.

[jcxz]

[uquote="Аlex",url="/forum/viewtopic.php?p=4690018#p4690018"]PS: Помнится, я как-то заморачивался с подобной задачей. Мне потребовалось создавать отдельный таск с высоким приоритетом, в котором обрабатывался счётчик, который инкрементируется в Idle. При старте мы сначала подсчитываем кол-во инкрементов счётчика, а затем используем это значение как эталонное. Время для всех расчётов - 1 сек.[/uquote]Я тоже примерно так во всех проектах делаю. И ARV я тоже советовал такой способ. Даже исходный код приводил на electronix.ru. Но похоже он так ничего и не понял, раз продолжает вошкаться с замерами длительностей таймера.
Оценивать загрузку по длительности таймерных интервалов - в принципе неправильный способ. И вроде очевидно почему. С ростом частот переключений задач и всяческих событий в РТОС, этот "способ" будет врать всё больше и больше. И чем слабее CPU - тем сильнее врать.
Попереключаться между задачами РТОС с частотами порядка десятков кГц - и будет значительная ошибка.
В том время как измерение загрузки по счётчику выполнения какой-то инструкции - всегда будет выдавать правильный результат. С точностью до 1 цикла прохода инструкции.

[uquote="Аlex",url="/forum/viewtopic.php?p=4690018#p4690018"]Только стартовый подсчёт эталона необходимо производить до запуска всех рабочих тасков. Подсчитали, затем запускаем все остальные таски.[/uquote]Я его делаю вообще до старта ОС. И при всех выключенных прерываниях (кроме одного таймерного).

Добавлено after 7 minutes 34 seconds:
[uquote="Аlex",url="/forum/viewtopic.php?p=4690018#p4690018"]И второй момент. Вначале для измерения используется таймер, а в Idle таске - Tick Counter (счётчик системных тиков ОСьки). Что-то не клеется [/uquote]Не знаю, что возвращает xTaskGetTickCount(), но если она возвращает значение SysTick выравненное по правому краю, то и вся математика у ARV неверная. Так как SysTick - 24-битный. А значит будут проблемы в коде при переходе счётчика через 0.
Это кроме того, что и счётчики разные.

[Sergi]

ARV, по сбросу питания своего мк смотрите RM0376 стр 149 - 151

[ARV]

У меня есть цикл, условно, 100000 инкрементов переменной.
Я измерил его длительность до старта ОС, т.е. в режиме нулевой загрузки ОС.
Теперь я этот цикл запускаю в Idle, и он, естественно будет поерван любым другим процессом. То есть время его прогона будет тем больше, чем сильнее нагружена ОС.
Что здесь не так? Если Idle никогда не получит управление, это сделает время завершения цикла бесконечным - 100% загрузки. Не понимаю, почему я не правильно сделал...
И, даже если я сделал не правильно, почему после перепрошивки результат отрицательный?!

Добавлено after 5 minutes 4 seconds:
[uquote="Аlex",url="/forum/viewtopic.php?p=4690018#p4690018"]

__HAL_TIM_GET_COUNTER(&htim22) = 0;

Это как ?[/uquote]это не функция, а макрос, который по сути является синонимом регистра счетчика этого таймера, так что можно значение и получать, и присваивать

Добавлено after 1 minute 34 seconds:
[uquote="Sergi",url="/forum/viewtopic.php?p=4690104#p4690104"]ARV, по сбросу питания своего мк смотрите RM0376 стр 149 - 151[/uquote]
По сбросу питания проблем нет, все работает верно, проблема именно после перепрошивки

[jcxz]

[uquote="ARV",url="/forum/viewtopic.php?p=4690109#p4690109"]У меня есть цикл, условно, 100000 инкрементов переменной.
Я измерил его длительность до старта ОС, т.е. в режиме нулевой загрузки ОС.
Теперь я этот цикл запускаю в Idle, и он, естественно будет поерван любым другим процессом. То есть время его прогона будет тем больше, чем сильнее нагружена ОС.
Что здесь не так?[/uquote]Длительность измерения непостоянна. Чем выше нагрузка - тем дольше измерение. Длительность измерения всегда будет плавать. Причём - в очень большом диапазоне.

[uquote="ARV",url="/forum/viewtopic.php?p=4690109#p4690109"]Если Idle никогда не получит управление, это сделает время завершения цикла бесконечным - 100% загрузки.[/uquote]И никогда об этом не узнаете. Что загрузка близка к 100%. А при 99% загрузке частота получения данных упадёт в 100 раз. Ваш метод более-менее нормально работает только при малой загрузке CPU. А на практике важнее знать загрузку при высокой нагрузке. Чтобы узнать - сколько осталось ресурса.

Опять-же - как усреднять если неизвестна временнАя база? (если нужно получить более плавно меняющиеся данные для индикации) Если не усреднять - при малой загрузке индикатор будет постоянно дёргаться, и будет малополезно для пользователя. А если усреднять - будет очень долго обновляться с ростом загрузки CPU.

[ARV]

Длительность измерения непостоянна. Чем выше нагрузка - тем дольше измерение.

так на этом же и основан принцип замера?! чем дольше цикл, тем выше нагрузка, разве нет?

А при 99% загрузке частота получения данных упадёт в 100 раз.

так уже при загрузке 80% надо бить тревогу - то ли код оптимизировать, то ли МК брать мощнее. это ведь параметр, нужный для, так сказать, сервиса

[jcxz]

[uquote="ARV",url="/forum/viewtopic.php?p=4690254#p4690254"]так на этом же и основан принцип замера?! чем дольше цикл, тем выше нагрузка, разве нет?[/uquote]Это у вас. В этом его существенный недостаток. Как писал выше...

[uquote="ARV",url="/forum/viewtopic.php?p=4690254#p4690254"]так уже при загрузке 80% надо бить тревогу - то ли код оптимизировать, то ли МК брать мощнее.[/uquote]Почему? Код бывает разный - бывает реалтайм-код. Там важно чтобы всё успевало, за заданное время. Там надо чтобы загрузка была не более чем сколько то %%.
Но есть множество не реал-тайм кода. Для которого не нужно чтобы он выполнялся за определённое время. Для него нужно просто минимальное время выполнения. Такой код будет грузить CPU на 100% всегда. Например: пришёл вам HTTP-запрос, вам нужно сформировать HTTP-ответ на него. Вам не нужно формировать ответ прям вот чётко за заданное время - за N мсек. Нужно его сформировать просто за минимальное время. С низким приоритетом. Вот на время формирования этого ответа загрузка CPU будет =100%. Это нормально. И при возникновении любой подобной низкоприоритетной задачи, загрузка CPU будет =100% на время её выполнения.

Вот у меня проект - работает HTTPS-клиент. Который получает поток шифрованных данных с HTTPS-сервера и на лету его дешифрует. И на графике загрузки CPU я наблюдаю резкие скачки загрузки CPU. Так как данные сервер отдаёт большими блоками - по несколько КБ. Блок данных; его дешифровка на МК; затем на несколько мс - тишина; и далее - по кругу. Загрузка CPU меняется резко - от 100% до буквально 10% или меньше.

PS: Ваш способ измерения загрузки CPU и в таком случае (в случае резко меняющейся нагрузки; когда иногда выполняются кратковременные низкоприоритетные тяжёлые обработки) - тоже будет работать совершенно никудышно. Вы никогда не увидите этих пиков загрузки. Будете получать какое-то "среднее по больнице". Ни о чём не говорящее. Да ещё и с плавающей частотой результатов.

Вобщем - совершенно никудышный способ. Подходит только разве, что если загрузка CPU не очень высокая всегда и примерно равномерная. Но зачем такое делать, если элементарно можно сделать по-нормальному? "Измерение загрузки CPU под РТОС на Cortex-M" - это вещь такая универсальная, реализовав которую один раз, в одном проекте, потом можно просто копировать её из проекта в проект, почти без изменений. Реализация этой функции не должна зависеть от алгоритма работы очередного проекта. Если конечно реализована она правильно.

Добавлено after 1 hour 10 minutes 23 seconds:
[uquote="ARV",url="/forum/viewtopic.php?p=4690109#p4690109"]У меня есть цикл, условно, 100000 инкрементов переменной.
Я измерил его длительность до старта ОС, т.е. в режиме нулевой загрузки ОС.
Теперь я этот цикл запускаю в Idle, и он, естественно будет поерван любым другим процессом. То есть время его прогона будет тем больше, чем сильнее нагружена ОС.
Что здесь не так? Если Idle никогда не получит управление, это сделает время завершения цикла бесконечным - 100% загрузки. Не понимаю, почему я не правильно сделал...
И, даже если я сделал не правильно, почему после перепрошивки результат отрицательный?![/uquote]И как вы предлагаете угадывать "почему" если даже своего кода полностью не привели?
Например - что такое load_check()? Где её код? Предлагаете угадывать??

Вангую, что она написана неправильно. И из-за этого возможны глюки.

[ARV]

Например - что такое load_check()? Где её код? Предлагаете угадывать??

Вангую, что она написана неправильно. И из-за этого возможны глюки.

Код: Выделить всё

void load_check(void){
	volatile uint32_t tmp;
	for(tmp=0; tmp < 2000000; tmp++);
}

И при возникновении любой подобной низкоприоритетной задачи, загрузка CPU будет =100% на время её выполнения.

в общем, вы намекаете, что пока Idle прерывается более приоритетными задачами, мой подход будет измерять, но как только приоритетная задача возникнет на достаточно длительное время, Idle вызываться вообще не будет, и, соответственно, просто не будет вести замеры?

похоже, начинает доходить...

Добавлено after 2 minutes 32 seconds:
тогда еще раз прошу объяснить правильный метод измерения загрузки CPU. прошлые ваши объяснения. как это теперь очевидно, до меня не дошли

Добавлено after 1 minute 28 seconds:
В FreeRTOS есть встроенные средства измерения времени каждой задачи, но по-моему это довольно сильно расходует память, которой и так не много, поэтому я от этого способа сразу отказался

[jcxz]

[uquote="ARV",url="/forum/viewtopic.php?p=4690298#p4690298"]

Код: Выделить всё

void load_check(void){
	volatile uint32_t tmp;
	for(tmp=0; tmp < 2000000; tmp++);
}

[/uquote]ну вот, как я и предполагал - функция написана неверно.
Такая функция как раз и может приводить к отрицательным результатам загрузки. Я же не случайно вам на electronix-е приводил код измеряющей функции написанный на ассемблере. На си её писать нельзя. Подумайте - почему.

[uquote="ARV",url="/forum/viewtopic.php?p=4690298#p4690298"]в общем, вы намекаете, что пока Idle прерывается более приоритетными задачами, мой подход будет измерять, но как только приоритетная задача возникнет на достаточно длительное время, Idle вызываться вообще не будет, и, соответственно, просто не будет вести замеры?[/uquote]Примерно так. В случаях, когда загрузка CPU меняется резко, в больших пределах (в моей практике так почти всегда), ваш способ будет работать или плохо или вообще не будет.

Добавлено after 7 minutes 32 seconds:
[uquote="ARV",url="/forum/viewtopic.php?p=4690298#p4690298"]тогда еще раз прошу объяснить правильный метод измерения загрузки CPU.[/uquote]Общий смысл алгоритма: Есть некий фиксированный код, имеющий постоянное время выполнения цикла, который просто непрерывно выполняет простой цикл, инкрементируя непрерывно счётчик проходов цикла. Этот код - самый низкоприоритетный в системе (Idle-задача). А другой код (высокоприоритетный, лучше - ISR) - делает срезы состояний этого счётчика проходов цикла. Разница между двумя срезами показывает величину загрузки CPU. Интервалы между срезами должны быть фиксированными. Это квант времени измерения загрузки CPU. Эталонный квант измеряется на полностью незагруженной системе (даже все лишние ISR должны быть выключены, и частота таймера срезов - минимальна; лучше сделать её на это время равной частоте квантов измерения загрузки CPU).
Если CPU будет загружен на 100%, то тот цикл выполняться не будет, а значит разницы между срезами будут =0.

[ARV]

Подумайте - почему

даже предположить причину не могу.
более того: не могу предположить связь между гарантированно отрицательным результатом замеров после обновления прошивки и гарантированным отсутствием отрицательного результата при обычном рестарте/запуске/включении питания.

Добавлено after 6 minutes 53 seconds:

Если CPU будет загружен на 100%, то тот цикл выполняться не будет, а значит разницы между срезами будут =0

но я об этом никогда не узнаю, т.к. для вывода этого значения я использую не самый высокоприоритетный процесс, а значит, к тому моменту, когда я смогу выводить результат, нагрузка CPU уже не будет 100%.
а если выводить в высокоприоритетном, то вообще всё поломается - второстепенная задача будет жрать ресурс, не давая работать важным.

[jcxz]

[uquote="ARV",url="/forum/viewtopic.php?p=4690319#p4690319"]даже предположить причину не могу.[/uquote]Потому как не обязательно, что в случае двух вызовов этой функции будет выполняться один и тот же код. Компиляторы умеют оптимизировать, в том числе - инлайнить код. Если например в точке измерения эталона код окажется более медленным, чем в точке уже рабочих измерений, то значения как раз будут иногда случаться отрицательными.
Для вычисления загрузки CPU, измерительная линейка должна быть одинаковой: или в обоих случаях мерить в сантиметрах или в обоих случаях - в дюймах. Вы же меряете двумя разными линейками, а потом пытаетесь делить сантиметры на дюймы. Образно говоря.

[uquote="ARV",url="/forum/viewtopic.php?p=4690319#p4690319"]но я об этом никогда не узнаю, т.к. для вывода этого значения я использую не самый высокоприоритетный процесс, а значит, к тому моменту, когда я смогу выводить результат, нагрузка CPU уже не будет 100%.[/uquote]Сегодня список задач - один, завтра - другой. Добавите например низкоприоритетную задачу. С приоритетом ниже приоритета вывода, и всё сломается.

[Аlex]

ARV, пройдёт некоторое время, и ты поймёшь, что это всё была пустая трата времени.
Задача не имеет практического смысла. CPU всегда загружен на 100% (за исключением sleep-режима). По этому, все эти замеры абсолютно ничего не показывают и не доказывают.
Нужно просто уметь правильно распределять ресурсы CPU при планировании алгоритма в целом. И тогда мыслей о измерении количества вхождений в idle-task никогда не возникнут.

[ARV]

ну да, пока CPU не в SLEEP-режиме, он на 100% загружен
но цель этих измерений не собственно загрузку CPU определить, а загрузку FreeRTOS, потому как от этой загрузки отзывчивость может меняться заметно.
я ж многозадачную систему строю...

Добавлено after 2 minutes 16 seconds:

Если например в точке измерения эталона код окажется более медленным, чем в точке уже рабочих измерений, то значения как раз будут иногда случаться отрицательными.

ну Ок, согласен. но тогда код, выполняемый после обновления прошивки и код, выполняемый после сброса ранее обновленной прошивки, по-вашему, получается разным? ведь отрицательные значения исчезают после нажатия на кнопку сброса

Добавлено after 8 minutes 48 seconds:
и все-таки "правильный" метод определения загрузки как-то меня угнетает... Я FreeRTOS намеренно применяю, чтобы как можно дальше от прерываний уйти... чтобы код выглядел линейным, но несколькими параллельными линиями а теперь надо снова вопреки РТОС уходить "вниз"... как-то не хорошо это.

если до старта планировщика я еще это могу как-то принять, то после... не хорошо. не прилично как-то. если назначить задаче измерения загрузки, т.е. задаче, делающей срезы счетчика, назначить наивысший приоритет - это ведь почти то же самое, что и по прерыванию будет?

[jcxz]

[uquote="Аlex",url="/forum/viewtopic.php?p=4690360#p4690360"]ARV, пройдёт некоторое время, и ты поймёшь, что это всё была пустая трата времени.
Задача не имеет практического смысла. CPU всегда загружен на 100%[/uquote]Не согласен. Очень нужная вещь! Позволяет планировать ресурсы - сколько осталось ресурса, нужно ли оптимизировать и на сколько? Так -же - сразу показывает эффект от оптимизации алгоритма - на сколько %% удалось улучшить. Если следовать вашей логике - и оптимизация вообще не нужна и смотреть сколько свободной памяти осталось - тоже не нужно.
СPU не "загружен всегда на 100%". Загружен он только то время, которое не находится в Idle-задаче.

Добавлено after 5 minutes 29 seconds:
[uquote="Аlex",url="/forum/viewtopic.php?p=4690360#p4690360"]Нужно просто уметь правильно распределять ресурсы CPU при планировании алгоритма в целом.[/uquote]И как же их распределять если их не измерять?

Добавлено after 12 minutes 5 seconds:
[uquote="ARV",url="/forum/viewtopic.php?p=4690388#p4690388"]ну Ок, согласен. но тогда код, выполняемый после обновления прошивки и код, выполняемый после сброса ранее обновленной прошивки, по-вашему, получается разным? ведь отрицательные значения исчезают после нажатия на кнопку сброса [/uquote]Я не знаю что у вас там происходит. Узнавать это вы должны сами. При помощи отладчика и анализа кода.
Что мешает вам например сравнить аргументы операции деления до прошивки и после? Вместо того, чтобы строчить об этом на форум уже которое сообщение.
По опыту - если в коде имеется несколько багов, то часто их комбинированное воздействие даёт совершенно неожиданный суммарный эффект.

[uquote="ARV",url="/forum/viewtopic.php?p=4690388#p4690388"]Я FreeRTOS намеренно применяю, чтобы как можно дальше от прерываний уйти[/uquote]Тогда надо вообще от программирования контроллеров уходить. На программирование ПК или страничек в инете.

[uquote="ARV",url="/forum/viewtopic.php?p=4690388#p4690388"]т.е. задаче, делающей срезы счетчика, назначить наивысший приоритет - это ведь почти то же самое, что и по прерыванию будет?[/uquote]Можно конечно, но зачем??? Это будет из пушки по воробьям. Задача - это вещь на порядок тяжелее, чем прерывание. Ей хотя-бы свой стек нужен. И из-за такой ерунды - такие траты??? Да ещё на вашем дохлом МК... лучше ресурсы потратить на полезное дело.

[Аlex]

Если следовать вашей логике - и оптимизация вообще не нужна и смотреть сколько свободной памяти осталось - тоже не нужно.

Не проецируйте свои домыслы на мою логику. "Не следить за временем нахождения CPU в Idle задаче" и "Не следить за тем, какой код ты пишешь и сколько он занимает" - две разные вещи.

И как же их распределять если их не измерять?

Мозгом. И только им ...

[jcxz]

[uquote="Аlex",url="/forum/viewtopic.php?p=4690414#p4690414"]"Не следить за временем нахождения CPU в Idle задаче" и "Не следить за тем, какой код ты пишешь и сколько он занимает" - две разные вещи.[/uquote]И как же, только глядя на код, определить - сколько он занимает тактов?
Видимо у вас в мозгу имеется компилятор. Который умеет быстро скомпилить пару сотен КБ кода. У меня, к сожалению, такого нет.

[Аlex]

ARV, если хочется только с Idle-потоком поиграться, без ISR и приоритетных потоков, то вот такое будет работать. Но, только если CPU будет загружено не на полную (в Idle хоть что-то будет попадать) :

Спойлер

Код: Выделить всё

int     cpuPerc = 0;

void IdleTask(void const* argument) {
static int      idleCounter;
static uint32_t ts1Sec = 0;

ts1Sec = xTaskGetTickCount();

while (1) {
    //--------------------------
    osDelay(1);
    //--------------------------
    idleCounter++;

    //--------------------------
    if ((xTaskGetTickCount() - ts1Sec) > 1000) {
        ts1Sec = xTaskGetTickCount();
        cpuPerc = ((1000 - idleCounter) * 100) / 1000;
        idleCounter = 0;
    }
    //--------------------------

}
}

Комменты к коду, думаю, не нужны.

Спойлер

2025-03-06_22-04-29.png

(142.27 КБ) 257 скачиваний

Спойлер

1.gif

(4.29 МБ) 228 скачиваний

[ARV]

Аlex, спасибо. думаю, меня вполне устроит такой принцип, попробую применить

Добавлено after 6 minutes 4 seconds:
jcxz, вот вопрос на счет журнала EEPROM. вы настоятельно рекомендовали применять хитрое кодирование, забыл, как называется, но у меня вопрос: зачем?! ведь если просто указывать длину записи в её первом байте, можно легко проследить всю цепочку записей, а если эта длина равна 0, значит, больше записей нет. в чем скрытый смысл вашего подхода и какие минусы у моего?

Добавлено after 55 minutes 10 seconds:
и еще вопрос по FreeRTOS, не хватает моих текущих познаний.

вот у меня есть переменная uint32_t ABC, которая в одном потоке может быть изменена, а в другом используется в расчетах. вопрос в обеспечении атомарного доступа к ней, и состоит из нескольких подвопросов:

1. FreeRTOS контекст задач переключает только по блокирующим функциям типа osDelay и т.п. xSemaphoreTake, или в любой момент по таймеру?
2. нужно ли эту переменную описывать volatile?
3. для атомарного доступа есть какие-то готовые решения, или тупо использовать пару taskENTER_CRITICAL()/taskEXIT_CRITICAL()?
4. если я "забуфферизирую" эту переменную в потоке, где использую, примерно так uint32_t tmp = __ATOMIC_READ(ABC); - компилятор ничего не учудит с оптимизацией tmp? в том плане, что посчитает меня тупее валенка и вместо tmp продолжит использовать ABC?
5. если ответ на предыдущий вопрос "компилятор может учудить", как его заставить этого не делать?
6. или, поскольку ARM 32-битный, чтение любой переменной этого размера всегда атомарное, и достаточно просто забуфферизировать переменную?
7. если ответ на предыдущий вопрос "да", то относится ли это к переменным uint8_t и uint16_t?
8. я тупой, и вообще не в том направлении думаю?

Добавлено after 12 minutes 1 second:
вопрос 1 снимается - уже выяснил.

[GARMIN]

[uquote="ARV",url="/forum/viewtopic.php?p=4690590#p4690590"]Аlex
вот у меня есть переменная uint32_t ABC, которая в одном потоке может быть изменена, а в другом используется в расчетах. вопрос в обеспечении атомарного доступа к ней, и состоит из нескольких подвопросов:

1. FreeRTOS контекст задач переключает только по блокирующим функциям типа osDelay и т.п. xSemaphoreTake, или в любой момент по таймеру?
2. нужно ли эту переменную описывать volatile?
3. для атомарного доступа есть какие-то готовые решения, или тупо использовать пару taskENTER_CRITICAL()/taskEXIT_CRITICAL()?
4. если я "забуфферизирую" эту переменную в потоке, где использую, примерно так uint32_t tmp = __ATOMIC_READ(ABC); - компилятор ничего не учудит с оптимизацией tmp? в том плане, что посчитает меня тупее валенка и вместо tmp продолжит использовать ABC?
5. если ответ на предыдущий вопрос "компилятор может учудить", как его заставить этого не делать?
6. или, поскольку ARM 32-битный, чтение любой переменной этого размера всегда атомарное, и достаточно просто забуфферизировать переменную?
7. если ответ на предыдущий вопрос "да", то относится ли это к переменным uint8_t и uint16_t?
8. я тупой, и вообще не в том направлении думаю?

[/uquote]
1) Переключение контекста и по блокирующим функциям, и по системному таймеру.
2) нет, она используется в нескольких функциях.
3) критические секции и есть готовые решения, но не в этом случае, ибо:
4) 32-битный процессор читает любую переменную 8-32 бита за один такт.
Определите глобальную структуру данных со своими переменными и используйте их во всех ваших файлах