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

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

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

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

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

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

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

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

[Aprox]

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

Видите-ли, я тупой юзер, и лишние заморочки мне совсем не нужны. Извините, но совершенно фиолетово, как и что будет "обрезать" компилятор, главное- чтобы результат вычислений был правильным. И если мне на входе сказали, что переменная типа unsigned char может хранить значения от -128 до +127, а перменная типа int значения в пределах от - 2147483648 lдо + 2147483647, то этого вполне достаточно, чтобы приступить писать конкретное приложение особо ничем не заморачиваясь .

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

Я посмотрел на текст файла stdint.h в составе IAR 6.0. Увидел by options, т.е. никакой это не стандарт. Но заморочит голову прикладнику по-крупному. Вам, как авторам, это надо? К тому-же, принцип "одинаково хорошо" очень неубедителен, когда видишь сколь велик в ресурсах разброс предлагаемых микроконтроллеров. По-моему, все окучить "одинаково хорошо" никак невозможно.

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

"Студия" не спотыкается, она просто не знает ничего про разрядность типов данных. Но зато прекрасно выделяет стандартные ключевые слова: signed, long, void, double .. и т.д. Точно также IAR выделяет эти ключевые слова. А вот vu16_t, извините, не выделяет. Потому, что не стандарт ни С, ни С++. Стоит ли овчинка выделки?

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

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

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

И если мне на входе сказали, что переменная типа unsigned char может хранить значения от -128 до +127, а перменная типа int значения в пределах от - 2147483648 lдо + 2147483647,

Переменная типа unsigned char может хранить значения от 0 до 65535 (на TI's C2000, C5500) а int от -32768 до +32767 (AVR). И что нам с этим делать?

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

Вам никто не запрещает в своем приложении использовать те типы, которые вам больше нравятся.

Но заморочит голову прикладнику по-крупному.

Странно. Сколько человек узнавали о stdint.h - все находили его удобным. Вы первый прикладник, которого ставят в тупик (морочат голову) выражения типа typedef unsigned char uint_fast8_t; Видимо ваш прикладник переписывает код под каждую платформу заново, а пользователи stdint.h просто используют один и тот же код на PC, Blackfin, ARM, MSP430, AVR и прочих без ненужных затрат на этапе выполнения.

К тому-же, принцип "одинаково хорошо" очень неубедителен, когда видишь сколь велик в ресурсах разброс предлагаемых микроконтроллеров. По-моему, все окучить "одинаково хорошо" никак невозможно.

Поэтому давайте сделаем для всех платформ хуже чем возможно только потому, что Aprox имеет аллергическую неприязнь к stdint.h?

Но зато прекрасно выделяет стандартные ключевые слова: signed, long, void, double .. и т.д. Точно также IAR выделяет эти ключевые слова. А вот vu16_t, извините, не выделяет.

Значит надо взять хороший редактор. Eclipse выделяет. Не таким же цветом, как встроенный тип, но отдельным цветом - как определенный пользователем тип.

Под сколькими платформами вы используете одни и те же исходники?

[Aprox]

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

Нет, не буду. Наоброт, сейчаc порой страдаю из-за слишком быстрого процессора, котрый забегает вперед по кэшу уже после прерываний от периферии.

Переменная типа unsigned char может хранить значения от 0 до 65535 (на TI's C2000, C5500) а int от -32768 до +32767 (AVR). И что нам с этим делать?

Авторам универсальной OS ? - Не знаю. А юзеру -просто почитать мануал на компилятор для своей платформы. В целом, задача сделать универсальную OS на все случаи жизни мне представляется нерешаемой.

Вам никто не запрещает в своем приложении использовать те типы, которые вам больше нравятся.

Я этим постоянно занимаюсь, когда определяю классы в C++. Но ни разу в голову не пришло подменять стандартные ключевые слова языка C++ на какие-то свои обозначения.

Значит надо взять хороший редактор. Eclipse выделяет. Не таким же цветом, как встроенный тип, но отдельным цветом - как определенный пользователем тип.

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

Под сколькими платформами вы используете одни и те же исходники?

Всегда под одной единственной платформой- ARM9 и Cortex M3. Прикладнику и производственнику скакать по платформам - не имеет никакого смысла. И совсем не из-за stdint.h

Я говорил про M3. У него обработчик PendSV выполняется ~70 тактов (менее микросекунды на 72 МГц).

Уточните пожалуйста, имеется в виду "обработчик" от scmRTOS со всеми его полингами или чистую реакцию процессора на прерывание по вектору SW?

[AHTOXA]

Уточните пожалуйста, имеется в виду "обработчик" от scmRTOS со всеми его полингами или чистую реакцию процессора на прерывание по вектору SW?

Обработчик прерывания PendSV порта scmRTOS для Cortex-M3.

[Aprox]

Обработчик прерывания PendSV порта scmRTOS для Cortex-M3.

Спасибо. Теперь сравните со времнем реакции задачи, если бы она синхронизировалась напрямую от прерываний периферии и ее exec() находился бы внутри ISR. По моему, небо и земля. А если учесть, что в современных МК периферия работает с памятью по DMA, то вообще- OS по старинке отдыхает.

.. Пожалейте авторов! Они сделали большую работу очень качественно и бесплатно для пользователей.
P.S. Всегда считал, что писать переносимый код это хороший тон .

Я испытываю глубочайшее и искреннее уважение к авторам scmRTOS. И прежде всего потому, что сваяли вещь на С++, в то время как остальные тянут С. Как прикладник, я очень понимаю, сколь хорошо и надежно один раз создать и отладить класс, а потом наплодить на его основе много однотипных обьектов. Только поэтому и обратил внимание на scmRTOS, думал- вот оно! Но оказалось, что авторы, сделав грандиозный скачок в программировании, одновременно сделали и два, не менее грандиозных шага назад, в прошлый век,- по хардверу. Работая на передовом C++, они ориентируются на мелкие, примитивные микроконтроллеры, которые сейчас и найти-то стало трудно на рынке. Используют темплейты языка C++ для отживших свой век АVR! Честно скажу - уму нерастяжимо. Давно прошло то время, когда надо было влезать в узкие ворота ограниченных ресурсов процессора. Сейчас за те же деньги и при тех же габаритах юзер имеет возможность использовать чипы, сравнимые с ПК. Но авторы по-прежнему считают доблестью сохранить совместимость с устаревшими моделями. Причем, в ущерб своему же творению, его тянет назад груз прошлого, тормозит развитие. Извините, я этого понять не в состоянии.

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

Работая на передовом C++, они ориентируются на мелкие, примитивные микроконтроллеры, которые сейчас и найти-то стало трудно на рынке. Используют темплейты языка C++ для отживших свой век АVR!

Ну извините, не угодили использующим исключительно "профессинальные контроллеры" с переднего края полета мысли контроллеростроителей. Когда будем делать следующую ОСь, мы вас спросим, для каких контроллеров ее делать и главное, для каких ее делать не нужно.