第二章 Wince体系结构和功能.pptVIP

* * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 看下面应用互斥体的情景。Thread1创建并拥有了一个互斥体g_hMutex[序列12]。互斥体g_hMutex是定义的全局量，thread2可访问到，Thread2用WaitForSingleObject()试图获得该互斥体，因为此时g_hMutex是被Thread1拥有的，所以Thread2被挂起[序列3]。Thread1执行了一些操作之后，又用wait函数试图再次获得了该互斥体，因为此时g_hMutex的拥有者还是Thread1，所以Thread1立即再次获得了该互斥体[序列4-6]。Thread1对互斥体g_hMutex保护的共享资源操作完毕，释放该互斥体[序列7]，但是因为Thread1两次获得了g_hMutex，所以g_hMutex的拥有权并没有交出。等到Thread1再次释放互斥体g_hMutex[序列8]之后，Thread1才失去了g_hMutex的拥有权，Thread2可竞争g_hMutex的拥有权，如能成功拥有，就可从等待状态被唤醒，完成对共享资源的访问操作。 * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * * 在嵌入式系统软件的组成中，就有BSP。BSP是相对于操作系统而言的，不同的操作系统对应于不同定义形式的BSP,例如VxWorks的BSP和Linux的BSP相对于某一CPU来说尽管实现的功能一样，可是写法和接口定义是完全不同的，所以写BSP一定要按照该系统BSP的定义形式来写（BSP的编程过程大多数是在某一个成型的BSP模板上进行修改）。这样才能与上层OS保持正确的接口，良好的支持上层OS。 * * * * * * 作为直接使用统一音频模型 (UAM) 或实现流式接口的替代方法，可以使用 Microsoft 提供的模型设备驱动程序 (MDD) 库。该库通过音频设备驱动程序服务提供程序接口 (DDSI) 函数实现了流式接口函数。 如果您使用 Wavemdd.lib，则必须创建匹配的、实现了这些音频 DDSI 函数的平台相关驱动程序 (PDD) 库。PDD 库通常被称为 Wavepdd.lib（尽管不要求这样）。然后，可以将这两个库链接起来，以构成音频驱动程序（通常称为 Wavedev.dll）。一般情况下，音频硬件支持比通常适用于文件的操作集更大的操作集。例如，文件不具有音量控制和播放速度控制，但音频硬件通常具有这些控制。 流式接口的 DeviceIOControl 部分允许对文件进行任意操作，从而使得可以使用 WAV_IOControl 函数来操纵音频硬件。为了向音频硬件发送命令，OS 向 WAV_IOControl 传递了各种消息。例如，为了让音频硬件做好录制准备，中间件使用 WAV_IOControl 向音频驱动程序发送 WIDM_PREPARE 消息。 发送到音频驱动程序的消息类似于基于 Windows 的桌面 OS 上的用户模式音频驱动程序（如 Mmdrv.dll）所使用的那些消息。因为音频驱动程序完全依赖于 DeviceIOControl 函数消息，所以流式接口的其余部分的实现相对简单。特别地，WAV_Read、WAV_Seek 和 WAV_Write 函数仅仅是返回常数值的存根。 其他流式接口函数应该完全实现，并且遵循在这些函数的 Microsoft Windows CE API Reference 中描述的约定。下图显示了使用 MDD 库的音频驱动程序的交互。如图所示，播放和录制声音的第一步是创建一个从应用程序到 OS 的调用。OS 将此类调用转换为对音频驱动程序的 WAV_IOControl 调用。执行这一转换的 OS 技术为 Wave API Manager。然后，音频驱动程序对硬件执行适当的操作。 设备管理器只加载和注册音频驱动程序；它并不直接参与该驱动程序的操作。像标准流式接口驱动程序一样，音频驱动程序使用注册表项来存储配置信息以及将其本身公布给 OS。 如果该音频驱动程序尚未列在 Platform.reg 中，请创建一个 HKEY_LOCAL_MACHINE\Drivers\Builtin\Audio 注册表项来存储配置信息。 当该音频驱动程序在启动时加载时，设备管理器会为该驱动程序创建一个 HKEY_LOCAL_MACHINE\Driv