控制工程师论坛

嵌入式系统

C语言嵌入式系统编程修炼之内存操作篇

lxw19881017
lxw19881017

2012-08-27

数据指针

  在嵌入式系统的编程中,常常要求在特定的内存单元读写内容,汇编有对应的MOV指令,而除C/C++以外的其它编程语言基本没有直接访问绝对地址的能力。在嵌入式系统的实际调试中,多借助C语言指针所具有的对绝对地址单元内容的读写能力。以指针直接操作内存多发生在如下几种情况:

  (1)
某I/O芯片被定位在CPU的存储空间而非I/O空间,而且寄存器对应于某特定地址;

  (2)
两个CPU之间以双端口RAM通信,CPU需要在双端口RAM的特定单元(称为mail box)书写内容以在对方CPU产生中断;

  (3)
读取在ROM或FLASH的特定单元所烧录的汉字和英文字模。

譬如:


unsigned char *p = (unsigned char *)0xF000FF00;

*p="11";

  以上程序的意义为在绝对地址0xF0000+0xFF00(80186使用16位段地址和16位偏移地址)写入11。

  在使用绝对地址指针时,要注意指针自增自减操作的结果取决于指针指向的数据类别。上例中p++后的结果是p= 0xF000FF01,若p指向int,即:

int *p = (int *)0xF000FF00;

  p++(或++p)的结果等同于:p = p+sizeof(int),而p-(或-p)的结果是p = p-sizeof(int)。

记住:CPU以字节为单位编址,而C语言指针以指向的数据类型长度作自增和自减。理解这一点对于以指针直接操作内存是相当重要的。

函数指针

  首先要理解以下三个问题:

  (1)C语言中函数名直接对应于函数生成的指令代码在内存中的地址,因此函数名可以直接赋给指向函数的指针;

  (2)调用函数实际上等同于"调转指令+参数传递处理+回归位置入栈",本质上最核心的操作是将函数生成的目标代码的首地址赋给CPU的PC寄存器;

  (3)因为函数调用的本质是跳转到某一个地址单元的code去执行,所以可以"调用"一个根本就不存在的函数实体,晕?请往下看:


  请拿出你可以获得的任何一本大学《微型计算机原理》教材,书中讲到,186 CPU启动后跳转至绝对地址0xFFFF0(对应C语言指针是0xF000FFF0,0xF000为段地址,0xFFF0为段内偏移)执行,请看下面的代码:

typedef void (*lpFunction) ( ); /* 定义一个无参数、无返回类型的 */

/* 函数指针类型
*/

lpFunction lpReset = (lpFunction)0xF000FFF0; /* 定义一个函数指针,指向*/

/* CPU启动后所执行第一条指令的位置 */

lpReset(); /* 调用函数 */

  在以上的程序中,我们根本没有看到任何一个函数实体,但是我们却执行了这样的函数调用:lpReset(),它实际上起到了"软重启"的作用,跳转到CPU启动后第一条要执行的指令的位置。

  记住:函数无它,唯指令集合耳;你可以调用一个没有函数体的函数,本质上只是换一个地址开始执行指令!

数组vs.动态申请

  在嵌入式系统中动态内存申请存在比一般系统编程时更严格的要求,这是因为嵌入式系统的内存空间往往是十分有限的,不经意的内存泄露会很快导致系统的崩溃。

  所以一定要保证你的malloc和free成对出现,如果你写出这样的一段程序:


char * function(void)

{

 char
*p;

 p
= (char *)malloc(…);

 if(p==NULL)

  …;

  …
/* 一系列针对p的操作 */

 return
p;

}

  在某处调用function(),用完function中动态申请的内存后将其free,如下:

char *q = function();



free(q);

  上述代码明显是不合理的,因为违反了malloc和free成对出现的原则,即"谁申请,就由谁释放"原则。不满足这个原则,会导致代码的耦合度增大,因为用户在调用function函数时需要知道其内部细节!

  正确的做法是在调用处申请内存,并传入function函数,如下:

char *p="malloc"(…);

if(p==NULL)

…;

function(p);



free(p);

p="NULL";

  而函数function则接收参数p,如下:

void function(char *p)

