Вопрос с управлением памятью скрыт за многочисленными макросами. К тому же как я понял в LWIP существует не один вариант работы с выделением памяти. Но разобраться в этом надо , тат как памяти SRAM 128K контроллеру скорее всего не будет хватать и надо будет что-то разумно урезать , чем-то жертвовать.
Самая большая проблема в работе с не с выделение памяти (выделить ее совсем не сложно), а с очиской ее после логического использования.
Нас лично подвигло желание передавать через post запрос объем тела более 200 байт, но мы увидели , что данные не приходят полностью и пришлось разбираться.
Где резервируется память в LWIP ? Откуда надо изучать исходники.
memp_std.h
Для начала озадачиваемся наличием трех подходов к выделению памяти . Как понять каким на данный момент из трех вариантов мы пользуемся (или может быть несколькими вариантами одновременно...)
* We have create three types of pools:
* 1) MEMPOOL - standard pools
// сразу не используем
* 2) MALLOC_MEMPOOL - to be used by mem_malloc in mem.c
// такого дефайна как MALLOC_MEMPOOL на самом деле нет.
* 3) PBUF_MEMPOOL - a mempool of pbuf's, so include space for the pbuf struct
// pbuf_alloc | pbuf_free
По видимому , все области памяти , которые нам нужны будут прописаны в файле memp_std.h . В этом файле видим , что для каждого функционала выделяется память отдельно. Например для TCP так :
#if LWIP_TCP
LWIP_MEMPOOL(TCP_PCB, MEMP_NUM_TCP_PCB, sizeof(struct tcp_pcb), "TCP_PCB")
LWIP_MEMPOOL(TCP_PCB_LISTEN, MEMP_NUM_TCP_PCB_LISTEN, sizeof(struct tcp_pcb_listen), "TCP_PCB_LISTEN")
LWIP_MEMPOOL(TCP_SEG, MEMP_NUM_TCP_SEG, sizeof(struct tcp_seg), "TCP_SEG")
#endif /* LWIP_TCP */
Из вышеприведенного куска следует , что если нам нужен TCP , то по-любому мы используем LWIP_MEMPOOL, но сам вариант самого LWIP_MEMPOOL определяется по дефайнам в файле opt.h .
opt.h
Основной файл с дефайнами для памяти (также как и для других целей) opt.h .
/*
------------------------------------
---------- Memory options ----------
------------------------------------
*/
MEMP_MEM_MALLOC = 1 - это 2 вариант работы с памятью.
MEM_USE_POOLS =1 - это 3 вариант работы с памятью.
И если их выставить в 1 оба , то получаем при компиляции #error "MEMP_MEM_MALLOC and MEM_USE_POOLS cannot be enabled at the same time". Это срабатывает защита на уровне компиляции в файле init.c .
Вот так на уровне дефайнов осуществляется контроль над нашим пониманием , что мы делаем в дефайнах. Спасибо на этом разработчикам, потому как разобрать довольно сложно по причине большого количества единиц информации.
Итак похоже мы поняли что выбор использования памяти надо делать выставлением в 1 либо MEMP_MEM_MALLOC (что заметно уменьшает расход памяти) либо в 1 MEM_USE_POOLS .
На самом деле оба варианта используют в результате функцию mem_malloc для выделения памяти , но при MEM_USE_POOLS через pbuf_alloc добавляется еще дополнительная информация к куску памяти. Как минимум для того , чтобы строить связанные цепочки из кусков памяти.
И вот для варианта MEM_USE_POOLS срабатывает напоминание , что нам надо в этом случае включить MEMP_USE_CUSTOM_POOLS. Отлично : картина начинает прорисосвываться.
Для MEMP_USE_CUSTOM_POOLS надо определить в файле lwippools.h свои шаблоны кусков памяти примерно так :
//#ifndef LWIPPOOLS_H - это важно не использовать !!
//#define LWIPPOOLS_H - это важно не использовать !!
LWIP_MALLOC_MEMPOOL_START
LWIP_MALLOC_MEMPOOL(4, 256)
LWIP_MALLOC_MEMPOOL(2, 512)
LWIP_MALLOC_MEMPOOL(1, 1024)
LWIP_MALLOC_MEMPOOL_END
//#endif
Похоже есть нюанс - стандартную защиту от повторного включени хэдера *.h надо убрать.
Теперь изучим побробнее механизмы выделения памяти в 2 и 3 варианте. Начнем с более простого MEMP_MEM_MALLOC .
MEMP_MEM_MALLOC
Получая сырые данные с физического уровня (это у нас USB канал) мы сначала должны выделить память для них и скопировать туда пришедшие байты. Обработать их и потом очистить выделенный буфе. Как это делается в случае MEMP_MEM_MALLOC =1 ( MEM_USE_POOLS =0 & MEMP_USE_CUSTOM_POOLS=0).
PBUF_POOL_SIZE
В LWIP мы используем PBUF_POOL_SIZE . Это максимальное количество стандартных буферов для обслуживания каждого из пришедших пакетов, чтобы никого не потерять. Буферы создаются по цепочке.
lwippools.h
Мы по условиям программы мы обязаны оставить функционал arp, ,ip ,udp , tcp , icmp, dhcp сервер. Все остальное придется убрать для экономии памяти.
Allocating common symbols (файл map) - полезен для информации , что жрет память.
Дефайны , которые влияют на расход памяти :
TCP_MSS: TCP Maximum segment size
TCP_MSS: TCP Maximum segment size