Помощь - Поиск - Пользователи - Календарь
Полная версия этой страницы: Независимые кучи для FreeRTOS и для lwIP - в чем преимущество?
Форум разработчиков электроники ELECTRONIX.ru > Cистемный уровень проектирования > Операционные системы > FreeRTOS
Ruslan1
Здравствуйте!

У кого есть опыт использования одной общей кучи для lwIP и для FreeRTOS?

Сам использую отдельные кучи. И в примерах вижу отдельные кучи с отдельными менеждерами памяти для lwIP и для FreeRTOS.
Зачем это сделано?

Чем куча двойного размера хуже чем две отдельные?
Общая куча быстрее сегментируется из-за разнородности задач?
Или в случае двух куч менеджер памяти легче оптимизировать отдельно под каждую из этих двух задач?

И если это общая куча, то какой менеджер памяти лучше брать, из lwIP или из freeRTOS? (для FreeRTOS я использую heap5.c)
AlexandrY
Цитата(Ruslan1 @ Nov 10 2017, 12:29) *
Чем куча двойного размера хуже чем две отдельные?

Хотите чтобы пропускная lwIP зависела от работы стронних задач? Перебор по цепочке блоков в поисках свободного - затратная операция.
Еще важен фактор DMA.
Память пересылаемая по DMA должна лежать в определенных областях специально в архитектуре ARM для этого предусмотренных.
А память общего назначения може быть где угодно.

kolobok0
Цитата(Ruslan1 @ Nov 10 2017, 13:29) *
...И если это общая куча...


делал общую кучу. но с разными очередями раздачи(парковки свободных). одна чисто для драйвера, вторая чисто для задач. переписывал и затачивал на скорость.
профит = не надо копировать при приёме - быстрее обработка приходящих данных.
работает. уже несколько лет. stm32

удачи усем
(круглый)
ЗЫ
По секрету = железо критично к памяти только для заголовков цепочки ожидания (их вообще не надо трогать)...
Ruslan1
Уважаемые участники обсуждения, извините за долгое молчание.

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

Еще раз спасибо!
Для просмотра полной версии этой страницы, пожалуйста, пройдите по ссылке.
Invision Power Board © 2001-2025 Invision Power Services, Inc.