hexiaolong2009的专栏

紧接上篇文章，本篇翻译起来有难度，同时对读者的技术背景有一定要求，适合深入研究 DRM 驱动的开发人员阅读。通过阅读本文，你将了解如下内容：1. DRM_MODE_ATOMIC_ALLOW_MODESET 标志位的由来及其作用2. 驱动中随处可见的 ww_lock 到底是什么鬼？有什么作用？3. atomic helper 与 legacy helper 相比，都做了哪些优化？4. Atomic 框架中的 DPMS 为什么只有“ON”和“OFF”这两种状态？

Mesa 21.0 即将发布

通过阅读本文，你将了解以下内容：1. Atomic mode setting 产生的背景2. Atomic KMS 与谷歌 ADF 相比有哪些优势3. TEST_ONLY 模式的正确打开方式4. KMS state 的使用方法5. Atomic check 和 commit 的功能

Khronos 发布 Vulkan 光线追踪（Ray Tracing）最终版

* drm/crtc: 关于使用 kthread worker 来实现 non-blocking commit 的讨论* drm/cma-helper: 默认使用 drm_gem_cma_default_funcs callbacks* drm/atomic: 让 CRTC & Connector atomic 函数统一使用 drm_atomic_state 参数* Vulkan 1.2.158 新增 VK_KHR_fragment_shading_rate 扩展

drm-next for linux-5.11

CMA 是 Contiguous Memory Allocator 的缩写，它本身指代的是一种内存分配器（或内存分配策略），专用于分配物理连续的大块内存，以满足大内存需求的设备（如 Display、Camera）。CMA 除了具有内存分配的功能外，还具有内存迁移的功能，使得同一块 CMA 区域既可以被系统使用也可以被专用的 DMA 设备占用，从而大大提高了内存的使用率。要想使用 CMA 内存，需要在内核配置中开启 CONFIG_CMA 配置宏。

Android11 正式发布

* ARM 拥抱 Panfrost 开源社区；* gfx-pps 介绍：使用 Perfetto 工具跟踪 GPU 性能问题；* V3DV 完成 Vulkan 1.0 符合性测试，准备 Upstream 到 Mesa 主线；* VK_EXT_extended_dynamic_state 扩展是如何诞生的；* 关于 OpenGL 与 Vulkan 之间的互操作性；* VK_EXT_present_timing 简介；* AMD Trusted Memory Zone (TMZ) 简介；

* LPC2020: Linux kernel 添加 Rust 支持 * LPC2020: 只需要一笔 Patch，Android AOSP 就可以在 kernel-5.9 主线上运行

ION 将从 kernel 主线中彻底移除

DRM:1. 修复 dma-heap 导出 name 不准确的问题2. 为 dma-heap 添加 Device Heap3. 为 dma-heap 引入自定义 CMA Heap4. 为 dma-heap 添加 Chunk HeapAOSP:1. 新增 AidlMessageQueue 结构体2. systrace 新增 system property 跟踪信息Vulkan:1. Vulkan-Docs 仓库或将 master 分支更名为 main 分支

1. 彻底废弃 drm_driver 中的 prime callbacks，全面启用 GEM Object functions2. 为 GEM vmap 添加 I/O memory 的支持3. dma-heap：添加 system-uncached HEAP4. DMA Heap vs GEM5. dma-buf: 为每个进程添加 buffer 使用状态的 ftrace 信息6. backlight: 代码优化，新增宏定义及操作接口7. Huawei Hikey970 DRM/KMS 驱动

本文并不打算讲解 mmap 系统调用的原理及其相关细节，因为这涉及到 linux 内存管理的诸多概念，大家只需要了解如何去写一个简单的 mmap 驱动程序就可以了，为后续 drm mmap 驱动的编写做准备。

原文作者并不是一上来就讲解该 extension 是什么、怎么用，而是先介绍 vulkan pipeline 、shader、dynamic state 这些基本概念，然后通过问题来引出 VK_EXT_extended_dynamic_state 以及它的用法，最后还介绍了该 extension 产生的故事背景，整篇阅读起来十分顺畅。因此本人决定将其翻译成中文，分享给大家，方便大家阅读。

本文翻译自 Gustavo Padovan 于 2016 年 9 月发表在 Collabora 官网的三篇文章，Gustavo 本人也是内核中 dma-fence 的提交作者。通过本文，我们可以了解到 dma-fence 最初是如何演变而来的，以及它是如何在 graphics pipeline 中起作用的。

译者注以下为正文。介绍多年来，显示行业一直普遍认为显示器是以固定的刷新率（refresh rate）运行的，如 60Hz。这与以下事实形成鲜明对比：送给显示器的图像内容多种多样，每种图像都有自己独特的、变化的帧率（frame rate）。当显示的刷新率与图像内容自身的帧率不同步时，用户可能会察觉到撕裂（tearing）和卡顿（stutter）之类的异常效果。在移动应用程序中（如平板、笔记本电脑），对于静态图像和视频播放来说，较高的显示刷新率不仅显得多余，还增加了系统功耗，降低了续航能力。这些因素使得我

在上一篇文章中，我绍了一些关于 ION、DMA-BUF Heap、DMA API 的背景知识，以及 CPU Cache “所有权”的基本概念，最后站在传统 DMA API 的角度来描述 DMA-BUF 是如何处理 cache 同步问题的。文章最后还讨论了为什么传统的 DMA API 在现代移动平台上性能会这么差。本文将和大家一起探讨如何让 DMA-BUF exporter 避免不必要的 cache 操作的方法，并就如何改进这些方法提出了一些大致的建议。

在上一篇《关于 DRM 中 DUMB 和 PRIME 名字的由来》 文章中，我们知道了 dumb buffer 名字的由来。本篇，我们将一起来写一个最简单的 GEM 驱动程序。

kernel 中的 DMA API 都是用来在 CPU 和 device 之间共享 memory 的。近年来，传统的 DMA API 已经被运用到 ION、DMA-BUF 和 DMA-BUF Heap 这些接口中，但是在接下来的讲解中我们会看到，关于内存共享的效率问题，到现在都还没能被彻底解决掉。

在上一篇《DRM驱动程序开发（VKMS）》文章里，我们学习了如何编写一个最简单的 KMS 驱动。而本篇，我将以叙述的形式为大家讲解 DRM GEM 的相关概念，代码留到下一篇进行讲解。我知道，大多数的 DRM 初学人员，在刚接触到 GEM 相关概念时，首先困惑的不是 GEM 架构有多难，而是 GEM 里面的那些专业术语到底是怎么来的？为什么要这样命名？比如本篇要讲的“DUMB”和“PRIME”，当你得知它们的作用时，你甚至会有些愤慨：它们的名字和它们的功能简直毫无逻辑关系！是 DRM 社区的大佬们都喜欢

VKMS 是 “Virtual Kernel Mode Setting” 的缩写，它于2018年7月5日被合入到 linux-4.19 主线版本中，并存放在 drivers/gpu/drm/vkms 目录下。之所以称它为 Virtual KMS，是因为该驱动不需要真实的硬件，它完全是一个软件虚拟的“显示”设备，甚至连显示都算不上，因为当它运行时，你看不到任何显示内容。

本文简单介绍 Weston 常用的几种 backend 启动方式。目前最新的 Weston 8.0.0 支持如下几种 backend：drm-backendfbdev-backendheadless-backendrdp-backendwayland-backendx11-backend其中 headless-backend 不带任何 UI 界面，主要用于 weston 自测试，rdp-backend 则用于远程桌面。这两个 backend 本文不做介绍。

Render Hell – Book V避免使用小网格检查是否真的有必要使用小网格，或者是否可以将多个小网格组合成一个大网格。如果你有小网格，可以和 Graphic 工程师聊一聊，获取关于多边形个数“最佳点”（sweet spot，即低于该三角形个数的网格将无法得到更快的渲染速度）的信息。所以，如果你确实需要保留某个小网格，你可能需要采取一些措施来让事情顺利进行。你也需要注意多材质的问题。如果有一个大网格，却使用了5种材质，则在渲染过程中该大网格会被拆开，这意味着你现在又有了5个小网格。也许 Altl

