www.elektronik.si

[Sokrat]

Jah, pricakovano, ce ni nicesar, kr bi povzrocalo "mikrofonijo" na vodilu

Ja, drzi da mora drugi MCU sprejemati, ko prvi podatke posilja, sicer bo odlicni plan padel v vodo. Ce prav razumem tvoj opis, trenutno noben MCU ne uporablja interruptov. Ce je temu tako, potem je stvar zelo preprosta (vsak MCU poganja svoj clock, ki pride vezan na eksterni interrupt drugega MCUja, ta pa ob vsakem interruptu prebere nov bit in ga porine v spremenljivko, ko pa jih prebere 8 in ima torej cel bajt, pa o tem obvesti glavni program s postavitvijo zastavice). Na tak nacin je povsem nemogoce, da bi prislo do race conditiona, dokler je frekvenca clocka v razumnih mejah (ce recimo traja interrupt skupaj maksimalno 10 ms, potem clock ne more imeti periode krajse od 100 KHz).

Ce interrupti niso na voljo, se stvar malce zakomplicira (vsaj pri predlaganem stevilu linij, ce naj bo prenos se vedno full duplex). Tezko je svetovati najboljso resitev, ker ne poznam dovolj dobro tvoje aplikacije. Morda bi bila dovolj ze ena dodatna linija, s katero bi manj pomembni MCU dobil od bolj pomembnega potrditev, da sme smetiti po I2C vodilu, brez takega dovoljnega pa bi lahko po njem komuniciral samo prvi MCU.

V praksi bi to izgledalo tako, da drugi MCU spravi linijo i2cfree? iz enega stanja v drugo (0 v 1) in s tem zahteva prosto linijo, ko prvi MCU koncno blagovoli linijo sprostiti, mu po drugi liniji i2cfree! javi, da je vse prosto (iz 0 v 1) in se vzdrzi I2c komunikacij dokler drugi MCU spet ne sprosti i2cfree? (iz 1 v 0). Drugi MCU i2cfree? ne sme postaviti v stanje 1, ce ni i2cfree! 0, saj bi sicer lahko napacno interpretiral dovoljenje od prejsnjega prenosa, ce bi si dva sledila prehitro. V takem primeru ne more priti do nobenih tezav, saj bo vedno vodilo zasegel samo en MCU (tisti, ki je po tvoji oceni pomembnejsi, torej mora imeti vec casa vodilo na voljo). Se zaporedje stanj:

[vilko]

Oprosti Sokrat, dolgo je trajalo, da odgovarjam.
Pred vsem me je sram priznati, da se ne čutim sposobnega narediti tega, kar predlagaš, in kar bi vsekakor delovalo, potem, ko bi veliko testiranja in dela bilo vloženo. Saj to je nekako sinhroni softwareski uart, kar je uspeh celo za profesionalce.
Bom moral le ostati pri tem, kar imam, in izboljšati verjetnost kolizije tja na 1 : milijon, ali malo manj, se pravi, da če imam časovno okno 1 usek, kot je nedoločeno, ali bo tudi drugi procesor zasedel bus, mora biti zahtevana frekvenca posega na bus 1 sekunda ali manj.
Mislim, da bo to zadostovalo za kolikor toliko zanesljivo delo. če pa potem še dosežem toleranco napake, da mora vsak podatek prebrati dvakrat enako, in vsak vpisani podatek verificirati po vpisu, potem mislim, da bo delovalo dovolj zanesljivo.