存档

2012年2月 的存档

RTMP 协议研究(转载)

2012年2月22日
RTMP 协议研究(转载)已关闭评论

原文地址:http://blog.csdn.net/chenyanxu/archive/2009/09/02/4511087.aspx
正文开始:

RTMP 协议研究

1 协议研究概述
   协议设计和分析一直都是在工作遇到,正好在这里总结一下,说到协议,在这个网络的时代,没有人可以离开它了。他存在我们生活中的任何角落,只不过我们平时,并没有注意到它的存在,可以这么说如果没有协议,我们生活和日常的工作生产都不能进行。如果仔细想想你生活中用到的所有东西,协议已经包含其中。那到底什么是协议呢?说的简单一点就是双方达成的共识,以便更好的交流,理论上协议是什么呢?如果学过《信号与系统》的人都知道有个简单的道理,就是信息在经过一个管道的符号集,到另一个符号集时信息不会丢失。

    任何复杂的事物都有个最简单的本质,网络上的协议也是这样,有个最基本的本质。除去上下层的概念,协议就只剩下通信双方实体的规则。

   一般的协议都包含最基本的协议头,不管是物理层、链路层、还是网络层,这个头就构成了协议的本质东西。通常协议头要包含以下最基本的三项信息:

双方实体的唯一标示,用来标示通信双方的实体。
类型描述或者是净核描述,标志净核的内容。
协议净核的长度,用来在萃取净核的内容应用。
   其中,前两项是必须要有的,没有他们,通信双方的交互根本得不到保证,第三项在不太灵活的通信中可以去掉,而有第二项的类型推出。

    协议的丰富性,有净核的多样性体现。

   协议头除了以上的三项,还可以增加更多的信息(比如控制信息、时间信息等),取决于具体的应用。找到这些基本的东西,再去看协议的时候,能够更好的抓住协议的主体进行分析和设计了。

2 RTMP 协议概述
   RTMP 协议是被 Flash 用于对象、视频、音频的传输。该协议建立在 TCP 协议或者轮询 HTTP 协议之上, RTMP 协议就像一个用来装数据包的容器,这些数据可以是 AMF 格式的数据,也可以是 FLV 中的视 / 音频数据。一个单一的连接可以通过不同的通道传输多路网络流,这些通道中的包都是按照固定大小的包传输的 .

3 RTMP 协议部分

3.1 协议头
struct RTMP_HEAD

{

      char cChannelid : 6;// 第一个字节的后 6 位

      char cCheadsize ; // 第一个字节的头两位

      char cTimer[3];  // 三个字节表示的时间信息

      char cLength[3]; // 三个字节表示的长度

      char cDatatype; // 数据类型

      char sStreamid[4]; // 流标识

};

这里有三个最基本的元素(唯一标示 )、(类型 )和(净核的长度 )分别是: cChannelid 、 cDatatype 和 cLength 。

3.2 数据类型
数据类型 决定了协议上层可以做的具体的事情,和使用协议的人必须遵循的规则。

同时数据类型 说明了净核 的基本内容。

RTMP 数据类型:

0×01,  Chunk Size,  changes the chunk size for packets 
0×02,  Unknown,   anyone know this one? 
0×03,  Bytes Read,  send every x bytes read by both sides 
0×04,  Ping,  ping is a stream control message, has subtypes 
0×05,  Server BW,  the servers downstream bw 
0×06,  Client BW,  the clients upstream bw 
0×07,  Unknown,  anyone know this one? 
0×08,  Audio Data,  packet containing audio 
0×09,  Video Data,  packet containing video data 
0×0A-0×11, Unknown,  anyone know? 
0×12,  Notify,  an invoke which does not expect a reply 
0×13,  Shared Object,  has subtypes 
0×14,  Invoke,  like remoting call, used for stream actions too. 

3.3 协议的净核
   RTMP 的协议净核是用 AMF 格式来描述, AMF 格式本身的产生就是为了 RTMP 协议服务的,最初的 RTMP 采用 XML 的形式传输数据,但 XML 只是字符形式的值对的格式传输数据,而随着应用的普及这完全不能满足要求了,比如对象、结构、数组,甚至可以是数据集,配合 DataGrid 组件可以很方便地显示数据。
为了处理复杂数据类型,采用一种独有的方式使 Flash 与应用服务器间可以来回传送数据势在必行。于是 AMF 应运而生。

AMF 是 Adobe 独家开发出来的通信协议,它采用二进制压缩,序列化、反序列化、传输数据,从而为 Flash 播放器与 Flash Remoting 网关通信提供了一种轻量级的、高效能的通信方式。 
AMF 最大的特色在于可直接将 Flash 内置对象,例如 Object, Array, Date, XML ,传回服务器端,并且在服务器端自动进行解析成适当的对象,这就减轻了开发人员繁复工作,同时也更省了开发时间。由于 AMF 采用二进制编码,这种方式可以高度压缩数据,因此非常适合用 来传递大量的资料。数据量越大, Flash Remoting 的传输效能就越高,远远超过 Web Service 。至于 XML, LoadVars 和 loadVariables() ,它们使用纯文本的传输方式,效能就更不能与 Flash Remoting 相提并论了。

注意: Flash Remoting 需要浏览器支持 Binary POST , Flash 播放器在 Netscape 6.x. 环境下运行 Flash Remoting 会不起作用( Flash Remoting 调用没有效果也不返回错误), Netscape 7 已经纠正了这个 bug 。对于早期 Safari 和 Chimera 版的苹果机也有这个问题。
同样是轻量级数据交换协议,同样是通过调用远程服务,同样是基于标准的 HTTP 和 HTTPS 协议, Flash Remoting 为什么选择了使用 AMF 而放弃了 SOAP 与 Flash 播放器通信呢  有如下原因:
SOAP 将数据处理成 XML 格式,相对于二进制的 AFM 太冗长了; 
AMF 能更有效序列化数据;因为 AMF 的初衷只是为了支持 Flash ActionScript 的数据类型,而 SOAP 却致力于提供更广泛的用途; 
AMF 支持 Flash 播放器 6 只需要浏览器增加 4 KB 左右(压缩后)的大小,而 SOAP 就大多了; 

SOAP 的一些头部文件请求在 Flash 播放器 6 不支持。那 Flash 播放器 6 为什么能访问基于 SOAP 的 Web 服务呢?原来 Flash Remoting 网关将 SOAP 请求在服务器端与转换成 AFM 格式,然后利用 AFM 与 Flash 播放器通信。

另外, AMF 包中包含 onResult 事件(比如说 response 事件)和 onStatus 事件(比如说 error 事件),这些事件对象在 Flash 中可以直接使用。 
AMF 从 Flash MX 时代的 AMF0 发展到现在的 AMF3 。 AMF3 用作 Flash Playe 9 的 ActionScript 3.0 的默认序列化格式,而 AMF0 则用作旧版的 ActionScript 1.0 和 2.0 的序列化格式。 在网络传输数据方面, AMF3 比 AMF0 更有效率。 AMF3 能将 int 和 uint 对象作为整数( integer )传输,并且能序列化 ActionScript 3.0 才支持的数据类型 , 比如 ByteArray , XML 和 Iexternalizable 。

AMF 很好的解决了内容的丰富性。(具体 AMF 格式参考附件格式文档)

3.3.1 AMF中的数据类型Data Types

AMF0 supports the following data types (with their type field values):

NUMBER = 0x00
BOOLEAN = 0x01
STRING = 0x02
OBJECT = 0x03
MOVIECLIP = 0x04
NULL_VALUE = 0x05
UNDEFINED = 0x06
REFERENCE = 0x07
ECMA_ARRAY = 0x08
OBJECT_END = 0x09
STRICT_ARRAY = 0x0a
DATE = 0x0b
LONG_STRING = 0x0c
UNSUPPORTED = 0x0d
RECORD_SET = 0x0e
XML_OBJECT = 0x0f
TYPED_OBJECT = 0x10

Binary Format
AMF format for a value/object consists of a type byte (see above) followed by zero or more bytes. This section describes the bytes following the type byte for various types.

NUMBER (type byte: 0x00)
Numbers are stored as 8 byte (big endian) float double. On x86 you can just byteswap a double to encode it correctly.

BOOLEAN (type byte: 0x01)
A boolean is encoded in one byte. FIXME: is true sent as 0xff? 0x01?

STRING (type byte: 0x02)
A string is encoded as a 2 byte (big endian) count (number of bytes) followed by that many bytes of text. Note: there is no null terminator.

