Understanding the meaning of Portability in Embedded System Programming


I am working on an embedded system project which requires converting an existing embedded C code (using RTOS) to a portable code. The project is currently in analysis phase.

As I am quite new to this field, so I would like to clarify few basic things about portability,

What does a portable code signify in general sense.
Does the portable code mean a 100% platform independent code that should work on any hardware + OS combination?
Does this mean a code that works on a specific set of OS and hardware.?
Does the portable code need to be compiled differently to work on different OS?
What is the standard approach followed to convert a code into platform independent code?

Any suggestions/information will be of great help.

Thanks & Regards,
Who is Participating?

[Product update] Infrastructure Analysis Tool is now available with Business Accounts.Learn More

I wear a lot of hats...

"The solutions and answers provided on Experts Exchange have been extremely helpful to me over the last few years. I wear a lot of hats - Developer, Database Administrator, Help Desk, etc., so I know a lot of things but not a lot about one thing. Experts Exchange gives me answers from people who do know a lot about one thing, in a easy to use platform." -Todd S.

Karrtik IyerSoftware ArchitectCommented:
I think portability for me as a developer means (given your example) that given the system requirements and high level architecture, it should clearly say what platforms and OS should the program should run on. Given this input, we would not ideally want to write and maintain software for different platform's and OS, hence whatever code we write should work across those OS's and platform's defined as much as possible with exceptions being discussed and agreed upon with the system architects and product owners.
As an architect, it would also mean that if I foresee some futuristic requirements that might arise because of which I would want the code to be as portable as possible given the insights we have for such requirements. But I am not in a position to think of a suitable example for embedded scenario. From application architecture perspective, I as an architect might foresee that supporting mobile platforms might be something that might be true in near future and not immediately but my high level architecture, design and code should be such that there is enough flexibility to easily support and scale my application to support such new platforms.
To answer your other questions:
    Does the portable code need to be compiled differently to work on different OS?
My comments: Compilation might be still required, however code change for different platforms and OS should not be necessary if code is portable.
    What is the standard approach followed to convert a code into platform independent code?
My comments: Use standard libraries (either those that come with tools set say C compiler or 3rd library such as BOOST) that provide facade or interfaces or wrappers over OS or platform specific code. Or if such interfaces or wrappers are not available, our design of our components is such that such code is hidden from all the users or developers who might need it and develop such a layer ourselves. Based on some settings  or rules (compiler or design), appropriate classes or components are picked up based on which platform it is getting built. The key thing being having uniform interface across all platforms and OS's.

Experts Exchange Solution brought to you by

Your issues matter to us.

Facing a tech roadblock? Get the help and guidance you need from experienced professionals who care. Ask your question anytime, anywhere, with no hassle.

Start your 7-day free trial
Karrtik IyerSoftware ArchitectCommented:
It would also mean using consistent primitive data types across different flavors of same OS to produce consistent results. (Using typedef's instead of actual type was very helpful when we did 32 bit to 64 bit porting)
Say int on 32 bit Windows OS might be different to what int is on 64 bit Windows OS.
So on 64 bit what int can hold might be equivalent to long on 32 bit ( just an example may not be correct as it is stated exactly). So if we are using a TCP/IP communication and if we are using int in 64 bit processes to communicate with each other, it might be able to send higher range of values while the same values may get truncated if the processes were a 32 bit process.
Hope it makes sense, although the example may not be very accurate, it is just highlight the possible complexity while porting.
Does this mean a code that works on a specific set of OS and hardware.?
even less. firstly it means that the code compiles, links and runs at the build platforms.

working code only could be verified by platform specific tests.

Does the portable code need to be compiled differently to work on different OS?
yes. there might be some portability between compilers for UNIX platforms but as a rule of thumb you have to build (compile and link) for each platform.

What is the standard approach followed to convert a code into platform independent code?
for c code you should use an ansi c compiler for each platform. and use STRICT mode if available to prevent from "flavors" which are not portable. doing so for all your own code, the non-portable parts of the application only should occur in precompiler statements and header files of foreign or os-specific libraries. you would try to solve these differences within platform-specific preprocessor blocks like '#ifdef WIN32  ... #endif' in header files. but don't use c code within those blocks beside of typedef's and declarations. if libraries are not compatible you should use a wrapper library for one or for all platforms such that you could use same portable interface for both. be aware that 'portable' means that you have to use the least common factor if platforms differ in functionality. all platform-specific add-on is no longer portable code but has to be handled as "customization" only at the platform where it worked.

Why Diversity in Tech Matters

Kesha Williams, certified professional and software developer, explores the imbalance of diversity in the world of technology -- especially when it comes to hiring women. She showcases ways she's making a difference through the Colors of STEM program.

>> •What does a portable code signify in general sense.
In addition to previous comments, one very important general issue is to consider how an embedded system communicates with other systems, either by file, or by sockets. Namely, endian issues come up to bite you.
One reason that protobufs and xml are so popular in communications is that they deal with endianess automatically, so that the developer has one less thing to worry about. Of course xml is rather slow when compared to protobufs since they represent structures in a structured text format.
Speaking of structures, here is another entity that has portability issues, partly for endianess issues mentioned above, but also for differences in the way the data members are packed into the struct.

If you are writing/reading to disk in only one embedded system, then packing should not be a portability problem. Otherwise, if one compiler packs differently than another, then obviously the data members will not line up properly in communicating, and the two systems will not be able to talk to each other very well.
It's more than this solution.Get answers and train to solve all your tech problems - anytime, anywhere.Try it for free Edge Out The Competitionfor your dream job with proven skills and certifications.Get started today Stand Outas the employee with proven skills.Start learning today for free Move Your Career Forwardwith certification training in the latest technologies.Start your trial today
Operating Systems

From novice to tech pro — start learning today.