Introduction

The aim of this research project was to port RTLinux to the MIPS Atlas board with MIPS 4Kc core. We further intended to measure the response time of the real-time interrupts and the scheduler, and develop a suitable real-time environment for system-on-chip (SOC) based embedded applications such… as media gateway controllers, Voice-over-IP (VoIP) solutions, multimedia solutions, routers etc.

Approach and Design

The first step towards achieving our goal was to study the architecture of the MIPS Atlas boards, and get to know the microprocessor design and details. Then came the task of porting RTLinux onto the MIPS hardware. This required a complete and thorough understanding of both the RTLinux (software) and MIPS (hardware) architectures.

RTLinux uses a dual kernel architecture in which a small real-time micro kernel takes over the complete control of the MIPS hardware and runs Linux as the lowest priority task.

The following steps were needed in order to fulfill the goals of the project . . .

• Bring up a boot loader on the MIPS Atlas board
  
• Bring up the Linux 2.4.4 kernel on the MIPS Atlas board
  
• Port the RTLinux 3.1 micro kernel (on top of Linux 2.4.4) to MIPS Atlas board
  
• Write a serial test driver for the TL16C550 chip, in order to measure the interrupt and schedule response time of RTLinux on the MIPS Atlas board

Implementation

RTLinux is GPL software, and comes with following six modules . . .

• rtl.o — provides rtl_printfs for debugging, and provides APIs to configure real-time interrupts.
  
• rtl_time.o — provides rtl_timer.
  
• rtl_schedule.o — provides real-time scheduling capability.
  
• rtl_posix.o — provides posix standard APIs.
  
• rtl_fifo.o — provides FIFOs to enable communication with the Linux tasks.
  
• mbuff.o — memory buffer for shared memory.

In order to port these six modules to the MIPS Atlas board, some changes had to be made to the available RTLinux source code. Here is a brief summary of the major changes this entailed . . .

• The module rtl.o was re-coded so that rtl_printf's were available for debugging. The Interrupt handling portion of the Linux was taken over by RTLinux. The right to disable or mask interrupts was taken away from Linux by RTLinux — instead Linux got an interrupt handling routine which queues the interrupts. Responsibility of dispatching a task for execution was given to RTLinux depending on the priority. Interrupt dispatcher code was re-coded for RTLinux. The Linux calls like CLI, STI, save_and_cli(), were replaced with soft_cli(), soft_sti() and rtl_soft_save_and_cli(). rtl_hard_sti and rtl_hard_cli were used to perform the functions of disabling and restoring the interrupts.

• Modules rtl_schedule.o and rtl_time.o were ported, which required rtl_timer to be re-coded so as to have a real-time reference for scheduling a task. rtl_schedule had to be recoded so that it could schedule a task with real-time priority. We also had to resolve some issues relative to ispatching Linux tasks when RTLinux was up and running.

• As a result of porting RTLinux to MIPS, we could schedule more than one real-time task and could make certain interrupts real-time. When an interrupt occurs, RTLinux decides whether to execute it or keep it pending for normal Linux to handle. RTLinux disables interrupts only for the least possible period.

POSIX standard API's were available using rtl_posix.o module.

Response Time Measurement

Resources used were as follows . . .

• Necessary Hardware — SAB80C535 board (8051 compatible), 1488 and 1489 chips (to convert TTL voltage levels to RS232 voltage levels and back), +9V , -9V and +5V supply(we used 7809 and 7805 for +9V and +5V, -9V came from a second supply). The target system (MIPS ATLAS board with 4KC core) running RTLinux, had one RS232 serial port and a special driver was written for this. This driver had a Line Status interrupt service routine. Whenever the CTS signal on the port turn high, the driver should toggle the RTS in response.

• Optional Hardware — Breakout Box, CRO.

• Necessary Software — C Compiler for 8051 with ROM monitor debug feature (support for the SAB80C535 board). The serail port driver of the MIPS board running RTLinux has to be modified to respond to interrupts.

The following diagram illustrates the setup used for response time measurement . . .

Setup Diagram

RTLinux running on MIPS was tested using a serial port driver (the debug port of the Atlas board). Basically, a change in CTS used to generate an interrupt. Every low-to-high transition of CTS would make the RTS pin high (via an interrupt service routine), and a task is scheduled which subsequently sets the RTS pin low. The CTS signal to the COM port is made high through an output pin of the 80535. In response to this interrupt, the MIPS board (running RTLinux) will make RTS high. The time difference between these two events (CTS made high to RTS becoming high) represents the interrupt reponse time of the target system.

The steps followed to measure the interrupt response time are

• The CTS signal to the COM port is made high through an output pin of the 80535.
  
• The 80535 immediately starts polling the RTS pin, where it expects the response, as often as possible. The 80535 runs a time counter by incrementing a register.
  
• When the response is received on RTS pin (becomes high), the response time for that particular iteration is compared with a stored value (which is initially zero). If the present iteration response time is greater than the stored value, the present iteration response time is is stored.
  
• This loop is run as many times as wanted while some load (i.e. FTP, NFS activities, flood ping, etc.) is placed on the target MIPS board running the RTLinux system.
  
• When all the iterations are finished, the stored value will represent the worst case response time of the target RTLinux system.

The steps followed to measure the task response time are . . .

• A task is created which can make RTS pin low on the availability of a semaphore.
  
• The CTS signal to the COM port is made high through an output pin of the 80535.
  
• As RTS pin is made high in the ISR, and the semaphore is being released.
  
• The scheduled thread picks up the released semaphore, and makes the RTS pin low.
  
• The time difference between RTS-high and RTS-low is recorded as the task response time.

Observations

The following table summarizes the observations for the Interrupt and Task response time for MIPS 4KC platform . . .

Table of Results

Conclusion

The response time was measured for both interrupt and scheduler, and both response times were predictable and consistent. The figures in the above table indicate that the target system running the RTLinux system is capable of handling hard real-time applications. It has predictable and acceptable worst case timings for all the critical response times.

---

About the authors: Sachin Bharadwaj and M.R.Venkatesh are members of the Embedded System Group of Multitech Software Systems India. Bharadwaj serves as Project Leader, with responsibility for project management, technical leadership, and marketing support. Venkatesh, a software engineer, is responsible for implementation and testing of various embedded operating system projects based on ARM, MIPS, Motorola, and Intel processors. Aginotech Technologies Inc is the 100% US subsidiary of Multitech Software Systems India.

 
This article was originally published on LinuxDevices.com and has been donated to the open source community by QuinStreet Inc. Please visit LinuxToday.com for up-to-date news and articles about Linux and open source.