I think the text is assumed to be UTF-8. Can someone double check me on this?

NULL_VALUE (type byte: 0x05)
A null has zero bytes following the type byte

UNDEFINED (type byte: 0x06)
A undefined has zero bytes following the type byte

OBJECT (type byte: 0x08)
An object is encoded as a series of key/value pairs. The key is encoded as a STRING (above) WITH NO TYPE BYTE, and the value is any AMF value.

The object encoding is terminated by 0x000009 (that is a zero length string key, followed by the OBJECT_END type byte described below.

OBJECT_END (type byte: 0x09)
This is not really a value, but a marker for the end of an OBJECT. See above.

STRICT_ARRAY (type byte: 0x0a)
This is the encoding for arrays such as ["foo", "bar", 1, 2, 3]. For a hash (a set of key/value pairs) you’ll need to use OBJECT above.

An array is encoded as 4 byte (big endian) integer which is the number of elements in the array, followed by that many AMF values.

That’s it. There’s no terminator of any kind.

Use in shared object files
While most AMF objects are just a value, there is a special variation used by shared object files for properties. Rather than start with the type field, followed by the length, it starts with a byte count, then the name, and then the regular AMF type field, the length, and then the data.

3.4 客户端和服务器的连接过程

3.4.1客户和服务器的握手

   Flash Player 以系统时间作为种子通过某种算法生成的数字签名,大小是 1537 字节向服务器发起第一次握手,服务器根据客户端的数字签名产生一个 3073 字节的验证包,给客户端,客户端在接受到服务器的回应以后会发送一个 1536 字节的回复。

具体的流程:

发送第一次握手包 handshark1
接收第二次握手包 handshark2
发送的三次握手包 handshark3
第一个握手包 handshark1 和服务器的回复握手包 handshark2 都是以 0X03 开头。这三次握手不是 RTMP 协议本身的内容,所以在这并没有包含 RTMP  的协议头。是服务器的厂家自己产品做验证用的,严格的说就是你必须用  Adobe 的客户端和服务器才能使用我的协议。

3.4.2客户和服务器通信
   具体连接和请求视频的过程

发送 rtmp_connect 命令
发送本地带宽消息 . 默认是 125000
服务器返回服务器带宽信息
服务器返回本地带宽信息
服务器返回连接成功消息 "NetConnection.Connect.Success"
客户端发送创建流请求 encodeCreateStreamPacket
服务器返回创建流成功消息
客户端发送播放文件消息 Rtmp_Play
服务器返回 TYPE_CHUNK_SIZE 消息
服务器返回开始播放消息 "NetStream.Play.Start"
服务器返回视频信息 (TYPE_STREAM_METADATA) ,包括大小,宽高,速率等等信息--文件长度可以在这里推算出来
RTMP 的净核决定了内容服务, adobe 的服务器采用的 AMF 格式的字串命令来控制视频的传输和播放,具体的字串命令信息如下:

(注:字串的定义有厂家( adobe )自己定义,只要满足 AMF 的格式就可以) 
NetConnection.Call.Failed
NetConnection.Call.BadVersion 
NetConnection.Connect.AppShutdown
NetConnection.Connect.Closed
NetConnection.Connect.Rejected
NetConnection.Connect.Success
NetStream.Clear.Success
NetStream.Clear.Failed
NetStream.Publish.Start
NetStream.Publish.BadName
NetStream.Failed
NetStream.Unpublish.Success
NetStream.Record.Start
NetStream.Record.NoAccess
NetStream.Record.Stop
NetStream.Record.Failed
NetStream.Play.InsufficientBW
NetStream.Play.Start
NetStream.Play.StreamNotFound
NetStream.Play.Stop
NetStream.Play.Failed
NetStream.Play.Reset
NetStream.Play.PublishNotify
NetStream.Play.UnpublishNotify
NetStream.Data.Start
Application.Script.Error
Application.Script.Warning
Application.Resource.LowMemory
Application.Shutdown
Application.GC
Play
Pause
demoService.getListOfAvailableFLVs
getStreamLength
connect
app
flashVer
swfUrl
tcUrl
fpad
capabilities
audioCodecs
audioCodecs
videoCodecs
videoFunction
pageUrl
createStream
deleteStream
duration
framerate
audiocodecid
audiodatarate
videocodecid
videodatarate
height
width

3.4.2数据的萃取
      在服务器返回开始播放消息 "NetStream.Play.Start" 之后,服务器就会开始给客户端传输数据了,一般数据的萃取都是先解析协议的头,然后根据协议头中数据类型和净核长度就可以把数据部分取出, RTMP 协议也是这样。

struct RTMP_HEAD

{

      char cChannelid : 6;// 第一个字节的后 6 位

      char cCheadsize ; // 第一个字节的头两位

      char cTimer[3];  // 三个字节表示的时间信息

      char cLength[3]; // 三个字节表示的长度

      char cDatatype; // 数据类型

      char sStreamid[4]; // 流标识

}

      首先判断 cDatatype 是那种类型,然后根据不同的类型进行萃取数据部分,进行不同的处理,获取视频的数据的方式先看是否是一下的类型:

0×08  Audio Data  packet containing audio 
0×09  Video Data  packet containing video data 

根据净核的长度读取出内存中的音视频数据,这里的音视频数据是有一定编码格式的数据,这个取决于应用的具体配置, Flash play 使用的是 FLV 的格式。要对这部分数据进行存取,还有做一部分工作,对 FLV 的视频数据进行去壳,取出数据保存文件就可以了。

————————————————————————————

以下是百度百科上转载过来的,方便与上文对照理解:

rtmp

Real Time Messaging Protocol(实时消息传送协议协议)概述

实时消息传送协议是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的私有协议。它有三种变种:

1)工作在TCP之上的明文协议,使用端口1935;

2)RTMPT封装在HTTP请求之中,可穿越防火墙;

3)RTMPS类似RTMPT,但使用的是HTTPS连接;

介绍:

RTMP协议是被Flash用于对象,视频,音频的传输.该协议建立在TCP协议或者轮询HTTP协议之上.

RTMP协议就像一个用来装数据包的容器,这些数据可以是AMF格式的数据,也可以是FLV中的视/音频数据.

一个单一的连接可以通过不同的通道传输多路网络流.这些通道中的包都是按照固定大小的包传输的.

网络连接(Connection)

一个Actionscript连接并播放一个流的简单代码:

复制内容到剪贴板代码:

var videoInstance:Video = your_video_instance;

var nc:NetConnection = new NetConnection();

var connected:Boolean = nc.connect("rtmp:/localhost/myapp");

var ns:NetStream = new NetStream(nc);

videoInstance.attachVideo(ns);

ns.play("flvName");

默认端口为1935

握手

Client → Server :向服务器发出握手请求.这不属于协议包一部分,该握手请求第一个字节为(0×03),其后跟着1536个字节.经管看上去这部分的内容对于RTMP协议来说并不是至关重要的,但也不可随意对待.

Server → Client :服务器向客户端回应握手请求.这部分的数据仍然不属于RTMP协议的部分.该回应的其实字节仍然为(0x03),但是后边跟着个长度为1536个字节 (一共为3072 )的包块.第一个1536块看上去似乎可以是任意内容,甚至好像可以是Null都没有关系.第二个1536的代码块,是上一步客户端向服务器端发送的握手请求的内容.

Client→Server:把上一步服务器向客户端回应的第二块1536个字节的数据块.

至此客户端与服务器端的握手结束,下面将发送RTMP协议的包内容.

Client → Server :向服务器发送连接包.

Server → Client :服务器回应.

… …. 等等… …

RTMP 数据类型

0×01 Chunk Size changes the chunk size for packets

0×02 Unknown anyone know this one?

0×03 Bytes Read send every x bytes read by both sides

0×04 Ping ping is a stream control message, has subtypes

0×05 Server BW the servers downstream bw

0×06 Client BW the clients upstream bw

0×07 Unknown anyone know this one?

0×08 Audio Data packet containing audio

0×09 Video Data packet containing video data

0x0A – 0×11 Unknown anyone know?

0×12 Notify an invoke which does not expect a reply

0×13 Shared Object has subtypes

0×14 Invoke like remoting call, used for stream actions too.

Shared Object 数据类型

0×01 Connect

0×02 Disconnect

0×03 Set Attribute

0×04 Update Data

0×05 Update Attribute

0×06 Send Message

0×07 Status

0×08 Clear Data

0×09 Delete Data

0x0A Delete Attribute

0x0B

Initial Data

RTMP包结构

