从嵌入式设备以 xml 格式输出数据是否明智?

发布于 2024-10-03 17:03:42 字数 390 浏览 2 评论 0原文

我们公司生产许多嵌入式设备,这些设备通过我用 C#.net 编写的应用程序与 PC 进行通信。我一直在考虑改进数据传输的不同方法,以便 PC 应用程序可以更轻松地与设备当前状态(在某些情况下不断变化)同步。

我一直在考虑一种方法,其中设备将其描述和状态消息格式化为 xml 格式的消息,然后再通过串行端口、USB、以太网套接字等发送它们。我在想,它可能会完成获取所有信息的过程将这些数据放入我的 C# 类中更加简单。

另一种方法是主机应用程序发送像 GETSTATUS 这样的命令,设备以字节数组进行响应,每个字节代表不同的属性、传感器读数等。

我对 xml 没有太多经验,但从什么角度来看我已经看到可以使用 LINQ to XML 来完成,这似乎是一个好主意。你们觉得怎么样?这是常见的事情吗?这是一个可怕的想法吗?

Our company makes many embedded devices that communicate with PC's via applications that I write in C#.net. I have been considering different ways of improving the data transfer so that the PC application can be more easily synchronized with the devices current state (which in some cases is continually changing).

I have been thinking about an approach where the device formats it's description and state messages into an xml formatted message before sending them across either the serial port, USB, Ethernet Socket, etc. I was thinking that it may make the process of getting all of this data into my C# classes more simple.

The alternative is an approach where the host application sends a command like GETSTATUS and the device responds with an array of bytes, each representing a different property, sensor reading, etc.

I don't have a great deal of experience with xml but from what I have seen can be done with LINQ to XML it seems like it might be a good idea. What do you guys think? Is this something that is done commonly? Is it a horrible idea?!?

如果你对这篇内容有疑问,欢迎到本站社区发帖提问 参与讨论,获取更多帮助,或者扫码二维码加入 Web 技术交流群。

扫码二维码加入Web技术交流群

发布评论

需要 登录 才能够评论, 你可以免费 注册 一个本站的账号。

