小灰笔记

3. 非静态但是又不想作为API提供的函数，全都使用小写并且前面加上一个下划线表示这个是自己用的，不是一个全局功能。2. 中断的触发以及执行恢复等动作都是高于任务的，因此中断本身的堆栈处理并不会影响到线程相关的功能，不会影响到可移植性。参数是归属于线程的，因此可以通过传递相同的函数与多个参数的组合给不同的线程，并不会导致线程之间的冲突。1. OS内部的一些处理休眠的状态对象中有多个状态信息，可以表征任务的休眠原因。3. 在线程的工作区中，看得到线程自己的堆栈存储信息，初次之外还有中断信息。

这里的板子抽象的部分相比熟悉的AUTOSAR的架构图来说，位置是颠倒的。我觉得可能这里可以从一个实际的编码的经验角度考虑，其实这个启动代码提供的是一个初始化的接口，这里先进行一些初始化再启动OS，这样的流程应该就理顺合理了。但是，这样的功能并不是百分百绑定OS的，其实换一个其他的OS或者说是裸机程序都能够提供一些这样的实现。1. 不同于其他的OS，ChibiOS提供的不仅仅是一个调度器，而且还有丰富的OS组件。1. 内核部分中可移植的部分以及通用的部分进行了分离，这似乎是大部分的OS采用的手段。

4. 采用优先级的天花板机制，让信号具有高于任务的优先级，获得信号的任务具有与其对等的优先级。这样的机制，可以让使用互斥资源的任务中的资源请求任务临时获得所有资源使用任务中最高优先级的同等优先级。2. 关于中断是可以分为两类的，一种是不可以用OS接口的，另一种是可以用OS接口的。1. 针对前面的比较简单粗暴的保护区的处理机制，进行一个改进：关中断的时候不要把全部中断都关掉，只关闭一部分。第三，API的处理包括了ISR。1. 结合上一页的末尾以及这一页的开头，通过伪代码的形式来介绍了可能的共享数据问题。

5. 非实时的进程、软实时的进程和硬实时的进程可能同时存在于一个系统中，这一页中的这个图就是一个例子。I2到O1的一个路径经过了进程2是非实时的，这就是导致O1的输出可能会是非实时的。所谓的软实时，也有一定的实时性的要求，而且不在预期的时间内完成进程的执行可能会导致不理想的效果，但是这不会导致灾难性的后果。从这里的示意图看，抖动的定义是最坏的时间与最好的时间的差值。1. 其实前面介绍的一个活动可能是包含一系列进程以及输入事件和输出响应，而系统则是由若干这样的活动组成的。2. 什么是非实时性的OS呢？

毕竟，早期的linux也就是这么个玩意儿。我觉得这个对于初学者来说肯定是很好的，而且我之前看官方网站的时候已经看到了其实有一个一切就绪的虚拟机可以下载应用，这回更加让人觉得便捷了。而这样的感觉在作者1992年的时候就遇到了，那时候需要一个微内核，因此就催生了他的另一个作品MK。时光到了2006年，重新改造过的MK换了一个名字也就是ChibiOS，大约在2007年的时候与大家见面了。这就是对于ChibiOS网络book的介绍部分的简单了解，我觉得类似的开篇让我很有接下来品味一下这个OS效果的“食欲”了。

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.V9.0.0是一个版本的分水岭，在这个版本之前静态的配置应该是不支持的，只能够通过专门的heap来进行存储的分配。在这个版本之后，应用软件可以自行进行静态的存储分配。涉及到的功能其实还是很多的，上面画出来的这个清单就是。比较常用的任务、软件定时器、队列等等都在覆盖的范围内。关于静态以及动态存储分配，优劣并不是绝对的，各有优劣。两种方式甚至可以在同一个F

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.从描述看，FreeRTOS也可以不使用heap。关于这部分应该仔细研究下，按照之前我看过实践过的部分内容以及信息，我觉得FreeRTOS给我的一个很大的困惑点在于heap占用了太多的RAM。看起来，这方面还是有改进空间的。OS中的很多对象，例如task、队列等都需要用到RAM，可以直接从heap分配也可以由应用软件开发人员分配。关于后面的说法，之前我似

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.关于FreeRTOS的代码的管理，首先得注意到这里面分了两个部分。一个是FreeRTOS，另一个是FreeRTOS-Plus。前者主要是侧重于内核以及相关的演示例程，而后者则侧重于与FreeRTOS进行集成的各种组件的例程。如果是刚刚开始了解FreeRTOS或者仅仅是想对FreeRTOS的内核做一个深度的学习，那么很显然后者是比较适合的。内核相关的

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.空闲钩子函数是一个可选功能，如果要使用的话需要配置一个配置参数，同时给出函数的定义。这个空闲钩子函数是重复执行的，这个也容易理解，空闲肯定不是一次性的。如果要使用任务删除的API，需要让这个空闲任务的钩子函数周期性返回，用以支持资源回收。关于资源回收，是一个之前没了解过的功能点。后面花时间好好了解一下，一般来说感觉这个功能更加贴近于PC端这样的运行环境

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.其实，从这个简单的描述就能够知道软件定时器的作用。如果做一个比喻的话，软件定时器的作用就像一个定时炸弹的引爆器一样。它可以控制起爆的时间，而起爆对应的就是软件执行启动的时间。FreeRTOS的软件定时器其实是依赖于已经存在的FreeRTOS的功能来实现的而不是依赖于定时器的中断。因此，这样的实现不会在中断的上下文中执行任何代码。如果不是超时

