1248_FreeRTOS的系统配置选项
配置文件可以用来对FreeRTOS的功能进行定制配置，跟应用软件程序相关，因此没有归属到FreeRTOS的内核部分。配置文件是一个名称为FreeRTOSConfig.h的定制文件，每一个应用工程中都该有一个且需要让编译器找得到。
接下来，看一个比较典型的配置文件的组成。
忽略对于其他的文件的管理的提示，单纯看一下现在的几条配置信息。这几条配置信息基本上是OS的一个最基础的功能属性，比如是否是抢占模式的、始终多快、tick是多少等等。
这是可以提供的几个hook函数，关于这几个hook函数的介绍整理前面也已经看过了。这里是用来选择是否开启相应的功能。
这三部分有一个相对陌生的概念，Co-routine不知道是不是并发并行之类的概念？对于这个属性或者说功能，之前的确是没有了解。另外两部分则是熟悉的，一个是OS中的一些状态的跟踪统计；另一个则是软件定时器以及队列等基础功能的配置选择。
这两部分，一个是中断的配置信息，另一个是用来trap各种错误的配置，是一个基础的功能实现。主要的关注点应该还是中断的处理部分，虽然这部分没有几个配置信息，但是之前软件调试的时候这方面遇到的问题的确是让我头疼过。
这里的两部分配置，一个是MCU的内核相关的配置。另一部分则是可选的功能，如果不做这部分配置的话，用不到的功能可能会被链接器给优化掉。
从ucos接触的时候开始，基本上就陪抢占式内核是有优势的说法给洗脑了。的确，抢占式的内核是有一些优势的，但是到了汽车电子的领域这部分的确变得更加繁琐了。这个配置参数用来设置OS内核是否是抢占式的，如果是1是抢占式的，0则是协同式的。
在任务调度，比如优先级处理方面的设计上，FreeRTOS的内核提供了各平台通用的方式，同时也提供了针对不同平台的硬件特性优化过的设计。但是，优化的设计可能在应用上有一部分限制，比如支持的优先级的数目等方面可能会少一些。
FreeRTOS有一个无tick的模式，这个可以很好地支持低功耗的模式。我一直没有用过这个模式，理解上可能是纯粹的事件触发模式？
这几个hook函数前面单独拿出来看过了，如果要用需要修改这几个参数的配置，令其为1。
前面这两个配置，我理解其实是跟具体的驱动实现有一定关系的。如果在已经熟悉的MCU平台上从头开始移植FreeRTOS，类似的配置可能得变通处理甚至直接无效。第三个配置的参数其实是一个时间度量单位，但是这个其实是跟系统的tick频率有对应关系的。而tick，其实可以理解为是OS的一个内在基本调度激励信号。快了，实时性好，但是CPU的耗费也会多。
这个配置可以设置系统的最大优先级，多个任务可以使用相同的优先级。Co-routines的处理是特殊的，需要查看相关的介绍。从这里能够获取到另一个信息：优先级如果设置的多了，RAM的占用量也会多。这个之前的确是没有注意到，可能之前我测试的工程占用RAM比较多这里会是其中的一个因素？
一开始，我对这个描述多少还是有一些疑问的。名称叫做最小stack的大小，为什么会与idle task扯上关系呢？其实，变通思考就可以理解。stack的使用肯定是发生了抢占的时候才会存在占用，而idle执行的时候其实是没有其他的有效task在执行了。这样，idle task可以用得stack其实也就可以表征系统stack的占用量。这个大小的基本单位不是字节，处理的时候需要注意。
最大的任务名字长度，这个可以限制任务名称可以容纳的字符串长度。而这个名称可以在很多时候提供快捷的task的提示信息，自然，对于调度功能本身来说这个并不是必须的。
trace工具的配置可以允许增加一些可视化以及trace的信息，之前我用过的IDE中有一些可视化的信息，不知道是不是这个配置提供的。另外，这种可视化的信息是不是有比较通用的查看方式也需要后面专门研究一下。
使用16bit的tick，对于8bit或者16bit的MCU来说可以提升性能。但是，这个会影响一个task可以允许的最大延时时间。
之前这个功能简单看过，但是只是知道有这样的一个参数。具体是做什么用的一直没有弄清楚。这次看了一下，感觉这个参数支持的功能配置有点类似天花板任务处理一样。其实，一定程度上等同于让idle task有了一个更低得优先级。这样，如果有任务与idle task有相同的优先级的时候可能会有更多的时间来执行用户任务。
从过去接触到的各种嵌入式的软件设计应用来看，可能这样的设计用途并不是很大。而且，这个功能的生效有2个必须的条件：1，必须是抢占式的调度模式；2，用户必须创建idle task优先级的用户task。
任务通知功能的开启，这个功能我也是没有用过的。感觉应该是任务的一些状态提示事件或者状态的支持。如果开启了之后，任务的数据结构会增加8个字节的信息。
这个是关于互斥信号的功能配置，可能是我对这方面的理解有限。之前这样的功能是一直都没有用到过。
这个可选接口是用于队列的其他实现选择的，在新的设计中不推荐使用了。现在还留着应该是一个历史性问题了。
stack溢出的检查功能支持。关于stack的溢出检查以及stack本身的监控室一个有一定复杂度的问题，这里只是给出了一个参考的说明链接。自然，后面相应的链接我也会去看看。
这个功能也是跟调试相关的，而且还得配合一定的软件套件来使用。对于基础功能来说应该并不是一个必需项，只是可以让调试的人性化程度更高一些。
队列组功能。可能这个在我的实际应用中也用不到，但是关于队列等描述可能涉及到一些基础的知识。这样，了解一下还是有必要的。
时间切片功能的支持：在抢占模式下，允许在相同优先级的任务之间按照tick的激励进行切换。
这里提到了一个新的库，看起来有一定流行度了。我之前基本是没有接触过的，从名字看这个库一个很大的优势在于可重入性非常好。
这是对于之前的版本的支持的配置，开启后可以提供向前兼容的功能。
给任务线程的本地存储数组设置索引值。这个描述有一点看不懂，可能涉及到OS设计的一些概念了。后面做内核的代码解读的时候，仔细理解一下。
跳过了一部分看着熟悉或者是之前看过的功能配置，接下来梳理一下可能需要关注的或者比较实用的配置信息。
这个配置是用来提供生成运行时间统计信息功能开启的配置，之前曾经找过类似的接口并没有找到具体的实现。如果理解没有偏差，这个功能应该可以提供任务的执行时间等信息，也可以由此反应CPU的负荷率。
这一段描述讲得的确是好，之前的很多疑问基本上在这里找到答案了。这里有三个参数，其实是只有两个，因为其中的两个是等效的。基本的参数有kernel和system两个中断的优先级。其中，kernel是OS用的，应该设置为最低优先级。system的设置会决定哪些ISR可以使用OS的API，只有低于这个优先级的ISR才可以使用OS的优先级。高于system优先级的中断是OS不管理的。类比于之前用的比较多的RTAOS中AUTOSAR的概念，其实这里面是有CAT1以及CAT2中断的区分的。高于system的中断优先级的中断类似CAT1的中断。
对于只有一个kernel优先级实施的系统，使用其实是比较受限制的。所有的中断ISR想要访问OS的API的时候必须与kernel的优先级相同。儿对于kernel以及system的优先级都实现了的OS，其实是分为两种情况，一个是两者相同，另一个是两者不同。相同的时候，所有的中断都是OS托管的，ISR全都可以使用OS的API。但是，这时候其实整个OS只有一个优先级存在，其实并不是一个很好的设计。不同的时候，是一个完全嵌套的实现方式。如果system的优先级不是MCU允许的最高，这时候可能有最大的灵活度。除了OS托管的ISR之外，还有一部分ISR可以脱离OS的管束，拥有更快的响应速度。
断言的使用之前注意到过，其实在软件调试的时候很容易通过这个找到问题的提示。
这4部分都是跟MPU相关的，这个我虽然没接触过，但是从很多资料里面看MPU在安全领域的设计中是很重要的一个模块。如果能够找到有MPU的MCU板子的话，或许我可以深入研究一下这部分功能。
这个功能开启之后，需要借助于linker获取code的分配范围来判断系统调用接口的可信度。这部分主要是从安全的角度做出来的设计，可以避免内核以外的代码意外获取更高的权限。
这两个也是安全相关的，但是跟具体的MCU的架构是有一定关系的。看了一下，我现在手里应该还是有这样的板子的，后面可以研究一下了。
接下来很重要的一点：我觉得我应该找一个板子或者模拟环境开始实际的功能调试了。