RTMP包 包含一个固定长度的包头和一个最长为128字节的包体.包头可以是下面4种长度的任意一种:12, 8, 4, or 1 byte(s).

第一个字节的前两个Bit很重要,它决定了包头的长度.它可以用掩码0xC0进行"与"计算.下面的表格罗列了可能的包头长度:Bits Header Length

00 12 bytes

01 8 bytes

10 4 bytes

11 1 byte

我们在这里讨论关RTMP包结构的问题并不是非常的详细.我们在以后有时间会讨论关于AMF的问题(敬请期待…:loveliness:),其实RTMP包结构就是使用了AMF格式.

关于流的操作我们需要进一步研究,在论坛中的http://www.openred5.com/bbs /viewthread.php?tid=175&extra=page%3D1这篇文章研究的还是不错的,大家可以参考.不过下面可以列一个关于客户端向服务器端发送流的流程:

Client→Server :发送一个创建流的请求.

Server→Client :返回一个表示流的索引号.

Client→Server :开始发送.

Client→Server :发送视音频数据包(这些包在同一个频道(channel)并用流的索引号来唯一标识).

IT技术 ,

windows下编译librtmp、rtmpdump(转载)

2012年2月22日
windows下编译librtmp、rtmpdump(转载)已关闭评论

原文网站:http://zhaostudy2.blog.163.com/blog/static/1353502052011182538414/

    这段时间做实时视频的网页直播遇到了很多困难。

    开始时,迫于项目时间的压力,觉得没有足够的时间学习和分析如何将实时视频发送到RTMP流媒体服务器作为实时流,只好使用最粗糙的做法是:先把获取到的实时视频以RTP包的形式 发送给本机,然后本机程序中调用ffmpeg将接收到的RTP包 以RTMP的形式转发到Red5,最后,从网页上获取播放列表,播放实时视频。

    这种做法中存在很多问题:(1)多了一层rtp包到rtmp服务器的转发,浪费很多处理器的时间。(2)多了一层转发,系统稳定性很有问题。在视频流转发了一定时间后,ffmpeg会奇怪地停止转发,原因不明。(3)ffmpeg的视频流播放控制难以实现。在网页上停止播放和继续播放视频时,既要控制发送 RTP包,又要控制RTMP包,很麻烦。

    后来,分析了一下ffmpeg的源代码,发现FFmpeg中对RTMP的支持部分就是使用了RTMPDump中的librtmp。于是,我就打算直接使用librtmp与Red5建立rtmp连接,将实时视频直接发到Red5。

    最近过年,在家里闲着,就认真研究一下如何使用librtmp直接将实时视频发送到Red5。我们首先要做的就是编译出librtmp的动态库和静态库。

    RTMPDump项目官方网站在:http://rtmpdump.mplayerhq.hu/ 。对RTMP协议的实现在其中librtmp中。这是一个匈牙利人在2009年,Adobe公司还没有公开RTMP协议的情况下对RTMP协议的实现得。 官方网站中只提供了程序源代码和动态链接库(dll),要在开发中方便地使用RTMPDump,还需要自己编译它的静态库(lib)。

