[lmaks 0]

Использую высокоприоритетные прерывания (выше configMAX_SYSCALL_INTERRUPT_PRIORITY) для аппаратуры. Однако после завершения приема данных (несколько прерываний) требуется активировать задачу обработки.

Из высокоприоритетных прерываний нельзя пользоваться системными API (fromISR). Есть какие-нибудь мысли как это сделать красиво. Думал побаловаться с программным прерыванием SV CALL - но оно уже используется системой. Остались только кривые мысли типа активировать какой-нибудь таймер на минимуме - чтобы тот выдал прерывание уже с приоритетом ниже configMAX_SYSCALL_INTERRUPT_PRIORITY и далее уже активировать семафор задачи. Думал даже задействовать ножку под EXT interrupt - но они все уже заняты.

[seniorandre 0]

Использую высокоприоритетные прерывания (выше configMAX_SYSCALL_INTERRUPT_PRIORITY) для аппаратуры.

Ну типа, если нельзя, но очень хочется, то можно? Чем продиктовано?

[lmaks 0]

Ну типа, если нельзя, но очень хочется, то можно? Чем продиктовано?

Зачем же кто-то придумывал критические секции и мьютексы всякие. Зачем себе грабли подкладывать.

Нашел варитант. В ExtI прерываниях есть возможность активизации их программно.

EXTI_GenerateSWInterrupt(EXTI_Line22);

В теле прерывания необходимо проверить флаг программного прерывания

if(EXTI->SWIER & EXTI_Line22)

К примеру линия 22 подключена на RTC - то же не проблема. RTC проверяет свои флаги

if(RTC_GetITStatus(RTC_IT_WUT) != RESET)

Аккуратно надо только сбрасывать Pending бит.

EXTI_ClearITPendingBit(EXTI_Line22);

(т.е. сначала надо проверять программное прерывание, а потом RTC.) иначе сброс бита в RTC - сбросит

и бит программного прерывания.

[juvf 10]

А нельзя планку configMAX_SYSCALL_INTERRUPT_PRIORITY поднять? Или все прерывания опустить ниже configMAX_SYSCALL_INTERRUPT_PRIORITY? Не те, что требуют после приема активировать задачу, а вообще все. были прерывания с приоритетами 1,2,4,13,15..... станнут 10, 11, 12, 13,15 (ну или 1,2,4,5, 6 порядок приоритетов другой, не помню с ходу). При этом приоритет не поменяется.

[LightElf 0]

Остались только кривые мысли типа активировать какой-нибудь таймер на минимуме - чтобы тот выдал прерывание уже с приоритетом ниже configMAX_SYSCALL_INTERRUPT_PRIORITY и далее уже активировать семафор задачи. Думал даже задействовать ножку под EXT interrupt - но они все уже заняты.

Какой процессор/ядро? У кортексов через NVIC можно программно вызвать любое прерывание. Я такое делал, использовал незадействованный вектор в таблице прерываний.

 

 

[_3m 4]

В 07.03.2015 в 09:22, LightElf сказал:

Какой процессор/ядро? У кортексов через NVIC можно программно вызвать любое прерывание. Я такое делал, использовал незадействованный вектор в таблице прерываний.

Подниму тему.

Возникла точно такая же задача. (опустить приоритет ниже configMAX_SYSCALL_INTERRUPT_PRIORITY НЕ ПРЕДЛАГАТЬ!)

Более красивого решения чем задействовать неиспользуемый вектор так и не найдено ?

[Arlleex 131]

Насколько быстро надо обработать?

Ну раз нельзя приоритеты перестраивать, то можно активировать IdleHook(), в нем смотреть некий глобальный volatile-флажок, который будет подниматься в нужном быстром прерывании.

Как только поднялся - сбрасываем и активируем задачу уже средствами RTOS.

[haker_fox 60]

On 3/2/2015 at 4:29 AM, lmaks said:

