blocks|key|1683834|text|USB+bus将满足您的所有需求。它可能是非常简单usb设备，只有一个控制管道来发送请求到你的设备，或者你可以添加一个中断管道，允许你通知主机你的设备的变化。可以使用许多简单的usb控制器，例如Cypress或Microchip。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1683835|传输之上的协议实际上是关于您的需求的。从您的描述来看，似乎简单的同步协议就足够了。是什么让你徘徊并寻找其他方法？分享您的疑虑，我们将尝试提供帮助:)。|1683836|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/USB|1|http://www.cypress.com/products/?gid=9&fid=13&GoGatewayCategoryID=All&|2|http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&nodeId=2124%25C2%25B6m=en022613&page=wwwFullSpeedUSB^0|0|7|0|2P|7|1|2X|9|2|0|0^^$0|@$1|2|3|4|5|6|7|R|8|@]|9|@$A|S|B|T|1|U]|$A|V|B|W|1|X]|$A|Y|B|Z|1|10]]|C|$]]|$1|D|3|E|5|6|7|11|8|@]|9|@]|C|$]]|$1|F|3|-4|5|6|7|12|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]|P|$5|I|J|K|C|$L|Q]]]]

<a href="http://en.wikipedia.org/wiki/USB" rel="nofollow noreferrer">USB bus</a> will answer all your requirements. It might be very simple usb device with only control pipe to send request to your device or you can add an interrupt pipe that will allow you to notify host about changes in your device. 
There is a number of simple usb controllers that can be used, for example <a href="http://www.cypress.com/products/?gid=9&amp;fid=13&amp;GoGatewayCategoryID=All&amp;" rel="nofollow noreferrer">Cypress</a> or <a href="http://www.microchip.com/stellent/idcplg?IdcService=SS_GET_PAGE&amp;nodeId=2124&amp;param=en022613&amp;page=wwwFullSpeedUSB" rel="nofollow noreferrer">Microchip</a>. 

Protocol on top of the transfer is really about your requirements. From your description it seems that simple synchronous protocol is definitely enough. What make you wander and look for additional approach? Share your doubts and we will try to help :).

blocks|key|1468572|text|Adam+Liss提出了很多很棒的观点。简单性和健壮性应该是重点。人类可读的ASCII传输在调试时很有帮助。很好的建议。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1468573|它们可能无法满足您的需求，但HDLC和/或PPP增加了数据链路层的概念，以及数据链路层带来的所有好处(和成本)。链路管理、成帧、校验和、序列号、重传等。所有这些都有助于确保健壮的通信，但会增加复杂性、处理能力和代码大小，对于您的特定应用程序可能不是必需的。|1468574|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

Adam Liss makes a lot of great points. Simplicity and robustness should be the focus. Human readable ASCII transfers help a LOT while debugging. Great suggestions.

They may be overkill for your needs, but HDLC and/or PPP add in the concept of a data link layer, and all the benefits (and costs) that come with a data link layer. Link management, framing, checksums, sequence numbers, re-transmissions, etc... all help ensure robust communications, but add complexity, processing and code size, and may not be necessary for your particular application.

blocks|key|1468697|text|如果我不需要做有效的二进制传输，我会选择已经建议的终端风格的界面。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1468698|如果我确实想做二进制数据包格式，我倾向于使用一些松散的基于PPP+byte-asnc+HDLC格式的格式，这种格式非常简单，基本上很容易发送接收：|1468699|数据包以0x7e开始和结束您可以在字符前面加上0x7d并切换位5(即用0x20进行异或)来转义字符，因此0x7e变为0x7d+0x5e，0x7d变为0x7d+0x5d|1468700|每次您看到0x7e时，如果您存储了任何数据，则可以对其进行处理。|1468701|我通常做主机驱动的同步工作，除非我有很好的理由这样做。这是一种从简单的点对点RS232扩展到多点RS422/485的技术，没有任何麻烦--通常是额外的好处。|1468702|entityMap^0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|L|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|M|8|@]|9|@]|A|$]]|$1|D|3|E|5|6|7|N|8|@]|9|@]|A|$]]|$1|F|3|G|5|6|7|O|8|@]|9|@]|A|$]]|$1|H|3|I|5|6|7|P|8|@]|9|@]|A|$]]|$1|J|3|-4|5|6|7|Q|8|@]|9|@]|A|$]]]|K|$]]

