北京网站建设还公司,深圳企业网站制作流程,贵阳网站建设公司排行,seo含义Grey
全部学习内容汇总#xff1a;GitHub - GreyZhang/g_embedded: some embedded basic knowledge.
1846_安全SPI
SPI是一种常见的通信方式#xff0c;在汽车电子中比较常用。但是如果涉及到安全相关的设计#xff0c;可能得考虑更多。而SPI协议本身没有很好的标准化GitHub - GreyZhang/g_embedded: some embedded basic knowledge.
1846_安全SPI
SPI是一种常见的通信方式在汽车电子中比较常用。但是如果涉及到安全相关的设计可能得考虑更多。而SPI协议本身没有很好的标准化安全SPI是这方面的一个很好的解决方案。
主题由来介绍
之前用过一些SPI的通信其实SPI也是我最初迈入嵌入式的时候接触到的通信的功能算得上是一种让我感觉到亲近的一种通信方式。不过安全SPI之前还真没有注意过。过去的一段时间参与过功能安全项目的开发设计让我对安全这样的字眼有了一些直觉上的好奇。这次看到的这个安全SPI应该可以继续丰富补充我在安全设计方面的一些常识性短板。
资料分析 SPI是摩托罗拉开发出来的主要是用于短距离通信的同步串行通信。SPI并没有比常规的标准因此各方面的开发可能种类会非常多并且很多开发可能会重复性投入。在汽车电子领域中经常会有一个独立的SPI监控设备用来实现安全的功能。这样的功能通常是通过硬件实现的。 安全SPI可以应用于传感器、IC、ASICS以及MCU等看起来应用的场景还是很全面的。 如果片选不使能的时候MISO以及MOSI一般来说会进入到高阻态。这里给出来了一个安暖气囊的例子从这里看的确是有一个独立的监控器专门用来监控。如果这个只是一个监控如何跟整个系统进行交互这个会提供一些进入到MCU的新号 SafeSPI对于SPI外设的供电并没有什么要求可以是不同的。其实这么看的话也可以是相同的。 这里进一步讲了对于供电的要求要求SPI的接口的供电必须保持一致。从这里看其实这个标准是为了实现新号的一致性而不是考虑电源的失效。进一步考虑其实如果一个外设的供电与SPI的供电是一起的那么整个设计中全都采用相同的电源供电应该是满足的。 时序的规范上应该至少要能够支持到10M时钟。如果是在汽车电子用控制类的控制器中10M也不算低了。而且这个规范把这个定义为了一个最低标准这样整个规范的适用性应该很不错。从网上也找到了一些芯片资料采用了SafeSPI的标准但是最大的时钟只支持5M。不排除之前的版本中对此要求可能低一些。 为了满足SCK以及MISO的新号负载电容范围建议增加一个可以用户编程的驱动强度以及速率的配置项。针对slave的设计也有类似的要求这里不做重复的整理。 这里提到的参数9是一个帧间延时参数这个参数对于不通的通信模式要求是不一样的。如果是out of frame这个时间是要长一些的。因为需要有一定的时间去准备数据。out of frame 以及 in frame 分别是一个什么概念之前是没有了解过的。结合这里的描述应该是一个数据准备不需要时间一个数据准备需要一定的时间。 SafeSPI 支持32bit以及48bit两种模式。32bit模式支持 out of frame 以及 in frame 两种模式。但是48bit只支持 out of frame 模式。关于 out of frame 以及 in frame 的解释这里有一个说明。看起来之前我理解的还是错误的 out of frame 的数据返回实在下一帧内。而我之前理解的是连续的数据传输中需要一定的时间间隔准备数据。 in frame 的数据会在同一帧的数据之内做返回。通过这里的信息看其实 out of frame 以及 in frame 是指一个响应的模式跟安全其实没有什么特别的关联。 SafeSPI的数据格式定义为MSB。对于 out of frame 的通信读取指令CS的上升沿或者最后一个时钟相位新号作为从机数据准备的触发信号。无论是32bit还是48bit的格式数据帧的结构都是已经定义好了的。如果从机接收到了无法识别的命令应该按照规范中的应答格式进行响应回复。 SafeSPI中从机寻址有5种模式第一种是采用CS的方式。剩下的4种需要结合一个TA数值TA为 target address 的缩写。TA可能有1bit或者2bit体现的形式可能是pin的配置也可能是从机中的NVM编程bit。这样一共可以组合出来5种寻址模式。按照TA的方式进行寻址的方式让主机可以不用那么多的控制线就可以带最多4个从机。 关于寄存器的bit定义只看一下这个帧类型这部分。其他的部分可以结合具体的芯片在应用中继续做拆解分析。这类的这个帧类型其实更多的是提示不同模式中下一帧的数据会是什么信息。 SafeSPI协议中规定了一个CRC的校验这样可以确保数据的可靠性。 只是前面提到的一个错误处理的定义表。从表格中可以看得出来并不是所有的错误都会有显式的响应。有时候针对错误的输入可能是没有任何动作。
其他
继续往后主要是48bit模式的一些说明这个我感觉短时间内可能不会用到暂且先不去做深一步的了解。不过从后面的信息浏览中至少是可以看得出来48bit的CRC校验与32bit还是不一样的。此外从机可能会同时支持32bit以及48bit两种模式。
小结
随着科技的进步以及人们对于安全的重视未来汽车电子中的功能安全设计肯定会被考虑的越来越多。针对类似的统一性标准做一下了解对于未来面对随时可能出现的工程实施诉求还是有很大的帮助的。
