VxWorks is a popular real-time multi-tasking operating system for embedded microprocessor systems, designed by Wind River Systems of Alameda, CA. Like Unix and Linux,
VxWorks is generally compliant with the IEEE's POSIX (Portable Operating System Interface) standard, version 1003.1b.
The current release of VxWorks is version 5.4. VxWorks projects are usually developed in the Tornado 2 Integrated Development Environment (IDE) which provides for specifying a configuration (e.g., the libraries with which a project is linked), project builds, and code testing.
Code is written is written C/C++ with segments, usually short, in the target processor's assembly language. VxWorks runs on many target processors including, but not limited to the following processors: Motorola PowerPC, 68K and CPU32 cores; MIPS; ARM; Intel X86 (386 and up) and i960. SPARC/SPARCLite.
The VxWorks kernel wind is a proprietary product, outwardly similar to Unix and Linux for its multiprocessing capability.
VxWorks is a popular real-time multi-tasking operating system for embedded microprocessor systems, designed by Wind River Systems of Alameda, CA. Like Unix and Linux, VxWorks is generally compliant with the IEEE's POSIX (Portable Operating System Interface) standard, version 1003.1b. The current release of VxWorks is version 5.4. VxWorks projects are usually developed in the Tornado 2 Integrated Development Environment (IDE) which provides for specifying a configuration (e.g., the libraries with which a project is linked), project builds, and code testing. Code is written is written C/C++ with segments, usually short, in the target processor's assembly language. VxWorks runs on many target processors including, but not limited to the following processors: Motorola PowerPC, 68K and CPU32 cores; MIPS; ARM; Intel X86 (386 and up) and i960. SPARC/SPARCLite.
The VxWorks kernel wind is a proprietary product, outwardly similar to Unix and Linux for its multiprocessing capability.
A newly spawned task enters the state diagram through the suspended state.
Tasks may be scheduled for execution by assigning them priorities, ranging from 0 (higest priority) to 255. Once started, that is, having entered the ready state in Figure 1, a task may execute to completion, or it may be assigned a fixed time slice in round-robin scheduling. A task blocks (enters the pended state) while another task takes control. A task may be prempted because it has consumed its time slice, or because another task with higher priority exists. Task priorities may be changed during execution. A task may avoid being preempted by locking the scheduler while it has control. (This does not prevent interrupts from occurring.)
A task may also enter the delayed state, for example while waiting a fixed time between reading samples within a task before processing them as a group, during which time another task may take control. The delay is controlled by an external timer which runs independently of processing (combined with a tick counter maintained by the kernel) that awakens the delayed task and avoids having the task tie up resources with an index counter which would prevent another task from executing.
The suspended state is used to halt a task for debugging without loss of its context registers.
Several system tasks exist concurrently with user defined tasks. These are the root task, named tUsrRoot; the logging task tLogTask; exception task tExcTask; and the network task tNetTask.
Intertask communication (corresponding to Unix/Linux Interprocess Communication) can occur through semaphores that provide interlocking and synchronization of tasks, and messaging that allow tasks to communicate events or data with each other. Although semaphores and messaging are implemented with different kernel mechanisms, it is customary to treat them together.
Semphores can be categorized as ordinary binary semaphores and a special class of binary semaphores called mutual exclusion semaphores. Binary semaphores are used for task synchronization. As implemented in VxWorks, a binary semaphore has two values: full and empty. When full, it is available for a task. When empty, it is unavailable. A pending task proceeds by taking an available semaphore, which makes the semaphore empty or unavailable.. When the semaphore is no longer needed (because the task is about to return to the pending state), it gives the semaphore which makes it full or available for another task. A mutual exclusion semaphore (also called a mutex) allow one task to have exclusive use of a resource while it is needed.
The difference between an ordinary binary semaphore and a mutex semaphore is in the way the semaphore is initialized. For an ordinary binary semaphore, a task attempting to synchronize to an external event creates an empty semaphore. When it reaches the point to be synchronized, it attempts to take a semaphore. If unavailable, it waits at this point. A second task which controls the synchronization event gives the semaphore when it is no longer needed. The first task receives notification that the semaphore is available and proceeds. For a mutex semaphore, a task wishing to block other tasks from a resouce first creates a full semaphore, and then takes the semaphore, making it unavailable to other tasks. When it is no longer needed, it the task gives the semaphore, making the resource available. A mutual exclusion semaphore must have matching "takes" and "gives".
These ideas can be illustrated with the following code segments.
Innovative real-time embedded systems need a robust real-time operating system (RTOS) that leverages the latest and greatest enhancements in processor and hardware technology. Why is VxWorks the RTOS for your next project?
VxWorks drives RTOS innovation in key requirement areas for embedded systems. By their very nature, embedded systems are constrained by memory, performance, and power consumption. Application requirements continuously grow to satisfy new safety and security standards and customer value criteria such as rich user interfaces and connectivity. VxWorks meets these growing requirements with unparalleled RTOS innovation:
At Wind River, we take pride in the innovations in VxWorks that have made it the No. 1 RTOS in the world, and we're committed to continued innovation in each of our core strength areas:
VxWorks is generally compliant with the IEEE's POSIX (Portable Operating System Interface) standard, version 1003.1b.
The current release of VxWorks is version 5.4. VxWorks projects are usually developed in the Tornado 2 Integrated Development Environment (IDE) which provides for specifying a configuration (e.g., the libraries with which a project is linked), project builds, and code testing.
Code is written is written C/C++ with segments, usually short, in the target processor's assembly language. VxWorks runs on many target processors including, but not limited to the following processors: Motorola PowerPC, 68K and CPU32 cores; MIPS; ARM; Intel X86 (386 and up) and i960. SPARC/SPARCLite.
The VxWorks kernel wind is a proprietary product, outwardly similar to Unix and Linux for its multiprocessing capability.
VxWorks is a popular real-time multi-tasking operating system for embedded microprocessor systems, designed by Wind River Systems of Alameda, CA. Like Unix and Linux, VxWorks is generally compliant with the IEEE's POSIX (Portable Operating System Interface) standard, version 1003.1b. The current release of VxWorks is version 5.4. VxWorks projects are usually developed in the Tornado 2 Integrated Development Environment (IDE) which provides for specifying a configuration (e.g., the libraries with which a project is linked), project builds, and code testing. Code is written is written C/C++ with segments, usually short, in the target processor's assembly language. VxWorks runs on many target processors including, but not limited to the following processors: Motorola PowerPC, 68K and CPU32 cores; MIPS; ARM; Intel X86 (386 and up) and i960. SPARC/SPARCLite.
The VxWorks kernel wind is a proprietary product, outwardly similar to Unix and Linux for its multiprocessing capability.
A newly spawned task enters the state diagram through the suspended state.
Tasks may be scheduled for execution by assigning them priorities, ranging from 0 (higest priority) to 255. Once started, that is, having entered the ready state in Figure 1, a task may execute to completion, or it may be assigned a fixed time slice in round-robin scheduling. A task blocks (enters the pended state) while another task takes control. A task may be prempted because it has consumed its time slice, or because another task with higher priority exists. Task priorities may be changed during execution. A task may avoid being preempted by locking the scheduler while it has control. (This does not prevent interrupts from occurring.)
A task may also enter the delayed state, for example while waiting a fixed time between reading samples within a task before processing them as a group, during which time another task may take control. The delay is controlled by an external timer which runs independently of processing (combined with a tick counter maintained by the kernel) that awakens the delayed task and avoids having the task tie up resources with an index counter which would prevent another task from executing.
The suspended state is used to halt a task for debugging without loss of its context registers.
Several system tasks exist concurrently with user defined tasks. These are the root task, named tUsrRoot; the logging task tLogTask; exception task tExcTask; and the network task tNetTask.
Intertask communication (corresponding to Unix/Linux Interprocess Communication) can occur through semaphores that provide interlocking and synchronization of tasks, and messaging that allow tasks to communicate events or data with each other. Although semaphores and messaging are implemented with different kernel mechanisms, it is customary to treat them together.
Semphores can be categorized as ordinary binary semaphores and a special class of binary semaphores called mutual exclusion semaphores. Binary semaphores are used for task synchronization. As implemented in VxWorks, a binary semaphore has two values: full and empty. When full, it is available for a task. When empty, it is unavailable. A pending task proceeds by taking an available semaphore, which makes the semaphore empty or unavailable.. When the semaphore is no longer needed (because the task is about to return to the pending state), it gives the semaphore which makes it full or available for another task. A mutual exclusion semaphore (also called a mutex) allow one task to have exclusive use of a resource while it is needed.
The difference between an ordinary binary semaphore and a mutex semaphore is in the way the semaphore is initialized. For an ordinary binary semaphore, a task attempting to synchronize to an external event creates an empty semaphore. When it reaches the point to be synchronized, it attempts to take a semaphore. If unavailable, it waits at this point. A second task which controls the synchronization event gives the semaphore when it is no longer needed. The first task receives notification that the semaphore is available and proceeds. For a mutex semaphore, a task wishing to block other tasks from a resouce first creates a full semaphore, and then takes the semaphore, making it unavailable to other tasks. When it is no longer needed, it the task gives the semaphore, making the resource available. A mutual exclusion semaphore must have matching "takes" and "gives".
These ideas can be illustrated with the following code segments.
Innovative real-time embedded systems need a robust real-time operating system (RTOS) that leverages the latest and greatest enhancements in processor and hardware technology. Why is VxWorks the RTOS for your next project?
- Proven: VxWorks is the RTOS that powers more than 1 billion real-time systems across the globe, from small consumer products to commercial airliners. When the consequences for failure are expensive or, worse, life threatening, VxWorks RTOS is the only choice. After 30 years of RTOS leadership and consistently successful deployments, Wind River is the name you know you can trust.
- Optimized: VxWorks RTOS has been optimized for performance, determinism, and code footprint on each processor platform it runs on. VxWorks RTOS is also optimized for specialized hardware support for such features as network acceleration and graphics. Why waste processing power on a non-optimized RTOS?
- Innovative: VxWorks is leading the market in RTOS innovation. The first RTOS with 32-bit and 64-bit processing, multi-core and multi-OS support, and diverse connectivity options, VxWorks provides our customers with the leading-edge RTOS functionality they require to stay competitive. Why go with an RTOS that doesn't provide the solutions you need to take advantage of the latest technology?
VxWorks drives RTOS innovation in key requirement areas for embedded systems. By their very nature, embedded systems are constrained by memory, performance, and power consumption. Application requirements continuously grow to satisfy new safety and security standards and customer value criteria such as rich user interfaces and connectivity. VxWorks meets these growing requirements with unparalleled RTOS innovation:
- Multi-core/multi-OS: VxWorks is designed for use in various multi-core configurations as a single operating system in symmetrical multiprocessing (SMP) and asymmetrical multiprocessing (AMP) modes or as a guest RTOS on top of Wind River Hypervisor.
- Scalability: VxWorks offers robust and reliable RTOS performance on small memory- and CPU-constrained devices up to full 64-bit multi-core systems for high-end processing. Because of this scalability, VxWorks is the ideal RTOS for creating a common software platform for a product line of embedded devices.
- Security and safety: Our leadership in safe and secure systems includes an RTOS with COTS certification for conforming to the highest levels of global safety standards, including RTCA DO-178B, EUROCAE ED-12B and IEC 61508. VxWorks also provides a multilevel secure (MLS), High Robustness RTOS for the demanding requirements of the Common Criteria and National Information Assurance Partnership (NIAP). VxWorks is the first RTOS to be certified under Wurldtech's Achilles certification program, an internationally recognized standard for industrial cyber-security.
- Connectivity: VxWorks provides industry-leading advanced networking solutions for every facet of embedded systems communications, from device to device via USB, and core to core in an AMP multi-core system with MIPC.
- Graphics: VxWorks RTOS and Wind River Media Library form a robust platform for embedded graphics solutions. With Wind River Tilcon Graphics Suite, developers have a complete graphical user interface (GUI) development system for next-generation devices.
At Wind River, we take pride in the innovations in VxWorks that have made it the No. 1 RTOS in the world, and we're committed to continued innovation in each of our core strength areas:
- Footprint: VxWorks has a completely configurable and tunable small memory footprint for today's memory-constrained systems. You control how much of the operating system you need.
- Real-time performance: Capable of dealing with the most demanding time constraints, VxWorks is a high-performance RTOS tuned for both determinism and responsiveness.
- Reliability: A high-reliability RTOS, VxWorks provides certification evidence required by strict security standards. Even for non-safety-critical systems, VxWorks is counted on to run forever, error free.
- Scalability: An indispensable RTOS foundation for very small-scale devices, large-scale networking systems, and everything in between, VxWorks is the first RTOS to provide full 64-bit processing to support the ever growing data requirements for embedded real-time systems. VxWorks is scalable in terms of memory footprint and functionality; you will tune it to the exact needs of your project.
Custom Search
If you liked this article, subscribe to the feed by clicking the image below to keep informed about new contents of the blog:
0 commenti:
Post a Comment