www.elektronik.si

[vilko]

Pozdrav.

Nekje sem bral, da je potrebno onemogočiti prekinitve ( = Disable Interrups), kadar naslovim 1wire element. Menda zaradi časovnih zank.
To pravilo spoštujem in nimam problemov.

Ali velja isto tudi, kadar naslovim I2C element? Imam problme z I2C RTCRAM-om. Dela ure pravilno in potem enkrat napačna informacija iz I2C RAM-a, sledeče branje istega naslova je spet pravilno??

Kakšna ideja? Res je, nisem onemogočil prekinitve ko sem startal proces branja RAM-a, bi mi lahko škodovalo pri komunikaciji za RX/TX pini. Imam precej zapleteno RX prekinitveno rutino, vendar ta pri samem testiranju še ne sodeluje, in torej ne more biti vzrok za nesrečno branje I2C RAMA. Imam pa precej kratko timer0 interrupt rutino, (ima samo increment števec in return), ki bi pa po moje ne smela povzročati težav...

Morda bi moral le vprogramirati 'toleranco' do napačnega branja I2C RAMA tako, da podatek preberem dvakrat, in če je dvakrat enak, upoštevam, da sem bral RAM pravilno.

Kaj pravite?

[jur]

[vilko]

Uporabljam Bascom AVR kjer se tudi interrupt podprogrami končajo z Return.

Assembler je seveda drugače.

Hvala

(Nekdo je odgovoril, da je potrebna nekakšna drugačna return instrukcija, a je to sporočili 'izginilo'). Jaz pa svojega ne morem več brisati, lahko ga pa urejam. Zato to tako.)

[trot]

Imaš zadevo rešeno softversko ali hardversko? Kater uC imaš?

Če imaš softverski I2C (kot je to v primeru 1wire), potem moraš izključit tiste prekinitve, ki se ti lahko zgodijo med komunikacijo. Če pa je zadeva hardverska, pa drugi interrupt ne bo zmotil komunikacije.

[vilko]

Ja, res I2c je softwareski, uporabljam ATMega, ki sicer ima I2C pine, a niso tam, kjer sem predvidel tiskano vezje, ki je bilo narejeno za 89S8252 in ki ga uporabljam preko adapterja.... Hmm, to pomeni predelati in na novo narediti TIV?

[trot]

Ni nujno, odvisno kaj dela uC poleg I2C komunikacije. Jaz sem enkrat delal softversko I2C komunikacijo z atMEGA (ker je imel čip hrošča, in i2c ni več funkcioniral ko se je vrnil iz sleep mode), pa je zadeva delovala brez problema.

Poskusi samo I2C komunikacijo, in vse ostale funkcije ustavi. Jaz sem zadevo naredil z WinAVR, knjižnico pa se pobral na http://www.avrfreaks.net/

[vilko]

Trot, ali tudi ti programiraš v Bascomu?

[trot]

Včasih sem. Potem pa sem šel na C (WinAVR).

[Sokrat]

Joj fantje, ne klatite neumnosti, ker boste cloveka se bolj zmedli - I2C ima locen clock (za razliko od 1-wire), ki ima za casovni vsak parameter predpisano samo zgornjo mejo. Nikjer ne pise da se frekvenca ne sme spreminjati oz. da ne sme biti kar DC za nekaj casa.

To pomeni, da dokler je SW implementacija pravilno narejena (!) nima prav nobene zveze ce se interrupt pojavi med odposiljanjem oz. branjem, saj clock vedno kontrolira MCU. Ce pride vmes do interrupta, se pac cas enega bita raztegne, ampak to na nic ne vpliva, dokler HW deluje pravilno. Seveda koda v interruptu nima kaj sariti po linijah, namenjenih I2C !

Primerjava z SMBus

@Vilko: ce je HW brezhiben ter pravilno dizajniran (jur je omenil blokirne kondenzatorje) in so SW I2C rutine napisane pravilno (tega najbrz ne mores preveriti, ker izvorne kode Bascoma ne dobis prilozene, disassemblanje je pa mukotrpno pocetje ...), potem mora delati.

Predlagam, da naredis sledece:

1: Ce RAM in MCU nimata blokirnih kondenzatorjev na napajanju, jih dodaj, odstrani morebitne druge naprave z I2C vodila.

