New feature suggestions - consolidated list

This forum is dedicated to feedback, discussions about ongoing or future developments, ideas and suggestions regarding the ChibiOS projects are welcome. This forum is NOT for support.
steved
Posts: 671
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 8 times
Been thanked: 96 times

New feature suggestions - consolidated list

Postby steved » Fri Nov 22, 2019 9:49 am

With a new Chibi version in due course, I thought I would bring together my 'wish list' - many of them have already been mentioned in posts by myself or others.

Makefile Changes
================
Specify (and select) compiler version
- Avoids risk of using wrong version
- Simplifies management of things like the M0 optimisation bug
- Improves maintainability/repeatability - compiler version firmly associated with project


Debug/Release Compile option
============================
a) Within 'standard handling':
- Potentially extended hardware initialisation in debug mode (cannot assume hardware is in reset state)
- Different optimisation levels (-O0 or -Og in debug mode, -O2 in release)
- Different postprocessing (if relevant)
- Control over inbuilt debugging and handlers
b) For users:
- Different postprocessing options
- Control over debug features in code
- Controlling things such as password protection on access


Helpers
=======
1. When a function or feature is removed/changed which affects prior usage, have a macro generate an error message which points to the alternative (rather than getting a generic error message from the compiler/linker, such as 'undefined symbol' or similar)
2. Similarly, when a function is only available on some processors, give a clear "Not supported on this hardware" message (e.g. chSysPolledDelayX)
3. A macro to convert intervals to clock counts for chSysPolledDelayX() (or is there one I haven't found?)


Board Definition
================
At present board.c is auto-generated, yet includes functions which may need to be filled in by the user. These changes could easily get lost. Similarly, the __early_init() function may need modification, and there may be other code which should logically be in board.c. Perhaps auto-generate a file which is to be included in board.c, and don't touch board.c? (Changing the template isn't a 2-minute job, and its also quite likely that different boards may use the same processor but require different modifications).


Lockup handling
===============
a) There are some tight loops which only complete when the correct status is reached (e.g. there's one in the qspi driver). These should use the capabilities of the new 'Functional Safety Elements' to ensure they always time out; maybe selected with a #define. As for the action on timeout, probably an optional callback is the simplest way to handle it (my provisional intent would be to store the address of the caller, to look at off-line). If the callback returns, normal (error) processing is resumed. For peripherals, the callback address could be an additional field in the configuration structure (maybe with a global option to enable it).

b) There is a disadvantage to an assert, which is that the entire processor stops. It may be that the faulting thread is peripheral to the main function of the code, so minimal functionality is lost if it is stopped (in preference to stopping the whole processor). I realise it's possible to override the handlers; however a 'standard' alternative to just signal in some way and terminate/block the current thread could be advantageous.


'Absolute action' functions
===========================
I use this term to describe functions which clearly indicate the required end result, and where the previous state is of no concern. A simple example is stopping a peripheral; if I call i2cStop(), for example I would expect (assuming valid parameters passed) the peripheral to be unconditionally disabled, and left in a state where a call to i2cStart() reliably starts things going. Regardless of its current state. I would only expect abnormal behaviour (such as locking up on an assert) if the required end result cannot be achieved. At present peripheral drivers often check state in a way which unnecessarily asserts.


Naming
======
Ideally all Chibi functions should have 'unlikely' names, primarily to avoid clashes with user functions (e.g. I recently ended up with two implementations of 'flashProgram()' which did different things) Prefixing with 'ch' seems an obvious solution, and also helps identify the author (and hence location) of the code.


ChibiStudio
===========
Including the interrupt stack free space in the 'thread' list (or elsewhere) could be useful


Other
=====
hal_lld_init() would benefit from being a weak symbol, to allow override of the hardware initialisation.
(A consequence of this is that hal_lld_backup_domain_init() needs to be declared external, so that any modified hal_lld_init() can call it).

Virtual timers - function to return unexpired time could be useful (e.g. in assessing how much slack there is on a timeout for an operation). The value could be returned by chVTReset()

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

Re: New feature suggestions - consolidated list

Postby Giovanni » Fri Nov 22, 2019 3:08 pm

Hi,

Just a note about board files, you can include the code snippets in the .chcfh XML file, board.c is generated already with code inside.

The Safety Elements is to be decided, I hoped to offer those commercially, in this case HAL cannot have a direct dependency on that because HAL is free. If it will not become a commercial product then it will be simply become part of HAL.

Compiler version, how to select the version? compiler name does not contain a version number and paths are defined outside the Makefile.

About the other points, to be evaluated case by case.

Giovanni

steved
Posts: 671
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 8 times
Been thanked: 96 times

Re: New feature suggestions - consolidated list

Postby steved » Sat Nov 23, 2019 12:14 am

Giovanni wrote:Hi,
Compiler version, how to select the version? compiler name does not contain a version number and paths are defined outside the Makefile.

For the compiler, its largely a matter of selecting a top-level directory, and the path to that is straightforward in a standard ChibiStudio installation. For example:
../../tools/GNU Tools ARM Embedded/7.0 2017q4

