Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: FreeRTOS 9.0 Static
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > FreeRTOS
Boriska
В новой версии FreeRTOS 9.0 появилась возможность выделять память (под задачи/очереди и т.д.) статически.
Подскажите, как определить оптимальный размер памяти под стек задачи? Ну, кроме как ловить vApplicationStackOverflowHook?
Может есть какая-то методика?
x893
Точно так же как и раньше
1. Прописываем стек известным значением (мне нравится DEADBEEF) и потом смотрим
2. Отслеживать указатель стека при вызове функций.
zltigo
QUOTE (x893 @ Nov 7 2016, 15:59) *
Точно так же как и раньше

Ага. Только много неудобнее, ибо динамически выделенная память находится под управления менеджера памяти и соответственно можно добавить того-же владельца памяти и тип блока. В результате чего становится возможным абсолютно независимо от задач смотреть за тем-же использованием стека.
QUOTE
1. Прописываем стек известным значением (мне нравится DEADBEEF) и потом смотрим

А мне CAFEBABE sm.gif - оптимистичнее sm.gif
QUOTE
2. Отслеживать указатель стека при вызове функций.

Отслеживать - да. При вызове каких-то неведомых функций - незачем. У меня всегда есть консолька в ней можно и посмотреть по директиве и распределение памяти (статическое не использую по причине нахренненужности и неудобства - см.выше) и использование стеков.

Boriska
Цитата(x893 @ Nov 7 2016, 15:59) *
2. Отслеживать указатель стека при вызове функций.

Что-то я в этих стеках не очень понимаю. Может подскажите, где можно прочитать?
Что и кто туда пишет? Локальные переменные данной задачи? Значения регистров, при вызове прерываний, во время активности задачи?
jcxz
Цитата(zltigo @ Nov 7 2016, 18:08) *
Ага. Только много неудобнее, ибо динамически выделенная память находится под управления менеджера памяти и соответственно можно добавить того-же владельца памяти и тип блока. В результате чего становится возможным абсолютно независимо от задач смотреть за тем-же использованием стека.

Что же мешает делать то же самое при статически выделенных стеках?

Цитата(zltigo @ Nov 7 2016, 18:08) *
Отслеживать - да. При вызове каких-то неведомых функций - незачем. У меня всегда есть консолька в ней можно и посмотреть по директиве и распределение памяти (статическое не использую по причине нахренненужности и неудобства - см.выше) и использование стеков.

Я динамическое не использую по той же самой причине - нафига оно? Зачем ещё какие-то функции вызывать чтобы распределить этот блок под стек в run-time, когда то же самое прекрасно сделает линкер в build-time?
Стеки задач в процессе работы firmware у меня не меняются (как и сами задачи).
И, например, если в устройстве есть разная память (по скорости/латентности/занятости другими bus-masters), то статически я могу раскидать стеки задач по разным типам памяти, как считаю нужным. А с динамическим выделением что - для каждой памяти свой манагер писать??
x893
Если освоить SystemView, то можно на большом экране красивые диаграммы видеть. Только это надо обычно один раз. Ну или для простоты в Watch окне смотреть сколько осталось до границы стека. В общем 100500 способов есть.
zltigo
QUOTE (jcxz @ Nov 25 2016, 12:00) *
Стеки задач в процессе работы firmware у меня не меняются (как и сами задачи).

Но меняются от релиза к релизу. В результате, в случае чего, возникают интересные вопросы, а как память была распределоена линкером на релизе XX.YY годовой давности стоящем где-то на объекте...
QUOTE
А с динамическим выделением что - для каждой памяти свой манагер писать??

Нет, менеджер один, а блоки памяти, которые он распределяет, могут быть разные. Никаких проблем. Кроме того, менеджер памяти может работать и внутри уже им-же выделенного блока памяти, например, при использовании одинаковых по размеру блоков памяти для гарантированного исключения дефрагментации.


dxp
QUOTE (zltigo @ Nov 25 2016, 18:54) *
Но меняются от релиза к релизу. В результате, в случае чего, возникают интересные вопросы, а как память была распределоена линкером на релизе XX.YY годовой давности стоящем где-то на объекте...

Система управления версиями решает эту проблему за пару секунд. Если я правильно понял контекст вашего ответа. Кстати, как тут поможет динамическое выделение?
zltigo
QUOTE (dxp @ Nov 26 2016, 15:17) *
Система управления версиями решает эту проблему за пару секунд.

Ага, если все это хозяйство есть в нужный момент под руками. По закону подлости приходится разбираться и находясь в самом неподходящем месте, в самое неподходящее время, за тысячи километров, чужими руками.
QUOTE
Если я правильно понял контекст вашего ответа. Кстати, как тут поможет динамическое выделение?

Это уже наличие в консольке директивы позволяющей посмотреть распределение памяти, принадлежность блоков, их занятость и целостность. То есть позволяет иметь встроенный в устройство элемент контроля и отладки.
turnon
Цитата(x893 @ Nov 25 2016, 15:26) *
Если освоить SystemView, то можно на большом экране красивые диаграммы видеть. Только это надо обычно один раз. Ну или для простоты в Watch окне смотреть сколько осталось до границы стека. В общем 100500 способов есть.

