[DASM 0]

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

[jcxz 184]

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

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

 

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

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

[Forger 17]

"прихожу лишь к одному выводу " - приходите

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

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

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

 

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

Это делается средствами RTOS, разумеется, соотв. аварийные ситуации обрабатываются. Перед запуском проекта, он долгое время отрабатывается под systemview, где видно, кто и сколько чего кушает.

Это позволяет подстроить стеки более тонко (если нужно).

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

 

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

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

 

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

Речь не про это, речь про совсем про другое - гипотетическую экономию на абсолютно ровном месте.

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

 

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

Мы сейчас говорим про проекты для бытовых МК, а не толстых CPU с мб флэши и озу.

Второй случай требует RTOS другого класса, скорее всего платной RTOS.

Здесь же речь про простые вещи, где экономия на спичках выглядит очень и очень странно - вместо простой готовой RTOS колхозить некий самодельный костыльный SST ...

Вот мне лично совсем не ясна реальная мотивация подобной задумки.... Пытаюсь разобраться, может быть что-то упускаю )))

[DASM 0]

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

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

 

 

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

[Forger 17]

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

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

Каждая задача требует своего инструмента. А всякая попытка недооценивать и хаять готовые инструменты выставляет их автора в не самом лучшем свете ... по крайней мере перед теми, кто успешно использует эти инструменты ;)

Точно так же очень странно выглядит попытка пилить вековую сосну лобзиком под фанеру ....

 

 

 

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

Видать, первые попытки применения RTOS в лоб оказались для вас негативными...

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

 

Второй пример фрагментации памяти с malloc - памяти до хрена, а получаем NULL - ибо впихнуть нужный кусок некуда.

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

 

Я надеюсь вы уже решили эту проблему сборщиками мусора на микроконтроллерах? ;)

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

 

Меня недетерминированность поведения таких РТОС во многих задачах не устраивает

Все верно! Криво спроектированный код именно так себя и ведет :1111493779:

А RTOS тут совсем ни при чем ))

 

[DASM 0]

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

" Криво спроектированный именно так себя и ведет. RTOS тут ни при чем ))))" ртос тут вообщем непричем, давайте MMU, нет памяти - page fault - выделяем, едем дальше. А без MMU - "если заняться нечем" (с)

[Forger 17]

Ваши РТОС далеко не панацея... если мы посмотрим профессиональные проекты, нет статистики ...

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

 

Просто не стоит, изучив и используя что-то одно говорить, что сие есть истина, а остальным нечем заняться

Мне стало интересно, что такого вносит этот SST по сравнению с готовыми решениями, в частности с RTOS.

Оказалось, что он приносит лишь головную боль, причем, на ровном месте: без нужды усложняет структуру кода, от суперлупа со всеми его костылями в целом ничем не отличается.

(С) "Те же яйца, только в профиль."

Вот и пытаюсь увидеть мотивацию ... пока не увидел... Любопытно все же, что заставляет народ изобретать велосипеды с квадратными колесами :laughing:

[jcxz 184]

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

"Без ОС" - это значит всё в одной задаче. Если вы, не меняя алгоритма, перенесёте эту задачу в одну из задач (потоков) РТОС, что что изменится с потреблением стека? Ничего!

Так в чём разница???

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

Так в чём преимущество "без РТОС" по-вашему, в том что в таком случае заведомо меньше возможностей и криворукий программист сделает меньше багов? Не уверен что это преимущество....

 

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

Так если задачу можно реализовать в виде одного потока ОС, то зачем его делить на несколько?

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

 

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

"Смешались в кучу люди кони"... динамическая память-то тут причём??? Разговор про стеки вроде шёл. Нафига стеки в дин. память пихать??? Да ещё выделять/освобождать периодически.

Какие-то нереальные примеры выдумываете....

PS: За последние ~15 лет в отрасли и десятках реализованных проектов, я ни разу ещё не использовал malloc() в embedded-проектах. Что делаю не так? :blink:

[arhiv6 14]

Здесь была тема про SST. Посмотрите там, может, там есть ответ.

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

 

Я отказался от FreeRTOS, 256 К памяти не хочу транжирить, SST "х расходы стековой памяти по сравнению с традиционными операционными системами сокращается на 80%."

. Так что насчет "нечем заняться" не стоит огульно, SST прекрасно ложится на мелкие 1M/256K контроллеры, на средние (16G/1G) полноценный Линукс проще. Места классическим RTOS я лично не вижу

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

 

PS: При задавании подобных вопросов, очень уместно указывать ядро о котором спрашивается. Ибо реализация очень сильно зависит от этого самого ядра.

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

 

Гугл вводит на гитхаб. Возможно, всё украдено до нас?

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

 

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

[jcxz 184]

но навскидку 70-80 процентов используют либо суперлюп

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

 

Мне стало интересно, что такого вносит этот SST по сравнению с готовыми решениями, в частности с RTOS.

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

Поэтому и совет ему: сразу идти и посмотреть как это сделано в какой-нить РТОС. Чтобы попусту время не терять.

 

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

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

 

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

Ну наконец-то! Cortex-M всё-таки.

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

[Forger 17]

Чтобы попусту время не терять.

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

[jcxz 184]

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

Не верю!

Если бы Вы реально с ней работали, то знали бы как в ней переключается контекст. И не спрашивали бы.

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

 

Похоже, это - совсем не тот случай ;)

Человек пишет, что работает с системой, но не знает как она работает.

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

[arhiv6 14]

Смотрел я исходники ОС, но они все по похожему принципу сделаны - переключение между разными стеками. Вот например: для каждого потока выделен свой стек. Для переключения между двумя контекстами вызывается прерывание 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?

[Forger 17]

Наверное потому что круглые"

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

по методике SST

[arhiv6 14]

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

 

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