one-wire 调试单总线 ds2781

调试ds2781的时候可谓艰难啊,但是调完了一个模拟的iic时序之后单总线的时序竟然迎刃而解了。

下面总结一下调试的过程:

我使用ds2781的快速模式(OVD高电平)

1. 首先要有一个芯片的datasheet

这里写链接内容

2. 其次测试设备:示波器,逻辑分析仪

3. 根据手册上的时序写代码进行调试

时隙

复位时序

关于与复位时序,手册说明:

与DS2781的任何通信都必须从初始化过程开始,如上图所示。复位脉冲之后的在线应答脉冲表明DS2781已经准备

好接收网络地址命令。总线主机发出 (Tx) 持续tRSTL时间的复位脉冲。然后总线主机释放数据线,进入接收模式

(Rx)。然后由上拉电阻将1-Wire总线拉至高电平。DS2781检测到DQ引脚的上升沿后,将等待tPDH时间,然后发出持

续时间为tPDL的在线应答脉冲。

我调试的时候的复位波形是这样的:

要对照着时隙,我的三个参数分别是:65us,3us,12us。对应手册的 48-80us,2-6us,8-24us。

写0写1时序

关于写时序,手册上这样说明:

当总线主机将1-Wire总线从逻辑高 (无效) 电平拉至逻辑低电平时,开始写时隙。写时隙有两种类型:写1和写0。所

有写时隙必须保持tSLOT的时间,并且两个写时隙之间需要1μs的最小恢复时间 (tREC)。DS2781将在线路下降沿之后的

15μs至60μs之间 (高速模式下在2μs至6μs之间) 采样1-Wire总线数据。如果采样时总线为高电平,则为写1时隙。如

果采样时总线为低电平,则为写0时隙 (参见图23)。总线主机若要产生写1时隙,必须先拉低总线,然后释放,在写

时隙开始后的15μs (高速模式下为2μs) 之内将总线拉至高电平。主机若要产生写0时隙,必须拉低总线,并在写时隙

持续时间内保持为低电平。

我调试的时候的波形是这样的:

读0读1时序

关于读时序手册是这样说明的

当总线主机将1-Wire总线从逻辑高电平拉至逻辑低电平时,开始读时隙。总线主机必须使总线为低电平的时间至少持

续1μs,然后再释放总线,使DS2781输出有效数据。总线主机在读时隙开始后的tRDV时间内采样数据。DS2781在读

时隙结束时释放总线,允许外部上拉电阻将其拉至高电平。所有读时隙必须持续tSLOT,并且在两次读时隙之间需要

1μs的最小恢复时间 (tREC)。详细信息参见图23。

我调试的时候的波形是这样的:

按照实际的波形 tRDV 在小于3us内都是可以读出来的

  1. 调整时序

    如果应答信号收不到,那么仔细调整时序,如果在硬件没有问题的情况下,时序对了就可以正常读数的,因此要仔细调整时序。

