1 / 18

Porting iocCore onto - ITRON real-time kernel

This document discusses the benefits and implementation of porting μ-ITRON real-time kernel onto intelligent device controllers, including commercial devices and custom controllers. It also highlights the challenges faced and the future plans for implementing the kernel.

youngbrandon
Download Presentation

Porting iocCore onto - ITRON real-time kernel

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Porting iocCore onto -ITRON real-time kernel EPICS collaboration meeting 2004 12/10/2004 G.Jiang, A.Akiyama, J.Odagiri, N.Yamamoto

  2. What is -ITRON? • An API-specification of real-time kernel • Developed by Prof. Ken Sakamura of Tokyo Univ. • Many different implementations of products are available on the market • Widely used in consumer electronics fields in Japan • Mobile phones • TV-games • Automobile Navigation System • Details : See • http://tron.um.u-tokyo.ac.jp/TRON/ITRON/home-e.html

  3. Why -ITRON? • Running iocCore on intelligent device controllers • Many intelligent device controllers come with an Ethernet interface • Many of those have an SHx CPU and enough ROM/RAM capacity to run iocCore • Many of those run -ITRON Proprietary Protocol OPI OPI CA CA IOC Controller IOC VME or PC Controller

  4. Intelligent device controllers running -ITRON • Commercial Devices • PLC • Yokogawa FA-M3, used for Ion-source, vacuum etc. • WE7000 measurement station • Digital oscilloscope (100kS/s, 1MS/s, 100MS/s and 1GS/s) • Custom Device Controllers • EMB-LAN100 • Initially designed for the Power supplies of DTL Q-magnet • NDIM (Network Device Interface Module) • Developed by RIKEN for various control/monitoring

  5. Commercial devices FA-M3 PLC (Made by Yokogawa) WE7000 (Made by Yokogawa)

  6. Custom device controllers N-DIM (Developed by RIKEN) EMB-LAN100 (Developed by KEK)

  7. What are the benefits? • More distributed • More load distribution • More robust • Flatter hierarchy • Save IOCs being used as “protocol transformer” • No need for asynchronous driver Proprietary Protocol OPI OPI CA CA IOC Controller IOC MicroIOC Controller

  8. What’s available on the market • The kernel, NORTi4, from MISPO • Development environment • SHC (Super Hitachi Compiler) with a standard C/C++ library • Cygwin on Windows • Kasago TCP/IP + BSD socket library, from Elmic Systems, Inc. • We assume BSPs are available from the HW-manufactures

  9. How hard is it? • We have implemented OSD libraries (not yet tested) • We have asked Elmic Systems, Inc. to port the TCP/IP + BSD socket onto our target board • There are some missing functions in STC library needed by iocCore • Recent versions of EPICS base use lots of C++ codes • We have gotten linkage errors with some of those

  10. OSD implementation • -ITRON has abundant functions for synchronization and communication • It’s relatively easy • For example: itron case: const T_CMTX cmtx = {TA_TINHERIT,0,""}; struct epicsMutexOSD * epicsMutexOsdCreate(void) { ID id; ER ercd; ercd = acre_sem(&cmtx); … } Vxworks case: struct epicsMutexOSD * epicsMutexOsdCreate(void) { return((struct epicsMutexOSD *) semMCreate(SEM_DELETE_SAFE|SEM_INVERSION_SAFE|SEM_Q_PRIORITY)); }

  11. BSD socket library Elmic Systems, Inc. is going to develop libraries which interface their TCP/IP protocol stack with -ITRON/LAN controller driver

  12. Missing functions in STC library extern FILE *fdopen(int handle, const char * tmp) {...} extern char *getenv (char * tmp) {...} extern int putenv (char * tmp) {...} extern char *tmpnam (char * tmp) {...} extern FILE *tmpfile (void) {...} extern int atexit (void (*function)(void)) {...} extern void exit(int status) {...} void abort(void) {...}

  13. Building problems with C++ code • iocCore uses some methods not in SHC’s STD C++ library • logic_error::logic_error(); • Some of external references can’t be resolved • Related with class • Related with template • Related with inline function

  14. Status and future plans • We are trying to solve the linkage problems with C++ code • If not, we are going to try another compiler exeGCC, based on gcc • We lose support from the companies on BSP&BSD socket library • We hope we can succeed in running iocCore on a target board before Mar. 2005

  15. MCU made by Nichizou MCU running -ITRON SH4 (SH7751R-200 MHz) FLASH ROM 16MB SDRAM 64MB

  16. External references can’t be resolvedrelated with class • Example: L2310 (W) Undefined external symbol "type identifier for tcpRecvThread" referenced in "tcpiiu" • Details: In "epics\base-3.14.6\src\ca\virtualCircuit.h", class was declared, class tcpRecvThread : public epicsThreadRunable {…}; In "epics\base-3.14.6\src\ca\tcpiiu.cpp", the method is like this, tcpRecvThread::tcpRecvThread ( … ) {…}

  17. External references can’t be resolvedrelated with template • Example: L2310 (W) Undefined external symbol "type identifier for tsSLNode<tcpiiu>" referenced in "tcpiiu" • Details: In "epics\base-3.14.6\include\tsSLList.h",declare is like this: Template <class T> class tsSLNode { … };

  18. External references can’t be resolvedrelated with inline function • Example: L2310 (W) Undefined external symbol "comBuf::operator new(unsigned long)" referenced in "tcpiiu" • Details: In "epics\base-3.14.6\src\ca\comBuf.h", inline void * comBuf::operator new ( size_t size, comBufMemoryManager & mgr ) { return mgr.allocate ( size ); }

More Related