2

We have a program written in VBA that is running on Windows machines.

We have a very similar program written in ANSI C, using a Keil IDE and compiler that is running on an STR9x uP.

Our plans were to rewrite the VBA code in .NET using C#.

What is the feasibility of writing the shared code in C++ to be used on both systems? Obviously, the .NET framework would be off limits, but that isn't much of a concern. I'm wondering, specifically, about how labor intensive you think the compilation process might be.

This is kind of a theoretical question, I know, but thanks for any thoughts.

Community
  • 1
  • 1
qxn
  • 17,162
  • 3
  • 49
  • 72
  • 3
    What does the code do? This all depends on the interface. If it's a GUI framework, good luck. If it's, say, a math library, it should be easy. Any reason you can't stick with the ANSI C version on Windows? The STR9x is a pretty hefty beast, but you may also be interested in this question: [Is C++ suitable for embedded systems?](http://electronics.stackexchange.com/questions/3027/is-c-suitable-for-embedded-systems) – Kevin Vermeer Oct 07 '11 at 16:04
  • @KevinVermeer The code performs measurements on devices under test and makes decisions based on those measurements. The measurement methods differ depending on the platform, but I can abstract those differences away. I'm not a very good C programmer (the current production code is awful to look at), but I can try to get better if the general consensus is that ANSI C would be the best choice for both platforms. – qxn Oct 07 '11 at 21:09

2 Answers2

2

I do this a as general practice. I think a better question than "is it possible" is "how should I structure my code to be able to run on both an embedded system and also a PC".

I prefer to write the code in C and structure each file as a c++ class using static variables to make global variables private to the module. Create getter and setter functions to access the private variables. Also use function pointers which I set at initialization of the module for the methods the module need to call outside of the module.

It is also easy to refactor from the above structured c code to a class in c# or c++.

You can also use C++ directly but using it incorrectly on an embedded system can cause problems.

You will need a hardware abstraction layer if you are accessing any hardware. I separate my code into two types the first being code that has no reference to what it is running on and other code which I refer to as drivers.

I use this code for reusing modules for things like communication protocols. But more importantly I use it for testing. I like to use gtest to unit test the modules. I can also rewrite the drivers and simulate the hardware on a PC to be able to run it on the PC.

Rex Logan
  • 26,248
  • 10
  • 35
  • 48
  • "I prefer to write the code in C and structure each file as a c++ class using static variables to make global variables private to the module." --> Do you know of an example or blog post that describes this in more detail? Thanks. – qxn Oct 07 '11 at 21:10
2

Obviously, the .NET framework would be off limits

Not necessarily true. Given sufficient ROM and RAM resources (256K/64K respectively), the .NET Micro Framework will run on your device. However that is not necessarily a good reason to use it; there are already two other commonly used portable languages available for both your embedded target and Windows: C and C++. The target resource required for both C and C++ is minimal - C/C++ runtime start-up code can be well under 1K of code, almost all available resources can be utilised by your application code rather than the run-time environment.

The trick to utilising common code on both platforms is abstraction. This will involve at least hardware abstraction and possibly OS abstraction if your target is using any sort of kernel or scheduler such as an RTOS or thread library.

I'd recommend designing your embedded target with a layer architecture, having at least a device layer and an application layer and as mentioned already, possibly a system layer that deals with IPC, synchronisation and scheduling, if used. You may have other higher layer interfaces such as networking or filesystem that would equally benefit from abstraction. Note that standard APIs such as BSD sockets or stdio already count as abstraction, so if your target uses these, you have less work to do in Windows (minor differences between BSD Sockets and Winsock may still need some work)

The application layer will have no OS or hardware dependencies other than those accessible through the device and system layers. You must then implement the device and system layers on Windows as either a simulation or remapping to services or devices available on Windows. Some RTOS's already include Windows simulators for test and development, but defining your own OS API layer that you can port between a number of native RTOS and GPOS will allow your application code to be ported to different targets for both simulation and real-time execution very quickly.

Where the platform differences are minor and localised, and may not justify an abstraction layer, then target specific conditional compilation may be appropriate. Compilers support predefined macros for architecture, OS or compiler specific code that can be used for both this localised code and to make the abstraction layer code itself common where there is significant similarity.

Clifford
  • 88,407
  • 13
  • 85
  • 165