Comments (11)
Thanks! Generally, this sounds like a good idea to me
Moreover, they mentioned that we must wait for the send callback of esp_now_send. I noticed that current implementation does not count this. Maybe there should be another issue for this.
Didn't knew that t.b.h. - I agree adding an issue for this is a good thing
from esp-wifi.
Ok. I will open a pull request for the previous one after testing my implementation on the hardware. As for the latter one, I will write a demo to check the potential impact of a fix and open another issue later.
from esp-wifi.
I asked the developers of esp-now and they said that esp-now send is thread safe (espressif/esp-now#87). So I think my idea is safe to implement.
Moreover, they mentioned that we must wait for the send callback of esp_now_send
. I noticed that current implementation does not count this. Maybe there should be another issue for this.
from esp-wifi.
esp-idf-svc implemented esp now in a way where all config, send and receive methods do not take mutable reference of self
. Why not do what they did so we can just share references of EspNow
struct between threads.
from esp-wifi.
esp-idf-svc implemented esp now in a way where all config, send and receive methods do not take mutable reference of
self
. Why not do what they did so we can just share references ofEspNow
struct between threads.
To be honest I never looked into that but I think it's an easy and good enough solution for the problem. I don't see why we shouldn't do the same 👍
from esp-wifi.
Closed in favor of #237
from esp-wifi.
@bjoernQ Sorry I just realized that I've made a fundamentally wrong design in #232, which makes EspNow
totally unusable when performing data sending in multiple tasks (Sorry for not having it tested thoroughly).
Here I used an AtomicWaker
to wake the future when callback is invoked.
However, what I didn't considered is the register
method overwrites the previous waker. So when two tasks task1 and task2 are performing data sending, the following event series can occur:
[task1] esp_now_send
[task1] SendFuture::poll -> ESP_NOW_TX_WAKER = task1.waker
[task2] esp_now_send
[task2] SendFuture::poll -> ESP_NOW_TX_WAKER = task2.waker
[task1] callback -> wakes task2
[task2] Future returns with status of sending in task1
Finally, task1 will never get waked while task2 gets wrong status.
I believe your idea of wait before sending can help solving this issue. I'm currently working on this.
from esp-wifi.
Ah I see. Sorry I haven't noticed that before.
Maybe the easiest fix would be to combine what we have (awaitable result) and wait before sending. That way it's always just one "in-flight" send and the user can check the result when needed
from esp-wifi.
I agree that this is a good enough solution for the sync version. However, after having tried several different approaches for the async version, I realized that it's way more difficult than I've expected.
My approach
Initially I used a simple global flag to indicate whether the previous sending is completed, i.e. the send callback is invoked. Let's call it PREV_SEND_COMPLETE
, we may implement the future like this:
fn poll(...) -> ... {
if !PREV_SEND_COMPLETE {
return Poll::Pending
}
...
esp_now_send(...)
...
}
However, when the future is firstly polled with Poll::Pending
returned, it will probably never get polled again since the future will never be awoke by a waker.
So we should register a waker for current future before returning Poll::Pending
, and the waker should be called when the previous sending completes. Finally a chain-like relationship will be built between all spawned future:
Note that we need to add future to this chain at its first poll.
This idea still have drawbacks:
- It's pretty complex. I'm not sure if it's suitable to implement it in this crate.
- It requires dynamic allocation since the length of that chain is unknown. (or static sized queue with additional checks)
I have a feeling that this idea is over designed. But I cannot find a simpler design that really works.
Another Idea
If send_async
takes mutable borrowed receiver and we adopt to the type state design in my first comment. User will need a mutex to send data in multiple tasks, thus making the futures naturally non-overlapping. I think this would be better than synchronizing the futures inside the API implementation and also provides more flexibility.
from esp-wifi.
I agree, the async implementation shouldn't be over engineered.
Your suggestion sounds good to me
from esp-wifi.
We can finally closed this as #240 got merged.
from esp-wifi.
Related Issues (20)
- Driver Update HOT 1
- BLE example is not work for esp32s3 HOT 13
- [ESP32] esp-wifi crash if used with embassy and any task on the second core HOT 10
- Start a CHANGELOG.md
- ESP8266 WIFI attempts HOT 2
- esp-wifi should be useable without depending on embedded-svc HOT 1
- esp-wifi 0.3.0 does not compile for ESP32-C3, it depends on portable-atomic, and that doesnt build for RiscV HOT 5
- How to depend on esp-wifi in an external example HOT 3
- example/embassy_ble does not compile HOT 2
- esp-wifi lockup on esp32c3 when using the embassy InterruptExecutor HOT 3
- [ESP32] esp-wifi crashes when trying to connect via BLE HOT 6
- NVS initialization error HOT 1
- compile error HOT 2
- W (42148) wifi:m f null Getting This warning and then wifi is never reconnected in the execution HOT 1
- Critical section feature conflict between esp-wifi and esp-idf-hal HOT 3
- #[interrupt] macro has been removed from esp-hal-procmacros HOT 6
- docs.rs failed to build HOT 3
- HTTPS support HOT 2
- [RISCV] Stable esp-wifi HOT 2
- Access point example with password can't connect (ESP32S3) HOT 2
Recommend Projects
-
React
A declarative, efficient, and flexible JavaScript library for building user interfaces.
-
Vue.js
🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.
-
Typescript
TypeScript is a superset of JavaScript that compiles to clean JavaScript output.
-
TensorFlow
An Open Source Machine Learning Framework for Everyone
-
Django
The Web framework for perfectionists with deadlines.
-
Laravel
A PHP framework for web artisans
-
D3
Bring data to life with SVG, Canvas and HTML. 📊📈🎉
-
Recommend Topics
-
javascript
JavaScript (JS) is a lightweight interpreted programming language with first-class functions.
-
web
Some thing interesting about web. New door for the world.
-
server
A server is a program made to process requests and deliver data to clients.
-
Machine learning
Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.
-
Visualization
Some thing interesting about visualization, use data art
-
Game
Some thing interesting about game, make everyone happy.
Recommend Org
-
Facebook
We are working to build community through open source technology. NB: members must have two-factor auth.
-
Microsoft
Open source projects and samples from Microsoft.
-
Google
Google ❤️ Open Source for everyone.
-
Alibaba
Alibaba Open Source for everyone
-
D3
Data-Driven Documents codes.
-
Tencent
China tencent open source team.
from esp-wifi.