Программное прерывание STM32

[Гость Dmitry]

Здравствуйте!
У меня возникла необходимость генерировать программное прерывание, то есть устанавливать некий бит и улетать в обработчик прерываний с приоритетом выше USB и ниже I2S. Не уверен, то ли я нашел, но в STM32F429 есть регистр EXTI_SWIER, устанавливая бит которого в мануале обещают программное прерывание. Пытаюсь его настроить так:

    EXTI->IMR |= EXTI_IMR_MR0;
    NVIC_SetPriority(EXTI0_IRQn, 15);
    NVIC_EnableIRQ(EXTI0_IRQn);
    
    EXTI->SWIER |= EXTI_IMR_MR0;

обработчик прерываний такой:

void EXTI0_IRQHandler (void)
{
    SET(TEST_X);
}

Вроде как, после установки EXTI->SWIER |= EXTI_IMR_MR0 программа должна улететь в обработчик прерывания, но этого не происходит. Подскажите пожалуйста, что я делаю не так?
 

 

[Реклама]

Реклама: ООО ТД Промэлектроника, ИНН: 6659197470, Тел: 8 (800) 1000-321

[Alex]

6 часов назад, Гость Dmitry сказал:

Подскажите пожалуйста, что я делаю не так?

Наверное - мыслите.
Скажите, чем отличается вызов прерывания (то, что Вы хотите сделать), в котором вызывается некая функция от обычного вызова этой же функции ? Да ничем, кроме лишних телодвижений процессора.
Тогда для чего это всё ? 

 

[Реклама]

20% скидка на весь каталог электронных компонентов в ТМ Электроникс!

Акция "Лето ближе - цены ниже", успей сделать выгодные покупки!

Плюс весь апрель действует скидка 10% по промокоду APREL24 + 15% кэшбэк и бесплатная доставка!

Перейти на страницу акции

Реклама: ООО ТМ ЭЛЕКТРОНИКС, ИНН: 7806548420, info@tmelectronics.ru, +7(812)4094849

[Yurkin2015]

Для разрешения software interrupt надо размаскировать бит в Event mask register тоже:

EXTI->EMR |= EXTI_EMR_MR0;

[Реклама]

Выбираем схему BMS для корректной работы литий-железофосфатных (LiFePO4) аккумуляторов

 Обязательным условием долгой и стабильной работы Li-FePO4-аккумуляторов, в том числе и производства EVE Energy, является применение специализированных BMS-микросхем. Литий-железофосфатные АКБ отличаются такими характеристиками, как высокая многократность циклов заряда-разряда, безопасность, возможность быстрой зарядки, устойчивость к буферному режиму работы и приемлемая стоимость. Но для этих АКБ, также как и для других, очень важен контроль процесса заряда и разряда, а специализированных микросхем для этого вида аккумуляторов не так много. Инженеры КОМПЭЛ подготовили список имеющихся микросхем и возможных решений от разных производителей. Подробнее>>

Реклама: АО КОМПЭЛ, ИНН: 7713005406, ОГРН: 1027700032161

[Alex]

Объясните мне глупому, каков таинственный смысл подобных извращений ? Почему бы, вместо программного вызова прерывания, не использовать код, находящийся в прерывании ?
 

[mail_robot]

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

[Гость Dmitry]

Смысл в том, что в обычной функции обработка может быть прервана любым прерыванием. А обработка в программном прерывании абсолютно атомарна, при соответствующем приоритете прерывания, естественно. Но дело не в этом. У меня идет выдача данных на два ЦАП через I2S. Прерывание I2S при этом одно, оно вызывается двумя событияти, по I2S1 и I2S2. При этом каждый отправляемый отсчет нужно посчитать и этот расчет может занимать разное время. И что-то я побаиваюсь, не возникнет ли джиттер в результате...
 То есть получается так: генерируется прерывание I2S1, я сразу отправляю данные и в прерывании начинаю считать следующий отсчет. По идее, пока я считаю может возникнуть прерывание от I2S2 и оно будет ждать, пока я досчитаю отсчет для первого. Я хотел сначала считать отсчеты в основной программе, а не в прерывании, но поэкспериментировав, заметил, что иногда переход из прерывания I2S в основную программу занимает довольно много времени. Я использую FreeRTOS, возможно дело в нем, возможно долго обрабатывается прерывание USB, не знаю точно. А переход из прерывания I2S в программное занимает 360 наносекунд.

[mail_robot]

а на время вызова этой функции разве нельзя запретить "лишние" аппаратные прерывания?

[Гость Dmitry]

Можно, но это все равно будет долго. STM32 из прерывания в прерывание за 6 тактов прыгает, а из прерывания в main за 12. Но это ерунда, плюс к этому ведь еще и переключение контекста FreeRTOS происходит.

[Alex]

Почему это будет долго ? Запретили необходимые прерывания, выполнили код, разрешили прерывания. Запрет/разрешение долго ? Дольше чем аппаратная обработка прерывания ?

Сдаётся мне, Вы запутались где-то. Ещё и RTOS сюда приплели зачем то...
 

[Гость Dmitry]

Почему приплел, я же RTOS никуда не дену. Вариантов работы два:

