( Csab | 2019. 09. 11., sze - 10:44 )

Nem kell zavart érezni az erőben, tök mindegy, hogy mit írnak a gyártók, nem muszáj megvenni a termékeiket.
Flow control nélkül semmi értelme az I2C-nek, mert a többi protokoll sokkal jobb megoldást kínál erre.

Az I2C nagyon sok tekintetben nem optimális, ami tök jó, hogy vissza tud szólni, ha még nem fejezte be a feldolgozást.

AVR alatt megpróbáltam a multimaster-es módot is interrupt kezelésre, de a chip erre alkalmatlan 4-5 hardverhiba miatt. Valszeg azért lett TWI, mert idő hiányában piacra dobtak valami szart I2C helyett.
- egyszerre küldött start jelnél kiakadhat mindkét mester
- néha elveszíti a biteket és kifagy a CLK vonal
- a STOP-ot rosszul kezeli, ha gyorsan küldenek a masterek és a kódod lassú, könnyen NACK jön vissza
- nem tartja be az I2C "bus free time"-ot a specifikációból

Protokoll hibák:
- a felhúzó ellenállások miatt zajra érzékeny
- hosszú kábelnek nagy a kapacitása, miközben egy SPI/UART a HI szintet beleveri 40mA-rel, addig az I2C 5kohm felhúzó esetén 1mA-rel tölt
- őrülten lassú, a 100kHz az semmi, már egy 128x256-os LCD-hez is kevés.

Mivel helyettesítettem idáig az I2C-t?
- SPI a leginkább kézenfekvő, egy 320x200-as színes LCD-hez már 10 MHz-cel DMA-val tolom az adatokat
- WiFi (ESP8266+ESP32 egy I2C-hez képest elképesztő sebességekre képes)
- UART (mehet több résztvevő között is, multiplexinggel)
- CAN busz is lehet, nem véletlenül ezt használják a kocsikban és nem I2C-t

Hőmérőt meg vehetsz SPI-set is, meg OneWire-t is ha szívatni akarod magadat. Én a Microchip-től SPI-s cuccokat szoktam venni, mert az I2C-vel kapcsolatban fenntartásaim vannak.