Search code examples
embeddeddriveruarti2cspi

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

Most controllers like msp430 have multiple serial communication interfaces like I2C, UART and SPI. I'm trying to create a software layer on top of these interfaces which remains common for all these peripherals. I'm assuming the interface functions should probably look something like below.

ProcessRxBuffer(); Data from the peripheral are stored in the RX buffer. The peripheral would interrupt the higher layer once a fully formed command is received.

ProcessTxBuffer(); Data from the TX buffer is sent out by the peripheral.

The lower level drivers will be peripheral specific.

  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?

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

EDIT: Some more details.

  • This is an MCU application layer code. The end-user can choose any one of the underlying serial interface for his system.

  • This will only be a slave system with software defined registers into which the connected host will write into or read from.

Solution

  • They are all serial interfaces not protocols. They differ significantly from each other in ways that make a common interface difficult or impractical.

    For example a UART has no means of addressing or device selection, SPI and I2C are master/slave, while UART is peer-to-peer and full-duplex with independent Tx and Rx. Moreover a UART connection is typically between two devices with processing capability, whereas SPI and I2C are most often a connection between a "smart" master, and a "dumb" slave. Your SPI and I2C interfaces at the application layer generally have to behave and have an interface dictated by the device you are talking to.

    In some cases, an I2C or SPI device (not the interface) implements a data-stream like interface, (such as, not unexpectedly an SPI or I2C UART would do, and a GNSS module would) then it is of course be possible to implement a common application interface above a generic interface driver. In that case each separate device would be treated like a UART rather then the interface itself. Common SPI/I2C devices with random-access addressed or register-access behaviour do no tend themselves so easily to a data stream interface.

    So what you need perhaps is to implement generic SPI and I2C device drivers that can talk to any bus device, and for those devices that provide or accept a data stream, implement a higher-level interface to those devices that is common to your UART device.

    That is to say, your serial API should, for SPI and I2C, employ a device driver for the I2C or SPI slave device, rather then the I2C or SPI interface because not all devices you might connect to are appropriate to that kind of interface. Communication interface devices or processor to processor connections are and obvious choice for a common 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?

    I am not sure why you need to make that assumption, it seems unnecessarily restrictive. What I have described would look like the following:

    enter image description here

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

    If the application is multi-threaded/tasking and each device may be accessed from independent threads you will need to manage thread-safe access to the common hardware interfaces.