Просветите пожалуйста, что за SystemView? И как в Watch окне смотреть сколько осталось до границы стека?
x893
1. Копируем в гуглопоиск SystemView и смотрит первую ссылку.
2. В начале каждой функции делаем функцию которая сохраняет меньшее значение указателя стека из текущего и сохраненного. Конец стека мы и так знаем. В Watch их выбираем и смотрим.
dxp
QUOTE (zltigo @ Nov 26 2016, 23:04) *
Ага, если все это хозяйство есть в нужный момент под руками. По закону подлости приходится разбираться и находясь в самом неподходящем месте, в самое неподходящее время, за тысячи километров, чужими руками.

Слабо представляю себе ситуацию, чтобы выехать на объект с пустыми руками, т.е. без инструментария и проекта. А если есть проект, так там и репозиторий (.git), где вся история в подробностях.

Кроме того, как правило имеется удалённый репозиторий, с которым регулярно делается синхронизация. Есть бесплатные и хорошо развитые и бесплатные сервисы как для открытых (github.com), так и закрытых (bitbucket.com) проектов. Т.ч. всегда можно вытянуть проект, был бы интернет.
haker_fox
А мне тоже нравится динмаическое распределение, чувствуешь какую-то волшебную принадлежность к большим ОС))) Ну, а если серьёзно, то действительно удобно смотреть, что кому отдано и для каких целей)
zltigo
QUOTE (dxp @ Nov 27 2016, 07:17) *
Слабо представляю себе ситуацию, чтобы выехать на объект с пустыми руками, т.е. без инструментария и проекта. А если есть проект, так там и репозиторий (.git), где вся история в подробностях.

Объектов многие тысячи за многие годы. Экземпляров оборудования - миллионы. На объекте есть обслуживающий персонал заказчика, выехать максимум могут сервисные инженеры из ближайшего сервисного центра, но ближайший, это тоже могут быть пару тысяч километров. Ничего из вышеперечисленного у них нет, как и соответствующей квалификации sad.gif. Часть оборудования вообще находится во взрывоопасных и труднодоступных местах (так что ни компьютеров, ни отладчиков там не может быть в принципе).
Таковы реалии. Так что наличие встроенных средств локализации совершенно обязательно.
jcxz
Цитата(zltigo @ Nov 25 2016, 14:54) *
Но меняются от релиза к релизу. В результате, в случае чего, возникают интересные вопросы, а как память была распределоена линкером на релизе XX.YY годовой давности стоящем где-то на объекте...

Узнаём версию firmware "где-то на объекте", скачиваем её исходники из репозитария, компилим, открываем .map и смотрим. В чём проблема?

Цитата(zltigo @ Nov 25 2016, 14:54) *
Нет, менеджер один, а блоки памяти, которые он распределяет, могут быть разные. Никаких проблем. Кроме того, менеджер памяти может работать и внутри уже им-же выделенного блока памяти, например, при использовании одинаковых по размеру блоков памяти для гарантированного исключения дефрагментации.

Для того, чтобы менеджер распределял память из разных блоков, ему надо как-то сообщить: какой блок мы хотим в очередном запросе? Т.е. - очевидно нужно передать какой-то доп. аргумент в функции malloc() или new (что там используется во FreeRTOS?). И как же из вызова xTaskCreate() передать в каком блоке памяти она должна выделить память? Да и наверняка в вызовах менеджера памяти внутре FreeRTOS она запрашивает у malloc()/new только объём памяти и не передаёт никаких доп. аргументов.
Так как же при создании задачи FreeRTOS задать блок памяти в каком она должна выделить стек?

Цитата(zltigo @ Nov 26 2016, 19:04) *
Ага, если все это хозяйство есть в нужный момент под руками. По закону подлости приходится разбираться и находясь в самом неподходящем месте, в самое неподходящее время, за тысячи километров, чужими руками.

Это надуманная проблема.
Я участвовал в разработке многих изделий, которые потом стояли и работали "за тысячи километров" и при возникновении каких-то проблем у этих заказчиков, сам по ним не ездил, а только запрашивал номер версии firmware оттуда и разбирался уже на месте, указанным способом, воссоздавая обстановку у заказчика у себя в лаборатории.

Цитата(x893 @ Nov 26 2016, 23:22) *
2. В начале каждой функции делаем функцию которая сохраняет меньшее значение указателя стека из текущего и сохраненного. Конец стека мы и так знаем. В Watch их выбираем и смотрим.

Видимо Вы никогда не включали оптимизацию. В общем случае, список функций в ПО может не совпадать со списком подпрограмм в скомпилированном коде, так как опитимизатор например сам может убирать или добавлять новые подпрограммы, например когда видит одинаковые участки кода. В таких местах вы не получите реальной вершины стека.
Да и алгоритм действий компилятора, при котором он на входе в функцию один раз делает PUSH/SUBS SP,... а потом больше не трогает SP, это имхо не есть догма.
Не исключаю, что в каких-то случаях или какие-то компиляторы могут в теле функции менять SP. Это во многих случаях было бы полезно.
Да и учтите, что стеков может быть много (при наличии RTOS да и не только).