评论(6

南烟 2024-10-10 17:03:43

首先,无论采用哪种方式,请确保返回的数据嵌入了版本号,以便您可以修改数据结构。

两者都是一个选择吗?说真的,在某些情况下,以更易读的形式发送数据是更好的,而在其他情况下,更密集的表示是最好的(这些比大多数人想象的要少,但我不想为此引发一场宗教战争)。人们会热情地争论两者,因为他们正在针对不同的事物进行优化。提供这两种选择将使两个阵营都满意。

良好、清晰的 XML 状态肯定可以降低开始使用您的设备的人员的门槛。您还可以构建一个可以从返回的二进制数据反序列化的 C# 对象。

First, which ever way you go, make sure the returned data has a version number embedded so that you can revise the data structure.

Is both an option? Seriously, there are always situations where sending data in a more readable form are preferable, and others where a more dense representation is best (these are fewer than most people think, but I don't want to start a religious war about it). People will passionately argue for both, because they are optimizing for different things. Providing both options would satisfy both camps.

A nice, clear XML status could definitely lower the bar for people who are starting to work with your devices. You could also build a C# object that can be deserialized from the binary data that is returned.

冰之心 2024-10-10 17:03:43

这不是一个糟糕的想法,但它可能是一种过度设计。我更喜欢使用嵌入式设备更容易、更快生成的格式。然后在 PC 端我会插入一个图层以将其转换为方便的格式。您还可以将 LINQ 与对象一起使用。为什么不以二进制形式或简单的 ASCII 协议发送数据,然后将其转换为 C# 对象?您可以使用 LINQ 来访问数据。我认为,在这种情况下,XML 引入了不必要的复杂性。

It isn't a terrible idea, but it is probably an overdedesign. I would prefer to use a format that the embedded device will generate easier and faster. Then at the PC side I would insert a layer to conver it to a convenient format. You can also use LINQ with objects. Why don't 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 the data. In my opinion, in this case XML introduces an unnecessary complexity.

乖乖哒 2024-10-10 17:03:43

无论哪种方式都需要权衡,因此正确的选择取决于您的应用程序、您的设备的强大程度以及谁将使用该协议。

您提到替代方案是二进制序列化的请求响应方法。我认为这里有两个独立的维度:序列化格式(二进制或XML)和通信风格。您可以在推送协议或请求响应协议中使用您想要的任何序列化格式。

,那么XML 可能是一个不错的选择。

  • 如果可读性很重要
  • 如果设备之间存在差异,即如果您拥有具有不同属性的不同设备,因为 XML 往往是自描述的。
  • 或者,如果您想将设备的数据发布到互联网上。

当然,XML 很冗长,并且肯定有一些方法可以使用二进制协议完成上述所有操作(例如,可以使用标记值来使二进制协议更具描述性)。

There are tradeoffs either way, so the right choice depends on your application, how powerful your device is and who is going to be using this protocol.

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

XML might be a good choice if

  • Readability is important
  • If there is variation between devices, i.e. if you have different devices that have different properties, since XML tends to be self-describing.
  • Or if you want to publish your device's data to the Internet.

Of course, XML is verbose and there are certainly ways to accomplish all of the above with a binary protocol (e.g. with tagged values can be used to make your binary protocol more descriptive).

゛时过境迁 2024-10-10 17:03:43

该网站的创始人之一在 XML:尖括号税

One of the founders of this very site has some sane and amusing opinions on XML in XML: The Angle Bracket Tax

辞旧 2024-10-10 17:03:43

我在以前的设计中做了一些非常类似的事情,使用 XML 格式进行 PC 到微处理器的通信。它在 PC 端运行得非常好,因为 Adob​​e Flex(我们使用的)可以非常轻松地解释 XML,而且我怀疑 .Net 也可以非常轻松地完成同样的事情。

其中更复杂的部分是在微处理器方面。 XML 解析必须手动完成,这并不是那么复杂,但只是耗时。创建 XML 字符串也可能需要大量代码,具体取决于您正在执行的操作。

总的来说 - 如果我必须再做一次,我仍然认为 XML 是一个不错的选择,因为它是一个非常灵活的协议。对于在微处理器端的 FIFO 缓冲区中存储一些数据包而言,RAM 并不是什么大问题,但这可能是您的应用程序中需要考虑的问题。

I did something very similar in a previous design with PC to microprocessor communications using an XML format. It worked very well on the PC side since what Adobe Flex (what we were using) could interpret XML very easily, and I suspect .Net can do the same thing very easily.

The more complicated part of it was on the microprocessor side. The XML parsing had to be done manually, which was not really that complicated, but just time intensive. Creating the XML string can also be quite a lot of code depending on what you're doing.

Overall - If I had to do it again, I still think XML was a good choice because it is a very flexible protocol. RAM was not that much of an issue with regards to storing a few packets in our FIFO buffer on the microprocessor side but that may be something to consider in your application.

一腔孤↑勇 2024-10-10 17:03:43

生成和传输 XML 文件浪费了宝贵的嵌入式 CPU 时间。相反,我只会使用二进制字节数组来表示数据,但我会使用结构来帮助解释数据。 C# 的结构特性使您可以轻松地将字节数组解释为有意义的数据。下面是一个示例:

[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,
}

然后您将拥有一个将字节数组转换为此结构的函数:

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

与 XML 相比,此方法将节省设备和 PC 上的 CPU 时间,并且比 XML 模式更容易维护,用于构建和解析 XML 文件的补充功能。您所要做的就是确保嵌入式设备中的结构体和枚举定义与 C# 代码中的定义相同,以便 C# 程序和设备就使用的协议达成一致。

您可能希望在 C# 和嵌入端都使用“packed”属性,以便所有结构元素都以可预测的方式定位。

It's a waste of precious embedded CPU time to generate and transmit XML files. Instead, I would just use an array of binary bytes represent the data, but I would use structs to help interpret the data. The struct feature of C# lets you easily interpret an array of bytes as meaningful data. Here's 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 would have a function that converts your array of bytes to this struct:

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

Compared to XML, this method will save CPU time on the device and on the PC, and it is easier to maintain than an XML schema, with complementary functions for building and parsing the XML file. All you have to do is make sure that the struct and enum definitions in your embdedded device are the same as the definitions in your C# code, so that the C# program and device agree on the protocol to use.

You'll probably want to use the "packed" attribute on both the C# and embedded side so that all the struct elements are positioned in a predictable way.

~没有更多了~
我们使用 Cookies 和其他技术来定制您的体验包括您的登录状态等。通过阅读我们的 隐私政策 了解更多相关信息。 单击 接受 或继续使用网站,即表示您同意使用 Cookies 和您的相关数据。
原文