Видимо, для эффективной экономии ОЗУ нужно не только знать размеры переменных, но и знать архитектуру своего ПО.
Хотя сейчас напрягаться не принято и проще поставить внешнюю SDRAM и/или выбрать МК с большим количеством набортного ОЗУ.
В приложениях с таким функционалом, что приходится использовать TCP/IP, обсуждение размера переменной (1 или 4 байта)
вызывает у меня определенные подозрения (что что-то не так).

Америку открыли
Главное обеспечить невозможность одновременного выполнения процессов использующих эту общую область.

И если такой возможности нет то и никакой мыныджер не поможет.

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

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

Это Вы сами так решили или подсказал кто?

Может.

ТС в сообщении 15.

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




Для вытягивания последних байтов надо знать уже все . Но это уже на самом деле большая редкость. Я вот тоже на в работе о которой писал, тоже уже для M8C контроллера последние байты вытягивал, вытянул, плюнул, переделал принципиально, и стало 64 свободных байта. Ну придет серверу отказ на исполнение одной редкой команды, если звезды не так лягут, ну переспросит.

Одиночной переменной - несомненно, но бывают и солидные массивы данных, где уже счет идет на тысячи таких переменных за каждым из тысяч процессов.
При этом слово тысячи не должно особо пугать - на одном из проектов еще на i8085 у меня в свое время было 256 процессов. На первом из опробованных ARM LPC2114 - 1280 процессов. В обоих случаях прикол был в том, что процессы находились в разных состояниях и в статических состояниях обходились достаточно небольшим количеством данных. На переходных режимах процессам добавлялся блок памяти для обслуживания "развития" процесса.

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

Интересно помог ли ТС ваш трёп память освободить?

Поживем-увидим. Но то, что я точно знаю, что Вам уже ничего не поможет .

Я в помощи не нуждаюсь , а уж в помощи такого хвастуна-виртуоза как вы и подавно.

Хахаха у zombi бомбануло прям так не слабо по ходу))))))))))
Не знаю, вроде zltigo дельные вещи говорил...

помог. вывод такой. взять камень с бОльшим RAM. дешевле чем внешнюю память ставить.

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

Т.е. совет использовать менеджер памяти подтолкнул Вас к решению "взять камень с бОльшим RAM"?
Феерично!
Или это сарказм такой?

Почитайте сообщение №51.

Не имею возражений к Вашему сообщению №51

И мне кажется что ТС сам же и ответил на свой вопрос написав:

Т.е. на этапе проектирования количество необходимой памяти не определено даже приблизительно.
О каких менеджерах вообще может идти речь?

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

тут нужно решать концептуально. есть 10 задач. либо загрузить их в RAM и проходить итерацией , либо брать по одной - загрузил-освободил - тогда можно и с malloc/free. но во втором случае возникает вопрос - где держать задачи.

хорошо. я написал код для PLC. В Ladder Diagram или мнемоник. где хранится пограмма которую PLC исполняет?

идея.положу во флеш..если останется место. он что то тоже стремительно убывает.

Обвинять кого либо в том чего он не говорил - не порядочно.

Значит менеджеры памяти в некоторых задачах нужны.
Пригодность задачи для использования динамического выделения памяти определяет разработчик.
Если задача непригодна (пусть даже по причине отсутствия опыта у исполнителя) - наращиваем ОЗУ.
Все - конфликт исчерпан. Я прошу меня простить, если с кем-то поступил не порядочно.

...

Тема исчерпана - неплохо бы закрыть и последнее почистить.

Ну значит так и есть
Удалил, мне не сложно.
А насчёт "закрыть" это лучше к ТС писать


Может СИшникам и нужны, мне точно не нужны.
Для меня это просто часть алгоритма и как его обозвать не имеет значения.

Создать глобальное объединение (union) из массивов всех нужных типов, максимально необходимого размера, и пользоваться им по мере необходимости вместо кучи. Годится?
Хочу понять, как куча может помочь сэкономить память? Если требуется хранить глобальные переменные, но никуда не денешься, придется выделить для них память сразу и навсегда. Если локальные, так они где создаются - в стеке или в куче? Кто (что) решает?