2: Preveri ali RAM sploh deluje OK. To pomeni pisanje razlicnih bitnih vzorcev (vsaj 0xaa in 0x55 oz. 0x00 in 0xff) na vse lokacije in branje nazaj, oboje pri dovolj nizkem clocku, da ne pride do motenj na napajanju. Tega ni se nihce omenil, a mozno je da ima RAM kaksno celico poskodovano ali pokvarjeno (to spada pod "brezhiben HW"), kar se sicer ne zgodi pogosto, se pa vseeno kdaj. Z dolocenimi vzorci vpisa te napake ne niti opazis !

Ce do napak ne pride, potem je ali cudno napajanje, ali pa je Bascomov SW I2C zanic napisan, kar se zdi precej neverjetno. Ce imas na voljo baterijo/akumulator namesto usmernika, lahko izlocis napajanje (dokler je napetost dovolj visoka, ob predpostavki, da je ploscica pravilno dizajnirana kar se tice napajanja), slednje pa bos bolj tezko preveril brez izvorne kode, lahko pa poskusis naslednje:

SCL (clock) linijo I2C povezi na vhod zunanjega interrupta. Najprej nastavi polariteto zunanjega interrupta na en prehod (denimo iz 0 v 1), potem pa se obratno. To bo zagotovo sprozilo interrupt ob vsakem bitu in ob razlicnih trenutkih v sekvenci posiljanja/branja. Koda v interruptu naj se izvaja vsakic nakljucno stevilko ciklov (tako da ne bo samo clock nekoliko upocasnjen, ampak se bo stalno spreminjal) in naj ne sari po linijah I2C. Predvidevam, da bi se tak poskus koncal povsem brez napak, ce je HW v redu.

Dobro bi bilo, ce bi pripel shemo ploscice.

[trot]

Pardon, moja napaka. Se opravičujem.

[vilko]

Hvala za odgovore in pripravljenost deliti z mano vaše znanje.

Ja, to sem si mislil, da pri I2c ne bi smelo biti kaj posebno občutljivo na timing, saj master generira svoj clock, s katerim se partner sinhronizira.

Priznam, nekaj sem zamolčal:
Na moj RTCRAM imata dostop dva mikroprocesorja. Da pa ne posegata hkrati, se preko tretjega pina, ki sem ga imenoval i2cfree dogovarjata, kdaj je prvi mikro master, kdaj drugi. I2cfree pin enega mikroprocesorja je vezan na i2cfree pin drugega mikroprocesorja in vse skupaj z enim pullupom na high.
Enostavno sem pred i2c ukazi naredil nekaj kot:

waitbit i2cfree, high
reset i2cfree
--- i2c pisanje ali branje in na koncu
set i2cfree

ta način mi je dobro deloval in imam že nekaj takih parov mikroprocesorjeve, ki si preko skupnega rama izmenjujejo podatke. A nikdar še nisem imel tako visoke frekvence poseganja po rtcram sužnju. Lahko, da pri manjši frekvenci poseganja po rtcramu sem imel enostavno 'srečo', da ni prišlo do hkratnega zaseganja in moja logika dogovarjanja ne deluje dovolj dobro.

Sledi testiranja programa in istočasno hw-a z enim samim mikroprocesorjem

Pozdrav
vs

[Sokrat]

Vilko, kako (v katerem nacinu) delujeta oba i2cfree pina na obeh MCUjih ? Zakaj je to pomembno: ce oz. dokler si take stvari uganjal s kloni 8051, ki imajo kvazi-dvosmerne vhode, je to najbrz celo delovalo, ker imajo pini interni pull-up (torej bi delalo tudi brez zunanjega).

Ce tvoj AVR nima identicnih tipov vhodov (to pomeni interni pull-up, za delovanje kot vhod mora biti port latch na 1, kar pomeni, da je port driver zaprt), potem to ne more nikakor delovati. Modernejsi mikrokontrolerji od 8051 (in AT89Cx051) imajo ponavadi push-pull izhode z moznostjo nastavitve open drain. Zunanji pull-up v primeru PP izhodov pomeni samo dodatno porabo toka, ko je izhod v stanju logicne 0. Z OD izhodi bi zadeva najbrz morala delovati, vprasanje pa je kaj MCU prebere, kadar je doloceni pin nastavljen kot izhod; ce ti namrec prevajalnik ne spremeni sam smeri (torej izkljuci izhodnega driverja in tako nastavi pina kot vhod), potem najbrz MCU ne prebere nic pametnega (stanje port latcha ?) in pocne traparije.

Ugibam, da sta oba MCUja poskusala hkrati sariti po vodilu, pa se je zadeva bolj slabo koncala.

