全部学习汇总： https://github.com/GreyZhang/g_FreeRTOS
官方针对很多不同的平台提供了Demo工程，每一个都是没有警告和错误的。但是，部分相关的工具或者组件的升级可能会改变现在的现状。还有一个单独的页面用来说明如何去创建一个独立的Demo工程，这个不知道跟前面看到过的移植到新的硬件上的那部分内容是否是同样的信息。
给出的演示版本的工程主要有两个目的：1，辅助学习如何使用FreeRTOS； 2，对于新的应用来说，这个配置好的Demo工程其实是一个很好的起点。
这里再次说了，对于已经支持了的平台来说，创建一个应用的比较好的方式是直接在demo工程基础上开始，增删自己期望的内容。不过，又一个点需要注意：在进行增删的时候尽量先把configUSE_TICK_HOOK设置为0，这虽然可能会导致一些例程的执行异常，但是也避免了tick hook与其他内容交互带来的一些问题。
每个演示项目都有一个文档页面，详细说明了FreeRTOS的工程位置。如如何设置硬件，以及如何构建项目等描述也一起说了一下，以节省用户的时间。
这些仅仅是内核的示范程序(不包含任何其他库的示范)，全都放在FreeRTOS/Demo目录的子目录中。这个目前前面也已经实际打开看过，目前我看到的有203个子目录。子目录的名称标识目标设备（可以理解为单片机）和用于生成其中包含的项目的编译器。 还有一个FreeRTOS源代码组织说明页面，对FreeRTOS目录结构进行了完整解释。
大多数演示应用程序在项目的main.c文件中使用#define来选择是构建一个基本的“blinky”风格的项目，还是构建一个全面的测试和演示项目。
Blinky演示项目包含在单个源文件中，并实现了独立于硬件的演示功能页面中描述的功能子集。暂且不去看这个页面，从这个名称看大概可以知道，这个OS本身的功能与硬件关系不大。
Blinky项目至少将演示如何使用FreeRTOS队列在两个任务之间传递一个值——每次接收到值时切换LED或打印输出。 许多blinky项目还演示了使用相同队列的单个软件计时器。
综合示例项目创建“通用示例任务”的全部或一部分——之所以这么说，是因为这些任务对所有综合示例都是通用的。 创建的任务数量取决于目标硬件(微控制器或微处理器)上的可用资源——任务堆栈可用的RAM数量是限制因素。
较早的常见示例任务只包含如何使用RTOS特性的演示。较新的常见演示任务包含集成测试—使其实现更加复杂。之前也花时间看过Windows模拟版本的一些例程，看起来我看过的更像是比较早的，只有OS特性展示的例子。
全面的示范例程创建一个'check'任务，也由少数工程会通过一个'check'函数从hook调用。 每个常见的演示任务都包含自我监控代码，check任务的工作是定期(通常为3秒或5秒，根据演示情况)对每个任务进行查询，首先确保任务仍在执行，其次判断任务是否检测到错误。 然后，check任务通过切换LED或打印一条消息报告系统状态。 如果没有检测到错误，那么就会以原始的速率进行LED的闪烁，如果检测到了则是加速闪烁。
关于最后的注意点，多少有一点没理解。难道抢占式的调度中，抢占发生了就是一种错误？
这是随便找了其中的一个例子看了下这个宏定义的使用。
进一步查看这个宏的使用，其实就是用来做不同分支的选择性编译。也就很容易知道这个设计的意图了，每一个工程可能都可以做一个完整功能的演示。
这是一段示范的伪代码，其实两个不同的编译分支应该是完全不同的初始化以及task的创建逻辑。
- 演示项目通常使用目标处理器上的所有可用RAM，需要在添加更多任务之前删除一些任务。
- 大多数构建标准演示任务的项目只是演示和测试内核。 有一些单独的项目展示了附加的库，如TCP/IP堆栈或FreeRTOS核心库。
- 提供标准的演示项目文件的目的是演示如何使用和测试RTOS内核。不是优化的解决方案。 尤其如此comtest.c(使用UART驱动的一个例子),侧重于测试RTOS内核实现,而不是提供一个最优集成的一个例子(UART接口通常会使用一个流缓冲区,而不是一个队列)。
这里有一点我觉得很值得注意，关于提到的优化解决方案中的stream buffer的使用。这具体是一个什么技术实现方案需要了解一下，在此之前类似的处理我也的确是在用队列的方式来实现。
这些都是旧的信息了，可能不是很重要了，可以做一个简单的理解。第一个是用来做LED访问的测试文件的说明。第二个是通用的全功能演示测试程序，早期设计的时候是考虑在DOS上运行，因此文件名尤其特殊性。再者，还有一些比较老的、原始的使用方式可能并不会有完善的文档，可以参考的文档其实也就是代码文件本身。
