另外一种BitBand操作的方式 - 让IDE来帮忙算地址

要使用Bitband来访问外设,一定要得出对应的映射地址。人工计算肯定是不靠谱的,而且也没人想这么干。因此可以通过Excel,拉个列表来计算,想想,这也是一个不错的招数。但是后来想想,还是嫌麻烦,毕竟还是需要建立表格,填入公式,从reference manual中找寻寄存器的地址。

后来看到EFM32的头文件,想到,既然头文件里已经把所有的寄存器的地址都制定好了的,为什么不直接拿来用的?利用IDE编译器帮我们计算呢?想来这也是比较简便的一条路子了。于是马上动手。

经过半个小时的奋斗,终于ok了。为什么要经历这么久的时间,主要是*号,()号,实在是有点多啊。。指针,地址,指针值来着。。各位看官就不需要重复这个过程了。

举个例子,想要通过bitband来控制PD7的输出,则宏定义如下:

#define SCK_Port        gpioPortD

#define SCK_Pin         7

#define SCK                (*((uint32_t *)(BITBAND_PER_BASE + (((uint32_t)&(GPIO->P[SCK_Port].DOUT) - PER_MEM_BASE) * 32) + (SCK_Pin * 4))))

在主函数中操作如下:

int main(void)

{

CHIP_Init();

CMU_ClockEnable(cmuClock_GPIO, true);

GPIO_PinModeSet(gpioPortD,7,gpioModePushPull,1);

while(1)

{

unsigned long Delay = 1000000;

while(Delay--);

SCK = 1;

Delay = 1000000;

while(Delay--);

SCK = 0;

}

}

通过查看IAR的汇编窗口,也能看到汇编指令也只需要3条而已。。

时间: 2024-10-09 20:54:44

另外一种BitBand操作的方式 - 让IDE来帮忙算地址的相关文章

第二种BitBand操作的方式 - 让IDE来帮忙算地址

要使用Bitband来訪问外设,一定要得出相应的映射地址.人工计算肯定是不靠谱的,并且也没人想这么干.因此能够通过Excel,拉个列表来计算.想想,这也是一个不错的招数.可是后来想想,还是嫌麻烦,毕竟还是须要建立表格.填入公式,从reference manual中找寻寄存器的地址. 后来看到EFM32的头文件.想到,既然头文件中已经把全部的寄存器的地址都制定好了的,为什么不直接拿来用的?利用IDE编译器帮我们计算呢?想来这也是比較简便的一条路子了. 于是立即动手. 经过半个小时的奋斗,最终ok了

oc/object-c/ios哪种遍历NSArray/NSDictionary方式快?测试报告

做app的时候,总免不了要多次遍历数组或者字典.究竟哪种遍历方式比较快呢?我做了如下测试:首先定义测试用宏: ? 1 2 3 4 5 6 7 8 9 #define MULogTimeintervalBegin(INFO) NSTimeInterval start = [NSDate timeIntervalSinceReferenceDate];\ NSTimeInterval duration = 0;\ NSLog(@"MULogTimeintervalBegin:%@", IN

TI_DSP_SRIO - 两种SRIO操作模式

DSP SRIO协议的逻辑层定义了操作协议和相应的包格式.DSP上SRIO支持的逻辑层业务(数据发送方法)主要是直接IO/DMA(Direct IO/ Direct Memory Access)和消息传递(Message Passing). ?直接IO/DMA模式是最简单实用的传输方式,其前提是主设备知道被访问端的存储器映射.在这种模式下,主设备可以直接读写从设备的存储器.可以硬件直接实现. ?消息传递模式则类似于以太网的传输方式,它不要求主设备知道被访问设备的存储器状况.数据在被访问设备中的位

四种保存数据的方式

转载地址:http://blog.csdn.net/tianyitianyi1/article/details/7713103 在iOS开发过程中,不管是做什么应用,都会碰到数据保存的问题.将数据保存到本地,能够让程序的运行更加流畅,不会出现让人厌恶的菊花形状,使得用户体验更好.下面介绍一下数据保存的方式: 1.NSKeyedArchiver:采用归档的形式来保存数据,该数据对象需要遵守NSCoding协议,并且该对象对应的类必须提供encodeWithCoder:和initWithCoder:

Adnroid 两种下拉刷新 方式的实现 sina刷新 gmail刷新

sina刷新 这种下拉刷新的方式是比较简单的.上个图: 这种刷新方式的思路是这样的: 首先是需要一个HeaderVIew也就是刷新时头部所显示出来的数据.这个view的布局随你,长啥样自己定夺. 其他不是特别重要,重要的是用户触摸事件的捕捉,看到github上的大神的一些方法是比较正规的,我就自己用自己的方法尝试,主要是捕捉到用户的点击事件来计算用户所触摸到的位置然后来更新头部布局的位置. 这个重要的代码贴出来: case MotionEvent.ACTION_MOVE: currentY =

Objective-C:三种文件导入的方式以及atomic和nonatomic的区别

一.三种文件导入的方式比较: 类的前项声明@class.import.include: 1.采用@class 类名的方式,它会告诉编译器有这么一个类,目前不需要知道它内部的实例变量和方法是如何定义的,后面会告你,现在你就可以直接使用它,节约程序编译时间: 2.采用import方式,能避免重复导入同一类,它导入的不但这个类的所有的内容,而且使用它之前,编译器必须先对类的所有内容走一遍,就是先做预编译处理,这样比较耗费程序编译的时间. 3.采用include方式,不能避免重复导入的问题,但是它用在C

java.io几种读写文件的方式

一.Java把这些不同来源和目标的数据都统一抽象为数据流. Java语言的输入输出功能是十分强大而灵活的. 在Java类库中,IO部分的内容是很庞大的,因为它涉及的领域很广泛:标准输入输出,文件的操作,网络上的数据流,字符串流,对象流,zip文件流. 这里介绍几种读写文件的方式 二.InputStream.OutputStream(字节流) //读取文件(字节流) InputStream in = new FileInputStream("d:\\1.txt"); //写入相应的文件

http 3种web会话管理方式

http是无状态的,一次请求结束,连接断开,下次服务器再收到请求,它就不知道这个请求是哪个用户发过来的.当然它知道是哪个客户端地址发过来的,但是对于我们的应用来说,我们是靠用户来管理,而不是靠客户端.所以对我们的应用而言,它是需要有状态管理的,以便服务端能够准确的知道http请求是哪个用户发起的,从而判断他是否有权限继续这个请求.这个过程就是常说的会话管理.它也可以简单理解为一个用户从登录到退出应用的一段期间.本文总结了3种常见的实现web应用会话管理的方式: 1)基于server端sessio

FMX有两种消息处理的实现方式,一种是用TMessageManager来实现自定义的消息,另外一种象TEdit中的实现,直接声明消息方法

看FMX代码,发现有两种消息处理的实现方式,一种是用TMessageManager来实现自定义的消息,另外一种象TEdit中的实现,直接声明消息方法. 早前,看过文章说TMessageManager的用法,可用到的时候,又找不到,只好自己动手. 我的应用场景是这样: 当前的Frame弹出一个对话框Frame,当操作对话框的时候,想让当前的Frame跟着应响,让用户看到操作的结果,如下图,点大中小字体,后面的题目的字体会跟着变化: 参考fmx的代码,试着用消息机制实现了: 1.声明消息类: typ