[NOTE] Things nice to have

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome.
User avatar
Giovanni
Site Admin
Posts: 10134
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 205 times
Been thanked: 183 times
Contact:

[NOTE] Things nice to have

Postby Giovanni » Mon Jun 12, 2017 7:47 am

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

Thargon
Posts: 46
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 3 times
Been thanked: 2 times

Re: [NOTE] Things nice to have

Postby Thargon » Mon Aug 14, 2017 10:08 am

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

User avatar
Giovanni
Site Admin
Posts: 10134
Joined: Wed May 27, 2009 8:48 am
Location: Salerno, Italy
Has thanked: 205 times
Been thanked: 183 times
Contact:

Re: [NOTE] Things nice to have

Postby Giovanni » Mon Aug 14, 2017 4:57 pm

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

Thargon
Posts: 46
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 3 times
Been thanked: 2 times

Re: [NOTE] Things nice to have

Postby Thargon » Mon Aug 14, 2017 5:41 pm

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 ;)

Tabulous
Posts: 418
Joined: Fri May 03, 2013 12:02 pm
Has thanked: 1 time
Been thanked: 10 times

Re: [NOTE] Things nice to have

Postby Tabulous » Tue Aug 15, 2017 11:16 am

1) Window watchdog driver for STM32
2) Implement RTC backup memory STM32

Thargon
Posts: 46
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 3 times
Been thanked: 2 times

Re: [NOTE] Things nice to have

Postby Thargon » Tue Aug 15, 2017 1:16 pm

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

steved
Posts: 429
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 3 times
Been thanked: 28 times

Re: [NOTE] Things nice to have

Postby steved » Tue Aug 15, 2017 1:28 pm

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.

steved
Posts: 429
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 3 times
Been thanked: 28 times

Re: [NOTE] Things nice to have

Postby steved » Tue Aug 15, 2017 1:36 pm

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.

Thargon
Posts: 46
Joined: Wed Feb 04, 2015 5:03 pm
Location: CITEC, Bielefeld University, germany
Has thanked: 3 times
Been thanked: 2 times

Re: [NOTE] Things nice to have

Postby Thargon » Tue Aug 15, 2017 2:28 pm

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.

steved
Posts: 429
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 3 times
Been thanked: 28 times

Re: [NOTE] Things nice to have

Postby steved » Tue Aug 15, 2017 3:12 pm

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: Bing [Bot] and 3 guests