www.elektronik.si

[herba]

Torej, zavedno sem kršil pravilo I2C komunikacije, da je namenjeno povezovanju enot na istem vezju. Vmes so kabli dolžine 1m - 2m. Master naprava je PIC, slave naprave (več na istem vodilu) so PCA9622 I2C 16-bitni led driverji. Ugotovil sem, da je lahko na vodilu priključenih tudi več naprav, vendar lahko (uspešno) komuniciram le z dvema, če poskušam komunicirati z več napravami na vodilu, so motnje prehude.

Prilagam posnetek komunikacije z 2. napravama. Komunikacija hitrosti 100kHz. PCA9622 podpira hitrosti do 1MHz, zaradi česar mislim da so tudi težave. PCA9622 čip ima sicer vgrajen filter šuma, ki filtrira signale pod 50nS kar pa ni dovolj (dolžina motilnega v mojem primeru je okoli 200nS).

Zamenjal sem kable z signalnimi in jih ustrezno oklopil, vendar to ne reši težav. Namenski čipi so za moj primer predragi, saj bi jih potreboval 10 (toliko je max. število naprav na liniji, ki jih načrtujem), kar močno podraži zadevo.

Kakšna druga rešitev? Bi RC filter pomagal?
Vem, da se tako I2C-ja ne uporablja, samo v času načrtovanja druge rešitve nisem našel, nisem si pa mislil, da bodo z komunikacijo take težave.

[dumr666]

tudi mene je matralo pri diplomski to, medtem ko je spi s 16 MHz šopal na polno. Sam sem sicer imel hitros 400 kHz in sem potem spustil na 100 kHz. Če imaš možnost spusti frekvenco prenosa

[.]

Brisana vsebina odstranjenega uporabnika.

[herba]

Vam da so moj problem parazitne kapacitivnosti, ki jih najbolj povečujejo spoji med povezavami in naprave vključene na linijo. Posledica so špice v komunikaciji. V specifikaciji I2C vodila ne piše nič konkretnega o tem, razen o toleranci šuma in kapacitivnosti vodnikov, ampak seveda sam tega tako ali tako ne uporabljam v skladu z priporočili, zato pa so težave.

PCA9622 podpira samo I2C, zato na način komunikacije neposredno ne morem vplivati, posredno pa seveda ni problema PIC <->I2C <-> izbrani protokol <-> I2C <-> PCA9622, oz. v mojem primeru PIC <-> izbrani protokol <-> I2C <-> PCA9622, glede na to, da imam z PIC-em odprtih več možnosti. Temu pa bi se rad, če je možno, izognil zato sprašujem.

Na voljo imam:
- Filtriram motnje na linijah I2C
- Izberem drug protokol do čipa PCA9622
- Vržem kar ne dela stran in uporabljam samo 2. napravi

Ali vzamem večji kozarec, ali med kozarec in steklenico dodam dovolj dolgo cev, da bo preostalo pivo ostalo v cevi, ali pa natočim 1 dcl preostalo pa zavržem.
Najprej bom poskusil 1. način, ker se mi zdi bolj smotren, nato če ne bo šlo pač drugi čeprav se bom požrl do konca, tretji ne pride v upoštev, ker ne bomo ničesar metali stran.

Z različnimi pull-upi se poizkusil, nima vpliva; žica hmm, nimam ideje kaj bi uporabil namesto signalnega kabla; znižanje frekvence ima za posledice velike programske posege, tudi najnižja frekvenca, ki jo podpera hardware-ski del namreč povzroča težave.
Uporabljam pa to za pogon luči na maketi (trenutno 4x16 kanalov) in bi, če bi vse združil na eni tiskanini, to pomenilo preveč kablovja izpod makete, zato sem moral I2C komunikacijo spraviti na kabel.

[Dorijan]

Na vsako vezje daš lahko i2c buffer.
http://www.nxp.com/documents/leaflet/75016081.pdf
http://www.ti.com/lsds/ti/interface/i2c-hub-buffer-repeater-products.page?paramCriteria=no

Vendar to so bolj "šalabajzarske" rešitve. Pretvorba na kak drug protokol se mi zdi bolj primerna.

lahko bi pa i2c signal nekako pretvoril v diferencialnega, čeprav ne vem točno kako bi to naredil za bidirectional signal.

[mucek]

Uporabljam flat kabel, kjer je vsaka druga žica masa in 3k3 pull up.
Zadeva deluje precej stabilno, kabla je kak meter in okolje je precej "svinjsko" glede EM motenj.

