Szóval két probléma van:

- a tápfesz. meredek változásai, tehát nem simán zavar, amit pl. egy bizonytalan kapcsoló is elő tud állítani, de sok más oka lehet, és nem is csak egy szimpla tápfesz-megszűnés,

- a buszon közlekedő jelek torzulásai.

 

Azért nem tartom hülyeségnek a saját felvetésemet (naná... :-), mert a processzoroknál van reset láb, ami ha aktív, semmit sem csinál a processzor, és aminek a meghajtását valóban illik rendesen megoldani áramkörileg - egy I2C-s eszköznél viszont nincs ilyesmi, legalábbis nem szoktam látni. Rendben, azok sokkal egyszerűbb eszközök, nem processzor, hanem célszerszám, de attól még lehetne, merthogy chip select sincs...

 

Tegyük fel, hogy nem probléma, ha egy rossz adat kerül egy EEPROM-ba, mert van hely és minden adat mellé tudunk írni egy megfelelően erős CRC-t, és az sem probléma, ha elvesztjük az adatokat, mert a “fájlrendszerünk” sérül, vagyis változó hosszú adatok tárolásánál a mutatók sérülnek - mert képesek vagyunk pótolni.

 

Akkor is ott van pl. egy I2C-s kapcsolóeszköz, ami ha reléket vezérel, biztosak szeretnénk lenni benne, hogy soha nem kapcsolnak rosszul. Talán ezen már nem lesz vita, mint az EEPROM-on. Nyilván lehet ismételgetni az utolsó parancsot egyfolytában, de az azért nem tetszik túlságosan.

 

Utánanéztem, más is feltette az egyik tipikus kérdést ezzel kapcsolatban, hogy “akkor miért nincsenek a csomagok ellenőrzőösszeggel ellátva, megvédve”.

 

Az egyszerűbb érvek mellett, hogy olcsók legyenek az ilyen eszközök, ill. ezek tipikusan egészen rövid buszok a készülékek belsejében, volt egy komolyabb is: hogy ha egy I2C busz elektromosan nem teljesen stabil, akkor előfordulhat, hogy az egyik eszköz feltartja az egészet, tehát már a hardware layer-en biztosítani kell a zavarszűrést stb. Úgy pedig igen kicsi a valószínűsége egy-egy hibás parancs vételének, nem éri meg bonyolítani.

 

Tehát azért áll elő ez a helyzet, mert egyrészt annak a busznak nincs külön chip select-je, valamint nyitott kollektoros meghajtású. Akkor mi a megoldás? Másfajta busz...

 

A kézenfekvő alternatíva az SPI, ahol van chip select és aktívan fel- ill. lehúzzák a szereplők a lábakat a logikai szintekre, talán ez is számít. Az, hogy gyorsabb tud lenni, most nem érdekes. A másik lehetőség a CAN, amit nem szerettem volna behozni a képbe, mert drágább, és készüléken belül eléggé túlzásnak tűnik. Ott egészen érdekes az arbitráció (ki szólal meg a buszon). Hogy a busz beragadásának minimalizálva legyen az esélye, minden kiadott bitet egyesével visszaolvasnak az eszközök, az üzenet száma egyben a prioritása is a buszon.

 

(Lassan harminc éve sikerült NT 4-re device driver-t írnom ISA buszos CAN kártyákhoz, mikor még a Microsoft Magyarország azt sem tudta, hogy létezik ilyen fejlesztőrendszerük... Ugyanazon a gépen debugoltam ki a kódot, így ha elszúrtam valamit, rögtön kékhalál lett, és akadtak még kalandok. Végül használható termék lett belőle, de hatalmas energiák árán. : -) De ez a szoftveres rész. CAN-Open, Open CAN, Selectron CAN - a fene tudja, hányféle létezik.)

 

Szóval az SPI busszal folytatom a keresést, hogy arról miket írnak a tápfesszel és a busz megbízhatóságával kapcsolatban. És persze nem ég a ház, csak ez nekem egy homályos terület. Példa rá az MCP23S08 - ilyenből cseréltem ki nemrég egy maroknyi villámcsapottat, de már írtam itt valahol. : -)