helper2416_rawos_lua组件移植ok_欢迎测试

lyzhangxiang

helper2416_rawos_lua组件移植ok_欢迎测试 [复制链接]

之前有一些关于裸机的帖子，主要是用ucosii，有一些相关的移植和小结，得益于一些瞎折腾，才有了这篇在rawos上的组件移植的帖子。lua相关的我就不做介绍了可以参考我前面的帖子（第一篇帖子主要是介绍和其他平台移植相关，第二篇主要在5、6楼中有初步移植问题讨论）。
helper2416_lua5.2移植_效率测试

helper2416_rawos_ping测试

我从rawos的git中fork了一份代码，后面会添加一些组件移植和现有组件的测试工作，需要的朋友可以直接从git获取代码地址如下

1. https://git.oschina.net/camel.shoko/helper2416.git

复制代码

基础的移植参考第一篇帖子中的描述，不再重复了。说说raw-os中移植遇到的问题，最初我使用raw_malloc.c中的内存分配方案替换lua中的内存分配，测试发现问题出在下面这几个宏上面，是c的标准库用法，我仿真跟踪了会跳来跳去，没有规律，看来基于堆栈的虚拟机不能随便使用malloc分配方案了。索性用微型库的内存分配方法。

1. #define LUAI_THROW(L,c)                longjmp((c)->b, 1)
   
2. #define LUAI_TRY(L,c,a)                if (setjmp((c)->b) == 0) { a }
   
3. #define luai_jmpbuf                jmp_buf

复制代码

卡死了这里



好吧说说现在如何解决，相关内存分配的方案可以参考我之前的帖子，细节的也就不说了，大家自己看。
helper2416_内存分配实现_有分析

修改luaxlib.c中的下面的函数如下

1. static void *l_alloc (void *ud, void *ptr, size_t osize, size_t nsize) {
   
2.         /* not used */
   
3.         (void)ud; (void)osize;  
   
4.         if (nsize == 0) {
   
5.                 free(ptr);
   
6.                 //raw_free(ptr);
   
7.                 return NULL;
   
8.         } else {
   
9.                 return realloc(ptr, nsize);
   
10.                 //return raw_realloc(ptr, nsize);
    
11.         }
    
12. }

复制代码

注意这里是内存分配函数指定，多看一些开源的代码，对搞c的很有帮助，人家的代码写的确实漂亮，羡慕不来的。

好了添加一个CLI用于测试lua，方法老样子的测试加法效率和c比较，结果还是很不错的。

1. extern RAW_S32 cmd_lua_test(RAW_S8 *pcWriteBuffer, RAW_U32 xWriteBufferLen, const RAW_S8 * const pcCommandString);

复制代码

1. RAW_S32 cmd_lua_test(RAW_S8 *pcWriteBuffer, RAW_U32 xWriteBufferLen, const RAW_S8 * const pcCommandString)
   
2. {
   
3.         RAW_SR_ALLOC();
   
4.        
   
5.         RAW_CRITICAL_ENTER();
   
6.         Lua_Efficiency_Test();
   
7.         RAW_CRITICAL_EXIT();
   
8.        
   
9.         return 1;
   
10. }

复制代码

1. rsh_register_command(&lua_shell_cmd,&lua_shell_item);

复制代码

注册这个命令就好了，等系统运行了就直接执行lua吧。

关于内存划分的一些简单说明
1）修改原始的内存池

1. #define HEAP_ADDRESS_START          0x30200000
   
2. #define HEAP_ADDRESS_END                  0x30400000

复制代码

2）添加堆栈（分散加载描述文件）

1. LR_ROM1 0x30800000 0x2800000 {    ; load region size_region
   
2.         RW_ROM1 0x30800000 0x2800000  {  ; load address = execution address
   
3.                 *.o (RESET, +First)
   
4.                 .ANY (+RO +RW)
   
5.   
   
6.         }
   
7.         RW_RAM1 0x33000000 0x1000000  {  
   
8.                 .ANY(+ZI)
   
9.         }
   
10.   
    
11.         ARM_LIB_HEAP  0x30400000 EMPTY  0x00200000 {
    
12.                
    
13.         }
    
14.         ARM_LIB_STACK 0x30800000 EMPTY -0x00200000 {
    
15.                
    
16.         }
    
17.        
    
18. }

复制代码

这里可以参考之前帖子的分析。

将0x30200000 - 0x30400000 作为RAW_MALLOC
将0x30400000 - 0x30600000 作为HEAP
将0x30600000 - 0x30800000 作为STACK


3）执行的结果

启动



执行




结果


好了，所有源码在前面的git中，可以直接编译执行，有问题欢迎大家讨论，后面会给大家一些lua的例子，展示他的魅力。当然了要做的事情有不少，需要实现文件系统的一些接口，还需要实现一些cli的命令，大家可以加入进来。