Так что я предпочитаю другой метод: высокочастотное прерывание, в котором делаем сохранение минимального значения SP для каждой задачи.
zltigo
QUOTE (jcxz @ Nov 28 2016, 12:22) *
Узнаём версию firmware "где-то на объекте", скачиваем её исходники из репозитария, компилим, открываем .map и смотрим. В чём проблема?

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

Да.
QUOTE
Да и наверняка в вызовах менеджера памяти....

Там используется обертка над одним из нескольких "штатных" менеджеров памяти. Я использую свой менеджер, имеющий больше возможностей. Если, вдруг окажется нужным разным задачам выделять тот же стек в разных блоках, добавлю без проблем. Эти дополнения будут ничем не сложнее добавления статического выделения памяти руками в разных секциях и их описание в скриптах линкера. Даже проще.
QUOTE
Это надуманная проблема.

Это вообще НЕ проблема сделать, как я сделал. ОДИН раз много лет назад был создан инструмент идентификации и просмотра блоков памяти. Он работает с тех пор тупо автоматически всегда и вообще нет необходимости придумывать причины его не использовать. Причем, поскольку динамическое выделение памяти используется на только для стеков задач, то этот же инструмент позволяет просматривать и области памяти всяких буферов и очередей.
QUOTE
Я участвовал в разработке многих изделий, которые потом стояли и работали "за тысячи километров" и при возникновении каких-то проблем у этих заказчиков, сам по ним не ездил, а только запрашивал номер версии firmware оттуда и разбирался уже на месте, указанным способом, воссоздавая обстановку у заказчика у себя в лаборатории.

Одна из областей в которой работают мои изделия, это телекоммуникационное оборудование. На объектах оно связано с оборудованием десятков производителей. Причем окружение все время меняется, поскольку сети живут и развиваются. Протоколы взаимодействия весьма сложны и имеют массу реализация, например, SS7 https://ru.wikipedia.org/wiki/ОКС-7. Я очень рад, что "у себя в лаборатории" Вы можете "воссоздать обстановку заказчика" sm.gif.
jcxz
Цитата(zltigo @ Nov 28 2016, 14:13) *
Там используется обертка над одним из нескольких "штатных" менеджеров памяти. Я использую свой менеджер, имеющий больше возможностей. Если, вдруг окажется нужным разным задачам выделять тот же стек в разных блоках, добавлю без проблем. Эти дополнения будут ничем не сложнее добавления статического выделения памяти руками в разных секциях и их описание в скриптах линкера. Даже проще.

Без проблем? Для этого Вам придётся модифицировать код самой FreeRTOS. Например: добавив в список аругментов xTaskCreate() ещё и идентификатор нужной кучи где стек выделять. И пробросить этот идентификатор внутрь xTaskCreate() до вызова Вашего malloc().
Или например передавать этот идентификатор через глобальную переменную, завернув вызов xTaskCreate() вместе с установкой этой переменной внутрь критической секции.
Конечно можно и так сделать. Можно и трусы через голову надевать каждую переменную в куче выделять. Но только - ЗАЧЕМ???
Зачем все эти кучи, malloc()-и и пр. хлам когда задачи создаются однократно (при старте firmware) и, соответственно, стеки выделяются также однократно. И никогда не освобождаются.
Зачем все эти лишние сущности, которые тратят доп. память, увеличивают кол-во кода и время выполнения (хоть и не на много)?
Даже просто посмотреть состояние стека выделенного статически гораздо проще. Для этого не нужно писать никакие свои тулзы, достаточно эмулятора. С динамическим стеком всё много сложнее.

Цитата(zltigo @ Nov 28 2016, 14:13) *
Это вообще НЕ проблема сделать, как я сделал.

Сделать можно всё что угодно, вопрос - зачем?
В программе всегда есть переменные/массивы, время жизни которых - всё время работы ПО. Такие переменные нужно распределять статически (сюда относятся и стеки статических задач).
Можно конечно все такие переменные выделять на куче (и я видел что многие ламеры так и делают на PC). Но зачем??? Никаких плюсов это не даёт, одни минусы.
Всё, что может быть распределено build-time и должно распределяться build-time.
zltigo
QUOTE (jcxz @ Nov 28 2016, 14:20) *
Без проблем? Для этого Вам придётся модифицировать код самой FreeRTOS.

