A microcontroller host can use the FMAC driver to access the Wi-Fi capabilities of the WFx solution. To do so, the host has to follow several requirements described below.

Bus Communication

The host's first requirement is to support either SPI or SDIO communication. If the power save feature is used, the host has to manage an additional GPIO (GPIO_WUP) to wake up the chip. More information in the Host Interface (HIF) .

SPI Bus

In addition to the SPI connections (MISO, MOSI, clock), the host requires two GPIOs to manage the chip select and interrupt functionalities. See WF200 Hardware Overview to connect the host to WFx. The chip select is considered asserted in the reset state and the interrupt is detected on a rising edge. If the power save feature is used, the host requires an additional GPIO (GPIO_WUP) to wake up the chip.

SDIO Bus

By default, the interrupt occurs on the SDIO data line 1. This can be changed using the Platform Data Set enabling the interrupt on the GPIO_WIRQ pin. This option can be useful for power save support. The WFx follows the SDIO specification ver 2.0.

Host Memory Requirements

Flash Memory

The WFx FMAC driver has a flash memory footprint inferior to 5 kB. The WFx firmware is a 300 kB encrypted binary. The host has to send the firmware to the WFx during the initialization phase. For future proof updates, keep at least 350 kB free for the firmware image.

RAM Memory

The RAM memory used to run the driver is small (<1 kB for the context structure) and only consists of the sl_wfx_context_t structure.

Host Software Requirements

In addition to the hardware and memory requirements, the host has to implement specific software pieces to enable the use of the FMAC driver. This code is dependent on the software solution used (RTOS/Bare metal, IP stack, and so on) and on the host MCU.

Host API Functions Implementation

The host application has to implement a number of functions to run the WFx FMAC driver properly. See the dedicated page Host API .

WFx Input Buffers Limit

When sending commands and frames to the WFx, the driver keeps track of the frames pending inside the WFx. The FMAC driver has to prevent the host to send more requests than the available WFx input buffers. The number of available input buffers is shared in the startup indication during initialization. See the startup indication structure to retrieve the number of available input buffers (num_inp_ch_bufs in sl_wfx_startup_ind_body_t ). While the driver is running, the used buffer count is maintained in the attribute used_buffers of the context sl_wfx_context_t . This attribute has to be decreased every time the host receives a SL_WFX_SEND_FRAME_CNF_ID indication. It can be done in the sl_wfx_host_post_event() function.

WFx Receive Frame Loop

The host must detect an interrupt coming from the WFx chip and call sl_wfx_receive_frame(uint16_t* ctrl_reg) function. After the function returns, the parameter ctrl_reg has the value of the control register . The first 11 bits of the control register indicates the size of the next available frame. Based on this information, the host can either call the functions again or store the information that a frame is available and read it later. To speed up the reading process, provide the last value of the control register to the sl_wfx_receive_frame() function. This way, the driver can skip the "read control register" step. Below is a possible implementation to call after the WFx interrupt has been detected.

        
         // The interrupt has been detected, signaling the presence of a frame in the WFx
        
        uint16_t control_register = 0;
       
         do
        
        {
       
         // Call sl_wfx_receive_frame with control_register as parameter
        
         sl_wfx_receive_frame
        
        (&control_register);
       
         // Loop until there is no more data to retrieve from the WFx
        
        }
        
         while
        
        ( (control_register & SL_WFX_CONT_NEXT_LEN_MASK) != 0 );

After a frame is received, it is sent to the host application through thesl_wfx_host_post_event() function.

In addition, the host also has to manage the priority between the received frames and the packets to be sent . The balance between RX and TX is use case-dependent. It is up to the host to manage this balance in high throughput situations.

Sl_wfx_host_post_event Implementation

All packets received from the WFx are passed from the FMAC driver to the host application through the sl_wfx_host_post_event() function. This includes the confirmations sent to acknowledge FMAC requests and asynchronous indications based on Wi-Fi events.

The confirmations have to be pushed to the pending sl_wfx_host_wait_for_confirmation() functions . The way the replies are pushed/sent to the waiting functions are fully dependent on the software architecture used (RTOS, bare metal, and so on).

The list of possible indications sent by the WFx can be found on the dedicated indications page. Here again, the way the indications are processed is completely dependent on the application. The information reported by each indication is described in sl_wfx_general_api.h and sl_wfx_cmd_api.h .

Integration Steps

When integrating the FMAC driver into a new system, these are the recommended steps.

1. Implement host functions for communication Bus and RTOS

Implement the bus communication functions for SPI or SDIO and the other functions described above.

2. Test Bus Communication

See the details in the Initialization and Configuration page for each initialization step and make sure the configuration is completely successfully.

3. Use the WFx FMAC driver API to Initiate a Wi-Fi Connection and Send/Receive Data

This step requires implementing the sl_wfx_receive_frame() function as described above.

Host Requirements