Имя Generi c Концепция "Труба" для физической коммуникации? - PullRequest
1 голос
/ 16 февраля 2020

В настоящее время у меня возникает мысль о том, как абстрагироваться (до некоторой степени) от общих механизмов передачи данных встроенных систем, таких как CAN, UART, SPI, I2 C, Ethe rnet, et c. В идеале я хотел бы иметь что-то вроде концепции Pipe, но чтобы интерфейс не заботился о том, по какой физической среде / протоколу передаются данные. Если я говорю «передать эти данные через канал», это просто работает. Очевидно, что должны быть некоторые подробности протокола c деталей в конструкции этого объекта канала, но вне этого это не должно иметь значения.

Есть ли общепринятое название для того, что я пытаюсь сделать ?

Является ли эта концепция даже хорошей идеей? Я чувствую, что это будет полезно для моих целей, но я не знаю, бессмысленно ли это в великой схеме мира встраиваемых систем.

Ответы [ 2 ]

2 голосов
/ 17 февраля 2020

Есть ли в отрасли общепринятое название для того, что я пытаюсь сделать?

Уровень аппаратной абстракции (HAL) подходит ближе всего. Имейте в виду, что упомянутые шины являются аппаратными стандартами, которые не определяют протоколы более высокого уровня. На более высоких уровнях это можно назвать «сокетами», хотя обычно это относится к IP.

Является ли эта концепция даже хорошей идеей?

Вероятно, нет, если у вас нет специальных требований c.

Например, было бы неплохо, если бы вы sh заменили старую сеть RS-485 на CAN, но сохранили старое оборудование. В этом случае имеет смысл иметь как можно большую часть программного обеспечения, совместимого с этим конкретным проектом c.

В противном случае, с общей точки зрения, каждая из этих шин выбирается в соответствии с совершенно разными требованиями. CAN, если вам нужна надежная и надежная система, UART, когда вам нужна обратная совместимость, SPI, когда вам нужна быстрая, синхронная, почти полная связь, Ethe rnet, когда вам нужна быстрая связь на большие расстояния и c и др c. Требования к оборудованию одной шины могут исключать другую.

Например, если я хочу, чтобы мой MCU связывался с «тупым» ЖК-дисплеем, имеет смысл только SPI. Возможно, мне придется переключать дополнительные контакты ввода / вывода вместе с сигналами SPI. Я мог бы хотеть использовать DMA. Et c. В этом контексте для меня нет никакой пользы, если мне нужно использовать абстрактный коммуникационный API, который переносим в CAN, Ethe rnet et c. Это просто глупость - этот код никогда не будет работать ни на одной из этих шин!

Гораздо разумнее разработать HAL для каждого типа шины, чтобы у вас был один SPI HAL, который переносим между микроконтроллерами. Это распространено и действительно полезно.

0 голосов
/ 16 февраля 2020

Каналы обычно используются для IP C (межпроцессное взаимодействие) или перенаправления вывода в файл или ... Для всего этого существуют удаленные технологии, 'remote' означает по сети или через интерфейс или шину , например, RS232, SPI, ... Имя для удаленного IP C: удаленные вызовы процедур (RP C), см. https://os.mbed.com/cookbook/Interfacing-Using-RPC и https://github.com/EmbeddedRPC/erpc. Как и для всех IP C, безопасность является серьезной проблемой, особенно в сети.

Т.е. запись удаленного файла (через TCP / IP) может быть выполнена, как в https://askubuntu.com/questions/917200/how-to-redirect-command-output-from-remote-machine-to-local-file-via-ssh

Имя входа S SH, которое вы можете заключить в функцию, и эта функция сокращает количество команд (макросы также можно использовать для переноса функции Вызов функции обтекания макросом )

Существуют также различные реализации протоколов связи друг с другом, например Ethe rnet по USB (https://en.wikipedia.org/wiki/Ethernet_over_USB)

...