Она и так модифицирована в том числе и под другой менеджер памяти. Многое в ней не устраивало sad.gif, или было недостаточно функционально с самого начала. На уровне 6 версии я вообще перестал следить за основной веткой. Только относительно недавно просмотрел 9 версию и с удовлетворением обнаружил, что подавляющая часть изменений, которая есть у меня и предлагалась Автору, таки появилась в 9 версии. Так что я добавил в 9 версию некоторые изменения (свой менеджер памяти, несколько дополниельных системных вызовов, другой порядок создания idle задачи,...) и у меня теперь большую часть проектов можно собирать с двумя вариантами операционки - "моим" и "почти 9".
QUOTE
Зачем все эти кучи, malloc()-и и пр. хлам когда задачи создаются однократно (при старте firmware) и, соответственно, стеки выделяются также однократно. И никогда не освобождаются.

Это у Вас в Ваших настольных sm.gif системах однократно. У меня есть и задачи, которые порождаются и уничтожаются. Как минимум это одна задача начальной инициализации и диагностики системы.
QUOTE
Зачем все эти лишние сущности, которые тратят доп. память, увеличивают кол-во кода и время выполнения (хоть и не на много)?

"Лишняя сущность" в виде динамического выделения памяти под задачи, конечно, "тратят память" на MCB, но эти затраты сразу с лихвой компенсируются даже уничтожением одной ставшей ненужной задачи типа начальной инициализации.
QUOTE
Даже просто посмотреть состояние стека выделенного статически гораздо проще. Для этого не нужно писать никакие свои тулзы, достаточно эмулятора.

Вы легко "забыли", что смотреть нужно не только в Вас на столе.
QUOTE
С динамическим стеком всё много сложнее.

Много проще, поскольку так или иначе в устройстве есть встроенные отладочные средства для отладки не "на столе" c эмуляторами, симуляторами, отладчиками... Такова моя реальность.
QUOTE
Сделать можно всё что угодно, вопрос - зачем?

Уже многократно объяснял.
QUOTE
В программе всегда есть переменные/массивы, время жизни которых - всё время работы ПО. Такие переменные нужно распределять статически (сюда относятся и стеки статических задач).

О! Появилась мысль, что задачи могут быть не статическими sm.gif. Так что, будете, как Вы тут выражались - "лишние сущности" и тоже менять операционку для создания статических и динамических задач? Вот уж точно лишние сущности, если есть создание динамических задач.
QUOTE
Можно конечно все такие переменные выделять на куче (и я видел что многие ламеры так и делают на PC).

Какие "такие"? Многие буфера и очереди выделяю и динамической памяти. Причины называл выше. Кроме того, MCB создают своеобразные защитные зоны между блоками и нарушение их сигнатур так же является индикацией ошибок переполнения.
QUOTE
Но зачем??? Никаких плюсов это не даёт, одни минусы.

Все уже говорилось неоднократно. То, что Вы ХОТИТЕ что-то не видеть, это не означает, что этого нет.
QUOTE
Всё, что может быть распределено build-time и должно распределяться build-time.

Вот тут уж мне остается только Вам задать вопрос - Почему?
jcxz
Цитата(zltigo @ Nov 28 2016, 15:59) *
"Лишняя сущность" в виде динамического выделения памяти под задачи, конечно, "тратят память" на MCB, но эти затраты сразу с лихвой компенсируются даже уничтожением одной ставшей ненужной задачи типа начальной инициализации.

И в чём выигрыш от её уничтожения? Или хотите сказать, что освобождаете память занятую под её стек? Т.е. - что такое union и как с его помощью можно эффективно распределять память, используемую на разных этапах работы ПО разными процессами, Вы не в курсе?

Цитата(zltigo @ Nov 28 2016, 15:59) *
Много проще, поскольку так или иначе в устройстве есть встроенные отладочные средства для отладки не "на столе" c эмуляторами, симуляторами, отладчиками... Такова моя реальность.

Так или иначе, для Вашего варианта без них никак не обойтись. А при статическом распределении никто не мешает написать эти самые "встроенные отладочные средства". Или обойтись без них если не нужно.
Опять минус Вашего варианта wink.gif

Цитата(zltigo @ Nov 28 2016, 15:59) *
О! Появилась мысль, что задачи могут быть не статическими sm.gif. Так что, будете, как Вы тут выражались - "лишние сущности" и тоже менять операционку для создания статических и динамических задач? Вот уж точно лишние сущности, если есть создание динамических задач.

Причём тут операционка??? Опять передёргиваете и подменяете понятия....
Например есть функция создания задачи (uCOS):
INT8U OSTaskCreate (void (*task)(void *p_arg), void *p_arg, OS_STK *ptos, INT8U prio)
где: ptos - указатель на вершину стека;
Передаю туда указатель на статически распределённый стек.
Теперь, пожалуйста, поясните почему я не могу туда точно так же передать указатель на динамически выделенный стек, коли мне уж так приспичит?
Зачем менять ОС, которая принимает указатель на стек, а не только его размер???

Цитата(zltigo @ Nov 28 2016, 15:59) *
Какие "такие"? Многие буфера и очереди выделяю и динамической памяти. Причины называл выше. Кроме того, MCB создают своеобразные защитные зоны между блоками и нарушение их сигнатур так же является индикацией ошибок переполнения.