{

 …
/* 一系列针对p的操作 */

}

  基本上,动态申请内存方式可以用较大的数组替换。对于编程新手,笔者推荐你尽量采用数组!嵌入式系统可以以博大的胸襟接收瑕疵,而无法"海纳"错误。毕竟,以最笨的方式苦练神功的郭靖胜过机智聪明却范政治错误走反革命道路的杨康。

  给出原则:


  (1)尽可能的选用数组,数组不能越界访问(真理越过一步就是谬误,数组越过界限就光荣地成全了一个混乱的嵌入式系统);

  (2)如果使用动态申请,则申请后一定要判断是否申请成功了,并且malloc和free应成对出现!

const在C++语言中则包含了更丰富的含义,而在C语言中仅意味着:"只能读的普通变量",可以称其为"不能改变的变量"(这个说法似乎很拗口,但却最准确的表达了C语言中const的本质),在编译阶段需要的常数仍然只能以#define宏定义!故在C语言中如下程序是非法的:

关键字const

  const意味着"只读"。区别如下代码的功能非常重要,也是老生长叹,如果你还不知道它们的区别,而且已经在程序界摸爬滚打多年,那只能说这是一个悲哀:

const int a;

int const a;

const int *a;

int * const a;

int const * a const;

const int SIZE = 10;

char a[SIZE]; /* 非法:编译阶段不能用到变量 */

关键字volatile

volatile变量可能用于如下几种情况:

  (1)
并行设备的硬件寄存器(如:状态寄存器,例中的代码属于此类);

  (2)
一个中断服务子程序中会访问到的非自动变量(也就是全局变量);

  (3)
多线程应用中被几个任务共享的变量。

C语言嵌入式系统编程修炼之屏幕操作篇

汉字处理

  现在要解决的问题是,嵌入式系统中经常要使用的并非是完整的汉字库,往往只是需要提供数量有限的汉字供必要的显示功能。例如,一个微波炉的LCD上没有必要提供显示"电子邮件"的功能;一个提供汉字显示功能的空调的LCD上不需要显示一条"短消息",诸如此类。但是一部手机、小灵通则通常需要包括较完整的汉字库。

  如果包括的汉字库较完整,那么,由内码计算出汉字字模在库中的偏移是十分简单的:汉字库是按照区位的顺序排列的,前一个字节为该汉字的区号,后一个字节为该字的位号。每一个区记录94个汉字,位号则为该字在该区中的位置。因此,汉字在汉字库中的具体位置计算公式为:94*(区号-1)+位号-1。减1是因为数组是以0为开始而区号位号是以1为开始的。只需乘上一个汉字字模占用的字节数即可,即:(94*(区号-1)+位号-1)*一个汉字字模占用字节数,以16*16点阵字库为例,计算公式则为:(94*(区号-1)+(位号-1))*32。汉字库中从该位置起的32字节信息记录了该字的字模信息。

对于包含较完整汉字库的系统而言,我们可以以上述规则计算字模的位置。但是如果仅仅是提供少量汉字呢?譬如几十至几百个?最好的做法是:

  定义宏:


# define EX_FONT_CHAR(value)

# define EX_FONT_UNICODE_VAL(value) (value),

# define EX_FONT_ANSI_VAL(value) (value),

定义结构体:


typedef struct _wide_unicode_font16x16

{

 WORD
value; /* 内码 */

 BYTE
data[32]; /* 字模点阵 */

}Unicode;

#define CHINESE_CHAR_NUM … /* 汉字数量 */

  字模的存储用数组:


Unicode chinese[CHINESE_CHAR_NUM] =

