I2C gyorsulásmérő (MXC6202xJV)

Szike

herc1234 írta:hát persze
azért ad nullákat vissza (jobb esetben )
mert nincs közte waitms 2 vagy 3
nincs ideje betölteni a verembe

Jó lenne ha igazad lenne, de kipróbálni legközelebb sajnos csak vasárnap tudom. Amúgy szerintem ha pár milisecen múlna, akkor lassabb buszsebesség mellett javult volna a helyzet (I2delay volt már 5,10,20 sőt már 200 is) de nem segített.

nobody_hun

A fordítási hibákért, magyartalanságért előre is elnézést:

Kód: Egész kijelölése

1. lépés:
I2C START-ot követően meg kell szólítani a chip-et a slave címen, írásra.
Ez a cím: 0010xxx (8. SCL lépésban az SDA maradjon alacsony).
XXX gyárilag programozott.

{saját megjegyzésem}
I2C címek:
MXC6202 0 = 20H
MXC6202 1 = 22H
MXC6202 2 = 24H
MXC6202 3 = 26H
MXC6202 4 = 28H
MXC6202 5 = 2AH
MXC6202 6 = 2CH
MXC6202 7 = 2EH
{/saját megjegyzésem}

2. lépés:
Miután a chip egy ACK jelet kap a master-től (MEMSIC egység az SDA-t lehúzza a 9. SCL impulzuskor), a masternek küldenie kell egy 00000000, jelezvén, hogy a címre (I2C hw cím) írni szeretne.
A MEMSIC egység ekkor küld egy ACK jelet a masternek (9. SCL impulzus).
Megjegyzés: mivel a MEMSIC egység csak egyetlen belső regiszterrel rendelkezik, amibe írni lehet, a felhasználónak mindig jeleznie kell 00000000-val, hogy ez az írási cím.

3. lépés:
A masternek küldenie kell egy felébresztő jelet a MEMSIC egység xxxxxxx0 belső memóriájába.
A MEMSIC egység erre válaszol egy ACK jellel.
Egy STOP utasítással jelezni kell, hogy befejeződött az írási művelet.
Egy (tipikusan) 100mS várakozási periódust követően a MEMSIC egység visszatér alvó üzemmódba.
A késleltetés ideje függ a MEMSIC egység tipusától. Általánosságban elmondható, hogy az alacsony fogyasztású termékeknek nagyobb feléledési időre van szükségük.

4. lépés:
A master küld egy START utasítást, meghívva a MEMSIC egység címét (I2C hw cím), WRITE utasítással (8. SCL lépésban az SDA maradjon alacsony).
Ezt a MEMSIC egység egy ACK jellel nyugtázza a végén.

5. lépés:
A master egy 00000000-t ír a MEMSIC egységbe, amivel azt jelzi, hogy milyen kezdő memória címről akar olvasni.
Mivel a 00000000 a belső vezérlő regiszter címe, erről a címről olvasva ellenőrizni lehet a működést, valamint, hogy az írás megtörtént-e.
Megjegyzés: a kiinduló cím alapvetően az 5 cím bármelyike lehet. Például a felhasználó kezdheti a kiolvasást a 00000001 címről is, amely az X csatorna MSB byte-ja.

6. lépés:
A master küld egy READ utasítást (8. SCL lépésban az SDA értéke magas)
Ezt a MEMSIC egy ACK-el nyugtázza a vételt.

7. lépés:
A master az SCL léptetésével az elsőként megcímzett memória adata megjelenik az SDA-n.
(magyarul, az elsőként megcímzett memória címen levő adatot kiolvassa a master. Lásd 5. lépés).
Ha ez az adat 00000000, akkor a belső vezérlő regiszter adata jelenik meg.
A master egy ACK-el nyugtázza a vételt.

8. lépés:
A master folytatja az SCL változtatását, a belső memória következő bájtja megjelenik az SDA-n.
(X csatorna MSB). A belső memória mutatója automatikusan a következő címre lép.
A master a vételt egy ACK-el nyugtázza.

9. lépés:
Az X csatorna LSB-je. Ha a belső regiszter TOEN bitje 1-re van állítva, akkor az utolsó két lépésben a TOUT (hőmérséklet) MSB és LSB értéke jelenik meg.

10. lépés:
Az Y csatorna MSB-je.

11. lépés:
Az Y csatorna LSB-je.
A master befejezi a kommunikációt egy NO ACK-el és egy STOP utasítással.
Megjegyzés: ha a master folytatja a kiolvasást az SCL változtatásával, akkor a memória mutatója tovább lép a hatodik és hetedik pozícióra, amely mindig 00000000 ad vissza.
A hetedik pozíció után a mutató ismét nullára lép vissza.