SV CALL - но оно уже используется системой

Оно используется однажды при запуске планировщика. Далее оно, насколько я знаю, не используется. В любом случае, SVC прерывание может принимать аргументы при вызове. Может быть Вам это поможет?

On 3/2/2015 at 4:29 AM, lmaks said:

Думал даже задействовать ножку под EXT interrupt - но они все уже заняты.

Через контроллер прерываний NVIC Вы можете программно инициировать любой! обработчик прерывания. Естественно, делать это нужно (в общем случае) для свободного, незанятого вектора.

[Arlleex 131]

3 минуты назад, haker_fox сказал:

Оно используется однажды при запуске планировщика. Далее оно, насколько я знаю, не используется.

С SVC надо быть весьма осторожным, если текущий приоритет выполнения > приоритета SVC, то получим HF.

А у вопрошающего явное желание задрать приоритеты каких-то прерываний в наивысшие.

P.S. На самом деле вариант с фиктивным программным прерыванием (любым) не так уж плох.

[EdgeAligned 53]

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

[Arlleex 131]

13 минут назад, EdgeAligned сказал:

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

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

[EdgeAligned 53]

Нет, не обязательно семафор, можно через vTaskResume(). Или же, согласно идеологии RTOS, полученные данные дожны передаваться в другую задачу именно через очередь, а задача и будет разблокирована при непустой очереди. 

Тормознуто? Но такова концепция RTOS - псевдопараллельное исполнение задач ценой накладных расходов. И грамотное построение взаимодействия в рамках RTOS - это отдельное искусство, так сказать. 

[haker_fox 60]

7 hours ago, Arlleex said:

если это тормозной FreeRTOS

Почему это он тормозной? Какая альтернатива?😀

On 3/2/2015 at 4:29 AM, lmaks said:

Однако после завершения приема данных (несколько прерываний) требуется активировать задачу обработки.

Мне подумалось, а насколько быстро нужно разбудить задачу после готовности данных? Всё может свестись к банальному опросу volatile-флага поллингом этой же задачей. Да, знаю, что поллинг и ОСРВ - обычно вещи несовместимые. Но иногда так приходится делать.

[amaora 20]

Сделать еще одно программное прерывание в котором уже вызывать FromISR функции это правильное и быстрое решение. Если RTOS находится в критической секции в момент выполнения приоритетного прерывания, то программное прерывание поставится в очередь до выхода из критической секции.

[Arlleex 131]

5 часов назад, haker_fox сказал:

Почему это он тормозной? Какая альтернатива?

Средства синхронизации в нем написаны примитивно "в лоб" без какой-то оптимизации, а соотв. (весьма длинные) функции оборачиваются в критические секции практически со входа до выхода. Ну и всякие другие моменты, связанные с универсальностью ОС - например, поиск задач, готовых к выполнению - через проход по спискам, когда на том же Cortex-M есть замечательная аппаратная однотактная CLZ. Итого, вместо одного такта на принятие решения о следующей выполняемой задаче получаем (вставьте любое большое кол-во) тактов на пробег по спискам задач и т.д. То же самое касается и постановки задачи на ожидание/готовность - один такт против вороха.

Альтернативы - если прямо нужны - всегда найдутся uCOS, например. Хотя и там все не совсем радужно местами. Универсальные ОС == тормозные, но они хороши для академического изучения и там, где юзеру вполне хватает.

P.S. Именно поэтому я из средств ОС пользуюсь малой частью того, что там наделали на текущий момент. Семафоры да рекурсивные мьютексы (редко).
Всякие очереди - всегда свои, типа точка-точка, ибо лично мне в разработке мало пригождались широкодоступные (всем задачам) очереди, блокирующие прерывания.
К тому же, очереди типа точка-многоточка (один писатель - много читателей) тоже можно реализовать без запрета прерываний. Все остальные вариации упрощаются применением GetKeeperTask().