P.S. Или приведением указателя к нужному типу пользоваться массивом целых и в хвост и гриву.

Никак. Может привести только к бОльшему расходу памяти.
Куча полезна только если нужно запускать различные задачи, заранее не известные (когда и какую), с заранее неизвестными требованиями к памяти. Но и то - нужна обработка случая нехватки памяти. Да и дефрагментация периодическая или после завершения каждой задачи. Это случай Linux-а и подобных ему систем.

Обычно для ембеддед достаточно:
union MemShare {
struct MemMode1 {
int member1, member2;
...
} memMode1;
struct MemMode2 {
int member1, member2;
...
} memMode2;
...
} memShare;
где Mode1, Mode2, ... - состояния работы устройства с неперекрывающимися структурами данных; которые в свою очередь могут быть union и делиться дальше.

Разумеется нет. Куча, это просто ОДИН ИЗ СТАНДАРТИЗИРОВАННЫХ механизмов расшаривания памяти. Само расшаривание памяти может использоваться для чего угодно, а отнюдь не только для "запуска задач с неизвестными требованиями".

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

Я прекраcно улавливаю разницу между "полезно" и "полезно ТОЛЬКО". Вот про использования Вами "полезна ТОЛЬКО если нужно запускать различные задачи", "Может привести ТОЛЬКО к бОльшему расходу памяти" и отвечал. Так что либо уберите слово ТОЛЬКО из своих постов, либо не пытайтесь сейчас юлить.

ТС вопрошает

"вЫртуоз" пишет:


Просто прохожий -

"вЫртуоз"-

и тд и тп


Внимание, ВОПРОС!!!
Помог ли "вЫртуоз" освободить память вопрошающему?

И если помог, то представляю как сейчас TC "купается" в огромном количестве свободной памяти которая так и просит его - ну возьми ну используй меня...

Будьте внимательнее. Ответ уже был http://electronix.ru/forum/index.php?showt...t&p=1410271
Мне описанный мной подход к делу помогает. По причине того, то я понимаю, что и как делаю. Вам, по причине полной неспособности понять, соответственно - нет.

Да ладно? Нормально тема раскрыта.
Или вы хотели чтоб тут за ТС прям все исправили и отладили?
Направление для изучения дано, варианты расшарить память между задачам/подсистемами/etc даны.
Техники от полу-кустарных, ручных вариантов с union до более правильных менеджеров памяти в общих чертах описаны....
Дальше человек уже должен маленько по гуглить и найти всё что ему нужно.

Тут как-бы получается умному достаточно, а дурак все равно не поймет.

P.S.
Честно не понимаю чего у нескольких людей на форуме так бомбит пукан от советов zltigo?
Это такой способ отомстить за курс Евро или что?
Потому что это уже явно какая-то не адекватная реакция часто начинается.. Объяснения приходят только в стиле теории заговоров или борьбы с империализмом и ненависти к буржуазии )))

Но убирает он вас всех здорово! Порой тему читаю только чтоб по улыбаться со всего этого ))))

Скоро вы всех СИ-шников припишете к наемникам zltigo...
Есть профи, которые на жизнь электроникой зарабатывают (и при этом любят электронику).
Им виднее, что и как надо делать, а что и как не надо делать - поэтому они готовы давать советы
для решения конкретной задачи в конкретных условиях.
А есть любители, которые считают только свой подход правильным в любых условиях.
Вроде, вопрос топика закрыли несколько страниц назад. Хочется поговорить о бесполезности СИ,
о ненужности абстракций программирования и о "любимом" ASM? - открывайте свою тему.
Да, zltigo довольно прямолинеен, но по информации из его постов можно судить о таком опыте
(в том числе и asm-разработок) и таком объеме созданного полезного, до которого вам еще очень далеко.
Завязываете: а то очень басню о Моське и Слоне напоминает.

Прямолинеен

Неужели наконец-то всю память сэкономили?

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