自从我（原作者）去年被调到了嵌入式组，终于和以前研究生阶段搞的开发经历一致了。但以前用的是ADS工具，还有用Linux平台上的交叉编译工具链，还有看linux 内核的驱动代码。
现在搞起对日外包了。日本人不爱用linux，凡事总是搞出自己的一套。现在用的ut-kernel(看成一个RTOS就好), 开发工具则有RVDS,DS-5，MTK和IAR， 硬件调试器有Dstream， Realview ICE。
现在对应的是富士通半导体部门，做的MCU（基于arm cm3,cm4, ca5核的富士通芯片） 的软件开发测试。
本来自己的想法是搞搞嵌入式，熟悉下硬件东西，这样可以加深的我的底层编程功底。
以下是几个阶段的工作感悟
1、ut-kernel/FA5 测试修复BUG工作：
日本人做的ut-kernel属于嵌入式RTOS范畴，这块同类的产品有uc/os, vxworks等，共同特征是高度可裁减，想塞到片内那有限的容量内。还有实时性好吧。实时性不仅表现在可抢占式进程调度，还有快速响应中断的能力。
RTOS的设计毕竟和通用操作系统（linux）的设计思想还是有很大的差别的。感觉这个领域更适合微内核结构的发挥，宏内核结构如linux可裁剪性方面是个缺点。
这个ut-kernel算是代码量比较简单，里面的修复BUG工作我觉得也不难，期间有timer相关的BUG，最后一看发现timer相关的代码根本没改造。
印象深刻的是后期做性能测试，对FA5和FM3芯片做比较时，因为两个各基于Cortex-m3和cortex-a5架构，架构不同，发现这里面还是很有意思的。一开始FA5的性能没有发挥出来，找到原因，cache没打开。高档次的CPU是要靠cache发挥威力的。
于是查找芯片手册，正确地初始化了cache并打开它。后来又发现还有些功能如指令分支预测等这些也得打开，于是又修改了相关寄存器。完了，感觉FA5的性能比以前好了很多。
于是对CM3和CA5的架构差别方面，我又充满了兴趣。我觉得知道这些，对以后并行多核程序开发，物联网领域的一些东西都有帮助。
感觉FA5这种档次高的芯片应该用到手持设备开发中去。那些工控级别的应用应该是FM3这类51单片机取代者的天下。ut-kernel是配着FM3芯片开发的，感觉配上FA5的话，ut-kernel架构就应该进行大改变了，或者直接用linux等内核比较好。
期间做了个初始化外接的DDR芯片工作，我们直接从UBOOT社区那边拷过来该芯片的初始化代码。然后针对该代码做成一个具有初始化DDR单一功能的AXF可执行文件。以此来方便我们测试。
还有测试中间差点闹出来一个大问题，当时日方客户见我们的初始化DDR代码中还残留有GPL版权信息，他们大怒，拷贝代码惯了，对版权从来没怎么看重。日本人对这块比较看重，听说在日本下载盗版音乐好像要被起诉。
下来经过这场事，我们对版权方面的东西特别敏感，搞好代码后，首先要在代码包中扫描版权信息。
2、micro.NET framework 在FM3平台上的移植
这个项目做起来还是非常有发展前途的。看看现在物联网炒得多么火热就知道了，可惜做了不到一半，日本人就给咔嚓掉了。不是我们做的不好，而是他们又想让我们做别的是事情了。
做对日外包就是这样，没自主权，得按别人指令办事。
这个项目的做的过程中，终于我对串口，timer，GPIO移植熟悉了很多，自己也做了些特性改造。而且我也会根据开发板的板子布线原理图以及芯片手册来写一些简单的驱动代码了。
还有对scatfile，分散加载也熟悉了很多，对于MDK, RVDS，DS-5调试工具以及ICE,Dstream等硬件调试器的灵活运用也掌握了不少。
3、ut-kernel/M3及M4F的测试
我亲自参与并熟悉了怎么在片外再扩接一个SRAM，因为我们的测试代码体积还比较庞大，无法放到片内中。想想自己以前本科学电子的，那时对示波器，万用电表掌握的特别熟练。现在却全部都忘完了（因为后来一直都搞的是纯软件）。看到项目组同事在使用示波器时，我想到自己还是有基础的，快速学习能力还是有的。
因为做驱动开发，不可避免要用到示波器等这些设备。可惜当时外接SRAM硬件并没多大问题，而且示波器等还是借的，所以我没太多机会熟悉这些硬件测量设备。
想想自己本科数字电路，模拟电路等一些硬件课程，实验课程都学的不错的。哎，如果我这些功底都恢复并加强的话，那么自己的底层软件编程也会加强不少，最主要的是编程视野也会相当开阔。毕竟最高层的软件算法分析设计，我研究生阶段都掌握了。
没事以后会有机会继续窥探到这一领域的。
可惜外接ram又不稳定，后来我们又不得不移到片内进行测试。这时为了能把程序放到片内去跑，就要对ut-kernel里面占用内存空间的地方进行剪裁了，好在ut-kernel都是可裁剪的，在我们裁剪完之后，发现放到片内ram中测试比片外ram稳定多了。
还有对嵌入式系统的软件BUG调试也有所掌握，感觉嵌入式里面的软件调试时，发现东西跑飞了。这时可以有多个途径查找。也许是没禁掉看门狗，或者那些pend_sv中断在内存中根本没有初始化正确, 或者中断向量表被冲掉了，或者对照着汇编指令看看寄存器状态有没有正确。要卡住出问题的地方来进行多方面原因的判断调查。另外也要结合map文件，看看地址链接和加载得是否都正确，有没有越界。
在测试M4F FPUT时，曾经发现一个诡异现在，一些调用子函数换个先后顺序去执行时，就崩溃了，再换过了就不崩溃了。这时我调查了下，发现崩溃前代码执行时用的栈遭到了破坏。
具体我往前推，发现在调用某个API返回之后，就会破坏掉待返回的正确栈上的值。具体再调查时，发现是执行某条汇编指令时，栈遭到了破坏。不过这时候这个调查上面中止了，事情实在太多了又去做其他事情了。不过我相信只要掌握了方法和本质，这些问题都只是时间问题。
‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧ END ‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧‧
