还是关于UCOS_II的问题

lxgree2013

还是关于UCOS_II的问题 [复制链接]

/*
*********************************************************************************************************
*                                              uC/OS-II
*                                        The Real-Time Kernel
*
*                         (c) Copyright 1992-2002, Jean J. Labrosse, Weston, FL
*                                        All Rights Reserved
*
* File : uCOS_II.C
* By : Jean J. Labrosse
*********************************************************************************************************
*/
#define  OS_GLOBALS                         /* Declare GLOBAL variables                            */
#include "includes.h"

#define  OS_MASTER_FILE                      /* Prevent the following files from including includes.h */
/* Microchip PIC18xxx specific */
#include "os_core.c"
/* End Microchip PIC18xxx specific */
#include "..\software\ucos-ii\source\os_flag.c"
#include "..\software\ucos-ii\source\os_mbox.c"
#include "..\software\ucos-ii\source\os_mem.c"
#include "..\software\ucos-ii\source\os_mutex.c"
#include "..\software\ucos-ii\source\os_q.c"
#include "..\software\ucos-ii\source\os_sem.c"
#include "..\software\ucos-ii\source\os_task.c"
#include "..\software\ucos-ii\source\os_time.c"

上面的文件名称是 UCOS_II.C，是从Micrium官网上下载的针对PIC18系列的移植范例port，我的问题有两个：
第一：该port里面并没有蓝色标出的这8个C文件，我看了一下主程序所在的TEST.C文件，感觉可能是由于例程里面并没有用到信号量、邮箱、时间管理等等这些东西，所以就没有放进去，不知道猜的对不对？
第二：我想请你注意的是，蓝色标出的书写格式，每个#include后面紧接着都有两个小点，我在工程里编译时候如果去掉这两个点，有会提示该C文件无法加载，看来是有作用的，我想问这是什么用法？是属于C语言范畴吗？
感谢你能看完我的帖子，谢谢！

lr2131

原帖由 lxgree2013 于 2013-1-22 17:30 发表
/*
*********************************************************************************************************
* uC/OS-II
* ...

第一个问题，如果不用到信号量、邮箱、时间管理等等这些东西。只需要在OS_CFG.H这个配置文件里面disable掉这些功能，在编译时，编译器就不会编译这些代码了，效果等效于不包含这些文件。

注意UCOS2是极其具有可裁剪性的。显然裁剪配置用宏的方式是极其安全可靠和移植性的。怎么会在这里用包含文件不包含文件的方法呢，你不觉得这个很不方面吗！！！
出现你说的这种现象，要么是这个被第三方(包括PIC官方)封装过但能正常编译，要么是被别人改了，直接在文件包含中删除了这些（可能不能正常编译）。

第二个问题，这个当然是C语言的范畴。其实真正要说也可以说不是C语言的范畴。你可以理解是C语言的范畴，反正只要你自己和别人知道说的是什么好。
这个其实是预处理的范畴，预处理在很多语言中都有，而且在C语言之前就有。预处理几乎都可以独立成一种小的语言。如果这么说的话，你可以说它不是C语言的范畴。

就算这个是C语言的范畴吧。扯这个是不是没意思。

这里#include后面紧接着都有两个小点指的是回退到上一级目录。也就是说这里给出的是相对路径，不然给出绝对路径的话，移动或拷贝了整个工程，每次都需要修改路径
你去掉这两个点的话，用“”，编译器会先在当前目录下来找这个文件，找不到了就会去编译环境定义的库路径来找，结果当然是找不到，当然说无法加载啊！！！

如果你熟知linux的话，应该知道一个点“.”是指当前目录，两个点是上级目录“..”，好像可以联系这个来理解，不知道对不对。

lxgree2013

出现你说的这种现象，要么是这个被第三方(包括PIC官方)封装过但能正常编译，要么是被别人改了，直接在文件包含中删除了这些（可能不能正常编译）。

我感觉肯定是被别人改了，因为这个例程是从PUDN网站上下载的，原作者移植时是在2002年，那天我在Micrium注册了一个账号，发现PIC的移植范例上根本就没有PIC18的了，就感觉拿手机做例子吧，我需求的是人家早就停产的型号，结果买到了，仔细一看却是翻新机。。。

lr2131

原帖由 lxgree2013 于 2013-1-22 21:56 发表
出现你说的这种现象，要么是这个被第三方(包括PIC官方)封装过但能正常编译，要么是被别人改了，直接在文件包含中删除了这些（可能不能正常编译）。

我感觉肯定是被别人改了，因为这个例程是从PUDN网站上下载的，原 ...

PUDN在PIC的UCOS2上当然不能算是官方网站，还不管是不是PIC18。那上面是别人改好的，他自己能用的，别人拿去能不能用就看这个代码写得怎么样了。所以，估计是被大幅改动过了且没有相关的文档，用起来不知道会不会很麻烦，但不管怎么样，如果能找到官方提供的那当然是最好的，不然以后还会遇到问题，如果自己能独立解决还好，不能的话就卡在那了，出了严重问题除了找原作者，找别人要么很难解决要么不愿意帮你，毕竟都不喜欢维护这种比较个人的东西是不是。

lxgree2013

严重同意！

还是关于UCOS_II的问题 [复制链接]

最新回复

点评

点评

回复沙发 lr2131 的帖子

点评

点评

回复 4楼 lr2131 的帖子

还是关于UCOS_II的问题 [复制链接]

最新回复

点评

点评

回复 沙发 lr2131 的帖子

点评

点评

回复 4楼 lr2131 的帖子

回复沙发 lr2131 的帖子