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

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

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

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 это частично сделано) и при желании, перед финалом глушитель и седло выбрасывать . Обычно это получается не в ущерб надежности.

Еще немного поковырял TNKernel, итого:
- 6.0uS без поддержки THUMB и только режим SUPERVISOR
- 6.2uS c поддержкой THUMB и только режим SUPERVISOR
- 6.4uS c поддержкой THUMB и любые режимы кроме USER/IRQ
Можно было бы еще ускорить, но переносить функции на asm или инлайнить относительно большие системообразующие процедуры (вызываются более чем в двух десятках мест) - "клиника", ИМХО. Завязываю

Отлично! "больной" оклемался за неделю, это нормальное течение "болезни"

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

В коммерческих осях, вообще проблему скорости реакции на внутренние события решают иначе.
Есть, например, механизм - High-Level Interrupt Service Routine (HISR)
Эти HISR имеют свой контекст и могут использовать сервисы RTOS, но вызов их быстрее чем вызов задачи через семафоры.

"Если ничего не помогает - прочтите, наконец, инструкцию" . В корне архива лежит файл release_notes.arm7_at91sam7.html. В конце этого файла в разделе Building даны все ключи компилятора, ассемблера и линкера для сборки примера средствами, отличными от IAR IDE. Увы, я не пользуюсь make и другими средами, поэтому не могу подготовить и адекватно проверить Makefile. Если вам это удалось и есть желание - мы с удовольствием включим ваш Makefile в официальный порт.

А вот за это спасибо. Упустил из виду. Поправлю.

Для справки - сделал порт TNKernel на PowerPC - MPC834x - получил 1.45uS при 400МГц. Но контекст PPC больше ARM-овского раза в 3 даже без плавающей точки. С плавающей точкой - каюк - четверть килобайта лопатить надо, вероятно сделаю смену "плавающего контекста" по исключениям.
Interrupt latency тоже интересный - до точки входа в C-процедуру - 370 nS.

А сколько он в байтах, этот конекст? Ну, примерно.

Чистый контекст CPU в стеке:
Для ARM - 64 байта или 16 слов: R0-R12, PC(R15), LR(R14), CPRS
Для PPC - 148 байт или 37 слов: GPR0, GPR2-GPR31, LR, PC, MSR, CR, XER, CTR - 148 байт
Если добавить плавающую точку для PPC - то 32*double + FPSCR - еще +65 слов

Исправил опечатку: для ARM R0-R12 (было R0-R13). SP(R13) в стеке не сохраняется - он заносится в TCB вытесняемой задачи.

А PPC может за такт слово в память сложить/взять из памяти? Что-то скорость не очень высокая для 400 МГц, имхо. Вот у Blackfin'а контекст порядка 180 байт, а переключается он за 1.5 мкс при 200 МГц. Правда, тут мы, видимо, сравниваем не чисто переключение контекста, а целиком передачу управления, т.к. там еще планировщик добавляет. Но он по сравнению с такими контекстами, имхо, не должен доминировать по времезатратам.

Теоретически 2 слова - внутри кристалла 64-битная шина на 266МГц, снаружи тоже 64-битная DDR, тоже на 266МГц. Но - "съест-то он съест, да кто ж ему даст". Есть инструкции множественного сохранения/чтения регистров в/из памяти. Но они работают медленнее, чем просто набор порегистровых сохранений/восстановлений (проверял сам, и в документации есть упоминание об этом факте).

Реально измеренные ПСП (после всех настроек):
DDR read speed test (128M) : 394 MBps
DDR write speed test (64M) : 349 MBps (включен конвеер шины - типа буфер отложенной записи)
Cache read speed test (4K) : 2240 MBps (732 такта процессора)

Скорость чтения из кэша показывает 5.5 байт на процессорный такт, так что, похоже, ядро e300
действительно суперскалярное. Со скоростью DDR тоже все понятно - длина busrt 4, тайминги стоят неагрессивные - теоретически при 100% загрузке шины DDR у меня получилось 425MBps. Разницу я списал на рефреш.


Именно. Тестовый фрагмент есть в этой ветке выше.
Настройки кэша - Write-Through, возможно это притормаживает запись.

"- Василий Иванович, а Ваша майка чернее моей"
"- Дык, я и постарше тебя буду, Петька" © Народный анекдот

Это я к тому, что за счет MAM, даже при более тормозной флешке, Филипсовская серия LPC все-таки побыстрее Атмеловской SAM, процентов на 30. На числовой молотилке (ЭЦП на Эль-Гамале) приведенная к одинаковым частотам разница 0.71/1.0 в пользу LPC.

Порт TN Kernel тоже на LPC2378 побыстрее зажужал:

