А как узнать, к примеру, о реентерабельности определённых функций библиотеки ИАРа?
Вроде нашёл среди inc. файлов конфиг. файл DLIB с метками multi-thread...

Наверное, надо спросить в соотв. теме
Вероятно, библиотеки можно как то конфигурировать.

Сорри, я с такими вещами ещё дел не имел, поэтому такие глупые вопросы

Я бы советовал начать с документации. Такие вещи указываются в обязательном порядке.

Спасибо, нашёл, стоило немного под напрячься!
После трудного дня легче спросить на форуме, чем шерстить занудные мануалы :

Most parts of the DLIB library are reentrant, but these functions and parts are not
reentrant because they need static data:
● Heap functions—malloc, free, realloc, calloc, and the C++ operators new
and delete
● Time functions—asctime, localtime, gmtime, mktime
● Multibyte functions—mbrlen, mbrtowc, mbsrtowc, wcrtomb, wcsrtomb,
wctomb
● The miscellaneous functions setlocale, rand, atexit, strerror, strtok
● Functions that use files in some way. This includes printf, scanf, getchar, and
putchar. The functions sprintf and sscanf are not included.
Some functions also share the same storage for errno. These functions are not
reentrant, since an errno value resulting from one of these functions can be destroyed
by a subsequent use of the function before it is read. Among these functions are:
exp, exp10, ldexp, log, log10, pow, sqrt, acos, asin, atan2,
cosh, sinh, strtod, strtol, strtoul

Remedies for this are:
● Do not use non-reentrant functions in interrupt service routines
● Guard calls to a non-reentrant function by a mutex, or a secure region, etc.

В общем, не так уж и много вещей, которых стоит бояться.
sprinf() можно пользоваться свободно, и слава богу

Может, кто подскажет идею, как в этой операционке сделать измерение процента бездействия\занятости процессора?

Жаль, что нет такого встроенного сервиса. Неужели это не просто сделать?

По идее, хук на вход в idle поток есть, если бы был второй хук на выход из этого потока...
Тогда бы вошли - запустили таймер - вышли - засекли время.

А чем лучше обернуть запросы на выделение памяти - memalloc() и компанию?
По идее, эти функции должны выполняться весьма быстро - подходит простая критическая секция.

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

Может, лучше ещё один мьютекс?

Первый раз, пока куча не фрагментирована. Да и от реализации менеджера зависит. А если самый худший случай - память кончилась и вызывается чистильщик?

Мутекс подходит очень хорошо.

Добавлю ссылку на пример: вот.

Понятно - значит, будет мьютекс

А что за чистильщик такой? Составная часть библиотечного malloc(), или что-то своё?
Каков его функционал - дефрагментация выделенных блоков?

Спасибо!

Там по ссылке чуть ниже описано. Система принимает сообщения, складывает в буфер и ретранслирует дальше. Если канал ретрансляции отвалился, то буфер в конце-концов переполнится. В этом случае чистильщик удаляет по одному самые старые сообщения пока не наберется достаточно свободного места для нового.

А для чего вообще в обработчики прерываний с сервисами РТОС добавлять "обёртку" TISRW?
Случайно забыл её добавить в обработчик, использующий SignalISR() - на работоспособности вроде не сказалось...

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

Ну так это надо сомтреть. Похоже, переключение задач, которое "попросило" сделать SignalISR(), происходит не сразу же, а после очередного прерывания системного тика либо другого прериывания, у которого есть TISRW. Т.е. увеличилось время реакции на тот SignalISR(), который не обёрнут в TISRW. Вполне может и не нарушить работоспособность в определ’нной ситуации.

Не может. Там есть Kernel.ISR_NestCount

По первому вопросу всё понял, спасибо!

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

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

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

Ну тут уже зависит от архитектуры.
Как в AVR - так там контекст программно сохраняется и вложенное прерывание не пролезет, пока вручную не разрешить таковые.
Если есть аппаратное сохранение контекста и если оно может быть прервано более приоитетным прерыванием, то да. Но с точки зрения ОС это мало отличается от следующих друг за другомо прерываний - она ещё не получила управления и не знает, что прерывания вложенные. Т.е. к началу работы высокоприоритетного обработчика ОС не знает, что низкоприоритетное вобще начиналось, с её точки зрения это те же "друг за другом".
Можно ли с этим побороться и как именно - тоже надо смотреть конкретную архитектуру.
Кстати, если реальное переключение задач производится специальным прерыванием, то и в описаных случаях хоть планировщик вызовется и несколько раз, а контекст на нужную задачу переключится один раз в конце.

Да, в порте для кортексов-м3 контекст переключается вызовом софтового прерывания - PendSV.
Оно имеет самый низкий приоритет, что гарантирует его обработку в последнюю очередь.

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

Спасибо за пояснения!