create New Value with ibosn systems


커널은 계층적/모듈 구조를 갖습니다.
소형 시스템(MICOM)용 운영체제입니다.
dooroos.Embedded is a embedded real-time operating system suitable for all the digital devices with very small memory in the form of multi-layered and modulated structure. dooroos.Embedded can be freely configurable to suit the characteristics of the production equipment, and requires a minimum of memory and system resources. In addition, the various basic modules are designed to be attached or dettached to/from digital system without constraints, then you can create a wide variety of very small embedded systems.
The preemptive scheduling based structure is used in dooroos.Embedded and provide additional policy, the round-robin scheduling. Also The Strong policy of time management makes to implement the may powerful features in the embedded systems required a tight time constraint.
Using a single address space, the kernel, middleware, and application of the single physical address space makes to be able to use the rapid implementation of real-time thread switching. And all component is loaded in the form of one image on the target system.
The record does not provide the user in arms, is the lack of features for the module itself felt capabilities can be inserted in the product. Of course, there is nothing functionally constraints.
When you write a driver or operating system, middleware, multi-threading capabilities of the various issues raised by (the synchronization, the sharing, and tasking conflicts ...) can be written without considering at all, to guarantee the stability of the system is possible.
Interrupt latency of the system, especially a constant delay in the real-time operating system is a very important issue. dooroos.Embedded provides always a constant interrupt delay and prevents efficiently the interrupt priority reserse. Most of the operating system interrupt for the delay in the implementation of multi-threading features considerable sacrifices in order to avoid conflicts and threads, and interrupt delay consideration when creating the driver should be written and will not affect the system. The creation of this relatively difficult for the driver in the operating system, the general developers are difficult to access. dooroos.Embedded resolves this issue at all these issues, so, developers can create without worrying about the driver at all for the delay does not affect interrupts.

Kernel : Minimum features and configuration of the operating system, at least to the library
Filesystem : To support the filesystem capabilities.
Network : To support the network capabilities.
Window : To support graphic winddown capabilities.
HAL : Porting the kernel to the hardware
Device Driver : Controls the hardware device
Library : Build a variety of functions
Application : System control main program

Server Concept : Only adding the server equipped with the necessary capabilities to expand the functions.
applicable of the external developmented Library : Developers can expand the library.
Indepency : The mutual independence between the servers to maintain and expand the shared resources available.

Mutual Independence : Independence Between modules make easy to debug and increase the stability
Modularity : Increasing the stability on the physical separation between the modules.
Block error propagation : Blocking the spread of problems in one module.

Very small memory requirement : Very small memory requirements on a very small kernel and it's configuration

The optimal product development : On high modularity, the optimal product development
Intuitive porting structure : Minimal Hardware-related functions and intuitive function configuration.
Exact technical support : The rapid support of operating system development group.
Price competitiveness : Excellent price competitiveness of products.

The nano-kernel of dooroos.embedded is the most important part, responsible for very small and powerful features and the core of the kernel, is especially connected and works directly with the hardware (HAL layer) and is connected directly. It connects the kernel to the kernel, and passes the hardware interrupts, such as the trap to the driver or kernel. In addition, It provides the basic functionality to the various kernel server running on the top of the features of the nano-kernel.
The other servers uses the kenrel API and library provided by nano-kernel and will operate on the nano-kernel. dooroos.embedded will be in charge of the important kernel features. The supported features of this servers is needed in most embedded system, and connects the above kernel servers to the nano-kernel services, and implements the library's functions exported from nano-kernel completely. In addition, a complete implementation of multi-threading has the ability to do only with this servers. Of course, all the modules are the server in the form of nano-kernel, is operated on the message-based communications of nano-kernel. The this servers is divided into three servers, time server, synchronization/communication server and device server to implement the functions.

  Multi-thread kernel
dooroos.embedded supports multi-thread.
Unlimited muilti-thread support.
Fast context switch between threads
Configuration for real-time processing

  Real-time scheduling
dooroos.embedded provides the perfect hard-real-time.
Support the fixed priority-based pre-emptive scheduling
Support the round-robin scheduling in the same priority
Support the wide priority range(0-255)

  Interrupt structure for real-time processing
For the minimum delay, dooroos.embedded provides the best of the interrupt structure.
Convert hardware interrupt to the virtual interrupt.
Support the dual strucure for interrupt minimum delay (interrupt low latency)
Support the interrupt through the thread.
Support the control of the interrupt priority through driver thread

  Message management
dooroos.embedded provides capabilities for communicating a message bus to the variety servers.
Support the quick message forwarding function
Support passing the interrupt through the message-passing
Support the port concept for sending and receiving messages
Support channel concepts for message sending and receiving server.
Modularization of the kernel features through the message bus

  Provides synchronization between threads
dooroos.embedded provides the synchronization of threads.
Support the critical-section function

  Various API support
dooroos.embedded provides the API for real-time function.
API support through system call
Real-time API support through the library call
Support the various library for kernel-servers.

  Time Server
Time Server is responsible for the time and time synchronization. Time Server implements the management for the time, Time-Out, Watch-Dog timer and the Thread's quantum management. This server is run on the tick timer interrupt or the request of other modules.
Functions for time of operating system through the tick timer.
Functions for API for time.
Functions for timer support of thread.

  Synchronization Server
The synchronization and communication between the dooroos.embedded threads is provided in synchronization server. Synchronization server supports the tools; semaphore, mutex, Event mechanism. And critical-section features is not serviced directly from the server, but it is serviced by system call of nano-kernel. When you use this synchronization features, there is a significant additional burden (overhead) in real-time applications. So, the proper use of this features can lead to prevent the burden. On writing applications using this resources available here, all the problems caused to the user should be prevented by the user. For example, threads waiting for the event resources that is given by other threads will continue running after the event receving. If that event is not given, these thread does not perform forever. Also, when multiple threads are running at the same time, deadlock may occur. In conclusion, the user using the services provided by the server will need considerable attention.
Conditional Variables
Message Queue
CriticalSection : Nano-kernel function

  Device (Driver) Server
Device server of the dooroos.embedded provides the attachment / detachment of the device driver. The device driver can be attached or detached to the dooroos.embedded freely without re-boot. The device server manages the access handle. All other parts can acquire the access handle from the device server. All device driver should be registered to the device driver to be accessed.
Device Driver attach/detach function.
Access handle management to device driver.

The filesystem server provides the data access service to the file on the block device. The application can use the various services of filesystem server to access the file. Some filesytems are provided, but the other filesystem can be plug-ined easily to the filesystem server without any restriction. The filesystem server uses the device server to access the block device, so block device driver should use standard device driver model.
The file access on block device.
The small memory requirement.
The access to various media(NOR filesystem, NAND filesystem, MMC, SD card,...)
The various media management support.
The simultaneous access to the various filesystem and the mounting function support.
The standard filesystem API support to the many filesystem.
FAT12/16/32 filesystem support.
ROM filesystem support
RAM filesystem support

The network server supports the TCP/IP network service. The application can use the network server to access the network. The socket interface is provided and TCP/UDP, IP, ICMP, ARP, RARP etc. is supported, but the not supported protocols can be implemented by using network server. The network device driver looks like the general device driver model, but some special network API is given.
The memory usage is defined to control the network throughput.
Provide the high speed and the high throughput network.
The stable network protocol is supported.
The network device driver regitration/deregistration.
Raw, TCP, UDP protocol.
IP, ICMP, ARP, RARP protocol.
Support ONLY one network device.

The window server manages the window on the display device. The application can use the window server to make the GUI and graphical interface. All the window is consist of the widget units. The widget is managed by the widget procedure supported by window server and is displayed on the screen by using the widget drawing fuctions and graphic library.
Window management support.
Standard window API support.
Drawing function call to display device.
The input device is connected to the thread
The graphic library and the window server is seperated.
User defined graphic library can be added.
The hardware dependent part is implemented in SDI (screen device drvier).