大家可以实现CLI如：ls 、 mdkir 、vi等，其实我一直想给这种RTOS移植一个vi编辑器。

好吧，当然了c解释器也很不错，我也想移植。可惜分身乏术，最近公司事情也不少。

lyzhangxiang

          自从1997年7月4日抵达火星表面后，火星探路者(The Mars Pathfinder)一直被大肆宣称为“完美的”。它确实包含了很多成功之处，从它那非传统的着陆方式――被巨大的气囊包裹着蹦蹦跳跳着陆，然后释放出 火星探路者――开始，直到它收集并向地球发回的大量火星第一手数据，比如后来流传到Web上并让人叹为观止的各种火星表面全景图。但是在着陆后的第10 天，也就是开始采集气象资料后不久，探路者开始犯傻――开始无规律地重启，每次重启都造成了数据丢失，在每天的记者招待会上这都是记者们不会放过的最热门 的话题。NASA（美国国家航空航天局）的公共关系部门只是用一些术语比如“software glitches”来解释，他们告知外界，原因是计算机试图同时完成太多的事情所以造成了故障。

    在上周的IEEE实时系统会议上，WindRiver CTO David Wilner给出了一个很有意思的新说法。当然，众所周知，该公司的实时嵌入式内核VxWorks，就用在火星探路者上。在该会议上，他详细解释了哪些真 正的软件问题导致了探路者整个系统的重启，以及他们是如何诊断并解决该问题的，让我们分享一下这个故事。



    先了解一些基本情况。

    VxWorks提供基于优先级的可强占调度方式。探路者上的任务均被赋予优先级，采用的是常规方式――按任务的紧急程度――划分优先级。
    探路者有一个“information bus”，可以看作是一块共享存储区，该区域用于在探路者的不同组件之间传递信息。当然，随之就有一个总线管理任务，该任务以高优先级运行，负责在总线上 放入或者取出各种数据。它被设计为最重要的任务，并且要保证能够每隔一定的时间就可以操作总线。对总线的异步访问是通过互斥锁(mutexes)来保证 的。

    另有一个气象数据搜集任务，它的运行频度不高，也只有低优先级，它只向总线写数据。写的过程是，申请/获得总线互斥量，进行写操作，完成后释放互斥量。在 互斥量被占有的情况下，如果总线管理任务被激活了，试图获得该互斥量，那么总线管理任务会被挂起，最终结果是或者一直等到气象任务释放该互斥量，或者总线 任务等待超时。最后，探路者上还有一个以中等优先级运行的通信任务，通信任务和总线是没有什么瓜葛的。

    开始的大多数时间，系统工作的很好，然而，还是发生了这样的情况：气象任务（低优先级）获得互斥量并写总线的时候，一个中断的发生导致了通信任务（中优先级）被调度并就绪，调度的时机正好是总线管理任务（高优先级）等待在总线访问互斥量上的时候。这种情况下，因为通信任务比气象任务优先级高，所以会抢占气象任务，当然，这也就更让总线管理任务失去了运行的机会。通信任务运行时间稍长，总线管理任务就会等待互斥量超时，返回错误，提示总线任务没有能够在一定的时间内完成总线操作，在探路者中，这种情况被当作严重错误处理，作为错误处理的结果就是――整个系统被重启。



    如何调试出这个问题的？

    VxWorks可以配置为在一种tracing模式下运行，即记录所有感兴趣的系统事件，例如，上下文切换，同步对象的使用，发生的中断。探路者上出现了 错误之后，JPL（美国国家航空航天局喷气推进实验室）的工程师们花了相当多的时间在实验室里的一台一摸一样的探路者上运行打开了tracing的系统， 希望能够再现引起重启的情况。几天过去了，一个清晨，几乎所有的工程师都走了，只剩下最后一位Mr. So-So的时候，火星上那台探路者兄弟身上发生的重启情况终于被再现了。经过对trace数据的分析，得出了原因，大名鼎鼎的――或者臭名昭著的？―― 优先级翻转。



    如何纠正这个问题的？

    什么是优先级翻转呢？以探路者的例子做一个一般性的描述就是：低 优先级的任务（气象任务）占有互斥量，这时有高优先级的任务（总线任务）申请信号量，因为不能满足而被挂起了，即低优先级任务阻塞了高优先级任务的运行 ――这还不是最糟的――这时插进了一个中优先级任务（通信任务），它又把低优先级任务抢占了，高优先级任务能执行的机会就更少了，成了解不开的死结。在 VxWorks里，当创建互斥量的时候，有一个bool参数，决定对该互斥量是不是采用优先级继承来防止发生优先级翻转。探路者的程序中创建的总线互斥量 正好把这个参数off了。如果这个参数on的话，探路者的行为就是另一个样子了：首先，气象任务（优先级最低）获得互斥量，做写操作，在还没有完成写操作 的时候，总线管理任务（优先级最高）申请信号量，所以互斥量的所有者，气象任务，将继承总线任务的高优先级，那么当中优先级的通信任务被调度的时候，是不 可能影响无辜的已经具有高优先级的气象任务的。这样优先级翻转就被避免了。

    VxWorks带有一个C语言解释器，允许开发者在调试时输入C表达式或者函数并且可以随意执行。JPL的工程师们很走运的在探路者上使能了这个功能。按 照他们的编码约定，该互斥量的初始化参数都存在全局变量中，全局变量的地址在符号表中，引导部分的软件包含了该符号表，并且可以被C语言解释器使用。所 以，工程师们上载了一段程序到探路者上，这段程序被解释后，把互斥量的参数改变为TRUE。结果是，再也没发生重启了。



    分析和教训 ANALYSIS AND LESSONS

    首先，也是最重要的，以黑盒方式调试这个问题几乎是不可能的，只有当造成系统错误的真实运行情况被trace下来分析识别后这个问题才得益解决。
    第二，在系统中保留调试功能会有用的，因为如果系统不能修改的话，问题是不可能得到解决的。
    最后，工程师们的分析――“总线任务的执行频率非常高并且是时间关键的，所以不应该为了优先级继承而花费额外的时间”――是极为错误的。显然，在这样时间关键但正确性也是十分重要的场合，即使付出额外的性能代价也是必须的。




    HUMAN NATURE, DEADLINE PRESSURES

    David告诉我们，JPL的工程师们后来承认，在飞行前测试阶段就发生过一两起这样的重启，但是相当不易重现所以也没有得到解释。工程师们――出于一种很自然的回避情绪――认为这个问题不重要，并且也找到了一个托词――可能是硬件上的小毛病引起的。
    另外工程师们的工作重点也是个问题。他们花费了极大的精力用于保证着陆软件部分的质量，使其几乎达到了完美的程度。因为如果着陆失败的话，整个火星探测计 划就完全失败了，所以，完全可以理解工程师们为什么会对相比之下次重要的陆地巡航软件的小问题不那么在意，特别地，只是把简单的重启当作错误处理的方法也 可以看出在这部分没有花费很多的注意力。


    成熟的理论/算法的意义 THE IMPORTANCE OF GOOD THEORY/ALGORITHMS

    David最后提到，关于这种情况，早有前人做过研究，CMU（卡耐基。梅隆大学，反正不会是中国医科大学）的研究人员多年前发表的文章中第一次讨论了优 先级翻转现象并给出了解决方法。David不太记得起文章的详细内容和作者了。不过实际上就有那么凑巧，该文章的三位作者正好就在那次讨论会上，讨论会的 最后，在会议主席的鼓励下，他们三位终于现身，起立并与大家致意，他们是Lui Sha, John Lehoczky, and Raj Rajkumar（第一位老先生也与RMS有关）。说句实话，诸位何时看到过人们向为推进人类智慧作出了杰出贡献的真正的计算机科学理论工作者欢呼致意的 情景?？这真是不多见的。

