A frequência mista I2C é possível?

Suponha que tenhamos um barramento I ² C de 400 kHz . Há um mestre e vários dispositivos escravos. Gostaríamos de apresentar mais um dispositivo escravo, mas infelizmente ele só chega a 100 kHz.

Claramente, as opções sólidas de design são:

• basta rodar esse barramento a 100 kHz
• use barramentos separados para os periféricos de 400 kHz e 100 kHz

Mas a questão é apenas sobre um hack: e se usarmos um barramento, abordarmos os dispositivos de 400 kHz a 400 kHz e mudarmos o barramento para 100 kHz quando falar com o escravo de 100 kHz?

Ou o escravo mais lento poderia se comportar mal em resposta ao hash de 400 kHz que vê no I ² linhas C porque pensa erroneamente que está sendo abordado?

Podemos depender de dispositivos de 100 kHz para ainda poder processar o sinal I ² C de 400 kHz o suficiente para ignorar com segurança as mensagens endereçadas a outros escravos?

Como você sugere, fazer isso não é uma boa prática de engenharia. Enquanto alguns dispositivos ignoram o tráfego que eles não conseguem receber (subamostra), outros podem atrapalhar o barramento com quadros incorretos.

Portanto, a resposta que você procura depende das especificidades do seu aplicativo, como:

• comprimento de suas conexões I2C
• valor dos resistores pull-up
• compatibilidade do dispositivo

Obviamente, é difícil prever o que aconteceria com um dispositivo operado fora das especificações daqui a alguns anos.

Outra opção é executar uma linha de desligamento para diminuir a velocidade dos dispositivos ou passar a linha do relógio (desde que eles não possam gerar sinal de relógio) através de um portão AND.

Outra opção, se você não tiver um barramento I2C adicional saindo do seu mestre, é usar um comutador I2C, como o PCA9543A / 43B . Coloque os escravos de 400kHz em um ramo e os escravos de 100kHz no outro e troque-o conforme necessário.

Não há garantia de que o dispositivo de 100kHz não se comporte mal quando exposto ao tráfego de 400kHz - tudo, desde NACKs a interrupções de barramento, é possível.

Você deve executar o barramento inteiro a 100kHz ou ter um barramento de baixa velocidade separado para o periférico lento.

Outras opções. Em vez de ter dois barramentos, você pode simplesmente usar uma linha extra (mais fácil com um software / bitbang I ² C). Uma linha de relógio separada ou uma linha de dados separada. Ou use um buffer I ² C ou ^um switch I ² C para colocar esse único chip de 100 MHz em seu próprio segmento, sem ter que mudar mais nada.

Ou apenas teste-o em um único barramento. É bem possível que o chip de 100kHz afete a linha. Ele poderia ler todos os 4 bits e acabar pensando que foi resolvido. Mas ele precisaria ver uma condição de início válida e, em seguida, ler todos os 4 bits dos próximos 32 bits como seu endereço exato; então, seria necessário tentar ler os próximos dois bytes como informações válidas para gravar nos registros. ou tente fazer o clock dos dados. Não acho que seja uma situação muito provável. A melhor aposta é conectá-lo em um circuito de teste e verificá-lo.

Duas coisas a serem observadas: se esse é um circuito único ou se você está fazendo apenas alguns, é fácil arriscar ou mudar. Se for um item produzido em massa, convém ter o segundo ônibus. O outro é que você deve considerar que o chip de 100kHz foi produzido simplesmente com a especificação I ² C original e pode muito bem suportar velocidades de clock mais altas. Simplesmente não foi testado para as especificações de 400kHz de velocidade mais alta.

O design do barramento I2C é tal que -

1. quando ocorre uma borda descendente no SCL, isso pode fazer com que um dispositivo escravo afirme imediatamente o SDA, sem nenhum atraso mínimo específico;
2. a ordenação relativa das arestas ascendentes e descendentes é de importância crítica.

Por causa da diferença na força do driver e na capacitância da linha, seria teoricamente possível que um dispositivo pudesse responder a uma queda lenta no SCL, dirigindo o SDA tão rápido que outro dispositivo veria o SDA cair primeiro.

Pode ter sido possível definir vários limites lógicos no SCL e especificar que, para que uma borda em queda no SCL seja considerada após uma borda na SDA, ainda deve estar acima de 2/3 VDD quando a borda na SDA for detectada, mas um dispositivo não pode declarar SDA em resposta a uma margem decrescente no SCL até cair abaixo de 1/3 do VDD, mas as especificações não estão escritas nesses termos.

Em vez disso, os dispositivos que vêem bordas descendentes quase simultâneas no SDA e no SCL geralmente consideram que o edge no SCL aconteceu primeiro, a menos que seja substancialmente precedido pelo edge no SDA. Algumas implementações de I2C lidam com isso sincronizando o SCL e o SDA com algum relógio externo e exigindo que uma borda decrescente do SDA seja observada dois períodos antes do SCL para que seja considerado o primeiro. Se a velocidade das operações no SCL e SDA for muito rápida em relação ao relógio de sincronização, os dispositivos poderão perceber sequências arbitrárias de sinais altos e baixos no SCL e SDA; se uma dessas seqüências parecer endereçar o dispositivo lento, ela poderá reagir de acordo, esmagando qualquer outra comunicação que possa estar acontecendo.

Não há nenhuma razão específica para que os dispositivos em um barramento I2C precisem confiar na sincronização com um relógio do sistema (ser capaz de detectar dois limites discretos no SCL seria melhor), mas o fato é que alguns dispositivos funcionam dessa maneira. Observe que, mesmo que um dispositivo limitado a baixas velocidades internamente quisesse coexistir com um barramento rápido, provavelmente teria que empregar no mínimo um relógio que esticasse a qualquer momento em que algo estivesse acontecendo no qual pudesse estar interessado.

Isso faria com que algumas comunicações ocorressem mais lentamente do que poderiam, mas a degradação da velocidade provavelmente não seria tão ruim quanto é necessária no design sincronizado com relógio (a quantidade real pela qual o dispositivo lento estica os relógios provavelmente não seja tão ruim quanto a quantidade pela qual o relógio deve ser mais lento para evitar falhas nos piores cenários das unidades de relógio sincronizadas).