If I wasn't expecting to need to do efficient binary transfers, I'd go for the terminal-style interface already suggested.

If I do want to do a binary packet format, I tend to use something loosely based on the PPP byte-asnc HDLC format, which is extremely simple and easy to send receive, basically:

Packets start and end with 0x7e
You escape a char by prefixing it with 0x7d and toggling bit 5 (i.e. xor with 0x20)
So 0x7e becomes 0x7d 0x5e
and 0x7d becomes 0x7d 0x5d

Every time you see an 0x7e then if you've got any data stored, you can process it.

I usually do host-driven synchronous stuff unless I have a very good reason to do otherwise. It's a technique which extends from simple point-point RS232 to multidrop RS422/485 without hassle - often a bonus.

blocks|key|1684094|text|我的票是人类可读的。|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1684095|但是如果你是二进制的，试着在开头放一个头字节来标记一个包的开始。我总是在串行协议不同步的情况下倒霉。标头字节允许嵌入式系统与PC重新同步。另外，在结尾处添加校验和。|1684096|entityMap^0|0|0^^$0|@$1|2|3|4|5|6|7|F|8|@]|9|@]|A|$]]|$1|B|3|C|5|6|7|G|8|@]|9|@]|A|$]]|$1|D|3|-4|5|6|7|H|8|@]|9|@]|A|$]]]|E|$]]

My vote is for the human readable.

But if you go binary, try to put a header byte at the beginning to mark the beginning of a packet. I've always had bad luck with serial protocols getting out of sync. The header byte allows the embedded system to re-sync with the PC. Also, add a checksum at the end.

blocks|key|1684200|text|我已经用简单的二进制格式做过这样的事情|type|unstyled|depth|inlineStyleRanges|entityRanges|data|1684201|struct+PacketHdr
{
++char+syncByte1;
++char+syncByte2;
++char+packetType;
++char+bytesToFollow;++//-or-+totalPacketSize
};

struct+VoltageSet
{+
+++struct+PacketHdr;
+++int16+channelId;
+++int16+voltageLevel;+
+++uint16+crc;
};

struct+VoltageResponse
{
+++struct+PacketHdr;
+++int16+data[N];++//Num+channels+are+fixed
+++uint16+crc;
}|code-block|syntax|javascript|1684202|同步字节在同步协议中没有异步协议那么关键，但它们仍然有帮助，特别是当嵌入式系统第一次加电时，并且您不知道它获得的第一个字节是否是消息的中间。|1684203|类型应该是告诉如何解压数据包的枚举。可以从类型推断出大小，但如果显式发送，则接收器可以处理未知类型而不会阻塞。你可以使用“总数据包大小”，或者“跟随的字节数”；后者可以使接收器的代码更整洁一些。|1684204|末尾的CRC增加了更多的保证，即您拥有有效的数据。有时我会在头部看到CRC，这使得声明结构更容易，但将它放在末尾可以避免在发送消息时对数据进行额外的传递。|1684205|在一个字节被丢弃的情况下，发送方和接收方都应该在接收到分组的第一个字节之后开始超时。PC端还需要超时来处理嵌入式系统未连接且完全没有响应的情况。|1684206|如果您确定两个平台都使用IEEE-754浮点型(PC的do)并且具有相同的字节顺序，那么您可以使用浮点型作为数据类型。否则，使用整数更安全，无论是原始A/D位，还是预置标度(即1位=+.001V给出%2B/-32.267+V范围)|1684207|entityMap^0|0|0|0|0|0|0|0^^$0|@$1|2|3|4|5|6|7|S|8|@]|9|@]|A|$]]|$1|B|3|C|5|D|7|T|8|@]|9|@]|A|$E|F]]|$1|G|3|H|5|6|7|U|8|@]|9|@]|A|$]]|$1|I|3|J|5|6|7|V|8|@]|9|@]|A|$]]|$1|K|3|L|5|6|7|W|8|@]|9|@]|A|$]]|$1|M|3|N|5|6|7|X|8|@]|9|@]|A|$]]|$1|O|3|P|5|6|7|Y|8|@]|9|@]|A|$]]|$1|Q|3|-4|5|6|7|Z|8|@]|9|@]|A|$]]]|R|$]]

