|
Special Feature 1 Spring 2011 Next Generation Version Loaded with New Functions T-Kernel 2.0 Appears at Last T-Kernel was made public in 2002. Valued for its outstanding real-time performance and small footprint, its high development efficiency, and more than anything else its open approach, it has been adopted in many embedded devices, from information terminals to satellites. And then eight years. Responding to the demands of a new age, a new powered up version will finally appear next spring. Heralding its release to the public, we are promptly introducing in this magazine the expectations Prof. Sakamura has placed in this new OS plus an outline of its new functions. |
We started development of T-Kernel around 2000, just about 10 years ago from the present. At the time, ITRON's actual results, such as the public announcement of examples in which ITRON had been loaded for engine control in automobiles, had begun to become known even to the general public, and examples of ITRON's adoption in AV devices, such as digital cameras, and OA devices, such as multifunctional copiers, were increasing. ITRON at this point in time had become almost mature technology, and it was in the process of proceeding from the research and development phase into the popularization phase.
ITRON is an OS for real-time control use. It is compact, and, moreover, it was designed by narrowing down functions in order to raise performance. Normally, functions such as file management and device management are not needed. However, together with the evolution of applications, several cases began to appear in which makers independently added these functions. Because they were not standardized functions, there were difficulties on the points of software compatibility and reusability, and that it was difficult to raise development efficiency had become an issue.
Following products becoming highly functional, together with compatibility with file systems and networks becoming indispensable, the development efficiency of software has also become an important problem. Together with the appearance of highly functional microprocessors, OSs for information processing use have also been studied. For example, there is Linux, the popularization of which began from about that time. However, there were problems in that with something for which file and network functions were easy to utilize and development efficiency was also raised, high performance real-time control was not possible, and hardware resource consumption, such as memory, was also great. As a high-performance embedded device OS, an OS of the type that possessed the merits of ITRON and Linux together was necessary, and numerous attempts of that type were also carried out.
The OS that was developed against this type of background was T-Kernel, and its aim is the coexistence of high-performance real-time control and high-level information processing equal to that of Linux and Windows. In T-Kernel, we are also making use of ITRON's real-time control functions as is, have raised OS extensibility by introducing subsystem functions, and utilizing these, we have developed basic middleware (T-Kernel Standard Extension), which provides process management and process functions. In embedded devices loaded with T-Kernel, in addition to high-performance style real-time control based on T-Kernel itself, T-Kernel Standard Extension provides so-called information type OS functions, and thus we can carry out high-level information processing equal to Linux and Windows. Through this type of system design, what we have made to try to answer the demand for high-end embedded devices in which both function and performance are sought is T-Kernel.
Actually, adoption in intelligent embedded devices in which high-level information processing is necessary, such as car navigation systems, printers, and handy terminals for business, is proceeding, and thus the appropriateness of the basic design at the outset has been proved. It is expected that embedded devices becoming intelligent will proceed more and more in the future, and thus T-Kernel in which high-performance real-time control and high-level information processing can coexist will hereafter probably go on to be loaded onto more more devices than up to now. Moreover, close to 10 years from the development of T-Kernel have elapsed, and, during this period, software resources on top of T-Kernel, such as device drivers and middleware, have also increased. From this state of affairs, the basic design and software configuration of T-Kernel will hereafter be unchangeable, and there will be no instances in which the basic specification of the OS will change either.
However, when we compare T-Kernel at the time of its design and the present, beginning with processors becoming high performance, highly functional, and highly integrated, and memory and disks becoming large capacity, the embedded device hardware and OS operational environment has greatly changed. Moreover, requests, such as detailed function additions and expansion of the range of standardization, have also appeared in the form of feeding back from experience from such things as products in which T-Kernel has been adopted and development examples. Reflecting this state of affairs, what has been versioned up into an OS that is easier to use and put to use hardware that has become high performance while leaving the basic parts of T-Kernel as is is T-Kernel 2.0.
In T-Kernel 2.0, things such as time control functions in microsecond units (cyclic handler, alarm handler, timeouts, etc.) and compatibility with 64-bit large-capacity devices have been added. All of them are additional functions that are upwardly compatible in regard to the T-Kernel of the past (T-Kernel 1.0). On the other hand, outside of maintaining compatibility with T-Kernel 1.0, all the T-Kernel 1.0 system calls have been left as is, because there are also not few uses in which these added functions are not necessary. For example, in T-Kernel there are system calls that control time in units of milliseconds, and system calls that carry out device input/output operations in 32 bits, but on top of having left these system calls as is, system calls that control time in units of microseconds, and that carry out device input/output operations in 64 bits have been added. For this reason, in regard to T-Kernel 1.0, there comes about binary compatibility and, further, source compatibility, and thus existing device drivers, middleware, applications, etc., for T-Kernel 1.0 use can all be executed as is without the need for recompiling.
Among the above mentioned added functions, there probably isn't any need for an explanation in regard the demand for compatibility with 64-bit large-capacity devices. As to the memory capacity of hard disks, etc., making the capacity greater and greater is proceeding; when it gets to capacity on the order of terabytes, expressing block numbers (sector numbers) with 32 bits becomes impossible. On the other hand, in regard to time control functions in units of microseconds, there are uses in such things as FA control equipment where the specification of detailed time is required, and programmable controllers (PLC). Demands of this type are still not still not many, but in a portion of uses they form a pressing demand.
Incidentally, what we call 1 microsecond (msec) that can be specified in T-Kernel 1.0, is the time to rotate just 36 degrees, if it's an engine or a motor that rotates 6,000 times each minute (6000 rpm). When this becomes microseconds (µsec), this is 1/1000, in other words, it is the time to rotate just 0.036 degree. In terms of machine control, there aren't many settings in which detailed resolution to this extent is necessary. Having said that, in the case of controlling an engine or a motor, there is the possibility that things will be too rough with control in units of 36 degrees for a millisecond. Even if a resolution of 1 microsecond is not necessary, there is the possibility that control in units of 100 microseconds corresponding to an angle of rotation of 3.5 degrees will be necessary, and, in that case, the added functions of T-Kernel 2.0 are effective.
On the other hand, when we look at communications concerns, if there's a 100 Megabit/second network, data transmission of 100 Kilobits (10 Kilobytes) per millisecond, and 100 bits (10 bytes) even per microsecond are possible; and there is the possibility that cases where we would like to control at this order of temporal granularity will come to increase in the future. Moreover, if we use the latest high-performance microprocessors, there will also be cases in which the processing time of T-Kernel system calls and task switching (task dispatch) will become less than 1 microsecond. When that comes about, for example, even though you have terminated after having created a task and carried out some sort of processing that includes the execution of several system calls, everything will end up finishing in a time of under 100 microseconds. If this type of processing exists in multiple and you try controlling them efficiently while watching the time, cases will come to appear in which things are too coarse in units of milliseconds.
Concerning the details of the added functions of T-Kernel 2.0, I would like you to look at the special feature.
In T-Kernel 2.0, in addition to the strengthening of the kernel's main body, we carry out widespread additions and improvements to even to the parts that correspond to "setting the table" on its periphery. In concrete terms, we will raise ease of use by carrying out expansion of the range and integrating into one package software that we will make public as open source.
We have made public the source of the main body of T-Kernel from the past, but concerning T-Monitor [Note 1], which is essential in the utilization of T-Kernel, due to the reason that its hardware dependency is strong, we have made public only the specification, and have not provided implementations (programs). Moreover, also concerning a portion of the device drivers and the development environment, although there were ones we provided on a sample basis, they were not official provisions for T-Kernel use, and thus in order to use T-Kernel, it was necessary to do such things as obtain a development environment separately on your own and develop device drivers.
At the time of the release of T-Kernel 2.0, we will greatly improve on this point, and thus we will collect together and provide all the software necessary in development. In other words, we will include T-Kernel, T-Monitor, device drivers, and the development environment all inside one package, and, in the manner of a Linux distribution, we will make it so that one can begin T-Kernel software development just by downloading this package. We call this one-stop service.
Among these, T-Monitor and the device drivers are hardware dependent, and even in a portion of T-Kernel, there are parts that depend on the CPU and the hardware. Therefore, these hardware-dependent parts are made up as programs targeted at a particular board (we call this the T-Engine reference board) for which the public release of technical information is possible, and that board and CPU hardware information also will be made public together with the programs. When we look at T-Kernel from the standpoint of makers who embed T-Kernel into devices, because the technical information of the hardware that will become the porting source and the programs that will run on top of the board have been made public, it's fine if one compares the hardware technical information of the porting source and the porting target, and then carry out porting and revision of programs that correspond to the differences between the two.
As for T-Engine reference boards, the T-Engine Forum, outside of providing one type for the time being, is planning to add others in the future. Important points as requirements for T-Engine reference boards are that T-Kernel 2.0 and its device drivers run, plus that related technical information can be made public; we do will not make any prescriptions concerning the board size and the location of connectors in the manner of the standard T-Engine board and the µT-Engine board.
The development environment that will be included in the package and made public is the same as in the past and is one that is gcc based; in addition to a compiler, linker, and debugger (gdb), it will also be provided together with the GUI base integrated development "Eclipse" and a simulator that runs on top of PCs, thus making it into something with far higher convenience than in the past.
Outside of this, we will also carry out a broad revision of the T-Kernel specifications. Up to now, we have carried out provision of specifications based on the PDF format, which assumed printing, but, with T-Kernel 2.0, giving forethought to the electronic utilization of the specification, we will provide an XML format specification as an electronic document. As for an XML format electronic specification, outside of being able to convert it into HTML format and viewing the necessary passage with a browser, you can change the format in accordance with need, to such things as the PDF format for printing, the format for use with the UNIX man command, and a format in which you can use the specification as help when you input the system call on top of the development environment, which raises the usability of the specification itself.
Furthermore, in order to systematically manage the record of T-Kernel versions and changes, we will introduce a source code traceability by assigning ucodes to the source code. By means of this system, even for bugs that might occur, grasping their background range becomes easy, and a rapid response becomes possible.
The T-Engine Project, at the point where it will soon approach 10 years, is broadly reforming its contents, and it is aiming at further raising ease of use and the expansion of uses. We call this "T2," and we will announce its details at TRON Show 2011. The first results of "T2" are T-Kernel 2.0 and one-stop service, but even afterward we are planning further step-ups, such as enhancing T-Kernel Standard Extension and making middleware replete.
Aiming at its second stage "T2," the T-Engine project's second chapter has now begun.
____________________
[Note 1] What we call T-Monitor is software positioned to mediate between T-Kernel and the hardware; it carries out such things as initial hardware settings and T-Kernel boot processing, plus interrupt and exception handling. Also, it provides debugging functions at a level close to the hardware.
The above article on T-Kernel 2.0 appeared on pages 6-8 in Vol. 126 of TRONWARE. It was translated and loaded onto this Web page with the permission of Personal Media Corporation.
Copyright © 2010 Personal Media Corporation
Copyright © 2011 Sakamura Laboratory, University Museum, University of Tokyo