Имеются такие данные?

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

На известной частоте ядра и в одном из режимов.

520 тактов проца от set_event до wait_event (управление передется сразу, ожидающая задача приоритетней) . Но это зависит от кол-ва задач, ждущих этого event. Порядок 500 - это если одна ждет. Если две - порядка 700 тактов

Хы, пробовал буквально утром - новый диспетчер 2.4 прогонял (и украл оттуда хинт - sub LR,LR,#4 - в самом начале )

Для:
- AT91SAM7X
- 48MHz core
- ARM mode
- flash execution, 1 wait clock
- cистемы компилировались с флагом USE_MUTEX=0 (влияет незначительно)
- IAR 4.30, оптимизация по размеру -z9

Дает длительность импульса на TEST_PIN:
13.2 uS - TNKernel v2.3
13.0 uS - TNKernel v2.4
11.2 uS - TNKernel v2.3 с полностью модифицированным диспетчером + оптимизирующие мелочи в синхрообъектах
Если не будет лень - попробую еще uC/OS для сравнения.

ну теже самый числа - это радует. У меня LPC48, время по таймеру0 засек, осцилла цифрового дома нет. Компилер RVDS ARM -o3 speed

Спасибо за исчерпывающий ответ.
В Thumb mode будет чуть дольше, если не ошибаюсь.


Было бы интересно, думаю цифра будет близкой.

Аппаратура - та же самая, компилятор тоже, софт:
- uC/OS v2.80
- официальный порт под ARM
Итого:
13.5 uS - разрешена проверка аргументов, hooks и статистика
13.0 uS - нет проверки аргументов, выключены hooks и статистика

На самом деле время переключения контекста вопрос далеко не праздный.
У меня пара проектов с USB требуют как можно большей потоковой производительности
+ вычисления в фоне. Сейчас вариант с обработкой протокола USB в прерываниях
справляется с небольшим запасом - теперь главное, чтобы при переходе под OS этот запас
не сожрался. Более быстрый проц, плиз, не предлагать - цена очень критична.

Мне тут в привате еще scmRTOS и FreeRTOS посоветовали. Может быть кто-нибудь из форумчан прогонит приведенный выше тест на своем SAM7 в указаных OS? Было бы очень любопытно. У меня в итоге после оптимизации TNKernel получилось 8.5uS без проверок параметров, и 11.0 uS со всеми проверками.

На FreeRTOS можете и не cмотреть - не для соревнований в скорости переключения создавалась
А scmRTOS думаю (совершенно субъективно ) где-то 7us будет.

Я вот только что дополнительно заинлайнил запрещение/разрешение прерываний при помощи intrinsic функций (по размеру даже меньше получилось - очень приличный код IAR 4.30 сгенерировал, ассемблеру 5-10% уступает, не больше) и в итоге получил - 7.3 uS
У меня сложилось впечатление, что любая инструкция перехода для SAM7 при исполнении из флеша порождает просто немерянные тормоза - перезагрузка конвеера просто множится на ожидание флеша.
А совершенно объективно по scmRTOS кто-то может сказать - тест-то на 15 минут?

Сергей Борщ, например, - он ее под ARM портировал.

Вот именно...

1 - Есть инфа на сайте, на самой первой странице.
2 - Та же инфа в форуме, в обсуждении первых вариантов порта scmRTOS под АРМ.

Какие основания не доверять этим значениям?

3 - в комплекте scmRTOS для SAM совершенно рабочий пример 1-EventFlag, вставить вывод и запустить не должно составить труда.

Не знаю, не знаю - для меня запуск scm оказался самым трудоемким из uC/OS и TNKernel.
scm тут совершенно не при чем, просто у меня стиль работы оказался с ним трудно совместим .
Хроника событий:
- C++ я никогда в embedded не использовал, в существующую программную платформу scm-ные файлы быстро прицепить не удалось (на uC/OS и TNK было потрачено примерно по полдня на разборку и прикручивание). Ладно забиваем на все наработки, в комплекте с scm идут примеры - прекрасно, стартуем с них.
- выясняем что примеры идут исключительно под IAR IDE. "Ну нет у меня гармошки" - процессоры меняются относительно часто (через месяц светит проект на PowerPC e300, во втором полугодии - MIPS-IV), если я буду изучать всякие IDE - крыша уедет окончательно. Поэтому nmake/gmake - это наш выбор .
- ставим (с кривой ухмылкой ) IDE, лечимся, решаем конфликты в path
- запускаем IDE, билдаем
- к чести авторов scm - билдается беспроблемно. Дайте две
- берем старую плату с SAM7S64
- пытаемся прошить (у меня свой программатор/отладчик - byteblaster называется - шьет/отлаживает через ICE), превед - формат файла не тот
- читаем хелп на предмет опций
- билдаем
- не работает, превед - конфигурация SRAM (а откуда я знаю что это и где это)
- билдаем FLASH
- шьем, превед - в intelhex файле запись с левым типом 05 (пока не выяснил, что это, уточню)
- имеем некоторы безопасный хекс с файлом - патчим его руками, шьем
- превед, на моих платах штатный кварц 12.0
- патчим low_level_init (наконец-то я узнал кто это такой )
- запустились наконец

Что показал осциллограф? Ага, там вам все сразу и расскажи.

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

А осциллограф, ну что осциллограф - 6.5uS. Ну я взял бубен и немного побегал вокруг. Типа - это лучший результат из опробованных осей. Потом бубен выбросил и стал рыдать над исходниками. Ну где, где !!!? Да как так получается !!!? А-а-а, вот они - последствия IDE-разврата - надо галочку ARM в свойствах проекта поставить, interwork пока нахрен снимаем. Билдаем - 4.5uS. ПРЕВЕД? Как бы не так - кто регистр MC_FMR прописывать для 48МГц будет? Потирая руки пишем туда единичку, и... получаем "законные" 6.9uS.

Возможно, я где-то еще накосячил, но пока, хит-парад "по чистой скорости":
1. scmRTOS - 6.9uS
2. TNKernel - 7.2-13uS
3. uC/OS 2.80 - 13-13.5uS

И не забываем, что TNKernel имеет дополнительный round-robin scheduler и благодаря этому возможна реализация протоколов коррекции приоритетов при использовании мутексов.

Гы. Отныне появилось третье измерение по мемерению пиписьками в эмбеддед :-D
Кстати где поглядеть толковое описание сути проблемы с мутексами ? Я так понимаю речь об инверсии приоритетов? Что-то никак не могу догнать, как бы такую засаду себе устроить

Далось же вам это время переключения контекста !
Да любая серьезная коммерческая RTOS (VxWorks, pSOS,Nucleus,ThreadX)
имеет время переключения контекста значительно больше чем scmRTOS,
TNKernel, uCOS -II из-за многочисленных самопроверок,повышенной функциональности(те
увеличенному размеру контекста) и т.п.

Высокая скорость переключения контекста в этих 3х маленьких кернелах - это высокая скорость мотоцикла, с которого сняли глушитель и седло для пассажира...

ИМХО, в тех ембеддед системах, где эти кернелы применимы, нет ни пассажира ни водителя, а есть только сам мотоцикл . Можно убрать все несущественные проверки под ключ компиляции (в uCOS это частично сделано) и при желании, перед финалом глушитель и седло выбрасывать . Обычно это получается не в ущерб надежности.