Уровень встроенного интерфейса хоста, который будет работать с несколькими последовательными протоколами, такими как I2C, SPI и UART - PullRequest
0 голосов
/ 26 сентября 2018

Большинство контроллеров, таких как msp430, имеют несколько последовательных интерфейсов связи, таких как I2C, UART и SPI.Я пытаюсь создать программный уровень поверх этих интерфейсов, который остается общим для всех этих периферийных устройств.Я предполагаю, что интерфейсные функции должны выглядеть примерно так:

ProcessRxBuffer ();Данные с периферийного устройства хранятся в буфере RX.Периферийное устройство будет прерывать верхний уровень после получения полностью сформированной команды.

ProcessTxBuffer ();Данные из буфера TX отправляются периферийным устройством.

Драйверы более низкого уровня будут специфичными для периферийного устройства.

  1. Предполагая, что в любой системе, использующей это программное обеспечение, будет активен только один из периферийных устройств, есть ли другой шаблон архитектуры / дизайна, на который я должен обратить внимание?

  2. Есть ли какие-либо подводные камни, о которых мне следует знать, прежде чем я передам эту конкретную структуру?

РЕДАКТИРОВАТЬ: Еще несколько подробностей.

  • Это код прикладного уровня MCU.Конечный пользователь может выбрать любой из базовых последовательных интерфейсов для своей системы.

  • Это будет только подчиненная система с программными регистрами, в которые подключенный хост будет записывать или считывать данные.с.

1 Ответ

0 голосов
/ 26 сентября 2018

Все они являются последовательными интерфейсами , а не протоколами .Они значительно отличаются друг от друга способами, которые делают общий интерфейс трудным или непрактичным.

Например, UART не имеет средств адресации или выбора устройства, SPI и I2C являются главными / подчиненными, а UART одноранговыми-пир и полный дуплекс с независимыми Tx и Rx.Кроме того, соединение UART обычно находится между двумя устройствами с возможностью обработки, тогда как SPI и I2C чаще всего являются соединением между «умным» ведущим и «немым» ведомым.Ваши интерфейсы SPI и I2C на прикладном уровне обычно должны работать и иметь интерфейс, определяемый устройством, с которым вы разговариваете.

В некоторых случаях устройство I2C или SPI (неинтерфейс) реализует интерфейс, подобный потоку данных (например, не случайно SPI или I2C UART будут делать, а модуль GNSS будет), тогда, конечно, можно реализовать общий интерфейс приложения выше универсальный драйвер интерфейса.В этом случае каждое отдельное устройство будет рассматриваться как UART, а не как сам интерфейс.Обычные устройства SPI / I2C с адресом произвольного доступа или режимом доступа к регистру не так легко привязываются к интерфейсу потока данных.

Поэтому, возможно, вам нужно реализовать универсальные драйверы устройств SPI и I2C, которые могут взаимодействовать с любым шинным устройством, и для тех устройств, которые предоставляют или принимают поток данных , реализуютинтерфейс уровня к тем устройствам, которые являются общими для вашего устройства UART.

То есть ваш последовательный API должен, для SPI и I2C, использовать драйвер устройства для I2C или SPI подчиненное устройство , а не интерфейс I2C или SPI , поскольку не все устройства, к которым вы можете подключиться, соответствуют такому интерфейсу.Устройства интерфейса связи или соединения процессора с процессором являются и очевидным выбором для общего API.

  1. Предполагая, что только одна из периферийных устройств будет активна в любой системе, использующей это программное обеспечение, есть ли какая-либо другая?шаблон архитектуры / дизайна, на который я должен смотреть?

Я не уверен, зачем вам делать такое предположение, оно кажется излишне ограничительным.То, что я описал, выглядело бы следующим образом:

enter image description here

Есть ли какие-либо подводные камни, о которых мне следует знать, прежде чем я передам эту конкретную структуру?

Если приложение является многопоточным или выполняет задачи, и каждое устройство может быть доступно из независимыхпотоки, которые вам понадобятся для управления потокобезопасным доступом к общим аппаратным интерфейсам.

...