Sziasztok!

Szeretnék egy I2C -re akasztani egy DS1631-et és egy DS1307-et.
A 1631-nek be is lehet állítani az I2C címét, de a 1307-nek nem, vagy legalább is az adatlapban nem láttam (lehet hogy vak vagyok). Egyáltalán lehet?
A kérdésem az lenne, hogy hogyan tudnám egy I2C buszon használni a két IC-t?
Előre is köszönöm!

Próbáld meg az 1101000 címet a DS1307 címeként. Az adatlap 12. oldalán említi ezt a kommunikáció példájában.

Elvileg ezeket nem kell állítani, mivel két külön funkciót ellátó egységről van szó, ezért a gyári címe is eltér.

DS1307 1101000 (adatlap 12.o.)
Bővebben: Link
DS1631 10010000 (adatlap 11.o.)Bővebben: Link
A DS1631-nél hardveresen tudod még választani a címet az A0 A1 A2 lábakkal. Ha mindhárom GND-re van kötve akkor a fent említett cím a jó (default).

Ha változtatni akarsz, akkor az Ax lábak valamelyikét, vagy mindet kösd tápra, ekkor a következőképpen alakul a dolog:

1001xxx0
A 3db x helyére helyettesítendő be az A2 A1 A0 lábak állapota, mégpedig, amelyiket tápra tetted az 1 amelyiket gnd-re az 0.
Tehát, ha mondjuk az A2 és A0 tápon az A1 gnd-n van akkor így néz ki: 10011010
(az utolsó bitet nem kell piszkálni, mert az jelzi sz eszköz felé az R/W szándékot)
:yes:

Köszi! Bejött a megérzésem, vak vagyok.
Halálra kerestem a lábait amin a címet be lehet állítani mint a 1631-nél, bér több egy buszon RTC valóban nem túl okos dolog.
ciw: bocsi, köszi az alapos leírást, de potyó gyorsabb volt...

Témacím kicsit igazítva.

Megnyugodtam, nem én vagyok vak. Megnéztem mégegyszer a datasheetet, ebben tényleg nem találom...

Ha nem vagyok Windisgraetz, most ezek közül melyik IC-hez nézeted a DS1302 adatlapot?

A kérdés nem rossz.
A dolog úgy indult, hogy DS1302 (soros) lesz, aztán jött az ötlet hogy az is mehet az I2C-re. 1307-el, az legalább van SMD-ben is.
A lényeg hogy most kell abbahagyni...... benéztem de rendesen.....

PIC16F877-tel I2c vonalon szeretnék egy 2402 eepromot irni, olvasni. A mintapéldában igy lettek beállitva a PIC SSP regiszterei. Valami nem stimmel, mert az SDA vonal folyamatosan magasban, az SCL vonal pedig folyamatosan alacsonyban van szkóppal figyelve. A START állapotba hozás sem történik meg.
Mi lehet az, amit elszúrok!

Sziasztok!
Remélem jó helyre írok.
Énis szeretnék több eszközt vezérelni i2c buszon, de az én esetemben az érdekesség,hogy a mikrovezérlőm 5v -ról megy ahogyan az i2c-s eszközeim nagy része is.A busz fel van húzva 2,2K val.
A kommunikáció tökéletes.Szeretnék további eszközt csatlakoztatni aminek a megengedett max feszültsége 3,3v .Ez az új eszköz egy komplett modul (MMA7455) ami tartalmaz egy 3,3v os feszstabot.A modulon a buszok felvannak húzva 4,7K val a 3,3v os VDD-re.Az a nagy kérdés,hogy én ezt ráköthetem e közvetlen a buszra szintillesztés nélkül ,és az ellenállásokat kicseréljem e.

Közvetlenül nyílván nem, viszont ha jól emlékszem a többi is magasnak veszi a jelet 3V felett és elég lehet akár a 3.3V az egész buszra, csak a modul által felhúzva.

Akkor kiiktassam az eddigi 5v ra húzást?

Az 5V-ra húzást igen. Esetleg szükség lehet 3,3V-ra húzásra, de ha az 5V-ra húzást kiveszed, és egy ampermérővel lehúzod az egyik vonalat GND-re, ha folyik mondjuk 1mA környéki áram, akkor jó lesz a modul felhúzása is.

Ha a 3V-ra felhúzással nem megy korrektül:
Bővebben: Link
an97055

Köszönöm. Közbe énis megleltem.
Sajnos ahogy nézegettem a moduljaimat(iránytű, gyorsulásmérő) az az észrevételem,hogy mindegyikre tettek 4,7k-s felhúzást, ami mondjuk 6 eszköznél nem valami szerencsés.
Szerintetek ezeket érdemes leforrasztani?