Ну понятно - Вам проще, так как у Вас всё работает на столе и нет жёстких требований по экономии памяти, быстродействия и т.п. Можно хоть каждый байт в куче выделять...
Поди и связные интерфейсы реализуете ногодрыгом? biggrin.gif

Цитата(zltigo @ Nov 28 2016, 15:59) *
Вот тут уж мне остается только Вам задать вопрос - Почему?

Ладно - воля Ваша - делайте хоть malloc(1) для каждого байта, хозяин - барин.
zltigo
QUOTE (jcxz @ Nov 28 2016, 16:51) *
И в чём выигрыш от её уничтожения? Или хотите сказать, что освобождаете память занятую под её стек? Т.е. - что такое union и как с его помощью можно эффективно распределять память, используемую на разных этапах работы ПО разными процессами, Вы не в курсе?

Как правило существует больше одного способа сделать дело. Но поскольку есть система, то логично решать поставленные задачи однотипно и понятно. Создать задачу и прибить ее это в духе операционной системы и соответственно понятно. Выделять двум задачам одну область памяти, следить что бы этой памяти хватало обеим задачам и ее объем в идеале не был избыточен ни для одной из задач, а потом одну задачу остановить навсегда, это уже криво и непонятно.
QUOTE
Так или иначе, для Вашего варианта без них никак не обойтись. А при статическом распределении никто не мешает написать эти самые "встроенные отладочные средства". Или обойтись без них если не нужно.
Опять минус Вашего варианта wink.gif

Ага, для каждого случая каждый раз вписывать. Некрасиво, если все может быть ОДИН раз написано и использоваться и для задач и для любых блоков памяти.
QUOTE
Причём тут операционка??? Опять передёргиваете и подменяете понятия....
Например есть функция создания задачи (uCOS):
INT8U OSTaskCreate (void (*task)(void *p_arg), void *p_arg, OS_STK *ptos, INT8U prio)
где: ptos - указатель на вершину стека;
Передаю туда указатель на статически распределённый стек.
Теперь, пожалуйста, поясните почему я не могу туда точно так же передать указатель на динамически выделенный стек, коли мне уж так приспичит?
Зачем менять ОС, которая принимает указатель на стек, а не только его размер???

Передавайте. Речь идет НЕ о том, как выглядит системный вызов конкретной операционной системы, а об самом факте использования динамически выделяемой памяти.
В случае FreeRTOS, которая здесь обсуждается, надо дописывать раздельные функции. Это не хорошо и не плохо. Это просто реализация которую можно обсуждать. В реализации FreeRTOS, напрмер, изначально была возможность стек и TCB размещать в разных областях памяти, что тоже может иметь свои преимущества в некоторых случаях.
QUOTE
Ну понятно - Вам проще, так как у Вас всё работает на столе и нет жёстких требований по экономии памяти, быстродействия и т.п. Можно хоть каждый байт в куче выделять...
Поди и связные интерфейсы реализуете ногодрыгом? biggrin.gif

Изверетелись, как я вижу весь в попытках объснить "ненужность" sad.gif и начали просто хамить sad.gif. Напомню, что все началось с того, что я написал, что как раз "наcтольные" приемы отладки недоступны ввиду абсолютно ненастольных условий. Теперь Вы вдруг взялись рассказывать, что у меня, а не у Вас настольные системы. Что для "ногодрыга", который почему-то на голубом глазу мне тоже приписали, не требуется быстродействия. Ну и на сладкое вообще глупость, про экономию памяти - динамическое выделение памяти как раз и позволяет ЭКОНОМИТЬ память в системах с ограниченными ресурсами. А, например, те же телекомуникационные системы они все такие - делят ограниченные ресурсы каналов, пропускной способности каналов,... И соответственно и микроконтролеры имеют ресурсы в том числе и по памяти требуемой для процессов и соединений на расчетную нагрузочную способность.
QUOTE
Ладно - воля Ваша - делайте хоть malloc(1) для каждого байта, хозяин - барин.

Спасибо, но про выделение памяти под байт, это Вы придумали. Я всегда писал только о функционально законченных блоках памяти, причем в основном хранящих однотипную информацию (очереди, буфера,....). Что в качестве ДОПОЛНИТЕЛЬНОГО эффекта позволяет при динамическом выделении под них памяти использовать встроенные унифицированные средства отладки и для их просмотра и анализа.

haker_fox
QUOTE (jcxz @ Nov 28 2016, 18:22) *
Это надуманная проблема.
Я участвовал в разработке многих изделий, которые потом стояли и работали "за тысячи километров" и при возникновении каких-то проблем у этих заказчиков, сам по ним не ездил, а только запрашивал номер версии firmware оттуда и разбирался уже на месте, указанным способом, воссоздавая обстановку у заказчика у себя в лаборатории.

Одно из недорузамений, которое происходит при общении с опытными людьми, возникает в тот момент, когда они пытаются тебе сказать, что много видели, и много знают, а значит, ситуации которой они не знают, просто не существует rolleyes.gif Без обид. Занимаюсь разработкой оборудования, которое может работать на подстанции вплоть до 750 кВ. Воссоздать всю эту "мерзкую" обстановку из электромагнитных полей у себя сможет далеко не каждая сертифицированная лаборатория. А симитировать какой-нить транс на 250 МВа вообще невозможно, не имея такой же у себя (или дорого в десятой степени) rolleyes.gif

