LibCat » Книги » Справочная литература » Руководства » Nicolas Besson - Microsoft Windows Embedded CE 6.0 Exam Preparation Kit

Nicolas Besson - Microsoft Windows Embedded CE 6.0 Exam Preparation Kit

Здесь есть возможность читать онлайн «Nicolas Besson - Microsoft Windows Embedded CE 6.0 Exam Preparation Kit» весь текст электронной книги совершенно бесплатно (целиком полную версию без сокращений). В некоторых случаях можно слушать аудио, скачать через торрент в формате fb2 и присутствует краткое содержание. Город: Redmond, Год выпуска: 2008, Издательство: Microsoft, Жанр: Руководства, ОС и Сети, Программы, на английском языке. Описание произведения, (предисловие) а так же отзывы посетителей доступны на портале библиотеки ЛибКат.

Читать книгу

Название:
Microsoft Windows Embedded CE 6.0 Exam Preparation Kit
Автор:
Nicolas Besson
Издательство:
Microsoft
Жанр:
Руководства / ОС и Сети / Программы / на английском языке
Год:
2008
Город:
Redmond
ISBN:
нет данных
Рейтинг книги:
5 / 5. Голосов: 1
Избранное:

Добавить в избранное
Отзывы:
Написать комментарий
Ваша оценка:
- 100
- 1
- 2
- 3
- 4
- 5

Microsoft Windows Embedded CE 6.0 Exam Preparation Kit: краткое содержание, описание и аннотация

Предлагаем к чтению аннотацию, описание, краткое содержание или предисловие (зависит от того, что написал сам автор книги «Microsoft Windows Embedded CE 6.0 Exam Preparation Kit»). Если вы не нашли необходимую информацию о книге — напишите в комментариях, мы постараемся отыскать её.

Microsoft Windows Embedded CE 6.0 Exam Preparation Kit — читать онлайн бесплатно полную книгу (весь текст) целиком

Ниже представлен текст книги, разбитый по страницам. Система сохранения места последней прочитанной страницы, позволяет с удобством читать онлайн бесплатно книгу «Microsoft Windows Embedded CE 6.0 Exam Preparation Kit», без необходимости каждый раз заново искать на чём Вы остановились. Поставьте закладку, и сможете в любой момент перейти на страницу, на которой закончили чтение.

Тёмная тема

Шрифт:

↓

↑

Сбросить

Интервал:

↓

↑

Закладка:

Сделать

Memory Mapping and the BSP<\/p> <\/div>

You must customize two elements to include information about static memory mappings in a BSP:<\/p>

■ Config.bib file<\/strong>Provides information about how the system should use the different memory regions on the platform. For example, you can specify how much memory is available for the OS, how much can be used as free RAM and also reserve memory for specific needs.<\/p>

■ OEMAddressTable<\/strong>Provides information about the memory layout of the underlying platform, as discussed in Lesson 1. The memory specified in Config.bib should also be mapped in the OEMAddressTable.<\/p>

Mapping Noncontiguous Physical Memory<\/p> <\/div>

As mentioned in Chapter 2, "Building and Deploying a Run-Time Image," you must define a single contiguous region in the RAMIMAGE memory region for the operating system in the MEMORY section of the Config.bib file. The system uses this definition to load the kernel image and any modules you specified in the MODULES and FILES sections. You cannot define multiple RAMIMAGE regions, yet the OAL can extend the RAMIMAGE region and provide additional noncontiguous memory sections at runtime.<\/p>

Table 5-11 summarizes important variables and functions to extend the RAM region.<\/p>

Table 5-11 Variables and functions to extend the RAM region<\/strong> <\/p>