Hali!
Ha nem használod az an97055-öt akkor, az 5V-ra húzókat mindenféleképpen

Hi,

Úgy látom ez egy tipikus I2C sensor probléma!

Adott 32 darab gyroscope sensor (Bosch BMG160) I2C interfésszel. A sensorokat fizikailag egymás mellé szeretném sorba kötni, kb 10 cm-re egymástól. Erre az I2C bus tökéletesen megfelel.

A BMG160 és úgy látom minden más gyroscope sensor címtartománya 2 elemű, azaz összesen max 2 címet kaphat, ami 1101000b, vagy 1101001b. Tehát nem tudok 32 sensort megcímezni, csak 2-őt, mert címkonfliktus lenne.

Akkor hogyan? I2C címfordító nem létezik (address translator)? Chip, aminek a konfigurálható címtartománya 128, és ha megszólítom ezt a chipet, akkor a vele sorba kötött másik I2C chipet szólítja meg, de már az eredeti címen. Mint egy proxy.

Találtam I2C Address translation címen szabadalmat itt Bővebben: Link, de megvalósítást nem.


Ötlet?

Van neki csb bemenete, ez tág teret ad az elébe épített címdekódernek.Esetleg egy I2C buszos io egységgel egyesével címezheted az eszközöket, majd a kijelölteket simán olvashatod. Esetleg 4 bites bcd decimális dekóderrel is kiválaszthatod a soron következő kettőt.

Én úgy látom, mintha csak 1 címe lenne, és az utolsó bit a R/W-ot vezérli.

De nem ez a lényeg. A 32 db érzékelő 10 cm-enként, az kb. 3m-nyi I2C BUS-t eredményez. Egyes tapasztalatok szerint már néhányszor 10 cm is problémát okozhat, ha ezt a BUS-t nem építjük ki elég gondosan (reflexiók kerülése, lezárások).

Ezért, ha nekem kellene megvalósítanom, akkor abban gondolkodnék, hogy aZ I2C-t egyenként egy-egy mikrovezérlővel fogadnám, és ugyanezeknek a mikrovezérlőknek az USART-ját használnám a kommunikációra RS-485 buszon (pl. PIC16F690 és 75176). A 485 nagyobb távolságon is stabil (szimmetrikus!); a címzést vagy beégetném a programba, vagy inkább a többi lábat használnám a beállítására. Emellett kitalálnék egy olyan kommunikációs protokollt, ami a közös soros vonalon címzett csomagokkal kommunikál (van is ilyenem).

Esetleg ez az irány?
nxp i2c multiplexer

Lecsokkentett orajel (tavolsag miatt) es CS lab multiplexerrol hajtva?

Szia!
Az adatlap Tabla 14. szereint I2C módban a CSB láb nem használt. Az SDO pedig az I2C cím legalsó bitje (a R/W bit utáni). Arról nem ír az adatlap, hogy a szintet mikor értékeli ki. Ha menet közben is lehet változtatni és a program mindig az SDO alacsony szintjével kérdez és az összes érzékelőnek ezen lábán magas szint van, nem fog válaszolni egyik sem. Ha egy I2C prortbővítő (esetleg még egy dekóder segítségével) egyidőben mindig csak egy érzékelő SDO lába lesz alacsony, akkor az az érzékelő fog válaszonli.

Ez nem jó hír. Ez biztos így van? Igazából nem kell 32db, nem kell 10cm, de ha akarnám, nem működne?

És ha csak 1 cm-re kéne rakni, azt kibírná? Vagy az SPI? SPI nem bírja jobban? Jó lenne a 400KHz sebesség ha megmaradna. Bár 100KHz is elég, ha muszáj.

Címzésben akkor marad a multiplexálás, egy 3bit címzésű 2 csatornás multiplexer.

Szevasztok!
Egyenlőre csak Proteus/ISIS -ben próbálom szimulálni az I2C-t egy 18F4550 és két slave 18F252 között. A kezdeti nehézségek után a slave1-re már sikeresen tudok adatot küldeni, de csak egy bájtot pillanatnyilag, mivel a cím elküldése után, mikor az adatot kezdem küldeni, a slave2-nek megtelik a buffere és collision interruptot csinál. Ezután persze NAK-ot küld miegymás...
teljesen összekavarja a buszt. Interrupt a slave2-n csak akkor indul be ha cím egyezés van, egyébként a hardvernek kéne rendezni a dolgokat. Vagy rosszul gondolom? Valaki találkozott már ezzel a problémával? Vajon honnan kelle tudnia a slave2-nek hogy ha nem neki lett küldve egy cím akkor az utána következő adato(ka)t ne vizsgálgassa? És meddig nem fogja vizsgálni? Sőt! Mi van ha egy másik slave-nek címzett adatbájt az ő címét tartalmazza véletlenül? Gyanítom ez(eke)t külön kellene leprogramozni, mert a hardveres rész ezzel nem nagyon foglalkozik... És leírást sem nagyon találtam 1master és 2slave pic felállásra. Olyan szörnyű érzésem van hogy valamit nagyon félreértettem és tök egyszerű a megoldás a dologra. De egyenlőre csak szenvedek vele. Valaki át tudna lökni a holtponton? Előre is köszönöm a segítséget!!!

Az I2C azért busz, mert hogy eleve arra készült, hogy több eszköz legyen rajta. Hardver csak akkor rendezi, ha célhardver van rajta, de neked programmal kell megoldanod, hogy csak akkor figyeljen, ha csak a saját címe jön.

Ha az I2C buszon egy ciklus kezdődik, a buszon a START állapot jelzi. A START után a címzés történik. Ha a slave a saját címét érzékeli, veszi a további adatokat, ha a parancs kiolvasás volt, az adatot (adatokat) elküldi. A buszciklus a STOP állapottal zárul. Ha a slave nem a saját címét érzékeli, a további adatokat vennie sazbad, de nem szabad értelmezni. Ha nem veszi át a nem neki szóló adatokat, akkor le kell kezelnie a adatráfutás hibát. Figyelni kell a STOP állapotot. A STOP után várakozni kell az újabb ciklusra.

Az I2C-s kommunikációt, először próbáld ki egyszerű szolgával, mégha szimulációban is. Így könnyebben eldöntöd melyik oldal nem OK. A start feltétel és az összeg ide tertozó rutin a Modulrendszerű PIC programozás topicban 2008,05.16 hsz-ban ott van. Ebben is találhatsz segítséget...Ezek a gyakorlatban jelenleg is futnak...

Köszönöm a válaszokat!
Sikerült működésre bírnom végül. A probléma a túlcsordulás kezelésével (azaz esetemben nem-kezelésével, illetve a clock stretching-el volt) Azért leírom a működést, hátha tudtok elegánsabb megoldást is. A master start-al kezd. mindkét slave PIC veszi a címet. A címzett természetesen felismeri hogy neki szól és rendesen kezeli tovább a dolgot. A másik slave eddig mindíg beleszólt a cím utáni adatbájtba, mivel a cím utáni 9. órajeltől kezdve ő már elkezdte beolvasni a következő bájtot mindenféle megszakítás nélkül (amiben esetleg megakadályozhattam volna ezt egy buffer ürítéssel) mert az csak cím egyezés estén indul. A buffer feltöltődése után mivel a clock stretching be volt állítva ő bőszen megakadályozta a további kommunikációt a 2. bájt mínusz 1bit kiküldése után. Mivel az interrupt-om nem kezelte a SSPOV -bitet, így a kommunikáció leállt. Tehát először is lekezeltem a túlcsordulást, aztán mivel így még mindíg szaggatott, rájöttem hogy a clock stretching-et is ki lehet kapcsolni az íráshoz, ha olvasni akarok a slave-ből úgy is automatikusan megy. így minden sikeresen továbbított adatbájtnál (illetve azelőtt egy bit-tel) a nem címzett slave is interrupt-ol egyszer, de az hipp-hopp lefut az SSPOV ellenőrzésével és közben amúgy is minden megy tovább a másikkal. Gyanítom ez a normális menet, ennél joban csak teljes szoftveres I2C-vel vagy Start-stop jelre aktiválódó interrupttal lehetne esetleg... de örülök hogy így megy, nem nyomorgatom tovább.

Sziasztok!

Szerintetek megoldható lenne-e egy AVR mikrovezérlővel vagy esetleg egy Arduinoval beavatkozzak egy I2C kommunikációba és módosítsam az azon futó adatokat?

Van egy központi rendszerem, ami most a master és egy periféria IC a slave az I2C buszon.
Arra gondoltam, hogy megszakítom a kapcsolatot és közéjük teszek egy AVR-t. Mondjuk az AVR hardveres I2C busza lenne a master a periféria felé és egy szoftveres I2C busz másik két lábon pedig lenne slave a központ felé.
A feladat az lenne, hogy a központi rendszer által a perifériából kiolvasott adatokat megszűrjem: kiértékelés alapján bizonyos adatokat változatlan formában küldenék tovább a központnak, más adatokat pedig megváltoztatva.

Szerintetek ez így működhet egy AVR mikrovezérlővel?

Működhet. Akkor lehet probléma, ha a mostani mester méri az időt, mennyi idő alatt jön vissza az adat.