This is the mail archive of the
elix@sources.redhat.com
mailing list for the Elix project.
回覆 : subset of EL/IX for DSPs
- To: "'Nick Garnett'" <nickg at cygnus dot co dot uk>, Julian Rose <jhrose at dial dot pipex dot com>
- Subject: 回覆 : subset of EL/IX for DSPs
- From: Jwusheng Hu <jshu at cn dot nctu dot edu dot tw>
- Date: Tue, 15 Aug 2000 17:39:57 +0800
- Cc: "elix at sources dot redhat dot com" <elix at sources dot redhat dot com>
- Encoding: 57 TEXT
Julian Rose <jhrose@dial.pipex.com> writes:
> Hello,
>
> Could anyone point me to info regarding a subset of EL/IX
> or POSIX that targets DSPs? Or if anyone else is thinking
> about this then their suggestions would be welcome. The
> context of the question is the kernel I'm developing, please
> see "http://www.jhrose.dial.pipex.com/dsp_K.htm". Thanks.
>
> Nobody has put any real thought into the requirements of DSPs yet.
> Embedded and real-time systems have proven to be difficult enough to
> pin down. I suspect that DSPs would require a subset of the RT subset
> of EL/IX, perhaps with special schedulers and variations of some
> communications primitives. Whether we need to provide a specific DSP
> subset, or whether this would just be a version of the real-time
> subset I don't really know yet.
> Suggestions and comments about what would be good for DSPs are very
> welcome. This would at least help to ensure that the next version of
> EL/IX is not actively DSP-hostile.
>
> --
> Nick Garnett, eCos Kernel Architect
> Red Hat, Cambridge, UK
It appears that there are two types of requirements here and they are
related to a fundamental design question: will you design a system
completely based on DSP? Traditionally, DSP usually acts as a slave
processor preforming repeated calculations for time-critical algorithms.
Because of this, DSP chips have very little support of system interface like
ethernet, LCD etc.., compared with most microcontrollers.
However, when the MIPS of DSP exceeds the needs of algorithm complexity, it
is quite natural to use the extra MIPS for system interface and a RTOS would
be very helpful. However, most DSP algorithms must be coded in assembly to
fully utilize the computational capability, e.g., zero-overhead looping.
This creates a potential threat to RTOS that full control of the CPU
resource maynot be possible and users can easily crash the kernel by
mistake. Hence, unless DSP programmers understand the kernel well, she/he
may have difficulty using other people's RTOS.
On the other hand, the master-slave structure is still popular when DSP
takes on the computing role for software radio. For example, TI has a
DSP+ARM solution that is targeted for portable wireless devices. In this
case, the need would be how to have a single RTOS that handles both
processors together and provides a seamless communication interface between
them.
Jwusheng Hu, Professor
Dept. of Electrical and Control Engineering
Embedded System Design Lab, http://xlab.cn.nctu.edu.tw
Director, EECS DSP lab,
http://dsp.cn.nctu.edu.tw
Executive Consultant, DigiRose Co Ltd, http://www.digirose.com