Render Hell – Book IV首先，在填充命令缓冲区之前，你可以对所有的命令进行排序（例如按 Render State 进行排序），这样就可以大大减少那些不必要的 Change State 命令，因为在切换状态之前，你已经遍历了所有使用相同 Render State 的网格。

Render Hell – Book III欢迎来到第三篇！这里我们将检查一些在渲染过程中可能出现的问题。但首先，我们来点小练习：知道一个问题是有好处的，而真正去感受一个问题则更有助于理解。所以让我们试着感觉自己像个 CPU / GPU 吧。

Render Hell – Book IIPipeline 详解关于本篇文章，我收到的大多数积极反馈是：非常漂亮的演示说明，但是你的 Pipeline 已经是6年前的了！最初我一直不明白这句话是什么意思，直到 Christoph Kubisch 加入到我的 Render Hell 创作中来，我才明白这句话的含义。他是一名就职于 NVIDIA 的技术开发工程师，无论我有什么样的问题，他都会为我一一解答。请相信我，我的问题实在是太多了！????

Render Hell – Book I如今对美术师的要求越来越高，因为在计算机眼里，他们提供的资源（asset）不过是一堆 **顶点** 和 **纹理** 数据的集合而已。而将这些数据转换为最终的图像，则主要是通过计算机中的 CPU 和 GPU 来完成的。

本篇我们将在上一篇的基础上，实现一个简化版的ION驱动，以此来实现任意 size 大小的内存分配。如果你对 dma-buf 还不熟悉，强烈建议先阅读本系列教程的 1~6 篇，对 dma-buf 有一定理解后再回过头来阅读本文。

在前面的 dma-buf 系列文章中，exporter 所分配的内存都是通过 kzalloc() 来分配的。本篇我们换个方式，使用 alloc_page() 来分配内存。

本篇我们将一起来学习 dma-buf 用于 Cache 同步操作的 begin_cpu_access 和 end_cpu_access 这两个接口。之所以将这两个接口放在第六篇讲解，是因为它们在内核中的使用频率并不高，只有在特殊场景下才派的上用场。

在上一篇《dma-buf 由浅入深（四）—— mmap》中，曾提到过 dma_buf_fd() 这个函数，该函数用于创建一个新的 fd，并与 dma-buf 的文件关联起来。本篇我们一起来重点学习 dma-buf 与 file 相关的操作接口，以及它们的注意事项。

前面的两篇文章《dma-buf 由浅入深（二） —— kmap/vmap》和《dma-buf 由浅入深（三） —— map attachment》都是在 kernel space 对 dma-buf 进行访问的，本篇我们将一起来学习，如何在 user space 访问 dma-buf。当然，user space 访问 dma-buf 也属于 CPU Access 的一种。

在上一篇《kmap/vmap》中，我们学习了如何使用 CPU 在 kernel 空间访问 dma-buf 物理内存，但如果使用CPU直接去访问 memory，那么性能会大大降低。因此，dma-buf 在内核中出现频率最高的还是它的 dma_buf_attach() 和 dma_buf_map_attachment() 接口。本篇我们就一起来学习如何通过这两个 API 来实现 DMA 硬件对 dma-buf 物理内存的访问。

在上一篇《最简单的 dma-buf 驱动程序》中，我们学习了编写 dma-buf 驱动程序的三个基本步骤，即 dma_buf_ops 、 dma_buf_export_info、 dma_buf_export()。在本篇中，我们将在 exporter-dummy 驱动的基础上，对其 dma_buf_ops 的 kmap / vmap 接口进行扩展，以此来演示这两个接口的使用方法。

如果你和我一样，是一位从事Android多媒体底层开发的工程师，那么你对 dma-buf 这个词语一定不会陌生，因为不管是 Video、Camera 还是 Display、GPU，它们的buffer都来自于ION，而 ION 正是基于 dma-buf 实现的。假如你对 dma-buf 的理解并不深刻，又期望找个时间来彻底公关一下，那么很高兴，这几篇文章一定能让你对 dma-buf 有个更深入、更透彻的理解。