==> 编译librtmp静态库

    从官方网站http://rtmpdump.mplayerhq.hu/ 下载RTMPDump源代码。

    要编译librtmp,还需要另外3个库:zlib、OpenSSL、PolarSSL。

    zlib是用于数据压缩的函数库,数据压缩效果比较好,早在1995年就发布了第一版,目前仅支持LZ77变种算法、DEFLATE算法。(http://www.zlib.net/)。

    OpenSSL和PolarSSL 是对SSL(Security Socket Layer,加密套接字协议层)的实现。(http://www.openssl.org/ http://polarssl.org/)。

    (1)使用VC++6.0新建一个静态库工程,命名为librtmp,如下图所示:

[原创] 实时视频在网页直播--windows下编译librtmp、rtmpdump - 小小研究院 - 小小研究院

     (2)把RTMPDump源代码目录下的librtmp目录下的所有文件 复制到工程目录librtmp\下,并在VC++6.0中的Source Files和Header Files文件夹中添加librtmp相应的文件,如下图所示:

[原创] 实时视频在网页直播--windows下编译librtmp、rtmpdump - 小小研究院 - 小小研究院

     (3)下载zlib开发包 http://download.csdn.net/source/3013660。把其中的zdll.lib、zlib.def、zlib.h、zconf.h放到新建的工程目录librtmp\下。

     (4)下载openssl开发包 http://download.csdn.net/source/3013684。把其中的libeay32.lib、ssleay32.lib 及openssl文件夹 复制到工程目录librtmp\下,并在VC++6.0的“工具”->“选项”->“目录”-> “ Include files ”中添加当前的工程目录librtmp\。如下图所示:

[原创] 实时视频在网页直播--windows下编译librtmp、rtmpdump - 小小研究院 - 小小研究院

    (5) 下载PolarSSL源代码 http://download.csdn.net/source/3013696。解压出来,用VC++6.0打开\visualc\polarssl.dsw ,可以编译出静态库(polarssl.lib)。然后将头文件所在的文件夹polarssl\ 和polarssl.lib复制到工程目录librtmp\下。

    (6)编译静态库工程,这时会在多个文件中出现这样一个错误: error C2065: ‘__FUNCTION__’ : undeclared identifier 。解决办法是,在存在这个错误的.c文件的中添加一个宏定义:#define __FUNCTION__ "" 。问题就解决了。再编译工程即可得到librtmp.lib,如下图所示:

[原创] 实时视频在网页直播--windows下编译librtmp、rtmpdump - 小小研究院 - 小小研究院

[原创] 实时视频在网页直播--windows下编译librtmp、rtmpdump - 小小研究院 - 小小研究院

     (7)但是,这样编译出来的librtmp.lib在使用的时候会出现很多个外部符号未定义的错误。如下图所示:

[原创] 实时视频在网页直播--windows下编译librtmp、rtmpdump - 小小研究院 - 小小研究院

    这是librtmp的条件编译导致的问题,解决方法是:在rtmp_sys.h中把代码:

#ifdef _XBOX
#include <xtl.h>
#include <winsockx.h>
#define snprintf _snprintf
#define strcasecmp stricmp
#define strncasecmp strnicmp
#define vsnprintf _vsnprintf

#else /* !_XBOX */
#include <winsock2.h>
#include <ws2tcpip.h>
#endif

    改为

#include <winsock2.h>
#include <ws2tcpip.h>

#define snprintf _snprintf
#define strcasecmp stricmp
#define strncasecmp strnicmp
#define vsnprintf _vsnprintf

    然后,删除rtmp.c中的如下代码:

#ifdef _DEBUG
  fwrite(buf, 1, len, netstackdump);
#endif

#ifdef _DEBUG
extern FILE *netstackdump;
extern FILE *netstackdump_read;
#endif

#ifdef _DEBUG
      fwrite(ptr, 1, nBytes, netstackdump_read);
#endif

(8)编译rtmp.c即可得到librtmp.lib

    我已经将rtmpdump编译好的静态库、动态库以及源代码打成一个包,放到 http://download.csdn.net/source/3014336。如果不想自己编译,可以从这里下载,也可以直接下载下面的附件:http://dl.iteye.com/topics/download/3d9886b0-7e7a-3264-ba43-c23d207f719c

———————————-

林祥杰点评:

openssl和PolarSSL只需要用到一个,若不使用ssl都可以不添加,源代码里有宏CRYPTO可以关闭

IT技术 , ,

RTMP协议详解(转)

2012年2月22日
RTMP协议详解(转)已关闭评论

Real Time Messaging Protocol(实时消息传送协议协议)是Adobe Systems公司为Flash播放器和服务器之间音频、视频和数据传输开发的私有协议。

具体使用RTMP的AS代码大概如下:

var videoInstance:Video = your_video_instance;

var nc:NetConnection = new NetConnection();

var connected:Boolean = nc.connect("rtmp://localhost/myapp");

var ns:NetStream = new NetStream(nc);

videoInstance.attachVideo(ns);

ns.play("flvName");

Adobe也在官方网站已经提供了RTMP协议的官方文档说明,为什么要写这个系列文章最大的原因只是对前一段工作的一个总结和回顾,最近两个月,实现了一个RTMP Server的c++版本,把公司的流媒体服务和flash无缝对接起来。希望我的文字能给后来研究这个协议的同学有一定的帮助。

RTMP协议是一个基于TCP的高层协议族,当然这个玩意据说还有UDP协议版本的,不过现在还没有出来,好像Adobe下一版本的FMS会提供支持。下文将要描述的是TCP协议版本的协议。

RTMP协议的概要理解:

RTMP协议是为了和flash之间交换信令以及媒体数据。为了提高使用效率信令和媒体数据都是使用相同的机制。因为是相同的机制Adobe就整出来了一些比较搞人的概念,当然每个协议第一次接触都是比较难理解的。

在RTMP协议中信令和媒体数据都称之为Message,在网络中传输这些Message,为了区分它们肯定是要加一个Message head的,所以RTMP协议也有一个Message head,还有一个问题因为RTMP协议是基于TCP的,由于TCP的包长度是有限制的(一般来说不超过1500个字节),而RTMP的Message长度是有可能很大的,像一个视频帧的包可能会有几十甚至几千K,这个问题就必然有一个分片的问题,在RTMP协议中对应的说法就是chunk,每一个Message + head都是由一个和多个chunk组成的。到这里对RTMP协议的概要理解就算完了。

RTMP的字节序:
       RTMP的字节序和大多数网络协议一样是大端序,也有一些字段是小端序的,不过都有特殊的说明。
RTMP的head组成

         RTMP的head在协议中的表现形式是chunk head,前面已经说到一个Message + head可以分成一个和多个chunk,为了区分这些chunk,肯定是需要一个chunk head的,具体的实现就把Message head的信息和chunk head的信息合并在一起以chunk head的形式表现。

一个完整的chunk的组成如下图所示

Chunk basic header:

该字段包含chunk的stream ID和 type 。chunk的Type决定了消息头的编码方式。该字段的长度完全依赖于stream ID,该字段是一个可变长的字段。

Chunk Msg Header:0, 3 ,7, 11

该字段包含了将要发送的消息的信息(或者是一部分,一个消息拆成多个chunk的情况下是一部分)该字段的长度由chunk basic header中的type决定。

Extend Timestamp: 0 ,4 bytes

该字段发送的时候必须是正常的时间戳设置成0xffffff时,当正常时间戳不为0xffffff时,该字段不发送。当时间戳比0xffffff小该字段不发送,当时间戳比0xffffff大时该字段必须发送,且正常时间戳设置成0xffffff。

Chunk Data
        实际数据(Payload),可以是信令,也可以是媒体数据。
Chunk basic header:
   chunk basic head的长度为1~3个字节,具体长度主要是依赖chunk stream ID的长度,所谓chunk stream ID是flash server用来管理连接的客户端的信令交互的标识,在red5的文档中称之为channel ID,协议最大支持65597个streamID 从3~65599。ID 0,1,2为协议保留,0代表ID是64~319(第二个byte + 64);1代表chunk stream ID为64~65599((第三个byte)* 256 + 第二个byte + 64)(小端表示);2代表该消息为低层的协议(在RTMP协议中控制信令的chunk stream ID都是2)。3~63的chunk stream ID就是该byte的值。没有附加的字段来标识chunk stream streamID。在这里要指出的是虽然RTMP的chunk stream ID理论是可以达到65599,但是目前使用的chunk stream ID很少,2~7都是约定的,8是用来传输publish play等命令,其他的chunk stream ID目前好像没有使用,至少我不知道用来干嘛的。
      所以目前chunk basic head的长度一般为1个字节。这一个字节由两部分组成
                           +++++++++++++++++++
                            +fmt    + cs id               +
                            +++++++++++++++++++
      fmt占两个bit用来标识紧跟其后的chunk Msg Header的长度,cs id占六个bit。
      两位的fmt取值为 0~3,分别代表的意义如下:
      case 0:chunk Msg Header长度为11;
      case 1:chunk Msg Header长度为7;
      case 2:chunk Msg Header长度为3;
      case 3:chunk Msg Header长度为0;
      所以 只有一个字节的chunk basic header取值为 chunk basic header = (fmt << 6) | (cs id).

Chunk Msg Header:

Chunk Msg Header的长度是可变的,Chunk Msg Header可变的原因是为了压缩传输的字节数,把一些相同类型的chunk的head去掉一些字节,换句话说就是四种类型的包头都可以通过一定的规则还原成11个字节,这个压缩和还原在RTMP协议中称之为复用/解复用。

那我们以11个字节的完整包头来解释Chunk Msg Header,如图所示

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

+ timestamp + message length + message type id + message stream id +

++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++

Timestamp:3bytes

对于type 0的chunk,绝对时间戳在这里表示,如果时间戳值大于等于0xffffff(16777215),该值必须是0xffffff,且时间戳扩展字段必须发送,其他情况没有要求。

message length:3bytes

Message的长度,注意这里的长度并不是跟随chunk head其后的chunk data(Payload)的长度,而是前文提到的一条信令或者一帧视频数据或音频数据的长度。前文提到过信令或者媒体数据都称之为Message,一条 Message可以分为一条或者多条chunk。

message type id:1byte

Message的类型ID,具体的值将在后文专门来讨论。

message stream id:4bytes

message stream id的字节序是小端序,这个字段是为了解复用而设计的,RTMP文档上说的相当的模糊,

message stream ID可以使任意值,不同的消息流复用成相同的chunk stream,基于它们的ID能够解复用。于chunk stream 是相关的,这个字段是一个不透明的值没有整明白什么意思,我的理解就是用来标识和服务器连接的flash端的序号。

长度是7 bytes 的chunk head,该类型不包含stream ID,该chunk的streamID和前一个chunk的stream ID是相同的,变长的消息,例如视频流格式,在第一个新的chunk以后使用这种类型,注意其中时间戳部分是相对时间,为何上一个绝对时间之间的差值 如图所示:

++++++++++++++++++++++++++++++++++++++++++++++++++++++

+ timestamp    delta + message length + message type id +

++++++++++++++++++++++++++++++++++++++++++++++++++++++

        3 bytes的chunk head,该类型既不包含stream ID 也不包含消息长度,这种类型用于stream ID和前一个chunk相同,且有固定长度的信息,例如音频流格式,在第一个新的chunk以后使用该类型。如图所示:

                           ++++++++++++++++++++

                           + timestamp    delta +

                           ++++++++++++++++++++

        0 bytes的chunk head,这种类型的chunk从前一个chunk得到值信息,当一个单个消息拆成多个chunk时,这些chunk除了第一个以外,其他的都应该使用这种类型,

chunk的长度:

chunk的长度初始长度固定为 128个字节,但是这个值并不是不可变的,在客户端和服务端建立连接以后,客户端和服务端都可以通过发送信令的方式来通知对端修改chunk的长度,理论上来说可以修改chunk的最长长度为65536。这里chunk的长度是指chunk的数据部分的长度,即chunk data(payload)的长度,如果一条Message的数据长度超过了chunk的长度,就必须把Message分割成多条chunk,即如果一条视频类型Message长度为2000个byte,chunk长度为1500,则该Message将会分割成两条chunk,第一条的chunk data长度为1500,第二条的chunk data长度为500。当然这两条chunk的chunk head肯定是不同的,其中第二条chunk的chunk head就是0字节的。

转自《RTMP协议详解(一) (二) (三)

IT技术 , , ,

差分与单端(转载)

2012年2月21日
差分与单端(转载)已关闭评论

一、基本区别

不说理论上的定义,说实际的

单端信号指的是用一个线传输的信号,一根线没参考点怎么会有信号呢?

easy,参考点就是地啊。也就是说,单端信号是在一跟导线上传输的与地之间的电平差

那么当你把信号从A点传递到B点的时候,有一个前提就是A点和B点的地电势应该

差不多是一样的,为啥说差不多呢,后面再详细说。

差分信号指的是用两根线传输的信号,传输的是两根信号之间的电平差。

当你把信号从A点传递到B点的时候,A点和B点的地电势可以一样也可以不一样

但是A点和B点的地电势差有一个范围,超过这个范围就会出问题了。

二、传输上的差别

单端信号的优点是,省钱~方便~

大部分的低频电平信号都是使用单端信号进行传输的。一个信号一根线,最后

把两边的地用一根线一连,完事。

缺点在不同应用领域暴露的不一样

归结起来,最主要的一个方面就是,抗干扰能力差。

首先说最大的一个问题,地电势差以及地一致性。

大家都认为地是0V,实际上,真正的应用中地是千奇百怪变化莫测的一个东西

我想我会专门写一些地方面的趣事。

比如A点到B点之间,有那么一根线,用来连接两个系统之间的地

那么如果这根线上的电流很大时,两点间的地电势可能就不可忽略了,这样一个信号

从A的角度看起来是1V,从B的角度看起来可能只有0.8V了,这可不是一个什么好事情

这就是地电势差对单端信号的影响。

接着说地一致性。实际上很多时候这个地上由于电流忽大忽小,布局结构远远近近

地上会产生一定的电压波动,这也会影响单端信号的质量。

差分信号在这一点有优势,由于两个信号都是相对于地的

当地电势发生变化时,两个信号同时上下浮动(当然是理想状态下)

差分两根线之间的电压差却很少发生变化,这样信号质量不久高了吗?

其次就是传输过程中的干扰,当一根导线穿过某个线圈时,且这根线圈上通着交流电

时,这根导线上会产生感应电动势~~好简单的道理,实际上工业现场遇到的大部分

问题就是这么简单,可是你无法抗拒~

如果是单端信号,产生多少,就是多少,这就是噪声你毫无办法。

但是如果是差分信号,你就可以考虑拉,为啥呢,两根导线是平行传输的

每根导线上产生的感应电动势不是一样吗,两个一减,他不久没了吗~

确实,同样的情况下,传输距离较长时,差分信号具有更强的驱动能力、更强的

抗干扰能力,同样的,当你传输的信号会对其他设备有干扰时,差分信号也比

单端信号产生的信号相对小,也就是常说的EMI特性(存疑,是这么说把?)

三、使用时需要注意di

由于差分比单端有不少好处,在模拟信号传输中很多人愿意使用差分信号

比如桥式应变片式力传感器,其输出信号满量程时有的也只有2mV

如果使用单端信号传输,那么这个信号只要电源的纹波就能把他吃光。

所以实际上,都是用仪表运方进行放大后,再进行处理。

而仪表运方正是处理差分信号最有力的几个工具之一。

但是,使用差分信号时,一定要注意一个问题,共模电压范围。

也就是说,这两根线上的电压,相对于系统的地,还是不能太大。

你传输0.1V的信号没问题,但是如果一根是 1000.0 另外一根是 1000.1,那就不好玩了

问题在于,在很多场合下使用差分信号都是为了不让两个系统的地简单的共在一起

更不能把差分信号中的一根直接接在本地系统的地上,那不白费尽吗–又成单端了

那么如何抑制共模电压呢?

其实也挺简单的,将两根线都通过一个足够大的电阻,连接到系统的地上。

这就像一根拴在风筝上的线,我在地上跑跑跳跳,不会影响风筝的高度

但是你永远逃不出我的视线,而我的视线,在电子行业,叫共模电压范围~~嘿嘿

最后,回答板上一个网友的问题

单端转差分怎么转。

单单将单端信号用反向跟随器跟随并不是不行

但是差分信号被平白的放大了2倍~~

常见的用仪表运方+普通运方搭建的单端转差分是个很好的例子。

另外有一篇也是说明单端与差分输入的差别,摘录了一段,供参考。

差分信号和普通的单端信号走线相比,最明显的优势体现在以下三个方面:

a.抗干扰能力强,因为两根差分走线之间的耦合很好,当外界存在噪声干扰时,几乎是同时被耦合到两条线上,而接收端关心的只是两信号的差值,所以外界的共模噪声可以被完全抵消。

b.能有效抑制EMI,同样的道理,由于两根信号的极性相反,他们对外辐射的电磁场可以相互抵消,耦合的越紧密,泄放到外界的电磁能量越少。

c.时序定位精确,由于差分信号的开关变化是位于两个信号的交点,而不像普通单端信号依靠高低两个阈值电压判断,因而受工艺,温度的影响小,能降低时序上的误差,同时也更适合于低幅度信号的电路。目前流行的LVDS(low voltage differential signaling)就是指这种小振幅差分信号技术。

IT技术 , ,

数字逻辑标准及接口技术

2012年2月21日
数字逻辑标准及接口技术已关闭评论

我们知道,0和1是数字世界的两个基本元素,在数字电路中它们由特定范围的高低电平来表示。数字电路发展的早期,绝大多数数字器件都采用TTL和CMOS数字逻辑标准。近几年,产生了许多针对不同应用的低压、高速的数字逻辑标准,例如LVTTL、LVCMOS、LVDS、HSTL、SSTL、LVPECL等。

实际应用中共有二三十种数字逻辑信号标准,根据其物理连接特性不同,可以划分为单端逻辑信号、单端差分逻辑信号和差分逻辑信号三大类。在对它们详细介绍之前,我们首先了解一下数字逻辑信号的几个重要专业术语。

     a. 门限电压(VTH ) 
–      -顾名思义,VTH为逻辑状态高或低转换的门限电压,在逻辑器件中,当信号电压高于VTH 为逻辑高,反之则为逻辑低,通常VTH为电源电压的1/2。 
—  b. 输出高电平(VOH)和输出低电平(VOL) 
—     确切地说VOH应该为逻辑器件输出高电平的下限,VOL为输出低电平的上限。通常在VOH和VOL之间有一个电压缓冲区,这样在实际电路中输出逻辑信号迭加噪声后,就不会导致对逻辑状态的错误判断。 
—  c. 输入高电平(VIH)和输入低电平(VIL) 
—     VIH为输入高电平的下限,VIL为输入低电平的上限。

在许多数字系统中,前一个逻辑器件的输出就是后一个逻辑器件的输入,所以必须满足VOH>VIH、VOL< VIL,否则就会出现逻辑状态判断错误。另外,它们之间的差值称为噪声容限,外部叠加的噪声应小于噪声容限,否则也会出现逻辑状态判断错误。

单端数字逻辑信号
—单端信号是两个逻辑器件互连最基本的方法,它只需要一条连线来实现逻辑信号传输。另外,它也可以实现单端发送、差分接收的连接方式,这时差分接收器的另外一个输入端提供参考接地电平,即图4中的VREF接地。-单端信号连接的数字逻辑标准主要有TTL、CMOS、LVTTL、LVCMOS、PCI等,它们的主要性能参数如表1所示。 
—(1) 注意:信号的传输带宽是一个粗略的估算值,因为器件工艺、连线长度、PCB走线方式和应用环境都会对实际传输带宽造成影响。

单端差分逻辑信号
—单端差分信号指的是信号单端发送、差分接收的一种信号传输方式。差分接收器的两个输入端,一个接收信号,另一个提供参考电平VREF。VREF是用来设置接收器的门限电压,其大小通常为单端驱动器输出电压VDDO的1/2。相对单端信号,单端差分信号是通过降低传输信号的电平幅度,来加快晶体管的转换速度,从而提高传输带宽。 
—图6为HSTL-I单端差分信号的实际参数和信号波形图,其中单端驱动器输出电压VDDO=1.5V;门限电压VTH = VREF=1/2 VDDO=0.75V;VIL= VREF – 0.1V 、VIH= VREF + 0.1V。 
—除了HSTL-I单端差分逻辑标准外,另外一个常见的标准是美国Cypress的1.8V HSTL,也称eHSTL,其性能参数如表2所示。

差分逻辑信号
—如图7所示,差分信号是通过一对单端信号线进行传输,两条线上的信号相同,但相位相差为180°。 
—从信号传输原理看,差分信号的电平幅度比单端差分信号更低;此外,如图8,差分信号接收端VDIFF=VOH-VOL,这样可以抵消实际传输过程中迭加在两个单端信号上的共模噪声,更好地保持了信号的完整性,降低了信号整体噪声, 从而实现更高的带宽。 
—常见的差分逻辑信号标准有LVDS、SSTL、ECL、PECL等,它们的具体性能参数如表3所示。

Table3

应用
—可以说,任何一种新的数字逻辑信号标准的产生,都是实际应用需要驱动的结果,每一种标准都有各自的特点及应用环境。 
—a. TTL、CMOS系列是应用最广泛的数字逻辑标准,被数字逻辑器件厂商普遍采用; 
—b. 时钟驱动器件、SRAM、DDR SRAM 等存储器件基本都采用HSTL标准; 
—d. SSTL系列是由IBM、Hitachi等公司发起的,主要用于PC内存模快上; 
—e. PECL系列是Motorola 公司发明的,广泛应用于精度较高的时钟器件; 
—f. LVDS广泛应用于中距离传输的一些高速串行或平行接口器件。

接口技术
—在数字系统的设计和调试中,会经常遇到不同数字逻辑标准的接口问题。只要深入理解各种逻辑标准的接口电平特性;遵循VOH>VIH 、 VOL< VIL,实际噪声小于容限噪声等原则;同时注意一些影响信号完整性的参数,例如驱动电流、匹配阻抗、转换速率等,许多问题都能迎刃而解。 
—另外,也可以选用专用逻辑电平转换器件、接口转换器件、可编程逻辑器件来解决数字逻辑标准的接口问题,提高传输的稳定性。例如,IDT、TI公司都推出了多款逻辑电平转换和接口转换器件;Xilinx公司的 CoolRunnerII系列CPLD可以支持LVTTL、LVCOMS、SSTL2-I、HSTL-I等多种接口标准,Spartan-3系列FPGA 支持的标准多达23种。

TTL:Transistor-Transistor Logic 三极管结构。

Vcc:5V
输出 VOL: <0.8V ; VOH:>2.4V。 
输入 VIL:   <1.2V ; VIH: >2.0V 
TTL器件输出低电平要小于0.8V,高电平要大于2.4V。输入,低于1.2V就认为是0,高于2.0就认为是1。

因为2.4V与5V之间还有很大空闲,对改善噪声容限并没什么好处,又会白白增大系统功耗,还会影响速度。所以后来就把一部分“砍”掉了。也就是后面的LVTTL。
LVTTL又分3.3V、2.5V以及更低电压的LVTTL(Low Voltage TTL)。

3.3V LVTTL:
Vcc:3.3V;VOH>=2.4V;VOL<=0.4V;VIH>=2V;VIL<=0.8V。
2.5V LVTTL:
Vcc:2.5V;VOH>=2.0V;VOL<=0.2V;VIH>=1.7V;VIL<=0.7V。

TTL使用注意:TTL电平一般过冲都会比较严重,可能在始端串22欧或33欧电阻;TTL电平输入脚悬空时是内部认为是高电平。要下拉的话应用1k以下电阻下拉。TTL输出不能驱动CMOS输入。

CMOS电平:Complementary Metal Oxide Semiconductor  PMOS+NMOS。

Vcc:5V
输出 VOL: <0.1*Vcc ; VOH:>0.9*Vcc。 
输入 VIL:  <0.3*Vcc ; VIH: >0.7*Vcc.

CMOS电平Vcc可达到12V 
CMOS电路输出高电平约为0.9Vcc,而输出低电平约为 0.1Vcc。

相对TTL有了更大的噪声容限,输入阻抗远大于TTL输入阻抗。对应3.3V LVTTL,出现了LVCMOS,可以与3.3V的LVTTL直接相互驱动。

3.3V LVCMOS:
Vcc:3.3V;VOH>=3.2V;VOL<=0.1V;VIH>=2.0V;VIL<=0.7V。
2.5V LVCMOS:
Vcc:2.5V;VOH>=2V;VOL<=0.1V;VIH>=1.7V;VIL<=0.7V。
CMOS使用注意:CMOS结构内部寄生有可控硅结构,当输入或输入管脚高于VCC一定值(比如一些芯片是0.7V)时,电流足够大的话,可能引起闩锁效应,导致芯片的烧毁。
CMOS电路不使用的输入端不能悬空,会造成逻辑混乱,不用的输入端必须连到高电平或低电平, 这是因为 CMOS 是高输入阻抗器件, 理想状态是没有输入电流的. 如果不用的输入引脚悬空, 很容易感应到干扰信号, 影响芯片的逻辑运行, 甚至静电积累永久性的击穿这个输入端, 造成芯片失效. 
另外,CMOS集成电路电源电压Vcc可以在较大范围内变化,因而对电源的要求不像TTL集成电路那样严格。 
用TTL电平他们就可以兼容。

TTL和CMOS区别:

1.电平的上限和下限定义不一样,CMOS具有更大的抗噪区域。同是5伏供电的话,ttl一般是1.7V和3.5V的样子,CMOS一般是2.2V,2.9V的样子,不准确,仅供参考。

2。电流驱动能力不一样,ttl一般提供25毫安的驱动能力,而CMOS一般在10毫安左右。
3。需要的电流输入大小也不一样,一般ttl需要2.5毫安左右,CMOS 几乎不需要电流输入。 
4。TTL电路是电流控制器件,而coms电路是电压控制器件。 
5。TTL电路的速度快,传输延迟时间短(5-10ns),但是功耗大。COMS电路的速度慢,传输延迟时间长(25-50ns),但功耗低。COMS电路本身的功耗与输入信号的脉冲频率有关,频率越高,芯片集越热,这是正常现象。
COMS电路的锁定效应:
COMS电路由于输入太大的电流,内部的电流急剧增大,除非切断电源,电流一直在增大。这种效应就是锁定效应。当产生锁定效应时,COMS的内部电流能达到40mA以上,很容易烧毁芯片。 
防御措施: 1)在输入端和输出端加钳位电路,使输入和输出不超过不超过规定电压。 
2)芯片的电源输入端加去耦电路,防止VDD端出现瞬间的高压。 
3)在VDD和外电源之间加线流电阻,即使有大的电流也不让它进去。 
4)当系统由几个电源分别供电时,开关要按下列顺序:开启时,先开启COMS电路得电源,再开启输入信号和负载的电源;关闭时,先关闭输入信号和负载的电源,再关闭COMS电路的电源。

