Audio Driver Development [WinCE]

Interrupt handling inside Windows CE BSP [Windows]

  Here in this article, I will explain about how to trace your code in InterruptEnable, InterruptHandler, InterruptDone and InterruptDisable.

Lets start from code in xxx_Init, when we generate System IRQ using IRQ (KernelIoControl) and save this information in it's irq-sys irq table. 

Now we create a thread (CreateThread).

After creating event, we bind System IRQ with an event(InterruptInitialize). This is the point when OEMInterruptEnable (to initialize the interrupt) is getting called. Now ABCinterruptEnable(implementer dependent name) get called. As InterruptInitialize called with Syetsm IRQ so OEMInterruptEnable  convert System IRQ to IRQ and with this parameter it call ABCInterruptEnable. So depending on this IRQ it enable the interrupt control registers. 

InterruptDisable and  InterruptDone call OEMInterruptDisable and OEMInterruptDone respectively.  

Now I will  talk about ISR part. As soon as, Interrupt occurs in device, the vector table in vector.inc(private code) called and jump to exception code related to the IRQHandler in armtrap.s. Now before going to perform any action it save register context and change mode to IRQ handling.

  After saving and does nessesacity code execution, it calls OALInterruptHandler in ISR. (I guess we say vector table because it has magnitude like the address of the IRQHandler and it has Direction which say where to go.) In ISR, in OALInterruptHandler,  It will check the interrupt register which will give information about the interrupting device to decide the interrupt device and the do the appropriate task. like masking the lower priority interrupt as well as it self and then clearing the pending register.

After returning the SysIntr, kernel will check for the with which event, this sysIntr is mapped and then signal the event and which will make sure that WaitForSingleObject API or any other API which are waiting for the event to get signalled will be called

WinCE 5 vs WinCE 6 [Windows]

	Windows CE 5	Windows Embedded CE 6.0
