[den_po 0]

V8.2.3

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

[den_po 0]

now all RTOS objects can be created using statically allocated memory

УРА!

[zltigo 0]

УРА!

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

 

 

[den_po 0]

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

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

 

ни посмотреть на ходу что где находится и чем и насколько зянято.

.map, отладчик

 

В общем дурацкое "приобретение" :(. Не смогли написать нормальный портируемый менеджер памяти :(

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

[zltigo 0]

Лично я ждал эту фишку как раз ради объектов, которые живут вечно.

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

Но и удалить тоже ничто не мешает. Или я чего-то не знаю?

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

.map,

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

отладчик

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

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

Зачем???

 

 

 

 

[den_po 0]

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

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

 

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

Глупости же.

 

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

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

В остальном абсолютно ничего не мешает ВАМ смотреть то же самое точно так же, как вы делали с динамическим выделением.

Да и использовать статические буферы вас никто не заставляет.

 

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

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

 

Зачем???

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

[zltigo 0]

Глупости же.

:)

Да и использовать статические буферы вас никто не заставляет.

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

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

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

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

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

 

 

[den_po 0]

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

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

 

УБИРАНИЕ возможности спросить у менеджера памяти распредерение и принадлежность блоков памяти никак не может служить "ускорением" чего либо.

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

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

[zltigo 0]

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

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

Никто ничего не убирал. Вместо одного способа стало три

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

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

расписаться в собственном бессилии.

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

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

[AlexandrY 2]

А так сие выглядит как

расписаться в собственном бессилии.

 

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

Очень удобно.

 

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

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

 

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

 

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

 

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

[zltigo 0]

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

Очень удобно.

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

Динамический менеджер это дополнительный расход памяти

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

, фрагментация

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

и ухудшение скоростных параметров задач.

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

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

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

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

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

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

Практически все не так :(, начиная с их дивного количесва, что уже само по себе уродство. Ну и первое, что я вообще сделал мамнадцать лет назад, это добавил отдачу в менеджер ВСЕЙ отавшейся свободной памяти вместо тупого дефайна размера пула. Потом добавление нескольких пулов, потом дефрагментацию. Все на самом деле очень несложно. Результат когда-то на форум выкладывал.

http://electronix.ru/forum/index.php?showt...st&p=487855

http://electronix.ru/forum/index.php?showt...st&p=746045

 

[AlexandrY 2]

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

 

 

Практически все не так :(, начиная с их дивного количесва, что уже само по себе уродство. Ну и первое, что я вообще сделал мамнадцать лет назад, это добавил отдачу в менеджер ВСЕЙ отавшейся свободной памяти вместо тупого дефайна размера пула. Потом добавление нескольких пулов, потом дефрагментацию. Все на самом деле очень несложно. Результат когда-то на форум выкладывал.

 

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

 

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

И от этого раздосадованы, что не можете доказать свой приоритет?

[zltigo 0]

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

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

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

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

И от этого раздосадованы, что не можете доказать свой приоритет?

Глупость :(

 

P.S.

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

[den_po 0]

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

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

 

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

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

 

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

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

Вы опять, как и в другой дискуссии, придумываете за меня, о чём я думаю.

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

[zltigo 0]

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

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

Жду от вас пару поучительных историй о том, как вам на практике безмерно помогло подобное знание.

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

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

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

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

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

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

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

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

Радуйтесь!