Open SandorDobos opened 2 years ago
This looks like a good addition to the nanoFramework. Your project looks mainly ok except for the Initialization of the WiFi. As it possible to run ESP-NOW and a Wifi station or AP the WiFi init will need to be left up to nanoFramework. Maybe have a check that the WiFI is in correct state before dong the esp_now_init, but Init & deinit needs to be done by system and esp_now_init() & esp_now_deinit can be done by the naitive part of the esp_now.
We will need to create a repo for the nanoFramework.Hardware.Esp32.EspNow so you can clone and update with your managed code changes,
For the native part clone current nanoFramework, add your changes and then create a PR for changes.
I have created a nanoFramework.Hardware.Esp32.EspNow repo which you can now clone, update and create PR. Use another repo as template for required files etc.
See section "Prepare the Initial Commit" in https://docs.nanoframework.net/content/maintainers/creating-a-new-repo.html
nanoFramework.Hardware.Esp32.EspNow is probably not the best choice for this assembly as it not specific to any hardware component in ESP32. Will rename repo once name is decided on.
... except for the Initialization of the WiFi. As it possible to run ESP-NOW and a Wifi station or AP the WiFi init will need to be left up to nanoFramework.
// out-of-date I would remove wifi init from native code and add "wifi initialized somehow" prerequisite to the managed package. But I found no ways to just init wifi (equivalent of code to be removed from my native implementation). I found just samples to pull up full fladged AP or STA. What if the developer do not want AP nor STA just ESPNOW? Any suggestions appreciated :)
How about a managed constructor parameter with which the developer can indicate wether espnow code should do the wifi init on it own (like the current code) because no wifi (neither AP nor STA modes) will be used in project? If flag set everything works like the current implementation: espnow native code will init wifi stack without actually start it. If flag unset espnow code wont touch any wifi things but will throw an exception if wifi was not initialized in any other ways before the call. // out-of-date
Wifi init code removed. It turns out that steps start from ESP's nanoHAL_Initialize already do enough for ESPNOW to work, so no additional code required :)
It has been decided to use the nanoFramework.EspNow namespace for this feature so repo has been renamed @SandorDobos
@AdrianSoundy native and managed code reflects the namespace change now
This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs. Thank you for your contributions.
Not stale just waiting for @AdrianSoundy
I don't see any PR for the hardware.Esp32now repo @SandorDobos
Hi, What is the status of Esp32now in nanoframework? Could you please give us an update?
nanoFramework area: Community contributions
Is your feature request related to a problem? Please describe.
ESP32 has a radio communication method (ESPNOW) which allows peer-to-peer, peer-to-many, many-to-peer and many-to-many data exchange without any infrastructure (e.g. no access point needed). This allows many uses between equal level nodes.
Describe the solution you'd like
Lets have ESPNOW available in managed code.
Describe alternatives you've considered
Wifi and BLE. Both lacking some of features mentioned above.
Additional context
The official ESPNOW documentation is here.
Submit a PR with the implementation
My implementation lives here. Native part Managed code I am sure some administration is still missing, but technically the feature is fully implemented. Please point me to necessary steps required to accept this implementation!