V8.2.3
наконец-то включили фикс для ренесасовских 78k

УРА!

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

Лично я ждал эту фишку как раз ради объектов, которые живут вечно. Но и удалить тоже ничто не мешает. Или я чего-то не знаю?


.map, отладчик


Отличное приобретение. Особенно когда оно помогает распределять память на этапе сборки.

А при динамическом выделении что Вашим объектам мешает жить вечно?

Удалить-то, очевидно, можно, но память больше никогда обратно в распоряжение работающей прошивки не получите.

Очень "удобно" хранить мапы для всех версий прошивок.

Да, да, на объекте где нибудь в тайге на сосне компьютер, установленый на нем софт, Адаптер и обученый человек это самое то .

Зачем???

Ничего не мешает. Просто присутствует иногда лишняя сущность.


Глупости же.


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


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


Затем, что удобней. Можно раньше проблему найти.

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

Вы же сами написали, что хотьте для посмотреть в дополнение к мар еще и отладчик. Не удобно, уже писал, к сосне все это доставлять и подключать.

УБИРАНИЕ возможности спросить у менеджера памяти распредерение и принадлежность блоков памяти никак не может служить "ускорением" чего либо. На самом деле проблемы с менеджерами памяти нет никакой, за исключеним той, что то что накидано в комплекте FreeRTOS в качестве "менеджеров", есть действительно кривизна и убожество . Ну в самой операционке подлатать момент создания Idle Task - первой, ибо самая обязательная , а не последней. Как понимаю, это едиственая причина по которой Вам может хотеться заренее распределить память, дабы убедится, что сисема сможет запуститься. Ну и, конечно, менеджер должен сам забитать себе всю свободную память. То, что в убогих менеджерах из комплекта память под хип нужно выделять статически это убожесто неземное .

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


Никто ничего не убирал. Вместо одного способа стало три - динамическое выделение памяти функциями FreeRTOS, динамическое выделение пользователем, выделение компилятором (с подсказкой пользователя, конечно).
В одном случае я могу узнать, что перестал влезать в допустимый объём памяти, только после запуска, а в другом на этапе сборки. Вы же не будете спорить, что чем раньше обнаружится проблема, тем лучше?

В том-то и дело, что менеджер памяти знает их расположение. А через костыли это как раз то, что Вам так понравилось.

Прелестное "решение" - сначала сделали кучу менеджеров памяти и все, как один, через анус, а потом еще добавили "способы" как через анус обойти сделаные через анус менеджеры .
Если бы был штатный достойный менеджер памяти, то тогда мое отношение к варианту с отказом от менеджера памяти было-бы нейтральным - ну типа, да, вариант на любителя. А так сие выглядит как
расписаться в собственном бессилии.

Несколько секунд времени единожды потраченные на запуск не являются сколь-нибудь заметой ценой за саму возможность ОБОЙТИСЬ МЕНЬШИМ КОЛИЧЕСТВОМ ПАМЯТИ, которую дает менеджер памяти. Толку от того, что Вы так, или иначе узнали, что памяти нехватило? Нужны механизмы для борьбы с нехваткой памяти и один из механизмов это менеджер памяти от отсутствия которого Вы испытываете радость.

В MQX Lite всегда использовалось статическое выделение памяти и задачи там создаются только статически.
Очень удобно.

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

Беда FreeRTOS в том, что IAR и прочие скоростные IDE поддерживают ее рудиментарно, как бы для отмазки, нельзя посмотреть ни распределение памяти ни даже остатки по свободных пространств в стеках.

А вот MQX Lite в IAR отладчики можно просмотреть до любых мелочей. Состояние всех объектов, все цепочки выделенных блоков и т.д.

Кстати, что там с менеджерами памяти во FreeRTOS не так?

Привычная убогость не есть синоним удобства.

Расходы на MCB это считанные байты. Неубедительно.

Глупость. Если не использовать удаления-создания объектов, так-же как это по причине НЕВОЗМОЖНОСТИ происходит при статическом создании объектов, то и фрагментации тупо неоткуда взяться. Это раз. А при использовании все зависит от стиля писания и качества менеджера.

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

Не валите с больной головы на здоровую. Либо памяти зватает для тупо статически выделеных объектов и тогда такого-же ее объема хватит и для динамических объектов, либо для статического выделения памяти просто НЕ ХВАТИТ.

Для этго нужно просто написать хоть сколь-нибудь приличный менеджер памяти и пару десятков строк в систему. Ну а остаток свободного пространства стеков во FreeRTOS был и есть от рождения.

Практически все не так , начиная с их дивного количесва, что уже само по себе уродство. Ну и первое, что я вообще сделал мамнадцать лет назад, это добавил отдачу в менеджер ВСЕЙ отавшейся свободной памяти вместо тупого дефайна размера пула. Потом добавление нескольких пулов, потом дефрагментацию. Все на самом деле очень несложно. Результат когда-то на форум выкладывал.
http://electronix.ru/forum/index.php?showt...st&p=487855
http://electronix.ru/forum/index.php?showt...st&p=746045

Не убожество, а другой стиль программирования задач.

Так вы значит изобрели велосипед по типу umm_malloc только не выложили его на Github почему-то.
И от этого раздосадованы, что не можете доказать свой приоритет?

В том-то и дело, что с менеджером можно программировать в любом стиле и реализовавать в системе ДОПОЛНИТЕЛЬНЫЕ возможности. А без него НЕТ.

Я сделал лет 12 тому назад то, что мне нужно. Вещь простая, работы на несколько часов. Самое сложное было сформулировать самому себе желания. Дальше уже просто. Этот менеджер один тз тех случаев, когда проще написать, чем чего-то искать и разбираться в "велосипедах". Ни о какои "изобретении" и речи не идет.

Глупость

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

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


Нередко многократное пересоздание объектов операционки нафик ненужно. В этом случае именно отказ от использования кучи позволит сэкономить.


Ну да, ну да, стоит взять менеджер памяти, и сразу памяти станет завались.
Вы опять, как и в другой дискуссии, придумываете за меня, о чём я думаю.
Я не предлагаю полностью отказаться от менеджера памяти. У меня есть проекты с ним, частично с ним (куча используется только внутри FreeRTOS) и вообще без него. Но если есть возможность обойтись без него там, где он нафик не нужен, я буду этой возможностью пользоваться.

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

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

Уже присал. Если не нужно, то памяти до фига. Если дофига, то зачем нести чушь об экономии и плодить в системе ЛИШНИЕ сущности ввиде альтернативных вызовов. Общие-же затраты на Memory Control Block невелики. Да, и еще, для любителей сначала не думая писать что-то а потом "отлаживать" - добавление такого MCB к блоку памяти позволяет получить своеобразный индикатор перехода за границы выделенного блока при ошибках .

Сразу станет возможным берережно обращаться с памятью и расшаривать ее использование.

Незачем пользоваться ни нафиг ненужными заплатками типа этого кастрирования менеджера. Но, если испытываете ничем необъяснимое счастье, то, конечно, пользуйтесь!
Можете считать, что я написал все это не для Вашего вразумления, а только для того, что-бы необъяснимое счастье не сильно расплескивалось в окружающую среду .
Радуйтесь!