MSComm控件在串口编程中使用

(出處: http://www.samool.com/delphibbs/379/3797202.htm)

目 次
MSComm控件两种处理通讯的方式
CommPort属性
RThreshold 属性
CTSHolding 属性
SThreshold 属性
CDHolding 属性
DSRHolding 属性
Settings 属性
InputLen 属性
EOFEnable 属性

Handshake 常数
OnComm 常数
InputMode 常数
错误消息


MSComm 控件通过串行端口传输和接收数据，为应用程序提供串行通讯功能。MSComm控件在串口编程时非常方便，程序员不必去花时间去了解较为复杂的API函数，而且在VC、VB、Delphi等语言中均可使用。 Microsoft Communications Control（以下简称MSComm）是 Microsoft公司提供的简化Windows下串行通信编程的ActiveX控件，它为应用程序提供了通过串行接口收发数据的简便方法。具体的来说，它提供了两种处理通信问题的方法：一是事件驱动(Event－driven)方法，一是查询法。

1.MSComm控件两种处理通讯的方式

MSComm控件提供下列两种处理通讯的方式：事件驱动方式和查询方式。
1.1 事件驱动方式

事件驱动通讯是处理串行端口交互作用的一种非常有效的方法。在许多情况下，在事件发生时需要得到通知，例如，在串口接收缓冲区中有字符，或者 Carrier Detect (CD) 或 Request To Send (RTS) 线上一个字符到达或一个变化发生时。在这些情况下，可以利用 MSComm 控件的 OnComm 事件捕获并处理这些通讯事件。OnComm 事件还可以检查和处理通讯错误。所有通讯事件和通讯错误的列表，参阅 CommEvent 属性。在编程过程中，就可以在OnComm事件处理函数中加入自己的处理代码。这种方法的优点是程序响应及时，可靠性高。每个 MSComm 控件对应着一个串行端口。如果应用程序需要访问多个串行端口，必须使用多个 MSComm 控件。

1.2 查询方式

查询方式实质上还是事件驱动，但在有些情况下，这种方式显得更为便捷。在程序的每个关键功能之后，可以通过检查 CommEvent 属性的值来查询事件和错误。如果应用程序较小，并且是自保持的，这种方法可能是更可取的。例如，如果写一个简单的电话拨号程序，则没有必要对每接收一个字符都产生事件，因为唯一等待接收的字符是调制解调器的“确定”响应。

2.MSComm 控件的常用属性
MSComm 控件有很多重要的属性，但首先必须熟悉几个属性。
CommPort 设置并返回通讯端口号。
Settings 以字符串的形式设置并返回波特率、奇偶校验、数据位、停止位。
PortOpen 设置并返回通讯端口的状态。也可以打开和关闭端口。
Input 从接收缓冲区返回和删除字符。
Output 向传输缓冲区写一个字符串。

下面分别描述：

CommPort属性 设置并返回通讯端口号。
语法 object.CommPort[value ] (value 一整型值，说明端口号。)
说明 在设计时，value 可以设置成从 1 到 16 的任何数（缺省值为 1）。但是如果用 PortOpen 属性打开一个并不存在的端口时，MSComm 控件会产生错误 68（设备无效）。
注意：必须在打开端口之前设置 CommPort 属性。

RThreshold 属性：在 MSComm 控件设置 CommEvent 属性为 comEvReceive 并产生 OnComm 之前，设置并返回的要接收的字符数。
语法 object.Rthreshold [ = value ]（value 整型表达式，说明在产生 OnComm 事件之前要接收的字符数。 ）
说明 当接收字符后，若 Rthreshold 属性设置为 0（缺省值）则不产生 OnComm 事件。例如，设置 Rthreshold 为 1，接收缓冲区收到每一个字符都会使 MSComm 控件产生 OnComm 事件。

CTSHolding 属性：确定是否可通过查询 Clear To Send (CTS) 线的状态发送数据。Clear To Send 是调制解调器发送到相联计算机的信号，指示传输可以进行。该属性在设计时无效，在运行时为只读。
语法： object.CTSHolding（Boolean）

Mscomm 控件的 CTSHolding 属性设置值：
True Clear To Send 线为高电平。
False Clear To Send 线为低电平。

说明：如果 Clear To Send 线为低电平 (CTSHolding = False) 并且超时时，MSComm 控件设置 CommEvent 属性为 comEventCTSTO (Clear To Send Timeout) 并产生 OnComm 事件。

Clear To Send 线用于 RTS/CTS (Request To Send/Clear To Send) 硬件握手。如果需要确定 Clear To Send 线的状态，CTSHolding 属性给出一种手工查询的方法。

详细信息 有关握手协议，请参阅 Handshaking 属性。

SThreshold 属性： MSComm 控件设置 CommEvent 属性为 comEvSend 并产生 OnComm 事件之前，设置并返回传输缓冲区中允许的最小字符数。

语法 object.SThreshold [ = value ]
value 整形表达式，代表在 OnComm 事件产生之前在传输缓冲区中的最小字符数。

说明：若设置 Sthreshold 属性为 0（缺省值），数据传输事件不会产生 OnComm 事件。若设置 Sthreshold 属性为 1，当传输缓冲区完全空时，MSComm 控件产生 OnComm 事件。如果在传输缓冲区中的字符数小于 value，CommEvent 属性设置为 comEvSend，并产生 OnComm 事件。comEvSend 事件仅当字符数与 Sthreshold 交叉时被激活一次。例如，如果 Sthreshold 等于 5，仅当在输出队列中字符数从 5 降到 4 时，comEvSend 才发生。如果在输出队列中从没有比 Sthreshold 多的字符，comEvSend 事件将绝不会发生。


Handshake 常数

常数 值 描述
comNone 0 无握手。
comXonXoff 1 XOn/Xoff 握手。
comRTS 2 Request-to-send/clear-to-send 握手。
comRTSXOnXOff 3 Request-to-send 和 clear-to-send 握手皆可。


OnComm 常数

常数 值 描述
comEvSend 1 发送事件。
comEvReceive 2 接收事件。
comEvCTS 3 clear-to-send 线变化。
comEvDSR 4 data-set ready 线变化。
comEvCD 5 carrier detect 线变化。
comEvRing 6 振铃检测。
comEvEOF 7 文件结束。


Error 常数

常数 值 描述
comEventBreak 1001 接收到中断信号
comEventCTSTO 1002 Clear-to-send 超时
comEventDSRTO 1003 Data-set ready 超时
comEventFrame 1004 帧错误
comEventOverrun 1006 端口超速
comEventCDTO 1007 Carrier detect 超时
comEventRxOver 1008 接收缓冲区溢出
comEventRxParity 1009 Parity 错误
comEventTxFull 1010 传输缓冲区满
comEventDCB 1011 检索端口 设备控制块 (DCB) 时的意外错误

InputMode 常数
常数 值 描述
comInputModeText 0 （缺省）通过 Input 属性以文本方式取回数据。
comInputModeBinary 1 通过 Input 属性以二进制方式检取回数据。





CDHolding 属性：通过查询 Carrier Detect (CD) 线的状态确定当前是否有传输。Carrier Detect 是从调制解调器发送到相联计算机的一个信号，指示调制解调器正在联机。该属性在设计时无效，在运行时为只读。

语法 object.CDHolding
设置值：CDHolding 属性的设置值为：
设置 描述
True Carrier Detect 线为高电平
False Carrier Detect 线为低电平
说明：注意当 Carrier Detect 线为高电平 (CDHolding = True) 且超时时，MSComm 控件设置CommEvent 属性为 comEventCDTO（Carrier Detect 超时错误），并产生 OnComm 事件。
注意 在主机应用程序中捕获一个丢失的传输是特别重要的，例如一个公告板，因为呼叫者可以随时挂起（放弃传输）。
Carrier Detect 也被称为 Receive Line Signal Detect (RLSD)。
数据类型 Boolean

DSRHolding 属性：确定 Data Set Ready (DSR) 线的状态。Data Set Ready 信号由调制解调器发送到相连计算机，指示作好操作准备。该属性在设计时无效，在运行时为只读。
语法：object.DSRHolding
object 所在处表示对象表达式，其值是“应用于”列表中的对象。
DSRHolding 属性返回以下值：
值 描述
True Data Set Ready 线高
False Data Set Ready 线低
说明：当 Data Set Ready 线为高电平 (DSRHolding = True) 且超时时，MSComm 控件设置 CommEvent 属性为 comEventDSRTO（数据准备超时）并产生 OnComm 事件。
当为 Data Terminal Equipment (DTE) 机器写 Data Set Ready/Data Terminal Ready 握手例程时该属性是十分有用的。
数据类型：Boolean


Settings 属性: 设置并返回波特率、奇偶校验、数据位、停止位参数。

语法: object.Settings[ = value]
说明：当端口打开时，如果 value 非法，则 MSComm 控件产生错误 380（非法属性值）。
Value 由四个设置值组成，有如下的格式：
"BBBB,P,D,S"
BBBB 为波特率，P 为奇偶校验，D 为数据位数，S 为停止位数。value 的缺省值是：
"9600,N,8,1"


InputLen 属性：设置并返回 Input 属性从接收缓冲区读取的字符数。

语法 object.InputLen [ = value]
InputLen 属性语法包括下列部分：
value 整型表达式，说明 Input 属性从接收缓冲区中读取的字符数。
说明：InputLen 属性的缺省值是 0。设置 InputLen 为 0 时，使用 Input 将使 MSComm 控件读取接收缓冲区中全部的内容。

若接收缓冲区中 InputLen 字符无效，Input 属性返回一个零长度字符串 ("")。在使用 Input 前，用户可以选择检查 InBufferCount 属性来确定缓冲区中是否已有需要数目的字符。该属性在从输出格式为定长数据的机器读取数据时非常有用。


EOFEnable 属性：确定在输入过程中 MSComm 控件是否寻找文件结尾 (EOF) 字符。如果找到 EOF 字符，将停止输入并激活 OnComm 事件，此时 CommEvent 属性设置为 comEvEOF，
语法：object.EOFEnable [ = value ]
EOFEnable 属性语法包括下列部分：
value 布尔表达式，确定当找到 EOF 字符时，OnComm 事件是否被激活，如“设置值”中所描述。
value 的设置值：
True 当 EOF 字符找到时 OnComm 事件被激活。
False （缺省）当 EOF 字符找到时 OnComm 事件不被激活。
说明：当 EOFEnable 属性设置为 False，OnComm 控件将不在输入流中寻找 EOF 字符。


错误消息（MS Comm 控件）


下表列出 MSComm 控件可以捕获的错误：

值 描述
380 无效属性值 comInvalidPropertyValue
383 属性为只读 comSetNotSupported
394 属性为只读 comGetNotSupported
8000 端口打开时操作不合法 comPortOpen
8001 超时值必须大于 0
8002 无效端口号 comPortInvalid
8003 属性只在运行时有效
8004 属性在运行时为只读
8005 端口已经打开 comPortAlreadyOpen
8006 设备标识符无效或不支持该标识符
8007 不支持设备的波特率
8008 指定的字节大小无效
8009 缺省参数错误
8010 硬件不可用（被其它设备锁定）
8011 函数不能分配队列
8012 设备没有打开 comNoOpen
8013 设备已经打开
8014 不能使用 comm 通知
8015 不能设置 comm 状态 comSetCommStateFailed
8016 不能设置 comm 事件屏蔽
8018 仅当端口打开时操作才有效 comPortNotOpen
8019 设备忙
8020 读 comm 设备错误 comReadError
8021 为该端口检索设备控制块时的内部错误 comDCBError

[串列埠通信]MSComm控件的主要属性及事件

(出處: http://www.samool.com/delphibbs/379/3797202.htm)
MSComm控件的主要属性及事件
（1）CommPort：设置或返回串行端口号，缺省值1。
（2）Setting：设置或返回串口通信参数，格式为“波特率，奇偶校验位，数据位，
停止位”。例如：MSComm1.Setting:=′9600,n,8,1′
（3）PortOpen：打开或关闭串行端口，格式为：MSComm1.PortOpen:={True|False}
（4）InBufferSize：设置或返回接收缓冲区的大小，缺省值为1024字节。
（5）InBufferCount：返回接收缓冲区内等待读取的字节数，可通过设置该属性为0来
清空接收缓冲区。
（6）RThreshold：该属性为一阀值，它确定当接收缓冲区内的字节个数达到或超过该
值后就产生代码为ComEvReceive的OnComm事件。
（7）SThreshold：该属性为一阀值，它确定当发送缓冲区内的字节个数少于该值后就
产生代码为ComEvSend的OnComm事件。
（8）InputLen：设置或返回接收缓冲区内用Input读入的字节数，设置该属性为0表示
Input读取整个缓冲区的内容。
（9）Input：从接收缓冲区读取一串字符。
（10）OutBufferSize：设置或返回发送缓冲区的大小，缺省值为512字节。
（11）OutBufferCount：返回发送缓冲区内等待发送的字节数，可通过设置该属性为0
来清空缓冲区。
（12）OutPut：向发送缓冲区传送一串字符。
如果在通信过程中发生错误或事件，就会触发OnComm事件，并由CommEvent属性代码反映错误类型，在通信程序的设计中可根据该属性值来执行不同的操作。CommEvent属性值及其含义如下：
（1）ComEvSend：值为1，发送缓冲区的内容少于SThreshold指定的值。
（2）ComEvReceive：值为2，接收缓冲区内字符数达到RThreshold指定的值。
（3）ComEvFrame：值为1004，硬件检测到帧错误。
（4）ComEvRxOver：值为1008，接收缓冲区溢出。
（5）ComEvTxFull：值为1010，发送缓冲区溢出。
（6）ComEvRxParity：值为1009，奇偶校验错误。
（7）ComEvEOF：值为7，接收数据中出现文件尾（ASCII码为26）字符。

Using AT commands to Send and Receive SMS

Tutorial :: Using AT commands to Send and Receive SMS
http://www.control.com.sg/at_commands_sms.aspx#Receiving%20SMS%20using%20using%20AT%20commands


SMS source samples (for GSM phones)
http://www.scampers.org/steve/sms/samples.htm


AT commands for GSM (GB2312)
http://www.cnblogs.com/goodloop/archive/2006/03/03/342282.html

How to convert .wav files to .gsm for Asterisk use

[Target]
Convert a .wav file(VIO voice greeting-VP1.wav) to .gsm

[Enviornment]
Ubuntu 7.10
Sound files of Asterisk is put under /var/lib/asterisk/sounds

[Steps]
1. Copy VP1.wav onto Desktop

2. Install sox : ae@Asterisk-PBX:/$sudo apt-get install sox

3. convert file to gsm format :
If your WAV file was in stereo, add the -c1(c one) option to convert to mono, or the output will sound very strange
ae@Asterisk-PBX:/$sox VP1.wav -r 8000 -c1 VP1.gsm resample -ql

4. put the .gsm file into Asterisk sounds folder :
ae@Asterisk-PBX:/$sudo cp VP1.gsm /var/lib/asterisk/sounds/

5. modify extensions.conf to use the new voice prompt

[reference]
http://www.voip-info.org/wiki/view/Convert+WAV+audio+files+for+use+in+Asterisk

How to Build Live Update Server for Test

如何建立apt-server

1）先switch 到root權限

打開terminal 視窗

ae@ae-desktop2:~$sudo su

會要求輸入密碼，之後字尾會從”$”變成”#”

2）以ubuntuOS為例，首先需安裝apache2，命令如下：

root@ae-desktop2:/home/ae#apt-get install dpkg-dev apache2

3）建立APT目錄：

root@ae-desktop2:/home/ae#mkdir -p /var/www/lexis30/ippbx

4）Copy將被升級的packages到指定目錄：

LiveUpdate 昇級需要的packages，以使用1.0.11.8為例，將lexis30-1.0.11.8-20080709.tar.bz2 copy到update server並解開，可得到setup-file的目錄，在裡面找到"atompbx-skype-smp-configs_1.0.11.8_i686.deb", "atompbx-skype-smp-modules_1.0.11.8_i686.deb", "atompbx-skype-smp-zap-sky_1.0.11.8_i686.deb"，在misc目錄裡可找到"atompbx-skype-smp-jdk_1.0.11.8_i686.deb", "atompbx-skype-smp-tomcat_1.0.11.8_i686.deb"

共5個deb packages

root@ae-desktop2:/home/ae#cp your.deb /var/www/lexis30/ippbx

5）建立packages的連結

root@ae-desktop2:/home/ae#cd /var/www/lexis30

root@ae-desktop2:/var/www/lexis30#dpkg-scanpackages ippbx /dev/null | gzip -9c > Packages.gz

會產生一個叫Packages.gz的檔案，因為測試使用，所以需要手動去改變version號，在VIT1/E1上才會抓取並顯示可以更新.

6）手動更新版本號

• 使用ubuntu 6.06時，打以下指令

root@ae-desktop2:/var/www/lexis30#vim Packages.gz

修改裡面的Version: 1.0.11.8，改成1.0.11.99，共有5個地方要修改

• 使用ubuntu 7.10時，打以下指令

root@ae-desktop2:/var/www/lexis30#gzip –d Packages.gz

會解出一個Packages的檔

root@ae-desktop2:/var/www/lexis30#vim Packages

修改裡面的Version: 1.0.11.8，改成1.0.11.99，共有5個地方要修改

修改完後再輸入以下指令

root@ae-desktop2:/var/www/lexis30#gzip -9c Packages > Packages.gz

注意：上一步產生Packages.gz時，如果是使用Ubuntu 7.10，則檔案中會有一行"Depends: "，這行需要刪除，否則會有問題

Normal 0 0 2 false false false MicrosoftInternetExplorer4

client端如何更新

以ubuntu為列，修改如下檔：

/etc/apt/source.list 修改為：

deb http://apt-server IP/lexis30 /

架設好server，修改好Client端後，每隔一定時間，ubuntu系統會自動以/etc/apt/source.list檔裏的內容為目標，做查詢操作，如果server伺服器上的包版本要高於Client，則提示是否要進行下載更新，提示現象為，在ubuntu系統的右上角，有個標誌會亮起。LiveUpdate分為2步操作，第一步為查詢有沒高版本的deb包，第二步才是下載並更新操作。

RFC2833 DTMF packets

The observed behavior is that the Asterisk unit sends six RTP Event packets for each digit press. The first three packets are typical "start of event" packets. The first of these three has the SDP marker set to True (per RFC 2833). The other two have this marker set to False which is typical. All three of these "start" packets have the event duration set to zero. This is also typical. Basically, these three packets serve as a preamble telling the terminating gateway that a DTMF event is coming. See frames 3633-3635 of the attached capture for an example.

The last three packets of the six are all identical "end of event" packets. Each has the end-of-event bit set which is a different flag than the marker bit used in the first start packet. Each of these "end" packets also provide the total duration of the tone event. The Asterisk behavior observed is the total event duration is always 800 clocks ticks. Clock ticks are in reference to an 8kHz clock. So, 8 clock ticks represent 1 millisecond. And, 800 clock ticks would indicate a 100 ms tone duration. See frames 3636-3638 for examples.

The above behavior seems to indicate that when an Asterisk detects a digit press it calls a routine that always generates the above six packets (three start, three end, volume always 10, and tone duration always 100 ms). Other originating devices (i.e. Cisco) will actually sample the digit press for volume and duration and send event "update" packets (my terminology) between the start and end packets. These update packets increase the event duration throughout the length of the digit press. The samples are usually sent at an interval equivalent to the ptime of the codec (i.e. 20 ms for G.711). However, there's nothing inherently wrong with the 6-packet method used by Asterisk. And, I believe it would be considered to conform to RFC 2833. There is however another problem with the way Asterisk delivers these six packets that's at the heart of the double digit problem.

Let's look at two digit press examples from the capture. One that was interpreted correctly (digit press of a "1") and another that experienced a triple bounce (digit press of a "2").

Frames 3633 through 3638 represent one digit press event of the number "1". This digit played out correctly. Note the sequence numbers of these three frames show they arrived in sequence.

Frame 3633 - seq 56430 - start marker true - end of event false - event duration 0
Frame 3634 - seq 56431 - start marker false - end of event false - event duration 0
Frame 3635 - seq 56432 - start marker false - end of event false - event duration 0
Frame 3636 - seq 56433 - start marker false - end of event true - event duration 800
Frame 3637 - seq 56433 - start marker false - end of event true - event duration 800
Frame 3638 - seq 56433 - start marker false - end of event true - event duration 800

Now look at frames 3741 through 3746 for a single press of the number "2". Note how the frames arrive out of sequence.

Frame 3741 - seq 56485 - start marker true - end of event false - event duration 0
Frame 3742 - seq 56488 - start marker false - end of event true - event duration 800
Frame 3743 - seq 56488 - start marker false - end of event true - event duration 800
Frame 3744 - seq 56486 - start marker false - end of event false - event duration 0
Frame 3745 - seq 56488 - start marker false - end of event true - event duration 800
Frame 3746 - seq 56487 - start marker false - end of event false - event duration 0

The above plays out as a triple press. The first three frames are played out as one tone. The fourth and fifth frames play out a second tone. And the sixth frame starts a third tone. Packets arriving out of sequence like this are the cause of the double and triple digits heard by IVRs on the terminating side.
Examination of the time delta between each of the above frames indicates the Asterisk is sending the 6 packets that represent an RTP event as a single burst. The time differential between the packets is extremely small. It is often sub-10 micro-seconds (that's micro, not milli). Given the nature of latency on the public Internet it's easy to see why packets sent so close together may arrive out of sequence at the other end.

I suggest that you find the Asterisk routine responsible for generating the 6-packet RTP event and insert some "sleep" time between each of the six packets to space them out better. Or perhaps, insert just one sleep cycle between the three "start" packets and the three "end" packets. I think the latter is a better suggestion. I believe a 20 ms sleep cycle (the typical ptime for G.711 and G.729) between the three start packets and the three end packets should be enough to compensate for IP jitter in transport. However, you can experiment with different values to see what makes DTMF transport most reliable."

VISIP DTMF debug

1. Click here to download

2. Back up
chan_sip.so
usr/lib/asterisk/modules/

3. Replace new
chan_sip.so
usr/lib/asterisk/modules/

4. Restart now

5. More debug message at:
/var/log/asterisk/messages

6. Replace back with old chan.sip.so after the test
Click here to download

screen resolution problem in ubuntu 6.06

1. Ctrl &Alt&F1

2. sudo dpkg-reconfigure xserver-xorg

3. In case it doesn't work:
sudo lspci grep -i vga
grep -i driver /etc/X11/xorg.conf