QUOTE (jcxz @ Nov 28 2016, 20:20) *
Можно конечно все такие переменные выделять на куче (и я видел что многие ламеры так и делают на PC). Но зачем??? Никаких плюсов это не даёт, одни минусы.

Отдельные переменные выделять в куче - это, на мой взгляд, ибыточно. Обычно в куче выделяются массивы данных. Зачем это делать динамически во встраиваемой системе? Но ведь сама FreeRTOS изначально диктует динамическое выделение структур: стек, TCB... Статически всё это выделять можно только с 9 версии, если я не ошибаюсь.

Также удобно по ходу программы писать что-то в стиле
CODE
type_t * ptr = new type_t[ WANT_SIZE]
,
использовать массив, а затем удалить его, нежели заранее создавать его статически.
zltigo
QUOTE (haker_fox @ Nov 29 2016, 14:26) *
Зачем это делать динамически во встраиваемой системе?

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


jcxz
Цитата(zltigo @ Nov 28 2016, 18:53) *
Как правило существует больше одного способа сделать дело. Но поскольку есть система, то логично решать поставленные задачи однотипно и понятно. Создать задачу и прибить ее это в духе операционной системы и соответственно понятно.

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

Цитата(zltigo @ Nov 28 2016, 18:53) *
Изверетелись, как я вижу весь в попытках объснить "ненужность" sad.gif и начали просто хамить sad.gif.

Смотримся в зеркало:
Цитата(zltigo @ Nov 28 2016, 15:59) *
Это у Вас в Ваших настольных sm.gif системах однократно.


Цитата(zltigo @ Nov 28 2016, 18:53) *
Ну и на сладкое вообще глупость, про экономию памяти - динамическое выделение памяти как раз и позволяет ЭКОНОМИТЬ память в системах с ограниченными ресурсами.

Вот это как раз и есть ГЛУПОСТЬ.
Каким образом экономят объясните пожалуйста??? Количество бит в байтах увеличивает?
Именно обычное дин. выделение, а не выделение блоков одинакового размера по Вашему экономит?
Т.е. - что такое фрагментация дин. памяти Вы как бы не задумывались никогда?

Цитата(haker_fox @ Nov 29 2016, 15:26) *
Воссоздать всю эту "мерзкую" обстановку из электромагнитных полей у себя сможет далеко не каждая сертифицированная лаборатория. А симитировать какой-нить транс на 250 МВа вообще невозможно, не имея такой же у себя (или дорого в десятой степени) rolleyes.gif

Ну естественно воссоздание насколько это возможно.

Цитата(haker_fox @ Nov 29 2016, 15:26) *
Обычно в куче выделяются массивы данных. Зачем это делать динамически во встраиваемой системе? Но ведь сама FreeRTOS изначально диктует динамическое выделение структур: стек, TCB... Статически всё это выделять можно только с 9 версии, если я не ошибаюсь.

На FreeRTOS свет клином не сошёлся. Есть и другие ОС, где разработчики постарались отделить мух от котлет и не валить всё в одну кучу, а предоставить возможность разработчику самому решать как ему оптимальнее распределить память. Та же uCOS например. Во FreeRTOS до этого додумались почему-то только к 9-й версии.

Цитата(haker_fox @ Nov 29 2016, 15:26) *
Также удобно по ходу программы писать что-то в стиле
Код
type_t * ptr = new type_t[ WANT_SIZE]
,
использовать массив, а затем удалить его, нежели заранее создавать его статически.

А теперь представьте, что это работает не в игрушке у Вас на столе, с которой Вы поигрались и потом выключили, ну а если что зависло - нажали кнопочку RESET. А что это система, работает за много тыс. км где-нить на месторождении в тайге у заказчика, куда и дороги-то нету. И что таких устройств не одно, а их тысячи работают. И работают они в режиме 24/7. И что задача под ОС крутится не одна, а с десяток или больше. И что задачи эти обрабатывают события асинхронные друг относительно друга. И что требования к памяти у этих задач разные: одна выделяет большими блоками редко, другая часто и мелкими, третья - вообще разные размеры запрашивает.
И тогда после продолжительной работы, у Вас окажется что вроде и памяти-то свободной ещё много, но она вся оказалась так фрагментирована, что задача которой нужны мелкие блоки их получить может, а вот задаче требующей большие блоки будет отказ, так как хоть памяти вагон ещё свободной, но сплошного блока требуемого размера нет.
Вот тут и идёт лесом всё удобство....
Конечно если памяти в устройстве с избытком, то здесь другое дело. Но мне всё время приходилось работать над системами, где ресурсов в обрез.
zltigo
QUOTE (jcxz @ Dec 2 2016, 14:41) *
Вот это как раз и есть ГЛУПОСТЬ.

