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

[arhiv6]

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

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

[DASM]

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

[jcxz]

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

А в чём разница между стеком задачи под ОС и стеком той же самой задачи без ОС? У Вас, что ОС сама ваш код компилирует? Или может даже пишет?

Потоки и жрут.

Что за злобные такие "потоки", лазящие по Вашим исходникам и жрущие память??? Жутко даже становится...

[DASM]

А в чём разница между стеком задачи под ОС и стеком той же самой задачи без ОС? У Вас, что ОС сама ваш код компилирует? Или может даже пишет?

Тем, что без ОС такой - стек общий, и памяти не хватит тогда, когда ее не хватит вообще. А с потоками вытесняющими - это как коробка конфет , места много займет, а конфет мало, в отличии от единого стека. Второй пример фрагментации памяти с malloc - памяти до хрена, а получаем NULL - ибо впихнуть нужный кусок некуда. Я надеюсь вы уже решили эту проблему сборщиками мусора на микроконтроллерах? Короче не стоит далее спорить, все останутся при своих это очевидно. Меня недетерминированность поведения таких РТОС во многих задачах не устраивает, расход памяти тоже


"другого класса, скорее всего платной RTOS. " - то есть все бесплатное - это дерьмо по умолчанию? Странная мысль.

[jcxz]

Тем, что без ОС такой - стек общий, и памяти не хватит тогда, когда ее не хватит вообще. А с потоками вытесняющими - это как коробка конфет ,

"Без ОС" - это значит всё в одной задаче. Если вы, не меняя алгоритма, перенесёте эту задачу в одну из задач (потоков) РТОС, что что изменится с потреблением стека? Ничего!
Так в чём разница???
Далее - конечно под РТОС вы потом можете эту же задачу реализовать в виде многих потоков РТОС. Это разве будет тем же самым алгоритмом? Нет конечно, это новая реализация, совершенно по другому написанная. И да, если писать не включая голову, можно сколько угодно памяти израсходовать.
Так в чём преимущество "без РТОС" по-вашему, в том что в таком случае заведомо меньше возможностей и криворукий программист сделает меньше багов? Не уверен что это преимущество....

места много займет, а конфет мало, в отличии от единого стека.

Так если задачу можно реализовать в виде одного потока ОС, то зачем его делить на несколько?
Или всё-таки нельзя (или будет заведомо худшее решение), то очевидно тогда что с РТОС - лучше? Разве не?

Второй пример фрагментации памяти с malloc

"Смешались в кучу люди кони"... динамическая память-то тут причём??? Разговор про стеки вроде шёл. Нафига стеки в дин. память пихать??? Да ещё выделять/освобождать периодически.
Какие-то нереальные примеры выдумываете....
PS: За последние ~15 лет в отрасли и десятках реализованных проектов, я ни разу ещё не использовал malloc() в embedded-проектах. Что делаю не так?