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()
New feature suggestions - consolidated list
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: New feature suggestions - consolidated list
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
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
Re: New feature suggestions - consolidated list
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)
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: New feature suggestions - consolidated list
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
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
- FXCoder
- Posts: 384
- Joined: Sun Jun 12, 2016 4:10 am
- Location: Sydney, Australia
- Has thanked: 180 times
- Been thanked: 130 times
Re: New feature suggestions - consolidated list
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
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
Re: New feature suggestions - consolidated list
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).
- Giovanni
- Site Admin
- Posts: 14455
- Joined: Wed May 27, 2009 8:48 am
- Location: Salerno, Italy
- Has thanked: 1076 times
- Been thanked: 922 times
- Contact:
Re: New feature suggestions - consolidated list
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
Giovanni
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 15 guests