Забудьте как страшный сон попытки использовать динамическое распределение памяти на таких контроллерах,
это возможно только с памятью ~8Kб+ хотя я например и на 32Кб стараюсь все в статике распределить.

Не стоит только этот один козий библиотечный malloc и встроенный heap ассоциировать со всем многообразием "динамического распределения" памяти.

Пусть есть некий пул состоящий из 5-ти буферов, объявленный статически:
TBUFFER pool[5];

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

надо только написать свои:
TBUFFER *pool_alloc();
pool_free( TBUFFER *);

Совершенно никакой разницы нет в том, как именно вы собираетесь выделить память под heap. А автору топика, вместо того, чтобы "накатывать" на форумчан, что "мало" помогают, неплохо было бы разобраться в том, как современные с/с++ компиляторы распределяют сегменты RAM для различных типов данных. А heap на 20 байт - это полная и бессмысленная фигня. Вы прикиньте, сколько места сожрали программы для ее обслуживания.

Кроме того, при использовании heap, у вас и озу было потрачено. При чём соотношение затрат к размеру кучи в % уже говорит в пользу отказа от такого подхода.
Даже в учебных целях, размер кучи (собственно выбор камня) неудачен.

В тоже время, это совершенно не значит, что для работы с динамической памятью нет места в однокристалках. Многие используют динамическую память. Есть кристаллы с 4/8/64к оперативки. Там это применимо. В одном случае я применял динамику в м88 (1к). Там, конечно, нет полной работы с кучей, а только выделение памяти и освобождение её всем куском, но всё-же.

Ну, тогда по большому счету и запись переменных в union тоже можно назвать динамическим ну если не распределением, то использованием памяти.
Флаги занятости добавить - и гордое слово "распределение".

Нет там было честное выделение памяти. Работа с датчиками 1-ware. При соединении - выделялась память для датчика и туда заносился номер его. А вот удаление не по штучно, "а разом"
Ну так задача стояла. Никто по большому счёту не мешал и полному управлению с поштучным удалением и дефрагментацией. Не такие уж накладные расходы.

Например, по такому принципу, можно построить работу с таблетками или RFID картами.

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

Я бы перефразировал это в что-нить типа:
... должна иметь эффективный алгоритм отведения/освобождения памяти для элементов РАЗНОГО размера.

Эффективность алгоритма - дело десятое. Важнее - функциональность. Тут коллеги приводят примеры, когда выделение/освобождение может вообще раз-другой и производится.

Под эффективностью я имел в виду не только скорость алгоритма но и то что под 5 байт не будет выделяться 100байт.
Такой "обобщенный" параметр сводящийся к общей эффективности решения.

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

и


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

Я бы не стал перефразировать и конкретизировать.
Динамическое распределение, как было сказано, - это возможность захватить и освободить ресурс - alloc/free.
Размеры это уже дело десятое.


Если знаете что там всегда 5 байт, то выделите себе 5 байт статически.
А если не знаете сколько, то чем не устраивает брать по 100?

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

Поскольку malloc() аппаратно контроллером не поддерживается то создам статический буфер т.к. его размер и когда/кем будет использован знаю.
Вопрос на счет "материализовался": почему когда создается куча то память отбирается у области ОЗУ где Hardware Stack а не, скажем, у Data Stack ? Почему так?

Извиниться не хотите, перед теми, кто тратил на Вас свое время?

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