У кого-нибудь есть соображения по этому поводу?

Ничего не понял в вопросе.

если uOS это uCOS-II то там есть дефайн OS_TASK_STAT_EN который подключает отдельную задачу статистики, где все уже за вас сделано. Почитайте по этому делу хелп

Дополню, что там же имеется дефайн для юкосвью. Статистику можно рассматривать на красивых графиках.
На директорат и мененеджмент действует, как консервная банка на папуасов

uOS это не uOS-II. uOS-это другая ось. www.uos.vak.ru
И там ничего такого нет.

А вопрос вот в чем. Требуется знать загрузку процессора при определенной частоте опроса внешних устройсв и.т.п.. Т.е. "успеет ли?"

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

В оС должна быть IDLE TASK. И должны быть хуки входа и выхода в нее. Так же должен быть доступ к счетчику системных тиков. При входе в IDLE смотрите на счетчик - запоминаете. При выходе из IDLE опять смотрите - запоминаете. Разность - это есть "время" простоя. При следующем входе в IDLE вспоминаете значение системного тика, которое было при выходе в прошлый раз. Разность - время работы. И так суммируете, суммируете времена эти... а загрузка это

1 - t(idle)/(t(idle) + t(work))

Никаких средсв работы с задачей idle тут,как я понимаю, нету. Поэтому немного подругому нужно.
А счетчик тиков есть разумеется.

В принципе такое обычно нужно чтобы одна конкретная задача успевала отработать за счёт других. Обычно она синхронная. То есть привязана ко времени.

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

у меня способ простой:
например оценка времени обработки прерываний:
в начале прерывания свободный вывод в "0", а перед выходом в "1". чуп
осциллографа на этот выход и смотрю

Это нормальный, но оценочный способ. Иногда, когда оптимизируешь программу, не совсем очевидно дадут вносимые изменения положительный или отрицательный эффект и если дадут, то какие. И тут важно зать численное значение. Потому, что результат может быть равен 1-2%, а на глаз это не заметишь.

Осциллографы разные бывают . Приличный и наносекунды измерит, и разброс зафиксирует и кореляцию посчитает...