The two-wire interface slave with EasyDMA (TWIS) driver includes two layers: the hardware access layer (HAL) and the driver layer (DRV).
The hardware access layer provides basic APIs for accessing the registers of the TWI. See the API documentation for the TWIS driver - legacy layer for details.
The driver layer provides APIs on a higher level than the HAL. See the API documentation for the TWIS driver - legacy layer for details.
Key features include:
The following configuration options are available in sdk_config.h:
The TWIS driver supports two different modes: synchronous mode and asynchronous mode.
In synchronous mode, the driver works completely without interrupts. To configure the driver to use synchronous mode, pass a NULL pointer as the pointer to the event handler during driver initialization.
In synchronous mode, events are pooled every time a state function is called. Pooling and state machine processing can be entered only once at the same time. Therefore, if a function is called from the main thread and, while it is processed, an interrupt occurs that tries to process a TWIS event again, the checking function in the interrupt is skipped.
The TWIS driver is a slave driver. Therefore, the reasons for configuring this driver to use synchronous mode are different than for a master driver. For a slave driver, it does not make sense to support sending data from the main thread and from interrupts at the same time. State testing functions like nrf_drv_twis_is_busy are not guaranteed to process the current state in the interrupts if the same functions are processed in the main thread. Interrupts should not wait for a state change. Otherwise, they might be locked.
The following example code shows how to use synchronous mode:
In asynchronous mode, all events are processed in internal interrupt service runtime. When anything requires processing, the event handler is called. See nrf_drv_twis_evt_type_t for a list of defined events.
The event handler is always called in the following pattern: REQ -> DONE or ERROR. This means that if we get a TWIS_EVT_READ_REQ message, the answer will always be TWIS_EVT_READ_DONE or TWIS_EVT_READ_ERROR. The answer will be sent even if there is no STOP condition on the bus, but reading finishes for example by a repeated START condition.
There are different ways to prepare buffers for receiving or sending data:
The following pseudocode shows how to implement an event handler: