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

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

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

• Download;
• svn.

Искренние поздравления!
Использовал несколько раз третью ветку. Доволен! Самое то для маленьких МК)
Быть может в будущем четверку возьму в проекты.

Молодцы!

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

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

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

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

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

Для embedded привычно указание в типе его разрядность.

Во-первых все уже придумано до нас. эти типы являются частью стандарта C-99 (см. описание stdint.h) . Их вводили потому, что разрядность char, short, int, long, long long стандартом не определена. И еще для того, чтобы код без переписывания компилился максимально оптимально под любую платформу. И если нам нужно целое для хранения значения то 0 до 255, то на 8-битном AVR или 16-битном MSP430 для этого оптимально подходит байт (т.е. тип unsigned char на этих платформах), а для ARM более эффективен будет 32-битный unsigned int, ибо процессор не имеет 8-битной арифметики и вынужден будет постоянно преобразовывать 8 бит в 32 и обратно. Стандарт гарантирует, что тип uint_fast8_t будет удовлетворять нашим требованиям. Если копнуть глубже, то обнаружится, что для AVR этот тип будет компилиться в unsigned char а для ARM - в unsigned int. Не трогая исходников, что очень важно для многоплатформенного кода. Если пример с арифметикой вас не убеждает - подумайте о типе uintptr_t, т.е. целое, в котором умещается указатель. Размеры указателя на разных платформах отличаются.

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

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


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

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



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

Какраз наоборот

Я бы поменял местами встречающуюся в коде последовательнсть:на
Ибо попадались Си-шные компиляторы дающие предупреждение на то что сначала должен идти storage квалификатор.
Хотя тут С++, может и не быть никаких предупреждений, но у меня в голове это засело крепко и я уже как бык на красную тряпку реагирую...

Никакой заботы компилятор предоставить не может . Вот укажете вы какой-нибудь переменной unsigned int чтобы было быстро на ARM, и компилятор будет вынужден использовать 2 байта на AVR, хотя может быть и достаточно одного. А укажете unsigned char - и компилятор для ARM будет вынужден после каждой арифметической операции обрезать 24 старших бита, ибо делать арифметику с байтами ядро делать не умеет. А укажете uint_fast8_t и все будут довольны. Чем плохо?
То есть для каждой переменной мы должны просматривать мануалы на все компиляторы всех процессоров, под которые портирована ОС и искать тот тип, который удовлетворит нас для этой переменной на всех платформах/компиляторах? Но зачем, если специально для такого случая придуман stdint.h? И во многих случаях один стандартный тип не будет одинаково хорош на всех платформах, пример выше.
Кроссплатформенность еще лучше соблюдается с типами из stdint.h. И с этими типами прекрасно себя чувствует умный редактор типа Eclipse. Если Студия спотыкется на стандартных заголовочных файлах - увы. Как же она тогда работает с остальными typedef, в том числе и пользовательскими?

Причина?

ответил в предыдущем посте.

помимо приведённого примера с uint_fast8_t, который хоть и медленее, но работать будет,
могут быть еще замечательные грабли вида
for (int i = 0; i < 100000; i++){...}
если тип int вдруг внезапно окажется 16 разрядов вместо 32 и 100000 в него уже не влезет.

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

Ну, как только (если) возникнет такой вопрос, так сразу и будем решать. Пока, вродь, не было прецедентов.