- исполнение из внутренней flash
- 72 MHz CPU clock
- MAM mode 2
- MAMTIM 4

Измеренное время переключения контекста составило 3.3uS. Разница между обработкой в самом прерывании и отложенной обработкой в приоритетной задаче и того меньше - ~1.5uS. Жить можно и даже неплохо .

Майка становилась все чернее и чернее
Написан порт TNKernel на Cortex-M3. Надо сказать, что архитектура CM3 оказалась безумно красивой и на нее идеально легла упомянутая ОС - я получил немалое удовольствие при портировании.
В итоге на LPC1768, 100МГц, FlashWS = 4, результаты такие:
- 4.86uS - включены все проверки и assert-ы
- 3.94uS - отключены проверки и assert-ы, оставлен только потоковый профайлер (меряет процессорное время для задачи в тактах ядра)
- 2.87uS - отключены все проверки, assert-ы и профайлер
- 2.83uS - то же самое, но обработчик переключения контекста выравнен на 16 байт (как раз 4 100МГц такта выигралось)
В-общем, LPC17xx вещь очень неплохая, но LPC23xx по скорости не так уж превосходит. Оно бы взлетело - да флеш не дает.

Upd: скомпилировал с оптимизацей по скорости - получил 2.50uS, размер теста стал ~9300 байт вместо ~7900.

Чем ваш порт отличается от того, что лежит на родном сайте?

Три года назад родная версия (2.3 на тот момент) была "доработана напильником" под собственные нужды. При этом она стала работать примерно в два раза быстрее (тут же в топике хроника событий) и несколько утратила совместимость с "официальными" портами.

Оптимизировать в официальной версии можно достаточно много, ну а идеология кортексовского порта та же самая - PendSV на переключение контекста - в самом деле, трудно предложить что-нибудь лучше для C-M3. Ну и частнопортовые оптимизации - запрос на переключение контекста ставится не в каждом прерывании, а именно в тот момент когда нужно переключение контекста - в других же портах приходится явно проверять при выходе из прерывания на предмет переключения. Флажка tn_context_switch_request как такового у меня вообще нет - выкинут еще три года назад при оптимизации, да и сам обработчик PendSV занимает 16 инструкций вместо 22 родного (можно было бы и 15 и минус один ldr=, но IAR 5.xx перестал нормально выражения с внешними символами поддерживать)

Использую TNKernel на LPC2387 - всё прекрасно работает,
но теперь перехожу на LPC1768 где операционной памяти 32KB меньше.
Внастоящее время пытаюсь найти возможности её расход уменьшить.

Поэтому нескромный вопрос к VslavX: не поделитесь ли вашим оптимизированным вариантом
или советом по оптимизации расхода памяти?

А расход памяти в официальном варианте несильно можно пооптимизировать, так, повыкидывать только некоторые статистичеcкие поля в объектах, требования к памяти снизяться очень незначительно. Я оптимизировал произодительность и простоту кода, но, cорри, свой вариант пока в открытый доступ выкладывать не буду, по разным причинам. Особого секрета из своих оптимизаций я не делаю - все исходники автору отсылались. Самое простое и банальное - заинлайнить некоторые функции, примерно так (для Cortex, IAR 5.x):

За счет того что эти функции инлайняться - компилятор не сохраняет перед вызовом РОНы, нет самого вызова/возврата bl/bxlr - в итоге сам код становится короче и быстрее. Эта парочка определений переезжает в tn_port.h и прекрасно адаптируется к разным компиляторам - я пробовал IAR ARM 4.x/5.x, MSVC 6/7/2005, GCC ARM/PPC 3.x/4.x, CW PPC - нормально, эффект есть везде

Далее:

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

Вышеописанное дает основной вклад в оптимизацию - процентов 50-60. Ну а остальные 40-50 - это уже в сами систеные функции лезть надо. Есть и небольшие архитектурные изменения - выкинута таймерная задача - жалко на каждый системный тик дважды переключать контекст, все это переехало в таймерное прерывание, которое допускает вложение других прерываний - чтобы rt не страдал, упрощены протоколы мьютексов - приоритет пересматривается однократно при освобождении объекта, по другому ведется учет объектов - вместо id сделаны честные списки и все это отключаемо по флажку компиляции (реально помогает только на этапе отладки), и прочая неоригинальная мелочь.

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

Update: Новые времена - новые контроллеры - новые времянки.
На STM32F207 @ 120 MHz/3 waitstate - время переключения контекста 1.280 uS
На STM32F407 @ 168 MHz/5 waitstate, ART prefetch ON, no FPU - время переключения контекста 0.904 uS
Таки контроллеры становятся быстрее и быстрее