Программные прерывания разного приоритета Опции

[amaora]

Один из таймеров задает базовую частоту, в его обработчике прерывания запускается опрос датчиков и забираются результаты предыдущего опроса. Надо обрабатывать данные одновременно на разных частотах. Для примера конкретные числа, приходит 400 Гц, в первом же обработчике все преобразуется к 100 Гц, далее обработка на 100 Гц. Одновременно с этим 100 Гц преобразуются в 10 Гц и обрабатываются вторым способом, формируются поправки, которые идут на входы первой процедуры обработки.

То есть на временной диаграмме будет долгая работа 10 Гц процедуры, которую несколько раз прерывает 100 Гц процедура, и в 4 раза чаще прерывание для чтения измерений датчиков, которое перебивает всех но занимает мало времени.

Как это сделать на прерываниях? Из первого каждые 4 такта можно запускать второе прерывание с меньшим приоритетом. А из второго каждые 10 тактов третье с еще меньшим приоритетом. Но где взять программные прерывания? Занять неиспользуемые IRQ? Красивее вариантов нет?

Можно было бы обойтись одним прерыванием, если было бы можно разрешить одному IRQ вытеснять самого себя, менять приоритет исполняемого в данный момент прерывания. Но почитав внимательнее про регистр BASEPRI я понял, что так не получится.

МК - stm32f4xx.

Спасибо.

[amaora]

Если переходит на rtos, то я надолго закопаюсь в переписывание всего кода под нее. Наловлю проблем с синхронизацией потоков. Это останавливает. Хотя код во многих прикладных местах может стать более простым, но для этого надо будет отладить сложный низкоуровневый код.

PS вроде б можно крутить приоритет текущего прерывания. Надо б внимательно прочитать, в какой момент оно в контроллере прерываний сравнивается. Но зачем подкладывать себе же такие очевидные грабли?!

Да в документах arm об этом, что-то было. Только подразумевается смена приоритета для прерываний которые возникнут после этой смены. А не смена приоритета того, что выполняется в данный момент.

На стеке хранится значение регистра PSR в котором номер ISR, по которому похоже определяется приоритет прерывания после, например выхода из вложенного. А приоритеты хранятся в регистрах NVIC, может случится нехорошо если после выхода из вложенного прерывания окажется, что приоритет уже другой.

[jcxz]

Если переходит на rtos, то я надолго закопаюсь в переписывание всего кода под нее.
...
Да в документах arm об этом, что-то было. Только подразумевается смена приоритета для прерываний которые возникнут после этой смены. А не смена приоритета того, что выполняется в данный момент.

Берёте любой неиспользуемый в программе вектор аппаратного прерывания и используете его (возбуждаете это прерывание программно).
Никаких изменений приоритета на ходу делать конечно не надо. Если нужно чтобы управление попало в этот, программно возбуждаемый вектор, после завершения инициировавшего прерывания, то его приоритет делаете ниже чем у инициировавшего прерывания. Лучше даже ниже чем у любого настоящего аппаратного прерывания. Получается что-то типа задачи ОС, получающей управление по событию в инициирующем ISR.
Делал так не раз в разных проектах (и в давно работающих) на разных МК, там где и ОС при этом работает - всё прекрасно работает без проблем. Да и почему не должно работать?

На стеке хранится значение регистра PSR в котором номер ISR, по которому похоже определяется приоритет прерывания после, например выхода из вложенного. А приоритеты хранятся в регистрах NVIC, может случится нехорошо если после выхода из вложенного прерывания окажется, что приоритет уже другой.

На стеке сохраняется предыдущее значение PSR (и поле IPSR его в том числе) сохранённое при стэкинге. При выходе из прерывания оно будет просто восстановлено в PSR.
Текущее содержимое IPSR имхо просто маскирует содержмое регистра запросов NVIC (маскируются все прерывания с приоритетом ниже указанного в IPSR).

То есть процессором это значение создаётся, но потом им не читается и ни на что не влияет.

Не может быть. Если более приоритетный ISR (номер N) прервал выполнение менее приоритетного (номер K), то после возврата из ISR N, что CPU должен записать в IPSR? Откуда он это определит? Вот как раз со стека он это считывает и заносит в PSR.

[GetSmart]

Не может быть. Если более приоритетный ISR (номер N) прервал выполнение менее приоритетного (номер K), то после возврата из ISR N, что CPU должен записать в IPSR? Откуда он это определит? Вот как раз со стека он это считывает и заносит в PSR.

Документальные подтверждения где?
На уровне предположений - может. Как говорится мухи отдельно, котлеты отдельно. Номера векторов могут "гулять" по стеку и IPSR. А приоритеты этих активированных векторов могут жить своей (невидимой программисту) жизнью внутри NVIC. При этом можно в стеке эти номера менять (сбивать), оттуда значение грузится в IPSR, а на котлеты (приоритеты принятых прерываний/исключений) это не повлияет.

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

Сообщение отредактировал GetSmart - Jun 28 2016, 17:06

[jcxz]

Документальные подтверждения где?

Вам письмо за подписью директора ARM нужно?

При этом можно в стеке эти номера менять (сбивать), оттуда значение грузится в IPSR, а на котлеты (приоритеты принятых прерываний/исключений) это не повлияет.

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

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

Открываете описание ядра с http://www.arm.com, читаете про регистр IPSR и про регистр Interrupt Control State Register (в числе регистров NVIC), в котором есть поле VECTACTIVE.
Пишете простейший код, в котором изнутри одного ISR вызываете другой, более приоритетный.
Трассируете:
вход в первый ISR - содержимое IPSR и VECTACTIVE - совпадают (например ==0x24);
вход во второй ISR (вложенный) - содержимое IPSR и VECTACTIVE - совпадают (например ==0x0B); в стеке содержимое IPSR из первого ISR (0x24), LR=0xFFFFFFF1;
меняете на стеке содержимое IPSR на какое-либо другое (например ==0x25);
выполняете BX LR и убеждаетесь, что теперь IPSR и VECTACTIVE становятся раными значению, записанному Вами в стек (0x25), а не тому значению, что было в первом ISR (0x24).
Обратите внимание - оба регистра IPSR и VECTACTIVE установились в значение, записанное Вами в стек (0x25), а не в значение из первого ISR (0x24), которое могло быть получено из неких "невидимых программисту" субстанций.