[VslavX 0]

Еще немного поковырял TNKernel, итого:

- 6.0uS без поддержки THUMB и только режим SUPERVISOR

- 6.2uS c поддержкой THUMB и только режим SUPERVISOR

- 6.4uS c поддержкой THUMB и любые режимы кроме USER/IRQ

Можно было бы еще ускорить, но переносить функции на asm или инлайнить относительно большие системообразующие процедуры (вызываются более чем в двух десятках мест) - "клиника", ИМХО. Завязываю :)

[zltigo 2]

Завязываю :)

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

Еще немного поковырял TNKernel, итого:

- 6.0uS без поддержки THUMB и только режим SUPERVISOR

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

[AlexandrY 3]

В коммерческих осях, вообще проблему скорости реакции на внутренние события решают иначе.

Есть, например, механизм - High-Level Interrupt Service Routine (HISR)

Эти HISR имеют свой контекст и могут использовать сервисы RTOS, но вызов их быстрее чем вызов задачи через семафоры.

 

 

Далось же вам это время переключения контекста :) !

Да любая серьезная коммерческая RTOS (VxWorks, pSOS,Nucleus,ThreadX)

имеет время переключения контекста значительно больше чем scmRTOS,

TNKernel, uCOS -II из-за многочисленных самопроверок,повышенной функциональности(те

увеличенному размеру контекста) и т.п.

 

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

[Сергей Борщ 143]

Хроника событий:

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

 

кто регистр MC_FMR прописывать для 48МГц будет?

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

[VslavX 0]

Еще немного поковырял TNKernel, итого:

- 6.0uS без поддержки THUMB и только режим SUPERVISOR

- 6.2uS c поддержкой THUMB и только режим SUPERVISOR

- 6.4uS c поддержкой THUMB и любые режимы кроме USER/IRQ

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

Interrupt latency тоже интересный - до точки входа в C-процедуру - 370 nS.

[dxp 67]

Для справки - сделал порт TNKernel на PowerPC - MPC834x - получил 1.45uS при 400МГц. Но контекст PPC больше ARM-овского раза в 3 даже без плавающей точки.

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

[VslavX 0]

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

Чистый контекст 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 вытесняемой задачи.

[dxp 67]

Чистый контекст CPU в стеке:

Для ARM - 64 байта или 16 слов: R0-R13, PC(R15), LR(R14), CPRS

Для PPC - 148 байт или 37 слов: GPR0, GPR2-GPR31, LR, PC, MSR, CR, XER, CTR - 148 байт

Если добавить плавающую точку для PPC - то 32*double + FPSCR - еще +65 слов

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

[VslavX 0]

А PPC может за такт слово в память сложить/взять из памяти? Что-то скорость не очень высокая для

Теоретически 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. Разницу я списал на рефреш.

 

400 МГц, имхо. Вот у Blackfin'а контекст порядка 180 байт, а переключается он за 1.5 мкс при 200 МГц.

Правда, тут мы, видимо, сравниваем не чисто переключение контекста, а целиком передачу

Именно. Тестовый фрагмент есть в этой ветке выше.

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

[VslavX 0]

"- Василий Иванович, а Ваша майка чернее моей"

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

 

Это я к тому, что за счет 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. Жить можно :) и даже неплохо :).

[VslavX 0]

Майка становилась все чернее и чернее :)

Написан порт 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.

[Alex B._ 0]

Написан порт TNKernel на Cortex-M3.

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

[VslavX 0]

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

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

 

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

[prgjz 0]

Использую TNKernel на LPC2387 - всё прекрасно работает,

но теперь перехожу на LPC1768 где операционной памяти 32KB меньше.

Внастоящее время пытаюсь найти возможности её расход уменьшить.

 

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

или советом по оптимизации расхода памяти?

[VslavX 0]

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

или советом по оптимизации расхода памяти?

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

INLINE_FORCED
DWORD 
tn_disable_interrupt(void)
{
    DWORD   rc = __get_PRIMASK();
    __disable_interrupt();
    return rc;
}
#define tn_enable_interrupt(sr)  __set_PRIMASK(sr)

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

 

Далее:

#define CONTAINING_RECORD(address, type, field)     ((type *)( (PBYTE)(address) - (PBYTE)(&((type *)0)->field)))

#define get_task_by_tsk_queue(que)      CONTAINING_RECORD(que, TN_TCB, task_queue)
#define get_task_by_timer_queque(que)   CONTAINING_RECORD(que, TN_TCB, timer_queue)
#define get_mutex_by_mutex_queque(que)  CONTAINING_RECORD(que, TN_MUTEX, mutex_queue)
#define get_mutex_by_wait_queque(que)   CONTAINING_RECORD(que, TN_MUTEX, wait_queue)

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

 

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