Different from the general-purpose operating systems like Linux, the traditional embedded operating systems have some particularities. For example, uClinux, uC/OS-II, eCos, and VxWorks usually run on non-MMU CPUs, without support for processes that have separate address spaces but only threads or tasks. Therefore, the runtime environments are entirely different. Therefore, we can configure and compile MiniGUI into three runtime modes for different operating systems:
MiniGUI can almost run on all operating systems under MiniGUI-Standalone mode theoretically. MiniGUI-Threads are suitable for real-time operating systems, which provide support for multi-task, or general-purpose operating systems like Linux/UNIX. Moreover, MiniGUI can run on only Linux operating system under MiniGUI-Processes mode.
No matter which mode is used, MiniGUI provides for applications the furthest compatibility; only a few initialization interfaces are different for different runtime modes.
MiniGUI-Processes is a successor of MiniGUI-Lite. It offers full-featured support for multi-process embedded operating systems, such as Linux and VxWorks 6. The runtime mode MiniGUI-Lite offered by MiniGUI V1.6.x and previous versions is designed for multi-process environment of Linux; We can run several client processes on the basis of efficient client/server architecture, and make use of superior features like address space protection. With MiniGUI-Lite runtime mode, the flexibility, stability, and scalability of embedded system based on MiniGUI will improve greatly. For example, we can run several MiniGUI client processes on MiniGUI-Lite, and if one process terminates abnormally, other processes will still run well. Moreover, on MiniGUI-Lite, it is convenient for us to integrate third-party applications. Actually, this is why many embedded device developers use Linux as their operating systems.
Although MiniGUI-Lite runtime mode provides support for multi-process, it cannot manage windows created by different processes at one time. Therefore, MiniGUI-Lite distinguishes windows in different processes by layers. This method fits for the most embedded devices with low-resolution screen, but brings some problems for application development.
MiniGUI V2.0 solves this problem completely. A window created by a client of MiniGUI-Lite is not a global object, i.e., a client does not know the windows created by others. However, windows created by MiniGUI-Processes are all global objects, and windows created by MiniGUI-Processes can clip each other. The following figure gives the screenshots of MiniGUI-Lite runtime mode of MiniGUI V1.6.x and MiniGUI-Processes runtime mode of MiniGUI 2.0.x.
In Figure 1 in the left sidebar, we run two client processes: vcongui and housekeeper. It is obvious that after housekeeper started, we could not see the windows of vcongui; in Figure 2 in the right sidebar, we run three client processes: vcongui, fminigui, and housekeeper, but we can see all windows created by these three clients.
Compared with MiniGUI-Lite, MiniGUI-Processes runtime mode has obvious advantages. So MiniGUI is not only useful for traditional embedded system (MiniGUI-Threads), but also useful for embedded system with multi-process features, such as Linux and VxWorks 6. Besides, MiniGUI-Processes keeps the concept of layer in MiniGUI-Lite. You can put windows of different client processes into different layers. By using layer, we can create many workspaces for different processes like X Window, whereas, the footprint of MiniGUI-Processes is far less than X Window. With the MiniGUI-Processes runtime mode, MiniGUI will extend its application fields in high-end embedded devices.
Figure 1
Figure 2
京ICP备05046847号-1；京公网安备11010802008976号；经营许可证号：110108004781535