{

{

EX_FONT_CHAR("业")

EX_FONT_UNICODE_VAL(0x4e1a)

{0x04, 0x40, 0x04, 0x40, 0x04, 0x40, 0x04, 0x44, 0x44, 0x46, 0x24, 0x4c, 0x24,
0x48, 0x14, 0x50, 0x1c, 0x50, 0x14, 0x60, 0x04, 0x40, 0x04, 0x40, 0x04, 0x44,
0xff, 0xfe, 0x00, 0x00, 0x00, 0x00}

},

{

EX_FONT_CHAR("中")

EX_FONT_UNICODE_VAL(0x4e2d)

{0x01, 0x00, 0x01, 0x00, 0x21, 0x08, 0x3f, 0xfc, 0x21, 0x08, 0x21, 0x08, 0x21,
0x08, 0x21, 0x08, 0x21, 0x08,

0x3f, 0xf8, 0x21, 0x08, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01, 0x00, 0x01,
0x00}

},

{

EX_FONT_CHAR("云")

EX_FONT_UNICODE_VAL(0x4e91)

{0x00, 0x00, 0x00, 0x30, 0x3f, 0xf8, 0x00, 0x00, 0x00, 0x00, 0x00, 0x0c, 0xff,
0xfe, 0x03, 0x00, 0x07, 0x00,

0x06, 0x40, 0x0c, 0x20, 0x18, 0x10, 0x31, 0xf8, 0x7f, 0x0c, 0x20, 0x08, 0x00,
0x00}

},

{

EX_FONT_CHAR("件")

EX_FONT_UNICODE_VAL(0x4ef6)

{0x10, 0x40, 0x1a, 0x40, 0x13, 0x40, 0x32, 0x40, 0x23, 0xfc, 0x64, 0x40, 0xa4,
0x40, 0x28, 0x40, 0x2f, 0xfe,

0x20, 0x40, 0x20, 0x40, 0x20, 0x40, 0x20, 0x40, 0x20, 0x40, 0x20, 0x40, 0x20,
0x40}

}

}

  要显示特定汉字的时候,只需要从数组中查找内码与要求汉字内码相同的即可获得字模。如果前面的汉字在数组中以内码大小顺序排列,那么可以以二分查找法更高效的查找到汉字的字模。

  这是一种很有效的组织小汉字库的方法,它可以保证程序有很好的结构。

系统时间显示

  从NVRAM中可以读取系统的时间,系统一般借助NVRAM产生的秒中断每秒读取一次当前时间并在LCD上显示。关于时间的显示,有一个效率问题。因为时间有其特殊性,那就是60秒才有一次分钟的变化,60分钟才有一次小时变化,如果我们每次都将读取的时间在屏幕上完全重新刷新一次,则浪费了大量的系统时间。

  一个较好的办法是我们在时间显示函数中以静态变量分别存储小时、分钟、秒,只有在其内容发生变化的时候才更新其显示。

extern void DisplayTime(…)

{

 static
BYTE byHour,byMinute,bySecond;

 BYTE
byNewHour, byNewMinute, byNewSecond;

 byNewHour
= GetSysHour();

 byNewMinute
= GetSysMinute();

 byNewSecond
= GetSysSecond();

 

 if(byNewHour!=
byHour)

 {

  …
/* 显示小时
*/

  byHour
= byNewHour;

 }

 if(byNewMinute!=
byMinute)

 {

  …
/* 显示分钟
*/

  byMinute
= byNewMinute;

 }

 if(byNewSecond!=
bySecond)

 {

  …
/* 显示秒钟
*/

  bySecond
= byNewSecond;

 }

}

  这个例子也可以顺便作为C语言中static关键字强大威力的证明。当然,在C++语言里,static具有了更加强大的威力,它使得某些数据和函数脱离"对象"而成为"类"的一部分,正是它的这一特点,成就了软件的无数优秀设计。

动画显示

  动画是无所谓有,无所谓无的,静止的画面走的路多了,也就成了动画。随着时间的变更,在屏幕上显示不同的静止画面,即是动画之本质。所以,在一个嵌入式系统的LCD上欲显示动画,必须借助定时器。没有硬件或软件定时器的世界是无法想像的:

  (1) 没有定时器,一个操作系统将无法进行时间片的轮转,于是无法进行多任务的调度,于是便不再成其为一个多任务操作系统;

  (2) 没有定时器,一个多媒体播放软件将无法运作,因为它不知道何时应该切换到下一帧画面;


  (3) 没有定时器,一个网络协议将无法运转,因为其无法获知何时包传输超时并重传之,无法在特定的时间完成特定的任务。

  因此,没有定时器将意味着没有操作系统、没有网络、没有多媒体,这将是怎样的黑暗?所以,合理并灵活地使用各种定时器,是对一个软件人的最基本需求!

菜单操作

  无数人为之绞尽脑汁的问题终于出现了,在这一节里,我们将看到,在C语言中哪怕用到一丁点的面向对象思想,软件结构将会有何等的改观!


  笔者曾经是个笨蛋,被菜单搞晕了,给出这样的一个系统:

  要求以键盘上的"← →"键切换菜单焦点,当用户在焦点处于某菜单时,若敲击键盘上的OK、CANCEL键则调用该焦点菜单对应之处理函数。我曾经傻傻地这样做着:

/* 按下OK键 */

void onOkKey()

