 |
Synergy Software Package User's Manual
|
|
Synergy Software Package User's Manual
|
The Wi-Fi framework provides a high-level API for configuring and provisioning Wi-Fi modules as well as performing data transfers with or without on-chip networking capability. Currently, only the Qualcomm GT202 module is supported. The Wi-Fi framework communicates through the SPI with the underlying GT202 module.
The Wi-Fi Framework defines API functions for each of the related modules. The following descriptions explain the operation of each API. A table of common return codes follows at the end of the section. Refer to the API reference section for the associated module for additional details.
Additionally, a more detailed API description, along with a working example application (which is too lengthy to include in this document), is available on the Renesas web site. Just search for the associated application note document number, r11an0226eu, in the top page search bar on www.Renesas.com. It is highly recommended that you use the application note to augment the summary descriptions found in this document.
WiFi Framework Module API Summary
| Function Name | Example API Call and Description |
|---|---|
| open | g_sf_wifi0.p_api->open (g_sf_wifi0.p_ctrl, g_sf_wifi0.p_cfg);This API initializes and enables the Wi-Fi module. The open function returns the Wi-Fi control structure, uniquely identifying the instance of the Wi-Fi framework. |
| close | g_sf_wifi0.p_api->close(g_sf_wifi0.p_ctrl);This API un-initializes the Wi-Fi module and powers it off. |
| infoGet | g_sf_wifi0.p_api->infoGet (g_sf_wifi0.p_ctrl, wifi_info);This API takes the WiFi control structure as an argument and returns the following information obtained from the WiFi module: - Chipset/driver information string - RSSI value (unsigned integer 16 bits) - Noise level (unsigned integer 16 bits) - Link Quality (unsigned integer 16 bits) |
| statisticsGet | g_sf_wifi0.p_api->statisticsGet (g_sf_wifi0.p_ctrl, p_stats);This API gets the data statistics from the Wi-Fi module. It takes the Wi-Fi control structure as an argument and returns the following statistics: - Received packets (unsigned integer 32 bits) - Transmitted packets (unsigned integer 32 bits) - Transmit packet errors (unsigned integer 32 bits) |
| transmit | g_sf_wifi0.p_api->transmit (g_sf_wifi0.p_ctrl, p_buffer, length);This API sends the data/packet out. This function takes the Wi-Fi control structure as an argument. It takes the network packet buffer, and the network packet buffer length as arguments. The Wi-Fi framework transmit function passes the packet buffer to the Wi-Fi driver for transmission. |
| provisioningGet | g_sf_wifi0.p_api->provisioningGet (g_sf_wifi0.p_ctrl, &sf_wifi_provisioninfo);This API takes the Wi-Fi control structure as an argument and returns the following parameters: - Mode (enumeration, that is, AP or client) - Channel (unsigned integer 8 bits) - SSID (string) - Security type (enumeration) - Encryption type (enumeration) - Security key (string) |
| provisioningSet | g_sf_wifi0.p_api->provisioningSet (g_sf_wifi0.p_ctrl, &g_sf_wifi_provisioninfo);This API sets the Wi-Fi module in the given mode AP/Station. The provisioningSet function uses the following parameters to provision the WiFi module: - Mode (enumeration, that is, AP or client) - Channel (unsigned integer 8 bits), only used in AP mode - SSID (string) - Security type (enumeration) - Encryption type (enumeration) - Security key (sting). - Connection Status Notification Callback function: Used to get connection status change notification *See note at the end of this table. |
| scan | g_sf_wifi0.p_api->scan (g_sf_wifi0.p_ctrl, p_scan, p_count);This API scans the available SSIDs (that is, access points) in range. This function takes the Wi-Fi control structure as an argument and returns a list of SSIDs scanned by the WiFi module with the following parameters: - HW mode (enumeration a/b/g/n) - RSSI (unsigned integer 16 bits) - SSID (string) - BSSID (byte array of size 6 bytes) - Channel (unsigned integer 8 bits) - Security type (enumeration) - Encryption type(enumeration) - BSS type (enumeration) The Wi-Fi framework scan function takes the SSID count as an argument, which acts as an in/out parameter. It specifies the size of the scan result array and the Wi-Fi framework sets it to count the indicating number of scan results stored in the array. |
| ACLAdd | g_sf_wifi0.p_api->ACLAdd (g_sf_wifi0.p_ctrl, peer_device_mac);This API adds the given MAC address to the access control list. This function takes the Wi-Fi control structure and the MAC address as arguments. |
| ACLDelete | g_sf_wifi0.p_api->ACLDelete (g_sf_wifi0.p_ctrl, peer_device_mac);This API deletes the given MAC address from the access control list. This function takes the Wi-Fi control structure and MAC address as arguments. |
| multicastListAdd | g_sf_wifi0.p_api->multicastListAdd (g_sf_wifi0.p_ctrl, p_mac_addr);This API adds the given Multicast IP address to the multicast filer list. This function takes the Wi-Fi control structure and MAC address as arguments. |
| multicastListDelete | g_sf_wifi0.p_api->multicastListDelete (g_sf_wifi0.p_ctrl, p_mac_addr);This API deletes the given Multicast IP address from the multicast filer list. This function takes the Wi-Fi control structure and MAC address as arguments. |
| macAddressGet | g_sf_wifi0.p_api->macAddressGet (g_sf_wifi0.p_ctrl, p_mac);This API reads MAC address from WiFi module. This function takes the Wi-Fi control structure as argument and returns MAC address read from Wi-Fi module. |
| macAddressSet | g_sf_wifi0.p_api->macAddressSet (g_sf_wifi0.p_ctrl, p_mac);This API sets Wi-Fi module's MAC address. This function takes the Wi-Fi control structure and MAC address as arguments. |
| wpsStart | g_sf_wifi0.p_api->wpsStart(g_sf_wifi0.p_ctrl, &wps_data);This API starts WPS on device. The wpsStart function uses the following parameters passed to a structure to start WPS on device: - WPS method as Push-button or Pin - WPS pin. Used only with WPS pin method - WPS timeout value in seconds - Pointer to callback function to be called on change in client's connection status with AP or client connected/disconnected |
When device is provisioned in AP mode then arguments passed to callback will have only below valid fields,
While calling the sf_wifi_api_t::provisioningSet API function to provision the device in client mode, the framework will not call the callback function on the successful association with the AP or on a failure. When the device is provisioned in AP mode, if the client tries to connect with the AP using the wrong password, the callback will be called twice; first with the connected event and then immediately after with the disconnected event.
These APIs can be used to configure the Wi-Fi module when using an on-chip networking stack, which helps to configure the IP address for the interface and start/stop the DHCP server (when configured in the AP mode).
On-Chip Networking Stack Support Wi-Fi Framework Module API Summary
| Function Name | Example API Call and Description |
|---|---|
| open | g_sf_wifi_onchip_stack0.p_api->open (g_sf_wifionchip_stack0.p_ctrl, g_sf_wifi_onchip_stack0.p_cfg);This API calls the WiFi framework open API which initializes the Wi-Fi module. |
| close | g_sf_wifi_onchip_stack0.p_api->close(g_sf_wifi_onchip_stack0.p_ctrl);This API calls the Wi-Fi framework close API which un-initializes the Wi-Fi module. |
| ipAddressCfg | g_sf_wifi_onchip_stack0.p_api->ipAddressCfg (g_sf_wifi_onchip_stack0.p_ctrl, p_cfg);This API configures the IP address of the interface using an on-chip networking stack. It provides facility to configure static IP address or using DHCP. |
| dhcpServerStart | g_sf_wifi_onchip_stack0.p_api->dhcpServerStart (g_sf_wifi_onchip_stack0.p_ctrl, p_start_ip, p_end_ip);This API starts the DHCP server on the interface (when configured in AP mode) using on-chip networking stack. It takes the range of IP addresses to be used by DHCP server. |
| dhcpServerStop | g_sf_wifi_onchip_stack0.p_api->dhcpServerStop (g_sf_wifi_onchip_stack0.p_ctrl);This API stops the DHCP server. |
| versionGet | g_sf_wifi_onchip_stack0.p_api->versionGet (&version);Retrieves the API version with the version pointer. |
These APIs can be used for BSD socket support using the GT202 on-chip stack implementation.
BSD Socket using GT202 On-Chip Stack Wi-Fi Framework Module API Summary
| Function Name | Example API Call and Description |
|---|---|
| open | g_sf_socket0.p_api->open (g_sf_socket0.p_ctrl, g_sf_socket0.p_cfg);This API initializes the networking interface. |
| close | g_sf_socket0.p_api->close(g_sf_socket0.p_ctrl);This API closes the network interface. |
| versionGet | g_sf_socket0.p_api->versionGet (&version);Retrieves the API version with the version pointer. |
Additionally, this implementation includes socket APIs which are compliant with BSD APIs. These APIs can be used by the application to perform data transfer using sockets. The following APIs are available:
More information is available for these APIs as described in the NetX BSD 4.3 Sockets API Compliancy Wrapper for NetX User Guide which can be found on the Synergy Gallery on the SSP page under the documentation tab in the Azure RTOS Component Documents for Renesas Synergy zip file.
The Synergy Wi-Fi framework supports the NetX/NetX-Duo Network Services Abstraction Layer. This includes the NetX/NetX-Duo driver, packet transmit and receive callback functions implementation.
NetX/NetX-Duo Driver Function
The NetX/NetX-Duo driver function takes the NetX IP instance, Wi-Fi framework instance and NSAL configuration as arguments. The NSAL configuration controls the behavior of transmit and receive callback functions. The NSAL configuration includes flags which indicates zero-copy support is enabled or disabled in transmit and receive path. The NetX/NetX-Duo driver functions implement various IP driver commands used by NetX/NetX-Duo. The interface attach command calls the Wi-Fi framework open API to initialize the Wi-Fi module. The initialize command calls the Wi-Fi framework macAddressGet API to read MAC address from the Wi-Fi module. The multicast-join command calls the Wi-Fi framework multicastListAdd API to add the given MAC address to multicast list. The multicast-leave command calls the Wi-Fi framework multicastListDelete API to delete the given MAC address from the multicast list. The Send/Broadcast command calls the Wi-Fi framework transmit API to transmit a packet.
NSAL Transmit Function
The NSAL transmit function takes the NetX IP instance, the NetX packet, the Wi-Fi framework instance and the NSAL configuration as arguments. If zero-copy support is enabled, then the same NetX packet is transferred from NetX to the Wi-Fi driver. If zero-copy is not supported, then it copies data from the NetX packet to the driver buffer. It calls the Wi-Fi framework transmit API, which passes the buffer/packet to the Wi-Fi driver for further transmission.
NSAL Receive Callback
The NSAL receive callback function takes the NetX IP instance, the packet buffer, the packet buffer length and the NSAL configuration as arguments. This callback is called from the Wi-Fi device driver. If zero-copy support is enabled, then the same NetX packet is transferred from the Wi-Fi driver to NetX. If zero-copy is not supported, then it copies data from the driver buffer to the NetX packet and then passes the NetX stack for further processing. It calls the Wi-Fi framework transmit API, which passes the buffer to the Wi-Fi driver for further transmission.
More information is available for these APIs as described in the NetX User Guide which can be found on the Synergy Gallery on the SSP page under the documentation tab in the Azure RTOS Component Documents for Renesas Synergy zip file.
The following table lists the Wi-Fi Framework specific error codes. These error codes are part of ssp_err_t.
Wi-Fi Framework Error Codes
| Error Codes | Description |
|---|---|
| SSP_ERR_WIFI_CONFIG_FAILED | Configuration failed. |
| SSP_ERR_WIFI_INIT_FAILED | Initialization failed. |
| SSP_ERR_WIFI_TRANSMIT_FAILED | Transmission failed. |
| SSP_ERR_WIFI_INVALID_MODE | Invalid mode specified. |
| SSP_ERR_WIFI_FAILED | WiFi failed. |
| SSP_ERR_WIFI_WPS_INVALID_START_INFO | Invalid input parameters. |
| SSP_ERR_WIFI_WPS_MULTIPLE_PB_SESSIONS | Another Push button session is already in progress. |
| SSP_ERR_WIFI_WPS_WALK_TIMER_TIMEOUT | WPS Timer expired. |
| SSP_ERR_WIFI_WPS_M2D_RECEIVED | M2D Error code received which means Registrar is unable to authenticate with the Enrollee. |
| SSP_ERR_WIFI_WPS_AUTHENTICATION_FAILED | WPS authentication failed. |
| SSP_ERR_WIFI_WPS_CANCELLED | WPS Request was not accepted by underlying driver. |
| SSP_ERR_WIFI_WPS_INVALID_PIN | Invalid WPS pin. |
The Wi-Fi framework provides a high-level interface for the application to configure the Wi-Fi module, provision the Wi-Fi module and perform data transfers. This simplifies application development and allows the same application code to be used across different Wi-Fi modules.
The following figure provides an overview of the Synergy Wi-Fi framework layered architecture:
The Wi-Fi framework implementation allows Wi-Fi modules with or without On-chip networking stack support to be integrated with the SSP low-level support blocks.
Wi-Fi Framework Module API Use Notes
Open:
When using the Wi-Fi framework module with NSAL, that is, with NetX/NeXDuo, the application should not call the Wi-Fi framework module sf_wifi_api_t::open API directly; instead, it should call the NetX nx_ip_create() API, which internally calls sf_wifi_api_t::open API from the NetX driver.
When using the On chip networking stack, the application should call the sf_wifi_api_t::open API from the BSD socket interface, which internally calls the Wi-Fi framework sf_wifi_api_t::open API.
Close:
When using the Wi-Fi framework module with NSAL, that is, with NetX/NetX Duo, the application should call the NetX nx_ip_delete() API directly.
When using the On chip networking stack, the application should call the sf_wifi_api_t::close API from the BSD socket interface, which internally calls the Wi-Fi framework module sf_wifi_api_t::close API.
ProvisioningSet:
When the device is provisioned in client mode, the callback will be called when the connection with the AP is lost and re-established. When the device is provisioned in AP mode, this callback is called when any client connects/disconnects with the AP. When the device is provisioned in client mode, the arguments passed to the callback will only have the following valid field:
event = SF_WIFI_EVENT_AP_CONNECT or SF_WIFI_AP_DISCONNECT
When the device is provisioned in AP mode, the arguments passed to the callback will only have the following valid fields:
event = SF_WIFI_EVENT_CLIENT_CONNECT or SF_WIFI_CLIENT_DISCONNECT
mac_addr = MAC address of client.
While calling the sf_wifi_api_t::provisioningSet API to provision the device in client mode, the framework will not call the callback function on successful association with the AP or on a failure.
When the device is provisioned in AP mode, if the client tries to connect with the AP using the wrong password, the callback will be called twice, first with the connected event and then immediately after this, with the disconnected event.
InfoGet:
When the device is provisioned in the client mode, the RSSI value obtained using the sf_wifi_api_t::infoGet API call represents the SNR in dB. The noise_level and link_quality fields returned by the sf_wifi_api_t::infoGet API call do not contain any information - they are set to zero.
wpsStart:
If user wants to connect with Wi-Fi access-point, then user must know the SSID name, password and security type set on access-point. With this information, user can call Wi-Fi provisioning API to connect the device with given access-point. Wi-Fi Protected Setup (WPS) is a wireless network security standard that tries to make connections between a router and wireless devices faster and easier. WPS automatically configures the network name (SSID) and security key for the access point. User does not need to know the SSID and security key or passphrase when connecting WPS enabled devices.
There are 2 primary methods used in the WiFi Protected Setup:
Using the sf_wifi_api_t::wpsStart API, user can start WPS on device.
BSD Socket APIs:
While using the on-chip networking stack, applications can use all the BSD Socket APIs, all the On-Chip Networking Stack support APIs, and few Synergy Wi-Fi Framework APIs. The available Wi-Fi framework APIs are the sf_wifi_api_t::provisioningSet API, sf_wifi_api_t::provisioningGet API, sf_wifi_api_t::scan API, sf_wifi_api_t::macAddressGet, sf_wifi_api_t::macAddressSet API, and the sf_wifi_api_t::infoGet API.
This section describes how to include the Wi-Fi Framework module in an application using the SSP configurator.
To add the Wi-Fi Framework module to an application, simply add it to a HAL /Common thread using the stacks selection sequence given in the following table. (The default name for the Wi-Fi Framework module is g_sf_wifi0. This name can be changed in the associated Properties window.)
Wi-Fi Framework Module Selection Sequence
| Resource | ISDE Tab | Stacks Selection Sequence |
|---|---|---|
| g_sf_wifi0 GT202 Wi-Fi Device Driver on sf_wifi_gt202 | Threads | New Stack> Framework> Networking> WiFi> GT202 Wi-Fi Device Driver on sf_wifi_gt202 |
| g_sf_wifi_onchip_stack0 On-Chip Stack on Gt202 Wi-Fi Framework | Threads | New Stack> Framework> Networking> WiFi> On-Chip Stack on Gt202 Wi-Fi Framework |
| g_sf_socket0 BSD Socket using On-Chip Stack on Gt202 Wi-Fi Framework | Threads | New Stack> Framework> Networking> WiFi> BSD Socket using On-Chip Stack on Gt202 Wi-Fi Framework |
| g_sf_el_nx0 NetX Port using Wi-Fi Framework on sf_wifi_nsal_nx | Threads | New Stack> Framework> Networking> WiFi> NetX Port using Wi-Fi Framework on sf_wifi_nsal_nx |
When the Wi-Fi Framework module on sf_wifi is added to the thread stack as shown in the following figure, the configurator automatically adds any needed lower‑level modules. Any modules needing additional configuration information have the box text highlighted in Red. Modules with a Gray band are individual modules that stand alone. Modules with a Blue band are shared or common; they need only be added once and can be used by multiple stacks. Modules with a Pink band can require the selection of lower-level modules; these are either optional or recommended. (This is indicated in the block with the inclusion of this text.) If the addition of lower-level modules is required, the module description includes Add in the text. Clicking on any Pink banded modules brings up the New icon and displays possible choices.
The Wi-Fi Framework module must be configured by the user for the desired operation. The SSP configuration window will automatically identify (by highlighting the block in red) any required configuration selections, such as interrupts or operating modes, which must be configured for lower-level modules in order to ensure successful operation. Furthermore, only those properties that can be changed without causing conflicts are available for modification. Other properties are 'locked' and are not available for changes, and are identified with a lock icon for the 'locked' property in the Properties window in the ISDE. This approach simplifies the configuration process and makes it much less error-prone than previous 'manual' approaches to configuration. The available configuration settings and defaults for all the user-accessible properties are given in the Properties tab within the SSP configurator, and are shown in the following tables for easy reference.
Configuration Settings for the BSD Socket Using GT202 On-Chip Stack on GT202 Wi-Fi Framework
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enable or disable the parameter checking. |
| Name (Must be a valid C Symbol) | g_sf_socket0 | Module name. |
Configuration Settings for the On-Chip Stack on GT202 Wi-Fi Framework
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enable or disable the parameter checking. |
| Name (Must be a valid C Symbol) | g_sf_wifi_onchip_stack0 | Module name. |
Configuration Settings for the NetX Port using Wi-Fi Framework on sf_wifi_nsal_nx
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enable or disable the parameter checking. |
| Name (Must be a valid C Symbol) | g_sf_el_nx0 | Module name. |
Configuration Settings for the Wi-Fi Device Driver on sf_wifi_gt202
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enable or disable the parameter checking. |
| On-Chip Stack Support | Enabled, Disabled Default: Disabled | On-chip stack support selection. |
| Driver Heap Size in Bytes (Minimum 8192 bytes) | 8192 | Driver heap size selection. |
| Name (Must be a valid C symbol) | g_sf_wifi0 | Module name. |
| Hardware Mode | 802.11a, 802.11b, 802.11g, 802.11n Default: 802.11n | Hardware mode selection. |
| Transmit (TX) Power (Valid Range 1-17) | 10 | Transmit power selection. |
| Ready/Clear to Send (RTS/CTS) Flag | Enabled, Disabled Default: Enabled | Ready/Clear to send selection. |
| Delivery Traffic Indication Message (DTIM) Interval (Valid Range: 1-255) | 3 | Delivery traffic indication message interval selection. |
| Broadcast SSID (AP mode only) | Enabled, Disabled Default: Enabled | Broadcast SSID selection. |
| Beacon Interval in Microseconds (AP mode only and must be greater than 1023) | 1024 | Beacon interval in microseconds selection. |
| Station inactivity timeout in seconds (AP mode only and must be greater than 0) | 100 | Station inactivity timeout selection. |
| Requested High Throughput | Enabled, Disabled Default: Disabled | Requested high throughput selection. |
| Reset Pin (must be a valid C symbol) | IOPORT_PORT_06_PIN_00 | Reset pin selection. |
| Slave Select Pin (SSL)(Must be a valid C symbol) | IOPORT_PORT_01_PIN_03 | Slave select pin selection. |
| GT202 Driver Task Thread Priority (Modifying Task Thread Priority may cause Driver to malfunction) | 5 | GT202 driver task thread priority selection. |
| Callback | NULL | Callback selection. |
| Support NetX Packet Chaining | Enabled, Disabled Default: Enabled | Support NetX packet chaining selection. |
In some cases, settings other than the defaults can be desirable. For example, it might be useful to select different screen sizes. The configurable properties for the lower-level stack modules are given in the following sections for completeness and as a reference.
Typically, only a small number of settings must be modified from the default for lower-level drivers as indicated with red text in the thread stack block. Notice that some of the configuration properties must be set to a certain value for proper framework operation and will be locked to prevent user modification. The following tables identify all the settings within the properties section for the lower-level modules:
Configuration Settings for the SPI HAL Module on r_rspi
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enable or disable the parameter error checking. |
| Name | g_spi0 | Module name. |
| Channel | 0 | SCI or SPI Channel number to which the device has been connected. |
| Operating Mode | Master | Configure as a Master or Slave device. Note: Current version of SSP supports only SPI Master mode. |
| Clock Phase | Data sampling on even edge, data variation on odd edge | Data sampling on odd or even clock edge. |
| Clock Polarity | High when idle | Clock level when idle. |
| Mode Fault Error | Disable | Indicates Mode fault error (master/slave conflict) flag. |
| Bit Order | MSB First | Select transmit order MSB/LSB first. |
| Bitrate | 500000 | Transmission or reception rate. Bits per second. |
| Callback | NULL | Optional Callback function pointer. |
| SPI Mode | Clock synchronous operation | Select spi or clock syn mode operation. |
| Slave Select Polarity(SSL0) | Active Low | Select SSL0 signal polarity. |
| Slave Select Polarity(SSL1) | Active Low | Select SSL1 signal polarity. |
| Slave Select Polarity(SSL2) | Active Low | Select SSL2 signal polarity. |
| Slave Select Polarity(SSL3) | Active Low | Select SSL3 signal polarity. |
| Select Loopback1 | Normal | Select loopback1. |
| Select Loopback2 | Normal | Select loopback2. |
| Enable MOSI Idle State | Disable | Select MOSI idle fixed value and selection. |
| MOSI Idle State | MOSI Low | Select mosi idle fixed value and selection. |
| Enable Parity | Disable | Enable/disable parity. |
| Parity Mode | Parity Even | Select parity. |
| Select SSL(Slave Select) | SSL0 | Select which slave to use; 0-SSL0; 1-SSL1; 2-SSL2; 3-SSL3. |
| Select SSL Level After Transfer | SSL Level Do Not Keep | Select SSL level after transfer completion; 0-negate; 1-keep. |
| Clock Delay Enable | Clock Delay Disable | Clock delay enable selection. |
| Clock Delay Count | Clock Delay 1 RSPCK | Clock delay count selection. |
| SSL Negation Delay Enable | Negation Delay Disable | SSL negation delay enable selection. |
| Negation Delay Count | Negation Delay 1 RSPCK | Negation delay count selection. |
| Next Access Delay Enable | Next Access Delay Disable | Next access delay enable selection. |
| Next Access Delay Count | Next Access Delay 1 RSPCK | Next access delay count selection. |
| Receive Interrupt Priority | Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX) Default: Priority 12 | Receive interrupt priority selection. |
| Transmit Interrupt Priority | Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX) Default: Priority 12 | Transmit interrupt priority selection. |
| Transmit End Interrupt Priority | Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX) Default: Priority 12 | Transmit end interrupt priority selection. |
| Error Interrupt Priority | Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX) Default: Priority 12 | Error interrupt priority selection. |
Configuration Settings for the Transfer Driver on r_dtc Event SPI0 TXI
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Selects if code for parameter checking is to be included in the build. |
| Software Start | Enabled, Disabled Default: Disabled | Software start selection. |
| Linker section to keep DTC vector table | .ssp_dtc_vector_table | Linker section to keep DTC vector table selection. |
| Name | g_transfer0 | Module name. |
| Mode | Normal | Mode selection. |
| Transfer Size | 1 Byte, 2 Bytes, 4 Bytes Default: 2 Bytes | Transfer size selection. Note: For WiFi GT202 module, this property should be set to 1 Byte. |
| Destination Address Mode | Fixed | Destination address mode selection. |
| Source Address Mode | Incremented | Source address mode selection. |
| Repeat Area (Unused in Normal Mode | Source | Repeat area selection. |
| Interrupt Frequency | After all transfers have completed | |
| Destination Pointer | NULL | Destination pointer selection. |
| Source Pointer | NULL | Source pointer selection. |
| Number of Transfers | 0 | Number of transfers selection. |
| Number of Blocks (Valid only in Block Mode) | 0 | Number of blocks selection. |
| Activation Source (Must enable IRQ) | Event SPI0 TXI | Activation source selection. |
| Auto Enable | False | Auto enable selection. |
| Callback (Only valid with Software start) | NULL | Callback selection. |
| ELC Software Event Interrupt Priority | Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX), Disabled Default: Disabled | ELC Software Event interrupt priority selection. |
Configuration Settings for the Transfer Driver on r_dtc Event SPI0 RXI
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Selects if code for parameter checking is to be included in the build. |
| Name | g_transfer1 | Module name. |
| Mode | Normal | Mode selection. |
| Transfer Size | 1 Byte, 2 Bytes, 4 Bytes Default: 2 Bytes | Transfer size selection. Note: For WiFi GT202 module, this property should be set to 1 Byte. |
| Destination Address Mode | Incremented | Destination address mode selection. |
| Source Address Mode | Fixed | Source address mode selection. |
| Repeat Area (Unused in Normal Mode | Destination | Repeat area selection. |
| Interrupt Frequency | After all transfers have completed | Interrupt frequency selection. |
| Destination Pointer | NULL | Destination pointer selection. |
| Source Pointer | NULL | Source pointer selection. |
| Number of Transfers | 0 | Number of transfers selection. |
| Number of Blocks (Valid only in Block Mode) | 0 | Number of blocks selection. |
| Activation Source (Must enable IRQ) | Event SPI0 RXI | Activation source selection. |
| Auto Enable | False | Auto enable selection. |
| Callback (Only valid with Software start) | NULL | Callback selection. |
| ELC Software Event Interrupt Priority | Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX), Disabled Default: Disabled | ELC Software Event interrupt priority selection. |
Configuration Settings for the SPI HAL Module on r_sci_spi
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Enable or disable the parameter error checking. |
| Name | g_spi0 | Module name. |
| Channel | 0 | SCI or SPI Channel number to which the device has been connected. |
| Operating Mode | Master | Configure as a Master or Slave device. Note: Current version of SSP supports only SPI Master mode. |
| Clock Phase | Data sampling on even edge, data variation on odd edge | Data sampling on odd or even clock edge. |
| Clock Polarity | High when idle | Clock level when idle. |
| Mode Fault Error | Disable | Indicates Mode fault error (master/slave conflict) flag. |
| Bit Order | MSB First | Select transmit order MSB/LSB first. |
| Bitrate | 100000 | Transmission or reception rate. Bits per second. |
| Bit Rate Modulation Enable | Enable, Disable Default: Enable | Bitrate Modulation Function enable or disable. |
| Callback | NULL | Optional Call back function pointer. |
| Receive Interrupt Priority | Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX) Default: Priority 12 | Bitrate Modulation Function enable or disable. Note: This is applicable only for SCI SPI. |
| Transmit Interrupt Priority | Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX) Default: Priority 12 | Transmit interrupt priority selection. |
| Transmit End Interrupt Priority | Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX) Default: Priority 12 | Transmit end interrupt priority selection. |
| Error Interrupt Priority | Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX) Default: Priority 12 | Error interrupt priority selection. |
Configuration Settings for the Transfer Driver on Event SCI0 TXI
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Selects if code for parameter checking is to be included in the build. |
| Software Start | Enabled, Disabled Default: Disabled | Software start selection. |
| Linker section to keep DTC vector table | .ssp_dtc_vector_table | Linker section to keep DTC vector table selection. |
| Name | g_transfer0 | Module name. |
| Mode | Normal | Mode selection. |
| Transfer Size | 1 Byte | Transfer size selection. |
| Destination Address Mode | Fixed | Destination address mode selection. |
| Source Address Mode | Incremented | Source address mode selection. |
| Repeat Area (Unused in Normal Mode | Source | Repeat area selection. |
| Interrupt Frequency | After all transfers have completed | Interrupt frequency selection. |
| Destination Pointer | NULL | Destination pointer selection. |
| Source Pointer | NULL | Source pointer selection. |
| Number of Transfers | 0 | Number of transfers selection. |
| Number of Blocks (Valid only in Block Mode) | 0 | Number of blocks selection. |
| Activation Source (Must enable IRQ) | Event SCI0 TXI | Activation source selection. |
| Auto Enable | False | Auto enable selection. |
| Callback (Only valid with Software start) | NULL | Callback selection. |
| ELC Software Event Interrupt Priority | Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX), Disabled Default: Disabled | ELC Software Event interrupt priority selection. |
Configuration Settings for the Transfer Driver on r_dtc Event SCI0 RXI
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Selects if code for parameter checking is to be included in the build. |
| Software Start | Enabled, Disabled Default: Disabled | Software start selection. |
| Linker section to keep DTC vector table | .ssp_dtc_vector_table | Linker section to keep DTC vector table selection. |
| Name | g_transfer1 | Module name. |
| Mode | Normal | Mode selection. |
| Transfer Size | 1 Byte | Transfer size selection. |
| Destination Address Mode | Incremented | Destination address mode selection. |
| Source Address Mode | Fixed | Source address mode selection. |
| Repeat Area (Unused in Normal Mode | Destination | Repeat area selection. |
| Interrupt Frequency | After all transfers have completed | Interrupt frequency selection. |
| Destination Pointer | NULL | Destination pointer selection. |
| Source Pointer | NULL | Source pointer selection. |
| Number of Transfers | 0 | Number of transfers selection. |
| Number of Blocks (Valid only in Block Mode) | 0 | Number of blocks selection. |
| Activation Source (Must enable IRQ) | Event SCI0 RXI | Activation source selection. |
| Auto Enable | False | Auto enable selection. |
| Callback (Only valid with Software start) | NULL | Callback selection. |
| ELC Software Event Interrupt Priority | Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX), Disabled Default: Disabled | ELC Software Event interrupt priority selection. |
Configuration Settings for the External IRQ Driver on r_icu
| ISDE Property | Value | Description |
|---|---|---|
| Parameter Checking | BSP, Enabled, Disabled Default: BSP | Parameter checking setting enables or disables the addition of parameter checking code. |
| Name | g_external_irq0 | Module name. |
| Channel | 0 | Specifies the hardware IRQ channel used. |
| Trigger | Falling | Selection for trigger event mode |
| Digital Filtering | Disabled | Digital filter enable/disable. |
| Digital Filtering Sample Clock (Only valid when Digital Filtering is Enabled) | PCKL/64 | Sets noise filter sampling period. |
| Interrupt enabled after initialization | TRUE | Determines if the interrupt is enabled immediately after initialization. |
| Callback | custom_hw_irq_isr | A user callback function can be registered in external_irq_api_t::open. If this callback function is provided, it is called from the interrupt service routine (ISR) each time the IRQn triggers. Warning: Since the callback is called from an ISR, care should be taken not to use blocking calls or lengthy processing. Spending excessive time in an ISR can affect the responsiveness of the system. |
| Interrupt Priority | Priority 0 (highest), Priority 1:14 Priority 15 (lowest - not valid if using ThreadX) Default: Priority 12 | Interrupt priority selection. |
The Wi-Fi Framework module uses the clocks required for the specific selections of the lower-level modules (such as the SPI).
The Wi-Fi Framework module uses input and output pins depending on the selections of the low-level modules (such as the SPI or the IRQ).
The following description is a high-level overview of some typical Wi-Fi use cases. A more detailed description and a working application project (which is too lengthy to include in this document), is available on the Renesas web site. Just search for the associated application note document number, r11an0226eu, in the top page search bar on www.Renesas.com. It is highly recommended that you use the application note to augment the summary descriptions found in this document.
Each of the Wi-Fi framework implementations are treated differently in a target application. The typical control flow for initialization, packet transmission using NetX/NetX Duo, packet reception using NetX/NetX Duo and using an on-chip networking stack are of particular interest. Example flow diagrams for some typical implementations of these functions are shown as follows:
Wi-Fi WPS Connection Methods
Flow diagrams for implementations of WPS connections for an application in both Station and AP modes for PIN and Button based connections are available in a Knowledge Base article here: https://en-support.renesas.com/knowledgeBase/18380440