Discussion of the feature/esp_as_mcu_host branch (EHM-23)

[Evlers]

Checklist

• Checked the issue tracker for similar issues to ensure this is not a duplicate.
• Provided a clear description of your suggestion.
• Included any relevant context or examples.

Issue or Suggestion Description

哈喽，时隔一年不到，我又回来了。
目前我已经基于feature/esp_as_mcu_host branch分支移植了wrapper层并通过了esp_wifi_init的无感调用。
但我对rpc_core.c的set_sync_resp_sem函数有点疑问！
在737行处创建了一个信号量：
https://github.com/espressif/esp-hosted/blob/83efce638beb0d59b641399df862b20e3aa12f36/host/drivers/rpc/core/rpc_core.c#L737
但是在738行的位置马上就使用阻塞方式获取信号量导致线程的阻塞：
https://github.com/espressif/esp-hosted/blob/83efce638beb0d59b641399df862b20e3aa12f36/host/drivers/rpc/core/rpc_core.c#L738
请问这里是有什么特殊的意义吗？

[mantriyogesh]

Please check the semaphore create function:
https://github.com/espressif/esp-hosted/blob/83efce638beb0d59b641399df862b20e3aa12f36/host/port/os_wrapper.c#L486-L510

We are releasing semaphore immediately after creation.
This is the reason, it is acquired after creation.

Anyway, To make it easily portable for any host port, this call needs to be replaced by,

g_h.funcs->_h_get_semaphore(app_req->rx_sem, 0);

this way, non-blocking way it would just cleanup the semaphore count, irrespective of port used

[Evlers]

ok, thank you !
I also gave a signal when I created it.
used to take after rpc creation.

[Evlers]

I have a very strange problem
I made sure I did all the initialization before scanning
But the scan results are always zero!

[mantriyogesh]

Slave side api returned error. That same error was sent back to host as return value.

Worth to check and compare return value with
https://docs.espressif.com/projects/esp-idf/en/stable/esp32/api-reference/network/esp_wifi.html#_CPPv428esp_wifi_scan_get_ap_recordsP8uint16_tP16wifi_ap_record_t

[Evlers]

Found the problem! Because I provided an invalid wifi_scan_config_t.

Now can connect to the Internet, hey hey

[mantriyogesh]

That's indeed great news. May we know which platform you have ported onto?
If it is fine for you, Someone else in future may also refer to you for same platform.

[Evlers]

I ported it to RT-Thread.
The spi device driver of rtthread is connected to the transport layer.
The network pair is connected to the wlan framework.
If you will allow me to PR, I will push a change on portability later.

[mantriyogesh]

That would be a great help, @Evlers .

I am not sure exactly right now, how or if we can take the PR over main branch, or how can we support it.

But still having PR would make it usable for RT-Thread port for someone else.

[Evlers]

My current porting mode is outside the esp-hosted directory,
that is, I do not modify the esp-hosted code(Modified some freertos apis and log print to the wrapper layer)
I think the main thing is to ensure the universal portability of esp-hosted, and then I will make a software package and add this esp-hosted as a submodule to perfectly support RT-Thread

[mantriyogesh]

Actually, the port layer in the current repo (esp-hosted**-mcu**) is simplified.

We also have added recently STM32 support (not yet on master), which we tried to make simplified as non-ESP-IDF port.
But not yet on the master. check

esp-hosted-stm32_non_IDF-port.tar.bzip2.zip

unzip ./esp-hosted-stm32_non_IDF-port.tar.bzip2.zip
tar xvf ./esp-hosted-stm32_non_IDF-port.tar.bzip2

[Evlers]

I wrap the port at the level above the esp-hosted directory.
Instead of compiling freertos port directory in the esp-hosted.

Good, I see ota functionality has been ported to this port layer, I can use it as a reference.