Files

iranl 6c74d62531 P4 fixes

2025-06-27 12:09:24 +02:00

31 KiB

Raw Blame History

ESP-Hosted SDIO Operation

Sections 3 below covers the hardware requirements like external pull-up requirement, possible efuse burning for co-processor and other hardware aspects to consider for SDIO.

Section 4 to 8 covers the complete step-wise setup co-processor and host with SDIO, for 1-bit and 4-bit SDIO.

If you wish to skip the theory, you can refer the Quick Start Guide below. For quick navigation, please unfold the Table of Contents below.

Table of Contents

1. [Quick Start Guide](#1-quick-start-guide)

Introduction
Hardware Considerations || 3.1 General Considerations || 3.2 Pull-up Resistors || 3.3 Voltage Levels & eFuse burning || 3.4 Jumper Wires || 3.5 PCB Design || 3.6 Advanced Considerations || 3.7 Testing Connections
Hardware Setup
Set-Up ESP-IDF
Flashing the Co-processor || 6.1 Create Co-processor Project || 6.2 Co-processor Config || 6.3 Co-processor Build || 6.4 Co-processor Flashing
Flashing the Host || 7.1 Select Example to Run in Hosted Mode || 7.2 Host Project Component Configuration || 7.3 Menuconfig, Build and Flash Host
Testing and Troubleshooting
Performance and Memory Usage || 9.1 Stream and Packet Mode || 9.2 Double Buffering on the Host || 9.3 Reducing Memory Usage || 9.4 Switching to Packet Mode
References

1 Quick Start Guide

This section provides a brief overview of how to get started with ESP-Hosted using SDIO mode. For detailed instructions on each step, please refer to the following sections:

4. Hardware Setup
5. Set-Up ESP-IDF
6. Flashing the Co-processor
7. Flashing the Host
8. Testing and Troubleshooting
9. Performance and Memory Usage

These sections will guide you through the process of flashing both the co-processor and host devices, setting up the hardware connections, and verifying successful communication.

2 Introduction

SDIO is a high-speed bus that uses the same SDMMC hardware protocol used for SD Cards, but with its own set of commands for communicating with SDIO aware peripherals.

Note

Only some ESP32 chips support the SDIO Protocol:

A. SDIO as Slave (Co-processor): ESP32, ESP32-C6
B. SDIO as Master: ESP32, ESP32-S3, ESP32-P4

3 Hardware Considerations

3.1 GPIO Configuration for SDIO

The SDIO interface can use almost any GPIO pins. For maximum speed and minimal delays, it is recommended to select the SDIO pin configuration that uses the dedicated IO_MUX pins. Hardware connections in later sections use IO_MUX pins, as much as possible. ESP32 only supports IO_MUX pins for SDIO. other chips may support other flexible pins using GPIO_Matrix, with small performance penalty.

3.2 Extra GPIO Signals Required

Extra GPIO signals are required for SDIO on Hosted and can be assigned to any free GPIO pins:

Reset signal: an output signal from the host to the co-processor. When asserted, the host resets the co-processor. This is done when ESP-Hosted is started on the host, to synchronise the state of the host and co-processor.

Note

The Reset signal suggested to connect to the EN or RST pin on the co-processor, It is however configurable to use another GPIO pin.

To configure this, use idf.py menuconfig on the co-processor: Example configuration ---> SDIO Configuration ---> Host SDIO GPIOs and set Slave GPIO pin to reset itself.

3.3 General Hardware Considerations

For SDIO, signal integrity is crucial, hence jumper wires are not recommended.
Jumper wires are only suitable for initial testing and prototyping.
If you wish, you can test SDIO 1-Bit mode using jumper cables, only for initial testing and prototyping. Pull-Ups are still mandatory for all, [CMD, DAT0, DAT1, DAT2, DAT3] irrespective how do you connect, using jumpers or PCB.
Ensure equal trace lengths for all SDIO connections, whether using jumper wires or PCB traces.
Very strict requirement, to keep wires as short as possible, under 5 cm. Smaller the better.
Use the lower clock frequency like 5 MHz for evaluation. Once solution verified, optimise the clock frequency in increasing steps to max possible value. Max SDIO host clock frequency that all SDIO co-processors can work is upto 50 MHz.
Provide proper power supply for both host and co-processor devices. Lower or incorrect power supplies can cause communication issues & suboptimal performance.

3.4 Pull-up Resistors

SDIO requires external pull-up resistor (51 kOhm recommended) and clean signals for proper operation.
For this reason, it is not recommended to use jumper cables. Use PCB traces to connect between a Hosted Master and Co-processor.
For full requirements, refer to ESP-IDF SDIO pull-up resistor requirements at Pull-Up Requirements.

3.5 Voltage Levels & eFuse burning

SDIO expects all signals to be at 3.3V level. If you are using level shifter, ensure that the level shifter output is set to 3.3V.
If you use classic ESP32, there is good chance that you would need to burn the eFuse.
eFuse burning is one time and non reversible process. You may brick your device, if burn the eFuse incorrectly.
Please check full documentation at eFuse burning If your chip is listed explicitly, not to burn eFuse, you can ignore this.
This document covers below issues and their solutions:
- External pull-ups to be used on: CMD, DAT0, DAT1, DAT2, DAT3, with 51K Ohm recommended, irrespective of jumpers or PCB.
- Bootstrapping pin and DAT2 voltage issues and solution of eFuse burning, with complete procedure.

3.6 Jumper Wires (only for SDIO 1-Bit mode)

External Pull-ups mandatory for CMD, DAT0, DAT1, DAT2, DAT3 of 51 kOhm.
Smaller the better, strictly under 5 cm. All equal length.
Use high-quality, low-capacitance jumper wires.
Arrange wires to minimize crosstalk, especially for clock and data lines.
Possibly, use twisted pairs for clock and data lines to reduce electromagnetic interference.
If possible, use a ground wire between every signal wire to improve signal integrity.
Connect as many grounds as possible to improve common ground reference and reduce ground noise.

3.7 PCB Design

For optimal performance and reliability in production designs:

Ensure equal trace lengths for all SDIO signals (CLK, CMD, DAT0, DAT1, DAT2, DAT3) as much as possible. This practice, known as length matching, is crucial for maintaining signal integrity and reducing timing skew, especially at higher frequencies.
If perfect length matching is not possible, prioritize matching the clock (CLK) trace length with the data lines.
Use controlled impedance traces for high-speed signals.
Place bypass capacitors close to the power pins of both the host and co-processor devices.
Consider using series termination resistors on the clock and data lines to reduce reflections.
For high-speed designs, use a 4-layer PCB with dedicated power and ground planes.

3.8 Advanced Considerations

Calculate the maximum allowed trace length based on your clock frequency and PCB material.
Consider the capacitive load on the SDIO bus, especially for longer traces
For very high-speed designs, consider using differential signaling techniques.
Implement proper EMI/EMC design techniques to minimize electromagnetic interference.

4 Hardware Setup

Setting up the hardware involves connecting the master and co-processor devices via the SDIO pins and ensuring all extra GPIO signals are properly connected. Below is the table of connections for the SDIO setup between a host ESP chipset and another ESP chipset as co-processor:

Host Connections

SDIO-capable host microcontrollers (MCUs) can connect their GPIO lines to the co-processor as detailed in the table below.

GPIO Flexibility

The ESP32 supports SDIO host on fixed GPIOs.
The ESP32-S3 supports SDIO host on flexible GPIOs.
For the ESP32-P4, Slot 0 supports fixed GPIOs, while Slot 1 supports flexible GPIOs.

By default, Slot 1 is used on the ESP32-P4 to take advantage of its flexible pin mapping; however, Slot 0 is also supported. Parallel access to both Slot 0 and Slot 1 is supported for all hosts.

Signal	ESP32	ESP32-S3
CLK	14	19
CMD	15+ext-pull-up	47+ext-pull-up
D0	2+ext-pull-up	13+ext-pull-up
D1	4+ext-pull-up	35+ext-pull-up
D2	12+ext-pull-up	20+ext-pull-up
D3	13+ext-pull-up	9+ext-pull-up
Reset Out	5	42

ESP32-P4-Function-EV-Board Host Pin Mapping

Signal	ESP32-P4 with ESP32-C6 Co-processor	ESP32-P4 with ESP32-C5 Co-processor
CLK	18	33
CMD	19+ext-pull-up	4+ext-pull-up
D0	14+ext-pull-up	20+ext-pull-up
D1	15+ext-pull-up	23+ext-pull-up
D2	16+ext-pull-up	21+ext-pull-up
D3	17+ext-pull-up	22+ext-pull-up
Reset Out	54	53

Co-processor connections

SDIO slave provider ESP chips are : ESP32, ESP32-C5, ESP32-C6.
All these chips have fixed GPIOs SDIO support.

Signal	ESP32	ESP32-C6	ESP32-C5
CLK	14	19	9
CMD	15	18	10
D0	2	20	8
D1	4	21	7
D2	12	22	14
D3	13	23	13
Reset In	EN	EN/RST	RST

Note

External pull-ups are mandatory

5 Set-Up ESP-IDF

Before setting up the ESP-Hosted co-processor & host for SDIO mode, ensure that ESP-IDF is properly installed and set up on your system.

5.1 Installer Way

Windows
- Install and setup ESP-IDF on Windows as documented in the Standard Setup of Toolchain for Windows.
- Use the ESP-IDF Powershell Command Prompt for subsequent commands.

Linux or MacOS

For bash:

bash docs/setup_esp_idf__latest_stable__linux_macos.sh

For fish:

fish docs/setup_esp_idf__latest_stable__linux_macos.fish

5.2 Manual Way

Please follow the ESP-IDF Get Started Guide for manual installation.

6. Flashing the Co-processor

Supported Co-processor Targets	ESP32	ESP32-C6	ESP32-C5

There are four steps to flash the ESP-Hosted co-processor firmware:

6.1 Create Co-processor Project

Navigate to the directory where you want to create the co-processor project.
Use the following command to create a new project:
```
idf.py create-project <project_name>
```
Replace <project_name> with your desired project name.

6.2 Co-processor Config

Navigate to the project directory:
```
cd <project_name>
```
Configure the project:
```
idf.py menuconfig
```

6.2.1 Transport config

Navigate to "Example configuration" -> "Transport layer"
Select "SDIO"

6.2.2 Any other config

Optionally, Configure any additional SDIO-specific settings like co-processor GPIOs, SDIO Mode, SDIO timing,etc.

Generated files

Generated config files are (1) sdkconfig file and (2) internal sdkconfig.h file.
Please note, any manually changes done to these generated files, would not take effect.

Defaulting specific config (Optional)

This is advanced option, so please be careful.
To mark some config options as default, you can add specific config line in file, sdkconfig.defaults.<target>. So whenever next time building, you do not need to re-configure.

6.3 Co-processor Build

Build the project:
```
idf.py build
```

6.4 Co-processor Flashing

There are two methods to flash the ESP-Hosted co-processor firmware:

6.4.1 Serial Flashing (Initial Setup)

For the initial setup or when OTA is not available, use serial flashing.

Flash the co-processor firmware using

idf.py -p <co-processor_serial_port> flash

Note

If you are not able to flash the co-processor, there might be a chance that host is not allowing to to do so.

Put host in bootloader mode using following command and then retry flashing the co-processor

esptool.py -p **<host_serial_port>** --before default_reset --after no_reset run

Flash the co-processor and log the output:

idf.py -p <co-processor_serial_port> flash monitor

6.4.2 Co-processor OTA Flashing (Subsequent Updates)

For subsequent updates, you can re-use ESP-Hosted-MCU transport, as it should be already working. While doing OTA, Complete co-processor firmware image is not needed and only co-processor application partition, 'network_adapter.bin' need to be re-flashed remotely from host.

Ensure your co-processor device is connected and communicating with the host with existing ESP-Hosted-MCU.
Create a web server You can re-use your existing web server or create a new locally for testing. Below is example to do it.

Make a new directory so that web server can be run into it and navigate into it
Create simple local web server using python3
```
python3 -m http.server 8080
```

Copy the co-processor app partition network_adapter.bin in the directory where you created the web server.

The network_adapter.bin can be found in your co-processor project build at <co-processor_project>/build/network_adapter.bin

Verify if web server is set-up correctly

Open link http://127.0.0.1:8080 in the browser and check if network_adapter.bin is available.
Right click and copy the complete URL of this network_adapter.bin and note somewhere.

On the host side, use the esp_hosted_slave_ota function to initiate the OTA update:
```
#include "esp_hosted.h"

const char* image_url = "http://example.com/path/to/network_adapter.bin"; //web server full url
esp_err_t ret = esp_hosted_slave_ota(image_url);
if (ret == ESP_OK) {
    printf("co-processor OTA update failed[%d]\n", ret);
}
```
This function will download the firmware in chunk by chunk as http client from the specified URL and flash it to the co-processor device through the established transport. In above web server example, You can paste the copied url earlier.
Monitor the OTA progress through the console output on both the host and co-processor devices.

Note

A. The esp_hosted_slave_ota function is part of the ESP-Hosted-MCU API and handles the OTA process through the transport layer.
B. Ensure that your host application has web server connectivity to download the firmware file.
C. The co-processor device doesn't need to be connected to the web server for this OTA method.

7 Flashing the Host

Supported Host Targets	Any ESP chipset	Any Non-ESP chipset

Any host having SDIO master can be used as host. Please make sure the hardware configurations, like external pull-ups are installed correctly. Tthe voltage at SDIO pins is expected to be 3v3 volts.

ESP chipsets as SDIO master
- ESP as host could be one of ESP32, ESP32-S3, ESP32-P4.
- For ESP32 as host, may need additional eFuse burning for voltage correction on one of data pin. ESP32-S3 and ESP32-P4 does not need this.
Non ESP SDIO Master
- Any other host having SDIO master can be used as host. Please make sure the hardware configurations, like (external Pull-up Resistors) are installed correctly. Tthe voltage at SDIO pins is expected to be 3v3 volts.
Pull-ups required for CMD, DAT0, DAT1, DAT2, DAT3 lines (for both 1-Bit and 4-Bit SDIO)
eFuse burning may be required for classic ESP32.
Pull-Up and eFuse burning is detailed in (3) Hardware Considerations

7.1 Select Example to Run in Hosted Mode

Select an example from the ESP-IDF examples directory that you wish to run in ESP-Hosted mode. All Wi-Fi and Bluetooth examples are supported. For simplicity and demonstration purposes, we will use the ESP-IDF iperf example.

7.2 Host Project Component Configuration

Now that ESP-IDF is set up, follow these steps to prepare the host:

1. Navigate to the iperf example in your ESP-IDF directory:

cd $IDF_PATH/examples/wifi/iperf

2. Dependency components

Add the required components to the project's idf_component.yml file:

idf.py add-dependency "espressif/esp_wifi_remote"
idf.py add-dependency "espressif/esp_hosted"

3. Remove conflicting configuration

Open the main/idf_component.yml file and remove/comment the following block if present:

# ------- Delete or comment this block ---------
espressif/esp-extconn:
  version: "~0.1.0"
  rules:
    - if: "target in [esp32p4]"
# -----------------------------------

This step is necessary because esp-extconn and esp-hosted cannot work together.

4. Disable native Wi-Fi if available

If your host ESP chip already has native Wi-Fi support, disable it by editing the components/soc/<soc>/include/soc/Kconfig.soc_caps.in file and changing all WIFI related configs to n.

If you happen to have both, host and co-processor as same ESP chipset type (for example two ESP32-C2), note an [additional step](docs/troubleshooting/#1-esp-host-to-evaluate-already-has-native-wi-fi)

7.3 Menuconfig, Build and Flash Host

1. High performance configurations

This is optional step, suggested for high performance applications.

If using ESP32-P4 as host:

Remove the default sdkconfig.defaults.esp32p4 file.

Create a new sdkconfig.defaults.esp32p4 file with the following content:

CONFIG_ESP_WIFI_STATIC_RX_BUFFER_NUM=16
CONFIG_ESP_WIFI_DYNAMIC_RX_BUFFER_NUM=64
CONFIG_ESP_WIFI_DYNAMIC_TX_BUFFER_NUM=64
CONFIG_ESP_WIFI_AMPDU_TX_ENABLED=y
CONFIG_ESP_WIFI_TX_BA_WIN=32
CONFIG_ESP_WIFI_AMPDU_RX_ENABLED=y
CONFIG_ESP_WIFI_RX_BA_WIN=32

CONFIG_LWIP_TCP_SND_BUF_DEFAULT=65534
CONFIG_LWIP_TCP_WND_DEFAULT=65534
CONFIG_LWIP_TCP_RECVMBOX_SIZE=64
CONFIG_LWIP_UDP_RECVMBOX_SIZE=64
CONFIG_LWIP_TCPIP_RECVMBOX_SIZE=64

CONFIG_LWIP_TCP_SACK_OUT=y

For other hosts also, you can merge above configs in corresponding `sdkconfig.defaults.esp32XX` file.

2. Set environment for your host ESP chip:

idf.py set-target <host_target>

Replace <host_target> with your specific ESP chip (e.g., esp32, esp32s3, esp32p4).

3. Flexible Menuconfig configurations

idf.py menuconfig

ESP-Hosted-MCU host configurations are available under "Component config" -> "ESP-Hosted config"

Select "SDIO" as the transport layer
Change co-processor chipset currently in-use under, "Slave chipset to be used"
Change SDIO Bus Width to 1-bit or 4-bit based on the co-processor using "Hosted SDIO Configuration" -> "SDIO Bus Width"
Optionally, configure SDIO-specific settings like:

SDIO Host GPIO Pins
Lower SDIO Clock Speed You can use a lower clock speed to verify the connections. Start with a clock speed between 400 kHz to 20 MHz. To configure this, use Menuconfig on the Host: Component config ---> ESP-Hosted config ---> Hosted SDIO Configuration and set SDIO Clock Freq (in kHz). > [!NOTE] > > The actual clock frequency used is determined by the hardware. Use an oscilloscope or logic analyzer to check the clock frequency.
Using 1-bit SDIO Mode By default, SDIO operates in 4-Bit mode. You can set the SDIO Bus Width to 1-Bit. In 1-Bit mode, only DAT0 and DAT1 signals are used for data and are less affected by noise on the signal lines. This can help you verify that the SDIO protocol is working at the logical level, if you have issues getting 4-Bit SDIO to work on your prototype board.

To configure this, use Menuconfig on the Host: Component config ---> ESP-Hosted config ---> Hosted SDIO Configuration ---> SDIO Bus Width to 1 Bit.
SDIO Mode Packet or Streaming mode could be used, but co-processor has to use same SDIO mode used.

Note

Pull-ups are still required on DAT2 and DAT3 lines to prevent the SDIO slave from going into SPI mode upon startup.

After confirming the functionality of the 1-Bit SDIO mode, you can revert to the 4-Bit mode with PCB to benefit from increased data transfer rates. Using the previous configuration, switch back to 4 Bit.

4. Build the project:

idf.py build

5. Flash the firmware:

idf.py -p <host_serial_port> flash

6. Monitor the output:

```
idf.py -p <host_serial_port> monitor
```
- If host was put into bootloader mode earlier, it may need manual reset

8 Testing and Troubleshooting

After flashing both the co-processor and host devices, follow these steps to connect and test your ESP-Hosted SDIO setup:

Connect the hardware:
- Follow the pin assignments for SDIO as specified in Hardware Setup.
- Ensure all necessary connections are made, including power, ground, and the extra GPIO signals (Data_Ready and Reset).
Power on both devices. Apply correct input rating power for both chipsets.
Verify the connection:
- Check the serial output of both devices for successful initialization messages.
- Look for messages indicating that the SDIO transport layer has been established.

Logs at both sides:

Host:

I (522) transport: Attempt connection with slave: retry[0]
I (525) transport: Reset slave using GPIO[54]
I (530) os_wrapper_esp: GPIO [54] configured
I (535) gpio: GPIO[54]| InputEn: 0| OutputEn: 1| OpenDrain: 0| Pullup: 0| Pulldown: 0| Intr:0
I (1712) transport: Received INIT event from ESP32 peripheral
I (1712) transport: EVENT: 12
I (1712) transport: EVENT: 11
I (1715) transport: capabilities: 0xe8
I (1719) transport: Features supported are:
I (1724) transport:        - HCI over SDIO
I (1728) transport:        - BLE only
I (1732) transport: EVENT: 13
I (1736) transport: ESP board type is : 13

I (1741) transport: Base transport is set-up

Co-processor:

I (492) fg_mcu_slave: *********************************************************************
I (501) fg_mcu_slave:                 ESP-Hosted-MCU Slave FW version :: X.Y.Z

I (511) fg_mcu_slave:                 Transport used :: SDIO
I (520) fg_mcu_slave: *********************************************************************
I (529) fg_mcu_slave: Supported features are:
I (534) fg_mcu_slave: - WLAN over SDIO
I (538) h_bt: - BT/BLE
I (541) h_bt:    - HCI Over SDIO
I (545) h_bt:    - BLE only

Test basic functionality:
- The iperf example automatically attempts to connect to the configured Wi-Fi network. Watch the serial output for connection status.
- If the automatic connection fails, you can manually initiate a Wi-Fi scan and connection:
```
sta_scan
sta_connect <SSID> <password>
```
Additional commands to test:
- Get IP address: sta_ip
- Disconnect from Wi-Fi: sta_disconnect
- Set Wi-Fi mode: wifi_mode <mode> (where mode can be 'sta', 'ap', or 'apsta')

Advanced iperf testing: Once connected, you can run iperf tests:

Test Case	Host Command	External STA Command
UDP Host TX	`iperf -u -c <STA_IP> -t 60 -i 3`	`iperf -u -s -i 3`
UDP Host RX	`iperf -u -s -i 3`	`iperf -u -c <HOST_IP> -t 60 -i 3`
TCP Host TX	`iperf -c <STA_IP> -t 60 -i 3`	`iperf -s -i 3`
TCP Host RX	`iperf -s -i 3`	`iperf -c <HOST_IP> -t 60 -i 3`

Note: Replace <STA_IP> with the IP address of the external STA, and <HOST_IP> with the IP address of the ESP-Hosted device.

Tip

To measure the optimal performance, check out the Shield Box Test Setup.

Troubleshooting:
- Consider using a lower clock speed or checking your hardware setup if you experience communication problems.
- ESP-Hosted-MCU troubleshooting guide: docs/troubleshooting.md
Monitoring and debugging:
- Use the serial monitor on both devices to observe the communication between the host and co-processor.
- For more detailed debugging, consider using a logic analyzer to examine the SDIO signals.
- Use a logic analyzer or oscilloscope to verify the SDIO signals.
- Ensure that the power supply to both devices is stable and within the required voltage levels.

9 Performance and Memory Usage

Quick summary:

for maximum network performance, at the cost of more memory usage on host and co-processor, use SDIO Streaming Mode (default mode of operation)
for lower memory usage, at the cost of lower network performance, use SDIO Packet Mode

9.1 Stream and Packet Mode

The co-processor SDIO can operate in two modes: Streaming Mode and Packet Mode.

Streaming Mode	Packet Mode
Co-processor combines multiple queued Tx packets together into one large packet	Co-processor queues individual Tx packets
Host fetches the large packet as one SDIO transfer	Host fetches each packet one at a time
Host breaks the large packet back into individual packets to send to the Rx queue	Host sends each packet to the Rx queue
More efficient (less SDIO overhead), but requires more memory at Host to hold the large packet	Less efficient (higher SDIO overhead for each packet), but minimises memory required at Host

9.2 Double Buffering on the Host

The Host implements a double-buffering scheme to receive data. One thread fetches data (using hardware DMA) from the co-processor and stores it in one Rx buffer, while another thread breaks up previously received data into packets for processing.

9.3 Reducing Memory Usage in Streaming Mode

9.3.1 Host Receive

Note

Host Receive: Router --Network Data--> Co-processor --SDIO--> Host

In SDIO streaming mode, the host receives SDIO data from the co-processor in one large SDIO transfer. For this reason, Streaming mode consumes more heap memory compared to Packet mode, and has a higher throughput (less SDIO overhead).

For Host systems with high heap memory usage, you can reduce the amount of heap memory used by ESP-Hosted for buffers, at the cost of reduced throughput, by adjusting the number of Tx buffers used by the co-processor.

On the co-processor: run idf.py menuconfig ---> Example Configuration ---> SDIO Configuration and adjust SDIO Tx queue size. The default queue size is 20.

The table below shows the effect of changing SDIO Tx queue size on throughput and memory usage on the Host. The throughput numbers are obtained by using the RawTP option in ESP-Hosted to send / receive raw SDIO data.

SDIO Tx queue size	Host Rx Raw Throughput (Mbits/s)	Memory Used by Buffers (Tested)	Memory Used by Buffers (Theoretical)
5	54	12,288	15,360
10	70	26,624	30,720
15	76	41,984	46,080
20	80	56,320	61,440
25	82	65,536	76,800
30	84	65,536	92,160

Note

The SDIO packet size is 1536 bytes. The co-processor can send at most (Tx queue size) * 1536 bytes. Since the Host does double buffering, the theoretical Buffer Size needed is 2 * (Tx queue size) * 1536.

From the table above, throughput is more or less stagnant on and above Rx queue size of 25. For a good trade off between memory consumption vs performance, the Rx queue sizes are currently defaulted to 20.

9.3.2 Host Transmit

Note

Host Transmit: Host --SDIO--> Co-Processor --Network Data--> Router

To reduce memory usage on the co-processor, you can reduce the number of buffers the co-processor uses to receive data from the Host.

On the co-processor: run idf.py menuconfig ---> Example Configuration ---> SDIO Configuration and adjust SDIO Rx queue size. The default queue size is 20.

Reducing the number of Rx buffers on the co-processor can affect the Tx throughput from the Host if the number of Rx buffers is set to a small value.

9.4 Switching to Packet Mode

For mimimal memory usage with a lower throughput, you can switch to Packet Mode. To do this:

on the co-processor: run idf.py menuconfig ---> Example Configuration ---> SDIO Configuration and untoggle Enable SDIO Streaming Mode
on the host: run idf.py menuconfig ---> Component config ---> ESP-Hosted config ---> Hosted SDIO COnfiguration ---> SDIO Receive Optimization and select either No optimization or Always Rx Max Packet size. Always Rx Max Packet size will give a slightly higher throughput.

In Packet Mode, the host uses 2 * 1536 or 3,072 bytes of memory for Rx buffers.

with No optimization, Rx Raw Throughput is 33.0 Mbits/s
with Always Rx Max Packet size, Rx Raw Throughput is 33.2 Mbits/s

31 KiB Raw Blame History