{

 /*
判断在什么焦点菜单上按下Ok键,调用相应处理函数 */

 Switch(currentFocus)

 {

  case
MENU1:

   menu1OnOk();

   break;

  case
MENU2:

   menu2OnOk();

   break;

  …

 }

}

/* 按下Cancel键 */

void onCancelKey()

{

 /*
判断在什么焦点菜单上按下Cancel键,调用相应处理函数 */

 Switch(currentFocus)

 {

  case
MENU1:

   menu1OnCancel();

   break;

  case
MENU2:

   menu2OnCancel();

   break;

  …

 }

}

  终于有一天,我这样做了:

/* 将菜单的属性和操作"封装"在一起 */

typedef struct tagSysMenu

{

 char
*text; /* 菜单的文本 */

 BYTE
xPos; /* 菜单在LCD上的x坐标 */

 BYTE
yPos; /* 菜单在LCD上的y坐标 */

 void
(*onOkFun)(); /* 在该菜单上按下ok键的处理函数指针 */

 void
(*onCancelFun)(); /* 在该菜单上按下cancel键的处理函数指针 */

}SysMenu, *LPSysMenu;

  当我定义菜单时,只需要这样:

static SysMenu menu[MENU_NUM] =

{

 {

  "menu1",
0, 48, menu1OnOk, menu1OnCancel

 }

 ,

 {

  "
menu2", 7, 48, menu2OnOk, menu2OnCancel

 }

 ,

 {

  "
menu3", 7, 48, menu3OnOk, menu3OnCancel

 }

 ,

 {

  "
menu4", 7, 48, menu4OnOk, menu4OnCancel

 }

 …

};

  OK键和CANCEL键的处理变成:

/* 按下OK键 */

void onOkKey()

{

 menu[currentFocusMenu].onOkFun();


}

/* 按下Cancel键 */

void onCancelKey()

{

 menu[currentFocusMenu].onCancelFun();


}

  程序被大大简化了,也开始具有很好的可扩展性!我们仅仅利用了面向对象中的封装思想,就让程序结构清晰,其结果是几乎可以在无需修改程序的情况下在系统中添加更多的菜单,而系统的按键处理函数保持不变。

  面向对象,真神了!

C语言嵌入式系统编程修炼之键盘操作篇

功能键的问题在于,用户界面并非固定的,用户功能键的选择将使屏幕画面处于不同的显示状态下。

处理功能键

  功能键的问题在于,用户界面并非固定的,用户功能键的选择将使屏幕画面处于不同的显示状态下。例如,主画面如图1:






















图1
主画面


  当用户在设置XX上按下Enter键之后,画面就切换到了设置XX的界面,如图2:




图2
切换到设置XX画面

  程序如何判断用户处于哪一画面,并在该画面的程序状态下调用对应的功能键处理函数,而且保证良好的结构,是一个值得思考的问题。

  让我们来看看WIN32编程中用到的"窗口"概念,当消息(message)被发送给不同窗口的时候,该窗口的消息处理函数(是一个callback函数)最终被调用,而在该窗口的消息处理函数中,又根据消息的类型调用了该窗口中的对应处理函数。通过这种方式,WIN32有效的组织了不同的窗口,并处理不同窗口情况下的消息。

  我们从中学习到的就是:

  (1)将不同的画面类比为WIN32中不同的窗口,将窗口中的各种元素(菜单、按钮等)包含在窗口之中;


  (2)给各个画面提供一个功能键"消息"处理函数,该函数接收按键信息为参数;


  (3)在各画面的功能键"消息"处理函数中,判断按键类型和当前焦点元素,并调用对应元素的按键处理函数。

/* 将窗口元素、消息处理函数封装在窗口中 */

struct windows

{

 BYTE
currentFocus;

 ELEMENT
element[ELEMENT_NUM];

 void
(*messageFun) (BYTE keyValue);

 …

};

/* 消息处理函数
*/

void messageFunction(BYTE keyValue)

