Прерывание в прерывании, Для реализации Super Simple Tasker Опции

[arhiv6]

Super Simple Tasker - один из вариантов реализации вытесняющей многозадачности для микроконтроллеров. Как в нём работает асинхронное переключение на более приоритетные задачи написано в статье под рисунком 3. Для реализации SST нужна такая вещь: в функции-обработчике прерывания, после выполнения необходимого кода, нужно как-то сообщить микроконтроллеру, что с прерыванием закончили работать но из функции-обработчика не выходить. Т.е. нужно разрешить вложенные прерывания (одни и те же).

В статье в примере для ПК это делается так: используется команда End Of Interrupt (EOI) - outportb(0x20, 0x20). Обычно она выполняется непосредственно перед выходом из функции-обработчика прерывания, но в SST после EOI вызывается диспетчер, прямо в контексте прерывания. Т.е. вызвав EOI, но оставаясь в контексте прерывания, мы разрешаем вложенные прерывания. Как это можно сделать для ARM (Cortex)?

[DASM]

"прихожу лишь к одному выводу " - приходите
", обычно хватает 128....256 байтов"- просто у вас " в реально примитивных проектах"
Вы лучше скажите, каким образом вы доказываете, что данная задача никогда не превысит отведенный стек, при условии, что если такое возникнет - аппарат под контролем процессора с вашим замечательным ртос со стеком задачи 128 байт отрежет например рабочему руку.
" "толстые" МК с 256 кб" вы серьезно считаете, что это толсто? Это копейки с нынешними стеками и протоколами, стек BLE один сожрет 300 кб флеша, порядка 100 к ОЗУ, а к нему еще Thread прикуртить надо, оный тоже 250 кбайт и ОЗУ немерянно.
Очень интересно глянуть вашу "сурьезную задачу" с 128 байт ОЗУ

[Forger]

"прихожу лишь к одному выводу " - приходите
", обычно хватает 128....256 байтов"- просто у вас " в реально примитивных проектах"

Я не кладу в стек гигантские структуры, а стараюсь их использовать статически. Динамическую память не использую.
Там, где это нужно, память выделяю пулами (фиксированными кусками).

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

Это делается средствами RTOS, разумеется, соотв. аварийные ситуации обрабатываются. Перед запуском проекта, он долгое время отрабатывается под systemview, где видно, кто и сколько чего кушает.
Это позволяет подстроить стеки более тонко (если нужно).
Используются ГОТОВЫЕ решения. Это работает и переполнения стека отлично отлавливаются (при тестировании это проверяю - занижаю размеры стеков и контролирую работу кода в таких условиях).

" "толстые" МК с 256 кб" вы серьезно считаете, что это толсто?

Для любой примитивной RTOS (та же freeRTOS -одна из них) эти ТТХ контроллера вполне толстые. Речь об этом.

Это копейки с нынешними стеками и протоколами, стек BLE один сожрет 300 кб флеша, порядка 100 к ОЗУ, а к нему еще Thread прикуртить надо, оный тоже 250 кбайт и ОЗУ немерянно.

Речь не про это, речь про совсем про другое - гипотетическую экономию на абсолютно ровном месте.
В конце-концов, существует cmsisOS, даже cmsisOS-II, стандарт. Но нет же, ведь всегда найдутся энтузиасты, которым нужно "изобрести велосипед с квадратными колесами" и пытаться на нем ехать, делая вид, что это нормально

Очень интересно глянуть вашу "сурьезную задачу" с 128 байт ОЗУ

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