全部学习汇总： https://github.com/GreyZhang/g_FreeRTOS针对FreeRTOS的完全全新的移植并不容易。我画出来的第二点其实算是对这个难度原因的部分解释，而这个解释其实不仅适用于FreeRTOS，针对很多功能都是如此的。嵌入式系统中的很多功能对于MCU以及编译器等工具有着高度的依赖性，这让软件设计可能存在很多不通用的地方。移植的时候，有一个算是官方推荐的目录管理模式。既然这是大家约定的模式，后续我自己使用的时候也得尽量用这样的目录管

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.其实，这个话题基本上是关于FreeRTOS的移植了。简单的移植可能只是换换硬件板子，涉及到的OS本身修改几乎没有。也有可能是换个同架构但是配置略微不同的MCU，这样可能只需要少许修改即可。也可能是换一个新的编译器，这个可能复杂度就稍微大一点。最难的是从工具到MCU的架构都是全新的，这样的移植可能并不是很简单。这一部分的内容所涉及到的其实不仅仅是让FreeRTO

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.FreeRTOS的源代码比较简洁，必要的文件只有3个系统相关的还有1个移植相关的。但是，看了下后面，其实如果用起来的话还是有很多其他的相关文件的，比如说配置文件；再比如说如果要用软件定时器本身软件定时器的模块也是独立的文件。从不同的地方多次看到了创建一个新工程官方推荐的做法：找一个Demo然后在这个基础上做修改。当然，这个并不是唯一的方式，如果想完全从头创建也

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.官方demo支持的硬件平台覆盖度可能不是很全面，但是相关的demo移植到其他的平台上还是有方法可以参考的。之前我看过的一段文档说明应该就是讲解的这部分了。如果是没有硬件，一日按是可以快速了解FreeRTOS的，可以通过Windows或者Linux的移植版本，也可以尝试QEMU的仿真。这是一个完整的半导体供应商的支持清单，我接触到的或者了解过

全部学习汇总： GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS.官方的例子很难覆盖每一种硬件以及编译器的组合，因为设计一部分硬件不相干的例子这样可以确保用户能够快速了解OS的基础功能。为了能够保证不依赖于硬件，相关的例子中没有任何IO访问。而是采用对变量进行修改的方式来取代。用户需要做的事情：1， 一个非RTOS但是可以运行的程序，保证启动代码以及链接文件的正确性。看起来，整理对OS独占分区没有什么特别的要求。

全部学习汇总： https://github.com/GreyZhang/g_FreeRTOS大概看了一下这个页面，其实感觉这个页面看下去的意义不大。但是，从另一个角度讲，了解一下历史也是好的，简单快速地看一下吧。这里开篇其实就说的清楚了，新的示范工程里面其实Full目录是不用了的。留着的目的也只是为了能够让老的一些例程容易构建出来。新的例程全都在Minimal的目录下，而且相关的说明都在代码文件中。这个文件中测试了队列以及task的一些特性，涉及到的点：队列的阻塞、队列的深

全部学习汇总：GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. 首先看一下MPS2是个什么概念。 没有找到MPS2，但是找到了一个MPS2+，看样子这个是一个开发板的名字。 开发工具上，有IAR以及gcc的编译器可以选择。对于我自己的学习来说，自然是后者了。GNU等开源的组织的确是很好的网络雷锋，让我们接触新的技术方便了很多。 这部分内容很简单了，描述了相应的QEMU的工程...

全部学习汇总：GitHub - GreyZhang/g_FreeRTOS: learning notes about FreeRTOS. 如果没有硬件，可以使用集中其他的手段来进行学习。一个是windows或者linux下的移植，另一个就是M3的QEMU。前面这个是我上一次了解FreeRTOS功能的时候使用的方式，后面这个看起来是我这一次要去学习了解的对象。这里的仿真对象是一个M3的内核而不是一款具体的单片机，我多少有一些好奇，M3一个单纯的内核是不是可以提供足够多的功能去完成一个功...

