作者:佚名 来源:不详
质量是关键。没有人会对很差的工作感到满足。当完成高质量的工作时,你会为此而感到骄傲。不管你是否知道,你都会因为你的高质量工作而得到信誉。因此,要想为自己所做的事感到骄傲,就需要建立个人标准,并为达到这一标准而努力奋斗。在达到这些标准时,再提高标准并继续努力。挑战自己去完成更优良的工作,你将会为自己的成就而感到惊讶。
1.1 了解单片机的能力
【规则1】设计满足要求的最精简的系统。
正确估计单片机的能力,知道单片机能做什么,最大程度的挖掘单片机的潜力对一个单片机系统设计者来说是至关重要的。我们应该有这样一个认识,即单片机的处理能力是非常强大的。早期的PC机,其CPU(8086)处理能力和8051
相当,却能处理相当复杂的任务。单片机的能力的关键就在软件设计者编写的软件上。只有充分地了解到单片机的能力,才不会做出冗余的系统设计。而采用许多的外围芯片来实现单片机能实现的功能。这样做,即增加了系统成本,也可能会降低了系统的可靠性。
1.2 系统可靠性至关重要
【规则2】使用看门狗。
看门狗电路通常是一块在有规律的时间间隔中进行更新的硬件。更新一般由单片机来完成,如果在一定间隔内没能更新看门狗,那看门狗将产生复位信号,重新复位单片机。更新看门狗的具体形式多是给看门狗芯片相关引脚提供一个电平上升沿或读写它的某个寄存器。使用看门狗电路将在单片机发生故障进行死机状态时,重新复位单片机。当前有多种看门狗的芯片,如MAXIM
公司的MAX802,MAX813
等。而且,有好多种单片机中本身就集成有看门狗。一个外部的看门狗是最好的,因为它不依赖于单片机。如果可能的话,看门狗更新程序不应该放在中断或是子程序中,原则上应该放在主程序中。我曾经见过一个工程师,他所调试的程序在运行时偶而会引起看门狗的复位动作,于是他干脆在每10ms
就中断一次的时钟中断程序中清看门狗。我相信他也知道使看门狗失去作用,可他却没有不是去查明引起这个现象的真正原因。因此,我想提醒大家:不论什么理由,绝对不要忽略系统故障的真正原因。高质量的产品来自于高素质的工程师,高质量的产品造就高素质的工程师。
【规则3】确定系统的复位信号可靠。
这是一个很容易忽略的问题。当你在设计单片机系统时,你脑中有这个概念吗?什么样的复位信号才是可靠的吗?你用示波器查看过你设计的产品的复位信号吗?不稳定的复位信号可能会产生什么样的后果?你有没有发现过你所设计的单片机系统,每次重新上电启动后,数据变得乱七八糟,并且每一次现象并不相同,找不出规律,或者有时候干脆不运行,或者有时候进入一种死机状态,有时候又一点事都没有正常运行?在这种情况下,你应该查一下你的系统的复位信号。一般在单片机的数据手册(Datasheet)中都会提到该单片机需要的复位信号的要求。一般复位信号的宽度应为。复位电平的宽度和幅度都应满足芯片的要求,并且要求保持稳定。还有特别重要的一点就是复位电平应与电源上电在同一时刻发生,即芯片一上电,复位信号就已产生。不然,由于没有经过复位,单片机中的寄存器的值为随机值,上电时就会按PC
寄存器中的随机内容开始运行程序,这样很容易进行误操作或进入死机状态。
【规则4】确定系统的初始化有效。
系统程序开始应延时一段时间。这是很多单片机程序设计中的常用方法,为什么呢?因为系统中的芯片以及器件从上电开始到正常工作的状态往往有一段时间,程序开始时延时一段时间,是让系统中所有器件到达正常工作状态。究竟延时多少才算合适?这取决于系统的各芯片中到达正常工作状态的时间,通常以最慢的为准。一般来说,延时20-100毫秒已经足够。对于系统中使用嵌入式MODEM
等慢热型的器件来说,则应更长。当然,这都需要在系统实际运行中进行调整。
【规则5】上电时对系统进行检测。
上电时对系统中进行检测是单片机程序中的一个良好设计。在硬件设计时也应该细细考虑将各个使用到的芯片、接口设计成容易使用软件进行测试的模式。很多有经验的单片机设计者都会在系统上电时(特别是第一次上电时)进行全面的检测,或者更进一步,将系统的运行状态中分为测试模式和正常运行模式,通过加入测试模式对系统进行详细的检测,使得系统的批量检测更为方便容易。另外要注意的是,一个简单明了的故障显示界面也是颇要费得心思的。比如:系统的外部RAM(数据存储器)是单片机系统中常用的器件。外部RAM
如果存在问题,程序通常都会成为一匹脱缰的野马。因此,程序在启动时(至少在第一次上电启动时)一定要对外部RAM
进行检测。检测内容包括:1)检测RAM 中的单元。这主要通过写入和读出的数据保持一致。2)检测单片机与RAM
之间的地址数据总线。总线即没有互相短路,也没有连接到地上。另外,很多芯片,都提供了测试的方法。如串行通信芯片UART,都带环路测试的功能。
【规则6】按EMC 测试要求设计硬件。
EMC 测试要求已经成为产品的必需。有很多的文章关于这方面的。
1.3 软件编程和调试
【规则7】尽可能使用Small 模式编译
对比起Large模式和Compact 模式,Small 模式能生成更为紧凑的代码。在Small 模式下,C51
编译器将没有使用关键词,如idata、pdata、xdata特殊声明的变量通通放在data单元中。在编程中,对于在的数据区,可以指定放在外部存储器中。
【规则8】在仿真前做好充分的准备
单片机硬件仿真器给单片机开发者带来了极大的方便,同时也很容易造成人的依赖性。很多时候,没有仿真器却能促使工程师写出更高质量的程序。也许在硬件仿真调试之前,下面准备工作将会对你有用:
1)程序编完后,对代码仔细逐行检查。检查代码的错误,建立自己的代码检查表,对经常易错的地方进行检查。检查代码是否符合编程规范。
2)对各个子程序进行测试。测试的方法:用程序测试程序,编制一个调用该子程序的代码,建立要测试子程序的入口条件,再看看它是否按预期输出结果。
3)如果代码有修改,再次对代码进行检查。
4)有可能的话,进行软件仿真——Keil C
的软件仿真功能十分强大。软件仿真可以防止因硬件的错误,如器件损坏、线路断路或短路,而引起调试的错误。
5)开始硬件仿真。
【规则9】使用库函数
重用代码,尤其是是标准库的代码,而不是手工编写你自己的代码。这样更快、更容易也更安全。KeilC
中提供了多个库函数,这些库函数的用法在KeilC 的帮助文件中有详细的描述。
【规则10】使用const。
这一点在很多经典的关于C
和C++的书籍中是必谈的要点。在《Exceptional C++》一书中,对这点有很精彩的描述,现摘录如下:没有正确的安全意识的枪手在世界上是不可能活的很长的。const
观念不正确的程序员也是一样和没有时间戴紧帽子的正确,没有时间检查带电电线的电工一样不会活的很长。
在C 语言中,const
修饰符表示告诉编译器此函数将不会改变被修饰的变量的指向的任何值(除了强制类型转换)。当把指针作为参数传递时,总是合适地使用const,不仅可以防止你无意中错误的赋值,而且还可以防止在作为参数将指针传递给函数时可能会修改了本不想改变的指针所指向的对象的值。如:
const int num = 7;
num = 9; //可能得到编译器的警告。
const char *ptr,则表示该指针所指向的内容不会被改变,如果在程序中被发生对其赋值的操作,编译时将出错误提示。如:
const char *ptr = hello;
*ptr = ‘H; //错误,所指内容不可改变也可将const 放在星号后面来声明指针本身不可改变。如:
char* const ptr;
ptr++; //错误,指针本身不可改变
也可同时禁止改变指针和它所引用的内容,其形式如下:
const char* const ptr;
【规则11】使用static
static是一个能够减少命名冲突的有用工具。将只在一个模块文件中的变量和函数使用static
修饰,将不会和其他模块可能具有相同名称的函数和变量在模块连接时不会产生名称冲突。一般来说,只要不是提供给其它模块使用的函数,和非全局变量,均应使用static修饰。将子程序中的变量使用static
修饰时,表示这个变量在程序开始时分配内存,在程序结束时释放,它们在程序执行期间保持它们的值。如:
void func1(void)
{
static int time = 0;
time++
}
void func2(void)
{
static int time = 0;
time++;
}
两个子程序中的time 变量使用static
修饰,所以它们是静态变量,每调用一次time将进行加1,并保持这个值。它们的功能与下面程序相似:
int time1 = 0;
int time2 = 0;
void func1(void)
{
time1++
}
void func2(void)
{
time2++;
}
我们可以看出,使用static修饰后,模块中的全局变量减少,使得程序的更为简单。
【规则12】不要忽视编译器的警告。
编译器的给出的警告都是有的放矢,在没有查清引起警告的真正原因之前,不要忽视它。
【规则13】注意溢出问题,写安全的代码。
1.4 KeilC 编程
【规则14】深入了解你所用的工具。仔细查看KeilC 附带的帮助文件,你能找到你期待已久的东西。KeilC
是当前最好用的单片机开发软件。要充分利用该软件的功能,就必须对它深入的进行了解。
【规则15】不要使用语言的冷僻特性,并且记住,耍小聪明会贻害无穷。最重要的是编写你理解的代码,理解你编写的代码,你就可能会做得很好。