I've done stuff like this with a simple binary format

<pre><code>struct PacketHdr
{
 char syncByte1;
 char syncByte2;
 char packetType;
 char bytesToFollow; //-or- totalPacketSize
};

struct VoltageSet
{ 
 struct PacketHdr;
 int16 channelId;
 int16 voltageLevel; 
 uint16 crc;
};

struct VoltageResponse
{
 struct PacketHdr;
 int16 data[N]; //Num channels are fixed
 uint16 crc;
}
</code></pre>

The sync bytes are less critical in a synchronous protocol than in an asynchronous one, but they still help, especially when the embedded system is first powering up, and you don't know if the first byte it gets is the middle of a message or not. 

The type should be an enum that tells how to intepret the packet. Size could be inferred from type, but if you send it explicitly, then the reciever can handle unknown types without choking. You can use 'total packet size', or 'bytes to follow'; the latter can make the reciever code a little cleaner.

The CRC at the end adds more assurance that you have valid data. Sometimes I've seen the CRC in the header, which makes declaring structures easier, but putting it at the end lets you avoid an extra pass over the data when sending the message.

The sender and reciever should both have timeouts starting after the first byte of a packet is recieved, in case a byte is dropped. The PC side also needs a timeout to handle the case when the embedded system is not connected and there is no response at all.

If you are sure that both platforms use IEEE-754 floats (PC's do) and have the same endianness, then you can use floats as the data type. Otherwise it's safer to use integers, either raw A/D bits, or a preset scale (i.e. 1 bit = .001V gives a +/-32.267 V range)

blocks|key|1468960|text|Modbus可能就是你要找的东西。它正是为您所遇到的问题类型而设计的。有很多代码/工具，遵守一个标准可能意味着以后很容易重用。它还支持人类可读ASCII，因此仍然很容易理解/测试。|type|unstyled|depth|inlineStyleRanges|entityRanges|offset|length|data|1468961|请参阅适用于windows和嵌入式源代码的FreeModBus。|1468962|entityMap|0|LINK|mutability|MUTABLE|url|http://en.wikipedia.org/wiki/Modbus|1|http://www.freemodbus.org/^0|0|6|0|0|L|A|1|0^^$0|@$1|2|3|4|5|6|7|P|8|@]|9|@$A|Q|B|R|1|S]]|C|$]]|$1|D|3|E|5|6|7|T|8|@]|9|@$A|U|B|V|1|W]]|C|$]]|$1|F|3|-4|5|6|7|X|8|@]|9|@]|C|$]]]|G|$H|$5|I|J|K|C|$L|M]]|N|$5|I|J|K|C|$L|O]]]]

<a href="http://en.wikipedia.org/wiki/Modbus" rel="noreferrer">Modbus</a> might be what you are looking for. It was designed for exactly the type of problem you have. There is lots of code/tools out there and adherence to a standard could mean easy reuse later. It also support human readable ASCII so it is still easy to understand/test.

See <a href="http://www.freemodbus.org/" rel="noreferrer">FreeModBus</a> for windows and embedded source.

I am building a small device with its own CPU (AVR Mega8) that is supposed to connect to a PC. Assuming that the physical connection and passing of bytes has been accomplished, what would be the best protocol to use on top of those bytes? The computer needs to be able to set certain voltages on the device, and read back certain other voltages.

At the moment, I am thinking a completely host-driven synchronous protocol: computer send requests, the embedded CPU answers. Any other ideas?

Protocols used to talk between an embedded CPU and a PC

嵌入式系统

我正在构建一个小型设备，它有自己的CPU (AVR Mega8)，应该可以连接到PC。假设已经完成了物理连接和字节的传递，那么在这些字节之上使用的最佳协议是什么？计算机需要能够在设备上设置特定的电压，并回读某些其他的电压。目前，我正在考虑一种完全由主机驱动的同步协议:计算机发送请求，嵌入式CPU应答。还有其他想法吗？

问用于在嵌入式CPU和PC之间通信的协议
EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问用于在嵌入式CPU和PC之间通信的协议EN

社区

活动

资源

关于

腾讯云开发者

热门产品

热门推荐

更多推荐

问用于在嵌入式CPU和PC之间通信的协议
EN