AURIX TC275 lite开发板说明文档中开发板基本信息梳理Grey全部学习汇总：https://github.com/GreyZhang/g_TC275AURIX TC275 lite开发板说明文档中开发板基本信息梳理信息整理我想这里应该是把hightec的名字给写错了吧？看起来，这个小组工作起来也没有那么谨慎。 这里提到了2套开发工具，看起来英飞凌给出来的开发环境应该会更好一些，支持会更到位一点。不过，为了工作上的衔接性，我觉得我还是想选择hightec来试一下，因为本质

野火RT-Thread教程学习3_Keil仿真功能的使用Grey全部学习汇总：GitHub - GreyZhang/g_RT-Thread: learning and hacking RT-Thread.野火RT-Thread教程学习3_Keil仿真功能的使用前言说起来，这个算不上是OS的学习内容，但是正好是从这本书中引出来的，因此把这部分的学习笔记一起放在这一个类别下管理。记录说明首先说明的一点是，先要掌握一个Keil基本工程的创建以及其文件管理的大概理念。之后基于一个工程可以

野火RT-Thread教程学习笔记2Grey全部学习汇总：GitHub - GreyZhang/g_RT-Thread: learning and hacking RT-Thread.野火RT-Thread教程学习笔记2摘录与批注首先说明，这里的学习跳过了若干页主要是因为这部分是工程创建的相关说明。 这部分自然是有参考价值的，尤其是对工具不熟悉的时候。 这里采用的工具是IDE，相比之下，我的确是更喜欢命令行一些，更加自由。嵌入式系统的几种类型区分。 轮训以及前后台的一个区分点

野火RT-Thread教程学习笔记1Grey全部学习汇总：GitHub - GreyZhang/g_RT-Thread: learning and hacking RT-Thread.野火RT-Thread教程学习笔记1前言马斯克说自学比上学学习的速度更快更好、读书可以让人短时间之内获取大量的知识。硅谷钢铁侠是我这种野生的程序员的佩服对象，因此像他学习，这次的学习从书籍开始。摘录与批注教程会是基于Linux环境的吗？这种很少见，但是我的确是喜欢这样的折腾方式。还有一个F

GreyRT-Thread官方开发工具与对Art Pi的支持全部学习汇总：GitHub - GreyZhang/g_RT-Thread: learning and hacking RT-Thread.Art Pi之前入手了一个Art Pi，当初多少有一点贪便宜的意思，这个开发板的价格的确是不贵。但是买来之后，这个板子就是一直吃灰的状态，没有使用。最近想找一个相对来说通用的OS，决定认识一下RT-Thread。如此，重新把这个板子找出来开始折腾。折腾的第一步是找一个开发工具，这是这一次整理内容

RT-Thread Nano版本简介解读Grey全部学习汇总：GitHub - GreyZhang/g_RT-Thread: learning and hacking RT-Thread.RT-Thread Nano版本简介解读摘录与批注很多特点介绍与标准版类似，应该会是标准版的裁剪版本？ 这一次，注意到了抢占式RTOS。感觉ucos成功后，大家的方式都是这个方式。但是，只有这一点的话，汽车领域推广就很难了。 有一个可以移植的FiSH。这个之前看过很多次，后面正式接触的时候得好好

