Кто-нибудь когда-либо разбивал I2C на два микроконтроллера?

Question

Итак, у меня есть эта дикая идея, чтобы попытаться разделить реализацию контроллера I2C на двух микроконтроллерах. То есть, один uC управляет SDA, а один uC управляет SCL и связывается как одно устройство I2C на шине, ведущем или ведомом. Я не пытаюсь просто выполнять базовые коммуникации I2C здесь, я хочу, чтобы два физически отдельных контроллера работали вместе как один интерфейс I2C.

Любой, кто когда-либо делает что-либо подобное, может предложить, как я могу это сделать?

Я предполагаю, что мои отдельные контроллеры SDA и SCL должны быть бит-удары, для начала, но я не уверен относительно остальных. Какую межпроцессорную связь вы бы использовали? SPI на много более высокая скорость кажется местом для начала. Насколько вероятно, что это сработает, и какую производительность можно ожидать от такой системы? Может быть, это возможно на несколько сотен Гц, может быть?

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

Answer 1

Предполагая, что у вас есть причина, по которой это нужно сделать, даже если это «для удовольствия» или «просто потому, что оно есть» (зачем подниматься по горе, когда вы можете обойти).

Посмотрите, как работает I2C. Оба должны будут наблюдать за сигналами друг друга (или каким-либо другим способом для синхронизации), если у вас есть SDA (владелец этого сигнала), наблюдающий за SCL и наоборот. Посмотрите на требования к форме волны, если оба начинают высоко, тогда SDA падает, владелец SCL видит это и бросает SCL, владелец sda видит это и утверждает первый бит. Теперь у нас уже проблемы. Если первый бит равен нулю, владелец SCL не знает, установил ли SDA бит, поэтому он не может поднять SCL, чтобы синхронизировать его. Там должно быть больше информации. Владельцам SDA и SCL придется согласиться с некоторыми правилами, когда SCL становится низким, владелец SDA должен согласиться изменить свое состояние, если оно собирается, в каком-то окне. SCL должен согласиться не изменять свое состояние до этого окна. Затем SDA может видеть, что SCL идет высоко, а затем низко. И повторяй. Или пойти с SCL не может превышать максимальную скорость для I2C или для этого периферийного устройства, и SDA живет внутри этого. SDA может быть доволен изменением бит до ACK, если SCL находится в пределах спецификации для этого периферийного устройства и/или I2C, тогда это нормально (что верно даже без этой двух схем владельца). Ваша настоящая проблема возникает, когда вы хотите остановиться, как SCL знает, что SDA сделала то, что ему нужно было делать, и подняться высоко и остаться на высоком уровне? Таким образом, SDA может подниматься высоко и оставаться высоко, и SCL возвращается в режим ожидания SDA, чтобы начать старт. Вам нужен по крайней мере еще один сигнал между ними, который не является частью i2c, и вам нужно это другое соглашение о том, что SCL идет не быстрее, чем X и SDA соответствуют этому (возможно, произвольное состояние SCL идет с максимальной скоростью, потому что, возможно, SDA не может продолжать с этим, возможно, периферийное устройство может, но, возможно, SDA не может, поэтому ваш дизайн системы должен покрыть это).

Далеко, проще всего сделать это с одним владельцем обоих сигналов. Технически, хотя это возможно, оно не дает вам ничего, кроме интересного дизайна системы. Люди, которые могут масштабировать скальные лица, имеют опыт над теми, кто просто идет по горам.

Возможно, без третьего сигнала у вас может быть состояние изменения SDA в два раза быстрее, чем согласованная тактовая частота I2C. SCL мог видеть это как признак того, что вы хотите сделать остановку. SCL затем поднимается высоко до высокого уровня, пока он не увидит SDA, а затем опустится низко, указывая на другой старт.

Im пытается решить, должен ли SCL оставаться там, можете ли вы просто использовать бесплатные часы для SCL, и SDA - это единственное, что принимает решения? Идите низко, дождитесь, пока SCL пойдет высоко (SDA все еще должен смотреть SCL), затем пойдите высоко, создав STOP. Оставайтесь на высоком уровне, и вы не создаете ни остановки, ни старта.Подождите, пока SCL высока, а затем опуститесь, вы создаете старт, наблюдаете за scl, чтобы управлять sda через транзакцию, создайте остановку в нужное время, я думаю, что она будет работать до тех пор, пока она не путает дизайн периферии. Возможно, спецификация говорит об этом, но это лишь незначительно актуально, как в I2C и SPI, часто спецификация игнорируется периферийными устройствами. Периферия, о которой идет речь, доминирует, так как именно с которой вы действительно хотите поговорить. Поэтому я думаю, что владелец SCL может быть таким же глупым, как просто источник синхронизации, без какой-либо другой логики.