FreeRTOS Heap_x.c Опции

[FormatCft]

Доброго времени суток!
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
1. Есть ли у кого своя реализация Heap_x.c? А то, что то не хочется использовать реализации которые есть (то без чистки памяти, то без объединения свободных блоков).
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
2. Еще вопрос по heap_3.c. Этот хип использует стандартный Си-шный хип или просто есть возможность его использовать?
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

[zltigo]

Есть ли у кого своя реализация Heap_x.c?

Делал свою реализацию именно по причине реализации объединения свободных блоков, алгоритма поиска наиболее подходящего, получения списка как занятых, так и свободных, добавления маркера владельца блока, организации поддержки вложеных менеджеров и сегментированного Heap. К делу не относится, но еще были объединены блоки памяти под TCB и Stack.

Еще вопрос по heap_3.c. Этот хип использует стандартный Си-шный хип или просто есть возможность его использовать?

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

[FormatCft]

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

Ого! Значительные навороты! ! !
Можно у Вас попросить поделиться результатами Ваших трудов? Был бы очень благодарен!
Или хотябы подсказать в каком направлении двигаться.

К делу не относится, но еще были объединены блоки памяти под TCB и Stack.

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

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

Понял. Т.е. есть смысл найти открытый нормально написанный или попыхтеть "немножко" и написать своё

[zltigo]

Можно у Вас попросить поделиться результатами Ваших трудов? Был бы очень благодарен!

Я подумаю. Основная проблема не в "секретности" а некоторой заточенности под несколько отличающееся от стандартного окружение и желательную чистку и комментирование перед раздачей

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

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

Понял. Т.е. есть смысл найти открытый нормально написанный или попыхтеть "немножко" и написать своё

Да, так.

Компактная и быстрая.

Ну несколько монументальна . Но в качестве объекта для изучения безусловно годится.

[FormatCft]

Я подумаю. Основная проблема не в "секретности" а некоторой заточенности под несколько отличающееся от стандартного окружение и желательную чистку и комментирование перед раздачей

Спасибо! Буду с нетерпением ждать

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

Ясно. Небольшая экономия места.

Ну несколько монументальна . Но в качестве объекта для изучения безусловно годится.

Т.е. я так понял, что для МК-го применения не подходит из-за того, что слишком много времени кушает?

[zltigo]

Т.е. я так понял, что для МК-го применения не подходит из-за того, что слишком много времени кушает?

Подходит. Время дело второе. Просто излишества есть, типа сервисных наворотов, realloc(),....

[FormatCft]

Подходит. Время дело второе. Просто излишества есть, типа сервисных наворотов, realloc(),....

Понял. Сейчас только жду вашей версии!

Запустил в своём проекте heap_3
arm-elf-gcc + newlib небольшие правки syscalls.c, вообщем получилось как костыль. Пока работает.

Спасибо! Костыли мне еще рано )) Я думаю, что буду использовать что-то из 2х предложенных вариантов (скорее всего вариант ЗлтИго)