views:

68

answers:

2

Our desktop application consists of a Mono/.NET 3.5 back end that communicates via USB with a variety of devices and a Silverlight front end that communicates with the back end via sockets. The firmware for the devices is developed in-house with C. To accelerate our development process and reduce bugs, we would like to share code between our firmware and desktop application. What tools and techniques would you suggest for us to be able to do this? Better yet, what have you successfully used in your software to solve a similar problem?

The two main things we'd like to share are the message structures that define our communication protocol and data that is currently defined through C structure/array constants. For the protocol messages, we're currently manually rewriting our message-implementing classes to match the C definitions, using the C code as a guide. For the data we share, we created a managed C++ application that links to the compiled C code then extracts the arrays' contents into an XML file.

Our techniques work, but they are less than optimal. For one, we had a multitude of bugs related to our reinterpretation of C structures as C#, due to the C code changing in parallel and programmer mistakes; we'd like to avoid this class of bugs in future development. For data sharing, I don't have a huge problem with our current solution, but the maintainer of the extraction program says that it's a painful process getting that to work properly.

We're a bit constrained on things we'll be able to change on the firmware for the devices. For one, we have a wide variety of processor architectures and embedded platforms, so the C code must remain portable. For another, the firmware runs real-time software and is constrained on available MIPS and storage space, so we cannot add anything with unpredictable or slow execution time.

+2  A: 

I would consider using XSLT transformation for code generation. Have an XML that defines the protocol structures and have various XSLTs that generate the C# and the various platforms C code. Then use the generated code in building the applications.

The XSLT transform can be made part of the project build, I used this technique on several projects as described in Using XSLT to generate Performance Counters code (although that post is not about comm protocols, I actually used the same technique on comm protocols, both as wire and between modules). Once you get over the difficulties to getting up to speed in writing XSL and XQuery, you'll become very productive and you'll appreciate how easy and fast you can change the communication protocol.

Remus Rusanu
Thanks for the suggestion. This is a possibility I've been considering. The main hurdle is the firmware developers' distaste for XML, though I'm sure they'd do it if they were properly convinced of the benefits.
Jacob
Well XML would be involved only during code generation, not at all in the firmware runtime.
Remus Rusanu
I tried having a look at XSLT, but found it to defy easy comprehension and usage. So I'd not be keen on that solution. But the general concept, of expressing the protocol in some generic format, and then processing it to generate C and C# code, seems worth pursuing.
Craig McQueen
@Craig McQueen: some prefer perl. Personally, after a rough start with XSL practice, I can say I'm quite happy with it now.
Remus Rusanu
I really like XSLT, but I decided that Protobuf might be the better choice, especially since so few grok XSLT.
Jacob
+2  A: 

Try protocol buffers, which is a binary, programming language-agnostic encoding format that Google uses as data exchange format between their services.

The idea is that you write a .proto file that describes structure of your data and run protocol buffers compiler which generates serialization/deserialization code for your language. This would be more efficient that encoding in XML and save the time of writing serializers/deserializers by hand and eliminate mistakes due to incorrect implementation (since they're auto-generated from high-level description in the case of protocol buffers).

Google's implementation supports C++, Java and Python and there are independent implementation for other languages, e.g. for C# there is this one and this one.

There are other technologies like that, e.g. Facebook's Thrift.

Krzysztof Kowalczyk
I love protocol buffers! We're using that for the socket communication between the Mono back-end and our Silverlight front-end. Unfortunately, the firmware is written in C, not C++, and there doesn't appear to be any C implementations.
Jacob
Bah, never mind. Apparently there IS a C implementation here: http://code.google.com/p/protobuf-c/.
Jacob