{

 BYTE
i = 0;

 /*
获得焦点元素
*/

 while
( (element .ID!=
currentFocus)&& (i >"移位操作效率更高,我们仅是为了说明问题的方便。试想,如果用户输入是十进制的,power函数或许是唯一的选择了。

总结

  本篇给出了键盘操作所涉及的各个方面:功能键处理、数字键处理及用户输入整理,基本上提供了一个全套的按键处理方案。对于功能键处理方法,将LCD屏幕与Windows窗口进行类比,提出了较新颖地解决屏幕、键盘繁杂交互问题的方案。

  计算机学的许多知识都具有相通性,因而,不断追赶时髦技术而忽略基本功的做法是徒劳无意的。我们最多需要"精通"三种语言(精通,一个在如今的求职简历里泛滥成灾的词语),最佳拍档是汇编、C、C++(或JAVA),很显然,如果你"精通"了这三种语言,其它语言你应该是可以很快"熟悉"的,否则你就没有"精通"它们。

C语言嵌入式系统编程修炼之性能优化篇

使用宏定义

  在C语言中,宏是产生内嵌代码的唯一方法。对于嵌入式系统而言,为了能达到性能要求,宏是一种很好的代替函数的方法。

  写一个"标准"宏MIN
,这个宏输入两个参数并返回较小的一个:

  错误做法:

#define MIN(A,B)  ( A  外部同步RAM > 外部异步RAM > FLASH/ROM

  对于程序代码,已经被烧录在FLASH或ROM中,我们可以让CPU直接从其中读取代码执行,但通常这不是一个好办法,我们最好在系统启动后将FLASH或ROM中的目标代码拷贝入RAM中后再执行以提高取指令速度;

  对于UART等设备,其内部有一定容量的接收BUFFER,我们应尽量在BUFFER被占满后再向CPU提出中断。例如计算机终端在向目标机通过RS-232传递数据时,不宜设置UART只接收到一个BYTE就向CPU提中断,从而无谓浪费中断处理时间;

  如果对某设备能采取DMA方式读取,就采用DMA读取,DMA读取方式在读取目标中包含的存储信息较大时效率较高,其数据传输的基本单位是块,而所传输的数据是从设备直接送入内存的(或者相反)。DMA方式较之中断驱动方式,减少了CPU 对外设的干预,进一步提高了CPU与外设的并行操作程度。

活用位操作

  使用C语言的位操作可以减少除法和取模的运算。在计算机程序中数据的位是可以操作的最小数据单位,理论上可以用"位运算"来完成所有的运算和操作,因而,灵活的位操作可以有效地提高程序运行的效率。举例如下:

/* 方法1 */

int i,j;

i = 879 / 16;

j = 562 % 32;

/* 方法2 */

int i,j;

i = 879 >> 4;

j = 562 - (562 >> 5 >"通常可以提高算法效率。因为乘除运算指令周期通常比移位运算大。

  C语言位运算除了可以提高运算效率外,在嵌入式系统的编程中,它的另一个最典型的应用,而且十分广泛地正在被使用着的是位间的与(&)、或(|)、非(~)操作,这跟嵌入式系统的编程特点有很大关系。我们通常要对硬件寄存器进行位设置,譬如,我们通过将AM186ER型80186处理器的中断屏蔽控制寄存器的第低6位设置为0(开中断2),最通用的做法是:


#define INT_I2_MASK 0x0040

wTemp = inword(INT_MASK);

outword(INT_MASK, wTemp &~INT_I2_MASK);

  而将该位设置为1的做法是:

#define INT_I2_MASK 0x0040

wTemp = inword(INT_MASK);

outword(INT_MASK, wTemp | INT_I2_MASK);

  判断该位是否为1的做法是:

#define INT_I2_MASK 0x0040

wTemp = inword(INT_MASK);

if(wTemp & INT_I2_MASK)

{

… /* 该位为1 */

}

  上述方法在嵌入式系统的编程中是非常常见的,我们需要牢固掌握。

总结

  在性能优化方面永远注意80-20准备,不要优化程序中开销不大的那80%,这是劳而无功的。

  宏定义是C语言中实现类似函数功能而又不具函数调用和返回开销的较好方法,但宏在本质上不是函数,因而要防止宏展开后出现不可预料的结果,对宏的定义和使用要慎而处之。很遗憾,标准C至今没有包括C++中inline函数的功能,inline函数兼具无调用开销和安全的优点。

  使用寄存器变量、内嵌汇编和活用位操作也是提高程序效率的有效方法。

  除了编程上的技巧外,为提高系统的运行效率,我们通常也需要最大可能地利用各种硬件设备自身的特点来减小其运转开销,例如减小中断次数、利用DMA传输方式等。

  
回帖

评论0

首页 | 登录 | 注册 | 返回顶部↑
手机版 | 电脑版
版权所有 Copyright(C) 2016 CE China