[AHTOXA 15]

Собственно, субж.

Ссылки:

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

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

• Download;
• svn.

[haker_fox 61]

Искренние поздравления!

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

Быть может в будущем четверку возьму в проекты.

[FatRobot 0]

Молодцы!

 

 

[aprox 0]

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

 

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

 

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

 

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

[Артём__ 0]

Или все по-старому, никаких 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();
}

[bookevg 0]

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

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

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

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

Во-первых все уже придумано до нас. эти типы являются частью стандарта 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 слишком длинно.

[aprox 0]

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

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

 

 

[demiurg_spb 0]

Зато кросплатформенность соблюдается.

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

 

Я бы поменял местами встречающуюся в коде последовательнсть:

INLINE static

на

static INLINE

Ибо попадались Си-шные компиляторы дающие предупреждение на то что сначала должен идти storage квалификатор.

Хотя тут С++, может и не быть никаких предупреждений, но у меня в голове это засело крепко и я уже как бык на красную тряпку реагирую...

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

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

Никакой заботы компилятор предоставить не может . Вот укажете вы какой-нибудь переменной unsigned int чтобы было быстро на ARM, и компилятор будет вынужден использовать 2 байта на AVR, хотя может быть и достаточно одного. А укажете unsigned char - и компилятор для ARM будет вынужден после каждой арифметической операции обрезать 24 старших бита, ибо делать арифметику с байтами ядро делать не умеет. А укажете uint_fast8_t и все будут довольны. Чем плохо?

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

То есть для каждой переменной мы должны просматривать мануалы на все компиляторы всех процессоров, под которые портирована ОС и искать тот тип, который удовлетворит нас для этой переменной на всех платформах/компиляторах? Но зачем, если специально для такого случая придуман stdint.h? И во многих случаях один стандартный тип не будет одинаково хорош на всех платформах, пример выше.

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

Кроссплатформенность еще лучше соблюдается с типами из stdint.h. И с этими типами прекрасно себя чувствует умный редактор типа Eclipse. Если Студия спотыкется на стандартных заголовочных файлах - увы. Как же она тогда работает с остальными typedef, в том числе и пользовательскими?

[dxp 53]

Я бы поменял местами встречающуюся в коде последовательнсть:

INLINE static

на

static INLINE

Причина?

[demiurg_spb 0]

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

[_pv 61]

Зато кросплатформенность соблюдается.

помимо приведённого примера с uint_fast8_t, который хоть и медленее, но работать будет,

могут быть еще замечательные грабли вида

for (int i = 0; i < 100000; i++){...}

если тип int вдруг внезапно окажется 16 разрядов вместо 32 и 100000 в него уже не влезет.

 

 

[AHTOXA 15]

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

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

[dxp 53]

Я бы поменял местами встречающуюся в коде последовательнсть:

INLINE static

на

static INLINE

Ибо попадались Си-шные компиляторы дающие предупреждение на то что сначала должен идти storage квалификатор.

Хотя тут С++, может и не быть никаких предупреждений, но у меня в голове это засело крепко и я уже как бык на красную тряпку реагирую...

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