Есть два человека - Вы и я. Я умею и пользуюсь с успехом динамическим выделением памяти. Вы НЕ умеете и не пользуетесь, но считаете возможным уже не первый пост нести пургу о "ненужности" и в "доказательство" начинаете приписывать мне то использование менеджера для выделения памяти по байту, то хаотические бессистемные и бездумные запросы и освобождения разнообразных блоков памяти да еще и при полном отсутствии у менеджера борьбы с дефрагментацией. Поскольку я не вчера слез с пальмы, а уже десятки лет проектирую, как уже писал, контроллеры для высокоответственных применений при заведомо ограниченных ресурсах (в том числе и памяти), то мне просто надоело с Вами общаться в таком ключе и выслушивать "идеи", как использовать менеджеры памяти через анальное отверстие. Если Вы по другому не умеете, это Ваши проблемы, а не проблемы менеджера памяти.
jcxz
Цитата(zltigo @ Dec 2 2016, 18:56) *
Вы НЕ умеете и не пользуетесь, но считаете возможным уже не первый пост нести пургу о "ненужности" и в "доказательство" начинаете приписывать мне то использование менеджера для выделения памяти по байту, то хаотические бессистемные и

Приписывание другому каких-то действий - это Ваш стиль. По ходу треда Вы уже не раз пытались самоутвердиться, то фантазируя о моих якобы "настольных системах", то выдумывая ещё какие-то небылицы.
Я просто отразил этот стиль на Вас, и это Вам почему-то не понравилось, хотя сами в таком ключе позволяете себе писать о других.
И ещё раз - не надо мне приписывать, чего-то, совершенно безосновательно. Динамическое выделение памяти (особенно для задач связи) я широко использую, только не в виде классического интерфейса malloc(), а в виде выделения индексов элементов статически распределённого массива (с элементами одинакового размера).
А вот динамическое выделение стеков для задач считаю и неудобным и совершенно ненужным. О чём и написал в первом посте.
zltigo
QUOTE (jcxz @ Dec 3 2016, 13:06) *
Я просто отразил этот стиль на Вас....

"Отобразил" это очень правильное слово. Только отобразили Вы не "стиль", а свой ограниченный круг задач, свои ограниченные знания операционных систем, свои ограниченные навыки и приемы программирования sad.gif.
Ввиду этой Вашей ограниченности убедить меня в "нафига оно" менеджеров памяти под нужды задач, ну совсем не получилось.
k155la3
Цитата(haker_fox @ Nov 29 2016, 16:26) *
. . .
Одно из недорузамений, которое происходит при общении с опытными людьми, возникает в тот момент, когда они пытаются тебе сказать, что много видели, и много знают, а значит, ситуации которой они не знают, просто не существует.
. . . .

Записано в мой "цитатник Мао" за Вашим (С) авторством sm.gif

Tahoe
Немного разбавлю этот двустраничный флуд, про оборудование, стоящее в миллионах экземпляров, за тысячи километров и странную организацию работ, когда для исправления ошибок ПО, отправляют малоквалифицированных сервисных инженеров, с еще более странным инструментом - отверткой.

Переписываю задачи на статик. Получаю в плагине IAR странное у.г. В частности, больше не отображается состояние задач - RUNNING/BLOCKED и т.д.

FreeRTOS v.9.0.0
IAR EWARM 7.2 с плагином: "Kernel awareness for FreeRTOS and OpenRTOS" 3.0.0

Это у всех так стало или пора обновлять IAR?

Немного прошелся поиском. Нашел здесь же, на электрониксе, топик с архивом, с плагином версии 2.х.х С ним, при открытии проекта, IAR просто падает, при попытке открыть проект. Что не удивительно.
zltigo
Цитата(Tahoe @ Dec 10 2016, 14:35) *
Немного разбавлю этот двухстраничный флуд, про оборудование, стоящее в миллионах экземпляров, за тысячи километров и странную организацию работ, когда для исправления ошибок ПО, отправляют малоквалифицированных сервисных инженеров, с еще более странным инструментом - отверткой.

Этот Ваш высер означает только то, что действительно больших и ответственных систем работающих в тяжелых условиях Вы даже и приблизительно не представляете sad.gif. Есть места на планете, куда если и можно отправить "квалифицированного" сервисного инженера, то не быстро (например, заполярье оно, блин, даже дальше МКАД), и компьютерами с отладчиками его обвешать тоже нельзя, например, по причине взрывоопасных условий в шахте с оборудованием размазанным на сотни километров под землей. И вообще там очень грязно, темно, столов, стульев и даже розеток для компьютеров нет совсем, зато есть каска с фонарем, резиновые сапоги, роба, самоспасатель на шее и возможность ползать на четвереньках. А стоимость простоя комплекса в ожидании сервисинженера (а что, сервисинженер должен уметь собой заменять и программиста, и вообще всех?) со свежим лицензионным IAR EWARM и плагинами к нему sm.gif, это не много, а очень очень много.
Tahoe
Цитата(zltigo @ Dec 10 2016, 15:49) *
Ваш высер

