Três armadilhas no I2C que todos gostariam que não existissem

A melhor parte do I2C é que ele é um barramento que está disponível em praticamente qualquer lugar, cobrindo um vasto ecossistema de dispositivos que o oferecem como uma interface definida por hardware, ao mesmo tempo que é descomplicado o suficiente para também poder ser implementado puramente em software em GPIO simples. pinos. Apesar dessa popularidade, o I2C é um daqueles padrões informais famosos que apresentam algumas implementações populares, deixando muitos detalhes, como tempo exato, capacitância do barramento e outros detalhes tediosos, para o pobre coitado que desenvolve o produto. É assim que terminamos com artigos como um recente no blog de trava-línguas [par de peras], cobrindo problemas encontrados durante a implementação de um escravo I2C.

Como acontece com qualquer barramento compartilhado, seja multimaster ou não, descobrir quando o barramento está livre é um assunto divertido, mas que pode causar dores de cabeça intermináveis. Um problema aqui vem de um recurso que a versão SMBus do I2C chama de leitura/gravação rápida. Isso permite a transferência rápida de alguns dados. Ainda assim, dependendo dos dados retornados pelo escravo, pode parecer ao mestre que nada está acontecendo ainda, uma vez que o SDA está sendo mantido baixo pelo escravo até a condição de parada, essencialmente travando o barramento.

As coisas ficam ainda mais emocionantes geralmente na forma do que os analisadores lógicos adoram chamar traumaticamente de “condição de início/parada espúria”. Isso se refere ao comportamento do SDA e do SCL, com o SDA diminuindo antes do SCL, indicando um erro. Isso pode ocorrer devido a um tempo de espera muito baixo, fazendo com que outros dispositivos no barramento percam a transição. Aqui o SMBus define um tempo de transição de 300 ns, enquanto o I2C chama por 0 segundos, mas agora é sugerido atrasar a chamada de uma condição de início/parada até que um atraso de 300 ns tenha passado. Essencialmente, parece que a implementação de um tempo de espera é o caminho a seguir até que apareçam provas em contrário.

A terceira armadilha diz respeito aos modos de alta velocidade do I2C, incluindo Fast-Mode (FM) e Fast-Mode Plus (FM+). A compatibilidade com versões anteriores com essas versões de alta velocidade é ausente ou irregular. Embora o FM+ (introduzido pela NXP em 2007) deva ser compatível com versões anteriores com velocidades mais lentas, efetivamente as diferenças nos requisitos de tempo entre os padrões FM+ e FM são grandes demais para serem compensadas. Pelo menos nas versões atuais dos padrões, uma das alegrias do I2C é que sempre há outro novo conjunto de revisões pelas quais ansiar.