#pragma CODE_SEG __NEAR_SEG NON_BANKED/#pragma CODE_SEG DEFAULT

简介:   在写到SCI 中断发送,中断接收程序的时候,在程序中会出现#pragma CODE_SEG __NEAR_SEG NON_BANKED/#pragma CODE_SEG DEFAULT,这两句话在程序中具体的代码如下: 1 /****************************...

  在写到SCI 中断发送,中断接收程序的时候,在程序中会出现#pragma CODE_SEG __NEAR_SEG NON_BANKED/#pragma CODE_SEG DEFAULT,这两句话在程序中具体的代码如下:

 1 /*************************************************/
 2 /*               串口中端接受函数                */
 3 /*************************************************/
 4 #pragma CODE_SEG __NEAR_SEG NON_BANKED     //将接下来的代码(一般是中断函数)置于非分页区
 5 interrupt void recievedata(void) {
 6   data_recieve = SCI_recieve();
 7   if(data_recieve == 'O') {
 8     SCI_send('Y');
 9     LEDCPU = LED_ON;
10   }
11   if(data_recieve == 'C') {
12     LEDCPU = LED_OFF;
13   }
14 }
15 #pragma CODE_SEG DEFAULT
Interrupt_recieve

  总的来说这两句话是这样的意思:

#pragma CODE_SEG __NEAR_SEG  NON_BANKED //中断函数置于非分页区内代码段
#pragma CODE_SEG DEFAULT //后续代码置于默认区域内

  freescale16位的板子中断向量位是16位,中断函数只有被置于非分页区内才能被寻址到,这就是第一行的作用。由于单片机内部非分页区大小有限,非中断函数一般置于分页区内,最后一行即为此作用。

  这里要从FLASH分页和非分页的区别说起, FLASH里非分页工作机制如下:
  FLASH一共为128K,一页是16K,那么应该有8页才是,但是实际只有6个分页。有2个非分页放在4000-7FFF,和C000-FFFF两个逻辑地址窗里。那么,当程序的寻址在64K之内(2^16=64K,16位机的寻址能力是64K)时,就不用分页了,直接使用那两个非分页的数据。实际上,3E页 3F页是可见的,其实他们就是那2个非分页的映射。因此,使用非分页FLASH,就不须设置PPAGE寄存器,直接使用逻辑地址即可。

  这点我们可以从以下看出:

/* non-paged FLASHs */
      ROM_4000      = READ_ONLY     0x4000 TO   0x7FFF;
      ROM_C000      = READ_ONLY     0xC000 TO   0xFEFF;
PLACEMENT
      NON_BANKED,    INTO ROM_C000/*, ROM_4000*/;

 

  NON_BANKED一般位于0xc000-0xffff区域,而这个区域是16位单片机cpu可以直接寻址的区域,那么中断函数放在 NON_BANKED里,就可以把函数放在64K的寻址程序段中。这么一来,进中断就方便多了,效率也高很多(因为中断函数要求的就是实时性)...而 __NEAR_SEG告诉编译器函数放在固定页中,只有固定页中的函数才能访问其他页的数据,同时CODE_SEG定义了一个代码段.

相关文章
|
JavaScript 容器
JS实现瀑布流布局
JS实现瀑布流布局
|
安全 网络协议 算法
RTP、RTCP、RTSP 概念
<p style="line-height: 28px; margin-top: 0px; margin-bottom: 10px; padding-top: 0px; padding-bottom: 0px; color: rgb(51, 51, 51); font-family: 'Hiragino Sans GB W3', 'Hiragino Sans GB', Arial, Helve
8114 0
|
网络协议 PHP Python
推荐一些socket工具,TCP、UDP调试、抓包工具 推荐一些socket工具,TCP、UDP调试、抓包工具
还记得我在很久很久以前和大家推荐的Fiddler和Charles debugger么?他们都是HTTP的神器级调试工具,非常非常的好用。好工具能让你事半功倍,基本上,我是属于彻头彻尾的工具控。 假如有一天,你写“传统”的PHP有些累了,想玩玩socket了,搞搞python、NodeJS、GO之类的新兴语言或框架(当然我不是说这些语言不能写web),或者干脆就用PHP吧,事实上PHP5.
18236 0
|
开发框架 Ubuntu Linux
【Matter】esp-matter开发环境搭建
【Matter】esp-matter开发环境搭建
781 0
|
存储 Linux 开发工具
rockchip的yocto编译环境的搭建
rockchip的yocto编译环境的搭建
1290 0
rockchip的yocto编译环境的搭建
|
XML 存储 Ubuntu
RK3568开发笔记(五):在虚拟机上使用SDK编译制作uboot、kernel和ubuntu镜像
buildroot虽然灵活,但是基于实际情况,本身是侧重驱动和应用定制开发的只定制一次文件系统投入有点多,还不如直接ubunt自己交叉编译依赖库,做一些库的移植裁剪。   于是本篇就使用ubuntu系统了,至于其他库自己下源码在宿主机交叉编译号后,再拷贝过去或者直接在板子上编译也行(只是会比较慢),但是意义不大,因为开发过程肯定是用宿主机,不然核心板编译太慢,在编译上会花费不少可以省去的时间。
RK3568开发笔记(五):在虚拟机上使用SDK编译制作uboot、kernel和ubuntu镜像
|
IDE 搜索推荐 Java
STM32CubeIDE的一些使用技巧
STM32CubeIDE的一点使用技巧
2386 0
|
JSON API 数据格式
Restful API 的设计规范
Restful API 的设计规范 1. URI URI规范 资源集合 vs 单个资源 避免层级过深的URI 对Composite资源的访问 2. Request HTTP方法 安全性和幂等性 复杂查询 Bookmarker Format Content Negotiation 6. Response分页response 7. 错误处理 8. 服务型资源 9. 异步任务 10. API的演进 版本 URI失效 11. 安全 参考文档 本文总结了 RESTful API 设计相关的一些原则,只覆盖了常见的场景。
4039 0

热门文章

最新文章