"Высер", это когда кто-то, вместо ответа на конкретный вопрос, продолжает умничать, причем совершенно не по делу. Когда меня заинтересует твое мнение о разворачивании больших систем, инженеры в резиновых сапогах и прочие "места на планете"(с), я обязательно спрошу. Но уж точно это будет не в топике, о статическом размещении переменных.

А пока, если по существу моего вопроса ответить нечего - проходи мимо и не флуди. Я доходчиво обозначил позицию? Повторяться, как это часто бывает, для самых тупых/упоротых, не придется, надеюсь? Ты же выше этого, да? :D
zltigo
Цитата(Tahoe @ Dec 11 2016, 01:30) *
"Высер", это когда кто-то, вместо ответа на конкретный вопрос, продолжает умничать, причем совершенно не по делу. Когда меня заинтересует твое мнение о разворачивании больших систем, инженеры в резиновых сапогах и прочие "места на планете"(с), я обязательно спрошу. Но уж точно это будет не в топике, о статическом размещении переменных.

Вот ведь как получилось - Вы, ничего не понимая в том, какие условия эксплуатации и работы бывают. Какие способы контроля в процессе работы и отладки неоходимо ВСТРАИВАИТЬ в системы. В реальные системы, а не коробочку работающую на столе перед Вами. При при этом сами не умея самостоятельно разобраться с инструментом отладки даже у себя на столе, Вы сочли возможным походя обгадить инженеров "в сапогах с отвертками".
Цитата
А пока, если по существу моего вопроса ответить нечего - проходи мимо и не флуди. Я доходчиво обозначил позицию?

После чего имеете еще наглость "обозначать позиции".
Tahoe
Цитата(zltigo @ Dec 11 2016, 11:03) *
Вы, ничего не понимая в том, какие условия эксплуатации и работы бывают.

"Да уймись, дура!"(с)

По моему вопросу, о плагине, есть что сказать?
ar__systems
Задачу я решаю так: gcc умеет выдавать инфу, сколько памяти занимает на стеке каждая из функций. Так же он умеет выдавать дерево вызовов. Вот комбинируя эти данные с помощью скрипта я могу узнать, сколько стека надо для моей задачи. Конечно если есть вызовы функций через указатели придется инфу доработать вручную, но всяко лучше чем эксперементировать.


Цитата(zltigo @ Nov 28 2016, 07:59) *
Это у Вас в Ваших настольных sm.gif системах однократно. У меня есть и задачи, которые порождаются и уничтожаются. Как минимум это одна задача начальной инициализации и диагностики системы.


Спрашивается, зачем "задача начальной инициализации и диагностики системы" запускается как задача OS? Вызовите ее как обычную функцию до передачи управления OS и будет вам счастье.

Цитата(zltigo @ Dec 10 2016, 07:49) *
Есть места на планете, куда если и можно отправить "квалифицированного" сервисного инженера, то не быстро (например, заполярье оно, блин, даже дальше МКАД), и компьютерами с отладчиками его обвешать тоже нельзя, например, по причине взрывоопасных условий в шахте с оборудованием размазанным на сотни километров под землей. И вообще там очень грязно, темно, столов, стульев и даже розеток для компьютеров нет совсем, зато есть каска с фонарем, резиновые сапоги, роба, самоспасатель на шее и возможность ползать на четвереньках. А стоимость простоя комплекса в ожидании сервисинженера (а что, сервисинженер должен уметь собой заменять и программиста, и вообще всех?) со свежим лицензионным IAR EWARM и плагинами к нему sm.gif, это не много, а очень очень много.

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

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

Цитата(jcxz @ Nov 28 2016, 07:20) *
Зачем все эти кучи, malloc()-и и пр. хлам когда задачи создаются однократно (при старте firmware) и, соответственно, стеки выделяются также однократно. И никогда не освобождаются.
....
Всё, что может быть распределено build-time и должно распределяться build-time.

сам факт выделения стэков с помощью mallocov это не такая уж большая беда. В конце концов, если я создаю все задачи и стэки до запуска ос, выделение и размещение стэков происходит абсолютно детерменировано, и это главное. Т.е. это даже "динамическим" созданием можно назвать лишь с натяжкой. А вот по настоящему динамическое создание и запуск задач в процессе работы в эмбед системе это реальное зло, и я бы в своем железе не разрешил бы такое никогда. Особенно в том, которое работает в тех ужасных условиях, когда рядом нет ни стола, ни розетки wink.gif
Raven
Цитата(x893 @ Nov 7 2016, 15:59) *
1. Прописываем стек известным значением (мне нравится DEADBEEF) и потом смотрим

Цитата(zltigo @ Nov 7 2016, 18:08) *
А мне CAFEBABE sm.gif - оптимистичнее sm.gif

Использовали оба варианта. А недавно человек со свежим незамутненным взглядом предложил 0xDEDABABA :-)

Извините, не мог мимо пройти.
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2024 Invision Power Services, Inc.