lyzhangxiang

2楼的文章希望大家好好看一下（不看一楼都要看下2楼的），国外199x年的技术这么牛，真心佩服。每每读这篇文章我都热血沸腾，我试图找到伯乐在线上面的原文给大家，可惜没找到。贴到这里分享给大家。

C语言解释器，真心给力，所以说有脚本语言很有必要，大家有对c解释器兴趣的，我可以分享一些国外的项目给大家在CM3/PIC上面运行的c语言解释器项目。

yuanlai2010

lyzhangxiang 发表于 2014-8-29 21:56
自从1997年7月4日抵达火星表面后，火星探路者(The Mars Pathfinder)一直被大肆宣称为“完美的” ...

哈哈！这个好像就是优先级反转的一个实例，原来还有这么一个故事在里面。

lyzhangxiang

为helper2416准备的硬件，主要是把2416作为服务器，前面的一些nodejs和socket都能用起来了。

这个手工板子作为节点，采集一些传感器信息，PM2.5还不错，放在家里，还有点。
         

hbwangliang

嗯嗯，多看一些开源的代码，对搞c的很有帮助，人家的代码写的确实漂亮，羡慕不来的

lyzhangxiang

yuanlai2010 发表于 2014-8-29 22:08
哈哈！这个好像就是优先级反转的一个实例，原来还有这么一个故事在里面。

是啊  优先级反转，实际中还真遇到过，也是第一次看到这篇文章的时候了

jorya_txj

人多，人气旺，此言不假。