嵌入式系统的新思路

jimfoss

嵌入式系统的新思路 [复制链接]

以脚本式操作语言为API的交互式的嵌入式系统内核

简介

这种新型嵌入式系统内核可以理解为一个封装好的只能执行专门脚本语言（操作语言）的机器（脚本机器，Script Machine），类似于java虚拟机。但java虚拟机执行的是字节代码，而且是解释执行，语言结构也比较复杂。本脚本机器执行的是脚本语言，语法结构简单易懂易维护，而且是编译成二进制代码执行，函数经过一次编译后就以二进制形式嵌入到系统中，所以可以通过这种形式扩展系统功能。系统调用和用户增加的功能函数都组织到一个树形的名字空间中便于记忆。


一、结构形式


操作语言的语法类似于高级语言如 C、BASIC，应用程序用操作语言编写，不需要在系统外进行编译和链接，而是由系统内核直接执行，这一点上类似于脚本语言。
系统内核可以单独运行，运行过程中可以交互式接收用操作语言写成的代码并执行，用操作语言写成的用户函数可以驻留在系统中以扩展系统功能，供自己或其它应用调用。
一些外围的服务可以用操作语言编写，在系统启动时首先执行。只有特别基本和需要特别优化的系统函数调用才需要放在内核中。
操作语言编写的代码并非解释执行，而是通过内部编译成机器码后运行。
底层的系统调用和服务都被安排在一个树形的名字空间中，非常容易记忆和识别。

二、优点

1、        快速开发应用程序。
脚本式语言的语法简单，而且因为省去了在系统外进行编译和链接的过程，应用程序的代码可以用交互式的方式直接放到系统中测试、运行，可以大大提高软件开发速度。

2、        底层封装后代码更健壮。
以类似简单脚本语言的高级语言开发的应用程序简洁易读，容易维护。以操作语言编写的代码受到语言本身的限制，比二进制代码更安全，不会轻易破坏系统。

3、        动态添加和修改系统功能。
系统运行过程中可以动态接受操作语言写成的函数并扩展到系统调用的树形名字空间中。

4、        分层次开发。
开发内核的人和开发应用的人可以完全分工。

5、        底层封装后便于移植到不同的硬件。
不同的硬件只要实现了相同的操作语言，则应用程序可以完全不用改。

三、缺点

1、        占用内存。脚本内部编译器，系统名字空间，函数定义都要占用内存，本人开发的测试系统其中的这部分占用了十几K，如果实现更多的数据类型和运算符，应该在数十K左右。对于现在的嵌入式应用来说，不是很多。
2、        性能降低。性能降低分为两个部分：花在脚本内部编译的时间和运行时间的变慢。加载到系统中的函数是一次性编译为机器码，编译器使用汇编语言直接写成，运行速度是非常快的，编译时间一般可以承受，如果系统需要频繁启动，建议采用内存映象方式加载。因为脚本是编译成机器码后运行的，虽然编译器优化功能不强，但是跟直接用汇编写成的代码的运行速度应该还是在一个数量级上的，这一点可以通过对编译后的代码反编译后察看。

如果系统的设计能够大幅加快，同时带来很大的系统灵活性，我觉得上述缺点是值得牺牲的。而且对于一个成品系统，完全可以在开发设计完成后，对于需要进行性能优化的有关代码用汇编重写，直接嵌入内核作为系统调用。


四、总结

脚本语言在WEB服务器和浏览器中被大量应用就是因为其无以伦比的灵活性和快速开发能力。将脚本语言应用在嵌入式系统的开发设计上也许一样能大放光彩。

五、试验系统说明

试验系统的硬件为普通PC，采用了32位FLAT内存模型，试验系统做成了一个可启动的软盘映象，系统完全在内存中运行，只实现了一个键盘和显示器组成的CONSOLE，没有实现软硬盘的读写。
试验系统实现了内存管理，任务管理，中断处理，消息队列等操作系统内核。用户在CONSOLE中输入一段程序，并以单行的”/”结束输入时，系统会编译这段代码，并启动一个新的任务（进程）来执行这段代码。
为方便调试，系统在显示器右上角显示系统预定义的测试变量dx和dy得值，以便察看进程执行的结果，也可以用#console.write.int系统调用输出。
试验系统的下载，测试说明，测试代码，有关操作语言的语法简略说明请见网站：www.scriptmachine.cn 。

