-
Notifications
You must be signed in to change notification settings - Fork 632
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
Add embassy microcontroller example demonstrating async #7064
base: master
Are you sure you want to change the base?
Conversation
Hi, I have given this PR some thought and decided that adding the Slint copyright notice in the Cargo.toml file (or elsewhere) is problematic for my use case as I use this example as the basis of my commercial projects and it is not appropriate to have to include this notice in them. Transferring copyright means that I am exposing myself to risk in other projects as a result. Therefore I would like to retract my signing of the digital CLA contract yesterday and retract this pull request. I’m really sorry to have to do this and I understand the need for your project to have a CLA and copyright notices but it is just not compatible with my risk level. There are no easy answers here and I hope you understand. If Slint really wants an embassy example they are welcome to link to my repository. Also, the Embassy project is so fluid that referencing it from Slint via git revision numbers may be too weak for your stability goals at this time. Keep up the great work! |
Hi David! I'm sorry to hear that, but I understand. Thanks for your clear communication. Yes, linking to your repository is a good idea. I'll take a look to see how we can retract the CLA signature. |
Regarding, the signature, @ninjasource , I think that you can go to https://cla-assistant.io/my-cla and revoke it from there. |
FWIW, I haven't looked at the diff yet - that was still on my TODO. I'll abstain from doing that, and I hope that perhaps we can implement an embassy example ourselves in the future. |
Thanks for understanding and thanks for the link. I have a suggestion for demo projects like this that don’t include changes to the core codebase. Perhaps Slint can host a repository that simply links to various open source projects that use Slint. Something like this as an example: https://github.com/rust-embedded/awesome-embedded-rust That list is super easy to add to and fairly easy to do housekeeping on for the occasional repos that get taken offline. The Slint team won’t have the arduous task of keeping old demos alive and they will also get insights on how Slint is actually being used in the wild. |
Thanks for submitting the PR. Note that the CLA does not imply copyright transfer. It simply license your code to us under the MIT-0 license. Now, the CI does indeed check that all files have a license and the test are a bit strict as it force a copyright to Slint which is not needed. So we'd need to fix our CI to allow 3rd party copyright holder. (Which we should have done before as this is not the first time the problem comes up) I do think having an embassy example would be a great addition in the repository. |
Hi @ogoffart, Yes I would be open to keeping the PR and I am glad that you think it will be a great addition to the Repository!
Great, that makes sense, I'm happy with that.
That sounds like a good solution. I would even be open to removing copyright notices on example code but that is up to you guys. I was just uncomfortable with the possibility of losing access to something I had written and use in other projects. |
Hi @ninjasource . We just landed #7260 that should permit the copyright notice. Could you rebase your PR or would you mind if I do? |
da79383
to
30ebef3
Compare
I have spent several hours trying to figure out why the build is breaking with:
I suspect it has something to do with referencing git dependencies and caching but I'm a little stumped. Copying the |
It looks like the problem is that within the Slint cargo workspace, esp-hal's support for some boards also pulls in that embassy time driver, in a different version. And despite targeting entirely different boards/configurations, it's this "safeguard" that causes this: esp32-s2/s3 support seems to enable usb-otg, which I think is what pulls in embassy: https://github.com/esp-rs/esp-hal/blob/6b4312fb905f6cc356cedc07547cab09c92535da/esp-hal/Cargo.toml#L120 For now, one easy workaround for this issue is to take this example out of the Cargo workspace. I've posted a one-liner suggestion how this looks like. That way it compiles for me. |
efa3e8e
to
9bd4c09
Compare
a66f5fa
to
769e599
Compare
Thanks @tronical, the CI probably never ran due to that github actions outage last week. My trial and error approach to fixing ci issues has become painful and I probably should have put in the effort to run it locally. My apologies if there are clear instructions somewhere that I never followed. The latest issue seems to be related to some git shenanigans due to some autofix and I'm not sure if that is something I can fix or it is a bug in the ci or if rerunning will fix it. |
Thanks for your patience :). I'll have a look at fixing that. |
Co-authored-by: Olivier Goffart <[email protected]>
slint::platform::update_timers_and_animations(); | ||
|
||
// process touchscreen events | ||
process_touch(&touch, &mut i2c, &mut last_touch, window.clone()).await; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
i'm not exactly familliar with embassy so sorry if this is a dumb question, but should that not happen in parallel with the rendering
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Not at all, it could be done in parallel with the buffer swap transfer. However, since it only takes 2ms I figured that polling the touchscreen just before the window was about to be rendered would give more accurate user response (in the time domain). However, your suggestion would be better I recon. Somewhat confusingly (for me) I encountered a timeout issue on the I2C bus when using it in async mode with the latest version of Embassy (which is now all referenced from crates.io btw). I couldn't get to the bottom of the issue (slight changes to the code changes alignment and causes the issue, beats me for now. There are so many bugs in the dma peripherals for stm32s, could be that or maybe there is some anecdote in the 4000 page RM about stalling the bus when you use specific channels in specific combinations, I give up). So I changed it to using blocking I2C just to get this thing in.
// async transfer of frame buffer to lcd | ||
double_buffer.swap(&mut ltdc).await.unwrap(); | ||
} else { | ||
Timer::after(Duration::from_millis(10)).await; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
should that perhaps be waiting for slint::platform::duration_until_next_timer_update (if no animations)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
That call returns None for me as there is no active timer. Since I don't really know what the active timer is I just set an arbitrary sleep so that the touchscreen isn't spammed with requests.
An async demo using Embassy and an embedded stm32u5g9j-dk2 development kit. This demonstrates a method to use async in Slint with a microcontroller. The simulator can run on a PC if you do not have the dev kit on hand but it is not meant to be a reference design for an async GUI implementation on a PC.