嵌入式主机接口层,可与 I2C、SPI 和 UART 等多种串行协议配合使用

Embedded host interface layer which will work with multiple serial protocols like I2C, SPI and UART

大多数控制器,如 msp430,都有多个串行通信接口,如 I2C、UART 和 SPI。我正在尝试在这些接口之上创建一个软件层,这对所有这些外围设备来说都是通用的。我假设接口函数可能如下所示。

ProcessRxBuffer();来自外设的数据存储在 RX 缓冲区中。一旦接收到完整的命令,外围设备将中断更高层。

ProcessTxBuffer(); TX buffer中的数据由外设发送出去。

较低级别的驱动程序将特定于外围设备。

  1. 假设在使用该软件的任何系统中只有一个外围设备处于活动状态,是否还有其他 architecture/design 模式我应该查看?

  2. 在我致力于这个特定结构之前,是否有任何我应该注意的陷阱?

编辑: 更多细节。

它们都是串行的接口,而不是协议。它们在使通用接口变得困难或不切实际的方面彼此显着不同。

例如,UART 没有寻址或设备选择的方式,SPI 和 I2C 是 master/slave,而 UART 是点对点和全双工的,具有独立的 Tx 和 Rx。此外,UART 连接通常在具有处理能力的两个设备之间,而 SPI 和 I2C 通常是 "smart" 主设备和 "dumb" 从设备之间的连接。您在应用层的 SPI 和 I2C 接口通常必须表现良好,并且有一个由您正在与之通信的设备指定的接口。

在某些情况下,I2C 或 SPI 设备(不是接口)实现类似接口的数据流,(例如,SPI 或 I2C UART 并不意外,并且 GNSS 模块会)那么当然可以在 通用接口驱动程序之上实现通用应用程序接口 。在那种情况下,每个单独的 device 将被视为 UART 而不是接口本身。具有随机访问寻址或寄存器访问行为的常见 SPI/I2C 设备不会如此容易地倾向于数据流接口。

因此,您可能需要实现可以与任何总线设备通信的通用 SPI 和 I2C 设备驱动程序,对于那些提供或接受数据 的设备,实现那些 设备的更高级别接口,这对您的 UART 设备是通用的。

也就是说,对于 SPI 和 I2C,您的串行 API 应该使用 I2C 或 SPI 从设备 的设备驱动程序,而不是 I2C或 SPI interface 因为并非所有您可能连接的设备都适合那种接口。通信接口设备或处理器到处理器的连接是常见 API.

的明显选择
  1. Assuming that only one of the peripheral would be active in any system using this software, is there any other architecture/design pattern I should look at?

我不确定你为什么要做出这样的假设,这似乎是不必要的限制。我所描述的内容如下所示:

  1. Is there any pitfalls that I should be aware of before I commit to this particular structure?

如果应用程序是 multi-threaded/tasking 并且可以从独立线程访问每个设备,您将需要管理对公共硬件接口的线程安全访问。