keil

后文rtt代表RT-Thread 在官网公众号中，看到rtt发布了rtt nano，这个就很轻量级的rtos内核，把多余的驱动都裁剪了，因此移植工作量小，可以哪来学习一番，体验rtt之美 rtt现在也集成到cubemx5.0以上的平台，类似于freertos中间件，这个做法，倒是有点类似于大厂的风格了，看好rtt。 在keil5中，有两种方法可以移植rtt nano。 前提条件是：cubemx生成一个最小的裸机led系统。 MRTE的方法， 1、这个需要下载pack包RealThread::RT-Thread，keil有很多类似的第三方包，有ucos，freertos（这个比官网更新的都快，厉害了我的keil）rtx还是keil自带的免费rtos，这个我之前也有移植文档，也是很方便的。 安装好之后，左上方的写的小正方形，里面的rtos里面有很多选项。之前一直找不到， 是rtt的技术支持微信亲自指点的。因此需要注意。 我的选择如下： 其他的你也看到， 集成有很多rtos。 2、之后编译，会出现很多错误（重复定义之类），可以看到rtt的官网上，已经提到了，需要把很多中断Handler()注释掉，因为rtt自己已经实现了很多中断函数。 3、添加<rtthread.h>，把hal_delay()替换成rtt的延时函数，再次编译，即可一次成功。 源文件移植方法： 1、在现有的裸机工程中

Keil C是非常优秀的C51编译器，可能是最好的C51编译器，提供各种优化模式，对变量的优化和地址安排做得非常好。这是用C语言写代码的好处之一，如果用汇编写，得费一大番功夫给各个变量安排内存物理地址，还得时刻记住哪些地址的内存单元是已经分配了，新增加的变量就不能占用那些已经分配了的单元，以免产生内存交叠冲突和溢出。我一直非常信赖Keil C51的编译结果，在我的印象里，它对内存的分配是完美的，只要代码用它编译时没有报告任何warning和error，代码运行时不可能内存冲突或溢出的现象。 但，今天发生的事情证明我错了。 手头上有个产品的代码，代码量很大。程序跑起来的效果不大好，因此打算把代码优化一下。代码量越大，通常可优化的地方也越多。对8051来说，访问芯片内部的data区（0~7FH）内存速度是最快的，直接访问，一条指令就能读写，而idata区（80H~FFH）虽然还是内存区，但由于地址分配上跟特殊寄存器SFR重合，只能间接地址访问，两条指令才能读写，速度稍慢点，而外存xdata区（0~7FFFH）必须使用DPTR指针才能访问，速度是最慢的。很明显，优化的原则就是尽量把频繁读写的变量优先安排在data区，然后是idata区，最后才是xdata区。 当我做完变量手工优化工作后，把编译模式设为SMALL，这样C51编译器会自动把那些我没手工指定存放区的变量优先安排进data区

Keil编译时提示“main.c(16): error C129: missing ‘;’ before ‘num’” 折腾了很久才知道是前面的“typedef unsigned char u8;”语句把“typedef”漏掉了，而错误提示中的行号16正是程序第一次用到“u8”的那一行。这里虽然提示缺少分号，但实际上与分号没关系，需注意。 来源： CSDN 作者： weixin_46022757 链接： https://blog.csdn.net/weixin_46022757/article/details/103539654

#define TEMP 0x01u #define TEMP1 0x02u u 就表示unsigned，ul 就表示 unsigned long型，也就是无符号的意思。常用在非符号的场景，一是为了防止编译器将它作为有符号数字进行处理，显式声明，以防万一；二是防止编译提醒符合位改变等情况。 举例：比如ox8000 这是一个16位的数，如果不加u，有的编译器认为它是个负数，然后右移这个数的时候，编译器就会提醒符号位改变，就从负数变成了正数。如果加上u，0x8000u，直接声明这是一个无符号的16位数，随便怎么移动都没事，就相当于 usigned short 。 其实这和在数字末尾加f，加l等的作用是类似的。 来源： CSDN 作者： m0_37141848 链接： https://blog.csdn.net/m0_37141848/article/details/103536276

ARM程序的组成 此处所说的“ARM程序”是指在ARM系统中正在执行的程序，而非保存在ROM中的bin映像（image）文件，这一点清注意区别。 一个ARM程序包含3部分：RO，RW和ZI RO是程序中的指令和常量 RW是程序中已初始化变量 ZI是程序中未初始化或初始化为0的变量 由以上3点说明可以理解为： RO就是readonly， RW就是read/write， ZI就是zero ARM映像文件的组成 所谓ARM映像文件就是指烧录到ROM中的bin文件，也成为image文件。以下用Image文件来称呼它。 Image文件包含了RO和RW数据。 之所以Image文件不包含ZI数据，是因为ZI数据都是0，没必要包含，只要程序运行之前将ZI数据所在的区域一律清零即可，包含进去反而浪费存储空间。 Q：为什么Image中必须包含RO和RW？ A：因为RO中的指令和常量以及RW中初始化过的变量是不能像ZI那样“无中生有”的。 RM程序的执行过程 从以上两点可以知道，烧录到ROM中的image文件与实际运行时的ARM程序之间并不是完全一样的。因此就有必要了解ARM程序是如何从ROM中的image到达实际运行状态的。 实际上，ROM中的指令至少应该有这样的功能： 1. 将RW从ROM中搬到RAM中，因为RW是变量，变量不能存在ROM中。 2. 将ZI所在的RAM区域全部清零