Hi,
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.
Giovanni
[NOTE] Things nice to have
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
-
- Posts: 135
- Joined: Wed Feb 04, 2015 5:03 pm
- Location: CITEC, Bielefeld University, germany
- Has thanked: 15 times
- Been thanked: 24 times
- Contact:
Re: [NOTE] Things nice to have
Hi,
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.
That's it for now
Best regards,
Thomas
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.
That's it for now
Best regards,
Thomas
- Giovanni
- Site Admin
- Posts: 14457
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: [NOTE] Things nice to have
Hi,
The data structure could be easily added to the test runtime, good idea. I would also make it able take NULL as output stream if an output is not required.
Giovanni
The data structure could be easily added to the test runtime, good idea. I would also make it able take NULL as output stream if an output is not required.
Giovanni
-
- Posts: 135
- Joined: Wed Feb 04, 2015 5:03 pm
- Location: CITEC, Bielefeld University, germany
- Has thanked: 15 times
- Been thanked: 24 times
- Contact:
Re: [NOTE] Things nice to have
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
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
-
- Posts: 135
- Joined: Wed Feb 04, 2015 5:03 pm
- Location: CITEC, Bielefeld University, germany
- Has thanked: 15 times
- Been thanked: 24 times
- Contact:
Re: [NOTE] Things nice to have
talking about backup memory...
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
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
Re: [NOTE] Things nice to have
Thargon wrote:talking about backup memory...
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.
Re: [NOTE] Things nice to have
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:
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.
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.
-
- Posts: 135
- Joined: Wed Feb 04, 2015 5:03 pm
- Location: CITEC, Bielefeld University, germany
- Has thanked: 15 times
- Been thanked: 24 times
- Contact:
Re: [NOTE] Things nice to have
steved wrote:Thargon wrote:talking about backup memory...
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
Code: Select all
PRIMARY_DMA_MEM {
some_data_t data;
something_else_t else;
void methods_are_ignored() {
...
}
}
CCM_MEM {
...
}
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.
Re: [NOTE] Things nice to have
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!
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 53 guests