eCos内核概览

合集下载

基于eCos的嵌入式远程测控系统设计

基于eCos的嵌入式远程测控系统设计
a d r l b l y,a di a e wieyusd i h n u ty c n r la e . n ei i t a i n tc n b d l e n t eid s r o to r a
Ke wo d :e b d e y tm ;e s y r s m e d d s se Co ;m e s rm e ta d c n r l y tm ;ra i es se a u e n n o to se s e lt y t m m
0 引 言
当前 , 控制技 术 已经在 工业控 制领域 得 到快速 的 网络
程 监控 ;
() 有一定 的通用 性 , 定 的人 机 交互 功能 , 3能 有一 方便
实际中对工业参数的设定 、 系统的维护和扩充性 。 考虑如上要求 , 本文设计出如 图 1 所示的硬件结构。
R A M ¥C 4 0 含一 个 1/2b的 R S ( R 2T) 3 21 包 6 3 IC A M90 的
De i n o e o e m e s r m e nd c n r le b d e s g f r m t a u e nta o t o m e d d
s se a e n e s y t m b s d o Co
L i i e J
( S gn eig CO., CI DIEn iern LTD,Ch n qn 0 0 0 o i 403) g g
raie r mo emo i rn e l e t nt ig,t ed sg a e na m b d e n o f u e y tm ,n m ey t go m b d e y tm , z o h e inb sd o ne e d d a d c n i r ds se g a l hee se e d d 2 卷 第5 5 期

ecos内存管理

ecos内存管理
该函数产生一个可进行固定大小内存分配的定长内存池。堆大小不一定是整个可用内存的大小。定长内存池在速度上要优于变长的。新产生的内存池可以通过句柄对其进行访问。
2、删除内存池
void cyg_mempool_fix_delete(内存池句柄)
该函数删除定长内存池。不要删除正在使用的内存池,否则会引起系统错误。
7、检查是否有线程正等待分配内存
cyg_bool_t cyg_mempool_var_waiting(句柄)
8、取得内存池信息
void cyg_mempool_var_get_info(句柄,要返回的信息结构指针)
注意不定长分配内存时为了避免小碎片影响系统性能,应限定可变内存申请的最小值为一个比较大的数信箱和线程所需内存块
static char memvar[CYGNUM_LWIP_VARMEMPOOL_SIZE];//可变长内存池实体
static cyg_mempool_var var_mempool;//内存池结构体变量,详见kapidata.h.
#include "arch/sys_arch.h"
#include "lwip/sys.h"
#include "lwip/def.h"
#define tick_to_msec(tick) ((u16_t)((tick)*10+1))
#define msec_to_tick(msec) ((cyg_tick_count_t)(msec+9)/10)
***********************
1、创建内存池
void cyg_mempool_fix_create(堆起址,堆大小,内存块大小,返回的内存池句柄,固定内存池结构体)

(原创)eCos驱动分析 之 ISR是如何与硬件中断联系起来的 ---转载文章

(原创)eCos驱动分析 之 ISR是如何与硬件中断联系起来的 ---转载文章

