ThreadX RTOS ..

ThreadX is advanced Real-Time Operating System (RTOS) designed specifically for deeply embedded applications. ThreadX provides advanced scheduling facilities, message passing, interrupt management, and messaging services, as well as many others. ThreadX has many advanced features, including its picokernel™ architecture, preemption-threshold™ scheduling, event-chaining,™ and a rich set of system services. Combined with its superior ease-of-use, ThreadX is the ideal choice for the most demanding of embedded applications. ThreadX has been deployed in over over 2 billion electronic products in the areas of consumer devices, medical electronics, and industrial control equipment.Similar RTOSes are available from other vendors such as VxWorks, Nucleus RTOS, OSE, QNX, LynxOS, etc.

ThreadX is implemented as a C library. Only the features used by the application are brought into the final image. The minimal footprint of ThreadX is under 2KB on Microcontrollers.

• Minimal Kernel Size: Under 2K bytes
• Queue Services: 900 bytes
• Semaphore Services: 450 bytes
• Mutex Services: 1200 bytes
• Block Memory Services: 550 bytes
• Minimal RAM requirement: 500 bytes
• Minimal ROM requirement: 2K bytes

The name ThreadX is derived from the fact that threads are used as the executable modules and the letter "X" represents context switching, i.e., it switches threads. ThreadX can be seen as the "QThreads" of SystemC implemented in preemptive fashion. Like most RTOSes, ThreadX uses a multitasking kernel with preemptive scheduling, fast interrupt response, memory management, interthread communication, mutual exclusion, event notification, and thread synchronization features.

ThreadX is generally used in real-time embedded systems, especially in deeply embedded systems. Developing embedded systems using ThreadX is usually done on a host machine running Linux or Microsoft Windows, using cross-compiling target software to run on various target processor architectures. Several ThreadX-aware development tools are available, such as Wind River Workbench, ARM RealView, Green Hills Software's MULTI, Metrowerks CodeWarrior, IAR C-SPY, Lauterbach TRACE32, and visionCLICK.

ref:

http://en.wikipedia.org/wiki/ThreadX

http://rtos.com/products/threadx/

https://students.cs.byu.edu/~cs345ta/reference/RT%20Embedded%20Multithreading.pdf

http://amkamboh.seecs.nust.edu.pk/index_files/Multitasking%20Demo.pdf

http://rtos.com/products/guix/

ThreadX Application API - http://rtos.com/images/uploads/programmersguide_threadx.pdf

ThreadX to Linux porting -

• http://www.mapusoft.com/port-threadx-applications-to-linux/
• http://www.slideshare.net/MapuSoft/easy-way-to-port-thread-x-applications-to-linux
• http://info.mapusoft.com/Webinar3-29-11Webdnldpg.html

Systems Engineering ..

Systems engineering is an interdisciplinary field of engineering that focuses on how to design and manage complex engineering systems over their life cycles.

1. Focus on holistic product Architecture(Eco-System, System, Sub-System, Component)
2. Know your key stakeholder & involve them early in the decision making process
3. Focus on Why .. Ask right questions all the time
4. Trace tests(System tests, integration tests, unit tests) to Requirements/Needs
5. Focus on Usage model to come up with Business Requirements
6. Focus on Logic Architecture before jumping to product physical design
7. Follow RAPID approach in decision making
8. Follow V model of development

ref:

Systems Engineering - http://en.wikipedia.org/wiki/Systems_engineering

V-model - http://en.wikipedia.org/wiki/V-Model_%28software_development%29

Windows User-Mode Driver Framework (UMDF) ..

Windows Driver Frameworks (WDF) is a set of libraries that you can use to develop device drivers that are interoperable with Windows. WDF is comprised of Kernel-Mode Driver Framework (KMDF) and User-Mode Driver Framework (UMDF). UMDF is a framework for the creation of user-mode drivers. Like Kernel-Mode Driver Framework (KMDF), UMDF provides an abstraction layer from WDM, handling much of the Plug and Play (PnP) and power management functionality, and allowing the driver to opt in for specific functionality and event handling.

Writing a driver using UMDF version 1.x requires using the COM programming model to write C++ code. While UMDF version 1 is based on the same conceptual driver programming model as KMDF, UMDF 1 implements the model with different components, device driver interfaces (DDIs), and data structures. In contrast, starting in UMDF version 2, you can write a UMDF driver in the C programming language that calls many of the methods that are available to KMDF drivers. All of the interfaces that are shared between UMDF version 2 and KMDF have the same names, parameters, and structure definitions. If your driver uses only shared functionality, or uses conditional macros around calls that are only supported in one framework, you can write a single driver that you can compile with either UMDF or KMDF.

UMDF drivers abstract hardware functionality, run in the user-mode environment, and can access various services. UMDF drivers operate as part of a stack of drivers that manage a device. File system drivers, display drivers, and print drivers cannot be UMDF drivers. 

A UMDF driver interacts with the following system-supplied components:

