继续看AUTOSAR的文档，很枯燥，但是枯燥之中也有点有趣。今年的618，一片买买买的声音中本来想沉默，但是家属关怀备至，听说我去年买过的护眼显示器好用非得让我把家里的升级了。这下子，看这样的文件更舒服了！今天继续看《AUTOSAR_RS_Features》，似乎到了我之前可能了解最多的章节了，MCAL以及I/O。
这个应该就是对于MCAL的一个要求了，这个抽象层需要提供对于内部MCU配置寄存器的读写功能。而且，这样的配置寄存器也得是可以进行存储映射的。
对于初始化以及运行等，提供标准的接口。
提供数字I/O信号到数字I/O端口的映射，这样也是为了能够做到软件解耦，保证应用软件的可以执性。
这一条要求其实是跟上面那一条要求有一些类似的，但是，数字量变成了模拟量。
还是一条类似的需求，只是这个是要求了PWM的信号的映射。
一样的需求，这个要求针对输出比较单元。但是，对我来说这的确是一个新名词，输出比较单元之前似乎是没有使用过的。
针对这一条的理解，有点结合经验了。这里的要求，其实是一个PWM捕获的功能，之前看到的缩写词尾ICU。或许，ICU也有其他功能涵盖在其中，当前我工作之中遇到的的确是只有PWM的捕获功能。
提供对硬件定时器的访问，但是这个描述多少有点看不懂了，这个如何做到可以执行性呢？难道，这样的接口功能以及名字全都是定死的？我现在接触到的软件设计中，定时器的使用一般都是很少的，主要的原因可能出在我身上。我个人没有接触过太多关于定时器复杂的用法案例，没见过专业玩家如何玩的，一切设计全凭自己理解。而我个人目前几乎又是小团队中经验最多的了，大家都是看我的行为或者用我的成果，因此目前有这样的一个局面。但是，我一直觉得这个定时器上可能会有比较深得用法，或许还会有点睛之妙，但是这一切等着我自己发掘出来可能会是很久以后了。
结合这些描述看，这里面的要求很多应该是对于功能或者接口标准化的一个描述。而一条条的要求，其实是把涉及到的常用资源全都列数了一遍。这里提到的是对于SPI功能的提供要求。
提供对于通信总线的访问，这一条与我之前的理解有一些偏差，因为之前我觉得SPI也应该是通信总线之一。这里为什么把两者分开了呢？
我大概知道这条需求的要求，但是我觉得这个可能是有问题的。主要的问题点在于使用案例的描述，外部的EEPROM应该不会是划归到MCAL之中的。
又看了这条要求，让我有点迷糊了。难道，内部以及外部的看门狗、EEPROM等都是在MCAL之中的？看起来，这部分还是得找有经验的人学习一下。也可能是我之前理解错了，MCAL不仅是MCU的驱动本身。当然，我现在的文件阅读刚开篇，也有另外的可能性：这里提出的这个抽象成或许并不是我之前理解的MCAL。
这条描述对我来说很有启发性，甚至说解答了我的一个疑问。我在SENT等模块中看到过模块的看门狗，但是我一直不知道干什么用的。看起来，这个功能很可能是用来检测超时的。
对于连接的设备，提供标准化的模式支持。值得注意的是，从这一条开始，已经是IO硬件抽象层的说明了，不再是MCAL了。
IO硬件抽象提供在特定的域以及特定的硬件单元之间提供I/O信号的映射功能。具体来说，可能包含一些信号有效范围的检查、滤波、精度转换等。
IO硬件抽象层，提供边沿触发的I/O信号支持。主要包括脉宽、周期、占空比等信号的支持。这里面，脉宽的测量我似乎在之前的工作中没遇到过实际的案例。
IO硬件抽象层，提供对幅值level触发功能的支持。
支持时间域IO信号，看描述这个似乎主要是对于系统的离散化处理要求。
结合上一条，两条应该综合来看。IO硬件抽象层应该支持时域以及频域范围内的信号处理。
IO硬件抽象层应该支持一定的硬件防护功能。
以上，大概是对MCAL以及IO硬件抽象层的一个初步的信息梳理。这一次的信息梳理，还是有一些收获的。开卷有益！
