STM32系统中应用的动态加载可行性研究过程<三>

       研究总是让人痛苦并快乐着，痛苦是因为研究的东西都是自己不熟悉的未知领域，一开始往往方向是不明确的，思路是不清晰的，就像破案一样，首先需要我们从蛛丝马迹中收集到尽可能多的资料，然后根据收集到的资料进行分类归纳总结并寻找下一步方向。快乐是因为研究有了一定成果之后，你总会感觉很有成就感。对于"STM32系统中应用的动态加载可行性研究过程"这个课题，今天终于有一些新的进展和更明确的方向了。在阐述我的研究成果之前，我先补充说明一下我这里的标题：我在这里研究的课题并不是一定要在STM32平台上才能实现，而是一个嵌入式平台的通用原理和机制，只是根据你选择的实现方式不同可能涉及到对硬件平台的资源的考虑。比如之前我抛出的问题，如果要实现系统支持JavaScript的程序运行，那么系统中必须要有JavaScript引擎（简称JS引擎），JS引擎有Google开发的成熟的V8 JS引擎，但是V8的代码量很大，据说有8M多，那么如果想在STM32没有外扩SRAM和FLASH的情况下，可能只有128KB SRAM和只有1MB内置ROM，那么是完全无法将V8移植到系统中的，也就无法实现对JavaScript的支持。所以考虑到这点，我的研究方向再次转到了对Pebble方案的研究上，因为Pebble使用的正式STM32平台，其资源也是有限的，而听到很多人说Pebble支持C应用、JAVA应用和JavaScript应用的安装，安装的方式是从手机端的Pebble Mobile应用传送到Pebble watch（传送方式是蓝牙无线传输）。

       一开始听到别人（“别人”指的是领导包括老板，他们说你看Pebble都可以支持应用的安装，且可以使用流行的简单的设计语言JAVA和JavaScript语言进行应用的开发，那么我们是不是也可以实现，快研究一下Pebble是怎么实现的！！！）说这样的结论我感到很是惊讶，根据基本原理且Pebble使用的STM32平台是根本不可能支持JAVA和JavaScript应用的，只可能是支持C应用，这个也要在系统中实现动态加载和链接器之后。那么领导说的这个信息应该也不是无中生有，应该是我们对Pebb