关于在ADS环境下使用libc库函数的一些疑问

虽然ADS环境已经被ARM公司收购，并且停止了后续版本的升级维护，但应该说它还是一款比较好的SDK开发平台。
先说一下基本情况，公司由于项目的需要，硬件平台选用了ARM9的芯片，软件SDK采用了ADS1.2。虽然ADS1.2的后续版本已经改为Kei for Arm了，但以前的平台最高还是可以支持到Arm9的芯片的。
另外项目需要使用操作系统，我们已经自主开发出了一款小型的嵌入式操作系统，而且已经在一些其他的项目通过了实践测试，所以没理由不用自己的操作系统。由于应用程序的代码需要用到大量的C库函数和数学函数，并且对精度和实时性能有一定的要求，但我们并没有自己的C函数库和数学函数库，项目的完成时间又比较紧迫，于是决定使用ADS1.2中自带的库函数。于是乎问题来了，怎样在保证使用自己的操作系统的情况下正常调用ADS1.2的库函数？这里先了解一下ADS和操作系统的初始化流程。



以上的流程是ADS编译代码后的默认启动流程，其中与C库函数和数学函数相关的主要系统初始化步骤集中在了__main()函数中实现，而该函数被ADS公司打成包了。接下来看看我们操作系统的启动流程，这里暂时给系统命名为XOS。



如果光走操作系统的初始化流程，跳过ADS的初始化，那明显在使用库函数的时候会出问题。怎么办哪？那试试在跑完ADS启动流程进入到main()函数的时候再切到XOS的启动流程里。



这样看起来是可行的，我们在实际的使用过程中也确实可以，应用程序并没有出现崩溃等异常。但是细想想，好像稍微还有些不妥。在XOS中自己实现了一套内存管理机制（这里称为XOSMalloc）,我们在应用中的所有的内存管理都是用这套机制。而ADS函数库中的许多函数也是需要使用内存管理机制的，ADS也特意为它们实现了一套（这里称为Malloc）。从以上的流程看，整个的启动过程中即实现了malloc也实现了XOSmalloc，也就是整个程序中有两套内存管理机制。而在scf文件中只定义了一块heap段，两套机制在初始化时用的都是同一个heap段的起始地址和长度。写到这里问题又来了，如何保证两套不同的内存管理机制在同一块堆内存上的和平共处哪？



因为两套内存管理机制之间没有进行统一管理（malloc的源码是没公开的，也不知它实现的方式）。所以任何时候其中一套机制并不知道另一套机制对内存的分配情况。也就是说，实际上会产生两套机制分配到了同一块内存空间的情况，这样后分配的内存操作会覆盖掉前面分配的内存数据，就可能产生数据异常甚至造成系统崩溃。但奇怪的是，应用程序运行到目前为止并没有出现崩溃等重大错误。但在下位机上的长时间计算结果与PC端得出的还是有些出入。可能是这个问题造成的吗？也可能是其他问题造成的。反正到目前为止没有确切的证据证明是这个问题造成的，或许是个隐患吧！
疑问，都是疑问。知道问题所在该想办法去解决它吧！思前想后，找想到了两个办法去解决这个问题：
1， 分配一个新的heap段给其中的一个内存管理机制，保证两者的管理范围在物理内存空间上不发生重叠，也就不会出现数据覆盖的现象了。
2， 重新实现C函数和数学函数库。在库函数中调用操作系统自己的一套内存管理机制。这样应该可以从根本上解决这个问题。
上面两种方法中，第一种可以说是只能治标，因为即使成功之后换一个SDK平台的话又会遇上同样的问题，但是这种方法相对来说可以比较快的解决问题。如果想彻底解决问题的话还是需要使用第二种方法。但这种方法实现的时间比较长，需要自己理解与C库和数学函数库相关的一些定义。不过还是值得一试。
总的说来，我们在嵌入式平台上开发还需要做很多的事情。打好坚实的基础才能在以后的引用中得心应手。