INtime SDK Help
INtime System Description
INtime 5 introduced the possibility of an application distributed among multiple nodes on several hosts. This section described the INtime System and how the architecture can support such an application.
INtime runs on a PC. A PC platform is considered a host, and includes one or more Intel Architecture processors which may be a single core or multicore processor, with or without hyper-threading. Each core or hyper-thread is referred-to as a "hardware thread", a hardware entity which reads and executes instructions.
Host memory may be divided into partitions, for exclusive use by different instances of the INtime RTOS, or by Windows. In INtime for Windows, I/O devices may be assigned to a partition so that they are not accessible from a different partition or from Windows. An INtime partition may also have a dedicated hardware thread (core, hyper-thread) assigned to it for its exclusive use.
Host partitioning makes it possible to implement a subsystem which runs in isolation from other subsystems in separate partitions. The degree of isolation is, to some extent, dependent on the underlying platform architecture.
This figure shows how a 4-core processor platform may be partitioned with four INtime nodes. The system is divided into three subsystems: general services, motion control and vision subsystems. The first node is in control of the basic system devices (disk, network, console), and the other nodes have specific devices assigned to each one.
A node is an instance of the INtime operating system, including the kernel and the applications that are running on it. A Windows node is an instance of the Windows operating system, including the Windows applications that are running on it.
Hyper-threaded and multicore processors can run several nodes simultaneously. Each node may be assigned to a hardware thread.
The default configuration of INtime for Windows after installation is to dedicate a hardware thread to INtime. All supported versions of Windows require a hardware thread to be dedicated to INtime.
INtime for Windows is configured in Dedicated boot mode since INtime 7:
Multiple INtime nodes
INtime always runs on a single processor and there may be multiple instances of INtime, whereas Windows can run on more than one processor and there is always at most one instance of Windows.
The SDK and supporting development tools and any application supporting the INtime application are run on the Windows node alongside the INtime node on the same processor.
In the INtime Distributed RTOS configuration, Windows does not run on the same platform and processor as the INtime node(s). INtime can run on some or all of the target’s processor nodes depending on how it is configured by the user.
Figure: Two Quad-core processors platforms, one is configured with Windows and the other is loaded with four instances of INtime RTOS one per Core. INtime SDK and debugging tools run on the Windows platform. INtime applications must run on the second platform. Any Windows application that is running in conjunction with an INtime applications must run on the Windows platform and communicate via Ethernet with the INtime application.
Each INtime node is given a unique name on a given host in order to facilitate inter-node communications. The name is used to distinguish between different nodes.
By default an INtime system is installed with a single node, named NodeA, which can be renamed by the user. Subsequent nodes can be named by the user as they are enabled (see setup configuration section for details).
Nodes on different hosts use the host name as part of the full INtime node name, in order to provide a unique name across a whole system of INtime nodes on multiple hosts.
The host name used by INtime is the fully-qualified domain name, if available, or else a name assigned to the host during installation.
The full INtime node name is written as a combination of the host name and node name, thus:
myhost.domain.com/NodeA
It also has a URL form:
intime://myhost.domain.com/NodeA
The INtime operating system creates a virtual communications layer which enables an application running on one node to access objects created on a different node on the same host or another host.
Figure shows two hosts each supporting two nodes that are linked via a virtual "GOBSnet" layer to enable applications running on separate nodes to pass and share information. See the Distributed Applications section for a complete description of this technology.
Windows applications can interact directly with INtime applications using a Windows API called NTX which allows access to INtime objects. The programming interface is the same whether the INtime node is on the same host as Windows, or if it is on a different host.
The INtime components include:
❶ INtime kernel.
❷ Real-time application, C, and C++ libraries: Gives direct access to the RT kernel services for RT threads. For an overview of calls in these libraries, see INtime kernel system calls in the INtime Kernel section. For detailed information, including syntax and parameter values, see high level, low level, C calls, and C++ calls.
❸ NTX library: Provides RT interface extensions for the Win32 API that allows Windows threads to communicate and exchange data with RT threads within the application. For an overview of calls in this library, see NTX system calls in the INtime Kernel section.
❹ Transport driver: A driver that converts information to the protocol needed by the specified transport mechanism. For details, see Transport Mechanisms, below.
❺ Transport mechanism: The communication protocol or method used by NTX to communicate between Windows and RT threads. Whether the various portions of your INtime applications reside on a single PC, or on multiple computers accessed via Ethernet cable, NTX provides this essential communication. For details, see Transport mechanisms.
With INtime software, NTX communicates between Windows and Real-time (INtime) portions of an applications, whether they reside on a single PC (single- or multi-core, or on separate computers accessed via Ethernet cable:
❶ The Windows portion of INtime applications, located on a Windows host, makes NTX calls that communicate with INtime nodes.
❷ NTX determines INtime node locations, detects the connection method, and determines how to communicate between Windows and INtime threads.
❸ NTX uses the appropriate transport method to communicate with applications running on INtime nodes.
Transport methods available to NTX include: