3.4.2 Interrupt Handling

The HIF interrupts the host MCU when one or more events are pending in the ATWINC15x0 firmware. The host MCU application is a big state machine which processes received data and events when the ATWINC15x0 driver calls the event callback function(s). To receive event callbacks, the host MCU application is required to call the m2m_wifi_handle_events API to let the host driver retrieve and process the pending events from the ATWINC15x0 firmware. It is recommended to call this function if any of the following events occur:

  • The host MCU application polls the API in main loop or a dedicated task
  • When the host MCU receives an interrupt from the ATWINC15x0 firmware
Note: All the application-defined event callback functions registered with the ATWINC15x0 driver run in the context m2m_wifi_handle_events API.
The above HIF architecture allows the ATWINC15x0 host driver to be flexible to run in the following configurations:
  • Host MCU with no operating system configuration – the MCU main loop is responsible to handle deferred work from the interrupt handler
  • Host MCU with operating system configuration – a dedicated task or thread is required to call m2m_wifi_handle_events to handle deferred work from the interrupt handler
Note:
  1. Host driver entry point m2m_wifi_handle_events is non-reentrant. In the operating system configuration, it is required to protect the host driver from reentrance by a synchronization object.
  2. When the host MCU is polling m2m_wifi_handle_events, the API checks for pending unhandled interrupt from the ATWINC15x0. If no interrupt is pending, it returns immediately. If an interrupt is pending, m2m_wifi_handle_events sequentially reads all the pending HIF messages and dispatches the HIF message content to the respective registered callback. If a callback is not registered to handle the type of message, the HIF message content is discarded.