So I am migrating my application (fairly large, close to 100k LoC) from ChibiOS/RT 16 to ChibiOS/RT 18. Is there any write-up on the subject of porting from one version to a newer one? So far the only helpful resource I could find is the change log. Should I just stick to it?
The best documentation for ChibiOS that I know of is its source code (quite well-written I might add), but this form of documenting things lacks abstraction. The wiki and the articles seem quite dated. Perhaps there is some other place to look up documentation at that I don't know about?
v16 --> v17 --> v18 migration guide
- 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: v16 --> v17 --> v18 migration guide
Hi,
Last migration guide was from 2.6 to 3.0, the differences were significant during that transition,
Versions from 16 onward are almost stable as API, if you hit a difference then you would get a compile error. In general, if an API maintains the same name then the behavior is the same.
Changes are normally listed in the change log, if you read something about something you use then focus there. If in doubt about something just post here.
Edit: Make sure to take configuration files and Makefile from the version you are migrating too, this is the most important point.
Edit2: I will make an article with generic migration suggestions, this could help.
Giovanni
Last migration guide was from 2.6 to 3.0, the differences were significant during that transition,
Versions from 16 onward are almost stable as API, if you hit a difference then you would get a compile error. In general, if an API maintains the same name then the behavior is the same.
Changes are normally listed in the change log, if you read something about something you use then focus there. If in doubt about something just post here.
Edit: Make sure to take configuration files and Makefile from the version you are migrating too, this is the most important point.
Edit2: I will make an article with generic migration suggestions, this could help.
Giovanni
- 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:
- Spym
- Posts: 45
- Joined: Tue Oct 15, 2013 10:20 am
- Location: Tallinn, Estonia
- Has thanked: 2 times
- Been thanked: 3 times
- Contact:
Re: v16 --> v17 --> v18 migration guide
Thank you, this is helpful. However, it would be even better if there was something like a changelog on steroids for every new release, explaining what exactly to look out for and such. Like this: http://wiki.ros.org/kinetic/Migration
Re: v16 --> v17 --> v18 migration guide
I second this. My biggest issue is not changes in the API - as Giovanni says they are relatively stable and in any event compiler errors help a lot.
The absolute killer for me is the build system - I have many, many projects with Makefiles based on v16 and they simply don't work with the v18 code based checked out so it looks like a complete re-write which is utterly painful.
Some documentation on that would be much appreciated as, being very frank, I just can't face the nightmare it's causing at the moment......
The absolute killer for me is the build system - I have many, many projects with Makefiles based on v16 and they simply don't work with the v18 code based checked out so it looks like a complete re-write which is utterly painful.
Some documentation on that would be much appreciated as, being very frank, I just can't face the nightmare it's causing at the moment......
Re: v16 --> v17 --> v18 migration guide
avrhack wrote:The absolute killer for me is the build system - I have many, many projects with Makefiles based on v16 and they simply don't work with the v18 code based checked out so it looks like a complete re-write which is utterly painful.
I haven't run v18 yet, but for v16 to v17 I just compared my makefile with that from the nearest v18 sample project - it was usually pretty obvious what needed changing.
(My main issue with migrating is checking that various non-standard drivers still work OK - usually not a problem, but still has to be checked)
- wurstnase
- Posts: 121
- Joined: Tue Oct 17, 2017 2:24 pm
- Has thanked: 43 times
- Been thanked: 30 times
- Contact:
Re: v16 --> v17 --> v18 migration guide
The only thing I've seen with immigrating from <v18 for drivers is the (size_t)0 for the VMT. I'm pretty new to ChibiOS, so maybe there are others.
I'm using the chprintf to print stuff on my display, by implementing a put function. So my driver needs now also the (size_t)0 on top of the struct.
What is the reason for the (size_t)0?
I'm using the chprintf to print stuff on my display, by implementing a put function. So my driver needs now also the (size_t)0 on top of the struct.
What is the reason for the (size_t)0?
\o/ Nico
- 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: v16 --> v17 --> v18 migration guide
Hi,
It is the offset between the VMT address and the base of the containing object, it is required by a new multiple inheritance mechanism that allows objects to present multiple interfaces.
When there is a single interface then the offset is always zero.
Giovanni
It is the offset between the VMT address and the base of the containing object, it is required by a new multiple inheritance mechanism that allows objects to present multiple interfaces.
When there is a single interface then the offset is always zero.
Giovanni
Return to “Development and Feedback”
Who is online
Users browsing this forum: No registered users and 56 guests