高温传感项目调试日记
2015-6-27
1.Link to sources
新建工程路径中既没有源代码，也没有库，源代码和库在系统文件夹里
如果这时修改库或源代码，系统文件夹中的也相应修改。等到下次新建或者其他工程要包含这个库时，可能就不是原来的版本
2.Link libraries and copy sources
新建工程路径中有源代码，没有库，库在系统文件夹里
3.Copy contents
新建工程路径中既有源代码，也有库
比较推荐2或3
2015-6-29
第一次用example编译，发现提示有如下问题
Couldn't reserve space for cygwin's heap
去silab的线上找技术支持，发现有人遇到相同的问题，具体可参考下面链接
出错的原因大概是一个dll文件没有更新，他们也给出了一个新的dll，下载地址：http://download.csdn.net/detail/u011388550/9013065
STK3300左下角的开关忘记拨了，导致下载程序的时候，系统提示这个设备不兼容。
因为开关没有拨，MCU是没有上电的，但Jlink是上电的，系统可以识别出Jlink，但却识别不出设备。
2015-8-15
最近调试串口，发现只要一进串口中断，程序就卡死，后来发现，罪魁祸首是中断处理的函数名写错了。中断一直在寻找那个函数，又一直找不到。
其实这个中断函数是从官网上down下来的，可能是lib的版本不一样了，串口UART都需要改成USART。
2015-8-16
大概隔了一个星期没有动STK3300了，这次拿起来用，发现电脑识别不出Jlink了，下载不了，调试不了，回想一下，大概是有一次把泡椒水撒在了USB口和Jlink的地方，板子时好时坏的，撑了几次，终于一直都不行了。于是寻找解决方案，最简单粗暴的方法就是TB重新来一块，但TB的价格比较贵，便宜的也要250左右，官网卖的价格是29.9美元，但这个价格在中国享受不到，国内买要60美元，还不如上TB，TB卖家也说了，他们也是要国外订货，再发来这边。看来小壁虎的热门程序远不如STM32啊。后来发现有一种调试方式是JlinkOB，就是onboard，且SWD模式下，只需要4根线就可以调试了，STK3300留了相应的外置DEBUG接口。JlinkOB成功工作，但没过多久，JlinkOB又不行了。于是我又需要来回倒腾，重装Simplicity Studio、重装驱动、不断重启，好像都不是治本的方法，虽然一时可以调试了，但拔下来之后，过段时间再插上去，就又不行。
后来发现，可能是Jlink驱动的问题，我电脑上有2个版本的驱动，一个v4.8，一个v5.0，v5.0的是可以用的，猜测可能是因为两个版本的驱动的问题。
2015-8-22
调试串口的时候发现一个问题，已发送的index竟然比数据缓冲区中等待发送的index还要大1，导致程序混乱.
刚开始认为：出现这个问题的原因是串口的发送数据缓存区太小，只有512byte，程序中会一次将488byte放入数据等待区发送，这个buffer是循环存储的，如果发送得过慢，后面的会把前面的覆盖掉。
后来经过实践发现，这个不是缓存区大小的问题，而是我边组帧边发送的问题，我组一帧(8byte)就发一次，这样容易出乱，至于是怎么出得乱，debug了一天也没找出问题，如果可以用print函数调试，应该会比较容易定位出问题。出错的原因不知道，但如何修改还是很容易的，就是一次把所有的数据帧都组好，然后一起发送，比如一次要发送61帧，那么就是488byte，将488byte组好之后，一起发送，这样就不会出现上述问题了。
2015-9-2
今天看了EFM32中的LCD Driver，之前都没有接触过片上外设LCD驱动，且LCD都是集成好的，只要单片机往LCD里写简单的命令就可以了。这里要了解的，是更直接的驱动。
在上图中，当不通电压时，液晶的排列是渐变的，此时入射光的偏振方向会一点一点地改变，到达反射层并能成功地出去，这时，这一段就是透明的，可以说是关闭显示。
在下图中，当通电时，液晶会整齐排列，入射光的偏振方向与反射层的偏振方向正交，导致无光射出，这时，这一段呈现出黑色，可以说是开启显示。
那么要点亮一段LCD，只需要两个电极即可，也可以是两个引脚
这里给的电压必须是交流电，这跟数码管不同，若给直流电的话，液晶的排列只会持续很短的时间，因为直流电会影响液晶的工作，所以我们应该给一个RMS为0的信号。下图是两段LCD的工作原理，这种工作方式成为静态工作方式，有n段LCD，就需要n+1个引脚，缺点是引脚量太大；优点是省电，显示的对比度好。
下图给出的是另一种工作方式：复用工作方式，这种方式可以减少引脚，可以连接的LCD的段数是com和seg的乘积。这时，电平的模式就不能像静态方式一样是两电平，而是要多电平，这时LCD的off也只是相对的，相对on来说，波动小，显示不明显。如果段数增加，要想保持显示效果，那么就需要增大电压、增加电平数，那么相应地就会增大能耗
EFM32TG840中有8个com，24个seg，那么相应地就有8*24bit的寄存器，将该寄存器设置为1，外设就会配合产生方波波形，去点亮这个segmengt。com与seg具体对应LCD里的哪一段，这个需要看LCD的文档。
2015-9-06
今天发现要使用板载的Jlink必须要连上JlinkOB小模块（后来发现不是这个问题，而是拨码开关接触不好，开关接上了，JlinkOB就会亮；开关没接上，JlinkOB就不会亮。会让人误以为是JlinkOB的原因）
2015-9-8
今天把JlinkOB小模块用SEGGER J-link Configuration V5.02a 更新了一下"Update firmware of selected emulators"，然后这个小模块就可以用于调试了（用Simplicity Studio调试，用Keil是一直可以调试的）。
奇怪，之前刚买来的时候也是可以的，后来不知道为什么就不可以了。
后来用了几次，本来可以的，就又不可以用了，很是奇怪。
现在是用Keil调试，但感觉Keil没有Simplicity Studio好用
2015-9-12
想在Simplicity Studio上面调试程序，但自己做的板子只能用JlinkOB来调试，而JlinkOB只能在Keil上面使用，这个就恨麻烦，这周搞了一个星期的eclipse下编译cortex都失败了，还下了许多软件，Emblock、CoIDE，都感觉不好用，还试着刷Jlink的固件版本，但刷完后的Jlink不能使用，最后还是在Keil上写程序了，但明显感觉Keil没有eclipse好用。
2015-9-14
在924用示波器，感觉924没有接地，示波器使用一段时间，探头的地线就会放出静电。这个静电就把EFM32的OPA P2的引脚烧掉了，通过放大器进入ADC的D值是一直不变的。
2015-9-22
word与硬件系统有关，若是32位机，1word=4bite；若是16位机，1word=2byte.
在Keil编译完成后，会给出程序的大小：
Program Size：Code=10938 RO-data=446 RW-data=88 ZI-data=3608，这里每个数字的单位是byte
Code：程序代码部分
RO-data（ReadOnly-data）：程序定义的常量，const
RW-data（ReadWrite-data）：已初始化的全局变量
ZI-data（ZeroInitiate-data）：未初始化的全局变量
Code、RO-data、RW-data占用Flash
RW-data、ZI-data占用RAM
MCU初始化时，由于RAM是掉电不保存的，RAM刚开始是空的，RW-data从Flash拷贝到RAM，Flash是掉电保存的，所以程序中的一切信息都保存于Flash中
在移植uCOS到EFM32TG840F32（Flash：32K；RAM：4K）中时，原本每个任务的堆栈是256byte，共20个任务，于是编译不通过，提示错误RAM不够
将任务数量减小到3，任务堆栈减小到16，编译通过，可以看出这时的RAM=3608+88，已经接近4K
从这个ucos可以看出，一个ucos大概需要10K的Flash和4K的RAM，所以在我这个EFM32项目上用ucos不太好，移植了系统，还有自己的程序需要占用空间。
2015-9-30
在Modbus的函数中将数据从[512]增大到[640]，程序就会跑入HardFault_Handler死循环，可能是堆栈太大，后来改成不在函数中定义数组，而是将数组定义成static，放在全局变量区，也实现了对本文件的可视，对全局的隐藏
导致HardFault_Handler的原因一般是：
1. 数组越界
2. 野指针
3. 未初始化硬件却开始操作，或无中断服务函数等
2015-10-1
有时候在编译QT时，会莫名其妙地提示“无法解析的外部符号”，若确定代码没有问题，那么我们需要手动删除目录下的debug文件夹，然后重新构建项目。
客户希望线性化的数据可以不要每次都手动输入，能把目录下的Excel导入就方便很多。于是找了许多excel在QT下的库，最后看到一个BasicExcel（http://www.codeproject.com/Articles/13852/BasicExcel-A-Class-to-Read-and-Write-to-Microsoft），这是一个有关excel操作的类，且只有一个cpp和一个hpp，非常简洁，操作可参考上面那个网址，也可以参考http://www.linuxidc.com/Linux/2011-06/37581.htm