COMS电路的使用注意事项 
1)COMS电路时电压控制器件,它的输入总抗很大,对干扰信号的捕捉能力很强。所以,不用的管脚不要悬空,要接上拉电阻或者下拉电阻,给它一个恒定的电平。 
2)输入端接低内组的信号源时,要在输入端和信号源之间要串联限流电阻,使输入的电流限制在1mA之内。 
3)当接长信号传输线时,在COMS电路端接匹配电阻。 
4)当输入端接大电容时,应该在输入端和电容间接保护电阻。电阻值为R=V0/1mA.V0是外界电容上的电压。 
5)COMS的输入电流超过1mA,就有可能烧坏COMS。 
TTL门电路中输入端负载特性(输入端带电阻特殊情况的处理): 
1)悬空时相当于输入端接高电平。因为这时可以看作是输入端接一个无穷大的电阻。 
2)在门电路输入端串联10K电阻后再输入低电平,输入端出呈现的是高电平而不是低电平。因为由TTL门电路的输入端负载特性可知,只有在输入端接的串联电阻小于910欧时,它输入来的低电平信号才能被门电路识别出来,串联电阻再大的话输入端就一直呈现高电平。这个一定要注意。COMS门电路就不用考虑这些了。 
TTL电路有集电极开路OC门,MOS管也有和集电极对应的漏极开路的OD门,它的输出就叫做开漏输出。OC门在截止时有漏电流输出,那就是漏电流,为什么有漏电流呢?那是因为当三机管截止的时候,它的基极电流约等于0,但是并不是真正的为0,经过三极管的集电极的电流也就不是真正的 0,而是约0。而这个就是漏电流。开漏输出:OC门的输出就是开漏输出;OD门的输出也是开漏输出。它可以吸收很大的电流,但是不能向外输出的电流。所以,为了能输入和输出电流,它使用的时候要跟电源和上拉电阻一齐用。OD门一般作为输出缓冲/驱动器、电平转换器以及满足吸收大负载电流的需要。 
TTL集成电路中,输出有接上拉三极管的输出叫做图腾柱输出,没有的叫做OC门。因为TTL就是一个三级关,图腾柱也就是两个三级管推挽相连。所以推挽就是图腾。一般图腾式输出,高电平400UA,低电平8MA