Driver host process:
The driver host process loads vendor-supplied UMDF drivers and framework DLLs, provides an execution environment for user-mode drivers, and routes messages between drivers in a user-mode stack. The driver host process (Wudfhost.exe) is a child process of the driver manager service. Wudfhost.exe usually runs in the LocalService account, which has minimum privileges on the local computer. An instance of Wudfhost.exe loads one or more UMDF driver DLLs, in addition to the framework DLLs. The driver host process provides a runtime environment that handles interprocess communication (IPC) between the driver manager and the reflector, as well as I/O dispatching, driver loading, driver layering, and thread pool management.

Driver manager:
The driver manager is a Windows service that manages all instances of the Wudfhost driver host process. The driver manager launches and tracks information about each driver host process. Each host is a child process of the driver manager. Only one driver manager exists per system. The driver manager starts during installation of the first UMDF device and runs on the system thereafter.

Reflector:
The reflector is a kernel-mode driver that permits an application and a driver host process (and user-mode device stacks) to communicate. The reflector creates a separate device object for each device instance and handles Plug and Play (PnP) and power I/O requests associated with each device instance. All communication between the application and the driver host process happens through the reflector.

If your driver requires one of these features, you must write a KMDF driver:
While UMDF version 2.0 offers a significant subset of functionality that was previously available only to KMDF drivers, the following features are available only to KMDF drivers. 

• Direct memory access (DMA)
• Bus enumeration
• Functional power states (limited support is available in UMDF)
• Access to WDM objects
• Neither Buffered Nor Direct I/O
• Internal device control requests (IOCTLs)
• Remove lock opt-in for I/O requests

Advantages of Writing UMDF Drivers:

• UMDF drivers contribute to greater operating system stability because they have access only to the address space of the process in which they run.
• Because UMDF drivers run under the LocalService account, they have limited access to a user's data or to system files.
• User-mode drivers operate in a much simpler environment than kernel-mode drivers. For example, kernel-mode drivers must take into account IRQL, page faults, and thread context. In user mode, however, these issues do not exist. User-mode drivers always run in a different thread from the requesting process and can always take page faults.
• UMDF version 2 offers feature parity with KMDF in most areas. For a full comparison, see Comparing UMDF 2.0 Functionality to KMDF.
• UMDF version 2 facilitates converting between KMDF and UMDF. See How to convert a KMDF driver to a UMDF 2.0 driver (and vice-versa).
• You can debug UMDF drivers by using either a user-mode debugger or, starting with UMDF version 2, a kernel-mode debugger.
• You can use the Wdfkd.dll debugger extension commands with KMDF and starting with UMDF version 2. For more info, see Debugger Extensions.

A fundamental goal of the overall WDF model is to provide intelligent defaults, so that you can focus on your device hardware and avoid writing code to perform tasks that are common to most drivers. To achieve this goal, the framework is designed to work with drivers on an "opt-in" basis. When you write a UMDF driver, you provide callback routines for only the events that affect your device. For example, some devices require intervention immediately after they are turned on and just before they are turned off. The driver for such a device can implement callback functions that the framework calls at those times.

The driver includes code to handle only those events for which its device requires device-specific support. All other events can be handled by framework defaults.
In addition, a driver can configure its I/O request queues so that the framework stops dispatching requests while the device is in a low-power state and resumes dispatching after the device has returned to the operational state. Similarly, if an I/O request arrives while the device is in a low-power state, the framework can automatically turn on the device.

Misc Info:

• The Windows 10 WDF source code is now available as open source on GitHub. This means that you can debug your driver using WDF source code. Download it from http://github.com/Microsoft/Windows-Driver-Frameworks.
• The Windows Driver Kit (WDK) 10 samples are also now published to GitHub. Download them from http://github.com/Microsoft/Windows-Driver-Samples.
• Want to benefit from the universal capabilities of UMDF 2? To learn how to port your old UMDF 1 driver, see Porting a Driver from UMDF 1 to UMDF 2.

ref:

Getting started with Windows drivers -

• https://msdn.microsoft.com/en-us/library/windows/hardware/ff554690(v=vs.85).aspx
• https://msdn.microsoft.com/en-us/library/windows/hardware/dn265580(v=vs.85).aspx

Getting started with UMDF - https://msdn.microsoft.com/en-us/library/windows/hardware/dn384105(v=vs.85).aspx

UMDF overview - https://msdn.microsoft.com/en-us/library/windows/hardware/ff560442%28v=vs.85%29.aspx

Choosing driver model - https://msdn.microsoft.com/en-us/library/windows/hardware/ff554652%28v=vs.85%29.aspx

Comparing UMDF 2.0 Functionality to KMDF - https://msdn.microsoft.com/en-us/library/windows/hardware/dn376882(v=vs.85).aspx

How to convert a KMDF driver to a UMDF 2.0 driver (and vice-versa) - https://msdn.microsoft.com/en-us/library/windows/hardware/dn265585(v=vs.85).aspx

Windows Driver Framework(WDF) development guide - https://msdn.microsoft.com/en-us/library/windows/hardware/ff557565(v=vs.85).aspx

What's New for WDF Drivers in Windows 10 Insider Preview - https://msdn.microsoft.com/en-us/library/windows/hardware/ff544296(v=vs.85).aspx