十一月工作总结

最新推荐文章于 2024-11-30 14:51:46 发布

原创最新推荐文章于 2024-11-30 14:51:46 发布 · 636 阅读

0 ·

CC 4.0 BY-SA版权

文章标签：

#工作总结

工作相关专栏收录该内容

28 篇文章

订阅专栏

本文总结了十一月的工作经验，包括头文件包含问题、C语言作用域规则、调试技巧、编程习惯及语法注意事项等内容，并探讨了软件管理和编译相关的问题。

十一月的工作总结

1. 头文件包含问题

1）交叉包含问题，在*.h中包含了头文件。例如：a.h中include了b.h，而在b.h中include了a.h，则出错，相当于死锁。至于在a.c中include了b.h，b.c中include了a.h，则无此无问题。

2）在包含的头文件中，有多处宏定义了同一个宏名称，但是宏定义不一致，导致在某一处的*.c中使用该宏出现问题。例如：

在a.h中，

#define _ZZP 1

在b.h中，

#define _ZZP 0

在sample.c中，

#include “a.h”

#include “b.h”

这里，sample.c不知应该使用哪个宏。

解决方法：

1.2.1）只include其中一个*.h文件。

1.2.2)若不得不include两个文件，则使用比较猥琐的方法。在sample.c中重新定义该宏，注意该重新定义的宏应该写在上面两个include语句之后。

3）对于一个比较大的project，因为各个module的*.h文件是分散在各个目录下的，按照常规做法，当某个module需要include其他module时，include需要指定这个*.h文件的路径，相当麻烦。现在有两种做法：

1.3.1）这种解决方案中，在每个module下都有个lis文件，我们可以在每个module的lis中将本module将要被外部引用的头文件添加进去。这样当simulator编译时会自动将该lis枚举的*.h文件自动copy到某个INC目录下，该目录即作为所有module搜索*.h的地方。而在引用这些*.h的文件中，include语句只需添文件名。

1.3.2）对于某个要引用外部module的module，在VS2005中，project property->配置属性->c/c++->附加包含目录中将被引用的module加入。这样处理后会体现在*.vcproj文件。同样，在引用这些*.h的文件中，include语句只需添文件名。

2. C语言作用域相关

C语言中，变量声明应该位于局部作用域开头，否则会有sytex errror、“;”、endeclare identifer的error。若必须要将变量在函数开头以外地方声明，那么另外用{}建立一个作用域，且变量声明位于局部作用域开头。

3. Debug相关

3.1）打印log信息。通常可在函数入口处打印传入参数，函数结束处打印返回值等。对于一些开关语句，或是if/else语句，若有必要，也可打印。打印时加上函数名等一些特有的标记可以在debug时快速定位。

3.2）debug的一般步骤。首先，先理清code的逻辑，目测下确认与逻辑无关。接着，用工具debug。注意不能太过依赖工具，否则debug效率会降低。

3.3）一步一个脚印原则。每编完一个模块即进行验证，不要等编了一堆代码才验证，到时debug定位是个问题。当然也不能过于频繁验证，这就是个编程艺术问题了。

3.4）对于simulator上编译断点不能命中的问题，可用从以下方面排查：1）代码是否已经编译过，但是仍未将动态库copy到simulator那边。2）simulator的进程是否已经绑定了进程。3）进程绑定方式是否为native。

4. 编程习惯相关

函数传入参数时，若类型不一致，要用强制类型转换。否则，simulator虽然编通过，arm不一定编通过。放到非手机开发上，保证传入函数的变量类型与函数形参一致，是个好习惯。

5. 语法相关

5.1)宏定义的的使用。

#define _ZZP 1

//… …

#ifdef _ZZP

//… ….

#else

//… …

#endif

6. 编译相关

对于静态module，在真机编译时，需要编译AMSS。查看静态模块是否编译通过，可以查看/build/ms/bin/#project version#。静态module真机编译完后，烧入真机需要做：1）software download->CEFS，烧系统。2）software download->multi image，烧资源。