In this two part article we will look at the differences between porting and abstracting code with the purpose of helping you understand why and when to use each method. In the case where you need your code to execute on multiple embedded operating systems (platforms), it is almost guaranteed that you will need to adjust your code for each platform. Each platform has its own system call interface (or software development kit) that is accessed through code using differing protocols, sometimes even for the same functionality. In other cases, your target platform may not include certain functionality or may include additional functionality that could be used to enhance your platform.
Source
Porting
Most embedded systems have tight memory constraints. You must determine how much memory your embedded system allows (i.e. how much and what type of RAM is supported). Then, there are two factors to consider 1) what memory is required by the RTOS itself and 2) how much memory your application requires. For the second factor, you may need to utilize an RTOS simulator (most RTOSs come with one) to gain an accurate estimation, which is especially important if you are working with a severely limited system.
Currently there are two options available for porting: 1) manual adjustment of your code and 2) commercial automated solutions. Option 2 was born out of a need to reduce costs and shorten time to market. Note that with option 2, you will still need to manually adjust portions of your code if you are utilizing new functionality from your target platform. To help determine which option is best for your project, consider the following questions:
- What is your budget?
Determine how much it would cost to manually port the software. Then, determine how much it would cost to purchase a commercial solution. For the latter, be sure to account for the time to learn and implement the system.
- What is your timeframe to get to market?
Determine how many man-hours are required to manually port the software. Then, determine how many man-hours are required to learn and implement a commercial solution.
- How many platforms do you need to support?
Use this number to multiply your costs and man-hours. If you are going to use a commercial solution, find out if they support the required platforms.
- Is the functionality of your current platform duplicated on the target platform?
If there is a clear one-to-one mapping of functionality, you have a greater opportunity to automate the entire port. If not, you will need to account for additional man-hours to manually port those functions. This assumes that you can work around the limitations of the target platform.
- Will you be adding any new functionality based on the new targeted platform?
In this case, even if you choose a automated solution, you will need to account for the man-hours required to implement the new functionality.
Once you have determined the answers to these questions, you will have the data you need to determine which porting method is best for your project.
In part 2 of this article we will consider abstraction and offer some final considerations for both options.