Variable/Function<\/th>	Description<\/th> <\/tr>
MainMemoryEndAddress<\/td>	This variable indicates the end of the RAM region. The kernel sets this variable initially according to the size reserved for the operating system in the Config.bib file. The OAL OEMInit function can update this variable if additional contiguous memory is available.<\/td> <\/tr>
OEMGetExtensionDRAM<\/td>	The OAL can use this function to report the presence of an additional region of noncontiguous memory to the kernel. OEMGetExtensionDRAM returns the start address and length of the second region of memory.<\/td> <\/tr>
pNKEnumExtensionDRAM<\/td>	The OAL can use this function pointer to report the presence of more than one additional region of memory to the kernel. This mechanism supports up to 15 different noncontiguous memory regions. If you implement the pNKEnumExtensionDRAM function pointer, then OEMGetExtensionDRAM is not called during the startup process<\/td> <\/tr> <\/table> Enabling Resource Sharing between Drivers and the OAL<\/p> <\/div> Device drivers often need access to physical resources, such as memory-mapped registers or DMA buffers, yet drivers cannot directly access physical memory because the system only works with virtual addresses. For device drivers to gain access to physical memory, the physical addresses must be mapped to virtual addresses.<\/p> Dynamically Accessing Physical Memory<\/p> <\/div> If a driver requires physically contiguous memory, as in the case of buffers required for DMA operations, the driver can allocate contiguous physical memory by using the AllocPhysMem function. If the allocation is successful, AllocPhysMem returns a pointer to the virtual address that corresponds to the specified physical address. Because the system allocates memory, it is important to free the memory later on when it is no longer needed by calling FreePhysMem.<\/p> On the other hand, if a driver requires non-paged access to a physical memory region defined in Config.bib, you can use the MmMapIoSpace function. MmMapIoSpace returns a non-paged virtual address that is directly mapped to the specified physical address. This function is typically used to access device registers.<\/p> Statically Reserving Physical Memory<\/p> <\/div> Occasionally, it may be necessary to share a common region of physical memory between drivers or between a driver and the OAL (such as between an IST and an ISR). Similar to sharing a memory region for boot arguments between boot loader and kernel, you can reserve a shared memory region for driver communication purposes in the Config.bib file. A standard practice is to use the DRIVER_GLOBALS structure defined in Drv_glob.h, as mentioned in Lesson 1.<\/p> Communication between Drivers and the OAL<\/p> <\/div> In addition to the standard set of IOCTLs required by the kernel, drivers can communicate with the OAL through custom IOCTLs implemented in OEMIoControl. Kernel-mode drivers call OEMIoControl indirectly through KernelIoControl, passing in the custom IOCTL. The kernel does no processing, other than passing the parameters straight through to OEMIoControl. However, user-mode drivers cannot directly call custom OAL IOCTLs by default. The KernelIOControl calls from user-mode drivers or processes are passed to OEMIoControl through a kernel-mode component (Oalioctl.dll), which maintains a list of user-accessible OAL IOCTL codes. The call is rejected if the requested IOCTL code is not listed in this module, but you can customize this list by modifying the Oalioctl.cpp file that is located in the %_WINCEROOT%\Public\Common\Oak\Oalioctl folder.<\/p> Lesson Summary<\/p> <\/div> A good understanding of the Windows Embedded CE 6.0 memory architecture is a must for every CE developer. Specifically for BSP developers, it is important to know how CE 6.0 maps available physical memory into the virtual memory address space. Accessing memory from OAL, kernel-mode modules, and user-mode drivers and applications requires a detailed understanding of static and dynamic mapping techniques that are available in kernel mode or user mode. For more information about the communication between kernel-mode and user-mode components, refer to Chapter 6, "Developing Device Drivers."<\/p> Lesson 3: Adding Power Management Support to an OAL<\/p> <\/div> As discussed in Chapter 3, "Performing System Programming," Windows Embedded CE 6.0 provides a comprehensive set of power management features based on a Power Manager component that OEM developers can customize to implement system power state definitions as appropriate for their hardware platforms. In relationship to the OAL, implementing power management capabilities is a twofold task. You need to enable the operating system to control the power state of the hardware components and you need to enable the hardware platform to inform the operating system about power state changes. Most embedded devices require at least basic power management support to reduce power consumption and prolong battery life.<\/p> After this lesson, you will be able to:<\/strong> <\/p> ■ Describe how to reduce processor power consumption.<\/p> ■ Identify the transition paths to suspend and resume the system.<\/p> Estimated lesson time: 15 minutes.<\/strong> <\/p> <\/cite> Power State Transitions<\/p> <\/div> Embedded devices that are not constantly in use, such as personal digital assistants (PDAs), operate for extended periods of time in an idle state, thus providing an opportunity to preserve energy by switching from full-power mode to a reduced-power mode or suspend state. Most embedded processors available on the market today support these transitions, as illustrated in Figure 5-9.<\/p>