A kommunikáció végig szabályos. Az utolsó adat után a master elengedi az SDA-t, hogy a slave adhassa az ACK-t. Ehhez a master adna egy órajelet, de a slave addig tartja 0 szinten, amíg nem végzett a blokk a blokk írásával - ami több ms. Az írás sikerességének függvényében beállítja az ACK-t és elengedi az órajelet. Ez a clock stretching, ami teljesen normál buszművelet, ha implementált.
Mivel itt két processzor beszélget, bármit meg lehetne csinálni.
A probléma pl. egy EEPROM írásánál kezdődik, ha írás végét szeretnéd megállapítani. Megcímzed az eszközt és nem válaszol. (Lásd 5.1.6, Figure 9) Ugyanitt a másik anomália, ha utána nem akarsz sem írni, sem olvasni. Minkettő megoldásához nem std buszműveletet kell összerakni.
Tehát a bájtonként továbbított adatok helyett - mert ilyen üzemmódba is kapcsolhatsz - sokszor a buszciklus egyes elemeire is programot kell írni. A serial_write() erre nem alkalmas, de egyes hardvereket nem is tudsz programozni, mert csak a kötelező minimumot implemetálták az i2c protokollból.
Bonyolítsuk tovább a helyzetet, mert eddig még mindent össze lehetett rakni az i2c perifériát programozva. Pl. az AM2320 i2c/smbus protokollját sem tudod összerakni. A Figure 15 -> min 800us és a Figure 17 -> min 30us késleltetések nem valósíthatók meg az egyszerű i2c hardverrel. Csak az a megoldás marad, hogy i2c elemekre bontva + program + időzítés. Persze csak akkor, ha nem akarsz megállni és NOP-okkal késleltetni. ;) Marad az a megoldás, hogy az anomáliánál timer beállít és interrupt vége - majd, ha a timer lejárt folytatódik. Közben a processzor végrehajthat 300 utasítást.
Ez utóbbit szoktam iskolapéldaként emlegetni. Ember megírja rpi-re az AM2320 illesztését, fölrakja a githubra. Aztán vesz egy gyorsabb rpi-t és a program nem működik. Bezzeg, ha az adatlapot is elolvasta volna, vagy tisztába lett volna a serial_write() mögötti történésekkel, akkor akár hordozható programot is írhatott volna. :-D