This is a list of "simple" things that would be nice to have but not exactly high priority.

- Makefile support for GHS, CW, IAR and Keil (writing a rules.mk, a Makefile template and linker files).- Device memory map description in an XML file with generation of linker files for the various compilers.- Update the ChibiOS plugin to use the new Eclipse debugger API used in Neon.- OpenOCD in a PPA for easier Linux support.

I would like to see some further features regarding the test functions. For my own tests, I have introduced a preprocessor define so I can easily deactivate the tests in a ways that the compiler will completely skip the code which keeps the binary size reasonable small (especially since my tests come with a lot of output). As far as I understand it the only way not to compile the ChibiOS/RT tests is to remove $(TESTSRC) from CSRC in the Makefile, which is quite inconvenient imo.Furthermore, these tests just print their results to the given stream (see test/lib/ch_test.c: test_execute()) and a bool value is returned. A data structure where detailed information is stored would be nice so the results can be further evaluated by custom tools.

The struct where to store the results should be an optional argument as well for most flexible use, I think.People who just want to see the output, only set the stream argument and leave the output buffer NULL. People who only need the results keep the stream NULL and set a buffer. People who need both, set both. People who need nothing.... well, even for these there would be an option

Several STM32 products (e.g. F4) have multiple memory regions that are not continuous and have different capabilities (i.e. some can be accessed via DMA, others can not). Maybe these multiple memory regions can be represented some way. Honestly, I have no idea how the memory layout should or can be represented, but maybe someone else has

Several STM32 products (e.g. F4) have multiple memory regions that are not continuous and have different capabilities (i.e. some can be accessed via DMA, others can not). Maybe these multiple memory regions can be represented some way. Honestly, I have no idea how the memory layout should or can be represented, but maybe someone else has

Thomas

There's already some support for this in scatter files, coupled with use of appropriate directives in the source files to force variables to specific areas.

Detailed heap tracking and monitoring diagnostics.Primarily I'm thinking of an option to enable a callback within each of the heap management routines, which is passed the following information:

Action (allocate, free etc...) - suggest as individual bits, so actions of no interest can easily be masked out

Calling thread reference

Heap location reference

Block size

This could be augmented with a default handler which dumps the information to a BaseSequentialStream.

It would also be useful to have an API to analyse aspects of the heap - for example, a way of tracking along the 'free list' getting the memory address and block size (to help identify fragmentation problems).

I've not yet got beyond the default heap allocator myself, but there may need to be some extension to handle different allocation mechanisms.

Several STM32 products (e.g. F4) have multiple memory regions that are not continuous and have different capabilities (i.e. some can be accessed via DMA, others can not). Maybe these multiple memory regions can be represented some way. Honestly, I have no idea how the memory layout should or can be represented, but maybe someone else has

Thomas

There's already some support for this in scatter files, coupled with use of appropriate directives in the source files to force variables to specific areas.

I know, but that is still quite cumbersome imo. I would hope that there is a better way than using explicit compiler directives, like

As for your notes regarding heap monitoring: For real-time applications you should not use any dynamic memory allocation anyway, but use either static memory or memory pools. Neither will result in fragmentation (although pools might in some way) and your system still is deterministic. While the use of memory pools might result in a livelock, there are all the API functions you need to prevent this and monitor pools already.

Thargon wrote:As for your notes regarding heap monitoring: For real-time applications you should not use any dynamic memory allocation anyway, but use either static memory or memory pools. Neither will result in fragmentation (although pools might in some way) and your system still is deterministic. While the use of memory pools might result in a livelock, there are all the API functions you need to prevent this and monitor pools already.

I strongly support the sentiment; however I'm using various pieces of third party software (e.g. fatFS) which use the conventional malloc() and free() interface and which I'd prefer not to rewrite. And with RAM being relatively tight on embedded systems, allocating fixed length areas for strings such as file names is likely to be quite wasteful . Hence the desire to avoid solving a problem I may not have!