《单片机编程魔法师之高级裸编程思想》数据驱动程序

单片机

当你做了很多单片机项目的时候，你可能需要这些：

多任务程序

多任务并行程序

多个定时器

多个延时并行

面向对象编程

但是，你首先需要数据驱动程序……

yyy71cj · 2014-12-8 20:59:18

1.5.2 实现

图1.5.1所示问题的实现代码如图1.5-3。

文档：.. 3.c.. @Project:3.uvproj && Output: 3.hex

#include

***it P10=P1^0;

***it P11=P1^1;

void delay(unsigned int t)

{

unsignedint i;

for(i=0;i

}

main(void)

{

while(1)

{

P10 = 0; // 阶段1

P11 = 0;

delay(749);

P10 = 1; // 阶段2

P11 = 0;

delay(251);

P10 = 0; // 阶段3

P11 = 0;

delay(749);

P10 = 1; // 阶段4

P11 = 1;

delay(251);

}

图1.5-3 扩周期法同时实现两支波

yyy71cj · 2014-12-14 10:16:13

1.5.3 仿真

图1.5-3中所示的代码编译后仿真结果如图1.5-4所示。

仿真结果再一次告诉我们，解决问题，我们做到了，这两支波形不仅各自符合我们的要求，而且相互之间也完全同步，这无疑是一个好兆头。

1.5.4 亮点分析

图1.5-4的仿真结果验证了我们的编程方法没有问题，这就给了我们继续下去的信心和理由。但是我们依然不必太在意结果是否正确，而是更多地关注程序的编法，因为我们把任务弄得太简单了，但这还不是主要的，主要的是，我们离目标还有距离。为了获得编程思想上的升华，现在我们先来看看代码中的亮点(如图1.5-5)。

从图1.5-5中我们明显可以看出，代码中有冗余代码。通常，冗余的代码是不好的代码，为了节约资源与提高执行效率，我们会选择对其进行精简。但是这里为什么我们这里并不做简化呢？这是因为，我们还没把问题彻底解决，急于简化代码对我们解决问题未必就会有好处，所以我们权且把它们放在上面，等答案最终浮出水面的时候，我们再来考虑是否简化这些还来得及。

yyy71cj · 2014-12-15 20:26:20

本帖最后由 yyy71cj 于 2014-12-15 20:28 编辑

1.6四支波的实现1.6.1 问题与分析

我们前面说过，解决这样的问题，两支波与多支波的难度是一样的。

根据这种说法，在上节两支波已经被我们实现了，这也就等于四支波的问题也被我们解决了。

真的吗？是的！

我们再来回顾一下问题1中问题的关键：一是要实现这四支波，另一是要让这四支波保持一种同步关系。我们编程思路的正确与否，图1.5-4已经给了我们答案。

经历了一个循序渐进的编程思维演绎过程，问题1中的四支方波同步实现的问题不知不觉地得到了解决，它不再如我们初见它时的那么棘手与强大了。我们只要沿照上面的思路继续扩充我们的代码，问题就一定能够得到解决。

在实现方法上已经没有任何事情要处理了，关于编程工作，剩下的要做的就是，我们只需通过在循环体内扩充周期的方法依葫芦画瓢，找到这四支波在循环周期上的最小公倍数将实现代码写出来就可以了。

1.6.2 实现

实现四支波的完整代码如图1.6-1。

文档：.. 4.c.. @Project:4.uvproj && Output: 4.hex

#include

***it P10=P1^0;

***it P11=P1^1;

void delay(unsigned int t)

{

unsignedint i;

for(i=0;i

}

main(void)

{

while(1)

{

P10 = 0; // 阶段1

P11 = 0;

P12 = 0;

P13 = 0;

delay(749);

P10 = 1; // 阶段2

P11 = 0;

P12 = 0;

P13 = 0;

delay(251);

P10 = 0; // 阶段3

P11 = 0;

P12 = 0;

P13 = 0;

delay(749);

P10 = 1; // 阶段4

P11 = 1;

P12 = 0;

P13 = 0;

delay(251);

P10 = 0; // 阶段5

P11 = 0;

P12 = 0;

P13 = 0;

delay(749);

P10 = 1; // 阶段6

P11 = 0;

P12 = 0;

P13 = 0;

delay(251);

P10 = 0; // 阶段7

P11 = 0;

P12 = 0;

P13 = 0;

delay(749);

P10 = 1; // 阶段8

P11 = 1;

P12 = 1;

P13 = 0;

delay(251);

P10 = 0; // 阶段9

P11 = 0;

P12 = 0;

P13 = 0;

delay(749);

P10 = 1; // 阶段10

P11 = 0;

P12 = 0;

P13 = 0;

delay(251);

P10 = 0; // 阶段11

P11 = 0;

P12 = 0;

P13 = 0;

delay(749);

P10 = 1; // 阶段12

P11 = 1;

P12 = 0;

P13 = 0;

delay(251);

P10 = 0; // 阶段13

P11 = 0;

P12 = 0;

P13 = 0;

delay(749);

P10 = 1; // 阶段14

P11 = 0;

P12 = 0;

P13 = 0;

delay(251);

P10 = 0; // 阶段15

P11 = 0;

P12 = 0;

P13 = 0;

delay(749);

P10 = 1; // 阶段16

P11 = 1;

P12 = 1;

P13 = 1;

delay(251);

}

图1.6-1 扩周期法同时实现四支波

从图1.6-1中的代码中我们可以看出，这里没什么技巧，就是一些重复与状态的修改，任务就这样被完成了。

我们此时只需要暂且容忍里头存在着的大量的冗余就可以了，现在，一个正确的结果是我们更想要的，所以眼下还不是清理冗余的时候。

xiaozhu2014xwf · 2014-12-16 22:03:04

绝对的强大必须顶起

yyy71cj · 2014-12-16 22:59:17

1.6.3 仿真

这样的代码是否存在问题，我们都通常是很不愿意通过耗费大量精力对代码逻辑分析去验证的，因为那仍然不是很可靠。

直白的结果将更具有说服力，我们可以通过软件仿真来获得更直白的结果。我们只需要看一下仿真结果就可以验证我们代码的正确性了。

仿真结果如图1.6-2。

片刻便有了结果。结果很明显，程序是正确的，我们的努力获得了回报。

但是也许这不会给我们有惊喜的感觉，因为这里毫无技巧的代码让我们觉得很难受，甚至有挫败感。一段没有技巧的代码解决一个问题，这通常会让我们的感觉如同没有解决问题1样的郁闷。所以我们必须要想办法简化这段代码。

uiu809 · 2014-12-18 09:44:28

谢谢楼主的分享，希望俄能够学习

yyy71cj · 2014-12-19 21:00:48

1.7冗余代码的一次简化

1.7.1 亮点分析

在上节中我们虽然实现了问题1中的四支波，但是实现的代码却如新手编程一样，只堆积了一些冗余的语句。

由于在问题还没解决之前，我们更在乎的是我们能不能解决问题，而代码质量的好与坏还不是主要矛盾。但是现在问题解决了，我们不能对那些刺眼的代码再坐视不理了，我们已经忍得太久了。但凡有点编程基础的人对之都会很看不惯的，我们一定要想办法去简化它并期望能获得一个更好的执行效率。

但是如何简化呢？是直接把冗余的部分去掉吗？

通常我们会倾向这么做。

但是在这里，我们应该说“不”！因为看那些看似精炼的参差不齐的简化代码，我觉得倒不如把冗余放在上面，以让我们的代码看起来更有规律些，因为格式工整的代码更易于理解与维护。

既然我们不打算去掉冗余的代码，而我们又要简化这些代码，我们就必须得另辟蹊径，从这些规整的冗余中发现奥妙。

好了，为了解决简化代码的问题，我们还是把那些臃肿的代码先抽出一部分来分析一下(如图1.7-1)。

我们知道，在单片机的指令中，虽然位操作指令的执行速度比较快，但是位操作指令堆砌多了，那就未必了。为了优化代码，很显然我们不能容忍如图1.7-1这样啰嗦的代码。好在我们有办法来简化它们，我们只需要用一句更合适的C语言语句就能实现它们的全部功能(如图1.7-2)。

代码合并后，好处一是原来的4句代码变成了1句，很明显，语句减少了，这至少会让我们的源码变得更短一些，至于运行速度有没有提高，我们暂时不必去追究。

而这样简化的另一个好处，也是一个更重要的好处，那就是这个语句会让四个口线电平翻转更同步。

图1.6-2中的仿真结果虽然看起来很同步，但是事实上，根据图1.7-1中代码的运行特点，各端口的电平跳变不是同时发生的，而是从P1.0~P1.3依次存在一个指令执行时间的时间差。也就是说P1.1的电平翻转比P1.0的电平翻转滞后了一个执行语句“P10=1”的时间，P1.2的电平翻转比P1.1的电平翻转又滞后了一个执行语句“P11=1”的时间，依次类推。为什么图1.6-2并没有反映这一点呢？那是因为单片机执行一条端口位的赋值语句太快了，我们的软件示波器很难分辨出来，而我们的肉眼就更看不出来了，但是这个滞后毫无争议地存在。

经过图1.7-2中的代码合并后，虽然看起来处理是复杂了些，但是P.0~P1.3的电平翻转被一条字节赋值命令一下子全部执行了，也就是说，这4根口线电平翻转事件完全同步发生。这显然正是我们所追求的。

yyy71cj · 2014-12-20 14:19:55

1.7.2 代码简化

按照上面的思路，我们将图1.6-1中的四支波实现代码简化一下(如图1.7-3)。

文档：.. 5.c.. @Project:5.uvproj && Output: 5.hex

#include

***it P10=P1^0;

***it P11=P1^1;

void delay(unsigned int t)

{

unsignedint i;

for(i=0;i

}

main(void)

{

while(1)

{

P1 = P1 & 0xF0 | 0x00; //阶段1

delay(749);

P1 = P1 & 0xF0 | 0x01; //阶段2

delay(251);

P1 = P1 & 0xF0 | 0x00; //阶段3

delay(749);

P1 = P1 & 0xF0 | 0x03; //阶段4

delay(251);

P1 = P1 & 0xF0 | 0x00; //阶段5

delay(749);

P1 = P1 & 0xF0 | 0x01; //阶段6

delay(251);

P1 = P1 & 0xF0 | 0x00; //阶段7

delay(749);

P1 = P1 & 0xF0 | 0x07; //阶段8

delay(251);

P1 = P1 & 0xF0 | 0x00; //阶段9

delay(749);

P1 = P1 & 0xF0 | 0x01; //阶段10

delay(251);

P1 = P1 & 0xF0 | 0x00; //阶段11

delay(749);

P1 = P1 & 0xF0 | 0x03; //阶段12

delay(251);

P1 = P1 & 0xF0 | 0x00; //阶段13

delay(749);

P1 = P1 & 0xF0 | 0x01; //阶段14

delay(251);

P1 = P1 & 0xF0 | 0x00; //阶段15

delay(749);

P1 = P1 & 0xF0 | 0x0F; // 阶段16

delay(251);

}

图1.7-3 简化后实现四支波的代码

yyy71cj · 2014-12-21 15:50:38

1.8冗余代码的二次简化

1.8.1 亮点分析

不用说，在上节中，图1.7-3中的代码相比图1.6-1已经大大简化了代码，但是这显然还不是我们想要的结果，因为这样的代码依然很臃肿。我们一定不能容忍如图1.8-1所示的代码。

对于如图1.8-1的这种多次出现的代码，很多人一定会心痒痒地要将其简化掉。但是我们应该对其化简吗？

不！不必。前面的经验告诉我们，保留一个通用的规律，可能更科学。为了深入进一步简化，我们还是保留其计算规律更好。

相信大家一眼就能看出，图1.7-3中更冗余的代码不是其中的某一句，而是图1.8-2中所示的某两句。

图1.8-2中所示的代码模式在图1.7-3中的程序里重复出现了16次，这对我们来说还能算是简化的代码吗？当然不是。我们一再拒绝对图1.8-1中所示的代码进行精简，是因为我们需要一个精简的方向。因为更令我们不满的是图1.8-2中所示的这种成组的啰嗦重复的代码模式，我们可以尝试着把这两句代码进行合并，而且这样做除了可以简化代码外，还会给我们带来意外的惊喜。

我们保留了代码的高度一致性，没有盲目地去简化代码，为的就是这一次的合并。在延时前都做同样的事，很显然这一件事与延时函数可以融合，融合后的函数当然不再是单纯的延时函数了，它既修改口线状态，又实现延时，功能范围扩大了。功能范围的扩大，这只是个表象，而事实是，延时函数的身份在悄然发生变化。

冷超 · 2014-12-23 08:47:24

太厉害了。。。这么一个问题，就这么简单而完美的解决

yyy71cj · 2014-12-29 19:57:03

badboypaopao 发表于 2014-12-23 08:47
太厉害了。。。这么一个问题，就这么简单而完美的解决

1.8.2 代码简化

根据上面的思路，我们再对图1.7-3中的代码做一次优化(如图1.8-3)。

文档：.. 6.c.. @Project:6.uvproj && Output: 6.hex

#include

***it P10=P1^0;

***it P11=P1^1;

void delay(unsigned char d, unsigned int t)

{

unsignedint i;

P1 = P1 & 0xF0 | d;

for(i=0;i

}

main(void)

{

while(1)

{

delay(0x00, 749); //阶段1

delay(0x01, 251); //阶段2

delay(0x00, 749); //阶段3

delay(0x03, 251); //阶段4

delay(0x00, 749); //阶段5

delay(0x01, 251); //阶段6

delay(0x00, 749); //阶段7

delay(0x07, 251); //阶段8

delay(0x00, 749); //阶段9

delay(0x01, 251); //阶段10

delay(0x00, 749); //阶段11

delay(0x03, 251); //阶段12

delay(0x00, 749); //阶段13

delay(0x01, 251); //阶段14

delay(0x00, 749); //阶段15

delay(0x0F, 251); // 阶段16

}

图1.8-3 再次优化后实现四支波的代码

现在，图1.8-3告诉我们，函数delay发生了变化了，参数多了一个。我们把P1口的0~3四个口线的状态变成了数据，作为参数传递给了delay，而delay的身份显然已经发生了变化，现在它具有口线赋值与延时的双重身份。同时，在主体循环体内的代码数量，也减少了一半。

看来我们又如愿以偿地对代码做了一次精简，而且我们精简代码的工作看起来获得了不少的成效，代码少了，执行效率没有受到太多的影响。

但是，一堆delay出现在循环体内，很显然，精简工作还有事情要做。

yyy71cj · 2014-12-29 19:58:11

1.9冗余代码的三次简化

1.9.1 数码分离的启示

上节的简化中，我们已经把循环体内的代码做了大量的精简，虽然我们精简的工作还没有结束，但是我们精简的方向却逐渐明朗起来，更强烈的规律就摆在我们的眼前，相信善于思考的人此刻会有不少的想法。

我得告诉大家，我们离最终的目的也越来越近了。

正如图1.8-3中的代码所示，我们在循环体内只看到了delay和它的参数们。这正是为我们解决最后的优化问题而留下的一个暗示：只剩下一堆数据以及处理这些数据的一个通用函数了。

这是个什么情况？

一堆不需要代码的数据，与一个不需要特定数据的处理函数(代码)！这不正是数据驱动程序的典型特征吗？

这太让人兴奋了！几经折腾，我们终于找到了光明大道。我们所有的忍耐与提炼，就是为了在这里得到升华的。

我们知道，数据驱动的程序就是通过使用脚本解析器对数据脚本进行解析而驱动程序按照一定的逻辑进行演绎的程序。

现在我们只需要按照这种思路，把图1.8-3中代码的数据与脚本分别整理出来，我们就会修得正果，最终解决问题。

那么，图1.8-3中代码的脚本解析器是什么呢？很显然，delay函数是当仁不让的了，因为它是循环中唯一的执行机构。

那图1.8-3中代码的数据脚本又是什么？很显然，那一对对的参数，就是我们的delay解析器所需要的数据脚本了。

根据数据驱动程序的精神，我们应该为一个脚本解析器输送数据，并让这个脚本解析器解析数据，这样我们就能编写出数据驱动的程序来。

这里有两个要点。首先，最理想的情况是，脚本解析器只有一个；其次，最理想的情况是，脚本数据只有一种格式，而且是一组这种数据的集合，集合中的数据越多，越能体现数据驱动的优越性。

yyy71cj · 2014-12-30 19:04:13

1.9.2 数据脚本

好了，现在我们可以先专注于我们数据脚本的描述。

我们先来看一下数据脚本的特点。

首先，数据脚本是有一组数据单元组成的，数据单元彼此相邻，形成一个有秩序的序列，这样的形式才适合做扫描处理。数据单元的秩序便是一种动态时序的反映，它可以代表一个运动规律的一个片段，也可以代表整个运动规律。

其次，数据单元由数据组成，它既可以只有一个数据，也可以有多个数据联合组成，这些数据的数据类型可以相同，也可以不同。

第三，数据可以直白地描述客观对象，也可以对客观对象进行扭曲描述，描述的方式既为表达客观对象本身服务，也为便于数据解析服务。

如果是计算机编程，我们完全可以使用一个脚本文件来描述数据脚本，但是在单片机中我们不能这样做，因为单片机中文件处理很不方便。不过C语言中有一种数据结构，完全可以帮我们描述一些简单的数据脚本，这种数据结构就是数组。

我们把参数中的数据提取出来，按照不同的类型进行分组罗列，分别放到各自的数组中去(如图1.9-1)，形成一个序列，这就是我们最简洁的数据脚本。虽然这种罗列很初级，但是它已经能工作了。

// 端口状态数组

unsigned char codeP1_1234[] = {0, 1, 0, 3, 0, 1, 0, 7, 0, 1, 0, 3, 0, 1, 0, 15};

// 延时长度数组

unsigned int code Dts[] ={749, 251, 749, 251, 749, 251, 749, 251, 749, 251, 749, 251, 749, 251, 749,251};

图1.9-1 平淡无奇的数据脚本

因为是常量，所以我们应该把数组声明在代码段(code内存区)以节省内存，从这里可以看出，数据脚本还与存储方式相关。随着我们实践的深入与实践面的扩宽，数据脚本的一些特点便会逐渐被我们认识，我们与新概念的陌生感也终将会褪去。

yyy71cj · 2015-1-5 19:12:27

1.9.3 数据驱动的实现

这是一个其貌不扬的数据脚本，甚至根本就不像个脚本。但是在这里，我们先不追求它的样子了，有一个脚本已经是一个跨越了。我们依旧采取先解决问题的指导思想，播放它们才是我们急不可耐的目标。现在我们根据这个脚本把相应的播放程序完成(如图1.9-2)。

文档：.. 7.c.. @Project:7.uvproj && Output: 7.hex

#include

***it P10=P1^0;

***it P11=P1^1;

#define STAGES 16

unsigned char codeP1_1234[] = {0, 1, 0, 3, 0, 1, 0, 7, 0, 1, 0, 3, 0, 1, 0, 15};

unsigned int code Dts[] ={749, 251, 749, 251, 749, 251, 749, 251, 749, 251, 749, 251, 749, 251, 749,251};

void delay(unsigned char d, unsigned int t)

{

unsignedint i;

P1 = P1 & 0xF0 | d;

for(i=0;i

}

main(void)

{

inti;

while(1)

{

for(i=0; i

delay(P1_1234, Dts);

}

图1.9-2 再次简化后实现四支波的代码

yyy71cj · 2015-1-5 19:13:10

1.9.4 回顾与思考

上面这段代码就简洁多了，没几句话就解决了我们所提出的看似棘手的问题，重复出现的代码不复存在，没什么形式让我们感觉很碍眼的了，精简工作也终于尘埃落定。

但是我们不能急于沾沾自喜，因为光有个结果而没有方法论，不能算是技术上的进步。我们需要来思考一下，我们从这段工作中获得了什么，失去了什么。这不是说我们做事情患得患失，而是要对得失了然于心，好十分清楚我们行动的分寸，以便我们将来更好更准确的把握我们行为的尺度。

我们可以看出，前面未经简化的代码虽然很长，但是却很好懂，而图1.9-2中的代码虽然简洁，但是却很难懂，如果没有前面提出的问题，咋一看我们几乎不知道图1.9-2中的代码是做什么的。很显然，隐藏的规律是需要几经推敲才能被看出的，所以这可能会让我们不安，因为我们很有可能在时间的磨炼中忘记这段工作经历，最终我们将不再象现在这样把这里的逻辑说的头头是道。

这似乎需要我们进行一些反思，我们该如何让我们思想的光芒一直闪耀下去呢？按目前的情况，我想除了完备的文档资料，也许还没有别的更好的手段了。不是说最淡的墨水胜过最强的记忆吗？我们得坚信这一点。所以，也许我们应该为我们的程序加上详尽而准确的注释，以弥补那些被精简掉的逻辑表达形式。

由于对四支波的规律进行了高度浓缩地提炼，在实际应用的效果上，图1.9-2中的代码对于解决问题就将变得更合理、更有效。

这是为什么呢？

这是因为我们把原来有程序逻辑关系来解决的问题转移到数据脚本中去了，而数据脚本则用更精炼的直白告诉程序我们所面临的问题的逻辑关系。有了数据脚本，原来复杂的编程问题就转化成了简单的数据分析的问题，编写这样的数据脚本，即使是不懂编程的人稍加培训也能做到。

也因此，这种过去只属于设计研发人员的劳动，现在已经转化为可以进入生产流水线中的工作了。也许这种转变在很多场合下并没有多少实际意义，但是却在某些需要的场合可以让我们的任务进入量产，这种意义也非同小可。

尽管对于这种逻辑关系的提炼，可能需要我们经历一个更费脑筋的分析过程。但是，这很值得。因为一旦建立了数据脚本与解析器，我们除了解决了问题1中的问题外，我们还顺带地解决了所有类似的相关问题，关键是还不容易出错。

033157pmh · 2015-1-9 15:36:03

书写的不错，思路特别好，要是多一二个应用实例就更好了

yyy71cj · 2015-1-12 08:52:08

033157pmh 发表于 2015-1-9 15:36
书写的不错，思路特别好，要是多一二个应用实例就更好了

会有的，就是需要一些时间。不写书不知道，写书就知道，写起来很难……

yyy71cj · 2015-1-12 08:54:44

1.10四支波数据驱动程序应用(一)

1.10.1 问题2与分析

一个规律的发现，就是能为广泛应用服务的，如果不能那样，那就只是个特例。

数据驱动的代码既然能从应用中提炼出数据，那么数据规律就决定了应用的功能，因为播放器是没有特性的，它只是机械的解释数据，如果数据是这样，那播放器就会解析出这样的结果，如果数据是那样，那播放器就会解析出那样的结果。

在上节我们获得了一个数据驱动的四支波解析器，我们通过一个数据脚本，让它成功的解析了问题1中的四支波。现在我们继承一下这次成功的果实，不是说有些研发的成功可以带来应用的量产化吗？那么我们就利用前面的成果来量产化处理解析另外的四支波，看起来似乎完全没有共同点的四支。

现在我们自我折腾一下，用我们已有的数据驱动的代码来实现问题2(如图1.10-1)所示的四支波，图中的数据单位与前面的相同。

从问题2中可以看出，这四支波我们依旧是以延时循环次数作为延时单位，第一支波由1个宽度为500的低电平开始，接着便是7个宽度为500的连续高电平。第二支波则由两个宽度为500的低电平开始，接着便是5个宽度为500的连续高电平，最后还有1个宽度为500的低电平收尾。第三支波则由3个宽度为500的连续低电平开始，接着则是3个宽度为500的连续高电平，最后由2个宽度为500的低电平收尾。第四支波一开始便是4个宽度为500的连续低电平，然后只有1个宽度为500的高电平，最后还有3个宽度为500的连续低电平断后。

问题2中的这四支波依然具有严格的同步关系。尽管看起来它们没有共同的上升沿和下降沿，它们有着相同的起点与相同的终点，这样它们看起来是一种包含与被包含的关系，很显然，这种关系要求这四支波具有相同的频率。频率相同也为同步奠定了一个基础，至于方波的边沿则与是否同步毫无关系。

这个问题与问题1中的问题已经有了不少的变化，下面我们将利用我们已经修炼出的数据驱动程序的编程思想来实现这四支波。

我们知道，数据驱动程序的其中一个好处就是我们不再需要为代码花太多的精力了，因为我们有了一个通用的解析器，它并不为某个特定的波所专用。

我们这个通用的解析器可以根据方波的宽度来生成方波，并可以根据脚本数据的顺序来生成一定的波形。

尽管问题2中的波形与问题1中的波形有很大的差别，但是都是由方波组成的共性却洋溢于表。我们完全可以用一定的方波来组成它们，只要我们能生成方波就可以了。而生成方波组成一定的波形正是我们当前解析器的特长，它就如一个积木搭建器一样可以对方波进行各种组合。

现在我们的控制代码有了，看来编程的工作也基本结束了，剩下的只是，我们需要在编写数据脚本的问题上做做文章。也就是说，我们眼下的任务就是把问题2中的四支波拆分成最大细分基本组成单元，一些具有一定宽度的基础高电平与低电平，并用一组数据来描述它，就如一个个的积木，并最终交由积木搭建器来完成它们的组合。

根据前面的分析方法，我们可以将问题2的四支波进行一个阶段(即一个周期)的分析，我们需要挖掘出它们相互关联的数据，即一个循环周期是什么，循环周期内不同阶段各口线的电平是什么。

当然，脚本的形式对不同的问题未必一样，脚本的形式遵循代码优化原则，在此我们不对脚本代码优化进行过多的探讨，由魔法师们自己在具体应用中各显神通。

经过分析，我们会发现问题2这四支波的规律会比问题1的要简单得多，所以它的脚本也不必如图1.9-1中所示的那样复杂。新的脚本如图1.10-2。

// 脚本只包括变化的数据

// 变化的规律隐藏着事物的发展规律

// 固定的数据可以作为常数

// 因为这个问题的不同阶段的基本宽度是500

// 所以在这里当作常数来对待而不必在脚本中体现

unsigned char codeP1_1234[] = {0, 1, 3, 7, 15, 7, 3, 1};

图1.10-2 新的脚本

图1.10-2中我们只用了一个数组，因为问题2中的要求有所简化，延时的时长只有一个常量是500，所以我们没必要为一个固定的常量使用数组，这也是这个数据脚本更为简单的原因。

yyy71cj · 2015-1-13 15:27:22

1.10.2 实现

写出了新的脚本，我们基本上就完成了这四支波的编程任务，脚本播放器不用做任何修改就可以拿来使用。数据脚本发生了变化，我们只需要在播放器使用的时候略做一些修改就能达到目的。

解决问题2中四支波的代码如图1.10-3所示。

文档：.. 8.c.. @Project:8.uvproj && Output: 8.hex

#include

***it P10=P1^0;

***it P11=P1^1;

***it P12=P1^2;

***it P13=P1^3;

#define STAGES 8

unsigned char code P1_1234[]= {0, 1, 3, 7, 15, 7, 3, 1};

void delay(unsigned char d, unsigned int t)

{

unsignedint i;

P1 = P1 & 0xF0 | d;

for(i=0;i

}

main(void)

{

inti;

while(1)

{

for(i=0; i

delay(P1_1234, 500);

}

图1.10-3 实现问题2的代码

yyy71cj · 2015-1-14 18:23:02

1.10.3 仿真

看起来，我们面临的敌人似乎异常弱小，编程不再是什么艰苦的事情了，接下来我们只需要检验一下结果了。图1.10-3中代码编译后仿真的结果(如图1.10-4)。

从图1.10-4中我们可以看出，这四支波首先它们在形状上与我们的要求是一致的，自上而下，它们在高电平段一个包着一个，其次，如果从A点开始计算方波起点，那么这四支波的低电平与高电平的宽度也正好与我们的要求相符，第三，它们是同步的，形状上的位置关系与相同的周期能为我们提供足够的证据。看来这正是我们想要的，不是吗？程序没什么问题。

搜索历史

《单片机编程魔法师之高级裸编程思想》数据驱动程序

相关推荐

78 条评论

评论

精选推荐

热门帖

站长推荐 /6