RIOT
RIOT copied to clipboard
RIOT-OS
cpu/esp*: add Kconfig
Contribution description
This PR adds Kconfig for ESP32 and ESP8266 CPUs as well as the ESP netdev drivers esp_wifi
and esp_now.
Testing procedure
Use examples/gnrc_networking with commands
USEMODULE='esp_wifi esp_now' make BOARD=esp32-wroom-32 -C examples/gnrc_networking menuconfig
USEMODULE='esp_wifi esp_now' make BOARD=esp8266-esp-12x -C examples/gnrc_networking menuconfig
to configure both CPUs and try to compile them afterwards.
Issues/PRs references
Part of issue #12888
Lastly, I know that these are CPU-specific configurations for the ESP, but having the WiFi and ESP-NOW options under
CPUseems a bit off from the user perspective when using menuconfig.
What whould be a better place from your point of view?
What whould be a better place from your point of view?
I would expect to see this maybe in System > Networking > WiFi.
One thing that can be done is to have generic 'WiFi' symbols (e.g. CONFIG_WIFI_SSID) that can be translated to esp-specific parameters. Something similar like LoRaMAC has now with the keys
What whould be a better place from your point of view?
I would expect to see this maybe in
System > Networking > WiFi.
Hm :thinking: ok. Maybe there should be a further menu Network Devices and then WiFi and ESP-NOW?
`System > Networking > Network Devices > WiFi`
`System > Networking > Network Devices > ESP-NOW`
One thing that can be done is to have generic 'WiFi' symbols (e.g.
CONFIG_WIFI_SSID)
As long a there is no other WiFi netdev driver I would leave the symbols as they are. OK?
As long a there is no other WiFi netdev driver I would leave the symbols as they are. OK?
The problem with having the ESP specific symbols is that then you need to source a file that is placed in cpu/... from a file that is in sys/net/..., which may seem odd as we are trying to follow the same structure as we have for modules.
As long a there is no other WiFi netdev driver I would leave the symbols as they are. OK?
The problem with having the ESP specific symbols is that then you need to source a file that is placed in
cpu/...from a file that is insys/net/..., which may seem odd as we are trying to follow the same structure as we have for modules.
Yeah, that was the reason why I placed them in CPU section. Having ESP-WiFi in Networking and ESP-NOW in CPU section would be even more odd because ESP-NOW is nothing else than the WiFi interface that uses IEEE 802.11 Action Frames. So if we place ESPs network devices in Networking, the user would expect all of them there.
Something similar like LoRaMAC has now with the keys
I couldn't find Kconfig for LoRaMAC. I found sys/net/gnrc/link_layer/lorawan/Kconfig, but in this example all symbols are also called GNRC_LORAWAN_*.
I couldn't find
Kconfigfor LoRaMAC.
Sorry, I was just referring to the fact that they have generic LORAMAC_ macros that are used both by the Semtech package and GNRC LoRaWAN.
As long a there is no other WiFi netdev driver I would leave the symbols as they are. OK?
The problem with having the ESP specific symbols is that then you need to source a file that is placed in
cpu/...from a file that is insys/net/..., which may seem odd as we are trying to follow the same structure as we have for modules.Yeah, that was the reason why I placed them in CPU section. Having
ESP-WiFiinNetworkingandESP-NOWin CPU section would be even more odd becauseESP-NOWis nothing else than the WiFi interface that uses IEEE 802.11 Action Frames. So if we place ESPs network devices inNetworking, the user would expect all of them there.
We could place ESP-NOW there as well
@gschorcht do you think we could get this in shape for the feature freeze?
I don't think so. I have changed too much in the meanwhile. For example, I provided a huge code deduplication so that cpu/esp32/esp-wifi/esp_wifi_netdev.* and cpu/esp8266/esp-wifi/esp_wifi_netdev.* were merged and moved to esp_common. That is, the of the WiFi netdev configuration has been moved to esp_common.
Furthermore, we couldn't find a final agreement on where to place the ESP-specific network device configurations (at least as I remember).
Finallly, with PR #13754, a further WiFi netdev driver will become available. Thus it's time to change the ESP-specific ESP_WIFI_* configurations to more general WIFI_* definitions. We should change it first before we expose the configuration in Kconfig.
Thus it's time to change the ESP-specific
ESP_WIFI_*configurations to more generalWIFI_*definitions. We should change it first before we expose the configuration inKconfig.
That's good, and would be more in the direction of one of my proposals above, in order to have the WiFi parameters in a more generic place.
Ok, I'll be tagging this for next release then. Thanks for the quick response!
Because of PR #13754, it is time to change the ESP specific WiFi configuration to a more general one. This must be done first. Then we can expose the configurations via Kconfig. I would say, that it nothing we can realize with this release.
@gschorcht any plans on moving forward with this one?
Unfortunately not, I could not work on my RIOT contributions in the last months, because of other tasks related to the Corona online summer semester and the upcoming winter semester, which will be online again :worried: There are a number of open RIOT contributions just waiting to be completed. But I just don't have time to finish them and contribute at the moment.
@leandrolanzieri @gschorcht esp is one of the main items on the to-do list for Kconfig, is it interesting to revive this PR?
@leandrolanzieri @gschorcht
espis one of the main items on the to-do list for Kconfig, is it interesting to revive this PR?
Sure, I'm currently working on the modelling of the esp modules (minus networking), adding the configurations as well would be nice.
Sure, I'm currently working on the modelling of the esp modules (minus networking)
@leandrolanzieri Is your modelling esp modules something different or will you provide a new PR which makes this one obsolete?
Sure, I'm currently working on the modelling of the esp modules (minus networking)
@leandrolanzieri Is your modelling esp modules something different or will you provide a new PR which makes this one obsolete?
It is something different, I will be providing a different PR (similar to #16929), but it does not make this one obsolete, as this adds configurations, not modules.
@leandrolanzieri Is your modelling esp modules something different or will you provide a new PR which makes this one obsolete?
It is something different, I will be providing a different PR (similar to #16929), but it does not make this one obsolete, as this adds configurations, not modules.
So my first task would be to rebase this PR.
It is something different, I will be providing a different PR
@gschorcht see #17232
@leandrolanzieri Now were PR #17232 is merged, I would like to resume my work on the Kconfig for ESP network devices. I think this PR has to be reworked completely. Therefore, I would like to clarify the following questions before
- We have now a category
Drivers -> Network Device Driverswhere there are already network device drivers. I would add ESP network devices there? - I would like to leave the configuration parameters like
ESP_WIFI_*as documented to keep the compatibility with existing applications at user side. I would use the more general symbolsCONFIG_WIFI_*inKconfigand would map them as follows:
Would that be ok?#ifndef ESP_WIFI_SSID #ifdef CONFIG_WIFI_SSID #define ESP_WIFI_SSID CONFIG_WIFI_SSID #else #define ESP_WIFI_SSID "RIOT_AP" #endif #endif - How can I enable GNRC in
Kconfigfor tests? I have seen in https://github.com/RIOT-OS/RIOT/blob/85313ccc02cdb813d65f208c56d06992ad484130/sys/net/gnrc/Kconfig#L7-L8 thatKconfigfor GNRC depends onUSEMODULE_GNRC, but how can I enable it an required submodules? According to the documentationUSEMODULE_is generated byKconfigfromUSEMODULE += gnrc. But it works neither at command line nor in Makefiles.
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. If you want me to ignore this issue, please mark it with the "State: don't stale" label. Thank you for your contributions.
![stale[bot] avatar](https://avatars.githubusercontent.com/in/1724?v=4 "Published by a pub.dev verified publisher"){kind=small}