(原创)eCos驱动分析之ISR是如何与硬件中断联系起来的---转载文章要想知道ecos的中断ISR是怎么与硬件中断向量联系起来的,是怎么被调用的?那就要看下面这两个关键的函数:cyg_drv_interrupt_create()cyg_drv_interrupt_attach()这两个函数都声明在cyg/kernel/kapi.h中,其形式如下:void cyg_interrupt_create( cyg_vector_t vector, /* Vector to attach to */ cyg_priority_t priority, /* Queue priority */ cyg_addrword_t data, /* Data pointer*/ cyg_ISR_t *isr, /* Interrupt Service Routine */ cyg_DSR_t *dsr, /* Deferred Service Routine */ cyg_handle_t *handle, /* returned handle */ cyg_interrupt *intr /* put interrupt here */) __THROW;void cyg_interrupt_attach( cyg_handle_t interrupt )__THROW;(注: __THROW是在C++中用的,是用来抛出异常的,详见我的博文/blog/static/888807432011611193510/ 这里可以视而不见.)其中文意义对照如下:cyg_interrupt_create( 中断号, 中断优先级, 传递的中断参数, ISR函数,DSR函数, 被返回的中断句柄, 存放与此中断相关的内核数据的变量空间);cyg_interrupt_attach(中断句柄);这样实际上去研究一下cyg_interrupt_create函数的定义内容,应该就能搞明白我们的问题了!由于其函数声明在kapi.h中,很自然的就想到其定义应在kapi.c文件中,找到....\ecos\ecos-current\packages\kernel\current\src\common\kapi.cxx文件,找到这两个函数的定义如下:/*---------------------------------------------------------------------------*//* Interrupt handling*/externC void cyg_interrupt_create( cyg_vector_t vector, /* Vector to attach to */ cyg_priority_t priority, /* Queue priority*/ cyg_addrword_t data, /* Data pointer */ cyg_ISR_t*isr, /* Interrupt Service Routine */ cyg_DSR_t *dsr, /* Deferred Service Routine */ cyg_handle_t *handle,/* returned handle */ cyg_interrupt *intr /* put interrupt here */) __THROW{ CYG_ASSERT_SIZES( cyg_interrupt,Cyg_Interrupt );Cyg_Interrupt *t = new((void *)intr) Cyg_Interrupt( (cyg_vector)vector, (cyg_priority)priority, (CYG_ADDRWORD)data, (cyg_ISR *)isr,(cyg_DSR *)dsr ); t=t;CYG_CHECK_DATA_PTR( handle, "Bad handle pointer" ); *handle = (cyg_handle_t)intr;}voidcyg_interrupt_attach( cyg_handle_t interrupt )__THROW{ ((Cyg_Interrupt *)interrupt)->attach();}函数内容比想象中的简单,所有的操作又都传给了Cyg_Interrupt这个类来完成,那就来对Cyg_Interrupt探个究竟吧:(注意Cyg_Interrupt是个C++类, 可不要找成了struct cyg_interrupt,注意哟,cyg_interrupt_create函数的最后一个参数就是这个cyg_interrupt struct类型的,在cyg/kernel/kapidata.h中有个struct cyg_interrupt定义,虽然名字和内容都很相似,但实际上不是.)真正的class Cyg_Interrupt定义在cyg/kernel/intr.hxx中,这个头文件没干别的,就是声明这个class了,可见这是一个很大的class,如下:// -------------------------------------------------------------------------// Interrupt class. This both represents each interrupt and provides a static// interface for controlling the interrupt hardware.class Cyg_Interrupt{friend class Cyg_Scheduler; friend voidinterrupt_end( cyg_uint32,Cyg_Interrupt *,HAL_SavedRegisters *); friend voidcyg_interrupt_post_dsr( CYG_ADDRWORD intr_obj );friend void cyg_interrupt_call_pending_DSRs( void );cyg_vector vector; // Interrupt vector cyg_priority priority; // Queuing priority cyg_ISR *isr; // Pointer to ISR cyg_DSR *dsr; // Pointer to DSRCYG_ADDRWORD data; // Data pointer // DSR handling interface called by the scheduler// Check for pending DSRs static cyg_bool DSRs_pending();// Call anypending DSRs static void call_pending_DSRs(); static void call_pending_DSRs_inner();// DSR handling interface called by the scheduler and HAL // interrupt arbiters.void post_dsr(); // Post the DSR for this interrupt // Data structures for handling DSR calls. We implement two DSR // handling mechanisms, a list based one and a table based // one. The list based mechanism is safe with respect to temporary // overloads and will not run out of resource. However it requires // extra data per interrupt object, and interrupts must be turned // off briefly when delivering the DSR. The table based mechanism // does not need unnecessary interrupt switching, but may be prone // to overflow on overload. However, since a correctly programmed // real time application should not experience such a condition, // the table based mechanism is more efficient for real use. The // list based mechainsm is enabled by default since it is safer to// use during development.#ifdef CYGIMP_KERNEL_INTERRUPTS_DSRS_TABLE static Cyg_Interrupt *dsr_table[CYGNUM_KERNEL_CPU_MAX][CYGNUM_KERNEL_INTERRUPTS_DSRS_TABLE_SIZE] CYGBLD_ANNOTATE_VARIABLE_INTR;static cyg_ucount32dsr_table_head[CYGNUM_KERNEL_CPU_MAX]CYGBLD_ANNOTATE_VARIABLE_INTR;static volatile cyg_ucount32dsr_table_tail[CYGNUM_KERNEL_CPU_MAX]CYGBLD_ANNOTATE_VARIABLE_INTR;#endif#ifdef CYGIMP_KERNEL_INTERRUPTS_DSRS_LIST // Number of DSR posts made volatilecyg_ucount32 dsr_countCYGBLD_ANNOTATE_VARIABLE_INTR;// next DSR in list Cyg_Interrupt* volatile next_dsr CYGBLD_ANNOTATE_VARIABLE_INTR;// static list of pending DSRs static Cyg_Interrupt* volatile dsr_list[CYGNUM_KERNEL_CPU_MAX]CYGBLD_ANNOTATE_VARIABLE_INTR;#endif#ifdef CYGIMP_KERNEL_INTERRUPTS_CHAIN// The default mechanism for handling interrupts is to attach just // one Interrupt object to each vector. In some cases, and on some // hardware, this is not possible, and each vector must carry a chain // ofinterrupts.Cyg_Interrupt *next; // Next Interrupt in list// Chaining ISR inserted in HAL vector staticcyg_uint32 chain_isr(cyg_vector vector, CYG_ADDRWORD data);// Table of interrupt chains static Cyg_Interrupt*chain_list[CYGNUM_HAL_ISR_TABLE_SIZE];#endif// Interrupt disable data. Interrupt disable can be nested. On // each CPU this is controlled bydisable_counter[cpu]. When the // counter is first incremented from zero to one, the //interrupt_disable_spinlock is claimed using spin_intsave(), the // original interrupt enable state being saved in// interrupt_disable_state[cpu]. When the counter is decremented // back to zero the spinlock is cleared using clear_intsave().// The spinlock is necessary in SMP systems since a thread // accessing data shared with an ISR may be scheduled on a // different CPU to the one that handles the interrupt. So, merely // blocking local interrupts would be ineffective. SMP aware // device drivers shouldeither use their own spinlocks to protect // data, or use the API supported by this class, via //cyg_drv_isr_lock()/_unlock(). Note that it now becomes// essential that ISRs do this if they are to be SMP-compatible.// In a single CPU system, this mechanism reduces to just // disabling/enabling interrupts.// Disable level counter. This counts the number of times // interrupts have been disabled. static volatile cyg_int32 disable_counter[CYGNUM_KERNEL_CPU_MAX] CYGBLD_ANNOTATE_VARIABLE_INTR;// Interrupt disable spinlock. This is claimed by any CPU that has // disabled interrupts via the Cyg_Interrupt API. static Cyg_SpinLock interrupt_disable_spinlockCYGBLD_ANNOTATE_VARIABLE_INTR;// Saved interrupt state. When each CPU first disables interrupts // the original state of the interrupts are saved here to be // restored later. staticCYG_INTERRUPT_STATEinterrupt_disable_state[CYGNUM_KERNEL_CPU_MAX] CYGBLD_ANNOTATE_VARIABLE_INTR;public:Cyg_Interrupt // Initialize interrupt ( cyg_vector vector, // Vector to attach to cyg_priority priority,// Queue priority CYG_ADDRWORD data,// Data pointer cyg_ISR *isr,// Interrupt Service Routine cyg_DSR *dsr // Deferred Service Routine );~Cyg_Interrupt(); // ISR return values enum { HANDLED = 1, // Interrupt was handled CALL_DSR = 2// Schedule DSR };// Interrupt management void attach();// Attach to vector void detach();// Detach from vector // Static Interrupt management functions// Get the current service routine static voidget_vsr(cyg_vector vector, cyg_VSR **vsr);// Install a vector service routine static voidset_vsr( cyg_vector vector, // hardware vector to replace cyg_VSR *vsr,// my new service routine cyg_VSR **old = NULL// pointer to old vsr, if required ); // Staticinterrupt masking functions// Disable interrupts at the CPU static voiddisable_interrupts();// Re-enable CPU interrupts static voidenable_interrupts();// Are interrupts enabled at the CPU? static inline cyg_bool interrupts_enabled() { return (0 == disable_counter[CYG_KERNEL_CPU_THIS()]); } // Get the vector for the following calls inline cyg_vectorget_vector() { return vector; } // Static PIC control functions // Mask a specific interrupt in a PIC static void mask_interrupt(cyg_vector vector); // The same but not interrupt safe static voidmask_interrupt_intunsafe(cyg_vector vector);// Clear PIC mask static voidunmask_interrupt(cyg_vector vector); // The same but not interrupt safe static voidunmask_interrupt_intunsafe(cyg_vector vector);// Acknowledge interrupt at PIC static void acknowledge_interrupt(cyg_vector vector);// Change interrupt detection at PIC static void configure_interrupt( cyg_vector vector,// vector to control cyg_bool level,// level or edge triggered cyg_bool up// hi/lo level, rising/falling edge );#ifdef CYGPKG_KERNEL_SMP_SUPPORT// SMP support for associating an interrupt with a specific CPU. static void set_cpu( cyg_vector,HAL_SMP_CPU_TYPE cpu ); static HAL_SMP_CPU_TYPE get_cpu( cyg_vector );#endif };这只是声明了这个class,这个class的构造/析构函数和成员函数的实现,还要找cyg/kernel/intr.hxx头文件相对应的C文件,在这里....\packages\kernel\current\src\intr\intr.cxx 找到了intr.cxx文件,因为cyg_interrupt_create函数实际上调用了classCyg_Interrupt的构造函数,我们就来看看这个构造函数: Cyg_Interrupt::Cyg_Interrupt( cyg_vector vec,// Vector to attach to cyg_priority pri,// Queue priority CYG_ADDRWORD d,// Data pointer cyg_ISR *ir,// Interrupt Service Routine cyg_DSR *dr// Deferred ServiceRoutine ){ CYG_REPORT_FUNCTION();CYG_REPORT_FUNCARG5("vector=%d, priority=%d,data=%08x, isr=%08x, ""dsr=%08x", vec, pri, d, ir, dr); vector = vec; priority = pri; isr = ir; dsr = dr; data = d;#ifdef CYGIMP_KERNEL_INTERRUPTS_DSRS_LISTdsr_count = 0; next_dsr = NULL;#endif#ifdef CYGIMP_KERNEL_INTERRUPTS_CHAINnext = NULL;#endifCYG_REPORT_RETURN();};也就是分配了一下成员变量,把cyg_interrupt_create函数传进来的中断号、ISR、DSR等分配给类的成员变量,好像也没什么特别的。

EEOS

EEOS

EEOS内核分析报告(线程与调度部分)——工程实践总结计73班魏小亮971290一、EEOS概况Easy Embedded OS (EEOS )嵌入式操作系统是中科院计算所组织开发的开放源码的嵌入式操作系统。

该嵌入式操作系统重点支持p-Java,要求一方面小型化,一方面能复用Linux的驱动和其他模块。

EEOS的系统功能结构如下图所示:中科院在EEOS的开发上利用CYGNUS公司的RTOS(Real Time Operating System实时操作系统)eCos作为蓝本,并利用Utah大学的可重用OS工具OS-Kit作为开发基础,在此之上建立自己的驱动程序、API、Java虚拟机和相应软件开发工具和调试器,同时把Mini GUI纳入EEOS体系,最后形成了上图EEOS构架。

(该项目持续两三年,现在仍在发展。

)EEOS的目标是重点支持机顶盒产品的网络传输和多媒体浏览功能,同时具有非常灵活的可移植性。

二、内核总览[内核特点]我们研究的RTOS内核来自eCos实时内核。

作为EEOS的底层,eCos内核具有以下特征:1、实时性。

内核从调度器内部支持线程的实时特征,实现了真正意义上的实时性。

而通过Linux裁减的RTOS一般是在内核的外部添加一层外壳(Shell)来解决实时性的问题,并不能真正意义支持的实时功能。

2、可配置性。

内核的大小和功能非常灵活。

整个内核小于50K,核心源代码(C++程序)约17000行。

但实际应用的时候,配置非常灵活,eCos支持实时性/非实时性进程,BitMap/多级队列/彩票调度三种线程调度方式,单链表/多链表两种Alarm组织方式,固定大小内存/可变大小内存……用户可以根据实际应用生成自己需要的系统。

eCos 提供了可视化的系统配置工具,可以在windows上对系统(包括内核)进行各种配置。

3、支持uItron核心服务界面标准。

uItron是专门为实时系统制定的专用标准。

适用于代码尺寸限制严格的场合。

基于ARM920T的嵌入式系统eCos移植分析及应用

基于ARM920T的嵌入式系统eCos移植分析及应用

