|
电话远程遥控器,telephone remote controller
关键字：电话遥控,远程遥控,MT8870,89C51,电话遥控电路,远程遥控电路
因为单片机T0所响应的外部中断信号是低电平有效，所以在光耦输出端接了一个开关三极管T1控制指示灯，在三极管的输出端接了三个反向器。经过三极管T1的开关作用和三个反向器的反向作用，输出应该为低电平。但是在测量反向器输出端时发现：振铃指示灯亮，但反向器输出端为高电平。说明振铃信号可以通过三极管，但无法通过反向器。分析原因可能是反向器74LS04坏了，换之，再测，还是老问题。经过细心测量三极管的发射极电压发现：有振铃时Ve=1.1V，这时反向器74LS04认为是低电平，当无振铃脉冲信号时，还是认为是低电平，所以振铃信号无法通过反向器。解决方法很简单，把三极管的发射极端的下拉电阻R4从原来的20kΩ改成5.1kΩ，提升三极管的发射极电压。
在毕业设计的后期，实验室有了模拟小交换机，经测试，本单元电路完全正常，振铃检测部分调试完毕。
5.2.3 模拟摘挂机
此部分的调试较为容易，电路接好后，用5V高电平测试之，指示灯亮，继电器吸合正常。接入模拟小交换机，控制摘机时，交换机的端口指示灯亮，反之挂机时，指示灯灭。说明此部分完全正常。接入仿真机测试时发现：单片机的TXD端不能控制模拟摘挂机部分的摘挂机。分析得出结论：可能是接口的电平不相符合。解决方法：加上一个三极管模拟开关，加上一个反向器（74LS04）进行控制隔离作用。经过接入仿真机测试表明反向器的作用很明显，于是在后面的电路设计当中，我在许多的接口上大多使用了反向器。至此，模拟摘挂机部分调试完毕。
5.2.4 控制电器
控制电器这部分的外围硬件电路很容易，在调试过程中很顺利完成。在接仿真机时，使用的是P2口控制电器，实验结果表明P2口无法正常控制每个电器，翻阅资料发现单片机89C51的P2口没有数据锁存功能，不能保持上一个状态的数据。解决方法：把P2口控制电器改为P1口的低四位控制电器，改线之后控制正常，但是新的问题出现了，原来要求控制八路的端口，现在只能控制四个电器。
经过市场实际分析，一般的控制电器只要求3~4路即可，为了实验单片机扩展控制功能，提高本遥控装置的潜在功能，我决定实验使用3-8线译码器74LS138对P1口的低四位输出数据进行译码扩展。具体电路详见前面。在成功的扩展了控制电器的个数后，我又发现了一个新的问题：遥控器不能同时使两路以及两路以上的电器开，即在同一时刻，遥控器只能使一路电器开启。
经过仔细分析，我发现了问题原因之所在，那就是译码器的原理问题。通常情况下我们认为的译码器可以扩展所能控制的电器，其实译码器只能扩展位数，而不能使状态发生变化。例如：三位二进制000~111可以控制表示三个电器、八种状态，而经过3-8线译码器译码后，可以控制八个电器，但是其状态也只有八种，如下表所示。
A2 A1 A0 输出D0~D7
0 0 0 0 1 1 1 1 1 1 1
0 0 1 1 0 1 1 1 1 1 1
0 1 0 1 1 0 1 1 1 1 1
0 1 1 1 1 1 0 1 1 1 1
1 0 0 1 1 1 1 0 1 1 1
1 0 1 1 1 1 1 1 0 1 1
1 1 0 1 1 1 1 1 1 0 1
1 1 1 1 1 1 1 1 1 1 0
其解决方法是：使用D触发器使继电器保持上一个状态，这样才能使八路电器可以控制28=256个状态。
5.2.5 双音频检测
双音频检测是整体电路一个比较重要的过程，它的调试主要围绕着双音多频解码芯片8870展开的。在此部分的制作的前期，我采用的芯片是CM8870CPI。开始连接电路调试时，整体电路工作很正常，后来这块芯片使用大约一个星期左右的时间，解码电路经常会出现解码出错的情况。经过仔细检查电路，仿真机单步执行进行调试，确认硬件电路无误，诊断为CM8870CPI的问题。根据我的初步分析认定可能是芯片老化的原因，后更换为MT8870DE发现本装置工作很正常，而且换上MT8870DE工作了将近一个月，整体电路没有发生任何解码误码情况，MT8870DE在最后的联机调试过程中也没有出现任何问题。
5.3 软件程序调试
5.3.1软件系统设置
对于本系统而言，软件程序所实现的功能比较多，所以软件程序的调试显得相当的烦琐。整个程序是使用汇编语言，在MBUG下编写调试完成的。
首先我使用的是我自己的计算机联接MCS-51仿真机，计算机的主频为333MHz，但是出现了许多的问题。第一个问题就是：我所使用的MCS-51仿真机型号是ME-5103，联入计算机的25针串行口来进行程序的读入，但是我的计算机没有25针串行口。观察计算机的后面，主板上只有一个25针并行口，是用来连接打印机的；除了这个25针串行口外，还有两个9针串行口。
我只有把MCS-51仿真机的25针接口变成9针串行接口，才能连接计算机。后来我找到一个25针-9针的转换口，可以通过他使MCS-51仿真机和我的计算机联接。
我使用的是Manley In-Circuit Emulator Debugger(MBUG)开发软件，使用时发现此系统可以进行正常的Assemble（汇编），但是不能正常的进行Load Program，执行时会出现divide overflow error的错误，然后就退出此编译系统，这就使得无法进行仿真机模拟实验。
经过实验室多组同学的八台计算机的尝试，我们终于发现了问题之所在。实验结果表明：主频高于233MHz的计算机都不能正常联接MCS-51仿真机，而主频低于100MHz的计算机（有25针串行接口）均可以进行仿真实验。后来经过查阅有关技术资料，型号为ME-5103的MCS-51仿真机只能工作在IBM PC/XT/AT 286/386/486的环境下。
由于实验室的低档计算机（能联接MCS-51仿真机）的不太多，所以我们只有把仅有的几台计算机进行优化重组，以便合理利用有限的计算机资源。我的汇编语言程序相对来说还是比较多的，调试起来可能费时，所以我先在自己的计算机上对程序的语法错误（syntax error）进行调试修改，然后又对地址覆盖（org address is less）的错误进行修改，既对每个子程序的开始地址进行仔细的调整。到此为止整个软件程序调试环境就已经配好了。
5.3.2提示音信号
在本单元的调试过程中，我认为此部分的结构比较简单，因此在整体程序中直接调试。首先Ctrl+F5单步执行，发现此部分的RING1子程序正常，而其它的子程序在执行时却发生死循环。我把这几个子程序单独切出来进行分析，却发现执行正常，于是我推测并不是子程序本身的结构问题。然后使用Ctrl+F8对整个程序单步执行（两种单步执行的区别在于F5直接执行子程序，即不单步执行子程序，而F8对于整个程序都是单步执行，包括子程序），发现RING2中的R5寄存器已经在主程序中用作判断标志位，程序已经在外部完成对其赋值。这样就导致重复赋值，因此无法跳出循环子程序，直接导致死循环。
程序代码：
ORG 1150H
RING20:MOV R3，#03
RING21:MOV R6，#20 ;password wrong
RING22:MOV R5，#20 ;1600Hz
RING23:LCALL DL20 ;sound=3
CPL P3.0 ;delay=0.25s
DJNZ R5，RING23
DJNZ R6，RING22
CLR P3.0
MOV R5，#200
RING24:LCALL DL10
DJNZ R5，RING24
DJNZ R3，RING21
CLR P3.0
RET
后来我将子程序中的R5寄存器换成R7寄存器，子程序就正常了。
5.3.3密码检测
本部分的调试比较艰难，我是先调试一位密码，然后再调试五位密码。我先设定R5为一位，即先设定一位密码作为测试。首先单步执行，发现信号音无法正常输入到单片机的38H地址处的存储空间。现象：计算机联机单步执行，接收振铃信号，三次自动摘机，当程序执行到等待INT0中断（一个小的循环程序）时，既等待输入密码时，我按下“7”（事先设定的一位密码），单片机能够正常的响应中断信号，跳出循环程序，执行中断处理程序，单片机在比较比较密码时，总是出错。
在程序单步执行时，我仔细观察了每个寄存器和存储器的内容。地址为38H的存储空间内容始终为FFH，并没有变化，而且无论输入什么密码，寄存器A的内容总是恒定不变的。因为地址为38H的存储空间内放的是用户输入的密码，累加器A放的是@30H减去@38H的值，即输入密码正确时应该为0，所以我认为单片机并没有把数据写入地址为38H的存储空间。
经过反复调试我也没有发现问题之所在，于是我抱着尝试的想法用F9全部执行一次。结果很惊人，程序居然能通过密码检测部分。我仔细的思考了单步执行的每一个状态，终于发现了失败的原因。
程序单步执行到等待INT0中断，即要求输入密码时，按下电话机的一个按键，程序就跳出循环程序，跳到中断处理程序处处理双音频信号的输入。因为单步执行是一步一步的执行，其执行速度比较慢，等到把单片机的P1口高四位的双音频解码信号写入地址为38H的存储空间时，信号早已过去，P1口高四位也恢复高电平，写入P1口高四位的数据当然是FFH。而F9全程执行速度非常快，不是外部信号等待单片机的处理，而是单片机等待外部信号的输入，当然不会漏掉数据。
原因找到了，解决方法也很简单：在程序单步执行时，到了等待INT0中断时，我按下“7”键的时间特别长，直到看见程序执行到写入地址为38H的存储空间后才松手。这样数据就能正确写入寄存器，当然能够通过密码检测。
|