(I use a similar construct to determine the version of ChibiOS to use)

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

Re: New feature suggestions - consolidated list

Postby Giovanni » Sat Dec 07, 2019 10:54 am

Hi,

About the normal/debug options, wouldn't be possible to simply have 2 or more makefiles? Makefile_deploy, Makefile_debug, Makefile_experimental etc?

We already do this for multi target applications, it would be no different?

About compiler selection, I don't like the idea to bring paths in Makefiles, there are different platforms to consider with different path conventions. What about adding a new setting COMPILER_PATH, if left empty (or not present) then it would work as it is now, if a path is specified then it would use the compiler there.

Giovanni

User avatar
FXCoder
Posts: 241
Joined: Sun Jun 12, 2016 4:10 am
Location: Sydney, Australia
Has thanked: 91 times
Been thanked: 74 times

Re: New feature suggestions - consolidated list

Postby FXCoder » Sat Dec 07, 2019 1:43 pm

Hi,
The ChibiOS make system works very well for me.
But being able to specify a toolchain at a target's makefile level in a multi-target project would be helpful.

For example...
I have a project which builds variants from a substantial common code base to different board/MCU targets.
Software and hardware features, LLDs, etc. for a target MCU & board are defined by portab.h in the cfg folder for the target.
All target files (LLDs, portab.c, etc.) unique to a target are in that target's cfg folder.
LLDs etc can be built as required using the .mk method used extensively in ChibiOS system build.

Then the majority common project code (sections of which may be conditionally used) is in an AUTOBUILD source folder.
Very nice feature Giovanni I would like to say.

The make setup I have arranged in Eclipse allows for just one target out of the multiple available in a project to be built or cleaned.
I pass in the Eclipse config name in a make var to the top level make and that determines which target makefile is used.

That's all good and works nicely except where differing targets may need different GCCs (e.g the M0 GCC 5.4 case).
GNU_MCU and XPACKs (allowing toolchain to be set per project) is partially helpful by switching toolchains via GNU_MCU.
However, apart from the nuisance of having to switch toolchains the real downfall currently is that not all GCCs are there in XPACK form - e.g. GCC 5.4).

The nuisance would be overcome by makefile level compiler selection which would override the default path or that that set by GNU_MCU as/when required...
--
Bob

steved
Posts: 671
Joined: Fri Nov 09, 2012 2:22 pm
Has thanked: 8 times
Been thanked: 96 times

Re: New feature suggestions - consolidated list

Postby steved » Sun Dec 08, 2019 4:51 pm

Giovanni wrote:Hi,

About the normal/debug options, wouldn't be possible to simply have 2 or more makefiles? Makefile_deploy, Makefile_debug, Makefile_experimental etc?
We already do this for multi target applications, it would be no different?
Giovanni

Maybe I'm demonstrating how little I know about configuring Eclipse here, but the debug/release concept is a bit different to the multi-target application. IIRC multi-target always make for all the targets. This can be time-consuming for a big project. Another Eclipse-based development platform I use implements debug/release - where you select which you are compiling for. The 'visible' differences are:
[list=][*]The compiled output goes to a different project subdirectory
[*]'Release' code cannot be debugged - at least breakpoints do not work
[*]different libraries are invoked (the equivalent in Chibi would probably be different compile options.). Presumably some of these do additional checks, or handle errors differently, in debug mode
[*]A __DEBUG_ON__ #define or similar, so that application code can also handle the two modes differently
[*]Release code is smaller [/list]
The objective is to allow quick selection of two different compilation scenarios. Things which might be affected in a Chibi environment include:
[list=][*]Selection of optimisation level (-O0 or -Og for debug, -O2 for release, as defaults
[*]Different debug options in chconf.h (not necessarily all on or all off; two different lists according to mode)
[*]Different error handling - verbose mode to make debugging easy, and a terse mode for release[/list]
As before, the application programmer can also select different actions in the two modes.

All this can of course be achieved already, but IMO its one of those things where an 'official' solution would be preferable.

Giovanni wrote:About compiler selection, I don't like the idea to bring paths in Makefiles, there are different platforms to consider with different path conventions. What about adding a new setting COMPILER_PATH, if left empty (or not present) then it would work as it is now, if a path is specified then it would use the compiler there.

I think this is roughly as I envisaged, so that the compiler version to use is firmly associated with the project (in the same way as is done for the Chibi library already. (As Bob says, useful for handling platform differences, and another step on the safety/integrity path by pretty much eliminating the risk of compiling a project with the wrong compiler version).

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

Re: New feature suggestions - consolidated list

Postby Giovanni » Sun Dec 08, 2019 5:27 pm

Just a note, in Eclipse you can build/clear just one of the configurations, try a multi target demo, the "Default" configuration builds all of them but you can select one configuration and work with just that.

Giovanni


Return to “Development and Feedback”

Who is online

Users browsing this forum: No registered users and 2 guests