No subject
Thu Jul 24 13:47:21 EDT 2014
- ERCOS by ETAS because there is insufficient information in English on
their website,
- uC/OS-II by Micrium While the price is right ($59.95), I was left with
the feeling that this OS has not been widely adopted, and is not well
supported. It has the feel of an open source product with a devoted,
but small user community.
- osCAN by Vector Informatik because it is entirely oriented to the CAN
bus,
- OSEKWorks by Wind River Systems OSEKWorks is based on the OSEK/VDX
standards that were initially developed to provide an open platform for
the automotive industry. The very small size (as little as 2KB) raises
doubts as to functionality sufficient for our purposes. Interprocessor
communications is based on CAN or serial ports, no ethernet or TCP/IP
stack, and OSEK/VDX-based applications are statically configured at
compile time - no dynamic task creation or termination. All-in-all,
the OSEK/VDX standard seems inappropriate for our application.
- Rubus by Arcticus Systems because a) the web site contains
insufficient information to make a realistic evaluation, b) does not
seem to have the add-on components of interest, such as a TCP/IP stack,
and c) seems to take an approach to time and timing that would require
time-consuming investigation and evaluation on our part.
So, the remaining 7 candidates are:
- CMX-RTX by CMX Systems
- Nucleus PLUS and Nucleus uiPLUS by Accelerated Technology, Inc
- OSE by OSE Systems
- PXROS by HighTec GmbH
- ThreadX by Express Logic
- Jbed by esmertec
- JStamp/SaJe/JStik by Systronix
CMX-RTX by CMX Systems, http://www.cmx.com/
The home page offers a white paper on RTOSes - "Buy or roll your own". I'm
not sure if that is a good sign or a bad one for our purposes, but it
doesn't leave me with a warm feeling. CMX actually provides two offerings
- CMX-RTX (http://www.cmx.com/rtx.htm) and CMX-TINY+ (http://www.cmx.com/
tiny.htm). However, I see no mention of TriCore support for CMX-TINY+ so
only CMX-RTX is of interest to us.
A list of CMX-RTX functional is offered at http://www.cmx.com/rtx.htm. I
get the feeling of an adequate, but lean and small RTOS.
A CMX TCPIP package does exist which seems to be full-featured
(http://www.cmx.com/ Tcpip.htm), BUT the TriCore architecture is not among
the list of processors currently supported by this package. Such a port
may be currently under development or perhaps just released. Inquiries
would be necessary.
A debugger (CMXBug) and a real-time logging (execution trace) package
(CMXTracker) is offered. Both run only under Windows.
C appears to be the only language supported.
Probably a bit too minimalist for our application.
Nucleus PLUS and Nucleus uiPLUS by Accelerated Technology, Inc
www.acceleratedtechnology.com
www.acceleratedtechnology.com/ATI/nucleus.php
As an aside, it should be mentioned that ATI has been purchased by Mentor
Graphics. This purchase was completed only about 2 weeks ago and its
consequences for the companies product offerings and responsiveness is
currently unknown.
KERNELS
Nucleus uiPLUS is a port of Nucleus PLUS to the uITRON interface
specification that has seen fairly widespread adoption by embedded
developers in Japan. It is of interest to us only if we are interested
in the uITRON specification. uiPLUS includes the native PLUS interface
so uITRON conformance is an add-on that will consume additional RAM
space.
Nucleus PLUS is implemented as a C library. There is a web page
(http://www/acceleratedtechnology.com/ATI/nucleus.php) which provides
links to all available components - kernels, network stack, etc. At the
bottom of that page there is a link to a pdf brochure which gives an
overview of the components. If one follows the link to the kernels page
a pdf brochure can be downloaded which lists all of the kernel calls.
I do not know and could not find any reference to memory mapping so I do
not know if the Nucleus PLUS kernel makes use of available MMUs.
The available components, in addition to the Nucleus PLUS kernel, include:
DATA STORAGE
Nucleus FILE - FAT16 & FAT32 disk formats
Nucleus FILE Drivers - IDE/ATA, SCSI, floppy, PCMCIA, CompactFLASH
NETWORKING
Nucleus NET - the TCP/IP networking stack. C sockets interface.
Provided protocols are: TCP, UDP, IP, ICMP, IGMP, ARP, RARP, BOOTP, DNS,
DHCP, RIP/RIPII, and TFTP.
Nucleus NET Drivers - Ethernet & PPP
Nucleus EMAIL - POP3 & SMTP
Nucleus Extended Protocol Package - Telnet server, FTP file transfer, TFTP
file transfer
Residential Gateway - NAT, PPPoE, DHCP
Network Management - SNMP with support for MIB-II, RMON - supports all
nine groups of RMON MIB and all ten groups of MIB-II, SPAN - an
implementation of the IEEE 802.1d Spanning Tree specification.
Nucleus TLS - SSL & TLS. TLS provides a secure sockets API.
I saw no mention of security aware products such as SSH or any discussion
of IPv4 vs IPv6 - questions to be asked.
GRAPHICS
Nucleus GRAFIX - GUI support
Nucleus GRAFIX Drivers - device support
WEB PRODUCTS
Nucleus WebServ - HTTP server
Nucleus WebBrowse - an embedded web browser
DEVELOPMENT SUPPORT
Nucleus Kernel-Aware Debugging - plug-ins that enhance selected embedded
software debuggers with specific extensions for PLUS, NET, FILE and
GRAFIX.
Nucleus SHELL - an ASCII character based shell
PROTOTYPING
Nucleus MNT - a prototyping environment that allows software development
of Nucleus PLUS applications under Windows using Microsoft Visual C++ and
the Microsoft Visual Studio tool set prior to the availability of the
target hardware. Available for the PLUS kernel, NET, WebServ, GRAFIX,
FILE, and C++ components.
Nucleus ProView and SurroundView - Proview is a real-time profiler that
monitors kernel behavior - tasks, interrupts, semaphores, queues,
timers, signals, etc. SurroundView is a run time execution trace system
for applications.
LANGUAGE SUPPORT
Assembler - not specifically discussed, but the Green Hills and TASKING
tool suites offer assemblers for the TriCore architecture. The port of
Nucleus PLUS to the Infineon TriCore architecture is listed as being
compatible with the Green Hills and TASKING tool suites.
C - Not specifically discussed. May be a part of the Green Hills and
TASKING tool suites.
C++ - I'm a bit unclear on the nature of ATIs support for C++. I would
be very surprised if the Green Hills and TASKING tool suites did not
offer C++. In addition ATI seems to offer a set of C++ frameworks or
APIs for C++ language support (Nucleus C++ BASE), OS calls (Nucleus C++
PLUS), TCP/IP networking (Nucleus C++ NET), and data storage (Nucleus C++
FILE). This point requires further investigation.
Java - CEE-J, a suite of virtual machines for the EmbeddedJava platform.
Minimum footprint for a VM seems to be slightly under 100KB. Support for
the CLDC (Connected Limited Device Configuration), MIDP (Mobile
Information Device Profile), PersonalJava and EmbeddedJava standards.
The EmbeddedJava offering provides the JDK 1.1.8 feature set, no AWT
support, real-time extensions are available, and no file system is
required.
HOSTS
The OSes which can act as hosts for the ATI Nucleus software and the
TASKING and Green Hills tool suites is an unknown at this point. Another
question to be asked.
All Nucleus products seem to be royalty free. Emphasis is placed on
providing source code. The implication seems to be that the purchase price
includes full source code. Bruce provided some preliminary pricing info in
his evla-sw-discuss posting of 12/12/2001. Their pricing policy seems to
include a target CPU license plus per seat charges for development tools.
The (list) prices for the OS kernel was given as $12,495, for the network
stack $14,995, and $1300 per seat for items such as the shell. Could be
expensive, perhaps comparable to VxWorks.
ATI seems to have a very complete set of offerings. I do not know if all
of the above components are available for the TriCore architecture. We will
have to choose the components of interest and ask. It seems worth our time
to investigate this company, its offerings and its pricing more fully. It
would also seem to be worth our time to investigate the capabilities and
pricing of the Green Hills & TASKING (Altium) tool suites.
An important point not addressed is the amount of RAM consumed by these
various packages. This point is a make or break item. Bruce brought back
some information on this point from the Embedded Systems Conference.
Apparently, all ATI software is implemented as libraries, which allows one
to be selective about what is and is not included, making size reductions
possible. Bruce also mentioned that the network stack is capable of
supporting IPv4 and IPv6, at the same time.
Of all the web sites I visited, the ATI web site was the best organized and
most informative.
OSE by OSE Systems http://www.ose.com
While I am certain that OSE supports the TriCore architecture, the web
site specifically mentioned only the TC1775 chip, and not the TC11IB.
KERNEL
OSE claims a message-based architecture with an emphasis on high
reliability and high availability. The kernel was originally developed
(some 14 years ago) for use in the telecommunication industry, and has
special capabilities (discussed below) intended to support the
development of distributed systems. The kernel is not small by Mib
standards. In its product literature, the kernel requirement is given as
< 100 Kbytes. A workable number, but I want to see how it compares to
Nucleus PLUS and ThreadX.
The basic interprocess communication (IPC) method in OSE is messages. A
message contains an ID, the address of the sender, the address of the
receiver, and data. Ownership of a message is never shared. Once sent,
the sending process can no longer access it. Message passing is used
both for processes in the same CPU and for processes distributed across
different CPUs. Message passing between different CPUs is transparent
and does not differ (in the call) from message passing to processes in
the same CPU. Other, more conventional IPC methods are also available.
OSE claims to provide a sophisticated framework for creating error
handlers at the process, group and system level. The error handlers can
be invoked from the process, or automatically by the kernel. OSE makes a
number of claims for this approach including elimination of the need to
check error codes after OSE system calls, more uniform and consistent
error handling, and automatic elevation of the level at which the error
is handled.
Some of OSE claims appear to be tenable.
DATA STORAGE
OSE offers both an Embedded (and distributed) File System (EFS) and an
Atomic File System (AFS) which provides "bulletproof" synchronized file
operations.
NETWORKING
The networking stack is named INET. A standard BSD sockets interface is
provided, and it is a one-copy network stack. An alternate interface,
the OSE asynchronous signal interface, integrated with OSE message
passing is also available to the user. This latter interface is the
primary method for IPC within OSE, and is an extension of the BSD
interface. The OSE asynchronous signal interface provides blocking,
blocking with timeout, and non-blocking receives.
The supported protocols are TCP, UDP, IP, ICMP, raw IP,
IGMP/multicasting, a generic IP interface to lower link layers, ARP,
RARP, PPP, a loop-back interface, and IP Tunneling.
Available network applications are Telnet (server/client), FTP
(server/client), an HTTP server, BOOTP (client), BOOTP (relay agent),
DHCP (server/client), DNS (server/client), TFTP (server/client), and
NTP/SNTP.
Network management - integrated with EMANATE & EMANATE/Lite from SNMP
research, i.e., third party SNMP capabilities. OSE includes multicasting
support for use with Open Shortest Path First (OPSF), and support for
RIPv.1 and RIPv.2.
WEB PRODUCTS
As mentioned above, an HTTP server is available.
DEVELOPMENT SUPPORT
OSE offers a host-based suite of software tools for debugging and
analyzing OSE based applications. The name of the tool suite is
Illuminator. Illuminator communicates with target boards via TCP/IP and
interconnects with XRAY for OSE, a source-level debugger. XRAY provides
both C & C++ source-level debugging. A kernel-aware debugger is
available as part of the MULTI software development environment offered
by Green Hills. CodeTEST by Applied Microsystems is available for OSE.
PROTOTYPING
OSE offers both Soft Kernel and Soft Environment. Soft Kernel enables
simulation of an application, an entire system, or even a distributed
system on a host before moving the software to the target. Soft
Environment works with Soft Kernel to build a complete OSE system in a
host including the Link Handler, Name Server (the Link Handler and Name
Server will be discussed later), the embedded file system, internet
protocols and applications, and a web server. (Sounds expensive !)
LANGUAGE SUPPORT
OSE is integrated with MULTI from Green Hills, a software development
environment. In addition to the kernel-aware debugger mentioned above,
C, C++, EC++ (embedded C++) support is available. The term "support" is
somewhat ambiguous. I do not think it refers to compilers. For
compilers, OSE appears to us the GNU C & C++ compilers. Assembly
language programming is not discussed.
HOSTS
The Illuminator tool suite runs under Windows, Solaris, and Unix.
OTHER
OSE appears to take a unique approach that may give it some advantage
w.r.t. distributed systems. The OSE Link Handler connects all system
nodes and enables transparent communication among applications running on
different nodes. The OSE Name Server connects to the Link Handler and
enables applications to call any process in a distributed system using a
unique process name. No knowledge of where the process resides is
required.
OSE also offers a small footprint, high speed, memory resident database
named Polyhedra. Polyhedra includes the capability of encoding
application logic directly into the database enabling immediate
notification of changes in data.
OSE is an interesting operating system which may be better suited to
distributed systems than the other OSes considered in this report. I would
be interested in considering it as a replacement for VxWorks in the
real-time crates that are to reside in the control building. It does
appear to be a bit too complex under the hood and insufficiently lean for
the MIB, but may deserve some investigation for that purpose.
I have no information on pricing, licensing policies, or source code. I
fear that OSE may have policies and problems similar to Wind River for the
case of VxWorks.
PXROS by HighTec GmbH http://www.hightec-rt.com/uk/pxros.htm
I'm not really sure what to say about PXROS. PXROS stands for Portable
eXtendable Realtime Operating System. It does support the TriCore
architecture. The material on the web site says all the right things
w.r.t. kernels, and there are a series of "components" which include a DOS
& Unix file systems, a realtime monitor, NFS functionality, a TCP/IP stack,
and an HTTP server. I could find no discussion of tool suites, languages,
etc.
The socket interface is based on bsd 4.2 functionality, and does include
a SELECT call. In addition to TCP/IP and UDP, ARP, IP, and ICMP are
implemented. The web server is scalable from 20 - 90 KB, supports HTML 4.0
tags, CGI, SSI, server side java applets, cookies, SSL/TLS, and many other
features.
Basically, I rule it out simply because it is a huge unknown and we lack
sufficient time for the detailed examination that would be necessary. If
anyone reading this report has additional info, please speak up.
ThreadX by Express Logic http://www.expresslogic.com
The founder of Express Logic and sole author of ThreadX was a cofounder
of Accelerated Technologies, Inc, and the sole or primary author of Nucleus
PLUS, so it will not be surprising if we undertake a head-to-head
comparison of the two RTOSes. ThreadX definitely supports the TriCore
architecture, but I do not know if it specifically supports the TC11IB.
The company representative with whom I spoke is pursuing an answer to that
question. If not, they claim that a port to the TC11IB chip should not
take more than 4 to 8 weeks. We did not discuss price.
RTOS KERNEL
As with Nucleus PLUS, ThreadX is implemented as a library. ThreadX takes
the modularity of Nucleus PLUS one step further. Where Nucleus PLUS
sometimes combines more than one OS call into a file, ThreadX has
separated all OS functions into separate files. I spoke briefly with a
company representative and he claims that even if all OS services are
included, the total size of ThreadX is on order of 25KB - 30KB. Good, IF
ThreadX offers sufficient functionality. A list of OS calls and a users
reference manual are on the way to us. A description of the API for
ThreadX, version 4 can also be found at
http://www.expresslogic.com/txappinterface.html. It includes byte & block
memory pool services, event flags, one call for interrupt control,
message queue services, semaphore services, mutex services, thread
services (appears to be fairly complete), time and timer services. In
the Green Hills literature on ThreadX, the claim is made that ThreadX,
for the same set of applications, can be as much as 8 times smaller than
VxWorks, and as much as 50% smaller than Nucleus PLUS.
Some of the features of the kernel that are touted on the web page are:
ThreadX services - Threads, Application Timers, Message Queues, Counting
Semaphores, Mutexes, Event Flags
Preemption-Threshold - allows an application to disable preemption over
ranges of priorities instead of globally. Preemption-threshold is
currently a research topic in the academic community. It appears to have
advantages which include fewer context switches, the elimination of
priority inversion, and the ability to create classes of priorities which
are non-preemptible.
Timers are maintained in an ordered list by expiration. Reduces timer
expiration overhead.
Offers optional priority inheritance via a mutex object.
Hybrid kernel objects - for example, a service that allows threads to
feed from multiple message queues can be created by combining message
queues with a counting semaphore.
DATA STORAGE
FileX, version 3.0 Appears to be a complete and thoughtful
implementation. 12, 16, and 32 bit FAT support, small footprint, and
some increasingly difficult to find real-time features such as support
for contiguous files.
NETWORKING
While ThreadX does now offer a proprietary network stack- NetX, it is the
companies newest offering and currently supports only TCP/IP, UDP, IP,
ICMP, ARP and RARP. However, ThreadX has 2 partnerships with companies
that offer full-featured network stacks which are integrated with ThreadX
- Interniche and Elmic Systems. I have not had the opportunity to
research either of these offerings. The "Partners" page offers links to
these web sites.
It may be worth our while to track the development of NetX. It is a
zero-copy API which should provide high performance. A copy of the NetX
API is available at http://www.expresslogic.com/nxappinterface.html. I
did NOT find a SELECT call in the API.
GRAPHICS
Embedded Logic's offering is named PegX. All of the web pages are under
construction.
WEB PRODUCTS
Embedded Logic does NOT offer an http server.
DEVELOPMENT SUPPORT
ThreadX is closely integrated with the Green Hills MULTI Software
Development Environment and includes a ThreadX kernel-aware debugger.
Thread specific breakpoints can be set. The MULTI environment also
includes an event logging and analyzer tool for ThreadX.
LANGUAGE SUPPORT
ThreadX is closely integrated with the Green Hills MULTI environment, and
also has a partnership with the Altium TASKING tool set. I think we can
safely assume that assembler & C are available. W.r.t. C++ and Java, we
will have to make inquiries.
HOSTS
Unknown.
LICENSING
Royalty free. Source code included in the purchase price.
Embedded Logic's product offerings bear further investigation. While not
as extensive as those offered by ATI, they appear to be complete enough,
with an emphasis on full, high performance functionality with a small
footprint. The lack of an HTTP server could be a problem.
Embedded Java
Embedded Java has an appeal to software types. The language has a clean
syntax and high function libraries. For example, opening a socket is a one
liner in Java. Significantly more code is required to accomplish the same
task in C. However, only a subset of the Java libraries will be available
in an embedded Java. Just what libraries are supported would be an
important issue. Also, there is the question of cooperative development
between the hardware engineers and the software engineers. Will the
hardware engineers be willing to learn Java ? Is it not something of a
major jump to move from assembler coding with no RTOS present to
programming in embedded Java ? How many _software_ engineers would be able
to make the same jump, in one large step? Very few, I suspect. Is it fair
to present the hardware engineers with such a requirement, deflecting them
from what is correctly their primary focus - the hardware ? Would the use
of embedded Java place the entire burden for software development on the
Computer Division ? Does the use of embedded Java create place barriers
between the hardware developers and the hardware ?
Consideration of embedded Java cannot be based solely on considerations of
software elegance. Development of the MIB software must be a cooperative
effort and must speak to the requirements and reasonable expectations of
all concerned parties.
In the interests of time and division of labor, I will not undertake a full
investigation of embedded Java in this report. Kevin has been the advocate
for embedded Java, and I will allow him to continue to be so.
JBED by esmertec http://www.esmertec.com/index.html
JBED claims to implement an embedded Java which includes an RTOS,
networking stack, and an HTTP server in approximately 300 Kbytes of RAM
plus 200KB to 300KB of ROM. If external ROM is _required_ then JBED does
not meet our RFI criterion of execution without off-chip instruction
fetches. However, if the off-chip ROM can be replaced by on-chip RAM then
JBED is not necessarily out of the running. There is also the question of
a port. Is JBED currently ported to the TriCore architecture in general
and to the TC11IB chip in particular ? If not, how long would it take to
do so ? I would be very hesitate to recommend that we attempt such a port
in-house. Does esmertec offer porting services? If so, what is the cost,
the amount of time needed, and how do we form an estimate of the likelihood
of a satisfactory outcome ?
Another concern for JBED would be the functionality of the RTOS kernel. I
have seen nothing so far which provides technical information on this
subject.
One point that I have heard, but have not had the opportunity to confirm is
that JBED charges a $30 royalty fee per target. If true, then for our
purposes, that cost would be (in round numbers) 50 mibs/antenna X 30
antennas X $30/mib = $45,000.00 (!). This expense strikes me as
unreasonable, unaffordable, and unnecessary.
JStamp/SaJe/JStik by Systronix
http://jstamp/systronix.com
http://www.systronix.com/saje/index.htm
http://jstik.systronix.com
All three of these products are hardware as well as software products. As
such they must be evaluated as TC11IB replacements in addition to their
software capabilities.
JStamp offers 512 KBytes of SRAM, 512Kbytes of Flash (there is a JStamp+
which offers 2MBytes of Flash), two serial ports, with, apparently, one
usable as SPI, a JTAG port and more. The data path to the SRAM and Flash
is 8-bits. It uses an aJile aJ-80 processor which is designed to execute
Java code natively. Development systems cost $300, quantity pricing is ~
$100. (I do not know what volume is implied by "quantity".) It has a
small footprint (1.00" X 2.00"), and requires 3.3VDC. On the face of it,
not an unreasonable candidate for a MIB, but much additional investigation
would be required.
SaJe uses the aJ-100 processor (100MHZ operation), offers 1 MByte of 10
nsec SRAM, 4 MBytes of 90 nsec Flash, and a 32-bit wide interface to
memory. It has two serial ports, and, while I see no mention of SPI in the
literature on the SaJe, a comparison sheet does indicate that SPI is
present. Ethernet is on-board, but is 10BaseT, not 100 Mbps fiber. It's
size is 100 X 160mm (3.9" X 6.2" Euroboard) with RF shielded enclosures
available.
JStik is currently a pre-release product. It will be formally announced at
JavaOne this March. Prototypes were demonstrated last year (11/28 -
11/30/2001) at JavaOne in Japan. It has a 3" X 2.65" (SIMM30) form factor,
and is implemented in 3.3V CMOS. There is no firmware JVM or operating
system. These components are implemented in silicon. In effect, Java is
the assembly language of this board. It uses the aJ-100 processor, has a
32-bit memory path, offers 1 MByte of SRAM and 4Mbytes of flash. There is
a JSITK+ which offers 2 MBytes of SRAM and 8MBytes of flash. Since the JVM
and OS reside in silicon, all of this RAM & Flash is available for
applications. The board includes 2 RS-232 ports, and one of the spec
sheets does state that a SPI port is present. Unfortunately, ethernet is
on-board - 10BaseT with an on-board RJ45 connector. Both SaJe and JStik
offer a buffered I/O bus with an 8-bit data path, address strobes and chip
selects for interfacing to off-board devices.
JStik claims a 1 microsec thread switch time. Very impressive if true.
A cursory search revealed no information on RTOS functionality available on
the web site.
It seems to me that some of these approaches to embedded Java offer enough
promise to merit further investigation. However, I also consider it
essential to enlist the interest of and to hear opinions from the hardware
engineers.
Final Candidates
Given all of the above, my final list of RTOS candidates is as follows:
- Nucleus PLUS by Accelerated Technology, Inc
- ThreadX by Express Logic
- Inquire into VxWorks support for TriCore & the TC11IB chip. If
TriCore or the TC11IB is not supported we may wish to consider either
our own port or contracting with WindRiver for a port. I do not really
like the idea of doing our own BSP, but I am willing to be convinced
otherwise. I do not really trust Wind River, if contracted by us to do
the BSP, to give us a quality product at a reasonable price.
- Kevin's investigations concerning embedded Java
- An honorable mention goes to OSE, but I still suspect it may suffer
from a too-large footprint. Also, it's less conventional approach in
some areas may be confusing to some &/or involve a steeper learning
curve, although OSE claims just the opposite.
- Additionally, we will probably have to investigate the Green Hills tools
and the TASKING tool suite.
Hardcopy of my web research on all of the RTOSes discussed in this report
is available in my office - stacked in folders on one of my chairs. Anyone
interested is welcome to come by and borrow some or all of the material. I
do ask that any folders taken be signed out - name, date, folder or folders
taken. I've left a signout sheet on top of the stack. Sorry about the
signout, but the web work takes time, and I do NOT want to do it twice. I
need to be able to track down the folders when the need arises to do
further research, refresh my memory, speak with vendors, etc.
Standard Platform
Combining what is offered with what we think we may want allows the
beginning of a definition of a "standard platform" for the MIBs that
makes comparison of RTOSes, at least in the area of pricing, somewhat
easier. I would suggest the following:
RTOS kernel
Basic task services - create, delete, resume, suspend, terminate, plus
useful additions such as relinquish, sleep, change priority, etc
Priority based scheduling of tasks & threads is essential.
Task communication - mailboxes, queues, pipes
Task Synchronization - semaphores, plus, optionally signals.
Timer services - create, delete, set, reset, others ?
Memory services - memory mapped or flat, unprotected address space ?
With appropriate services for memory services as per the two cases.
If memory mapped, must investigate intertask communication capabilities.
Interrupt services - create, delete, install/register, others ?
I/O services - create, delete drivers and other niceties as available
File System
Not needed for the MIBs.
Networking
Sockets interface, TCP/IP, UDP, ICMP, IPv4 & IPv6, BOOTP (?), TFTP (?),
Ethernet drivers. Do we want/need DNS & DHCP ? How about NFS ?
Network servers & clients
telnet or rlogin (secure version), ftp file transfer, tftp file transfer
Web
HTTP server Useful to us IF we decide to embed the screen(s) for a MIB
in the MIB. If the HTTP server and the screen descriptions are
sufficiently compact, this idea has a strong appeal to those of us
writing software because it could significantly reduce the time needed to
field functioning screens for use by the engineers and technicians for
hardware development and testing.
Language Support
Assembler and C are essential. I consider the possibility of C++ to be
highly desirable, but not absolutely required. On the issue of Java, if
a "conventional" OS is chosen, the possibility of Java would be nice,
but we need clarification of the various small footprint platforms that
are currently defined, and may not want to spend precious on-chip RAM
resources on adding Java to a conventional RTOS.
Miscellaneous
- Source code, for the kernel, and preferably for all purchased
components, especially the networking components.
- No royalties for targets
- Do we want/need a shell ? Probably yes.
- Debugger, preferably a source code debugger
- A profiler might be useful
- Any offerings that enhance network security
- Known, acceptable footprints for the required run-time components
Host Platforms for Cross Development Software
At least one of the following - Solaris, Linux, Windows NT SP6 or
whatever the currently blessed version of Windows is at the time.
Target
Of course, the TriCore architecture must be supported. I would like to
see _specific_ support for the TC11IB chip.
--------------B90993C4AB26218BFCF02852--
More information about the evla-sw-discuss
mailing list