Запуск процесса на одном уровне прерывания, из разных уровней прерываний Опции

[Hexel]

Добрый день!

Ув. коллеги, подскажите пожалуста, как вызывая подпрограмму из разных уровней прерываний, обеспечить ее завершение таким образом, чтобы она не была прервана из более высокого приоритета? Речь идет об диспетчере событий (собственная терминология =), который фильтрует события из разных модулей и сохраняет отчет в EEPROM. Разрыв в неподходящий момент непременно приведет к порчи лога, и заметить это будет сложно.
Например, чтобы при вызове такая процедура работала на самом высоком уровне. Я полистал документацию по АРМ, но даже не знаю, где копать. Отключать прерывания нахрен до завершения - топорно, но должно работать) По-моему, еще такой функционал реализует RTOS, но опять же я в этом новичок. Какие есть варианты?

Проц STM32F334

[jcxz]

Какие есть варианты?

Записать сообщение (которое нужно сохранить в EEPROM) в некую структуру в памяти и вызвать процесс записи в EEPROM, который выгребет сообщение из этой структуры и запишет куда надо. Процесс записи - это или задача ОС или ISR - без разницы.

[Hexel]

Вот как раз что меня беспокоит: в процессе формирования сообщения может сработать прерывание. можно в первых строках процедуры запомнить текущий индекс StackTop и сразу его инкрементировать. тогда в локальном контексте разрыв уже не повлияет на работу, т. к. место в логе уже будет зарезервировано, а всю необходимую информацию для сообщения передать аргументами, ее на самом деле не так много. Весь лог будет держаться в оперативе, а сохранение в EEP может происходить не прямо сразу.
А через ISR - это как? кажется, я все-таки плохо представляю механизм прерываний.

[adnega]

А через ISR - это как? кажется, я все-таки плохо представляю механизм прерываний.

Через прерывание может получится асинхронно, т.е. флажок взвели, а перед обработчиком может выполниться еще несколько инструкций.
Можно через SVCall, тогда все будет синхронно.

Про SVC подробно написано в "Joseph Yiu. The Definitive Guide to ARM Cortex-M3 and Cortex-M4 Processors" раздел "10.3 SVC exception".

[Serge V Iz]

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

[adnega]

С той разницей, что "топорный" запрет прерываний не требует сбросов конвейера, переключений контекста и прочих всяких времязатратных вещей )

Работа с EEPROM довольно затратная по времени операция. Лишать систему прерываний на это время довольно опасно.
Я бы через SVC сделал доступ к очереди (быстрая часть), а в mainloop сделал бы вычитывание из очереди и запись в EEPROM.

[Serge V Iz]

Ну, я тоже надеюсь, что под атомарной операцией понимается только упихивпние очередной непременно целостной пачки данных в какой-то буфер в ОЗУ. )

[jcxz]

Я бы через SVC сделал доступ к очереди (быстрая часть), а в mainloop сделал бы вычитывание из очереди и запись в EEPROM.

А SVC то тут зачем?
Если нужно чтобы сообщения, кидаемые разными отправителями (ISR разных приоритетов), не терялись и писались все, делаем очередь с атомарной записью. Ну или несколько очередей (на выбор). Пишем сообщение туда. Потом возбуждаем (программно) какое-нить прерывание (записью в соответствующий регистр NVIC), в ISR которого считываем сообщения из этой очереди (очередей) и пишем их куда надо. Считываем и пишем пока очереди не опустошатся. Опустошились - выходим из ISR.
Вместо ISR в данном алгоритме можно использовать задачу ОС с каким-нить объектом синхронизации ОС (мэйлбокс, семафор, etc.).

[adnega]

А SVC то тут зачем?

Для простоты реализации атомарности.

[jcxz]

чем оно проще запрета прерываний?

[adnega]

чем оно проще запрета прерываний?

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

[jcxz]

Тем, что в системе могут оставаться высокоприоритетные прерывания.

У SVC вроде как наивысший приоритет. Выше чем у любого асинхронного прерывания. Разве что исключая NMI наверное. Так на NMI запрет прерываний и не влияет.
Да, и если уж так страшен запрет прерываний, то очереди можно и вообще без запрета прерываний организовать.

[Hexel]

Должен признать, что SVC - не совсем то, что я бы применил для данной задачи. Получается слишком сложно, но это именно то, что я хотел прояснить. Итого процедура логирования выходит строк на 10, так что запрет прерываний мне кажется, оптимальное решение. Ну и выгрузка в EEP конечно будет происходить где-то ближе к мейну, или низкоприоритетному таймеру.
Спасибо за советы! Ну и книжка многое прояснила

[SII]

У SVC вроде как наивысший приоритет. Выше чем у любого асинхронного прерывания. Разве что исключая NMI наверное.

Приоритет SVC, как и почти все остальные, настраивается. Но, если его приоритет не самый высокий (HardFault и NMI выше, но при нормальной работе они, как правило, не возникают, и, скорей всего, их можно не учитывать), на входе в обработчик регистры могут быть изменены: если одновременно с выполнением команды SVC появилось более приоритетное прерывание, вход будет выполнен в обработчик последнего, и именно в этот момент регистры будут сохранены в стеке. При возврате из высокоприоритетного обработчика произойдёт переход в ожидающий обработчик более низкого приоритета -- в SVC, при этом регистры из стека не восстанавливаются и повторно не сохраняются, а соответственно, имеют те значения, что в них находились на момент завершения обработчика высокоприоритетного прерывания.

Итого процедура логирования выходит строк на 10, так что запрет прерываний мне кажется, оптимальное решение. Ну и выгрузка в EEP конечно будет происходить где-то ближе к мейну, или низкоприоритетному таймеру.

Дело не в числе строк, а во времени их выполнения: если там ожидание завершения записи в EEPROM, оно может оказаться очень большим.

[Forger]

Отключать прерывания нахрен до завершения - топорно, но должно работать)

В STM запись в EEPROM и так приостанавливает работу выполнение кода на аппаратном уровне. Так что критические секции будут бесполезны.

When the code is executing from the Flash program memory, the instruction must be read
from it, this is not possible during a write operation on any memory block of the same bank.
In such case the program execution stalls during the EEPROM data write.
Stalling happens at the Busmatrix interconnection and blocks the data recipient until the
data is available.
The stall does not disrupt the sequence of operation. What happens is that the CPU core
keeps waiting for the instruction fetch. Also, the stall only affects the CPU core. Processes
independent from the core, such as DMA or peripherals may continue to work as long as
they avoid accessing the NVM bank.

Подробности как решить вашу задачу см. тут: AN4808.