RT-Thread标准版本简介解读Grey全部学习汇总：GitHub - GreyZhang/g_RT-Thread: learning and hacking RT-Thread.RT-Thread标准版本简介解读摘录与批注功能核心就是一个调度器。 采用了C语言开发，这基本是看到的大多数通用RTOS都采用的方式。 面向对象的设计，不知道具体的实现体现在什么地方。设计模式是我本身的技术短板，接下来正好可以学习一下。 精简的nano版本可以仅用3KB的flash和1.2K的ram

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 继续S32K144的学习，这一次看一下FreeRTOS的工作时钟修改。其实，这就是一个简单的power-mode的切换。但是，在效果上能够看得出FreeRTOS的行为的变化。这种配置，应该载我们工程创建之初就进行修改，这样会让其他的软件适配更简单。不过，从实际的体验看，这...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144继续S32K144以及FreeRTOS的学习，这一次看看heap剩余存储的信息获取。在实际的工程中，随着内存不断被申请，这个资源很可能会成为短板。如果有一个可以实时查看heap剩余空间这样的功能，可以方便我们在软件的调试过程中知道当前的资源使用情况然后根据这个做相应的优化。找...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144继续S32K144的学习，这一次继续总结FreeRTOS的部分功能。这次总结的对象是守护程序的启动监控。关于守护程序，我个人的简单理解是只有这个程序开启了之后FreeRTOS的各项功能才能够有序展开。如果在此之前，使用了一些FreeRTOS的接口的话可能就会导致一些系统的异常...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144继续S32K144的学习，这次小结的对象还是FreeRTOS。这一次看一下任务优先级获取的一个接口。说起来，这个功能我暂时没有考虑到应该如何在我的应用中使用。但是，总归是一个可以纳入到OS本身工具箱的一个功能。为了能够获取所有任务的优先级，我们创建任务的方式有限得修改一下，增...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144继续学习S32K144，这次基于这个芯片看一个FreeRTOS的功能。这次看的是FreeRTOS的Tick Hook功能。之前已经看过idle hook了，其实这个功能与之十分相似。启用相应的功能，需要配置一个宏参数。而SDK配合IDE提供了更加便捷的功能，我们可以仅仅增加一...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144继续S32K144的学习，昨天实现了一个可靠的串口的接收功能。这也算是我自己的首次试水。当然，测试的结果看得出接收功能确实是很可靠了。不过今天继续看我的这个程序的时候，发现了一个问题：有几个FreeRTOS的任务被饿死了。看了一下，应该是两个原因导致：1，优先级设置的过高；2...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144继续S32K144的学习，这次看一下FreeRTOS的周期性任务调度。其实，之前的测试一直在用一个1000ms的周期性调度，但是，这个调度仅仅是用了一个1000ms的延时来实现的。虽然有一定的准确度，但是依然不是很准确。为了测试，这里我修改了一下FreeRTOS的配置，直接把...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 继续S32K144的学习，这一次整理一个我在学习中遇到的BUG。我的软件中有一个基于串口的printf功能，最初这个功能都是OK了。但是，当我增加了一个浮点运算之后，打印了一下之后不再打印了。使用调试器，查看到软件停在了xQueueGiveFromISR函数中。...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 继续学习S32K144，结合这个芯片学习一下FreeRTOS的实际应用。这一次，我想先学习一下队列的应用。 按照文档的解读，这个队列其实确实是有着一个先后关系的意思。但是，这个队列的作用更多的是一个消息传递。今天，我需要做的工作如下：使能FreeRTOS中的...

完整的S32K144的学习汇总如下：https://github.com/GreyZhang/g_s32k144 继续学习S32K144，这一次虽然还是在围绕着S32DS的工具来做学习小结，但是这次与以往有着很大的不同了。这一次，学习总结的重点在与SDK中FreeRTOS的使用。与以往的学习不是很一样，这一次的学习跳过了驱动直接来了RTOS。其实，我觉得这也是现在很多ARM平台共通的...

整个理解思路应该跟信号差不多，仿真环境下能够看的大概也只有初步的效果。接下来，分析一下官方的例程代码。 两个任务创建，一个高优先级的任务用来推迟中断处理，另一个低优先级的用于周期性的调度实现。此外，还有一个模拟中断。 周期性任务，用来生成模拟中断，周期500ms。 中断ISR中，通知中断推迟处理的任务执行，并...

这个同步可以理解为多个状态同时满足，接下来分析下官方的例子。 上面的机制可以理解为，等待三个事件全都达到一起触发一个动作，也就是退出。相当于，三个任务各自等在自己的跑道上，等到了最后50m之后再一起来一个第二次冲刺。 运行效果： 我觉得可以做另一个测试，可以更好看出这个效果，那就是改掉平等的优先级。修改如下：...

先做一个个人理解上的功能小结：队列以及信号的功能：1. 把task置于阻塞状态；2. 信号发生的时候，结束阻塞；时间组的特殊点：1. 可以让一个任务等待一个或者多个时间；2. 还可以一个信号组解除多个任务的阻塞。 接下来，分析下官方的例程。 创建一个事件组，这个里面的有效标志为是24个。创...

官方的模拟环境使用不是很好去说明，毕竟这个资源的纠缠在于Windows，我这里仅仅做一下代码的理解以及测试。 互斥信号创建、任务创建并传入不同参数。 打印增加互斥信号进行资源保护。里面有一个停止调度的判断操作，依据是按键。 任务定义。 运行效果： 需要说明的是，这个...

这个或许不会是我的选择，但是使用守护进程延迟处理中断也有优势。比如，占用资源少，可以不用创建额外的Task。再比如，模型简单，处理容易。 先分析官方的例程： 创建了一个周期性的Task，优先级低于Timer的服务。创建了一个模拟的中断。 周期性任务功能，模拟每500ms产生一次中断。 IS...