Is it smart to output data from an embedded device in xml format?

Question

Our company makes many embedded devices that communicate with the PC through the applications that I write in C # .net. I’m considering various ways to improve data transfer so that the PC application can be more easily synchronized with the current state of the devices (which in some cases is constantly changing).

I was thinking of an approach when a device formats its description and status messages into an XML-formatted message before sending them via a serial port, USB, Ethernet socket, etc. I thought that it could make the process all of this data into my C # classes simpler.

An alternative is the approach in which the host application sends a command similar to GETSTATUS, and the device responds with an array of bytes, each of which represents a different property, reading the sensor, etc.

I don't have much experience with xml, but from what I saw can be done with LINQ to XML, it seems like this might be a good idea. Guys, what do you think? Is this something that is usually done? Is this a terrible idea?!?

Answer 1

First, whatever you do, make sure that the returned data has a built-in version number so that you can review the data structure.

Is there an option? Seriously, there are always situations where it is preferable to send data in a more readable form and others where a denser idea is better (this is less than many people think, but I do not want to start a religious war about it). People will argue passionately for both because they optimize for different things. Providing both options would satisfy both camps.

Good, clean XML status can definitely lower the bar for people who start working with your devices. You can also create a C # object that can be deserialized from the returned binary data.

Answer 2

This is not a scary idea, but it is probably a reevaluation. I would prefer to use a format that the embedded device will generate easier and faster. Then on the PC side I inserted a layer to convert it to a convenient format. You can also use LINQ with objects. Why not send the data in binary form or in a simple ASCII protocol and then convert it to C # objects? You can use LINQ to access data. In my opinion, in this case, XML introduces unnecessary complexity.

Answer 3

There are tradeoffs anyway, so the right choice depends on your application, on how powerful your device is and who will use this protocol.

You note that the alternative is a binary-serialized request-response approach. I think there are two different aspects here: serialization format (binary or XML) and communication style. You can use any serialization format that you want either in the push protocol or in the request-response protocol.

XML can be a good choice if

• Reading is important
• If there is a difference between devices, i.e. if you have different devices that have different properties, because XML tends to be self-describing.
• Or if you want to publish your device data on the Internet.

Of course, XML is verbose, and, of course, there are ways to accomplish all of the above using a binary protocol (for example, using marked values ​​can be used to make your binary protocol more descriptive).

Answer 4

One of the founders of this site itself has reasonable and funny opinions on XML in XML: Angle bracket tilt.

Answer 5

I did something very similar in a previous project from a PC to microprocessor communication using the XML format. It worked very well on the PC side, since Adobe Flex (which we used) could interpret XML very easily, and I suspect that .NET can do the same very easily.

The more complex part was on the microprocessor side. XML parsing had to be done manually, which was not so difficult, but just intense. Creating an XML string can also be quite a bit of code depending on what you are doing.

Overall - If I had to do this again, I still think XML is a good choice because it is a very flexible protocol. RAM wasn't a big issue regarding storing multiple packets in our FIFO buffer on the microprocessor side, but it might be something to consider in your application.

Answer 6

It is a waste of valuable processor embedded time to generate and transfer XML files. Instead, I would just use an array of binary bytes representing the data, but I would use structures to help interpret the data. The C # struct function makes it easy to interpret an array of bytes as meaningful data. Here is an example:

[StructLayout(LayoutKind.Sequential, Pack = 1)] public struct DeviceStatus { public UInt16 position; // Byte 0 and 1 public Byte counter; // Byte 2 public Fruit currentFruit; // Byte 3 }; enum Fruit : Byte { Off = 0, Apple = 1, Orange = 2, Banana = 3, } 

Then you will have a function that converts your byte array into this structure:

 public unsafe DeviceStatus getStatus() { byte[] dataFromDevice = fetchStatusFromDevice(); fixed (byte* pointer = dataFromDevice) { return *(DeviceStatus*)pointer; } } 

Compared to XML, this method will save processor time on the device and on the PC, and it is easier to maintain than the XML scheme, with additional functions for building and analyzing the XML file. All you have to do is make sure that the definitions of struct and enum in your embedded device match those of your C # code so that the program and C # device agree on the protocol used.

You will probably want to use the “packed” attribute in both C # and the built-in side, so that all elements of the structure are arranged in a predictable way.