3.3V和5.0V电平信号的转换
在混合电压系统中,不同电源电压的逻辑器件互相接口时存在以下几个问题:

第一,加到输入和输出引脚上允许的最大电压限制问题。器件对加到输入或者输出脚上的电压通常是有限制的。这些引脚有二极管或者分离元件接到Vcc。如果接入的电压过高,则电流将会通过二极管或者分离元件流向电源。例如在3.3V器件的输入端加上5V的信号,则5V电源会向3.3V电源充电。持续的电流将会损坏二极管和其它电路元件。

第二,两个电源间电流的互串问题。在等待或者掉电方式时,3.3V电源降落到0V,大电流将流通到地,这使得总线上的高电压被下拉到地,这些情况将引起数据丢失和元件损坏。必须注意的是:不管在3.3V的工作状态还是在0V的等待状态都不允许电流流向Vcc。

第三,接口输入转换门限问题。5V器件和3.3V器件的接口有很多情况,同样TTL和CMOS间的电平转换也存在着不同情况。驱动器必须满足接收器的输入转换电平,并且要有足够的容限以保证不损坏电路元件。

      基于上述情况,5V器件和3.3V器件是不能直接接口的。有些半导体器件制造厂家就推出了具有5V输入容限的3.3V器件,这种器件输入端具有ESD保护电路。实际上数字电路的所有输入端都有一个ESD保护电路,传统的CMOS电路通过接地二极管对负向高电压限幅,正向高电压则由二极管钳位。这种电路的缺点是最大的输入电压被限制在3.3V+0.5V(二极管压降)以内(否则电流将流向3.3V电源)。而大多数5V系统输出端的电压可达3.6V以上,因此采用了这种电路结构的3.3V器件是不能与5V器件输出端直接接口的。如果采用相当于快速齐纳二极管的MOS场效应管代替上述钳位二极管,实现对高电压限幅,并且去掉接到Vcc(3.3V)的二极管,那么最大输入电压不受Vcc(3.3V)的限制。典型情况下,这种电路的击穿电压在7V~10V之间。因此,这种改进后具有ESD保护电路的3.3V系统的输入端可以承受5V的输入电压。为了防止在3.3V器件的输出端可能存在电流倒灌问题,还需要在输出端加保护电路,当加到输出端电压高于Vcc(3.3V)时,保护电路的比较器会断开电流倒灌通路,这样在三态方式时就能与5V器件相连。
