Выпущена scmRTOS 4.0., Ура, товарищи! :) Опции

[AHTOXA]

Собственно, субж.
Ссылки:

• Что нового (en);
• Migration Guide;
• Download;
• svn (trunk).
• User Manual (русский)
• User Manual (en)

Кроме того, незадолго до этого была выпущена версия 3.11. Это завершающая, багофиксная версия 3.x. Ссылки:

• Download;
• svn.

[Aprox]

Уважаемые авторы новой 4-ой версии!

Позвольте пару вопросов от новичка, который только приглядывается к использованию OS и напряженно думает, зачем оно ему надо.

1. Вы ввели новое обзначение для типов переменных. Вопрос- чем не устраивают классические имена типов из С++? Зачем изобретать u32_t вместо всем знакомого из классики unsigned long?

2. В STM32 применен новый контроллер прерываний, отличный от старого VIC тем, что грамотно и надежно исполняет nested прерывания. Это nested каким-то образом нашло отражение в вашем порте на STM32? Или все по-старому, никаких nested ?

[_Артём_]

Или все по-старому, никаких nested ?

А что по вашему раньше нельзя было?
Код из примера v3

Код

#define ENABLE_NESTED_INTERRUPTS() __enable_interrupt()


#pragma vector=TIMER1_COMPA_vect
OS_INTERRUPT void Timer1_period_ISR()
{
    OS::TISRW_SS ISRW;

    ENABLE_NESTED_INTERRUPTS();
    Timer1_Ovf.SignalISR();
}

[Aprox]

А что по вашему раньше нельзя было?

Наверное можно. Но при этом нельзя было размещать внутри ISR длительных операций которые блокировали бы работу OS и всей системы в целом. Теперь, с появлением nested контроллера прерываний в ISR можно размещать практически целые статические task( за исключением инициализации задачи) и не боятся блокировки всей системы. Такой прием особенно хорош еще и тем, что в STM32 периферия взаимодействует с памятью по DMA, поэтому нагрузка на систему по прерываниям резко ниже. Вот, я и спрашиваю - учтены ли эти новации периферии в новой версии scmRTOS?

Во-первых все уже придумано до нас. эти типы являются частью стандарта C-99 (см. описание stdint.h) . Их вводили потому, что разрядность char, short, int, long, long long стандартом не определена. И еще для того, чтобы код без переписывания компилился максимально оптимально под любую платформу.

Мне представляется, заботу об оптимальности использования памяти или скорости выполнения кода берет на себя компилятор C++. По крайней мере, в IAR это именно так. Пользователю знать, в какой размер битов упакована его переменная, как правило не обязательно. По делу, ему важно знать только пределы изменения переменной. А эта информация представлена в мануалах на любой компилятор, например там пишут :

unsigned char 0 .. 255
signed char -128 .. +127
.... и т.д.

А во-вторых писать unsigned long слишком длинно.

Зато кросплатформенность соблюдается. Причем в мощных системах проектирования (Visual Studio), реализован умный редактор текстов, который подсказывает тип переменной и даже сам его вписывает.

[AHTOXA]

Вот, я и спрашиваю - учтены ли эти новации периферии в новой версии scmRTOS?

Вложенные прерывания у Cortex-M3 порта можно использовать, как в новой, так и в старой версии scmRTOS.

[_Артём_]

Вложенные прерывания у Cortex-M3 порта можно использовать, как в новой, так и в старой версии scmRTOS.

Может Aprox под поддержкой вложенных прерываний имел в виду что-то навроде такого:

Код

#define configKERNEL_INTERRUPT_PRIORITY n // максимальный уровень приоритета прерываний в которых могут использоваться сервисы ОС

Все прерывания с приоритетом выше configKERNEL_INTERRUPT_PRIORITY не запрещаются никогда, но работают без использования ОСи.
NVIC CM3 позволяет сделать подобное.
Но есть ли в этом смысл? Или оно не надо никому?

[AHTOXA]

Может Aprox под поддержкой вложенных прерываний имел в виду что-то навроде такого:

Нет, судя по тому, что он пишет, что "в ISR можно размещать практически целые статические task", речь как раз идёт о низкоприоритетных прерываниях. В принципе, нужды в этом при использовании оси нет никакой, ибо для этого есть процессы оси. Что же касаемо

Все прерывания с приоритетом выше configKERNEL_INTERRUPT_PRIORITY не запрещаются никогда, но работают без использования ОСи.

, то этого сейчас нет. Возможно, существуют задачи, для которых это бы могло пригодиться, но их весьма немного. Ибо выигрыш будет буквально мизерным (в scmRTOS прерывания запрещаются буквально на несколько тактов), зато:
- время переключения контекста возрастёт;
- время отклика оси ухудшится;
- добавится проблем по синхронизации безосёвого обработчика прерываний с осью.

[Aprox]

Нет, судя по тому, что он пишет, что "в ISR можно размещать практически целые статические task", речь как раз идёт о низкоприоритетных прерываниях. В принципе, нужды в этом при использовании оси нет никакой, ибо для этого есть процессы оси.

Не совсем так, рассмотрим для примера стек TCP/IP как task. При передаче по протоколу TCP существуют ряд коротких пакетов синхронизации и подтврждения, которые нет смысла отправлять на обработку фоновой задаче. Уже не говоря про поступающий "мусор", который надо просто игнорировать. Много проще короткие операции делать прямо в ISR, а уже пакеты с данными отправлять как message в ожидающую задачу OS. Приоритет такой ISR отнюдь не низкий, а наоборот- высокий, чтобы избежать ошибки overflow поступающих пакетов.

Что же касаемо, то этого сейчас нет. Возможно, существуют задачи, для которых это бы могло пригодиться, но их весьма немного. Ибо выигрыш будет буквально мизерным

Выигрыш в наглядности и простоте будет колосальный. Каждая задача синхронизирована за прерывание от периферии, - это и нужно прикладнику в первую очередь.

- время переключения контекста возрастёт;

Не знаю, как в других, но в ARM9/11 и Cortex контекст на прерываниях переключается практически мгновенно.

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

Привычная нам OS при таком подходе становится сама весьма сомнительной вещью. Надо-ли идти у нее на поводу?

Лучше посмотрите в стандарте stdint.h
Он там очень даже есть, более того, является его неотъемлемой частью.

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

[aaarrr]

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

Если <stdint.h> подключен, то ругнуться на uint8_t компилятор может только в том случае, если целевая платформа в принципе не имеет подобного типа данных (например, TI's C2000, C5500).