I looked up configSUPPORT_DYNAMIC_ALLOCATION. Currently I use 1. The RTOS gets a block of RAM (64k - the whole CCM) and within that it runs its own private heap. As each task is defined with e.g. xTaskCreate, this 64k gets gradually filled up. AFAICT FreeRTOS never frees any of this stuff so malloc() should be perfectly safe. Is there another reason to use static allocation? One concern I can see is if FR uses the heap for its message queues, which would be really dumb.
MEM_USE_POOLS and MEM_USE_CUSTOM_POOLS are both set to 0. Unfortunately I have not found any clear documentation on this stuff. The three main items are mem_size, pbuf_pool_size and pbuf_pool_bufsize, and there is a vast amount of conflicting info on the web about these. I think mem_size is used for tx buffers and the other two are for rx buffers, but this is probably wrong.
This is what I currently have and it works
// MEM_SIZE: the size of the heap memory. This is a statically allocated block.
// If MEMP_MEM_MALLOC=0, this holds just the PBUF_ stuff.
// If MEMP_MEM_MALLOC=1 (which is not reliable) this greatly expands and needs 16k+.
// Empirically this needs to be big enough for at least 4 x PBUF_POOL_BUFSIZE.
// 6k yields a good speed and going to 8k+ makes a minimal improvement. The main
// factor affecting speed is the poll period in ethernetif_input().
#define MEM_SIZE (6*1024)
// MEMP_ structures. It has been impossible to find out how big these are individually.
/* MEMP_NUM_PBUF: the number of memp struct pbufs. If the application
sends a lot of data out of ROM (or other static memory), this
should be set high. */
#define MEMP_NUM_PBUF 5
/* MEMP_NUM_UDP_PCB: the number of UDP protocol control blocks. One
per active UDP "connection". */
#define MEMP_NUM_UDP_PCB 6
/* MEMP_NUM_TCP_PCB: the number of simultaneously active TCP
connections. */
#define MEMP_NUM_TCP_PCB 5
/* MEMP_NUM_TCP_PCB_LISTEN: the number of listening TCP
connections. */
#define MEMP_NUM_TCP_PCB_LISTEN 5
/* MEMP_NUM_TCP_SEG: the number of simultaneously queued TCP
segments. */
#define MEMP_NUM_TCP_SEG 8
/* MEMP_NUM_SYS_TIMEOUT: the number of simulateously active
timeouts. */
#define MEMP_NUM_SYS_TIMEOUT 10
/* ---------- Pbuf dynamically allocated buffer blocks - for both TX and RX data ---------- */
// Two basic ideas are shown. The 8x512 is supposedly better than the commented-out one.
// The 512 byte mode will hold a full size packet in 3 buffers. The concatenation is
// automatic in LWIP. These two settings make NO difference to ETH speed.
/* PBUF_POOL_SIZE: the number of buffers in the pbuf pool. */
#define PBUF_POOL_SIZE 8
/* PBUF_POOL_BUFSIZE: the size of each pbuf in the pbuf pool. */
// If small, set it so that say 3 of them hold a complete largest packet (1500+stuff)
#define PBUF_POOL_BUFSIZE 512 // 1500 + PBUF_LINK_ENCAPSULATION_HLEN + PBUF_LINK_HLEN + PBUF_IP_HLEN + PBUF_TRANSPORT_HLEN
and some of the comments are probably wrong.
Thanks for the AMAP tip. It looks like a good tool. Unfortunately to lose say 30k I would need to replace all the functions in libc.a, or at least enough functions so that a whole .o module (the libc.a contains a load of these) can then be dropped by the linker. I don't think the linker can remove a part of a .o file. A compiler will remove unreferenced or unreachable code but I don't have the .c source for that ST libc.a library. So I would need to replace the scanf family, and the heap stuff, but that is working ok. Tracing code suggests that scanf is not using mutexes, which suggests the writer did not feel it needs thread protection (unlike printf where mutexes were used even if not the heap - e.g. %d invoked mutexes but not heap, while %l and %f invoked both). And on malloc and free I replaced the empty mutex stubs with a real (ex FreeRTOS) mutex, non recursive because I can't see who the hell would want recursive mallocs, so that should work, especially as almost nothing uses the heap now, and the only use now is for malloc and no free, which is safe. The only free() is within the TLS private heap, so that remains non deterministic but nothing can be done, and that whole heap gets chucked away when that HTTPS connection is closed.
If you have ideas on the lwipopts.h stuff I am very interested but I have already spent many days on it, with negligible effects. By far the biggest optimisation would be interrupt driven ETH RX, but how do people deal with an installation scenario where the product sees loads of traffic at the RJ45, and grinds to a halt?
Has anyone implemented packet filtering (by IP) at the low level ETH interface? A sort of primitive but fast firewall. The vast majority of ETH products need to respond to rx packets with just one destination IP.
