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

• Что нового (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.

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

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


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

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

Ну для авр запрет - несколько сотен тактов. Или я не прав? Ну да что от авр ждать-то.
Для Cortex-m3 во время выполнения PendSV прерывания где-то разрешены? И как можно посмотреть время выполнения PendSV?

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

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

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

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

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

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

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

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





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

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

В настройках практически любой современной IDE всегда есть возможность пополнить список ключевых слов чтобы и они тоже подсвечивались. Посмотрите в хелпе.


Вольному - воля.

Потом вы будете ныть, что программа медленная, а компилятор плохой и делает кучу ненужных действий.
Переменная типа 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?
Значит надо взять хороший редактор. Eclipse выделяет. Не таким же цветом, как встроенный тип, но отдельным цветом - как определенный пользователем тип.

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

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

Прерывания во время выполнения PendSV запрещены. Посмотреть время выполнения - например махать ножкой и смотреть скопом. У кортексов я засекал при помощи DWT. (Обнаружил при этом способ сократить PendSV до 60 тактов )

Найдена опечатка в порте AVR, Common/OS_Kernel.h
В исходниках:


Должно быть:

Кстати, в версии 3.11 такая же фигня.

а будет нормально работать если процессов больше 7?

скорее 15 или 31. (все цифири по умолчанию имеют тип int)

А почему должно быть так? В чем ошибка? Будет неявное приведение unsigned long к TProcessMap.
наверное правильнее (красивее) будет Но и в таком виде ошибки я тут не вижу.

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

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

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

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




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

Раз в Common/ , то это не в порте, а в ОС, в ее общей части. Только это не опечатка, а багфикс.


Когда-то было как раз так, как Вы предлагаете.

Теперь берём процесор с 16-битным int (MSP430, AVR, STM8) и берём, например, 17 процессов (вместе с idle).
Сдвигаем 1-ку, которая без суффикосв имеет тип int, на 17 бит. Получаем 0. Вычитаем 1, получаем -1 (типа int).
Как оно теперь приведётся к 32-битному TProcessMap, как 0xFFFFFFFF или как 0x0000FFFF — не важно, ведь нужно было 0x0001FFFF

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

При портировании по Вашему сценарию авторам придет портировать не только аппаратно-зависимую часть, но и программно-зависимую от int, char и т.д.
Аппаратно-зависимая часть сейчас в соответвтующем порте для процессора (Ports: OS_Target.h OS_Target_asm.S OS_Target_cpp.cpp) уже сделана.
Осталась программная часть: (Common ) OS_Kernel.cpp OS_Kernel.h OS_Services.cpp OS_Services.h scmRTOS.h scmRTOS_310_compat.h scmRTOS_defs.h usrlib.cpp usrlib.h и (Extensions ) profiler.h . Вроде ничего не забыл.
То есть ВСЕ и с учетом компилятора! Все надо отдельно отладить и поддерживать.

Код непереносимый получится. Пожалейте авторов! Они сделали большую работу очень качественно и бесплатно для пользователей.

P.S. Всегда считал, что писать переносимый код это хороший тон .

(выделение моё)
Это Вы о stdint.h ? Ну тогда, к примеру, #include <stdio.h> — это "подключать какие-то свои функции"
Кстати, если я не ошибаюсь, stdint.h, существующий в С начиная с C99, наконец-то вошёл в C++11


Я не помню, почему сделали не приведение к TProcessMap, а просто 1ul. Тогда в рассылке проскочило, быстренько обсудили, было исправлено в pre-v400. А я как раз в те дни что-то у себя менял, ну заодно и это исправил в 3.10.

Добавлено:
Ха! Так я сначала и хотел (TProcessMap)1
Смотрим рассылку (там, правда, часть покоцана в кодировках), ближе к концу — обсуждаемое.
Почему не (TProcessMap)1:
Надо было вообще ULL с запсом, чтобы позже нарваться на ненужное предупреждение.
Пусть 7 процессов и IDLE, итого 8. TProcessMap 8-битный. Сдвигаем (TProcessMap)1 на 8 и выходим за границы типа TProcessMap.
Результат будет всё равно правильный, но компилятор ворчит, лишние предупреждения в выдаче маскируют нелишние и вообще подстрекают снизить уровень ворчливости компилятора.

Да, теперь все ясно.

Получается, что в текущем варианте можно использовать не более 31 задачи, включая Idle (т.к. 1UL) для платформ разрядностью 32 включительно.

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

Да. Об этом написано в документации в самом начале главы 2.1. "Общие сведения":
и в комментариях исходников рядом со строкой задания количества процессов:

Зануда:
А в документации страницы с 115 по 118, 120, 122, 124, 126, 128, 130 и 132 не нумерованы (версия 29.03.2003 – 29.12.2011)

Тактов 300 с чем-то, но при полном запрете прерываний.
70 гораздо лучше.


Удобная штука. DWT только у M3 есть или у всех?

Получилось ~200 тактов от засыпания одной задачи до запуска другой.

Теперь уже 60

Насколько я смог понять, у M3 и M4(F). У остальных что-то не видно.

Да, это хорошо согласуется с моими измерениями (2.7мкс / 2.55 мкс).

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


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

У меня сложилось впечатление, что вы влезли в эту радостную тему с единственной целью - попонтоваться. К сожалению, получилось не очень, уровень не тот. Претензии к stdint.h выглядят просто жалко, а остальное - вообще какой-то поток сознания. Вы уж извините меня за прямоту.
Я думаю, что вам придётся писать свою ось. С unsigned int вместо uint32_t, и чтоб "задачи синхронизировались напрямую от прерываний периферии". Потому что scmRTOS - не такая, и такой не будет.
Чтож, желаю вам успехов в этом деле.

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

Aprox, Вас ни кто не заставляет использовать эту ОС.
Если Вас не устраивает сделанное кем-то, то сделайте свое и выложите для всех. Можно будет сравнить результаты.
ОС имеется множество, как и задач. Авторы scmRTOS позиционировали сферу применения (см. документацию).


Просветите, пожалуйста, какие это чипы. Возможно, я отстал от жизни.

Спасибо за замечание! Слетел стиль страницы в конце раздела. Поправлено.



Этта пять!



+1.

Дело закончилось обидами. А ведь я хотел как лучше! Чтобы отличная задумка авторов не отставала бы от времени, от прогресса в хардвере микроконтроллеров. Но раз обиделись, зачит чувствуете свою неправоту. Что же касается "придется писать собственную OS"- нет не придется. Ибо не вижу жгучей необходимости.

Остается искренне порадоваться, что вы идете в ногу "с прогрессом в хардвере микроконтроллеров". %)

ScmRTOS изначально задумывалась как легковесная ось для "тонких" контроллеров с 512Б ОЗУ.
Для "переднего края хардверного фронта" есть другие.
А авторы, прежде всего, разрушили два расхожих мифа: что операционкам, и тем более на с++, в мелкоте типа AVR и MSP430 не место.
За что им заслуженный респект.

Дело в том, что с типами данных действительно БЕДА.. Нестандартные размерности char, int как правило, действительно бесят, вынуждая программистов вытворять финты ушами. С этим ничего не сделаешь. Обижаться или придираться по этому поводу - бессмысленно. Приходится приспосабливаться к тому что есть.

Да, наверное есть, но программирование в системе реального времени на С++ я лично не встречал.

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