Opcionálisan:
A master készenléti állapotba kapcsolhatja a MEMSIC egységet azzal, hogy ír a belső regiszterébe. Lásd 1-4 lépéseket az írási művelethez.

Szike

Nagyon szépen köszönöm a fáradtságod.
Egyetlen apró hibát találtam benne:

nobody_hun írta:Egy (tipikusan) 100mS várakozási periódust követően a MEMSIC egység visszatér alvó üzemmódba.

Én inkább úgy értelmezem: visszatér alvó üzemmódbÓL.
És ha lefordítjuk BASCOM-ra a dolgot, akkor szerintem már az első kódnak is kellett volna működnie ( kivéve a 'I2cwbyte Slave , 0' sor, mert itt korábban 'I2csend Slave, 0' volt, amit figyelmetlenül javítottam ki.)
A második kód - amit a linkelt C program alapján raktunk itt össze - viszont elvileg hibátlan:

Kód: Egész kijelölése

I2cinit
I2cstart
i2cwbyte &H10
i2cwbyte 0
i2cwbyte 0
waitms 50
i2cstop
waitms 100     'Adatlap szerint 100ms kell ébredéshez
I2cstart
i2cwbyte &H10
i2cwbyte 0      'ez az első (állapot) regiszter, ha 1-et írok akkor az X MSB-vel kezdi
'ide tényleg kell még egy start???
i2crbyte adat1,ack
i2crbyte adat2,ack
i2crbyte adat3,ack
i2crbyte adat4,ack
i2crbyte adat5,nack
i2cstop

Vagy az van, hogy nem látom a fától az erdészt, és még magyarul sem veszem észre mit hagytam ki.
Mégegyszer köszi![/code]

herc1234

frnakón chaten most elmagyaráznám hogy szerintem miért...
a waiten múlik de nem az i2c slave a bünös hanem az avr
müködési mechanizmusa

nobody_hun

A várakozással kapcs. igazad van.

Szerintem nem csak a wait a bűnös, a hardver cím sem 10h.

Itt van egy Xilinx-es megoldás ugyanezzel a chip-pel, a forrást megnézve (accelerometers.xc) a fizikai cím 20h:
xlinkers.org/forum/viewtopic.php?f=8&t=57

"#define iicAddress 0x20"

Ezt igazolja az is, hogy ha binárisra alakítjuk az adatlap címeit, akkor ezt kapjuk:
MXC6202 0 = 20H = 0010 0000
MXC6202 1 = 22H = 0010 0010
MXC6202 2 = 24H = 0010 0100
MXC6202 3 = 26H = 0010 0110
MXC6202 4 = 28H = 0010 1000
MXC6202 5 = 2AH = 0010 1010
MXC6202 6 = 2CH = 0010 1100
MXC6202 7 = 2EH = 0010 1110

Az első 4 bit megegyezik az adatlapban írottal, a 8. bit pedig az írás olvasás (írás=0, olvasás=1).

Ezért nem jó a Szike által írt kód, mert az első 5 lépésben a H20-on kell kommunikálni a chip-pel, a 6. lépésben viszont már a H21-en ("A master küld egy READ utasítást (8. SCL lépésban az SDA értéke magas)").

Szike

Ok srácok, köszönöm!
Amint lehet ki fogom próbálni, és mindenképp tudatom veletek az eredményt.
Ez a 8. bit valóban elkerülte a figyelmem, de a hatodik lépésnél már nem is olvastam a zárójeles részt, mert gondoltam az I2C kommunikációs protokollját taglalja, amit ugye hardver szinten lekezel az AVR.
Kezdő vagyok még, és az arduinos példa is megkavart rendesen.
Köszönöm mindenkitől, hogy ilyen türelmesen válaszoltok!

Szike

Sziasztok!
Hazaértem, és kipróbáltam az általatok javasolt dolgokat.
Mindenek előtt egy hatalmas hibát fedeztem fel az egészben, konkrétan azt, hogy a SCL és SDA lábakat én nem állíthatom ahová csak akarom, hanem az Attiny45 lábkiosztását kell használni, vagyis a PB0 - SDA, PB2 -SCL. Hiába, kezdő vagyok.
Átalakítottam tehát a hardware-t, majd a software-t. Minden i2c művelet után tettem egy waitms 3-at, és olvasási címet is adtam.
Jelenleg ott tartok, hogy a &H20-as címre ha írok, akkor hiba nélkül teszi. Elvileg feléled a chip, beírom a kezdő regisztert, és utána kiírom az olvasási címet, de ez már hibát ad vissza.

