Updating ChibiOS to a newer version is a common task for those project that are maintained for long periods.
ChibiOS version numbers are composed as follow:
year.month.patch. Patch number is increased for bug fixing only within the same branch. Year and month define the branch.
The rule is that within a released branch only bug fixes are performed unless a change is required for bug fixing.
New features and API changes only occur between branches.
All changes are listed in the change log (the
readme.txt file in the ChibiOS root). It is always a good idea to read in in case one of the fixes impacted a feature that is used in your project.
All bugs have a tracking number like
#789 which is used to find the ticket in our bug tracker on SourceForge. Note that ticket very often are also discussed in our Bug Reports forum, you may obtain more information reading both sources.
There are several distinct update cases:
Updating within the same branch just means replacing your old ChibiOS source tree with the new one. The rule is that versions have to be compatible unless a change is reported in the change log.
This is more complex because API changes can occur between major releases and new features are added. It can also happen that features are removed and replaced by better equivalents. ChibiOS is an alive project and it grows and changes.
There is not a single recipe for an upgrade but there are several rules that are always true and must be followed.
mcuconf.h. Also update files from the external projects (FatFS, lwIP etc).
It is hard to write a guide about this but some recommendations can be made:
ChibiOS has been developed for more than 10 years now and is a set of well balanced tools, adopting it as a whole can really make your life easier. Of course is also possible to just take bits and pieces, for example just the RT RTOS, and integrate it in your project to replace another RTOS, in this case you would not benefit from the rest of the ecosystem and you will need to take care of all integration details.