Valójában a sebesség a kulcs. Amire azt mondjuk UART, olyanban 10 Mbaud volt a maximum, amit láttam RS485-re kiépítve, de km hosszúságban. (!) A PCIe már sok gigás tartományban mozog. Itt kezdődnek azok a problémák, amikor egész rövid vezetéken sem tudod megvalósítani azt topológiát, amin egyformán késnek a jelek. Az aktiv eszközök viszont gyorsabbak, mint a vezeték futásideje, ezért egy vezetéken (differenciális páron, mert azt jobban lehet illeszteni) sokkal nagyobb sebességet lehet elérni. A többi már csak protokoll kérdése, hogy a szinkron is és a kecske is megmaradjon. No, meg a kevesebb vezeték is egyszerűbb.
Szinkron kommunikáció is lehet változó bitrátás, ameddig két oldal sebessége megegyezik, nem?
Ez nem is kérdés, mert a master biztosítja a clock-ot, aminek valamelyik élére szinkronizáltan történnek a dolgok. Tehát, hogy a viharba ne egyeznének.
Amit emlegettem az I2C teljes implementációjából az a rész, amikor ugyan a master adja az időzítést, de a slave jogosult addig késleltetni, amíg rá nem ér. ;)
Konkrétan: A busz feszültségét (órajelet) csak lehúzni lehet, tehát felfelé a felhúzó ellenállás, lefelé az aktív elem. A master billegteti a clock-ot és az adatot - 8 bit + ACK -, de a slave megkapva az utólsó adatbitet nem engedi fel az órajelet. Ebben a példában a master egy firmware frissítést küld a slave számára. Amikor a slave megkapta a 32. bájtot, lehúzza az órajelet - és "elmegy" flashelni. ;) A művelet végén - annak eredményével beállítja az ACK bitet, - majd elengedi az órajelet. A műveletnek köze nincs a master órajeléhez, mert rossebb se tudja, menny ideig íródott a flash blokk. Ekkor a master kénytelen a felfutó élre szinkronizálni (lépteti az állapotgépet), kiolvassa az ACK értékét és lezárja a buszciklust. Hát ez nem az a tipikus szinkron művelet, amikor a master clock ütemében történnek a dolgok! Az algoritmus szépen működik két különböző PIC mcu között.