Experimental Physics and
Industrial Control System

"Dalesio, Leo `Bob`" <[email protected]> · Mon, 13 Jun 2005 04:39:41 -0700

I agree with Jun-ichi that the real issue is the availbility of BSPs. There is appromately a 4 month investment to create a new BSP. 

-----Original Message-----
From: Jun-ichi Odagiri [mailto:[email protected]] 
Sent: Sunday, June 12, 2005 6:28 PM
To: 'Noboru Yamamoto'; 'D. Peter Siddons'
Cc: Dalesio, Leo `Bob`; [email protected]
Subject: RE: Open source Real-time Oss / open source OS

Hi, all;

Let me explain "our work on ITRON" again in my words.

The goal of the work is to achieve what we call "Embedded EPICS", I mean, running EPICS directly on many different types of front-end controllers.
However, this scheme apparently has one serious difficulty.

Can we afford to create BSPs for each of the controllers by ourselves?
The answer is definitely NO.

Fortunately or unfortunately, we observed that a specific product of RT-kernel seems to be dominating the Japanese market due to its no-runtime-license feature.
We thought that if BSPs are available on the market and if we share the development environment with those companies, the difficulty in achieving "Embedded EPICS" might be solved. And, the product of RT-kernel happened to be a uITRON.

What matters is not ITRON but availability of BSPs and a development environment for them at a reasonable price.

Jun-ichi Odagiri

-----Original Message-----
From: Noboru Yamamoto [mailto:[email protected]]
Sent: Sunday, June 12, 2005 11:38 AM
To: D. Peter Siddons
Cc: Dalesio, Leo `Bob`; [email protected]
Subject: Re: Open source Real-time Oss / open source OS

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.h
tml

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
>>

Experimental Physics and Industrial Control System

Experimental Physics and
Industrial Control System