按此在新窗口浏览图片
    分析各种逻辑电平信号的电特性,会发现有以下五种接口情况:
第一,相同供电电压的TTL器件驱动CMOS器件时,TTL器件的输出高电平可能达不到CMOS器件的输入高电平的最小值。3.3V TTL器件的VOH是2.4V,3.3V CMOS器件的VIH是0.8VCC(3.3V×0.8=2.64V);5.0V TTL器件的VOH是2.4V,5.0V CMOS器件的VIH是0.7VCC(3.5V)。为了可靠地传输数据,可以将TTL器件的输出端上拉。有些CMOS工艺制造的器件兼容 TTL电平,这样就可以与相同供电电压的TTL器件直接接口,不需要上拉。

第二,相同供电电压的CMOS器件驱动TTL器件,电平匹配,数据能可靠地传输。

第三,不同供电电压的TTL器件驱动CMOS器件时,TTL器件的输出高电平也可能达不到CMOS器件的输入高电平的最小值。3.3V TTL器件的VOH是2.4V,5.0V CMOS器件的VIH是0.7VCC(3.5V),电平不匹配;5.0V TTL器件的VOH是2.4V,3.3V CMOS器件的VIH是0.8VCC(2.64V),可以将5.0V TTL器件的输出端上拉,达到电平匹配的目的。

第四,不同供电电压的CMOS器件驱动TTL器件时,在输入端具有5V容限的情况下,电平匹配,数据能可靠地传输。

第五,不同供电电压的TTL器件在输入端具有5V容限的情况下可以直接接口;不同供电电压的CMOS器件由于电平不匹配不能直接接口。

      由以上分析可知,不同逻辑标准的电平信号一般是不能直接接口的。在只有少量信号需要电平转换的情况下,可以考虑上拉电阻或选择具有5V输入容限的器件,甚至可以考虑电阻分压降低输入电压的办法。对于大量信号需要电平转换的情况,为了可靠传输数据,可以采用双电压(一边是3.3V,另一边是5V)供电的双向驱动器来实现电平转换。如仙童半导体公司的74LVX4245、TI公司的SN74ALVC164245、SN74ALVC4245
等芯片,可以较好地解决3.3V与5V电平的转换问题。

ECL:Emitter Coupled Logic 发射极耦合逻辑电路(差分结构)
Vcc=0V;Vee:-5.2V;VOH=-0.88V;VOL=-1.72V;VIH=-1.24V;VIL=-1.36V。
速度快,驱动能力强,噪声小,很容易达到几百M的应用。但是功耗大,需要负电源。为简化电源,出现了PECL(ECL结构,改用正电压供电)和LVPECL。
PECL:Pseudo/Positive ECL
Vcc=5V;VOH=4.12V;VOL=3.28V;VIH=3.78V;VIL=3.64V
LVPELC:Low Voltage PECL
Vcc=3.3V;VOH=2.42V;VOL=1.58V;VIH=2.06V;VIL=1.94V
ECL、 PECL、LVPECL使用注意:不同电平不能直接驱动。中间可用交流耦合、电阻网络或专用芯片进行转换。以上三种均为射随输出结构,必须有电阻拉到一个直流偏置电压。(如多用于时钟的LVPECL:直流匹配时用130欧上拉,同时用82欧下拉;交流匹配时用82欧上拉,同时用130欧下拉。但两种方式工作后直流电平都在1.95V左右。)
前面的电平标准摆幅都比较大,为降低电磁辐射,同时提高开关速度又推出LVDS电平标准。
LVDS:Low Voltage Differential Signaling 
差分对输入输出,内部有一个恒流源3.5-4mA,在差分线上改变方向来表示0和1。通过外部的100欧匹配电阻(并在差分线上靠近接收端)转换为±350mV的差分电平。
LVDS使用注意:可以达到600M以上,PCB要求较高,差分线要求严格等长,差最好不超过10mil(0.25mm)。100欧电阻离接收端距离不能超过500mil,最好控制在300mil以内。
下面的电平用的可能不是很多,篇幅关系,只简单做一下介绍。如果感兴趣的话可以联系我。
CML:是内部做好匹配的一种电路,不需再进行匹配。三极管结构,也是差分线,速度能达到3G以上。只能点对点传输。
GTL:类似CMOS的一种结构,输入为比较器结构,比较器一端接参考电平,另一端接输入信号。1.2V电源供电。
Vcc=1.2V;VOH>=1.1V;VOL<=0.4V;VIH>=0.85V;VIL<=0.75V
PGTL/GTL+:
Vcc=1.5V;VOH>=1.4V;VOL<=0.46V;VIH>=1.2V;VIL<=0.8V
HSTL是主要用于QDR存储器的一种电平标准:一般有V&not;CCIO=1.8V和V&not;&not;CCIO= 1.5V。和上面的GTL相似,输入为输入为比较器结构,比较器一端接参考电平(VCCIO/2),另一端接输入信号。对参考电平要求比较高(1%精度)。
SSTL主要用于DDR存储器。和HSTL基本相同。V&not;&not;CCIO=2.5V,输入为输入为比较器结构,比较器一端接参考电平1.25V,另一端接输入信号。对参考电平要求比较高(1%精度)。
HSTL和SSTL大多用在300M以下。
RS232和RS485基本和大家比较熟了,只简单提一下:
RS232采用±12-15V供电,我们电脑后面的串口即为RS232标准。+12V表示0,-12V表示1。可以用MAX3232等专用芯片转换,也可以用两个三极管加一些外围电路进行反相和电压匹配。
RS485是一种差分结构,相对RS232有更高的抗干扰能力。传输距离可以达到上千米

IT技术 , , , , , , , ,

Cadence Allegro PCB Design 16.3破解安装

2012年2月14日
Cadence Allegro PCB Design 16.3破解安装已关闭评论

在高速数字电路设计中,Cadence Allegro无疑是最常用的工具之一,但是如果要买正版,费用不是你我等能够承受得起的。作为个人或者学校学习用,安装一个破解版也是可行的。

一、下载安装包。

从网上搜做关键字“Cadence OrCad v16.3 SHooTERS”找到下载的网站并下载,文件大小为1.7GB左右,比如我是从这里http://www.verycd.com/topics/2795352/下载的,我的带宽是6兆,下载了4个小时,下载后的文件名是:
[PCB设计].Cadence.OrCad.v16.3-SHooTERS.iso

二、破解安装。

主意:安装前先关闭防火墙和杀毒软件

1、安装虚拟光驱工具

把下载的ISO文件刻录到DVD光碟上,如果没有刻录机怎么办,那就从网上下载一个虚拟光驱软件Daemon Tools 3.47.0,比如我是从这里http://www.newhua.com/soft/3617.htm下载这个工具的,下载后的文件名daemon_tools_347cn.zip,双击它解压并安装,安装完后需要重启电脑。然后:

这样就在我的电脑里多了一个名叫Cadence的虚拟光盘。

2、开始安装。

进入我的电脑,双击Cadence光驱(我的虚拟光驱盘符是P)进入,再双击里面的setup.exe启动安装程序:

在上图中点击“License Manager”安装许可证管理工具,每一步都选择默认值即可,直到出现下面的画面:

这是点击取消(Cancel)按钮,然后出现下面的画面:

接下来点击Finish,完成License Manager的安装。

