[Артём__ 1]

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

 

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

#define configKERNEL_INTERRUPT_PRIORITY n // максимальный уровень приоритета прерываний в которых могут использоваться сервисы ОС

 

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

NVIC CM3 позволяет сделать подобное.

Но есть ли в этом смысл? Или оно не надо никому?

[AHTOXA 25]

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

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

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

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

- время переключения контекста возрастёт;

- время отклика оси ухудшится;

- добавится проблем по синхронизации безосёвого обработчика прерываний с осью.

[Артём__ 1]

в scmRTOS прерывания запрещаются буквально на несколько тактов

 

 

Ну для авр запрет - несколько сотен тактов. Или я не прав? Ну да что от авр ждать-то.

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

[aprox 0]

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

 

 

[aaarrr 72]

Я посмотрел на текст файла stdint.h в составе IAR 6.0. Увидел by options, т.е. никакой это не стандарт.

Лучше посмотрите в стандарте stdint.h

Он там очень даже есть, более того, является его неотъемлемой частью.

[aprox 0]

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

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

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

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

- время переключения контекста возрастёт;

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

- время отклика оси ухудшится;

- добавится проблем по синхронизации безосёвого обработчика прерываний с осью.

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

 

 

 

 

Лучше посмотрите в стандарте stdint.h

Он там очень даже есть, более того, является его неотъемлемой частью.

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

[aaarrr 72]

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

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

[demiurg_spb 1]

"Студия" не спотыкается, она просто не знает ничего про разрядность типов данных. Но зато прекрасно выделяет стандартные ключевые слова: signed, long, void, double .. и т.д.

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

 

 

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

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

 

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

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

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

И если мне на входе сказали, что переменная типа 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 выделяет. Не таким же цветом, как встроенный тип, но отдельным цветом - как определенный пользователем тип.

 

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

[AHTOXA 25]

Ну для авр запрет - несколько сотен тактов. Или я не прав? Ну да что от авр ждать-то.

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

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

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

[Anatoly74 0]

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

В исходниках:

public:
    INLINE TKernel() : CurProcPriority(pr0)
                     , ReadyProcessMap( (1ul << (PROCESS_COUNT)) - 1)  // set all processes ready
                     , ISR_NestCount(0)
    {
    }

 

Должно быть:

public:
    INLINE TKernel() : CurProcPriority(pr0)
                     , ReadyProcessMap( (1 << (PROCESS_COUNT)) - 1)  // set all processes ready
                     , ISR_NestCount(0)
    {
    }

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

[_pv 107]

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

В исходниках:

ReadyProcessMap( (1ul << (PROCESS_COUNT)) - 1)  // set all processes ready

Должно быть:

ReadyProcessMap( (1 << (PROCESS_COUNT)) - 1)  // set all processes ready

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

[demiurg_spb 1]

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

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

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

Должно быть:

public:
    INLINE TKernel() : CurProcPriority(pr0)
                     , ReadyProcessMap( (1 << (PROCESS_COUNT)) - 1)  // set all processes ready
                     , ISR_NestCount(0)
    {
    }

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

наверное правильнее (красивее) будет

                     , ReadyProcessMap( ((TProcessMap)1 << (PROCESS_COUNT)) - 1)  // set all processes ready

Но и в таком виде ошибки я тут не вижу.

[aprox 0]

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

Нет, не буду. Наоброт, сейча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?