[spf 0]

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

 

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

 

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

[DASM 0]

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

[VslavX 0]

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

 

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

 

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

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

#define    TEST_PIN    (1<<21)

void test_task_func4(void *Param)
{
    for(;;)
    {
        PIOA_CODR = TEST_PIN;
        tn_sem_acquire (&setSem, TN_WAIT_INFINITE);
    }
}

void test_task_func3(void *Param)
{
    BOOL Create = TRUE;

    tn_sem_create (&setSem, 1, 1);

    for(;;)
    {
        PIOA_SODR = TEST_PIN;
        tn_sem_signal(&setSem);

        if (Create)
        {
            tn_task_create(
                (TN_TCB*)&test_task4,                
                test_task_func4,                        
                23,                                    
                &(test_task_stack4[TEST_STACK_SIZE-1]),
                TEST_STACK_SIZE,
                (PVOID)0,
                TN_TASK_START_ON_CREATION);

            Create = FALSE;
        }
    }
}

Для:

- 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 для сравнения.

[DASM 0]

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

[spf 0]

Спасибо за исчерпывающий ответ.

В Thumb mode будет чуть дольше, если не ошибаюсь.

 

Если не будет лень - попробую еще uC/OS для сравнения.

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

[VslavX 0]

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

Аппаратура - та же самая, компилятор тоже, софт:

- uC/OS v2.80

- официальный порт под ARM

Итого:

13.5 uS - разрешена проверка аргументов, hooks и статистика

13.0 uS - нет проверки аргументов, выключены hooks и статистика

 

На самом деле время переключения контекста вопрос далеко не праздный.

У меня пара проектов с USB требуют как можно большей потоковой производительности

+ вычисления в фоне. Сейчас вариант с обработкой протокола USB в прерываниях

справляется с небольшим запасом - теперь главное, чтобы при переходе под OS этот запас

не сожрался. Более быстрый проц, плиз, не предлагать - цена очень критична.

[VslavX 0]

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

[zltigo 0]

Мне тут в привате еще scmRTOS и FreeRTOS посоветовали.

На FreeRTOS можете и не cмотреть - не для соревнований в скорости переключения создавалась :)

А scmRTOS думаю (совершенно субъективно :) ) где-то 7us будет.

[VslavX 0]

На FreeRTOS можете и не cмотреть - не для соревнований в скорости переключения создавалась :)

А scmRTOS думаю (совершенно субъективно :) ) где-то 7us будет.

Я вот только что дополнительно заинлайнил запрещение/разрешение прерываний при помощи intrinsic функций (по размеру даже меньше получилось - очень приличный код IAR 4.30 сгенерировал, ассемблеру 5-10% уступает, не больше) и в итоге получил - 7.3 uS :)

У меня сложилось впечатление, что любая инструкция перехода для SAM7 при исполнении из флеша порождает просто немерянные тормоза - перезагрузка конвеера просто множится на ожидание флеша.

А совершенно объективно :) по scmRTOS кто-то может сказать - тест-то на 15 минут?

[zltigo 0]

по scmRTOS кто-то может сказать - тест-то на 15 минут?

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

[spf 0]

А совершенно объективно :) по scmRTOS кто-то может сказать - тест-то на 15 минут?

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

 

1 - Есть инфа на сайте, на самой первой странице.

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

 

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

 

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

 

//---------------------------------------------------------------------------
  OS_PROCESS void TProc1::Exec()
{
    for(;;)
    {
        ef.Wait();
        ////////// ПОГАСИТЬ
    }
}
//---------------------------------------------------------------------------
OS_PROCESS void TProc3::Exec()
{
    for(;;)
    {
        Sleep(1);
         ////////// ЗАЖЕЧЬ
          ef.Signal();
    }
}

[VslavX 0]

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

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

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 - это наш выбор :).

- ставим (с кривой ухмылкой :glare: ) 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 и благодаря этому возможна реализация протоколов коррекции приоритетов при использовании мутексов.

[DASM 0]

Гы. Отныне появилось третье измерение по мемерению пиписьками в эмбеддед :-D

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

[yuri_t 0]

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

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

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

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

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

 

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

[VslavX 0]

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

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