本文仅对BufferQueue最基本的操作接口进行讲解，不包含 SurfaceFlinger、Surface 等上层封装的概念介绍。阅读完本文后，你将了解如下内容：* 什么是BufferQueue* BufferQueue内部操作的原理是什么* BufferQueue跨进程操作是怎么实现的* 如何写一个最简单的BufferQueue测试程序

本篇将以最简单的代码形式，演示如何在远程操作BufferQueue。前面两篇文章《最简单的BufferQueue测试程序（一）》和《最简单的BufferQueue测试程序（二）》演示的都是在本地同一进程中操作BufferQueue，而实际使用过程中往往会出现Producer和Consumer位于不同的进程，这时候就需要通过binder调用来实现跨进程操作BufferQueue了。

在上一篇《最简单的BufferQueue测试程序（一）》中，我们了解了BufferQueue最基本的操作方法。除了dequeue/queue/acquire/release这些基本操作接口外，BufferQueue还为我们提供了一些特殊函数，如attach/detach/cancel等。本篇我们将一起来学习这些特殊函数的基本用法。Andriod版本：8.1伪代码void main(vo...

本示例代码使用BufferQueue最基本的操作接口，演示了BufferQueue操作的基本流程。Android版本：8.1伪代码void main(void){ createBufferQueue(); consumerConnect() connect(); dequeueBuffer(); requestBuffer(); queueBuffer(); a...

前言在前面的《最简单的DRM应用程序》系列文章中，我们学习了如何使用 libdrm 接口编写 DRM 应用程序。从本篇开始，我们将进入一个全新的世界，一起来学习如何在 kernel 空间编写 DRM 驱动程序。Objects在开始编写 DRM 驱动程序之前，我有必要对 DRM 内部的 Objects 进行一番介绍。因为这些 Objects 是 DRM 框架的核心，它们缺一不可。上图蓝色部...

https://en.wikipedia.org/wiki/Direct_Rendering_Manager#History

前言在上一篇《DRM应用程序进阶（atomic-crtc）》文章中，我们学习了如何通过libdrm的atomic接口实现modeseting的操作。本篇，我们将一起来学习如何通过atomic接口，来实现 drmModeSetPlane() 相同的操作。Atomic Commitplane update的atomic操作如下：drmModeAtomicAddProperty(req, pla...

前言在上一篇《DRM应用程序进阶（Property）》中，我们学习了Property的基本概念及作用。在本篇中，我们将一起来学习如何操作这些Property，即libdrm Atomic接口的用法。Atomic为什么叫“Atomic Commit”？初学者第一次接触到DRM时，总会好奇当初开发者为什么要起 Atomic 这个名字。Wiki上关于该名词有较详细的解释，如果大家感兴趣可以通过本...

前言通过前面几篇《最简单的DRM应用程序》系列文章，我们学习了如何编写一个最基本的DRM应用程序。但是，这些程序所使用的接口，在如今的DRM架构中其实早已经被标记为 Legacy（过时的） 接口了，而目前DRM主要推荐使用的是 Atomic（原子的） 接口。Atomic接口我会在下篇文章中重点介绍，本篇主要介绍Atomic操作必须依赖的基本元素，Property（属性）。Property所谓...

在上一篇 最简单的DRM应用程序 （page-flip）中，我们学习了drmModePageFlip()的用法。而在更早的两篇文章中，我们还学习了drmModeSetCrtc()的使用方法。但是这两个接口都只能全屏显示framebuffer的内容，如何才能在屏幕上只显示framebuffer的一部分内容呢？本篇我们将一起来学习DRM另一个重要的刷图接口：drmModeSetPlane()。在学习...

在上一篇 最简单的DRM应用程序 （double-buffer）中，我们了解了DRM更新图像的一个重要接口drmModeSetCrtc()。在本篇文章中，我们将一起来学习DRM另一个重要的刷图接口：drmModePageFlip()。drmModePageFlip()的功能也是用于更新显示内容的，但是它和drmModeSetCrtc()最大的区别在于，drmModePageFlip()只会等到V...

在上一篇 最简单的DRM应用程序 （single-buffer）中，我们学习了如何去编写一个最基本的DRM应用程序。而本篇文章，将在 modeset-single-buffer 的基础上，对其进行扩展，使用双buffer机制的案例，来加深大家对drmModeSetCrtc()函数的印象。使用上一节中的modeset-single-buffer程序，如果用户想要修改画面内容，就只能对mmap()后...

在学习DRM驱动之前，应该首先了解如何使用DRM驱动。以下使用伪代码的方式，简单介绍如何编写一个最简单的DRM应用程序。伪代码：int main(int argc, char **argv){ /* open the drm device */ open("/dev/dri/card0"); /* get crtc/encoder/connector id */ drmModeGe...

DRM（Direct Rendering Manager）学习简介学习DRM一年多了，由于该架构较为复杂，代码量较多，且国内参考文献较少，初学者学习起来较为困难。因此决定将自己学习的经验总结分享给大家，希望对正在学习DRM的同学有所帮助，同时交流经验。由于本人工作中只负责Display驱动，因此分享的DRM学习经验都只局限于Display这一块，对于GPU这一块本人无能为力，如果大家有相关经验...

概述在上一篇《LCD显示异常分析——开机闪现花屏》中，我们一起分析了开机花屏的问题，在这一篇中，我将对LCD撕裂(tear effect)问题进行详细分析，以及给出这类问题的常用解决方法。本文适用范围： 对象：LCD驱动调试人员 硬件：带GRAM的LCD （如SPI/MCU/DSI CMD屏） 软件：所有嵌入式操作系统 现象首先贴一张动态图，让大家能直观...

概述最近在工作中，有同事遇到LCD开机瞬间会闪现雪花屏的问题，而这类问题都有个共同点，那就是都发生在带GRAM的屏上，同样的问题，在休眠唤醒时也会出现。其实这类问题的原理分析并不难，只是在给别人解释的时候不太好描述，因此，我特地写了这篇文章，好让大家能够更容易、更直观的理解这类花屏问题的原因，也希望能够帮助那些遇到同样问题的朋友。环境 软件：Android 硬件：带GRAM的LCD（如

本人手里有块STM32F429 Discovery板子，因为某种原因需要使用8080接口的LCD，而该块开发板自带的LCD接口采用LTDC驱动，所以就在正点原子这里买了一块4.3寸电容触摸屏，驱动IC为NT35510。 为了快速搭建软件工程，本人使用STM32CubeMX工具生成代码模板，并编写了lcd.c和nt35510.c两个文件，代码如下：

好记心不如烂笔头，为方便以后查看代码及代码重复利用，这里贴出S3C2440 Camera驱动代码。使用友善MINI2440开发板，开发环境为RealView MDK 4.22。最初，本人在网上下载了许多mini2440 camera驱动的代码，但结果都不尽人意，因为这些代码看起来都比较晦涩难懂，都是直接对寄存器进行位与位或操作，且有的代码排版布局很乱，对初学者来说难度较大。由于本人接触了STM32开发后，觉得STM32的库函数给初学者提供了很大帮助，仅仅通过函数名及变量名就能知道当前操作的是哪个寄存器，

好记心不如烂笔头，为方便以后查看代码及代码重复利用，这里贴出S3C2440 UART驱动代码。使用友善MINI2440开发板，开发环境为RealView MDK 4.22。需要注意的是，本代码中，对GPIO的初始化放在了s3c2440.s中完成，采用keil自带的html方式进行配置。该源码结构简单明了，原始工程下载地址：点击打开链接UART控制器初始化：voi

好记心不如烂笔头，为方便以后查看代码及代码重复利用，这里贴出自己写的S3C2440 MMU代码库。使用友善MINI2440开发板，开发环境为RealView MDK 4.22。该源码结构简单明了，原始工程下载地址：点击打开链接

好记心不如烂笔头，为方便以后查看代码及代码重复利用，这里贴出S3C2440 LCD控制初始化代码。使用友善MINI2440开发板，LCD为320*240，开发环境为RealView MDK 4.22。该源码结构简单明了，原始工程下载地址：点击打开链接

本文基于ST官方demo板STM32F429 Discovery硬件平台，以看图说话的形式给大家讲解LTDC的主要参数配置。关于本文提到的代码部分均摘自本人另一片文章《STM32F429之LTDC代码模板》，LCD硬件为240x320，驱动IC为ili9341。本文目的意在让大家通过几张图就能掌握STM32F429 LTDC控制器的配置要领，而从干涩的文字中解脱出来，方便记忆。当然本文只是讲解了LTDC一些常用的设置，关于更多细节的操作还是得参照ST的官方datasheet。

好记心不如烂笔头，为了方便以后快速查阅代码，提高开发效率，在这里特将LTDC驱动的初始化代码贴上来。本代码是基于ST官方STM32F429 Discovery Demo板的，学习LTDC驱动时参考了Demo板的官方例程，但是总觉得官方例程写得有点繁琐，不简洁明了，于是在此基础上重新整理代码得到如下初始化模板。

SPB是Simple Peripheral Bus的简称，直译过来就是简单外设总线，它包括I2C总线、SPI总线。SPB是在Windows 8以后才被驱动支持的，而在之前如果系统想访问I2C外围设备，则只能通过BIOS程序间接的访问，没法直接访问外设寄存器。在系统启动时，ACPI固件会根据配置表扫描SPB设备，并将它们的资源信息传递给PnP（即插即用设备）管理器，这些资源就包括I2C从设备地址、I2C总线时钟频率以及该设备的中断号。需要注意的一点，在ACPI资源配置表中，是不允许使用Memory32Fixe

今天给大家讲解一下，在KMDF(Kernel-Mode Driver Framework)中是如何调用ACPI配置表中用户定义的Method。在ACPI中，凡是以下划线开头的Method（如_STA）都系统预定义的Method，它们都由Windows OS自己调用，其他用户自定义Method则由驱动程序调用。

在做Windows Phone驱动开发时，时常需要和注册表打交道，因此，作为手机驱动开发人员，有必要了解一下注册表相关的知识。本人目前对注册表也不怎么了解，也只是大概的知道在Windows Phone下，驱动的inf文件并不像桌面Windows那样提供驱动自动安装程序，在Windows Phone下，inf文件最终会被解析成注册表信息并添加到注册表中。我们驱动往往将一些硬件参数保存在注册表中，因此在软件编程时，自然就会涉及到注册表的读写更新操作。

在上一节 Windows Phone 8.1 驱动开发——GPIO 简介 中，我们了解了Windows 8系统中GPIO驱动的大体架构，由于在工作中手机驱动开发人员很少涉及到GPIO Controller驱动的开发，该部分都由平台厂商开发完成，所以这里给大家讲解一下GPIO Peripheral Device Driver的开发步骤。本文以微软官方提供的GPIO Sample为例进行讲解，你也可以到MSDN官网进行源码下载：GPIO Sample Drivers

在windows 8系统中，GPIO驱动被分成了三部分：GPIO控制器驱动、GPIO框架(GpioClx) 和 GPIO外设驱动。GPIO控制器驱动：直接操作GPIO控制寄存器，与控制器硬件相关，并通过事件回调的方式将数据传送给GpioClx。GPIO框架：负责连接GPIO Controller Driver 和 Periphera Device Driver 的中间层，实现外设驱动与控制

一、原理图确认 首先通过硬件人员或SPM获取到项目的电路原理图，观察Camera部分的电路原理图，了解Camera的总线接口以及引脚定义。下图为Tango+3GCamera部分的电路示意图：   二、GPIO配置    由以上原理图可知，Camera接口总共使用了17根引脚，分别为8根控制信号线、8根数据信号线和1根模组ID引脚。其中SCL、SDA、

本文以Tango+3G V1.0 Bugfix 的Config Spec文件为例进行说明。 #==========================================================================#  History :#----------------------------------------------------------

现象：在对某一个或某一些文件进行Check Out操作以后，当使用Find Checkouts时，却无法找出Check Out文件，如下图：  由上图可知，sim_msdc_test.c文件和BC_drv.c文件已经成功Check Out了，但是当使用Find Checkouts时，却出现如下状况：     问题原因：通过IT6000的帮

个人总结： 一个VOB实际上就是一个版本受控的文件的集合，这个集合存在于服务器上，并且这个集合是只读的。通过它的英文全称就很容易理解（Versioned Object Base）。 一个View实际上就是一个窗口，有了这个窗口，用户就能够看到VOB中的具体内容，实际上就是将VOB中想要访问的内容映射到这个窗口中来，没有这个窗口，用户就无法访问VOB中的数据。 注：以下图片均

一、介绍：本文以网上开源文件系统FatFs 0.01为研究对象，剖析FatFs文件系统的核心操作。FatFs目前最新版本已更新到0.10a版本，而我之所以选择0.01版本，是因为这是最早的发布版本，与最新的版本相比，去掉了很多高级应用，且代码量相对较小，宏开关也少了许多，易于阅读和理解，用来研究它的雏形再合适不过了，所以笔者选择0.01版本进行剖析。当大家了解了0.01的核心思想后，再回去看最

注：FAT16驱动代码不是本人编写的，是从网上下载的，本人只是对该代码进行研读学习，并做下笔记。该FAT16驱动应该是比较老的了，猜测应该在DOS时代比较流行，但放在今天，对于刚刚进阶FAT16的小伙伴来说，还是很适合初学者学习的好资料！笔者也相信，只要小伙伴们静下心来，慢慢读懂该代码，相信很快就能在脑海中形成一张FAT16的总览图了。        笔者对代码进行了简单测试，在STM32平台

第八篇：完善的占先式内核         与第七篇没有多大区别，只是将前面的占先式内核与协作式内核相结合，增加了任务阻塞和信号量功能。        任务级切换：高优先级——>低优先级       中断级切换：低优先级——>高优先级                                                                    

第七篇：占先式内核(只带延时服务)——任务调度对比        协作式内核 + 轮番调度内核  = 占先式内核

第七篇：占先式内核(只带延时服务)——时钟节拍中断对比增加了IntNum和OSCoreState两个变量register unsigned char IntNum asm("r4"); //中断嵌套计数器 //只有当中断嵌套数为0，并且有中断要求时，才能在退出中断时，进行任务调度 register unsigned char OSCoreState

第六篇：时间片轮番调度法的内核  //进行任务调度 void OSSched(void) { // 根据中断时保存寄存器的次序入栈，模拟一次中断后，入栈的情况 __asm__ __volatile__("PUSH __zero_reg__ \t"); //R1 …… __asm__ __volatile__("In

第五篇：完善的协作式的内核——OSTaskSemPost //发送一个信号量，可以从任务或中断发送 void OSSemPost(unsigned char Index) { if(Sem[Index].OSEventType) //当要求的信号量是共享型 { Sem[Index].OSEventState=0x

第五篇：完善的协作式的内核——OSTaskSemPend //任务等待信号量,挂起 unsigned char OSTaskSemPend(unsigned char Index,unsigned int Timeout) { //unsigned char i=0; if(Sem[Index].OSEventState) //信

第五篇：完善的协作式的内核——OSSemCreate //信号量 struct SemBlk { unsigned char OSEventType; //型号 0,信号量独占型；1信号量共享型 unsigned char OSEventState; //状态 0,不可用;1,可用 unsigned char OSTaskPendT

第五篇：完善的协作式的内核——OSTaskResume //恢复任务 可以让被OSTaskSuspend或 OSTimeDly暂停的任务恢复 void OSTaskResume(unsigned char prio) { OSRdyTbl |= 0x01<<prio; //从任务就绪表上重置标志位 TCB[prio].OSWaitTick=0;

第五篇：完善的协作式的内核——OSTaskSuspend //挂起任务 void OSTaskSuspend(unsigned char prio) { TCB[prio].OSWaitTick=0; OSRdyTbl &= ~(0x01<<prio); //从任务就绪表上去除标志位 if(OSTaskRunningPrio==prio)