I2C karışık frekansı mümkün mü?


12

Diyelim ki 400 kHz I 2 C veriyolumuz var. Bir efendi ve bir grup köle cihazı var. Bir köle cihazı daha tanıtmak istiyoruz, ancak maalesef sadece 100 kHz'e gidiyor.

Açıkça, sağlam tasarım seçenekleri:

  • o otobüsü 100 kHz'de çalıştır
  • 400 kHz ve 100 kHz çevre birimleri için ayrı veri yolları kullanın

Ancak soru sadece bir hack'le ilgili: bir veri yolu kullanırsak ve 400 kHz cihazlarda 400 kHz cihazlara hitap edersek ve 100 kHz slave ile konuşurken otobüsü 100 kHz olarak değiştirirsek?

Veya daha yavaş köle, I 2 C hatlarında gördüğü 400 kHz hash'a yanıt olarak yanlış davranabilir mi, çünkü yanlışlıkla ele alındığını düşünüyor mu?

400 kHz I 2 C sinyalini diğer slave'lere yönelik mesajları güvenilir bir şekilde göz ardı etmek için yeterince iyi işleyebilmek için 100 kHz cihazlara güvenebilir miyiz ?


4
Son cümlenizle ilgili olarak, 100kHz cihazların 400kHz sinyalleri işleyebileceğine güvenebileceğinizi düşünmüyorum.
gbmhunter

Yine de, böyle bir hack uygularsak, tam olarak buna bağlıyız, bu yüzden temelde söz konusu değil.
Kaz

Yanıtlar:


7

Önerdiğiniz gibi, bunu yapmak iyi bir mühendislik uygulaması değildir. Bazı cihazlar alamadıkları trafiği (alt örnek) görmezden gelse de, diğer cihazlar veri yolunu hatalı çerçevelerle karıştırabilir.

Bu nedenle, aradığınız cevap, uygulamanızın özelliklerine bağlıdır:

  • I2C bağlantılarınızın uzunluğu
  • çekme direnç değeri
  • cihaz uyumluluğu

Tabii ki, yolda birkaç yıl boyunca özelliklerinin dışında çalışan bir cihaza ne olacağını tahmin etmek zor.

Başka bir seçenek, cihazları yavaşlatmak için bir kapatma hattı çalıştırmak veya saat hattını (saat sinyali üretemedikleri takdirde) AND geçidinden geçirmektir.


10

Başka bir seçenek, master'ınızdan çıkan ek bir I2C veri yolunuz yoksa , PCA9543A / 43B gibi bir I2C anahtarı kullanmaktır . 400kHz slave'leri bir dalda, 100kHz slave'leri diğer dalda yerleştirin ve gerekirse değiştirin.


Philips'in (yaratıcısı) söylediklerine bakarsanız, tam olarak budur. Uyumlu değiller ve bir otobüs anahtarı önerilen çözümdür. (Bir uygulama notunda).
gbarry

6

100kHz cihazın 400kHz trafiğe maruz kaldığında yanlış davranmayacağının garantisi yoktur - NACK'lerden otobüs duraklarına kadar her şey mümkündür.

Tüm veri yolunu 100kHz'de çalıştırmalı veya yavaş çevre biriminiz için ayrı bir düşük hızlı veri yoluna sahip olmalısınız.


3

Diğer seçenekler. İki veri yolu yerine, bir ekstra satır kullanabilirsiniz (Bir yazılım / bitbanged I 2 C ile daha kolay ). Ayrı bir saat hattı veya ayrı bir veri hattı. Veya tek bir 100MHz yongayı başka bir şey değiştirmek zorunda kalmadan kendi segmentine koymak için bir I 2 C tamponu veya I 2 C anahtarı kullanın.

Ya da sadece tek bir otobüste test edin. 100kHz çipin hattı etkilemesi oldukça olasıdır. Her 4. biti okuyabilir ve ele alındığını düşünebilir. Ancak geçerli bir başlangıç ​​koşulu görmeli ve sonraki 32 bitin her 4 bitini tam adres olarak okumalıdır, o zaman ya sonraki bayt çiftini kayıtlarına yazmak için geçerli bilgi olarak okumayı dener. veya verileri zaman aşımına uğratmaya çalışın. Bunun çok muhtemel bir durum olduğunu düşünmüyorum. En iyi seçenek basitçe bir test devresine bağlamak ve kontrol etmektir.

Dikkat edilmesi gereken iki şey, eğer bu bir kapalı devre ise veya sadece birkaç tane yapıyorsanız, risk almak veya değiştirmek için yeterince kolaydır. Kitlesel olarak üretilen bir ürünse, ikinci otobüse sahip olmak isteyebilirsiniz. Diğeri, 100kHz çipin orijinal I 2 C spesifikasyonuna göre üretildiğini ve daha yüksek saat hızlarını çok iyi destekleyebileceğini düşünmeniz gerektiğidir . Daha yüksek 400kHz spesifikasyona göre test edilmedi.


2

I2C otobüsünün tasarımı öyle ki -

  1. SCL'de bir düşme kenarı meydana geldiğinde, bu, bir bağımlı cihazın herhangi bir minimum gecikme olmaksızın derhal SDA'yı iddia etmesine neden olabilir;
  2. yükselen ve düşen kenarların göreceli sıralanması kritik öneme sahiptir.

Sürücü gücü ve hat kapasitansındaki farktan ötürü, bir cihazın SDA'yı o kadar hızlı sürerek SCL üzerinde biraz yavaş düşen bir kenara tepki vermesi teorik olarak mümkün olacaktır.

SCL'de birden çok mantık eşiği tanımlamak ve SCL'deki düşen bir kenarın SDA'daki bir kenardan sonra geldiği kabul edilmesi için, SDA'daki kenar algılandığında hala 2/3 VDD'nin üzerinde olması gerektiğini belirtmiş olabilir, ancak bir cihaz, 1/3 VDD'nin altına düşene kadar SCL'deki düşen bir kenara yanıt olarak SDA'yı iddia edemez, ancak spesifikasyon bu şartlarda yazılmaz.

Bunun yerine, SDA ve SCL'de eşzamanlı olarak düşen kenarları gören cihazlar, SDA'nın kenarından büyük ölçüde önce olmadıkça, genellikle SCL'deki kenarı ilk önce gerçekleşmiş olarak görür. Bazı I2C uygulamaları, SCL ve SDA'yı bazı harici saatlerle senkronize ederek ve SDA'nın düşen bir kenarının SCL'den iki dönem önce gözlemlenmesini gerektirerek bunu gerçekleştirir. SCL ve SDA'daki işlemlerin hızı senkronizasyon saatine göre çok yüksekse, cihazlar SCL ve SDA'daki keyfi yüksek ve düşük sinyal dizilerini algılayabilir; bu sekanslardan biri yavaş cihaza hitap ediyor gibi görünüyorsa, buna uygun olarak tepki verebilir ve devam eden diğer iletişimleri ezebilir.

Bir I2C veriyolundaki cihazların bir sistem saatiyle senkronize edilmesi gerektiğine dair özel bir neden yoktur (SCL üzerindeki iki ayrı eşiği algılamak daha iyi olurdu), ancak gerçek şu ki bazı cihazlar aslında bu şekilde çalışır. Dahili olarak düşük hızlarla sınırlı bir cihaz hızlı bir veri yolu ile bir arada bulunmak istese bile, en azından ilgilendiği bir şey olduğunda en azından saatin kullanılması gerektiğini unutmayın.

Bu, bazı iletişimlerin aksi takdirde olabileceğinden daha yavaş gerçekleşmesine neden olur, ancak hızın bozulması muhtemelen saat senkronize tasarımda gerektiği kadar kötü olmaz (yavaş cihazın saatlerini uzattığı gerçek miktar muhtemelen senkronize saat birimlerinde en kötü senaryo arızalarını önlemek için saatin yavaşlatılması gereken miktar kadar kötü).

Sitemizi kullandığınızda şunları okuyup anladığınızı kabul etmiş olursunuz: Çerez Politikası ve Gizlilik Politikası.
Licensed under cc by-sa 3.0 with attribution required.