AR 2 T 处理器 内核 , M9 0 采用 0 1 x 制 造工艺 , . 8/ m 最 高操 作 频率 达 到 2 3MHz的微 处 理 器 。凭 借 低 价 0 格 、 功耗 、 低 高性 能 的 品质 , 国 内外 广 泛应 用 于 各 被 类 开发 板及 手持 便 携 设 备 中 。然 而 在 e o C s的官方
网站及 相关 文献 中并 没 有 公 布 e o C s针 对 ¥ C 4 0 3 2 1
i g wih ma e t m i i u n m m c nfgu a i wa buit O o i r ton s l t
gu d Co .The o ec fg a i nsa a k ge iee s n m r on i ur to nd p c a s w e e a de O t e t r e a d a e la n e S r d d t h a g t bo r s w l s a CO a plc to pr g a W a c m p l d T he r s t p ia in o rm S o ie . e ul s o s t a e s nd t a h w h t Co a is ppl a i n r r m c n i to p og a c a r n r a l h a g tbo r u no m ly on t e t r e a d.
CHENG n Yo g—Ia , ITig—j n. IXi u, I a~q n n o L n u CA n—j L U Hu i
( v lAe o a t a n ie rn n t u e Ya t i 6 0 1, h n ) Na a r n u i lE g n e i g I s i t , n a 4 0 C i a c t 2

面向eCos的嵌入式软件集成开发环境设计

面向eCos的嵌入式软件集成开发环境设计
组件 的嵌入式 可配置实时操作 系统 , 具有 良好 的可移植 性, 支持 当前 流行 的 A M、o eP X 6等 众 多体 系 的 R P w rC、 8 嵌入式处理器 , 以在 1 可 6位 、2位 和 6 3 4位 系 统之 上运 行 。 目前市场 上 已经 有许 多 应用 e o C s的嵌 入 式 产 品 , 为 了加快基 于 e o C s的嵌入 式系 统 的开 发 , 计 一 个优 设 秀的嵌入式 系统集成 开发环境非常重要 。
i 回
1 e o 操 作 系统 简 介 Cs
嵌 入式 可配 置操作 系 统 e o E e ddC n g — C s( mb d e of u i rbeO e t n Ss m) R d a 推 出 的嵌 入 式 实 a l pr i yt ¨ 是 e H t ao e 时操 作系统 。它 是 一个 源 码 开放 的操 作 系统 , 有 良 具
收 稿 日期 :070 -9 20 -31 修 订 日期 :07 6 6 20 - - 0 0
作者简 介: 马
辉( 9 2) 男 , 1 7 一 , 山西芮城人 , 高级工程师 , 研究 方向为计算机应用及系统仿 真。
维普资讯
20 07年 7月
的标 准 函数 ,C s 许 多软 件包 提 供 对 现有 A I的兼 eo有 P
容 , P SX和 IT O 应 用程序 可 以调 用 一些 标 准 如 OI x R N, l 函数 如 phed c a t a—r t r e e来使 用 内核服务 。
r . …………一
荏 ……………
嵌入式系统 主要 由嵌 入式 处理 器 、 关 支撑 硬件 、 相
理 、 务 f通 信 、 任 司 例外 处理等 。e o 内核结构 如 图 1 Cs 所

eCos用户指南之手动配置_翻译

eCos用户指南之手动配置_翻译
这段允许配置工具重载各种包形成配置。大多数信息不应该被编辑。如果需
要增加一个新包或者删除一个已存在的包应该用合适的工具,例如:
$ ecosconfig remove CYGPKG_LIBM
有 两 个 地 方 可 以 编 辑 。 配 置 有 个 名 字 , 这 里 是 eCos ; 有 一 个 描 述
跟着头段的段定义配置的整体。一个典型的例子是:
# ---- toplevel -------------------------------------------------------# This section defines the toplevel configuration object. The only # values that can be changed are the name of the configuration and # the description field. It is not possible to modify the target, # the template or the set of packages simply by editing the lines # below because these changes have wide-ranging effects. Instead # the appropriate tools should be used to make such modifications.
eCos User Guide(Chapter 28.manual Configuration)
eCos 用户指南之手动配置_翻译
翻译:JARI TOOL
1. 编辑一个 eCos 存档文件
eCos 配置信息存放在一个存档文件(savefile)中,典型的是 ecos.ecc, 这个文件既可以通过 GUI 界面配置工具产生,也可以通过命令行 ecosconfig 配 置工具产生。这个文件通常存在于编译树(build tree)的顶层。它是一个文本 文件,允许通过文本编辑器、其它程序或脚本来编辑各种配置选项,也可以在 GUI 配置工具里编辑。

三种开源嵌入式操作系统的比较

三种开源嵌入式操作系统的比较

;i●■三种开源嵌入式操作系统的比较苟军年(兰州交通大学自动化与电气工程学院甘肃兰州730070)信息科掌【捕要】嵌入式操作系统的性能和选择是大多数嵌入式系统开发都要面临的问题。

比较3种开源嵌入式操作系统嵌入式L i nu x、Q N x和ecos,分析3种开源操作系统的主要性能,并根据分析结果指出各自的适用领域.【关键词】嵌入式操作系统RT O S嵌入式系统中图分类号:TP316.2文献标识码:A文章编号i1671--7597(2008)1110061--01一、三种开曩E O S介绍(一)嵌入式L i M U X.L i n ux是一个类似于U ni x的操作系统,它已经是最为流行的一款开放源代码的操作系统。

嵌入式L i nux由于其源代码公开,人们可以任意修改来满足自己的应用。

像大多数自由软件一样,L i nux遵从G PL,因此使用它无须为每例应用交纳许可证费。

Li nux下的应用软件大量可用,其中大部分都遵从GPL,是开放源代码和免费的。

稳定是L i nu x本身具备的一个很大优点。

内核精悍,运行所需资源少,支持的硬件数量庞大等都是Li nux所具备的.(二)O N X∞。

Q N)【O S是由0N X软件系统有限公司开发的一套实时操作系统,它是一个实时的、可扩展的操作系统,部分遵循了PO S I X( Por t abl e O per a t i ng S ys t em I nt er f ace of U ni x)相关标准,可以提供一个很小的微内核及一些可选择的配合进程。

其内核仅提供4种服务:进程调度、进程阃通信、底层网络通信和中断处理。

(三)e C os。

e C os(e m be dde d C onf i gur a bl e oper a t i ng syst em),即嵌入式可配置操作系统。

它是一个源代码开放的可配置、可移植、面向深度嵌入式应用的实时操作系统。

其最大特点是配置灵活,采用模块化设计,包括内核、c语言库和底层运行包在内的核心部分由不同的组件构成。

eco-system

eco-system

eco-system
什么是eco-system?它是⼀个⽣态链系统,⼀个⽣态供应链系统,⼀个⽣态产业链系统。

因为它是⽣态,少不了绿⾊环保;因为它是链,少不了数字⽹络互联;因为它是系统,⾥⾯的各个主体错综复杂的交织在⼀起但都是和谐存在和发展的,每个个体都在努⼒的追求⾃⼰的发展,它的组织的结构使资源达到最有效的配置,能够使各个主体在数量和反应性上达到协同,能够发挥个体最⼤价值来创造⾼质量的⽣态环境。

每个⽣态链达到最优,同时追求整个供应链上的所有⽣态链协同最优,就是⽣态供应链;每个⽣态供应链达到最优,同时追求整个产业互联和协同发展就是⽣态产业链。

eCos在基于ARM7硬件平台上的应用

eCos在基于ARM7硬件平台上的应用

