Host requirements

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

Bus communication

The host first requirement is to support either SPI or SDIO communication. In case the power save feature is used, the host has to manage an additional GPIO (GPIO_WUP) to wake up the chip.

SPI bus

The WFx supports SPI 8-bit up to 50MHz. In addition to the SPI connections (MISO, MOSI, clock), the host requires two GPIOs to manage the chip select and interrupt functionalities. You can refer to 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. In case the power save feature is used, the host requires an additional GPIO (GPIO_WUP) to wake up the chip.

SDIO bus

The WFx supports SDIO 4-bit up to 50MHz. 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 in case of 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, we recommend keeping 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 on the host MCU chosen.

Host API functions implementation

The host application has to implement a number of functions to run the WFx FMAC driver properly. Refer to 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 is responsible to forbid 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. You can refer to 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 is responsible for detecting an interrupt coming from the WFx chip and calling sl_wfx_receive_frame(uint16_t* ctrl_reg) function. Once the function returns, the parameter ctrl_reg has the value of the control register . The eleven first 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, it is recommended to 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 once 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 );

Once a frame is received, it is sent to the host application through the sl_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 the 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...).

The list of possible indications sent by the WFx can be found on the dedicated indications page. Here again, the way the indication are processed is completely dependent on the application. The information reported by each indication is described in general_api.h and wfm_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

Refer to 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 WiFi connection and send/receive data

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