1) Отправляю данные по I2S, вызываю программное прерывание, там считаю следующий отсчет. Затраты времени на переход из одного прерывания в другое - 6 тактов.

2) Отправляю данные по I2S, считаю следующий отсчет в задаче RTOS. Затраты времени - 12 тактов на переход из прерывания в задачу плюс раз в миллисекунду вызывается планировщик задач RTOS, сколько времени это занимает не знаю, но думаю, что много. Или Вы предлагаете и это прерывание запретить? Это как минимум вырубит работу RTOS, что нехорошо.

[Alex]

Мы с Вами разговариваем на разных языках. Я в голову Вшу не залезу и программу Вашу не знаю. I2S, RTOS, USB, .... 
Вы задали вопрос по программному вызову прерывания, Вам сказали, что смысла в нём нет. А что у Вас там и куда отправляется, для нас - тайна, в которую вникать никто не будет.
 

[mail_robot]

2 часа назад, Гость Dmitry сказал:

из прерывания в прерывание за 6 тактов прыгает

за 6 ли? это просто вызов или со стеком считаете?

2 часа назад, Гость Dmitry сказал:

а из прерывания в main за 12

у вас main нету

2 часа назад, Гость Dmitry сказал:

плюс к этому ведь еще и переключение контекста FreeRTOS происходит.

если вызов будет из потока, то переключения контекста не будет. Задача то еще выполняется

Мыслю так.

5 часов назад, Гость Dmitry сказал:

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

если у вас возникает такая ситуация, то очевидно, что мощности камня не хватает, чтобы загрузить шину. Тут вам не помогут никакие хитрости с прерываниями. ИМХО. В ином случае обсчет очередного кадра можно просто отдать высокоприоритетному потоку, который будет стартовать по семафору из прерывания шины и все обязано успевать. То есть процесс такой:

I2S1 у вас отработало прерывание, в нем вы установили семафор, вышли из прерывания, сразу вызывается поток с максимальным приоритетом и выполняет обсчет, данные готовы и контекст уходит диспетчеру. Поступает прерывание I2S2, процесс повторяется. Если успевать не будет, ищите другой камень или думайте как оптимизировать обсчет. В RTOS 8 диспетчер вызывается гораздо чаще, чем раз в милисекунду, он детерминирован. Но максимальное время - квант. Поэтому к кванту можно не привязываться. А то что вы сэкономите на времени вызовов и так далее это семечки. Лучше поискать ресурсы в другом месте

Изменено 3 октября, 2016 пользователем mail_robot

[Гость Dmitry]

Я Вас понял, наверно Вы правы. Вызов задачи через семафор идет сразу, без переключения контекста, но прерывание USB таки придется на время расчета запретить, на всякий случай.

[Гость Dmitry]

Хотя нет, погодите, Systick же считает независимо от всего остального. То есть, например, вызову я задачу через семафор, начнет считаться следующий отсчет для I2S, а тут опа и пришло время на переключение контекста - вызовется планировщик, который посмотрит надо ли вызывать другую задачу, я другие заблокирую - то есть время он отъест, а работа его будет равна нулю.

[mail_robot]

делайте как хотите

[Alex Orlovecky]

Внезапно так же появилась нужда в программном прерывании..
Суть такова:
Блок телеметрии, который работает в режиме сна, прерывания сон пробуждают и только в них он и работает. После отработки прерывания, возвращается опять спать..

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

Сама функция в принципе не затратна по ресурсам: передаётся адрес и размер контроллеру дма (это аудио без кодеков). Но в начале нужно опустить некий флаг готовности в самой функции, по окончанию поднять этот же флаг, но уже в обработчике ДМА.  Если в начале флаг опущен, функция ждёт поднятия флага шагами по 100мс. 

Можно было выкинуть этот флаг и запускать функцию с того место где она потребуется, но тогда потребуется много памяти под сами аудио дорожки.
А так, записываем только отдельные слова, и в "неком контроллере целых фраз/ предложений"   вызываем поочерёдно нужные записи слов. К примеру:   
проиграть(напряжение);
проиграть(критично);

В другом участке может быть:
проиграть(напряжение);
проиграть(50);
проиграть(процентов);

[ruhi]

06.10.2016 в 11:49, Гость Dmitry сказал:

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

Вот и получается что вы пытаетесь решать какие то свои задачи, а у вас есть планировщик которому на эти ваши задачи начихать, он делает то что ему надо и когда ЕМУ надо. Зачем вам ОС уровня приложений когда вы на уровне драйверов работаете??? Выкинте нафик вашу РТОС и все станет на свои места. Кстати планировщик обычно сидит в прерывании какого то таймера, и что у вас с этим прерыванием?

Изменено 20 декабря, 2020 пользователем ruhi

[ruhi]

19.12.2020 в 11:52, Alex Orlovecky сказал:

Но в начале нужно опустить некий флаг готовности в самой функции, по окончанию поднять этот же флаг, но уже в обработчике ДМА.  Если в начале флаг опущен, функция ждёт поднятия флага шагами по 100мс.

Обработчик ДМА это прерывание? А почему флаг нельзя поднять в другом месте, и не поднимать его при каком то условии?  И что, оно засыпает по этому флагу? ...

Вы бы сначала разобрались с логикой работы вашей системы, может и вопросы не пришлось бы задавать!