把安装光盘中的目录\SHooTERS\license_manager下的两个文件cdslmd.exe和orcad_163.lic拷贝到 License Manager的安装目录下(默认安装目录是C:\Cadence\LicenseManager)。拷贝时如果提示目标文件名已经存在,直接点击“是” (即覆盖)即可。

用记事本打开刚刚复制到LicenseManager目录中的orcad_163.lic文件,将第一行的“this_host”修改成自己的计算机名称(比如我的计算机名称是moodisk-home):

修改完后保存退出,然后把文件orcad_163.lic改名为license.lic。

主意:如果不知道自己电脑的计算机名称,那么进入命令窗口,输入命令hostname即可查看,如下图所示:

回到Cadence Allegro 安装界面,点击Product Installation,开始安装各种产品:

接下来的安装画面选择默认值即可,直到出现如下的安装画面,直接点击“Next”进入下一步:

本破解方法成功破解了所有的产品,所以到了选择安装什么产品的时候建议安装全部产品:

需要消耗磁盘空间3.47GB。什么?报磁盘空间不够,那我也救不了您了,反正我的电脑有两块500GB的硬盘,做成RAID 1,绰绰有余。

接下来的安装步骤没有什么特别的,一直Next下去,最后点击“Finish”按钮完成安装。

……等等。

下面开始破解了。不过先别急,尽管您在上面的安装结尾点击了“Finsh”,但是实际上安装程序还要花很长的时间在后台做设置,直到安装程序退出了,才可开始破解。

复制安装光盘上的目录\SHooTERS下的文件orcad_163.exe到Cadence Allegro产品的安装根目录下(默认安装根目录是c:\Candence),如果您改变了安装目录,那么久拷贝到那个目录(安装根目录下一定存在子目录SPB_16.3)。拷贝完了双击orcad_163.exe文件运行它:

主意:最后出现的那个黑白窗口会停留数秒钟,如果机器速度慢,可能要几十秒钟,如果一出现马上就消失了,很可能不是您的机器速度太快,而且破解失败!!

完成上一步后,按照下图启动许可证服务器配置程序:

弹出如下画面:

点击“Browse…”按钮定位许可证文件license.lic(位于LicenseManager安装目录下,我们在前面的步骤中已经拷贝到那里,默认目录是C:\Cadence\LicenseManager):

此后一路“Next”,最后点击“Finish”完成破解。

主意:在后续步骤中可能会出现错误:
Unable to start Cadence License Server with the new license file
或者报内存错误,不用理会,我验证了全部的产品都可用。

还有如果您点击HELP中版本信息时,看到的序列号仍然是UNLICENSED,不过不影响任何功能使用。

就这样了,没花钱,能用就不错了! ^_^

附录:

1、配套的学习视频建议看看与博士的(从www.sig007.com下载),不过版本是15.7,与16.3版本在界面上有一定的差别。
2、另外配套软件LPViewer是不可少的,这个工具是免费的,用来查阅ipc 7351国标元件尺寸,从这里http://www.mentor.com/products/pcb-system-design/library- tools/lp-wizard/lp-viewer-download可以下载这个工具。

IT技术 , , ,

纽扣电池型号对照表

2012年2月13日
纽扣电池型号对照表已关闭评论

纽扣电池的型号通常是在纽扣电池的背面由字母和阿拉伯数字组成。瑞士的氧化银纽扣电池型号为3##,日本的型号通常是SR###SW,或 SR###W(#代表一个阿拉伯数字)。纽扣锂电池的型号通常为CR####。不同材料的纽扣电池,其型号规格也就不同。

各地的标准型号列举如下:

香港 国际 瑞士 日本 其他 电压 直径Ф*厚度(mm) 用途
AG0 LR69 379 SR521   1.5V 5.8*2.1  
AG1 LR621 364 SR621 164 1.5V 6.8*2.1  
AG2 LR726 396 SR726 196 1.5V 7.9*2.6  
AG3 LR41 392 SR41 192 1.5V 7.9*3.6 迷你手电、体温计
AG4 LR626 377 SR626 177 1.5V 6.8*2.6  
AG5 LR754 393 SR754 193 1.5V 7.9*5.4  
AG6 LR920 371 SR927 171 1.5V 9.5*2.1  
AG7 LR927 395 SR927 195 1.5V 9.5*2.6  
AG8 LR55 391 SR1120 191 1.5V 11.6*2.1  
AG9 LR936 394 SR936 194 1.5V 9.5*3.6  
AG10 LR54 389 SR1130 189 1.5V 11.6*3.1 计算器
AG11 LR721 362 SR721 162 1.5V 7.9*2.1  
AG12 LR43 386 SR1142 186 1.5V 11.6*4.2 计算器、计步器
AG13 LR44 357 SR1154 A76 1.5V 11.6*5.4 手表、计算机
      CR2032   3V 20*3.2 体重秤、主板
      CR2025   3V 20*2.6 电子词典
      CR2016   3V 20*1.6 手表,计算机、电子记事簿

下面例举两种材料的纽扣电池的型号对照表。

氧化银纽扣电池型号对照表——AG系列

锂-二氧化锰纽扣电池型号对照表——CR系列

IT技术 ,

USB 2.0 A型、B型、Mini和Micro接口定义及封装

2012年2月3日
USB 2.0 A型、B型、Mini和Micro接口定义及封装已关闭评论

USB全称Universal Serial Bus(通用串行总线),目前USB 2.0接口分为四种类型A型、B型、Mini型还有后来补充的Micro型接口,每种接口都分插头和插座两个部分,Micro还有比较特殊的AB兼容型,本文简要介绍这四类插头和插座的实物及结构尺寸图,如果是做设计用途,还需要参考官方最新补充或修正说明,尽管USB 3.0性能非常卓越,但由于USB 3.0规范变化较大,真正应用起来还需假以时日,不管怎样,都已经把火线逼到末路,苹果公司极其郁闷但也爱莫能助。

注意:

1、本文封装尺寸来源,USB 2.0 Specification Engineering Change Notice(Date:10/20/2000)

2、本文图片来源USB官方协议文档,由于USB 3.0在接口和线缆规范上变化较大,后面专门介绍。

3、本文未带插头封装尺寸,插头尺寸请参加官方文档ecn1-usb20-miniB-revd.pdf,下个版本USB 3.0在接口和封装上都有很大变化,本文属于USB 2.0协议内容,如果是USB 3.0设备,似乎只有A型头才能插到2.0插座中Receptacle。

1、A型USB插头(plug)和A型USB插座(receptacle)

引脚顺序(左侧为Plug,右侧为Receptacle):

引脚定义:

编号 定义 颜色识别
1 VBUS Red(红色)
2 D- White(白色)
3 D+ Green(绿色)
4 GND Black(黑色)

封装尺寸(单PIN Receptacle):

2、B型USB插头(plug)和B型USB插座(receptacle)

引脚顺序(左侧为Plug,右侧为Receptacle,注意箭头所指斜口向上,USB端口朝向自己):

引脚定义、封装尺寸均与A型USB引脚说明相同。

封装尺寸(单PIN Receptacle):

3、Mini B型USB插头(plug)和Mini B型USB插座(receptacle)

引脚顺序(左侧为Plug,右侧为Receptacle,注意宽边在上,USB端口朝向自己):

引脚定义:

编号 定义 颜色识别
1 VBUS Red(红色)
2 D- White(白色)
3 D+ Green(绿色)
4 ID Not connected(未连接)
5 GND Black(黑色)

封装尺寸(Receptacle):

以上部分为USB 2.0规范内容,下面的Micro USB实际上是在2006年才发布的补充规范,由于该接口定义无法后向支持USB 3.0协议,故仍然归于USB 2.0协议包。

4、Micro USB插头和插座

Micro USB补充定义用于蜂窝电话和便携设备的Micro USB接口,比Mini USB接口更小。其中标准A型和标准B型及Mini-B型都是在USB 2.0规范里定义,2006补充的Micro USB规范定义了,补充了以下定义:

Micro-B plug and receptacle

Micro-AB receptacle

Micro-A plug

由于该协议文档极不清晰,相关插图也是采用贴图形式,所以不再抓图介绍,只放两个实物照片上来看一下(图片来源:USB MOBILE):

A型与B型的比较如下图:从左往右依次为:miniUSB公口(A型插头)、miniUSB公口(B型插头)、USB公口(B型)、USB母口(A型插座)、USB公口(A型插头)
USB接口

详细了解,请参考官方USB 2.0规范文档,之Micro-USB_1_01.pdf一文,附USB官方网址:http://www.usb.org/

IT技术 , , , , , ,