I2C bus interaction operates asynchronously. The main reason? It operates in a typically much, much slower time frame especially in comparison with contemporary computer equipment running at clock rates of many hundreds of mega-Hertz or even many giga-Hertz.
I2CLIB’s design specifically targets modern high-speed processors by ‘nature of the beast.’ See document’s abstract: designed for high-level interfacing using high-level languages via special host-adaptor equipment. Typical target equipment? Embedded microprocessor or up-to-date desktop or laptop computer. Low-performance micro-controllers will not use the library; they typically run assembly-language bit banging software. I2C might run entirely in-sync with the micro-controller at low clock rate or close to it, or in separate bit-banging thread of control.
Asynchronous nature of communication for high-speed microprocessors versus I2C clocking rate raises some problems. Question: how to synchronise I2C events and microprocessor threads of execution?
Typically, I2CLIB waiting for completion of a bus cycle in single-threaded caller-callee style becomes impractical unless you either run a separate thread of execution or map interaction states to instance states rather than stack-based states.
I2CLIB accommodates both approaches. Core library state machines for interactions map their states to object instance states. This gives adaptability, allowing for full asynchronous communication or synchronous with blocking but separated by threads.