Pa se to: tvoja koda tako ali tako vsebuje t.i. "race condition"; interrupti morajo biti v vsakem primeru izkljuceni pred izvajanjem vrstice, ki preveri ali je pin i2cfree high, pa se potem je mozno, da en MCU ze zacne spreminjati stanje pina, drugi pa pa misli, da je pin se vedno high in ga zacne spreminjati tudi sam. Vsak ukaz se namrec izvaja dolocen cas, cetudi zelo kratek, in takrat obstaja kratek trenutek, v katerem se lahko zacneta MCUja hkrati puliti za vodilo in dreti po njem. Rezultati so napake v delovanju. Morebiten interrupt se poveca verjetnost, da bo MCU predpostavil, da je vodilo prosto (kar je tudi bilo ... pred veliko casa), v resnici pa ne bo vec. Ni potrebno, da so interrupti se vkljuceni potem, ko je ena naprava ze na vodilu in druga ne more vec sariti po njem.

Ce gre zgolj za komunikacijo dveh MCUjev, potem uporabi UART, pa ne bo nobenih problemov. Za sinhrono komunikacijo potrebujes 3 pine (toliko jih zdaj porabis za I2C + i2cfree), za asinhrono pa samo dva. Ce MCUja uporabljata kvarcni oscilator kot vir ure, potem je asinhrona cez glavo dovolj, hitrosti pa so lahko precej visoke (povsem primerljive z I2C, le da gre tukaj za full-duplex komunikacijo).

[vilko]

Sokrat, razmišljaš tako, kot sem razmišljal jaz, le še malo boljše.

Pri meni si rtcram (in ostale i2c sužnje na busu) delita atmega16 in 89c4051.
Pri avr-u moram poleg tega, da testiram i2cfrepin free še le tega imeti na načinu INPUT, in potem predno ga resetiram na 0, ga moram postaviti na OUTPUT in ga držim dako, vse dokler ni i2cprocess končan.

Moja koda za branje enega bajta je sledeča:

[Sokrat]

Aha ... Kakorkoli, tudi z izkljucenimi interrupti bo prislo do problema:

Prvi MCU pogleda, ali je linija prosta. Ugotovi da je in si misli "Super! Jo bom kar zaplenil.". Zacne torej izvajati ukaz, ki zaseze linijo i2cfree, ravno takrat enkrat (torej od trenutka, ko je prvi MCU ugotovil, da je linija prosta, ter do trenutka, ko ukaz za spreminjanje stanja linije to koncno prestavi v zasedeno stanje) pa drugi MCU pogleda stanje linije in vidi, da je ta prosta. "Super! Bomo mi to kar zasegli." in rezultat je, da oba MCUja mislita, da imata samo ona pravico sariti po I2C vodilu,

Ta nacin ne bo nikoli deloval zanesljivo, je pa zelo majhna verjetnost, da bo prislo do napak. Manj kot je komunikacije, manjsa je verjetrnost za tezave, a je se vedno vecja kot 0.

Moj predlog je, da napisi svoje rutine za sinhrono komunikacijo. Ce je vezje ze narejeno, potem bo malce tezje kar se tice sinhronizacije, sicer pa je stvar preprosta, ce iams le na voljo kaj prostih pinov (4 bi bili super, s tremi bi se vedno slo).

[vilko]

No, ne gre samo za komunikacijo, gre tudi za celo paleto podatkov, ki si jih delita preko skupnega rama, a me zelo zanima, kako si zamišljaš sinhrono komunikacijo.

Tole, preko skupnega rama je nekako poštni predal. eden preda drugemu v predal, ne, da bi drugega pri tem oviral, a ta drugi lahko ta čas dela nekaj drugega, le občasno gre pogledat, ali je kaj v predalu. To ni sihrona komunikacija, a je veliko bolj preporstoa kot sinhrona ki prinaša veliko dodatnih zahtev, ki jih je potrebno rešiti. Pred vsem takrat ko eden oddaja, MORA drugi sprejemati in ne se ukvarjati s čim drugim. To pa se mi zdi zelo težko izvesti.

Si ne upam sam seštrikati take sinhrone komunikacije...

Hvala, bom pazil, da bo komunikacija preko skupnega rama 'manj frekventna', da bo skoraj 0 verjetnosti, da bi prišlo do kolizije

mimogrede: če vzamem en mp iz podnožja, drugi bere že ure brez napak. Tukaj je toraj treba iskati črva.