Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

ESP32:ESPNOW feature #927

Open
SandorDobos opened this issue Jan 3, 2022 · 11 comments · May be fixed by nanoframework/nf-interpreter#2218
Open

ESP32:ESPNOW feature #927

SandorDobos opened this issue Jan 3, 2022 · 11 comments · May be fixed by nanoframework/nf-interpreter#2218

Comments

@SandorDobos
Copy link

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!

@AdrianSoundy
Copy link
Member

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.

@AdrianSoundy
Copy link
Member

AdrianSoundy commented Jan 5, 2022

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

@AdrianSoundy
Copy link
Member

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.

@SandorDobos
Copy link
Author

SandorDobos commented Jan 6, 2022

... 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

@SandorDobos
Copy link
Author

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 :)

@SandorDobos SandorDobos linked a pull request Jan 6, 2022 that will close this issue
14 tasks
@AdrianSoundy
Copy link
Member

It has been decided to use the nanoFramework.EspNow namespace for this feature so repo has been renamed
@SandorDobos

@SandorDobos
Copy link
Author

@AdrianSoundy native and managed code reflects the namespace change now

@stale
Copy link

stale bot commented Apr 16, 2022

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.

@stale stale bot added the stale The issue/PR hasn't seen any activity from the past 60 days. label Apr 16, 2022
@SandorDobos
Copy link
Author

Not stale just waiting for @AdrianSoundy

@stale stale bot removed the stale The issue/PR hasn't seen any activity from the past 60 days. label Apr 16, 2022
@AdrianSoundy
Copy link
Member

I don't see any PR for the hardware.Esp32now repo
@SandorDobos

@TheMo
Copy link

TheMo commented Apr 16, 2024

Hi,
What is the status of Esp32now in nanoframework? Could you please give us an update?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants