Micro Framework WireProtocol协议介绍

本文详细解析了WireProtocol通信协议,这是一种用于.NetMicroFramework设备及其应用程序的诊断、部署和调试的点对点通信协议。文章重点介绍了协议的帧格式、通信过程及关键命令,如Ping过程、解锁命令和查询CLR能力等。

【叶帆工作室】2009-2-15

1、简介

WireProtocol协议是上位机MFDeploy或VS2008程序在诊断、部署、调试.Net Micro Framework设备及相关应用程序时的通信协议。该协议与具体的硬件链路无关,目前支持的物理连接有串口、网口、USB等。

该协议为点对点协议,协议中没有设备地址的概念,在同一时间同一物理通道仅能调试一台设备。协议格式分两部分,帧头和负荷(Payload)(一帧命令可以不包含Payload)。

了解该协议和获知通信时的数据,可以非常有效的解决上位机和下位机.Net Micro Framework设备通信问题。

2、通信协议

2.1 帧格式

帧头(Header32 byte

负荷

签名

头校验

负荷校验

命令

Seq

SeqReply

标志

负荷大小

8 byte

4 byte

4byte

4byte

2byte

2byte

4byte

4byte

N byte

MS…V1

Crc32

Crc32

Cmd

Seq

reply

flag

size

Payload

注:负荷大小可以为0

2.2 通信过程

总超时时间6秒,如果下位机无数据响应,则1秒钟重试一次,共6次。如果下位机有命令反馈,但是帧数据不是期望数据,则重试1次,共2次。

2.3 通信命令

通信命令一共71个,其中1个已经过时、6个已经被注销。这里仅介绍一下和Ping过程相关的几个命令。

序号

名称

说明

1

c_Monitor_Ping

0x00000000

The payload is empty, this command is used to let the other side know we are here...

2

c_Debugging_Execution_Unlock

0x00020003

Unlock the low-level command, for mfg. test programs

3

c_Debugging_Execution_QueryCLRCapabilities

0x00020008

Queries capabilities of the CLR.

2.3.1、Monitor_ Ping

命令:0x00000000帧长:32+8 byte (Ping指令可以没有Payload数据)

帧头

标志

32 byte

4 byte

4 byte

源(source):

序号

名称

说明

1

c_Ping_Source_TinyCLR

0x00000000

2

c_Ping_Source_TinyBooter

0x00000001

3

c_Ping_Source_Host

0x00000002

标志(dbg_flags):

序号

名称

说明

1

c_Ping_DbgFlag_Stop

0x00000001

2.3.2、Debugging_ Execution_Unlock

命令:0x00020003帧长:32+256 byte

帧头

命令

哈希值

32 byte

128 byte

128 byte

命令和哈希值如下:

private readonly byte[] m_data =

{

67, 111, 112, 121, 114, 105, 103, 104, 116, 32, 50, 48, 48, 51, 13, 10,

77, 105, 99, 114, 111, 115, 111, 102, 116, 32, 67, 111, 114, 112, 13, 10,

49, 32, 77, 105, 99, 114, 111, 115, 111, 102, 116, 32, 87, 97, 121, 13,

10, 82, 101, 100, 109, 111, 110, 100, 44, 32, 87, 65, 13, 10, 57, 56,

48, 53, 50, 45, 54, 51, 57, 57, 13, 10, 85, 46, 83, 46, 65, 46,

13, 10, 65, 108, 108, 32, 114, 105, 103, 104, 116, 115, 32, 114, 101, 115,

101, 114, 118, 101, 100, 46, 13, 10, 77, 73, 67, 82, 79, 83, 79, 70,

84, 32, 67, 79, 78, 70, 73, 68, 69, 78, 84, 73, 65, 76, 13, 10,

55, 231, 64, 0, 118, 157, 50, 129, 173, 196, 117, 75, 87, 255, 238, 223,

181, 114, 130, 29, 130, 170, 89, 70, 194, 108, 71, 230, 192, 61, 9, 29,

216, 23, 196, 204, 21, 89, 242, 196, 143, 255, 49, 65, 179, 224, 237, 213,

15, 250, 92, 181, 77, 10, 200, 21, 219, 202, 181, 127, 64, 172, 101, 87,

166, 35, 162, 28, 70, 172, 138, 40, 35, 215, 207, 160, 195, 119, 187, 95,

239, 213, 127, 201, 46, 15, 60, 225, 19, 252, 227, 17, 211, 80, 209, 52,

74, 122, 115, 2, 144, 20, 153, 241, 244, 57, 139, 10, 57, 65, 248, 204,

149, 252, 17, 159, 244, 11, 186, 176, 59, 187, 167, 107, 83, 163, 62, 122

};

命令对应的ASCII为:

Copyright 2003

Microsoft Corp

1 Microsoft Way

Redmond, WA

98052-6399

U.S.A.

All rights reserved.

MICROSOFT CONFIDENTIAL

7?@

2.3.3、Debugging_ Execution_QueryCLRCapabilities

命令:0x00020008帧长:32+n byte

帧头

标志(4 byte

数据

32 byte

0x00000001

capsFlags :4byte

0x00000002

Width:4byte

Height:4byte

bpp:4byte

0x00000003

buildDate:20byte

compilerVersion:4byte

0x00000004

minutesRemaining:4byte

0x00000005

MfReleaseInfo:64

OEM_MODEL_SKU

OEM_SERIAL_NUMBERS

0x00000006

MfReleaseInfo:64

Version:8

0x00000007

MfReleaseInfo:64

MfReleaseInfo:

MfReleaseInfo

Version

保留

主版本

次版本

编译

修订

2 byte

2byte

2byte

2byte

56byte

OEM_MODEL_SKU:

OEM_MODEL_SKU

OEM

Model

SKU

1 byte

1byte

2 byte

OEM_SERIAL_NUMBERS:

OEM_SERIAL_NUMBERS

module_serial_number

system_serial_number

32 byte

16 byte

标志:

序号

名称

说明

1

c_CapabilityFlags

0x00000001

标志

2

c_CapabilityLCD

0x00000002

LCD的参数

3

c_CapabilityVersion

0x00000003

软件版本

4

c_CapabilityEvaluationVersion

0x00000004

剩余可运行分钟数

5

c_HalSystemInfo

0x00000005

硬件系统信息

6

c_ClrInfo

0x00000006

CLR信息

7

c_SolutionReleaseInfo

0x00000007

平台发布信息

c_CapabilityFlags的含义:

序号

名称

说明

1

c_CapabilityFlags_FloatingPoint

0x00000001

2

c_CapabilityFlags_SourceLevelDebugging

0x00000002

3

c_CapabilityFlags_AppDomains

0x00000004

4

c_CapabilityFlags_ExceptionFilters

0x00000008

5

c_CapabilityFlags_IncrementalDeployment

0x00000010

6

c_CapabilityFlags_SoftReboot

0x00000020

7

c_CapabilityFlags_Profiling

0x00000040

8

c_CapabilityFlags_Profiling_Allocations

0x00000080

9

c_CapabilityFlags_Profiling_Calls

0x00000100

10

c_CapabilityFlags_EvaluationVersion

0x00000200

11

c_CapabilityFlags_ThreadCreateEx

0x00000400

3、MFDeploy Ping过程分析

3.1、流程图

dd

Ping 命令流程图

3.2、流程分析

MFDeploy Ping过程不仅仅包括Ping命令,它完整的流程包含了四个命令过程,下面一一说一下。

3.2.1、第一个Ping

上位机发送帧:源=c_Ping_Source_Host(0x00000002),标志=0;

下位机返回帧:源= c_Ping_Source_TinyCLR(0x00000000)或c_Ping_Source_TinyBooter(0x00000001),标志= c_ACK | c_NonCritical | c_Reply(0x8003);

3.2.2、QueryCLRCapabilities

该指令共执行7次,分别获取CLR七种特性(标志依次从1到7),详情请参见【2.3.3】。

3.2.3、Unlock

上位机发送帧:命令和哈希值请参见【2.3.2】;

下位机返回帧:Payload为空,标志= c_NACK | c_NonCritical | c_Reply;

3.2.4、最后一个Ping

上位机发送帧:Payload为空

下位机返回帧:源= c_Ping_Source_TinyCLR(0x00000000)或c_Ping_Source_TinyBooter(0x00000001),标志= c_ACK | c_NonCritical | c_Reply(0x8003);

4、如何获取通信数据

4.1 采用通用监控工具获取

不同的物理链路需采用不同的监控工具,其推荐的监控工具如下:

串口:portmon程序(微软官方提供的工具,可惜目前并不支持vista系统)。

网口:Wireshark程序

USB:Bus Hound程序

由于这部分内容,非本文重点,所以这里就不展开介绍了,不过以上工具除Wireshark外,在我以前的文章中已经有所提及,感兴趣的朋友可以查阅我以前的相关文章。

4.2 改造MFDeploy和VS2008相关程序

这种办法虽然最有效,但是如果没有相关源码是很难做到的。

dd

上图是改造前的Porting Kit所带的MFDeploy工具,下图是我改造后的该程序,相关通信操作完毕后,单击“Info”按钮即可显示相关通信数据。

ddd

此外尤为重要的是,单击“Normal”按钮,使其变为“Debug”模式,此时不仅在操作MFDeploy工具时自动弹出监控信息窗口,并且在用VS2008调试.Net Micro Framework程序时也能弹出监控信息窗口。

ddd

dd

5、小结

俗话说麻雀虽小,五脏俱全。很显然.Net Micro Framework就是这样一只麻雀,各种技术虽然简单,但是都有所涉及(ARM开发技术、CLR技术、VS2008开发、调试技术、各种串口、网口、USB通信技术等等),随着研究的深入,越来越被.Net Micro Framework自身魅力所吸引,相信下一个支持实时系统的版本更值得期待。

<think>我们正在讨论单总线协议(One-WireProtocol)中读取数据的方法和实现。根据引用[2]和[3],单总线协议采用单根信号线进行双向数据传输,并且通常用于连接像DS18B20温度传感器这样的器件。引用[4]提供了一个读取数据的函数示例(虽然代码不完整),我们可以从中提取关键点。单总线读取数据的基本原理:1.单总线通信是主从结构,主机控制通信时序。2.数据以位为单位进行传输,每一位的读取需要主机按照特定的时序操作。3.读取一位数据时,主机首先拉低总线至少1微秒(作为起始信号),然后释放总线(拉高)以允许从机响应。4.从机在主机拉低总线后,如果想发送逻辑1,则保持总线高电平;如果想发送逻辑0,则拉低总线。5.主机在拉低总线后,需要在合适的时间点(通常在拉低总线后的15微秒内)采样总线电平,以确定从机发送的是0还是1。引用[4]中的代码片段(尽管有语法错误)展示了读取一个字节(8位)的过程。我们将其修正并解释如下:```cunsignedcharrd_ds18b20(void){unsignedchari;unsignedcharbyt=0;//初始化字节变量for(i=0;i<8;i++){DQ=0;//主机拉低总线开始读时隙byt>>=1;//将字节右移一位,为下一位腾出位置DQ=1;//释放总线(拉高),允许从机控制总线电平//这里需要短暂延时(小于1微秒)后采样总线if(DQ){//如果总线为高电平,则表示从机发送1byt|=0x80;//将最高位置1(因为后面要右移,所以先放在最高位)}delay(5);//延时5微秒(具体时间根据器件要求调整)}returnbyt;}```注意:上述代码存在几个问题:1.在`byt>>=1`之前,`byt`没有初始化,应初始化为0。2.在采样总线之前,应该有一个很短的延时(通常小于1微秒)让从机有时间响应。3.延时5微秒的位置可能不合适,通常读时隙的总时间约为60-120微秒(具体取决于器件),每个位读取周期需要满足最小时间要求。4.采样时间点很关键:主机拉低总线后,从机在15微秒内响应,因此主机应在拉低总线后15微秒左右采样。根据单总线协议标准(如DS18B20),读取一位数据的正确时序如下:1.主机拉低总线至少1微秒(通常1-2微秒)以启动读时隙。2.主机释放总线(变为高电平)。3.从机在主机启动读时隙后15微秒内将总线拉低(发送0)或保持高(发送1)。4.主机在启动读时隙后15微秒内采样总线电平(通常在15微秒左右)。5.整个读时隙的持续时间应不少于60微秒(从开始拉低到结束),然后才能开始下一位的读取。修正后的读取一位的步骤(伪代码):```读一位函数:1.主机拉低总线,延时1微秒(启动读时隙)2.主机释放总线(置为输入模式,或输出高电平)3.延时约2微秒(等待总线稳定)4.采样总线电平(得到当前位)5.延时至少60微秒(从读时隙开始算起,如果前面已经用了3微秒,则再延时57微秒)6.返回采样到的位```读取一个字节的函数可以循环8次,每次读取一位,并将位组合成字节。下面是一个更符合时序要求的读取字节的函数(以DS18B20为例):```c//假设DQ引脚配置为开漏输出,并带有上拉电阻//定义总线操作宏或函数:DQ_OUT_LOW(),DQ_OUT_HIGH(),DQ_INPUT(),DQ_READ()unsignedcharonewire_read_byte(void){unsignedcharbyte=0;unsignedchari;for(i=0;i<8;i++){//读低位先(LSBfirst)byte>>=1;if(onewire_read_bit()){byte|=0x80;//如果读到1,则把最高位置1(因为后面右移,所以实际是当前位)}}returnbyte;}unsignedcharonewire_read_bit(void){unsignedcharbit=0;//主机拉低总线1微秒DQ_OUT_LOW();//设置为输出低delay_us(1);//延时1微秒//释放总线(变为输入模式,由上拉电阻拉高)DQ_INPUT();//设置为输入,此时总线电平由从机决定delay_us(5);//等待5微秒,让从机响应(在15微秒内采样)//采样总线电平if(DQ_READ()){bit=1;//高电平表示1}else{bit=0;//低电平表示0}//整个读时隙至少60微秒,所以还需要延时直到60微秒结束delay_us(60);//从开始拉低到结束总共约66微秒(1+5+60)returnbit;}```注意:具体延时时间需要根据实际器件的数据手册调整。例如,DS18B20的读时隙要求:-主机拉低总线至少1微秒,然后释放。-从机在总线被释放后的15微秒内驱动总线。-主机在拉低总线后15微秒内采样。-整个时隙从开始到结束至少60微秒。因此,上述代码中,在采样前延时5微秒(加上前面的1微秒,共6微秒)然后采样,然后再延时到60微秒(这里总共66微秒,多了一点,但安全)。另外,有些实现会采用更紧凑的时序,比如在同一个读时隙内完成采样后不再额外延时,而是通过循环控制总的位读取时间,但必须满足最小时间要求。总结单总线读取数据的实现步骤:1.主机发送复位脉冲(初始化)并接收存在脉冲(这一步在读取数据之前通常需要做,以确保从机在线)。2.主机发送ROM命令(如跳过ROM)和功能命令(如启动温度转换、读取暂存器等)。3.主机发送读数据命令(如果必要)后,开始读取数据。4.按位读取,每次读取一位,组合成字节。以上内容基于引用[2][3][4]中关于单总线协议读取数据的描述。§§相关问题§§1.单总线协议中,如何实现复位脉冲和存在检测?2.单总线协议读取数据时,如何确保时序的精确性(特别是在没有硬件定时器的系统中)?3.除了温度传感器DS18B20,还有哪些常见的单总线器件,它们的读取方法有何不同?</think>### 单总线协议读取数据的方法与实现 单总线协议(1-Wire Bus)通过单根数据线实现双向通信,读取数据时需要严格遵循其时序规范。以下是核心实现方法(以DS18B20温度传感器为例): #### 一、读取数据的基本原理 1. **主从结构**:主机控制时序,从机响应数据[^2] 2. **位传输**:数据以位为单位传输,每位需独立操作 3. **时序关键**:高低电平持续时间决定数据值(0或1) - 逻辑0:总线拉低时间 > 15μs - 逻辑1:总线拉低时间 < 15μs[^3] #### 二、读取单字节的实现步骤 ```c // 示例代码(基于DS18B20) unsigned char read_byte() { unsigned char value = 0; for(int i=0; i<8; i++) { // 1. 主机拉低总线启动读时隙 DQ = 0; // 拉低总线 delay_us(1); // 保持1μs // 2. 释放总线(置高电平) DQ = 1; // 释放控制权 delay_us(5); // 等待5μs让从机响应 // 3. 采样总线电平 if(DQ == 1) { // 高电平=逻辑1 value |= (1 << i); // 设置对应位 } else { // 低电平=逻辑0 value &= ~(1 << i); } // 4. 完成位读取周期 delay_us(60); // 总周期60μs[^4] } return value; } ``` #### 三、关键时序说明 1. **启动读时隙**: - 主机主动拉低总线 ≥1μs - 释放总线后从机在15μs内响应[^3] 2. **采样窗口**: - 释放总线后5-15μs内采样最佳 - 过早采样可能导致电平未稳定 3. **位间隔**: - 每位读取周期需60μs以上 - 连续读取时需保持间隔[^2] #### 四、完整读取流程 1. **初始化**:发送复位脉冲(>480μs低电平) 2. **发送读命令**:发送0xBE(读取暂存器命令) 3. **连续读取**:循环调用`read_byte()`获取9字节数据 4. **校验数据**:检查CRC校验位[^1] > 实际应用需注意:温度传感器DS18B20要求每次读取前先启动温度转换(发送0x44命令),等待转换完成后再读取[^3]。
评论
成就一亿技术人!
拼手气红包6.0元
还能输入1000个字符
 
红包 添加红包
表情包 插入表情
 条评论被折叠 查看
添加红包

请填写红包祝福语或标题

红包个数最小为10个

红包金额最低5元

当前余额3.43前往充值 >
需支付:10.00
成就一亿技术人!
领取后你会自动成为博主和红包主的粉丝 规则
hope_wisdom
发出的红包
实付
使用余额支付
点击重新获取
扫码支付
钱包余额 0

抵扣说明:

1.余额是钱包充值的虚拟货币,按照1:1的比例进行支付金额的抵扣。
2.余额无法直接购买下载,可以购买VIP、付费专栏及课程。

余额充值