Boot Sequence	- kernel was hard-coded to launch filesys.exe as the second process. - starting order of system processes and applications was controlled by registry settings underHKEY_LOCAL_MACHINE\Init.	- most of the system processes have been converted to DLLs that load inside the kernel process, the system uses a mechanism that supports both DLLs and executables. - You cannot specify command-line parameters for executables. This is unchanged from previous versions of Windows Embedded CE. - Application-loading sequences are specified under the HKEY_LOCAL_MACHINE\Init registry key. - You can specify the load order of system DLLs, executables, and applications under theHKEY_LOCAL_MACHINE\Init registry key. - The OS launches executables listed under this key and loads DLLs under this key into the kernel. You can specify which DLL entry point to call when the application starts. - The startup sequence is similar to the service startup sequence in Services.exe and the registry enumerator.
Virtual Memory Layout	1. there was a limit of 32 processes, and a 32 MB limit on virtual memory (VM) for each process. 2. all of the processes shared the same 4 GB address space. 3. the current application executed in slot zero	1. the kernel process resides in the upper 2 GB of the 4-GB (32-bit) virtual memory space, and the bottom 2 GB is unique for each process. 2. limit of about 32,000 processes, due to the number of handles that can be created. The practical limit on the number of processes is bounded by the amount of physical memory. 3. slot zero, and all other process slots, are effectively 2 GB each. 4. Because virtual memory access is translated into hardware access through the memory management unit (MMU), virtual memory code is CPU-dependent. ARM and x86 CPUs use hardware page tables, so the content of virtual memory is accessed directly by the hardware.
Handle Tables	1. a handle to an event, a thread, a process, a mutex, and so on, could be passed to a different process and be usable by that process. -  If two handles were opened to the same object, the handle value, which is the 32-bit identifier that an application holds onto, was the same for both handles. In Windows CE 5.0, generated handle values could elevate user privileges. - There was one global list of handles that was shared by all processes. Handle objects are locked before they are used, and unlocked after they are used. The locking mechanism is a reference counter, which is incremented before the handle is used and decremented after the handle is used. -  Handle objects are destroyed only when their reference counter equals zero, so handle objects in use are never destroyed. - a handle object could be destroyed while it was still in use, for example, in the middle of a call to an API. 8.the reuse count was only 3 bits, so a handle could easily be reused. Therefore, stale handles could be a problem. -returned the same handle value for duplicated handles, or a named handle of the same name.	1. each process has its own individual handle table. - If two handles to the same object are opened, they have different values, even within the same process. - A handle value in one process cannot be used to access that object in another process. This includes the kernel. - The kernel process, including the kernel-mode servers running under it, has its own handle table, and cannot use a handle that was opened by a different process. -  If you try to pass a handle from one process to another, that handle value may already be used by the other process to refer to a different object. If that other process tried to use the handle value, it would access a different object. This improves security because handle guessing is eliminated. - Handles are looked up in the handle table, which the user cannot access. This prevents users from generating handle values. - Similar to Windows desktop-based operating systems, every newly created handle, including newly duplicated handles, has a unique value. 8. Handles cannot easily be reused because there is a 16-bit reuse count. Therefore, about 64,000 operations to create and close handles would be required to exhaust the reuse count. Tradeoffs of the Handle Tables Handles are only valid within the process that created them. Handles cannot be passed between processes. Existing code that passes handles from process to process must be changed to useDuplicateHandle to create a new handle that the other process can use. If necessary, use OpenProcessto access the other process.
Mapping Pointers and Sharing Memory between Processes	- When a function gets called, the kernel performed a 1-byte access check on pointer parameters and marshaled the pointer by mapping it. - The OS address space was arranged so that the 32-MB virtual-memory address space for every process was accessible at all times. -  Therefore, mapping required only modifying the pointer to point to the right memory space of the target process. - The server process was responsible for calling a function such as MapCallerPtr to verify that the caller process had sufficient privileges to access the entire buffer, and the server process was responsible for access-checking and marshaling any embedded pointers. - both the access check and marshaling were covered by calling MapCallerPtr. - The server was also responsible for performing a secure copy, if necessary.	- when an application calls a function, the kernel performs the full access check on buffer parameters, taking responsibility for that protection away from the server processes. - This is made possible by giving the kernel more information about parameter sizes. The kernel still marshals pointer parameters, and servers must still marshal embedded pointers. Servers must still perform a secure copy, if necessary. The following list shows what has changed: - The kernel has taken over full access checking of pointer parameters. - The function servers must call to marshal parameters. - Options available for servers to perform a secure copy. - marshaling must be handled if the server needs to access a buffer asynchronously.
Loading DLLs in Kernel Mode or User Mode	- One DLL cannot simultaneously load into both kernel mode and user mode. - When you run an executable file or a DLL, the code must be able to run at its specified address. For example, jumps within the code or references to global variables must be modified to refer to the hard-coded addresses. Because kernel DLLs load above 0x80000000 and user DLLs load below 0x80000000, it is impossible for a single copy of the DLL to be able to run in both locations at once.	- In Windows Embedded CE 6.0, the OS bypasses this limitation by having two versions of some DLLs; one version to load in kernel mode and one version to load in user mode. - The kernel has a new naming standard for DLLs that load in both kernel mode and user mode. The kernel-mode DLL has a k. at the beginning of the name. user-mode version of coredll is coredll.dll whereas the kernel-mode version is k.coredll.dll. - The kernel automatically translates kernel-mode accesses to user-mode DLLs into the proper kernel-mode version for this version. For example, if a DLL is linked to the user-mode coredll.dll, as almost all DLLs in the build system are, when that DLL is loaded into the kernel process, the DLL is importing from the kernel-mode k.coredll.dll, instead. There is no load error in this case because the imports are seamlessly redirected to the kernel DLL. Similarly, if code in the kernel process calls LoadLibrary on coredll.dll, it actually loads a reference to k.coredll.dll. Therefore, if it calls GetProcAddress and calls a function, it calls the proper kernel-mode function. - if you implement DLLs, you do not need to change all coredll.dll references to k.coredll.dll references. - In fact, that would destroy portability of your code to user mode. In the future, you may want to run your code in user mode, instead of inside the kernel. OEMs may need to specify where their DLLs load with .bib file flags. The Z flag specifies Windows CE 5.0 and prior versions. Z cannot be combined with the compression flag C, whereas there are no such
Process Switching	File system.exe, GWES.exe, and Device.exe are process hence process switch required.	File system.exe, GWES.exe, and Device.exe have become libraries which are loaded into the kernel. Now that they are libraries, there is no process switch between them. - Services.exe is still a user-mode process.
Paging Pool	- the paging pool was a fixed-size portion of memory reserved for executable code and read-only, memory-mapped files. - If the amount of code loaded into memory at any time was smaller than the pool, the pool did not shrink to match. - if the amount of coded loaded at any time was larger than the pool, only the most recently used pages were held in memory, up to the size of the pool. - The pool did not grow to hold more code, so executable code discarded. - OEMs controlled the size of the paging pool with an OEM adaptation layer (OAL) variable, cbNKPagingPoolSize. - the page pool maintained a physically contiguous range of pages and kept an array of information to track each page in the pool. - Pages were kept in a global first-in, first-out (FIFO) list, and in a list per module for quick discarding of a module on unload.	- The pool can temporarily exceed its reserved size. - Rather than setting a single size for the pool, an OEM can now choose a target size for the pool, plus a maximum size. - There is always enough memory reserved for the pool to grow to reach its target. - Above that, if memory is available the pool continues to grow, up to the maximum limit. - The pool never exceeds the maximum. - As soon as the pool exceeds the target, the kernel wakes up a trimming thread that walks through modules and discards pages. - The trimming thread runs at low priority normally, so that paging operations do not disturb other system activity. - If the pool approaches its maximum limit, the trimming thread runs at higher priority temporarily to ensure that pool memory is released. - There are now two pools. - One pool, the loader pool, holds executable code and read-only, memory-mapped files as did the Windows CE 5.0 paging pool. - A second pool, the file pool, holds data pages from memory-mapped files and from the new CE 6.0 file system cache manager. - The file pool is different from the loader pool in that its pages may also be read/write, so they may need to be written back to disk before being discarded. - Therefore, the file pool can be configured separately from the loader pool to maximize system performance. - Because file writes are relatively slow operations, the file pool trimming thread runs at lower priority than the loader pool trimming thread. - the OAL variable cbNKPagingPoolSize is deprecated. - Instead, to configure paging pool parameters, OEMs can implement a new IOCTL in their OAL: IOCTL_HAL_GET_POOL_PARAMETERS. - If the OAL does not implement this IOCTL, the kernel chooses suitable default settings. - The kernel also exposes information about the current state of the paging pool to applications through the new kernel IOCTL IOCTL_KLIB_GET_POOL_STATE. - Applications can call this IOCTL to query current memory usage and other state information about the paging pools.
Kernel Mode	1. SetKMode and ALLKMODE exist.	1. modules (DLLs) are loaded in the kernel process, a user process, or both. 2.  any thread owned by a module loaded in the kernel process is said to run in kernel mode. 3. any thread owned by a module loaded in a user process is said to run in user mode. 4. For threads to migrate to different processes, but in general, this happens only for a short duration when the threads are in process server library (PSL) servers.
Kernel Servers	- a process server library (PSL) is a process that implements a set of APIs for applications to call. - a kernel-mode server is a DLL that loads into the kernel process and implements a set of APIs for applications to call. Kernel.dll, filesys.dll, device.dll, gwes.dll, and most of device drivers are kernel-mode servers. - The kernel-mode servers are supported by a kernel-only version of coredll named kcoredll.dll. Any code that loads into the kernel, but was linked to coredll.dll, is automatically redirected to use k.coredll.dll, instead. Simplified and improved security for API calls.	- a user-mode server is a process that registers an API set. - Services.exe is a user-mode server that loads some drivers that in previous version of Windows Embedded CE were loaded by filesys, device, and gwes. - Improved performance for most API calls.