[源码](http://download.csdn.net/detail/a912293097/9054963 “csdn下载界面”)

版权声明:本文为博主原创文章,未经博主允许不得转载。

时间: 2024-10-09 20:16:05

one-wire 调试单总线 ds2781的相关文章

使用Eclipse配合JDWP对服务器上部署的代码进行调试

今天遇到了一个问题:同样的代码,在服务器上跑的时候会报空指针异常,但是在本地是没有问题的,看服务器上打印的日志只能看到异常信息,不能准确地定位到出问题的代码,于是就搜索了一下远程调试.结果还真的可以在eclipse中对服务器上的代码进行远程调试 有一个叫做JDWP的协议,支持对java虚拟机进行远程调试 JDWP的全称是Java Debug Wire Protocol,它定义了调试器(debugger)和被调试的 Java 虚拟机(target vm)之间的通信协议.其核心API已经包含在JDK

使用Eclipse远程调试及原理

今天定位Linux Server端的Java应用程序的问题,使用了 Eclipse 远程调试 Java 应用程序,这恐怕是定位Server端最常见也是最根本的方法,居然至少有两位有好几年开发经验的同事都不知道这个方法,我也感觉十分诧异. 本文在介绍使用Eclipse远程调试Java应用程序之外,着重解析了远程调试的原理. JVM原理 众所周知,Java由于引入了虚拟机JVM,拥有了很好的跨平台和安全性,.java文件由Javac编译成.class文件也叫字节码文件,字节码文件由JVM执行,并由翻

嵌入式OS入门笔记-以RTX为案例:十.Keil的RTX调试支持

嵌入式OS入门笔记-以RTX为案例:十.Keil的RTX调试支持 调试(debug)是软件开发的一个重要环节,对于嵌入式开发而言这个环节其实比较依赖一些硬件资源(硬件debugger)的支持.传统的嵌入式系统的调试比较依赖断点(breakpoint)和单步调试(single step through).而 ARM cortex-M 系列的芯片其实有很强的CoreSight片上调试支持,实际上就是一个小的调试硬件,作为ARM的标准,内嵌在ARM的芯片里.在ARM自家的调试器ULINK-pro等的帮

调试LATTICE 的SGMII的调试。

最近调试lattice 的sgmii接口. 项目最初的架构大概是这样的,用于调试. FPGA这边的架构,就是 Tri_mac 转为 sgmii,然后再通过pcs出去.其实sgmii核自带了一个pcs核,最坑人的是PCS必须是外部时钟,最后没有办法只能自己生成一个pcs核和sgmii核对接起来.由于MDIO,我们这边没有去使用.使用的是强制输出.我调试了两天才发现可能是交换机这边设置可能有问题,这边使用的 BCM56634,一开始也不熟悉,最后去请教了别人才把自动连接把它关了.然后ok了.我把交换

Arduino调试温湿度传感器AM2321

AM2321是广州奥松电子生产的数字式温湿度传感器.虽是国产品牌,其精度也可以与国外的主流温湿度传感IC媲美. 尺寸:11.3x7.8x4mm(长x宽x高) 封装:0.05 pitch PTH 工作电压:2.6~5V 接口:I2C,最大速率100kbps,有特殊时序要求 分辨率:温度0.1°C,相对湿度0.1%RH 精度:室温时温度误差+/-0.3°C,相对湿度误差+/-3%RH 重复性:温度+/-0.2°C,相对湿度+/-0.1%RH 美中不足:与国外同精度产品相比,AM2321的重复性和漂移

keil中的串口调试:

keil中串口的虚拟调试信息在通过View-serial windows-#usart1/2/3/4/debug(printf)可以看到.当然也可以通过虚拟串口VSPD+串口调试助手在外部实现,方法如下: 虚拟 串口使用:步骤 1 下载虚拟串口软件,虚拟2个连接的串口COMA/COMB,这两个串口与PC机的真实物理串口没关系.两边的设置相同 2 打开串口通讯助手,将A分配给串口通讯助手,则B就分配给下面的COMx 2 在MDK中输入命令行或者将下面的做成debug.ini文件加载 MODE CO

远程debug调试java代码

远程debug调试java代码 日常环境和预发环境遇到问题时,可以用远程调试的方法本地打断点,在本地调试.生产环境由于网络隔离和系统稳定性考虑,不能进行远程代码调试. 整体过程是通过修改远程服务JAVA_OPTS参数,然后本地通过Eclipse或IDEA等工具调试. 下面简单介绍下理论. 理论 JPDA(Java Platform Debugger Architecture)是Java平台调试体系结构的缩写.由3个规范组成,分别是JVMTI(JVM Tool Interface),JDWP(Ja

hadoop下远程调试方法

JPDA 简介Sun Microsystem 的 Java Platform Debugger Architecture (JPDA) 技术是一个多层架构,使您能够在各种环境中轻松调试 Java 应用程序.JPDA 由两个接口(分别是 JVM Tool Interface 和 JDI).一个协议(Java Debug Wire Protocol)和两个用于合并它们的软件组件(后端和前端)组成.它的设计目的是让调试人员在任何环境中都可以进行调试.更详细的介绍,您可以参考使用 Eclipse 远程调

使用Arduino Wire Library读取温湿度传感器AM2321

AM2321是采用I2C总线或单总线通讯的国产温湿度传感器.在AM2321手册中,当采用I2C通讯时,手册指定了多处需要主机等待的时间间隔,包括: (1)唤醒传感器时,从机不回复ACK,但主机主要等待800us~3ms再发送STOP信号: (2)主机发送读/写指令后,需等待至少1.5ms再发送读取时序: (3)读返回数据时,主机发送I2C地址后,需等待至少30us以上才能发送下一个串行时钟. 由于Arduino标准库Wire中的函数不支持指定(1)和(3)中的等待间隔,因此在之前的日志中,采用关