atghjiq

请各位业界人士提出意见，非常欢迎有32位bios或者驱动开发经验的人士共同研究，同时欢迎热心的开发测试人员！

SPEED

作为嵌入式系统来说，实时性很重要，
实时性在你的系统里如何体现？

我们不是看能提供什么功能，
而是看需要什么功能，

岚裳

这个RTOS目前的任务切换是通过时钟中断进行的，每个任务分配有时间片，时钟中断到达后时间片减一，时间片用完后切换到下一个任务。当前任务在等待时可以主动交出控制权，切换到下一个任务。任务之间是循环的，优先级高的任务分配的时间片长。
所以此RTOS的实时性总的来说跟时钟中断的频率有关，但是跟应用的代码设计也有关。
任务切换这一块其实还有其他方法实现，但是这不是我要说明的重点。

xiaohanfirst

随着硬件性能的不断发展，这个思路应该会在非实时性的嵌入式应用中出现

疯狂儿

有所得必有所失

winnie_nie

这个在嵌入式里面实施,势必影响许多,值得探讨.

bayasina

这个RTOS目前的任务切换是通过时钟中断进行的，每个任务分配有时间片，时钟中断到达后时间片减一，时间片用完后切换到下一个任务。当前任务在等待时可以主动交出控制权，切换到下一个任务。任务之间是循环的，优先级高的任务分配的时间片长。
所以此RTOS的实时性总的来说跟时钟中断的频率有关，但是跟应用的代码设计也有关。
任务切换这一块其实还有其他方法实现，但是这不是我要说明的重点。

----------------------------------------------
那就是说这个系统是不可抢占的，
优先级只是占用的CPU资源多些，

那么这个东西不适合建立在系统层面上，至少说没有任何实时性可言，
更适合在应用层面，封装api，相当于一种高级语言或shell吧，

hongrui1111

PLC就是怎么干的啊

yswlmike

不是所有的应用系统都允许承担这种代价...

应用局限性很明显

junuo

这个RTOS目前的任务切换是通过时钟中断进行的，每个任务分配有时间片，时钟中断到达后时间片减一，时间片用完后切换到下一个任务。当前任务在等待时可以主动交出控制权，切换到下一个任务。任务之间是循环的，优先级高的任务分配的时间片长。
所以此RTOS的实时性总的来说跟时钟中断的频率有关，但是跟应用的代码设计也有关。
任务切换这一块其实还有其他方法实现，但是这不是我要说明的重点。

----------------------------------------------
那就是说这个系统是不可抢占的，
优先级只是占用的CPU资源多些，

那么这个东西不适合建立在系统层面上，至少说没有任何实时性可言，
更适合在应用层面，封装api，相当于一种高级语言或shell吧，
----------------------------------------------
我不知道你说的抢占的意思，
在这个系统中，如果有需要的话，外部中断进来后可以进行任意的任务切换，
据我理解根据时钟中断进行任务时间分配就是抢占的，
windows3.1那种非抢占的必须要通过任务自己yield。

Horace88

谢谢 HZJMAN(龙珠) ，我的看法跟你一样

52FY

据我理解根据时钟中断进行任务时间分配就是抢占的，


这个更像是时间分片

抢占学术一点,应该是事件驱动的,

呵呵,也就是一个消息过来后,以一定的机制保证得到时间容许内的最快响应

以时间中断看,那顶多就是分时间片

feitian9215

据我理解根据时钟中断进行任务时间分配就是抢占的，


这个更像是时间分片

抢占学术一点,应该是事件驱动的,

呵呵,也就是一个消息过来后,以一定的机制保证得到时间容许内的最快响应

以时间中断看,那顶多就是分时间片
----------------------------------------------------
你说的这个在此系统中是完全可以做到的，
当一个事件发生时（中断处理过程中），所有任务的执行顺序可以任意修改，时间片也可以修改，
但是抢占不是独占，如果一个任务设计得太霸道，其他任务没有机会执行，就不能叫多任务了。

zhangping0525

有网卡开发经验能否与我联系，共同发展此系统，谢谢！

hzxiaobao

不管如何,还是值得顶一下,但就此看来,应用还是有局限性的.

tangrui0307

顶一下。