Druga opcija je, da z enim cenenim kontrolerjem narediš I2C - RS485/232 (ali kaj podobnega) vmesnik, kar pa pride v poštev le, če je hitrost komunikacije nizka.

LP, g

[gumby]

Tretja opcija je ta, da vzameš drug čip (z SPI recimo, kjer lahko za signale direktno uporabiš RS485 čipovje).

[Mbili]

Kolikšna je skupna dolžina vodila (kablov)? Je PIC na I2C priključen neposredno (težave), ali preko dodatnega čipa (npr. PCA9517)? Kakšni so pull-up upori? Tudi na I2C mora zadeva z več napravami na vodilu do meter ali dva dolžine delovati, če je prav narejena. Na metrskem vodilu z več priključenimi napravami, s katerimi se stalno vrši komunikacija, imam aplikacijo, ki že leta dela brez napak in to na 200 kHz, na cca. dvometrski povezavi pa na 100 kHz.

[int47]

Izgleda, da so napake precej pogoste.

Če imaš možnost, poglej dogajanje na liniji s spominskim osciloskopom.
Če gledaš logično stanje, vidiš le motnje, ki presežejo prag preklopa.

Oklopljen kabel ima verjetno večjo kapacitivnost/m, kot neoklopljen.

[marko]

Jaz sem se I2C vodilu v celoti odpovedal, ker me je spravil tolikokrat ob živce, da ga niti pogledat ne želim več. Sem poskušal z vsemi možnimi prijemi in ni nič pomagalo. Na koncu je še največ pomagalo dobro napajanje - pred regulatorjem dušilka + 2x low esr kondenzator in pa algoritem za zaznavanje obešanja i2c protokola in pa reset samega busa. Vendar je tudi to velikokrat premalo in se zadeva enostavno obesi. Uporabljam pa AVR, lahko da je tu tudi hardwerski i2c buggy, ne vem. Jaz se i2c, ko je bus daljši kot 1 cm, izogibam

[herba]

Po nekaj računanja in poizkušanja sem z pravilnim uporom sedaj uspel izničiti špice vsaj do te mere, da jih moj logični analizator več ne zazna (pri 24MHz in 10kOhm). Sem že spreminjal vrednosti uporov, morda premalo vztrajno. Digitalnega spominskega osciloskopa žal nimam, tako da več kot z logičnim analizatorjem ne morem pomeriti. Je pa vsaj zdaj slika komunikacije "čista".

Čedalje bolj me bega tole. Zakaj je lahko vseh 6 čipov priključenih na linijo, komuniciram pa lahko samo z dvema od priključitve napajanja. In to katera koli si izberem, čim komuniciram z enim več so težave. Prešinilo me je, da to morda sploh nima veze z komunikacijo, ampak je kakšna druga fora.

Naj še dodam, da sem, preden sem sistem vgradil preizkusil tako, da sem vse čipe ki sem jih imel, priključil na linijo (z istimi kabli kot sedaj) in uspešno prižgal vse kanale na voljo, zato sem rekel super dela. Sedaj ko je pa to na maketi vse vgrajeno in povezano z miljon žičkami pa Edina razlika med testom in seda je, da so bili vsi izhodni kanali med testom neobremenjeni. Da se stvar še bolj zakomplicira: ker sem med razvojem potreboval, sem spisal prigram, ki zna poiskati vse naprave priključene na vodilu, glede na to ali od njih dobi povratni odziv in glej ga zlomka najde vse priključene čipe in to vedno ter pravilno (spet na istih žicah kot sedaj).
Mogoče je pa hardware-ski i2c v PIC-u problematičen. V podatkovnem listu PCA9622 sicer piše, da lahko deluje z visoko kapacitivnimi vodili do 4000pF (standard določa do 400pF).

Še komentar pripete slike v mojem prvem prispevku. Ne vem kako, ampak imel sem priključen popolnoma napačen upor (nekaj 100 Ohm) in to ni odraz dejanskega stanja. V moji obupanosti bi moral dvakrat preveriti. Je pa zanimivo, kljub vsem tem motnjam - z dvema čipoma se lahko še vedno uspešno pogovarjaš. Ne vem več niti kako mi je ime.

[mucek]

[herba]

[mucek]

No, me veseli, da je pomagalo!
Nič se sekirat, če si se kaj več naučil - ti bo že še prav prišlo!

LP, g

[marko]

Super, da deluje. Vedi pa, da ko boš to priklopil v pravo okolje (ne samo na mizi v laboratoriju ) lahko pričakuješ še kakšen stresen dan ali dva

lp