Может 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?