S418 发表于 2011-7-6 18:33:12

嵌入式学习之移植篇

最近狂搞跨平台移植，小到小型游戏，大到文件系统、GUI以及OS，这里拿文件系统作为例子，主要阐述一个观点：编译器是死的，人是活的！


例 1

http://cache.amobbs.com/bbs_upload782111/files_42/ourdev_655195VIE0DY.jpg
1 (原文件名:1.jpg)
上图为FatFs文件系统常用子函数，主要功能检查文件系统是否存在。其中"DWORD temp;”为本人额外定义，也就是说后两个if语句中"temp="也是原先没有的。当我完成前面所有移植工作，测试文件系统是否可用时，问题就出来了，挂载磁盘返回正确参数，但打开不了磁盘，测试程序死等，百般纠结，通过各种方法最终锁定问题根结所在，就是后两个if语句无法正确执行，根据以往经验立刻推断问题归咎编译平台不同。


例 2

http://cache.amobbs.com/bbs_upload782111/files_42/ourdev_655196F053M1.jpg
2 (原文件名:2.jpg)
这个问题更为恶劣，文件系统移植完成，确认文件系统可用，并且前一天还在此文件系统上实现各种应用程序，第二天重新编译，发现显示屏显示不对劲，最下边稍微花屏，然后整个显示就乱了套，完全不符合本人的意愿，代码丝毫没有改动，显示却差之万里。首先确认故障原因不在硬件，然后，屏蔽所有显示子函数，花屏现象依然存在，真是郁闷。不过，此类问题不是一回两回碰到过，于是，对文件系统翻箱倒柜，确认问题出在上图所示子函数（该函数功能是读磁盘），其中"void *buff'上，传递给此参数的是一个数组名，此数组为

http://cache.amobbs.com/bbs_upload782111/files_42/ourdev_655197FA3XRO.jpg
3 (原文件名:3.jpg)
其中"static"是后面加上去的，起初，由显示屏花屏判断问题跟底层显示驱动有关系，于是开干，往底层找，对底层很熟，三下五除二，找出了原因，显示屏显示要在内存开辟缓存，缓存为二维数组，如下图示

http://cache.amobbs.com/bbs_upload782111/files_42/ourdev_655198EIZ0ZG.jpg
4 (原文件名:4.jpg)
花屏必定是buf数组跟缓存数组有叠加区域，为了把这两个区域强行隔开，buf数组加上关键字"static"，问题迎刃而解！


总结：编译器类别纷繁多样，不存在一款万能的编译平台，它只是模拟人类的思维，按照我们预定的规则替我们办事，但往往不能尽如人意，跟我们的思维总会有差距。所以，编译器只是依照预定的规则给我们办事，规矩是死的，人是活的！

tedden 发表于 2011-7-6 18:51:34

楼主研究的很仔细啊。咨询下楼主那个文件系统buf数组为啥会和LCD_BUFFER叠加起来呢？

S418 发表于 2011-7-6 19:01:38

回复【1楼】tedden
-----------------------------------------------------------------------

这也是本人依据现象做出的推断而已，估计编译器自身的问题！

tedden 发表于 2011-7-6 19:10:50

回复【2楼】S418
-----------------------------------------------------------------------

上次也有人问我类似的问题，说是定义两个数组改一个数组的元素另一个数组的也会变，估计就是这个情况。

S418 发表于 2011-7-7 09:15:03

回复【3楼】tedden
-----------------------------------------------------------------------

呵呵！

cooldog123ppqq 发表于 2011-7-19 12:35:30

移植确实是一门学问啊
页: [1]
查看完整版本: 嵌入式学习之移植篇