Marshalling in WinCE [Windows]

Marshaling Mechanics

- two possible ways that a buffer can be marshaled so that the server can use it:

-- Duplication - Allocate a new buffer for the server to use, and copy data into and out of the buffer as necessary.

- The server owns the buffer for the duration of the call.

- gives the server access to the buffer,

- prevents the caller from asynchronously modifying the buffer after it has been validated by the server.

-- Aliasing:

- Map part of the memory of the caller process into the memory space of the server process.

- Because every process has a separate address space, it is not possible to access another process's memory by using a pointer.

-  Instead, the kernel aliases part of the memory of the caller into the address space of the server, using the VirtualCopyEx function.

- The same piece of physical memory is temporarily shared between the two processes by mapping it to two different virtual address ranges inside the two processes.

- This form of mapping involves allocating a new virtual address range, instead of just re-basing a pointer

Access checking: Verifying that the caller process has sufficient privileges to access a buffer.

Marshaling: Preparing a pointer that a server can use to access a caller’s buffer.

Secure-copy: Making a copy of a buffer to prevent asynchronous modification by the caller.

Pointer parameter: Pointer that is passed as a parameter to an API.

Embedded pointer: Pointer that is passed to an API by storing it inside a buffer or inside of another embedded pointer.

Virtual memory layout - WinCE6 [Windows]

Benefits of the Virtual Memory Layout

1. Switching processes on ARM and x86 is faster because it is simpler to make use of the hardware page tables.
2. The time to handle TLB misses on ARM and x86 remains about the same.

Tradeoffs of the Virtual Memory Layout

1. The virtual memory for every process is no longer accessible at all times
2. -,the virtual memory for the kernel process and the current process are accessible at all times.
3. - Therefore, accessing the memory of another process, particularly buffer parameters that are passed to a server, is no longer as simple as mapping a pointer.
4. More complicated reference counting.
5. More complicated interprocess communication (IPC) and buffer passing.

WEC7 vs WinCE6 [Windows]

Catagory	CE7	CE6
User Interface options Silverlight and the Windows Embedded Silverlight Tools (WEST	- an extensible UI framework and the advanced Interaction options along with richer graphics with Silverlight 3.0 for evolving customer expectations. - support Silverlight 3 constructs and is accompanied by a powerful development tools that eases the integration work to hang in the C++ code behind. - gives consumers the ability to share and manage content across networked devices with Digital Living Network Alliance, such as new HDTVs, and a new media librarY	- limitation while using Silverlight for Embedded, first released in WinCE 6.0 R3 - silverlight 2.0
Multi-Touch and Custom gesture support	-  rich user experience with Multi-touch and custom gestures integrated into the browser.	- single touch only
Internet Explorer 7	- Internet Explorer 7 including support for Adobe Flash 10.1 - support for tabs, panning and zooming giving rich desktop browsing experience and natural touch input - browsing rich Web 2.0 content with streaming video on websites making the interface more interactive, -  browser control with IE7 rendering control surrounded with Silverlight Windows embedded application that allows developers to build highly interactive devices.	- IE6
hardware manufacturers and developers	- kernel support for 3GB physical RAM and also supports ARMv7 assembly. - market quicker with support for multi-core and
OS support for multi-core processors	- multiple CPU architectures and supports x86, SH (automotive only) and ARM. - supports multi-core processors, ARM VFPU and NEON instructions and provides support and commitment from ARM to Microsoft's Windows CE - supports ARMv7 - NO ARMv4 support	- Single CPU support - ARMv4 support
Media player	- Improved compression formats like mp4 and 3gp - improved video playback, video conferencing, video telephony, and digital TV
Exchange 2010 AirSync	- Improved Microsoft AirSync and Microsoft Exchange, as well as to Microsoft Office and Adobe PDF viewers to access important documents, and to Windows 7 Device Stage to transfer data and media between PCs and devices. - Synchronizes data using a direct connection with an Exchange Server that uses an Ethernet connection, this includes wireless and Ethernet cable connections.
Advanced Networking Stack	- advanced networking stack inspired from Windows 7 along with seamless connectivity options to PC and the Internet improved sync up with office products is an USP of the latest offering.

process vs thread [OS]

Process vs Thread

A problem with processes 1. expensive to create a new process. construct new data structure in the kernel copy memory 2. expensive to switch between processes (context switch)   3. cache must be flushed 4. registers reloaded 5. kernel scheduler and dispatcher is always involved

Threads in the same process share 1. process instructions most data 2. open files (descriptors) 3. signals and signal handlers Each thread has a unique 1. Thread ID 2. set of registers, stack pointer 3. stack for local variables, return addresses

Designated initializers [Embedded]

Initialize a structure (Designated Initializers)

int aa[4] = { [2] = 3, [1] = 6 };

In a structure initializer, specify the name of a field to initialize with ‘.fieldname =’ before the element value. For example, given the following structure,

   struct point { int x, y; };

the following initialization

   struct point p = { .y = yvalue, .x = xvalue };

is equivalent to

   struct point p = { xvalue, yvalue };

WEC2013 vs WEC7 [WinCE]

WEC2013	WEC7
Environment	Support for VS 2013 and VS 2012 - no WEC7 specific tool chain or compiler - fewer catalog items - Latest C runtime library	- vs2008 - separate pb for wec7
BSP or driver	- WLAN driver for TI WiLink 7.0 available - two new BSPs: the x86 based AMD G-Series and the ARM v7T2 based Texas Instruments OMAP 4470
Networking stack	- Enhanced network performance. - Dynamic Host Configuration Protocol version 6 (DHCPv6) client with stateful and stateless address configuration. - (L2TP/IPsec) over IPv6 for VPN - Utilities for configuration and display of IPv6
Snapboot	- snapshot boot significantly reduces the time that is required for device to boot by saving the state of device to persistent storage and then restoring that state when the device reboots. - restores the system by using a previously saved memory image that contains the state of the system, including the program and driver states, that you want restored on boot. - supports large snapshots up to 500 MB, and also supports paging on demand from the snapshot image to further reduce boot time.
ARMv7T2	- improved support for the latest ISO C++11 specification - Visual Studio 2013 compiler targets a newer version of the ARM Embedded-Application Binary Interface (EABI)
Expression Blend	- incorporated Expression Blend to design applications for compact devices, removing the need to download a separate tool
OOM Model	-OOM model uses several thresholds, adjustable by registry, to provide different levels of available memory for different types of components. - Fails memory allocation if there is no memory available. - Provides notifications of low-memory or critical-memory issues, before memory allocation starts failing. - Provides a notification for a healthy memory status. - When applicable, enables any application or shell to monitor and take the correct action on an OOM event. For example, a device could reboot on an OOM event, use a shell that handles an OOM event, or not take any action so that the application handles the OOM event.	out-of-memory (OOM) model was designed specifically for devices that have limited RAM. - This design required users to close applications to avoid memory allocation failures.
Native application and managed application	- newest Microsoft C++ compiler and supports the latest versions of the C++ runtime, the Active Template Library (ATL), the Standard Template Library (STL), and the Microsoft Foundation Classes (MFC). -  uses .NET Compact Framework 3.9 -  include a smaller memory footprint and faster startup time - backward compatibility with .NET Compact Framework 3.5.	.NET Compact Framework 3.5
Streamlined Catalog	removed from the product, including: Internet Explorer 7. Remote Desktop Protocol (RDP). Some consumer supported features, such as Digital Living Network Alliance (DLNA) and device sync. The Windows 95 shell.
Others	-  five new OS design templates to make creating OS designs simpler. - Improved support for data binding and new triggers -  use of a generic error handler plug-in at the FSDMGR level that can catch the failed disk I/O related operation and return an error value that can be acted upon -  HTML to display simple help files on a device - embedded offering which includes the iType® font engine and Monotype’s YingHei font