Протоколы I²C, SPI, CAN и модель OSI

Есть ли ссылка или какое объяснение того, что I²C и SPI являются просто протоколами физического уровня в модели OSI (я знаю, что эта модель предназначена для связи и, возможно, не совсем для бортовых шин) или протокол уровня канала передачи данных определен внутри их?

Как насчет протокола CAN?

Этот вопрос кажется не по теме, потому что он не касается электронного дизайна.
Привет, я хотел задать вопрос в stackoverflow, но я думаю, что люди там скажут, что это не вопрос программирования, хотя теги SPI и I2C встречаются в обеих группах. вы можете увидеть мой последний вопрос о протоколе UART в stackoverflow, а также положительные и отрицательные моменты, которые я получил, потому что люди там считают, что вопрос следует задавать на electronics.stackexchange.com, и именно поэтому я вчера открыл эту учетную запись.
Аппаратные протоколы низкого уровня, такие как SPI, IIC и CAN, имеют отношение к электротехнике, поэтому я думаю, что это здесь по теме, даже если конкретный вопрос является скорее теоретическим, а его ответ бессмысленным в практическом смысле.

Ответы (3)

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

если эти протоколы имеют свое определение уровня канала передачи данных внутри, это означает, что не я определяю, как заполняется кадр (комбинация адреса, данных и команд), это уже определено в SPI или I2C, например, первые 3 бита биты адреса, затем у нас есть 4 бита данных, затем снова у нас есть 2 бита адреса и т. д. но нигде в сети я не нашел эту информацию. не могли бы вы объяснить больше?
Эти отраслевые протоколы почти всегда содержат определения нескольких уровней, если не явно, то неявно, в предположении, что эти битовые форматы будут использоваться определенным образом. Настоящей проверкой того, является ли что-то вроде битового формата только уровнем данных, было бы показать, что несколько изолированных протоколов используют один и тот же уровень данных без изменений. Это случается редко, поскольку у каждого протокола есть определенные потребности, которые начинают просачиваться на уровни данных и физический уровень.

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

Как с SPI, так и с I2C можно перейти на более высокие уровни, если ограничить свое внимание конкретными стилями микросхем. Например, есть общий стандарт для I2C EEPROM до 2 Кбайт, а другой стандарт применим к I2C EEPROM до 512 Кбайт (хотя я не видел, чтобы его использовали в таких больших устройствах). Такие стандарты не только определяют, как выполнять транзакции на чипе, но и определяют, что чип будет делать с содержащимися в нем данными.

Ничего такого явного. Вы можете попытаться определить определенные части протокола I²C для разных уровней OSI, но то, как вы их определяете, и то, как их определяет кто-то другой, не будет совпадать (спросите пять инженеров и получите семь разных ответов).

Я считаю, что физический уровень самый простой. Для I²C требуются две линии шины с открытым коллектором, подключенные к V CC с подтягивающими резисторами со значением X, ограниченным емкостью Y пФ (где X и Y рассчитываются на основе желаемой частоты шины I²C). Устройства I²C должны освобождать линию, когда она простаивает, и переводить линию в низкий уровень только при активном обмене данными. Это физический уровень.

Слой данных немного сложнее. Мастера I²C, особенно в системе с несколькими мастерами, должны при попытке связи проверить, не опущены ли линии, если они свободны, попытаться установить связь, снова проверить линию. Если в какой-то момент он неожиданно упадет, следуйте арбитражным протоколам. Подчиненные устройства I²C (и ведущие устройства) также могут выполнять растягивание тактовых импульсов , контролируя обмен данными путем предотвращения тактовых импульсов.

Физическая и логическая адресация относится как к уровню канала передачи данных, так и к сетевому уровню, если вы включаете расширители шины/мультиплексоры/буферы/ИС с горячей заменой. I²C на самом деле не имеет сетевой топологии или IP- эквивалента, а расширители шины являются неспецифическим хакерским решением, которое придумали производители.

поэтому, когда я покупаю микроконтроллер с интерфейсом связи I²C и хочу подключить его к встроенному периферийному устройству, которое также имеет интерфейс I²C, через последовательные провода, я могу следовать определению схемы I²c (физический уровень), создавая две линии с указанными выше резисторами. , затем определите мой фрейм (адрес, данные, команду) с почти полной свободой, затем определите какую-то логику, которая выполняет арбитраж, квитирование, ... (материалы уровня канала передачи данных).
Читая ваше объяснение, мне кажется, что я спрашиваю: как определить модель OSI для параллельной цепи RLC? мой вопрос выглядит так? Спасибо
@ Мишель, нет, не полная свобода. Устройства i2c ожидают, что «кадр» будет стартовым, 7-битным адресом + 1 битным битом чтения/записи, n байтами данных, остановкой (или перезапуском).
Протоколы I²C, SPI, CAN и модель OSI
СпросиСетьПолитика конфиденциальности1y, 0v