EPICS Controls Argonne National Laboratory

Experimental Physics and
Industrial Control System

1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024  Index 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
<== Date ==> <== Thread ==>

Subject: Re: Open source Real-time Oss / open source OS
From: Noboru Yamamoto <[email protected]>
To: "D. Peter Siddons" <[email protected]>
Cc: "Dalesio, Leo `Bob`" <[email protected]>, [email protected]
Date: Sun, 12 Jun 2005 11:37:49 +0900
Hi,

D. Peter Siddons wrote:

Hi Noboru,
My recollection is that RTEMS also implements the iTron API. Did you look at that?
Pete.


Till Straumann wrote:

I don't know anything about itron but RTEMS also claims to support the ITRON API.

FWIW

Till

Till and Peter, Thank you very much for the valuable information. I didn't know it.


I looked at the pages at :

http://physics.usask.ca/~angie/ep414/labmanual/rtemsdocsx/itron/itron00210.html

for iTRON API in RTEMS, which Mr. Jiang GeYang gave to me.

Accoring to these pages, APIs related to task status handling, semaphore are comleted.
Othere APIs just have stubs. Time and Network, whch EPICS core requires, are not
supported by this iTRON API on RTEMS. But we might wants use POSIX/RTEMS API
for these functions. It shoul also be noted that ITRON API supported RTEMS is ver.3 but
not current 4.0. Anyway, EPICS is supported on RTEMS. There is no reason to use
iTRON API on RTEMS for EPICS.


In KEK, we don't have much applications on iTRON. We just uses applications supplied with
HW. In this case, we may not able to change OS on these HW from iTRON to RTEMS.
If we could change RTOS on these devices to RTEMS, we would use RTEMS.
Some company support vxWorks on their inteligent devices, but we don't want by another license
for new architecture(If you have a vxWorks license, which cover any CPU, this man NOT a problem)
If company does not wants support RTEMS, we need to develope routines to support this new
HW for RTEMS by ourselves. On the other hand, ONCE we could port EPICS to iTRON,
we can use it on any HW devices using iTRON. So than we can reduce a long-term maintenace/license costs.


Thanks,

Noboru

Noboru Yamamoto wrote:

Hi Bob,

Dalesio, Leo `Bob` wrote:

>It seems that we are diverging on these. It is a little worrisome, as operating system problems are ones that are very difficult to find and fix. It would seem most efficient to limit the number of these that we employ.

>In an interest to at least inform the community, there should be a session at the next meeting that covers open source OS. Could people please volunteer to cover your open source RTOS at ths meeting? I know that we have had talks on some of them, but never as a concentrated topic with the express purpose and finding out if there is one that is clearly better - or if there is a compelling reason to limit our support to one (or two, or at least less than we have operator interfaces).

>Bob
> >
For KEK/KEKB,   there is a good reason to port EPICS on iTRON.
First of all, Many inteligent devices available on the market  in JAPAN
uses SH CPU and iTRON for its inteligent
controller. That means that there already exists BSP to support this
device on iTRON. These devices may have
enough CPU, memory and network connection. In some cases, the company
supplies SDK for it. So once
EPICS is ported to iTRON, there may be a good chance to hook these
devices on EPICS based network directly.
Since iTRON is quite popular in JAPAN, there would be not so difficult
an engineer familiar with iTRON and even
support from companies.
The fact that eCos support ITRON API, I have a hope to share some code
between osd for eCos an iTRON. It may
reduce a cost of code maintenance in future,

I agree that if I start a new project I will limit a number of (RT)OSses
in the system. I also don't wants to increase
a number of OSes "officially supported" in EPICS. However, we should not
restrict someone to port EPICS on other (RT)
OSes,  as far as they take their responsibility. I hope that we, EPICS
commuity, will be open to change "officialy supported"
OSes in future, if there would be a good reason to do so. We don't even
know if WindsRiver or PowerPC still survive after 5 to 10 years

Regards,

Noboru




Replies:
Re: Open source Real-time Oss / open source OS Noboru Yamamoto
RE: Open source Real-time Oss / open source OS Jun-ichi Odagiri
References:
Re: Open source Real-time Oss / open source OS Noboru Yamamoto
Re: Open source Real-time Oss / open source OS D. Peter Siddons

Navigate by Date:
Prev: Re: Open source Real-time Oss / open source OS D. Peter Siddons
Next: Re: Open source Real-time Oss / open source OS Noboru Yamamoto
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
Navigate by Thread:
Prev: Re: Open source Real-time Oss / open source OS D. Peter Siddons
Next: Re: Open source Real-time Oss / open source OS Noboru Yamamoto
Index: 1994  1995  1996  1997  1998  1999  2000  2001  2002  2003  2004  <20052006  2007  2008  2009  2010  2011  2012  2013  2014  2015  2016  2017  2018  2019  2020  2021  2022  2023  2024 
ANJ, 02 Sep 2010 Valid HTML 4.01! · Home · News · About · Base · Modules · Extensions · Distributions · Download ·
· Search · EPICS V4 · IRMIS · Talk · Bugs · Documents · Links · Licensing ·