Conversion of desk-top operating system for real-time...

Electrical computers and digital data processing systems: input/ – Interrupt processing – Handling vector

Reexamination Certificate

Rate now

  [ 0.00 ] – not rated yet Voters 0   Comments 0

Details

C710S261000, C710S269000

Reexamination Certificate

active

06425038

ABSTRACT:

BACKGROUND OF THE INVENTION
The present invention relates to computer operating systems and in particular to a method of modifying of an embedded operating system for real-time embedded control thereby effectively creating a new computer operating system architecture.
Industrial controllers are special purpose computers used for controlling industrial processes or manufacturing equipment. Under the direction of a stored program, the industrial controller examines a set of inputs reflecting the status of the controlled process and changes a set of outputs controlling the industrial process. The inputs and outputs may be binary, that is on or off, or analog, providing a value within a continuous range. Typically analog signals are converted to binary words for processing.
An embedded operating system differs from general purpose operating system in two respects. The first is that the embedded operating system must provide a predictable, high speed response in reacting to input signals and changing output signals. Such fast and predictable responses are obtained by using hardware interrupts. Hardware interrupts make use of one or more physical lines communicating directly with a processor. A signal on any such line causes the processor to interrupt its current execution of a program (after saving stack registers and the like) and under hardware control to jump to an entry in a predefined interrupt vector table, the entry being determined by the particular interrupt line being activated. The interrupt vector table points to an address of an interrupt service routine, ISR, which the processor then executes. Upon completion of the ISR, the processor returns to the interrupted task. The hardware interrupt eliminates the need for the processor to poll input and output lines as part of the control program and thereby provides better use of processor resources and avoids the inherent delay caused by the intermittent nature of the polling process.
A second respect in which embedded operating system differ from general purpose operating systems is that the hardware configuration and software used in conjunction with an embedded operating system can be far more varied than that encountered by of a typical computer operating system. Normally an embedded operating system is custom configured from a wide variety of different types of input/output modules and communication modules and will execute a unique control program written particularly for the hardware configuration and control application at hand. One important point of variability in the hardware that is controlled by the embedded operating system is the hardware needed for communication protocols, both standard computer communication protocols and specialized protocols used principally for industrial automation. Such protocols may include open communication protocol such as Ethernet, ProfiBus, FieldBus, FireWire and DeviceNet, and proprietary data networks such as the Data Highway series of communication protocols developed by the assignee of the present application. In order to accommodate this variety of different communication protocols and the predictable, high speed responses required of such protocols used for industrial control, the embedded operating system may be constructed in modular form to allow different communication hardware (“cards”) to be interchanged by connection and disconnection on a common backplane.
An embedded operating systems ability to operate with a wide variety of data protocols cannot be easily matched by a standard embedded operating system. Such operating systems either prevent direct access by the user of the interrupt vector table or only allow access to the vector table at compile time. In a more general implementation of an embedded operating system the vector table is filled with addresses pointing to the operating system's interrupt “router” which handles all interrupts. This approach increases portability of the operating system between different processor types which may have different numbers of interrupt lines.
After the interrupts are directed to a single operating system router, they are forwarded to a limited number of ISR's (interrupt service routines) created by the user but loaded only at the time of generation of the operating system kernel. The user generated ISR's then poll the hardware devices to identify the particular device requiring service, and then reports this information back to the operating system which schedules an interrupt service “thread” including an appropriate software driver for later execution. The execution of the thread is according to the normal scheduling of tasks by the operating system and thus cannot be guaranteed to meet the response times required for high speed industrial control communication protocols. While the user generated ISR's can perform some handling of high speed communication tasks, the requirement that they be built in at the time of generation of the operating system kernel is unacceptable in an industrial control environment where hardware and thus ISR's must be changed in the field.
BRIEF SUMMARY OF THE INVENTION
The present inventor has recognized that the limitations of embedded operating systems in not allowing run time modification of interrupt service routines can be overcome by the technique of creating a “soft vectored” interrupt service routine at the time of generation of the operating system kernel and allowing the soft vectored interrupt service routine to redirect interrupts to “installable” interrupt service routines that are installed at a later time, for example, in the field. These installable interrupt service routines must be loaded so as to be accessible by the soft vectored interrupt service routines in the operating system space, and further after the installable interrupt service routines are loaded, the soft vectored interrupt service routine must be modified slightly to be able to identify the location of the installable interrupt service routines to forward interrupt requests. This is done by writing a loader function which, when invoked, loads the installable interrupt service routines and patches the soft vectors interrupt service routine with the address of the installable interrupt service routine. Potentially unlimited run-time modification to the interrupt service routines may thus be obtained while preserving, in addition, the ability to install drivers for less time critical aspects of the interrupt service that may be scheduled and loaded according to standard operating system protocol.
Specifically, then, the present invention provides a method of adapting an embedded operating system to allow the operating system to map real-time interrupt vectors to an operating system interrupt router which then activates an installed service routine which returns an indication of a device driver to be scheduled as a task for handling the interrupt. At the time that the operating system kernel is generated, the method includes the steps of generating an operating system accessible soft vector table and installing the soft vectored interrupt service routine which when executed interrogates the soft vector table to call a installable interrupt service routine indicated by the table. At run time, the method installs the installable interrupt service routine and loads the address of that installable interrupt service routine into the soft vector table.
Thus it is one object of the invention to provide for run time loading of interrupt service routines in a embedded operating system that normally requires interrupt service routines to be loaded at the time of generation of the operating system kernel.
It is another object of the invention to provide for an extremely high speed response to interrupts that allow such run time flexibility. In contrast, device drivers which are loadable at run time do not provide the reliable high speed response.
The method may include the additional steps of creating a loader function that executes to perform the run time steps described above and incorporating that

LandOfFree

Say what you really think

Search LandOfFree.com for the USA inventors and patents. Rate them and share your experience with other people.

Rating

Conversion of desk-top operating system for real-time... does not yet have a rating. At this time, there are no reviews or comments for this patent.

If you have personal experience with Conversion of desk-top operating system for real-time..., we encourage you to share that experience with our LandOfFree.com community. Your opinion is very important and Conversion of desk-top operating system for real-time... will most certainly appreciate the feedback.

Rate now

     

Profile ID: LFUS-PAI-O-2857706

  Search
All data on this website is collected from public sources. Our data reflects the most accurate information available at the time of publication.