ecos 在基于AR M 7硬件平台上的应用北京航空航天大学钱问发满庆丰耿春明摘要简单介绍e Cos 的体系结构!详细论述e Cos 的可配置机制的实现原理!重点介绍e Cos 在以AT 9l M 55800为核心的AR M 7硬件平台上的移植步骤!结合本系统简要介绍内核的配置方法"最后给出了基于e Cos 应用软件的编写方法"关键词e Cos 可配置机制AR M 7移植硬件平台e Cos (Embedded Confi g urabl e O p erati n g S y st e m >最初是由C yg nus Sol uti ons 公司为面向嵌入式领域而开发的源码公开\具有很强的可移植性和可配置性的9适合于深度嵌入式开发的实时操作系统o 现在e Cos 主要由e Cos-Centri c 公司和e Cos 开源社区共同开发维护o e Cos 的特性9特别是它的可配置性9能有效缩短嵌入式产品的开发周期并降低成本o1eCos 的体系结构及可配置性1.1eCos 体系结构e Cos 采用模块化设计9将不同功能的软件分成不同的组件9使其分别位于系统的不同层次o 这种层次结构实现了e Cos 的可配置性\可移植性\兼容性和可扩展性o 图l 是e Cos 系统的层次结构框图o 硬件抽象层(HAL >使其上层次结构不必关心具体的硬件结构9因此只需对HAL 进行修改就可以使整个e Cos 的应用移植到新的硬件平台上o图1eCos 的层次结构框图内核是e Cos 的一个核心组件9也是系统的一个可选组件9一些较为复杂的应用需要内核的支持o 内核提供了多个可供选择的调度算法9可以很好地支持多任务处理o e Cos 内核提供了一组丰富的同步源语9完全能满足各种嵌入式应用的需求o 内核还负责对中断和例外进行处理9它的中断滞后处理机制保证了系统的实时性o 此外9内核还具有内存分配机制和定时机制9并提供多线程GDB 调试支持o 内核为上层软件和应用软件提供了丰富的AP I 接口函数oRedBoot 是一个无内核的系统引导程序9是e Cos 的一个特殊应用o RedBoot 可以加载e Cos 应用程序9并提供D ebu g 支持9是开发e Cos 系统时非常有用的工具o 设备驱动程序负责对硬件设备进行控制和管理9并完成设备数据的读/写操作o 设备驱动程序自身也采用层次结构9上层驱动程序(相当于一个虚设备>可以调用下层驱动程序(物理设备>o 驱动程序为上层软件提供标准的AP I 函数9应用程序可以使用这些AP I 函数对设备进行访问oe Cos 包含的网络支持包支持完整的TCP /I P 网络协议栈o e Cos 还提供了标准库(ANS I C 库和数学库>\兼容层(POS I X 兼容和uI TRON 兼容>\文件系统等o 作为一种开放软件9e Cos 还可以很方便地容纳第三方软件o1.2可配置性原理e Cos 的一个主要特性就是其可配置特性o 可配置性最终是靠代码中的条件编译来完成的9条件编译是编程语言的特点9并不是e Cos 的原创o 当一个软件工程中的条件编译项的数目和复杂性达到一定程度时9其中有一些条件编译项就会因为存在逻辑上的依赖关系而使条件编译产生冲突o 而如何发现并有效解决这种冲突才是e Cos 可配置性的特点9如图Z 所示9其可配置特性的实现主要由图2可配置机制组件定义语言CDL (C o m p onent D efi n iti on L an g ua g e )\组件仓库ecos .db \图形配置工具confi g too l 三者共同完成O!1"组件定义语言CDL CDL 是e Cos 组件框架中的一个关键部分9e Cos 所有模块的程序包中都包含一个CDL 脚本对该包进行描述并提供配置选项O 以本系统中的串口驱动程序包为例9在该包对应的CDL 中定义了一个名为CYGPKG _I O _SER I AL _AR M _AT 9l 的cdl _p acka g e O 在这个cdl _p acka g e 中详细列出了该包的一些属性9如该包必须在工程已经包含了硬件抽象层包CYGPKG _HAL _AR M _AT 9l 和上层串口I O 包CYGPKG _I O _SER I AL 的情况下才会被使能O 另外9串口的一些常用特性9如波特率\设备名\缓冲区大小等配置选项也是必不可少的O 在一些复杂的CDL 中还会包含对该包中的源程序进行编译时的一些编译选项O 在进行配置的时候9该包还会产生一个包含了各个可配置参数数值的头文件O 当其他包使用由CYGPKG _I O _SER I AL _AR M _AT 9l 包提供的可配置参数时9这个新产生的头文件就会被相关的源文件通过#i ncl ude 语法包含O !2"组件仓库ecos .dbecos .db 是一个包含了所有可用程序包和配置模版的文本文件O 在该文件中9需要注册所有的CDL 包O 在注册时以p acka g e 关键字提供相应包的名称\CDL 脚本文件的文件路径以及对该包的一个简单描述O 在ecos .db 中还会以tar g et 关键字生成配置模版9从而提供目标平台的一些基本组成结构9使目标平台包括所需要的已经注册了的CDL 配置包O !3"图形配置工具confi 9t oo lconfi g t ool 是利用MFC 编写的W i ndo Ws 程序9是e Cos 可配置性的执行者9也可以理解成是CDL 脚本的解释器O 一方面它读取ecos .db 文件中的目标平台和已注册的配置包信息9根据配置包的路径找到相应的CDL 脚本9然后根据脚本中给出的属性向程序员提供图形化的配置信息;另一方面9它还可以接受用户的输入9包括单选按钮\复选框\下拉列表\文本输入等O 当用户保存一个配置时9confi g t ool 会根据CDL 语言的提示生成相应的头文件9也会将指定的头文件从配置包中复制到配置文件所在的工作目录O 无论是生成的头文件还是拷贝的头文件9都会在编译时被源程序所引用O 对于内核源程序9confi g t ool 又可以理解成编译器O 当用户的配置选项被保存并且对工程进行编译时9confi g t ool 会在后台调用真正的编译器GCC 9根据配置包CDL 中的编译选项控制GCC 对所有需要的内核源文件进行编译并生成库文件和对应的链接脚本O 当然confi g t ool 只是对e Cos 内核进行编译9用户的应用程序只需在编译时和由confi g t ool 编译生成的库文件进行链接就可以得到最终的可执行映像文件O2系统硬件框架本系统是一个以AR M 7为核心构成的测控系统9通过对传感器的脉冲信号进行处理而得到待测物料的流量9并通过控制给料器的给料速度达到流量控制的目的O 对于一个有实用价值的测控系统9必须具有人机交互\闭环控制\数据通信和存储等功能O 本课题所研制的流量测控系统的硬件框图如图S 所示O图3流量测控系统硬件框图图S 中9处理器为AR M 7内核的工业级芯片AT 9l M 558009其强大的功能保证了系统的实时性和稳定性的要求O Z MB 的F l ash SST S9VFl 60用来保存程序代码\测量所需的一些参数以及测量结果的简单统计信息O 在工业生产中9经常需要对一次测量中的数据进行历史再现9以便对一些事故或故障进行排查O 本系统通过采用l MB 的大容量RA M 来实现这一功能C 除了用来作为程序运行时的内存外9RA M 还用来实时保存每一时刻的测量数据O USB 总线的通信口用来和现场计算机进行通信9以实现一些更加完善的处理9如数据打印\结果分析\实时数据的硬盘保存等O 分辨率为SZ 0>Z 40的LCD 用来作为系统的显示终端配合4>5的键盘来完成系统的人机交互操作O 对变频器的控制和对温度信号的采集通过485总线完成O 6路脉冲信号是本系统测量功能的核心9通过对这6路脉冲进行处理可以得到流量相关的所有信息O 4~Z 0mA 电流信号用来控制给料系统9以实现闭环控制O 由于在工业环境中使用9对于一些长线连接必须采取隔离措施O 本系统对测量脉冲\485通信信号和4~Z 0mA 电流信号都采取了光电隔离措施O3eCos 在系统上的移植与应用软件编写3.1eCos 内核的移植由于e Cos 内核采用了可配置的模块化设计思想9因此只要修改硬件抽象层HAL的代码和CDL脚本并且在ecos.db中注册就可以应用于新的目标系统HAL又可以细分为S个层次①体系结构抽象层e Cos是可以应用于多种体系结构平台上的操作系统如AR M M I PS PO WERPC等在e Cos发布时已经将这些体系结构层的移植包一同发布了出来本系统的体系结构抽象层是AR M7体系结构抽象层②变体抽象层对于同一种体系结构的处理器各生产厂家会有不同的系列和型号如A t m el的AT9l系列Phili p s的LPC系列等虽然它们都采用AR M7体系结构但是不同的寄存器配置模式和中断处理方法也会影响到e Cos的移植本系统所使用的处理器AT9l M55800使用较为普遍在e Cos开源社区已经有移植好的AT9l M55800变体抽象层的代码和CDL 脚本只需作系统启动后对I O口的赋值情况等少许的改动即可完成对变体抽象层的移植③平台抽象层平台抽象层是对目标系统的整个硬件平台进行抽象包括平台的启动芯片配置定时I O寄存器及中断寄存等等系统需要进行的移植工作主要是平台抽象层的移植而平台抽象层中最重要的是F l ash驱动包和内存布局文件的移植主要的步骤为①安装AT9l M55800变体抽象层包从e Cos开源社区下载好的变体抽象层包在一个名为eb55的文件夹中在这个文件夹中还有cdl i ncl ude src等子文件夹分别包含了CDL脚本头文件源文件由于e Cos的软件包有严格的层次结构所以在安装软件包时应遵循这一结构以便于维护AT9l M55800属于AR M7的一个变体同AT9l系列的其他CP U处于同一层次所以变体抽象层软件包文件夹eb55的具体路径应为hal ar m at9l eb55接下来还应在ecos.db中注册变体抽象层包以p acka g e 关键字注册名为CYGPKG_HAL_AR M_AT9l_EB55的包这个名字必须和包中CDL文件hal_ar m_at9l_eb55.cdl中的所定义的包名完全一致在包名后面的花括号中登记hal_ar m_at9l_eb55.cdl文件的路径及文件名以及对该包的简单文字说明②编写F l ash的底层驱动软件包以便能够操作目标系统的F l ash存储器由于本系统在前期调试和代码固化时利用了RedBoot而RedBoot通过F l ash驱动程序操作目标F l ash所以必须先移植好F l ash驱动程序才能进行更进一步的开发工作首先需要编写底层驱动程序源文件不同的F l ash 的块空间大小以及写操作一般是不一样的本系统所用的F l ash SST S9VFl60是Z MB的l6位NOR F l ash共有5l Z0XZ00个块空间其块大小为4K0Xl000写操作的命令码符合J EDEC标准这些特点与A t m el公司AT49系列F l ash比较类似因此F l ash驱动程序可以从e Cos发布时自带的AT49系列F l ash的驱动程序修改得到最重要的地方是修改描述F l ash特性的结构体fl ash_dev_i n-f o_t变量中成员bl ock_siZe和bl ock_count的值使其分别为0Xl000和0XZ00接下来需要编写与F l ash底层驱动对应CDL脚本使配置工具confi g t ool能够正确配置编译F l ash驱动程序这个CDL文件完全可以参照AT49驱动包中的CDL 文件编写以cdl_p acka g e关键字定义名为CYGPKG_DEVS_F l ash_SST_S9VFl60的包在命令体中给出具体的配置参数由于底层驱动包必须结合上层驱动才能工作所以在命令体中用acti ve_if CYGPKG_I O_F l ash命令告诉confi g t ool必须在上层驱动包CYGPKG_I O_F l ash 已经被包含的情况下底层驱动包才会使能最后需要在ecos.db中注册底层驱动软件包具体做法和变体抽象层包的注册方法相同③修改内存布局文件使confi g t ool能够正确定位程序在系统存储器中的位置e Cos提供S种不同的运行方式即ROM方式RA M方式ROMRA M方式每种模式都有两个相应的布局文件如RA M方式的m lt_ar m_at9l_eb55_ra m.l di和m lt_ar m_at9l_eb55_ra m.h%.l di 和常见的AR M开发环境ADS中scatt ered链接方式下的%.scf文件的作用类似即用来对不同段分别指定不同的链接地址在%.l di中需要修改ME MORY和SECT I ONS两部分对于代码在RA M中运行的内核及应用程序需要根据系统RA M的实际情况修改内存布局文件中相关参数的值本系统具有l MB的RA M但有一半用来存放测量数据根据系统实际的硬件情况其起始地址为0X0Z000000大小为0X80000所以这个内存块定义为ra m OR I G I N=0X0Z000000LENGTH= 0X80000处理器内部集成了8KB SRA M其起始地址为0大小为0XZ000所以这个内存块定义为sra m OR I G I N =0X00000000LENGTH=0XZ000这样系统的ME MO-RY部分就由名为ra m和sra m的两个内存块构成系统比较重要的两处SECT I ONS部分的修改为SECT I ON_fi Xed_vect ors sra m0XZ0L MA_E@_V MA和SEC-T I ON_r o m_vect ors ra m0X0Z008000L MA_E@_V MA第一处表示fi Xed_vect ors段分配在从0XZ0开始的sra m中且L MA_E@_V MA指定其加载地址等于虚拟地址由于RedBoot运行时需要占用从0X0Z000000开始的一定空间的RA M所以第二处使程序代码从0X0Z008000开始的ra m中运行%.l di文件修改完毕后需要相应地修改%.h文件中的宏如#defi ne CYG ME M_REG I ON_ra m0X0Z000000④在组件仓库ecos.db中为以关键字t ar g et添加名为F l o W55的新目标平台在这个目标平台中还必须用关键字p acka g es 包括AR M 7体系结构层包和AT 9l M 55800变体抽象层包,同时为了实现调试还必须包括串口驱动包和F l ash 驱动包及其上层驱动包 除了这些被包含的软件包外,根据不同的选择confi g t ool 还会为目标平台包添加一些默认的包,如内核包 数学库包等 另外,还应加入一些对该平台的简单描述3.2内核的配置移植完成以后,一个最基本的目标平台就产生了 在confi g t ool 中可以看到T e m p l at es 菜单的硬件平台列表中新增了F l o W55目标平台模版,以def ault 方式打开这个模版 各个软件包的CDL 脚本中都给出了默认的配置值,有些值需要根据具体的应用要求重新配置 本系统一些重要的配置情况如下①由于系统线程数量较少<小于l 0>,所以选择效率更高的位图调度器B it m a p schedul er ,并将线程数nu mbers of p ri orit y l evels 限定为l 6,以提高任务切换的速度 当点击位图调度器的单选按钮时,confi g t ool 会检测到一个配置冲突 由于时间片轮转是默认使能的,而时间片轮转仅仅对应于多级队列调度器,所以出现配置冲突 Confi g t ool 会给出一个推荐的解决冲突的方法,即禁止时间片轮转,按照这个推荐的解决方法可以安全地解决这个冲突 这个地方可以充分体现出e Cos 强大的可配置性②由于配合RedBoot 一起使用,所以内核配置为RA M 启动方式 这样,系统上电后程序将由RedBoot 复制到RA M 中运行,以提高速度③系统的晶振频率为l6MH Z ,经PLL 倍频后为SZ MH Z ,所以需将C lock s p eed 配置为SZ000000~RTC 是系统的时钟节拍发生器,本系统的时钟节拍时间选为Z0m s ,所以也需要对RTC 相关项进行配置 具体参数为R eal-ti m e clock nu m erator 配置为Z000000000,R eal-ti m e clock deno m i nator 配置为l00,R eal-ti m e clock p eri od 配置为Z0000其余的配置选项使用默认的配置值即可 完成配置工作后,对内核进行编译可以产生内核库文件和链接脚本以及相关头文件 这些生成的文件再同应用程序一起编译 链接,生成最终的可执行映像文件图4应用软件结构3.3基于eCos 操作系统的应用软件的编写e Cos 是一个单进程多线程的操作系统,多个线程在宏观上可以认为是并发运行的,而且各线程之间耦合低,便于软件的编写和维护 针对这一特点,本系统的软件结构如图4所示本系统主要有两种程序运行方式,分别称为方式A 和方式B 方式A 中,硬件中断产生后,相应的I SR <I n-t err u p t S er vi ce Routi ne >程序运行,由于I SR 中是禁止中断的,所以在I SR 中只进行最简单的操作,I SR 退出后内核调用相应的DSR <D ef erred S er vi ce Routi ne > DSR 中中断是使能的,所以可以进行一些稍复杂的处理,如简单的数据运算 内核调用<发送信号量和邮箱等> 在得到相应的信号量或消息邮箱后,相应的线程进入就绪态被内核调度运行 本系统中对键盘的处理就是基于这种方式 按键产生硬件中断 I SR 执行,接着在DSR 中进行相应的运算得到具体的键值后以消息邮箱的方式通知并唤醒键盘处理线程,键盘处理线程在完成任务后进入休眠直到再次有按键发生而被唤醒 方式B 中,各线程只是周期性地被内核调度运行,如测量数据显示线程,在显示一次数据后调用延时函数进入休眠,直到延时完毕后再次进入就绪态被内核调用根据测控系统的实际情况,具体的线程编写如下 方式A 为流量计算线程 温度测量线程 键盘处理线程 USB 通信处理线程 方式B 为测量数据显示和曲线绘制线程 流量控制线程 初始标定线程4结论经过实践,本系统运行稳定,实时性能良好 由于e Cos 的强大可配置性使得系统的软硬件可维护性强,在进行硬件改动或应用要求改动后可方便地进行升级参考文献l M assa A J .嵌入式可配置实时操作系统e Cos 软件开发M .颜若麟,等译.北京 北京航空航天大学出版社,Z 006. Z 蒋句平.嵌入式可配置实时操作系统e Cos 开发与应用 M .北京 机械工业出版社,Z 004.S 王京起,等.嵌入式可配置实时操作系统e COS 技术及实现机制 M .北京 电子工业出版社,Z 005.4 马忠梅,等.AT 9l 系列AR M 核微控制器结构与开发 M .北京 北京航空航天大学出版社,Z 00S .5 Red Hat I nc &e Cos Centric L t d .e Cos U ser s Gui de .Z 00S .6 聂慧萍.新型固体科里奥利流量计测控系统研究 D .北京 北京航空航天大学,Z 005.钱问发<硕士研究生> 主要研究方向为工业测控网络与嵌入式系统应用;满庆丰<教授>.耿春明<副教授> 主要研究方向为工业测控网络与现场总线.嵌入式系统应用等<收稿日期:Z 006-l l-l 5>。

几种嵌入式实时操作系统的分析与比较

几种嵌入式实时操作系统的分析与比较

⼏种嵌⼊式实时操作系统的分析与⽐较VxWorks、µClinux、µC/OS-II和eCos是4种性能优良并被⼴泛应⽤的实时操作系统。

本⽂通过对这4种操作系统的主要性能进⾏分析与⽐较,归纳出它们的选型依据和适⽤领域。

1 4种操作系统的介绍(1)VxWorksVxWorks是美国WindRiver公司的产品,是⽬前嵌⼊式系统领域中应⽤很⼴泛,市场占有率⽐较⾼的嵌⼊式操作系统。

VxWorks实时操作系统由400多个相对独⽴、短⼩精悍的⽬标模块组成,⽤户可根据需要选择适当的模块来裁剪和配置系统;提供基于优先级的任务调度、任务间同步与通信、中断处理、定时器和内存管理等功能,内建符合POSIX(可移植操作系统接⼝)规范的内存管理,以及多处理器控制程序;并且具有简明易懂的⽤户接⼝,在核⼼⽅⾯甚⾄町以微缩到8 KB。

(2) µC/OS-IIµC/OS-II是在µC-OS的基础上发展起来的,是美国嵌⼊式系统专家Jean J.Labrosse⽤C语⾔编写的⼀个结构⼩巧、抢占式的多任务实时内核。

µC/OS-II 能管理64个任务,并提供任务调度与管理、内存管理、任务间同步与通信、时间管理和中断服务等功能,具有执⾏效率⾼、占⽤空间⼩、实时性能优良和可扩展性强等特点。

(3)µClinuxµClinux是⼀种优秀的嵌⼊式Linux版本,其全称为micro-control Linux,从字⾯意思看是指微控制Linux。

同标准的Linux相⽐,µClinux的内核⾮常⼩,但是它仍然继承了Linux操作系统的主要特性,包括良好的稳定性和移植性、强⼤的⽹络功能、出⾊的⽂件系统⽀持、标准丰富的API,以及TCP/IP⽹络协议等。

因为没有MMU内存管理单元,所以其多任务的实现需要⼀定技巧。

(4)eCoseCos(embedded Configurable operating system),即嵌⼊式可配置操作系统。

嵌入式系统uclinux和ecos的比较

嵌入式系统uclinux和ecos的比较

m c o c n o— i u 的缩写。同标准 l n x 比,它集成了 ir — o r l l n x iu 相
句话 “a ir tn e a o p k— X X B g M p ” C l b a i g d l y l o .o X o o i s,
标准 l n x i u 操作系统的稳定性 、 强大网络功 能和出色的文件
Ab ta tE b d e p r t n y t m i m e d d s s e h o e o p l c t o .T e c n r s h t t i a e sr c: m e d d o e a i g s s e s e b d e y t m t e c r f a p i a i n h o t a t t a h s p p r

要:嵌入 式操作 系统是嵌入 式系统应用 的核心。本文通 过对 两种典型 的开 源嵌 入式操作 系统 的对 比,分析和 总结
了嵌入 式操作 系统应用 中的若 干问题, 归纳 了嵌入 式操作 系统 的选型依据 。 关键词: 嵌入式: 操作 系统 中图分类号 :T 3 P 1 6 文献标识码 :A 文章编号 :1 7 一 7 2 (0 64 0 7 — 3 l 4 9 ~ 2 0 )— 0 8 0 6
嵌 入 式 系 本文通 i 统 o 过对 u o O 和 n o 以 通过 比较 , 能够为大家选择适合 自 广泛应用的的免费嵌入式操作系统 。 c I c×和 lnx 比 皎 以下几个方面进行 比较 。 c iu 的
eo的对比, cs 分析和总结 了嵌入式操作系统 应用 中的若干重
要问题 ,归纳 了嵌入式系统开发 中操作系统的选型 依据 。
嵌入式可配置操作系统 。 c s R d a e o 是 e H t的产 品,但是 e o cs 并不是 L n x L n x的派生,e o 弥补 了 L n x iu 或 iu cs iu 在嵌入式

ECOS介绍

ECOS介绍

ECOSECOS由Redhat推出的小型即时操作系统(Real-Time operating system),最低编译核心可小至10K的级别,适合用于作bootloader增强,微小型系统。

此系统和嵌入式Linux系统的差异是他将操作系统做成静态连结(static library)的方式,让应用程式透过连结(linker)产生出具有操作系统的特性的应用程式。

eCOS的全称为embedded Configuration operating system,eCOS是开放原码、免权利金的即时作业系统,这套作业系统是真对嵌入式系统及应用而设计,因此是以单一个行程1)再搭配多个执行绪的方式来执行。

eCos最大的特点是内核可配置。

它出生于1997年,相对其他的系统来说是非常年轻的,但是也正是因为出身的晚,所以在设计理念上面是比较新颖的。

其全部代码使用C++编写。

eCos 可以说是嵌入式领域的一颗新星,全称是Embedded Configurable Operating System。

绝大多数代码使用C++写作完成。

最早是 Cygnus公司开发(是不是想到Cygwin了?),不久被RedHat收购,现在RedHat又放弃了RedHat项目,解雇了eCos的开发人员,将他踢到了Free Found Org。

eCos最大的特点是模块化,内核可配置。

如果说嵌入式Linux太庞大了,那么eCos可能就能够满足要求。

它是一个针对16位、32位和64位处理器的可移植开放源代码的嵌入式RTOS。

和嵌入式Linux不同,它是由专门设计嵌入式系统的工作组设计的。

ECOS具有相当丰富的特性和一个配置工具,后者能够让你选取你所需要的特性。

Linux兼容的嵌入式系统在内核裁减后编译出来的二进制代码大小在500k字节以上,这还只包含最简单的内核模块,几乎没有加载任何其他的驱动与协议栈。

但是eCos最小版本只有几百K字节,一般,一个完整的网路应用,其二进制的代码也就100K字节左右。

ecos自学历程

ecos自学历程

ecos自学历程回顾我的ecos自学历程(一)环境安装篇转载-- 回顾我的 ecos 自学历程(一)环境安装篇前言:开篇之季,我先说一下我的ecos经历吧。

每个人都有过初学者的经历,初学ecos的时候我问了许多令网友老大啼笑皆非的问题,不过还是感谢这位热心的老大哥帮忙我才逐步的了解了ecos,从初学者变成了ecos的使用者。

从初学到使用也就是一共三个月的时间,三个月后我转正了,也转向了专功uclinux和linux的移植和驱动的编写,再也没有很好的研究过ecos,直到最近帮同事移植ecos,才重新回顾了那段刚刚参加工作的岁月。

刚来公司的时候,我的第一个任务就是做ecos上面的网络应用,但是我只拿到了一块板子,内核什么的都没有,怎么做?刚来公司的时候情况比较特殊,其他的同事都没有这方面的经验,而我们副理正好赶上生孩子,什么也没给我留下,所以便开始了ecos的郁闷之旅:),可以说ecos完全是自学的。

首先我google了一下什么叫ecos :),然后开始查查有没有好的论坛站点,然后看看有什么样的书可以要我看。

很可惜ecos在资料方面一直都很欠缺。

在网上找了个ecos方面的老大,很可惜现在他已经不怎么上网了,丢了联系方式。

就这样我正式开始了我的ecos学习!我们副理给我的只有ecos2.0的代码和编译器arm-tools 两个文件,第一步肯定是要安装了,很简单,那时候没人教我自己很快就装好了,哈哈!第一步:cygwin安装(下载here)一个在windows平台上运行的unix模拟环境。

具体的网上多的是就不解释了,下载得到cygwin后就可以点:setup.exe安装了。

(1)选择需要的安装文件的位置,一般我们都本地安装,因为下载cygwin又不费事。

下一步(2)提示用户选择安装位置,随便你选择。

Dos or unix?我一般都选unix,二者只是文件结尾的不同,前者/r/n 结尾,后者是/n结尾。

下一步(3)选择你要安装的cygwin包,我一般或者说肯定选完全安装,因为以前吃亏过,一通乱选到后来啥都找不到了,还不如完全安装呢,耗不了你多少空间,现在电子产品都便宜了,完全安装后下一步。

文入式操作系统uClinux和eCos的比较

文入式操作系统uClinux和eCos的比较
度 ( 别 为 2 6 1 、 2 、2 4 分 5 、5 2 1 4 8字 节 ) 以 观 察 不 同 的 块 0 0 , 长 度 对 存 储 器 访 问性 能 的 影 响 。表 2是 实 验 的结 果 : 向 横
2 基本 操 作 性 能 的 比较
2 1 应 用 程 序 的 运 算 能 力 .
维普资讯

_
嵌 入式 操作 系统 u l u C x和 e o i n C s的t 较 匕
■ 东 华 理 工 学 院 戴 晟 晖 张 良 清
关键词
嵌 入式
操 作 系统
e o u i u C s Cl x n
看 1 S可 以 循 环 多 少 次 , 后 除 以 5 0 0 0 就 得 到 了 然 0 0
2 2 存储 器 访 问 能 力 .
采 用 一 种 同时 能 够 测 试 缓 冲 控 制 器 和标 准 存 储 器 访 问 函数 的测 试 方 法 来 测 试 存 储 器 访 问能 力 。在 这 里 , 用 选 田纳 西 大 学 的 P ipJ hl .Mu c 等 人 提 出 的 Ca h B n h方 i ci ceec
在 In x和 u l u u i C i x操 作 系 统 启 动 的 时 候 , 会 有 这 n 都 样 一 句 话 — — C l rt gd lylo . k— X XB g Mis ai ai ea p .o b n o X o o p , 这 一 过 程 叫作 B g Mis 读 作 b g mis 。 Ln sTo v ls oo p ( o u p ) iu rad 引入 B g Mis主 要 有 两 个 目 的 :① 给 用 户 一 个 大 概 的 oo p
系统 运 算 能 力 的 概 念 ; 由 于 系统 中 有 许 多 代 码 需 要 精 ②

PC端操作系统、移动端操作系统、嵌入式操作系统

PC端操作系统、移动端操作系统、嵌入式操作系统

PC端操作系统、移动端操作系统、嵌⼊式操作系统左侧部分已是历史的操作系统,右侧的还是活跃的操作系统。

安卓系统Android 是Google开发的基于Linux平台的开源⼿机操作系统。

它包括操作系统、⽤户界⾯和应⽤程序—— 移动电话⼯作所需的全部软件,⽽且不存在任何以往阻碍移动产业创新的专有权障碍。

iOSiOS是由苹果公司开发的移动操作系统[1]。

苹果公司最早于2007年1⽉9⽇的Macworld⼤会上公布这个系统,最初是设计给iPhone使⽤的,后来陆续套⽤到iPod touch、iPad以及Apple TV等产品上。

iOS与苹果的Mac OS X操作系统⼀样,属于类Unix的商业操作系统。

Windows phoneWindows Phone(简称:WP)是微软发布的⼀款智能⼿机操作系统,它将微软旗下的Xbox Live游戏、Xbox Music⾳乐与独特的视频体验集成⾄⼿机中。

Firefox OSFirefoxOS,专案名称为Boot to Gecko。

是由谋智公司(Mozilla Corporation)主导研发的开放源代码移动操作系统,采⽤Linux核⼼,应⽤于智能⼿机。

采⽤开放⽹络(open Web)技术,它以Gecko浏览器引擎为核⼼,采⽤HTML5相关的Web前端技术开发。

不过在2015年12⽉Firefox 宣布关闭对Firefox OS的维护。

Ubuntu移动版操作系统Ubuntu是⼀个以桌⾯应⽤为主的Linux操作系统。

与Windows和Mac OS相⽐,Ubuntu尽管普及程度远不及前者,但得益于开源、免费等特性,在世界各地仍然拥有⼤量拥趸。

如果你是魅族⼿机的忠实粉丝,那么Ubuntu(乌班图)你肯定很熟悉:在2014年,Ubuntu正式宣布与魅族合作推出乌班图版MX3,正式开启了Ubuntu系统的魅族时代。

此后也推出了Ubuntu版的MX4和Pro 5,⼝碑也甚好。

YunOSYunOS是我们国家国产的操作系统⼀枚新星,虽然⽬标不仅仅是⼿机,更多的智能设备都可以⽤YunOS操作,系统是基于Linux研发,搭载⾃主研发的核⼼操作系统功能和组件,⽀持HTML5⽣态和独创的CloudCard应⽤环境,增强了云端服务能⼒。

几种嵌入式实时操作系统的研究与比较

几种嵌入式实时操作系统的研究与比较

几种嵌入式实时操作系统的分析与比较2008-07-04 20:54VxWorks、μClinux、μC/OS-II和eCos是4种性能优良并被广泛应用的实时操作系统。

本文通过对这4种操作系统的主要性能进行分析与比较,归纳出它们的选型依据和适用领域。

1. 4种操作系统的介绍(1>VxWorksVxWorks是美国WindRiver公司的产品,是目前嵌入式系统领域中应用很广泛,市场占有率比较高的嵌入式操作系统。

VxWorks实时操作系统由400多个相对独立、短小精悍的目标模块组成,用户可根据需要选择适当的模块来裁剪和配置系统;提供基于优先级的任务调度、任务间同步与通信、中断处理、定时器和内存管理等功能,内建符合POSIX(可移植操作系统接口>规范的内存管理,以及多处理器控制程序;并且具有简明易懂的用户接口,在核心方面甚至町以微缩到8 KB。

(2> μC/OS-IIμC/OS-II是在μC-OS的基础上发展起来的,是美国嵌入式系统专家Jean J.Labrosse用C语言编写的一个结构小巧、抢占式的多任务实时内核。

μC/OS-II能管理64个任务,并提供任务调度与管理、内存管理、任务间同步与通信、时间管理和中断服务等功能,具有执行效率高、占用空间小、实时性能优良和可扩展性强等特点。

(3>μClinuxμClinux是一种优秀的嵌入式Linux版本,其全称为micro-control Linux,从字面意思看是指微控制Linux。

同标准的Linux相比,μClinux的内核非常小,但是它仍然继承了Linux操作系统的主要特性,包括良好的稳定性和移植性、强大的网络功能、出色的文件系统支持、标准丰富的API,以及TCP /IP网络协议等。

因为没有MMU内存管理单元,所以其多任务的实现需要一定技巧。

(4>eCoseCos(embedded Configurable operating system>,即嵌入式可配置操作系统。

eCos在基于MPIS架构Soc上的移植实现

eCos在基于MPIS架构Soc上的移植实现
e o 支持 1 ,2 6 Cs 6 3 ,4位嵌入式处理器 , 具有完全 支持多任务
设 备 驱
动 程
e o 实时操作系统 ,
抢 占式管理 、 最小 的中断延时 、 完善 的同步机 制、 调度策略 、 中断 处理等特点 。非常适 合在 消费品电子 、 通信 、 汽车 电子及其它嵌
维普资讯
第2 4卷 第 1 2期
20 0 7年 1 2月
计 算机 应 用与软件
C mp tr A pi ai n n ot a e o u e p l t sa d S f r c o w
V0 . 4 No 1 12 . 2
D c2 0 e .0 7
MI S 2 c r , e e a t o o r n pa tn C st n e e d d pa fr i p o o e . h e on sf r h a s l n r ic s e a d P 3 oe g n rl me h d fr t s ln i g e o o a mb d e lt m s r p s d T e k y p it e t n p a t e d s u s d, n a o o t r a
植, 阐述 e o 在嵌入式系统上的移植方法。重点讨论 了移植过程 中的一些关键 点, Cs 分析 了硬 件抽 象层的移植 方法。该移植 方案 已
经过 实 际测 试 , 系统 稳 定 可 靠 。 关 键 词 实 时操 作 系统 e o 硬 件 抽 象 层 MIS Cs P
REALI ZATI ON OF TRANS PLANTI NG ECOS TO SOC I W TH I M PS
中断处理 机制 , 以及系统对于存储 器的使用机制 , 如内存的地 诸

eCos系统

eCos系统
嵌入式系統設計~以ARM處理器為 基礎之SOC平台
eCos嵌入式系統的安裝與實作步驟 嵌入式系統的安裝與實作步驟(cont.) 嵌入式系統的安裝與實作步驟
– 接下來選擇選擇platform和 RedBoot template, 之後就可以開始建立Redboot
嵌入式系統設計~以ARM處理器為 基礎之SOC平台
嵌入式系統設計~以ARM處理器為 基礎之SOC平台
eCos vs. uClinux
• code size :
– 所產生出最小的uClinux大約為600Kbytes – eCos大約為60Kbytes
• 發展新的嵌入式系統之BSP
– eCos提供強而有力的packages管理工具 – uClinux要由經驗老道的人將BSP加入uClinux中
• 下圖為layer of eCos packages
嵌入式系統設計~以ARM處理器為 基礎之SOC平台
eCos基本介紹 基本介紹(cont.) 基本介紹
嵌入式系統設計~以ARM處理器為 基礎之SOC平台
eCos基本介紹 基本介紹(cont.) 基本介紹
• eCos的“可組態(Configurable)”:
• 實例三: 實例三:
– 同樣以 ARM+eCos的軟硬體平台還有I-JAM的I-Jam Multimedia L.L.C系列的播放器,像IIJ-888 DVD/MP3 Player、Win-Jam II 等。
• 實例四: 實例四:
– 像本土英業達公司所出產的OKWAP手機系列,其產品就是以功能 豐富、強大著稱,在市場上佔有很高的比率,OKWAP手機所使用 的嵌入式作業系統即是eCos
嵌入式系統設計~以ARM處理器為 基礎之SOC平台
  1. 1、下载文档前请自行甄别文档内容的完整性,平台不提供额外的编辑、内容补充、找答案等附加服务。
  2. 2、"仅部分预览"的文档,不可在线预览部分如存在完整性等问题,可反馈申请退款(可完整预览的文档不适用该条件!)。
  3. 3、如文档侵犯您的权益,请联系客服反馈,我们会尽快为您处理(人工客服工作时间:9:00-18:30)。

eCos内核概览eCos内核概览(1)实时内核eCos的核心是一个功能全面的,灵活的,可配置的实时内核。

这个内核提供了多线程支持,多种调度器的选择,一组丰富的同步原语,内存分配原语和线程管理函数。

在这个内核中,可以改变或替换其中的某些部分(比如调度器)而不会影响内核本身的别的模块。

下列是这个内核的一些特征:可以选择内存分配算法可以选择调度算法一组丰富的同步原语定时器,计数器和alarms中断处理exception处理cache控制线程支持内核支持用GDB进行多线程调试trace buffersinfrastructure and instrumentationeCos内核概览(2)调度器调度器是内核的核心。

它定义了线程运行的方式,提供了线程同步的机制。

它也控制中断是如何影响线程执行的。

没有一个调度器可以覆盖所有可能的系统配置。

我们需要几种调度策略来满足不同的需要。

这里提供了三种调度器。

位图调度器位图中每一位表示一个可运行的线程,而每个线程有一个独一无二的优先级,系统允许的线程数是有上限的。

多级队列调度器可以在相同优先级线程之间按时间片轮换,支持优先级继承。

lottery调度器目前在任何时候系统只支持一种调度器。

将来系统会允许多种调度器共存,但是这将会隐藏在现有的调度器API后。

为了能够安全调度,我们需要一种在并发访问中保护调度器数据结构的机制,传统的方法是在这个临界区禁止中断。

不幸的是,这增加了中断的最大dispatch延迟,在任何实时系统中都应当避免这种情形的发生。

eCos采用的机制是保持一个计数器,Scheduler::sched_lock。

如果它的值不为0,就防止了重新调度。

当前的中断通过调用Scheduler::lock()得到这个锁,它对这个计数器加1避免进一步的调度。

函数Scheduler::unlock()对这个计数器减1,如果它返回0,允许继续调度。

为了在中断存在的情况下这种机制能够很好地工作,需要ISR推迟执行任何引起调度(scheduler-oriented)的操作,直到这个锁将要为0。

为此我们把ISR的工作分割成两部分。

并把第二部分,DSR,写进队列,直到调度器认为运行它们是安全的。

(细节见第三章的中断和exception handler)在单处理器上,Scheduler::lock()仅仅是对Scheduler::sched_lock加1。

既然这个锁严格地被嵌套,Scheduler::lock()不需要一个读-修改-写周期。

当前线程正在运行这个事实意味着这个锁还没有被别的线程获得,因此它总是可获得的。

eCos内核概览(3)线程同步为了允许线程协调和竟争资源,提供同步和通讯机制是必要的。

传统的同步机制是互斥/条件变量和信号量。

eCos内核不但支持这些机制,它还提供了在实时系统中普遍用到的其它同步和通讯机制,例如event flags和消息队列。

在任何实时系统中必须处理的一个问题是优先级倒转(priority inversion)问题。

它出现在一个高优先级线程(错误地)被一个低优先级线程阻止了继续执行。

一般的例子是:一个高优先级线程等待一个互斥量,而这个互斥量正被一个低优先级线程所拥有,如果这个低优先级线程被一个中等优先级的线程剥夺了运行,那么就发生了优先级倒转,既然这个高优先级线程被一个不相关的较低优先级线程阻止了继续执行。

这里有好几种方法可以解决这个问题。

最简单的是运用一个优先级ceiling protocal。

所有获得这个互斥量的线程把它们的优先级提升到一个事先规定好的值。

它有如下不利因素:它需要事先知道使用这个互斥量线程的最高优先级;如果这个事先规定的值太高,它相当于一个全局锁禁止了所有的调度。

一个更好的解决方案是使用优先级继承协议,拥有互斥量的线程的优先级被提升到与正在等待这个互斥量的最高优先级线程的优先级相等。

这个技术不需要预先知道准备使用这个互斥量线程们的优先级。

当一个更高优先级线程处于等待时,只有拥有互斥量的线程的优先级被提升。

这种方法减少了对别的线程进行调度的影响。

但是它的不利之处在于:每次同步调用的开销增加了,因为每次都得遵守这个继承协议。

第三种方法是:认识到糟糕地选择了相对的线程优先级,因此这个发生优先级倒转的系统本身是有缺陷的。

在这种情况下,当发生优先级倒转时,内核要有能力检测到,并产生一个exception来调试这个系统。

eCos提供了一种相对简单的实现方式。

它只在多级队列调度器中有效,它同时不能完全正确地处理嵌套的互斥量的极端例子。

但是,它不但速度快而且是确定性的。

如果不需要互斥优先级倒转,可以disable它,这将减少代码大小和数据空间。

eCos内核概览(4)例外(exceptions)一个exceptions是一个同步事件,它由一个线程在执行时产生。

exception包括硬件引起的机器exception(比如除零,内存出错和非法指令)和软件引起的机器exception(比如deadline overrun)。

标准c++ exception机制代价太昂贵了而不能在这儿使用。

处理exception最简单和最灵活的方式是调用一个函数。

这个函数需要赖以工作的上下文,因此需要访问一些工作数据。

这个函数至少也需要exception号和一些可选参数。

exception handler接受一个数据参数,这个参数是一个用handler和上下文信息指针注册的值。

它也接受一个exception号和一个错误码,exception号用来确认哪个exception产生了,而错误码则包含处理这个exception时需要的额外信息(比如一个内存出错地址)。

从这个函数返回使得线程继续执行。

根据配置选项,exception handler可以是全局的也可以是每个线程一个(per-thread),或者两种情况都有。

如果exception handler是每个线程一个,必须把exception handler附带(attach)在每个线程上。

eCos内核概览(5)中断中断是由外设引起的异步事件。

在任何时候它们都有可能发生。

它们并不与当前正在运行的线程有一丝联系。

中断处理是RTOS设计中最复杂的一部分,主要由于it is the least well defined。

如何对中断向量命名,如何把中断递交给软件和如何屏蔽中断都是高度与特定CPU结构(有时候与特定板)相关的。

让我们考虑一下中断向量这个问题。

这儿是硬件支持主要的差异:Intel和680X0支持把中断导引(vectored)到它们自己的向量上,而大多数RISC只有一个向量。

第一种情况,可以直接把ISR附带在这个向量上;第二种情况,必须确定实际是哪个外设产生中断,然后导引到正确的ISR。

如果这儿有一个外部中断控制器,将有可能对它进行查询并硬件实现本来是由软件实现的一些操作。

如果没有外部中断控制器,就必须依次调用ISRs对外设进行测试来决定产生中断的外设。

既然两个外设可以同时产生中断,那么每次中断产生时,就必须调用所有的ISRs。

屏蔽中断也有同样的问题。

大多数处理器在状态寄存器上有一个简单的中断屏蔽位。

而680X0有七级屏蔽。

可以对任何带有中断控制器的板进行编程提供相同的多级屏蔽。

必须保持中断屏蔽机制简单和高效,同时只需要CPU结构支持。

操作一个板上的中断控制器代价可能太高。

然而,个别的设备驱动程序可能需要访问中断控制器上个别的屏蔽位,因此必须提供这种支持。

eCos内核概览(6)计数器、时钟、ALARM和定时器如果硬件提供一个周期性时钟或定时器,它们将会用来驱动与定时有关的系统features。

很多CPU结构现在都有内嵌的定时寄存器,它们可以提供一个周期性中断。

应当用它们来驱动这些features。

要不然就必须使用一个外部的定时器/时钟芯片。

我们区分计数器,时钟,alarm和定时器:一个计数器保持一个递增的counter,它由一些ticks源驱动。

一个时钟是由一个有规律的ticks源驱动的计数器。

时钟有一个相关联的精度。

一个缺省系统时钟由上面提到的周期性中断驱动,tracks real-time。

别的中断源可能驱动另外一些计数器,它们以不同精度track real-time。

一些计数器可以被非周期的事件驱动,因此与实时没有一点联系。

一个Alarm附带在一个计数器上,基于counter的值,提供了一种产生single-shot或周期性事件的机制。

一个定时器是一个附带在时钟上的简单Alarm。

系统(包括内核)以ticks单元表示时间。

这儿有特定时钟的时间单元和通常是定时器中断的周期。

只有在必需的情况下,通过库函数完成由ticks到传统时间和数据单元的转换。

需要用64位表示当前tick count。

这需要编译器支持64位整数或汇编码。

第五章的时钟,计数器和alarm描述影响时钟,计数器和alarm的时钟API。

相关文档
最新文档