Closed XZ-Niupitang closed 5 months ago
Hello @XZ-Niupitang ,
Will check this in detail and come up with initial response tomorrow
Hello @XZ-Niupitang ,
Will check this in detail and come up with initial response tomorrow
Thank you for your reply. After checking several times, I found that the SPI communication harness was reversed. Now I can open AP mode and connect to WIFI normally. But there is still a problem. The transmission rate in AP mode is too slow, only more than 80 kb/s. Is there any good way to improve this situation? Can increasing the SPI rate improve this situation?
Can you please state the performance you receive in raw throughput in rx and tx direction? I think, before jumping to higher levels and wifi, this is important metric to understand and have confidence in transport layer.
Higher layers have n number of factors for the performance gain/loose. however, raw throughput would depict how the spi performs without other layer intervention
Can you please state the performance you receive in raw throughput in rx and tx direction? I think, before jumping to higher levels and wifi, this is important metric to understand and have confidence in transport layer.
Higher layers have n number of factors for the performance gain/loose. however, raw throughput would depict how the spi performs without other layer intervention
Thanks for your reply. My question is how to test the communication performance of the SPI interface of the TDA4VM chip? This should be determined by hardware.
You are absolutely right. It depends on hardware & underlying spi driver for you SoC. You can first test with spidev to understand the performance.
Then you can run raw throughout test in tx and rx to assess the transport speed. If any issues here, higher layers will suffer, including ESP-Hosted driver.
Make sure checksum is enabled using IDF.py menuconfig -> 'example configuration ', which would make sure the messages integrity is tested.
Also please check porting guide
You are absolutely right. It depends on hardware & underlying spi driver for you SoC. You can first test with spidev to understand the performance.
Then you can run raw throughout test in tx and rx to assess the transport speed. If any issues here, higher layers will suffer, including ESP-Hosted driver.
Make sure checksum is enabled using IDF.py menuconfig -> 'example configuration ', which would make sure the messages integrity is tested.
Also please check porting guide
Thank you for your reply. After trying to increase the communication rate to 20Mhz, the file transfer speed reached 420kb/s. Is there room for further optimization? I will post the throughput test results later.
Considering 20Mhz , 420 kBps = 3.3Mbps is extremely slow.
Anyway, my input would be the same, to https://github.com/espressif/esp-hosted/issues/402#issuecomment-2167440971
The test you perform have n number of factors in consideration. Please test raw throughout to assess your transport instead of jumping to iperf or file download test, asking with checksum enabled.
Considering 20Mhz , 420 kBps = 3.3Mbps is extremely slow.
Anyway, my input would be the same, to #402 (comment)
The test you perform have n number of factors in consideration. Please test raw throughout to assess your transport instead of jumping to iperf or file download test, asking with checksum enabled.
I understand. I will continue to look for problems later. If there are any findings or questions, I will synchronize them in time. Thank you.
The main control chip is TI's TDA4VM, and the onboard WIFI chip is ESP32C6. It can communicate with the onboard wifi module normally through USB. After porting the esp_host_fg driver to TDA4VM, it is found that TDA4VM can send SPI signal communication normally, but ESP32C6 does not respond normally, MISO has no level change, and the GPIO interrupts of HandShack and DateRead are normal.
After checking the PCB, I found that there is no broken wire, but there is currently no normal communication. What troubleshooting ideas do you have?
WIFI LOGO :
The modified (esp_spi_transaction ) function code is as follows
The system log of the mounted driver is as follows