реклама на сайте
подробности

 
 
> Программные прерывания разного приоритета
amaora
сообщение Jun 24 2016, 16:02
Сообщение #1


Местный
***

Группа: Участник
Сообщений: 421
Регистрация: 2-01-08
Пользователь №: 33 778



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

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

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

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

МК - stm32f4xx.

Спасибо.
Go to the top of the page
 
+Quote Post
 
Start new topic
Ответов
amaora
сообщение Jun 27 2016, 17:20
Сообщение #2


Местный
***

Группа: Участник
Сообщений: 421
Регистрация: 2-01-08
Пользователь №: 33 778



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

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


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

На стеке хранится значение регистра PSR в котором номер ISR, по которому похоже определяется приоритет прерывания после, например выхода из вложенного. А приоритеты хранятся в регистрах NVIC, может случится нехорошо если после выхода из вложенного прерывания окажется, что приоритет уже другой.
Go to the top of the page
 
+Quote Post
jcxz
сообщение Jun 28 2016, 04:09
Сообщение #3


Гуру
******

Группа: Свой
Сообщений: 5 228
Регистрация: 3-07-08
Из: Омск
Пользователь №: 38 713



Цитата(amaora @ Jun 27 2016, 23:20) *
Если переходит на rtos, то я надолго закопаюсь в переписывание всего кода под нее.
...
Да в документах arm об этом, что-то было. Только подразумевается смена приоритета для прерываний которые возникнут после этой смены. А не смена приоритета того, что выполняется в данный момент.

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

Цитата(amaora @ Jun 27 2016, 23:20) *
На стеке хранится значение регистра PSR в котором номер ISR, по которому похоже определяется приоритет прерывания после, например выхода из вложенного. А приоритеты хранятся в регистрах NVIC, может случится нехорошо если после выхода из вложенного прерывания окажется, что приоритет уже другой.

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

Цитата(GetSmart @ Jun 28 2016, 03:04) *
То есть процессором это значение создаётся, но потом им не читается и ни на что не влияет.

Не может быть. Если более приоритетный ISR (номер N) прервал выполнение менее приоритетного (номер K), то после возврата из ISR N, что CPU должен записать в IPSR? Откуда он это определит? Вот как раз со стека он это считывает и заносит в PSR.
Go to the top of the page
 
+Quote Post
GetSmart
сообщение Jun 28 2016, 15:14
Сообщение #4


.
******

Группа: Участник
Сообщений: 4 005
Регистрация: 3-05-06
Из: Россия
Пользователь №: 16 753



Цитата(jcxz @ Jun 28 2016, 08:09) *
Не может быть. Если более приоритетный ISR (номер N) прервал выполнение менее приоритетного (номер K), то после возврата из ISR N, что CPU должен записать в IPSR? Откуда он это определит? Вот как раз со стека он это считывает и заносит в PSR.

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

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

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


--------------------
Заблуждаться - Ваше законное право :-)
Go to the top of the page
 
+Quote Post

Сообщений в этой теме
- amaora   Программные прерывания разного приоритета   Jun 24 2016, 16:02
- - SII   А почему не сделать нормальные потоки и спокойно н...   Jun 26 2016, 16:35
- - amaora   Этот вариант рассматривается.   Jun 26 2016, 17:43
- - gerber   Выделите 2 свободные ноги (пустые), сконфигурируйт...   Jun 26 2016, 21:48
- - esaulenka   Идея, в принципе, верная - использовать какие-нибу...   Jun 27 2016, 07:52
- - GetSmart   Цитата(amaora @ Jun 24 2016, 20:02) Краси...   Jun 27 2016, 14:37
|- - GetSmart   Цитата(amaora @ Jun 27 2016, 21:20) На ст...   Jun 27 2016, 21:04
|- - jcxz   Цитата(GetSmart @ Jun 28 2016, 21:14) Док...   Jun 29 2016, 03:48
|- - GetSmart   Цитата(jcxz @ Jun 29 2016, 07:48) Обратит...   Jun 29 2016, 11:59
|- - jcxz   Цитата(GetSmart @ Jun 29 2016, 17:59) Вы ...   Jun 30 2016, 08:50
|- - GetSmart   Цитата(jcxz @ Jun 30 2016, 12:50) Это ещё...   Jun 30 2016, 19:06
|- - jcxz   Цитата(GetSmart @ Jul 1 2016, 01:06) Вы е...   Jul 1 2016, 03:22
|- - GetSmart   Цитата(jcxz @ Jul 1 2016, 07:22) Ну раз т...   Jul 1 2016, 08:41
- - ar__systems   У вас простейшая задача с минимальными скоростями,...   Jun 29 2016, 07:02
- - amaora   Еще вопрос. Допустим я решил использовать FreeRTOS...   Jul 1 2016, 14:42


Reply to this topicStart new topic
1 чел. читают эту тему (гостей: 1, скрытых пользователей: 0)
Пользователей: 0

 


RSS Текстовая версия Сейчас: 22nd July 2025 - 16:29
Рейтинг@Mail.ru


Страница сгенерированна за 0.0153 секунд с 7
ELECTRONIX ©2004-2016