Kód: Egész kijelölése

I2cinit
I2cstart
I2cwbyte &H20
'Waitms 3
If Err = 0 Then
   I2cwbyte 0
   waitms 3
   I2cwbyte 0
   Waitms 50
   I2cstop
   Waitms 100

   I2cstart
   waitms 3
   I2cwbyte &H20
   Waitms 3
   I2cwbyte 1
   Waitms 3
   I2cwbyte &H21
   '***itt már Err = 1***
   Waitms 3
   I2crbyte adat1 , Ack
   waitms 3
   I2crbyte adat2 , Ack
   waitms 3
   I2crbyte adat3 , Ack
   waitms 3
   I2crbyte adat4 , Nack
   waitms 3
   I2cstop
End if

[/code]

Az SCL/SDA bárhol lehet, mert a Bascomban alapesetben szoftveres szimulációval történik az I2C kezelése.

Kivéve, ha a HW-es TWI library-ra hivatkozol....
Config SCL= bármi
Config SDA= bármi

Szike

Robert írta:Az SCL/SDA bárhol lehet, mert a Bascomban alapesetben szoftveres szimulációval történik az I2C kezelése.

Kivéve, ha a HW-es TWI library-ra hivatkozol....
Config SCL= bármi
Config SDA= bármi

Az az igazság, hogy semmilyen lib-re nem hivatkozom. Ez is lehet egy hiba.
De ezt találtam, ami alapján gondoltam, hogy itt szúrtam el a dolgot.
Szóval hardwares TWI-hez mindenképp meg kell adni lib-et?
Szerk:
Rájöttem hogy (szerintem) a Attiny45 nem támogatja a HW TWI-t, így a fenti kérdés hülyeség, de az is lehet hogy most tévedek!

Maradj a SW-es I2C-nál. Annak semmi hasfájása nincsen....
Azaz ha nem kérsz _direkt_ HW-eset, akkor marad a SW-es....

Ez nem hiba, hanem előny:).

Szike

Továbbra is amatőr kérdéseim vannak:
-Lehet hogy kvarc hiányában a belső oszcillátorról működés miatt nem működik jól az I2C kommunkáció?
-Próbáltam állítgatni csak az alap órajelet. 1Mhz-nél nem tudott írni a slave-nek, 4Mhz-nél már igen. Mi lenne a helyes beállítás?
Köszi?

Az I2C a megadott órajelből számolódik.
A $crystal= és a Config delay= adatokból.

$Crystal= esetén a chip órajelét kell magdni. Ez nálad nem 1 hanem 1.2 MHz (ha a belsőről jár. Azaz
$crystal=1200000

A $delay=5 esetén 100 kHz a I2C busz.

Az I2C busz sebessége _nem_ időkritikus. Lassabb lehet, mint amit a chip tud, csak gyorsabb ne legyen!

Szike

Robert írta:Az I2C a megadott órajelből számolódik.
A $crystal= és a Config delay= adatokból.

$Crystal= esetén a chip órajelét kell magdni. Ez nálad nem 1 hanem 1.2 MHz (ha a belsőről jár. Azaz
$crystal=1200000

A $delay=5 esetén 100 kHz a I2C busz.

Az I2C busz sebessége _nem_ időkritikus. Lassabb lehet, mint amit a chip tud, csak gyorsabb ne legyen!

Értem. És ha megadom hogy $crystal= 4000000, de belső órajelről jár, akkor hosszabb lesz az időzítés, mert a 4Mhz-hez képest számolja a milisecet, közben 1,2 Mhz-en ketyeg továbbra is az oszcillátor?

Ha 4-t adsz meg, és valójában 1.2-vel jár, akkor az időzítés csúszik. De ekkor a sorosportod sem megy....

Az I2C-t nem befolyásolja a csúszás... lassabban szólítod meg.
De miért trükközöl az órajellel? nem illik... csak hibák forrásra lesz...

Szike

Csak azt vettem észre, hogy 1,2Mhz és I2cdelay=5 mellett néha tudok írni a H20-as eszköznek, néha nem (Olvasni a H21-ről továbbra sem). Először felvittem a delay-t 10-re de még mindig bizonytalan volt. Ekkor kezdtem emelni az órajelet, és így biztosabb lett.
Pedig ott van a chip az AVR-től 2cm-re. Nem értem.
Nem baj, nem adom fel, csak legfeljebb az idegeidre megyek!

Sorry!