Я немного преувеличил для ясности. Эти РТОС замечательны для обучения студентов имхо, только вот в реальной аппаратуре, с более ответсвенными целями чем очередной вебсервер - очень неуверен. MMU нет, MPU ни о чем, процы просто не предназначены под многозадочность, а то, что есть - костыли

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


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

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


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

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


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

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

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


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

По-вашему выходит, что ручная ножовка по дереву годится только для обучения и пару тонких дощечек для полочки под цветы всякий нужно раз пилить мощной бензопилой .... Хм, необычный подход, кардинальный :D
Каждая задача требует своего инструмента. А всякая попытка недооценивать и хаять готовые инструменты выставляет их автора в не самом лучшем свете ... по крайней мере перед теми, кто успешно использует эти инструменты
Точно так же очень странно выглядит попытка пилить вековую сосну лобзиком под фанеру ....




Видать, первые попытки применения RTOS в лоб оказались для вас негативными...
Однако, остальным почему-то повезло больше Может быть дело не в "инструменте" вовсе, а в "слесаре", который пытался его использовать не очень удачно


Сходу на тракторе да в соседский забор ... с дин. памятью в МК нужно быть аккуратнее. Это во всех книжках написано ))

Удивитесь, но да - проблема решена: не использовать дин. память в каждой дырке, или вообще не использовать. Это не так сложно, как кажется ))

Все верно! Криво спроектированный код именно так себя и ведет
А RTOS тут совсем ни при чем ))

Да никто не хает, каждый до..ит как хочет. Просто Вы так огульно говорите вопрошавшему "занять вам нечем" что именно это и вам выставляет в таком свете. Ваши РТОС далеко не панацея. Мало того, если мы посмотрим профессиональные проекты, нет статистики, но навскидку 70-80 процентов используют либо суперлюп, либо свой простенький кооператив. Нужели мозгов им не хватило? Не думаю. Можем дальше спорить , но зачем? Вот например С - зачем на нем писать, у нас же аж 256 кбайт памяти! Язык устарел, примитивен, от асма ушел недалеко . Ну и так далее. Просто не стоит, изучив и используя что-то одно говорить, что сие есть истина, а остальным нечем заняться
" Криво спроектированный именно так себя и ведет. RTOS тут ни при чем ))))" ртос тут вообщем непричем, давайте MMU, нет памяти - page fault - выделяем, едем дальше. А без MMU - "если заняться нечем" (с)

Ну, хорошо, хорошо, слив защитан Проехали ))


Мне стало интересно, что такого вносит этот SST по сравнению с готовыми решениями, в частности с RTOS.
Оказалось, что он приносит лишь головную боль, причем, на ровном месте: без нужды усложняет структуру кода, от суперлупа со всеми его костылями в целом ничем не отличается.
(С) "Те же яйца, только в профиль."
Вот и пытаюсь увидеть мотивацию ... пока не увидел... Любопытно все же, что заставляет народ изобретать велосипеды с квадратными колесами

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


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


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

Да, тоже вспомнил про эту тему, перечитываю. Но, насколько я помню, копкретной реализации переключения контекстов для SST там нет.


О, Вы на практике используете SST? А под какие процессоры?


Как указано в первом посте - ARM, Cortex. Пусть будет STM32F030 (Cortex-M0).


Видел. Но насколько я понял, там использую один обработчик прерывания PendSV (без его вложенного вызова), и можно реализовать всего 2 уровня приоритетов - idle в основном цикле в main + все остальные задачи в контексте PendSV_Handler. Они будут выполняться синхронно, в порядке приоритетов. А в SST из статьи более приоритетные задачи могут асинхронно прерывать менее приоритетные.

Пожалуйста, не нужно писать про FreeRTOS и KEIL RTX. Это отличные системы, с первой работал (и работаю), но в этом топике речь идёт о реализации SST.

90% железных "программистов" используют ардуйню. Предлагаете на них равняться и бросать наши кортексы/DSP?


Когда автор наконец-то реализует свой SST (если конечно реализует , он с удивлением обнаружит, что у него получился шедулер обычной РТОС.
Поэтому и совет ему: сразу идти и посмотреть как это сделано в какой-нить РТОС. Чтобы попусту время не терять.


Возьмите порт под нужное ядро любой РТОС и посмотрите на "конкретную реализацию".


Ну наконец-то! Cortex-M всё-таки.
На первой странице указано "ARM, Cortex". И всё. А среди них есть как Cortex-M, так и Cortex-A. И др. И да будет Вам известно, что система прерываний у них устроена совершенно по разному.

Не тот случай ...

Не верю!
Если бы Вы реально с ней работали, то знали бы как в ней переключается контекст. И не спрашивали бы.
И другого, лучшего метода переключения Вам не придумать. Ибо используется именно тот метод, который был заложен специально для РТОС при проектировании ядра.


Человек пишет, что работает с системой, но не знает как она работает.
Это то же самое, если-б водитель самосвала написал, что он работает на самосвале, но не знает от чего у него колёса крутятся. "Вот залазю туда и колёса начинают крутиться, кто его знает от чего они крутятся. Наверное потому что круглые"

Смотрел я исходники ОС, но они все по похожему принципу сделаны - переключение между разными стеками. Вот например: для каждого потока выделен свой стек. Для переключения между двумя контекстами вызывается прерывание PendSV (при этом на стек складываются R0-R3) и в PendSV_Handler сохраняются оставшиеся регистры (R4-R11), потом вызывается функция os_context_switch_hook, которая возвращает указатель на стек другой задачи. С этого стека восстанавливаем (R11-R4) , переписываем LR и выходим из PendSV_Handler, при этом восстанавливаются (R3-R0). Всё, мы переключились на другую задачу/другой стек.

А можете примерно так-же объяснить, что мне сделать для пререключения задач по методике SST?
Выполняем мы задачу А. Так же через вызов прерывания PendSV хотим запустить более приоритетную задачу (запустить функцию). Попали в PendSV_Handler, сохранили (R4-R11) на текущем стеке. Всё, контекст задачи A сохранён. Как теперь правильно запустить задачу В? Сделать просто вызов LDR R1, =taskB, BLX R1 нельзя - функция будет выполняться в контексте прерывания. Как правильно сделать? Из прерывания если выйдем ( BX LR) мы попадём обратно в задачу А. Как мне выйти из прерывания и при этом запустить функцию taskB?

Не тот случай - тут колеса НЕкруглые, сделаны

jcxz, Forger, я не знаю, как правильно сделать, поэтому и спрашиваю совета на форуме. Вы подсказать можете? Или Вы сами тоже не знаете, но хоть что-нибудь написать так и чешется (например, шутку про колёса)?

DASM, а можете рассказать, как у Вас реализовано? И под какой микроконтроллер?