151–160 of 167 posts
Earlier quoted context omitted.
Which G0 part is this? Can you point me to one of these forum posts?
Sorry, I was digging on that too much time ago and haven't saved any links. AFAIR, there is permanent busy state in certain conditions when functioning in SPI slave mode, unablility to reset TXFIFO/RXFIFO and some edge case with DMA and TXE/BSY when DMA failed and you don't know how many bytes are in RxFIFO.
Been using this to build a LoRa relay for the Bitchat app running on nrf52, it's actually very smooth for the most part. The only panics I seem to get are from the Nordic's SoftDevice, not for the ebasssy-rust code itself.
Earlier quoted context omitted.
The claim is you can get embedded concurrency without an OS. Do you disagree? I prefer C for embedded but must admit that's pretty compelling.
The claim is it "obsoletes the need for a traditional RTOS with kernel context switching." I don't think the authors understand what an RTOS is, because it has very little to do with concurrency. It is about providing hard guarantees about execution timing of interrupt events. E.g. you need to poll an input port every 20ms, or something like that, because that's when the signal will be on the wire. Not "Please wait a…
(interrupt queuing and prioritization can be handled by the hardware nowadays. RTIC, a similar project, uses this to drop the need for a scheduler altogether and just runs all code in interrupt handlers, something which 'traditional' realtime wisdom would forbid because it's from an era where you didn't have something like an NVIC.)
Earlier quoted context omitted.
> superloops I’ve been doing async non-blocking code for decades, but this is the first time I e seen that word used? I’m assume you’re meaning something like one big ass select!() or is this something else? > IMO one of the big reasons Arduino stayed firmly hobbyist tier is because it was almost entirely stuck in a single-threaded blocking mindset and everything kind of fell apart as soon as you had to do two things…
I'm surprised nobody has put together a cooperative threading C framework using the -fstack-usage ( https://gcc.gnu.org/onlinedocs/gcc/Developer-Options.html#in... ) option supported by GCC and clang. With per-function stack usage info, you can statically allocate a stack for a thread according to the entry function, just like async Rust effectively does for determining the size of the future. Context switching can b…
“… better stack usage, if you can keep it”
— Benjamin Franklin
Earlier quoted context omitted.
I've read this, and frankly its comparing apples to oranges. These are not the same things though naively they may appear the same.
I'd be happy to hear some of the differences if you don't mind. Both Embassy and FreeRTOS are often used to organize the various tasks you want to perform in an embedded context so I think it's fair to compare them. I know their implementations and behaviors can be quite different, but I'd like to hear more about what makes this an apples to oranges comparison.
There's a large number of things that the cooperative scheduler can't do. Maybe you don't need those things, that's fine! Embassy really is quite nice for cooperative task scheduling. But to benchmark a context swapping RTOS which can and pays the cost for doing so, against a cooperative task queue scheduler... these are not at all the same things, and won't have the same performance characteristics in simple scenarios like the one in the blog post.
This is at the center of a friction point in embedded rust: most of the OSS ecosystem has shifted to this framework, and as a result, is incompatible with, or is high friction if you don't want to make your firmware and control flow Async. This is notable because Rust embedded is nascent and small, so I think splitting the ecosystem along with Async is not ideal. It's also confused some people new to embedded: I regu…
As others have mentioned, ~all of the embassy HALs support nearly 1:1 parity of blocking interfaces for drivers next to the async ones. You really can avoid async entirely while still using embassy hals. The ecosystem is not tightly integrated/locked in. Even data structure libraries, like embassy-sync, all have `try_` methods, which would allow for polling usage outside of async. There's no mandate to use async - an…
If you look at espressif and how they support rust they have to offer both blocking and non blocking options, they also offer using rust on their freertos and C library setup. It’s quite an undertaking to do all of this.
Earlier quoted context omitted.
The claims, including in comments in this thread read to me as "I will make this claim". Then, someone points out that the claim is inaccurate. "I didn't really mean that, I meant slightly softer version ". It feels disingenuous.
What I'm seeing is an Embassy dev giving hard evidence of how this can be used for real-time tasks ironically proving that the weirdly upset people, who are claiming no one here knows what they are talking about, are in fact the ones who don't know what they are talking about.