crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
rardiol has joined #rust-embedded
ethanxxxl has joined #rust-embedded
ethanxxxl has quit [Remote host closed the connection]
explore has joined #rust-embedded
loki_val has quit [Remote host closed the connection]
<re_irc>
<dirbaio> chrysn: if that driver is using async i2c, the HAL i2c impl will very likely have multiple inner await points anyway, so the whole future stack needs state tracking anyway
crabbedhaloablut has joined #rust-embedded
<re_irc>
<dirbaio> "nb-style" single await point might be doable for spi/uart but definitely not for i2c, the states are very complex (doing the start condition, waiting to send the address byte, waiting for the ack bit, sending more bytes, receiving more bytes, doing the stop condition...)
<re_irc>
<dirbaio> this is why there's no "nb" i2c trait :)
<re_irc>
<dirbaio> so no, that's not a justification for returning "nb::Result" from an "async fn"
<re_irc>
<chrysn (@chrysn:matrix.org)> dirbaio: Provided the side effects "don't count", some of that state management can be done inside the objeat that provides an nb interface. But that's a big "if" (https://github.com/rust-embedded/nb/issues/16), and one of the reasons I rather use full async right away.
<re_irc>
<chrysn (@chrysn:matrix.org)> (I'm inclined to ditch nb fully, but don't have a good grasp of how much ecosystem I'd lose that way)
<re_irc>
<chrysn (@chrysn:matrix.org)> (I'm inclined to ditch nb fully, but don't have a good grasp of how much ecosystem I'd lose that way)
<re_irc>
<dirbaio> me too! if we tried to fix nb's problems instead (state tracking, cancelation, low-power, dma) the result would essentially look like a reinvented "Future" 😜
<re_irc>
<dirbaio> so let's just use "Future" instead lol
rardiol has quit [Ping timeout: 245 seconds]
explore has quit [Quit: Connection closed for inactivity]
<re_irc>
<ryan-summers> I don't think I've ever seen nb be useful in my use-cases. It's almost always gotten in the way for me
<re_irc>
<ryan-summers> Whenever I end up having an nb::WouldBlock, I think _maybe once_ I've done something other than spin-loop
<re_irc>
<ryan-summers> And if it's that rare, your driver can just return a custom error type as well
<re_irc>
<ryan-summers> Also, has anyone else seem Element behave oddly with Matrix text history? I have a feeling that if Element is closed, it doesn't get any of the chat in between when you open and close it
crabbedhaloablut has quit [Ping timeout: 268 seconds]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<chrysn (@chrysn:matrix.org)> I've twice so far done something different than a spin loop. In both cases I had to expose platform specifics up through the interfaces, and thread them up to the main loop setup where it'd register to sleep until any of these got events, and it felt very brittle and unergonomic.
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc>
<ryan-summers> Yeah, the cases where nb _would_ be useful tend to be the cases where things are _not_ clear cut enough for a clean platform-agnostic impl
<re_irc>
<ryan-summers> So it doesn't matter that nb provides an agnostic interface
<re_irc>
<ryan-summers> Unrelated comment - has anyone seen a nice ADC implementation that allows a single ADC to be shared between potentially multiple users, each with their own channel?
<re_irc>
<ryan-summers> I'm imagining something like shared-bus, but for ADCs
<re_irc>
<dirbaio> RefCell :P
<re_irc>
<9names (@9names:matrix.org)> is each user getting a channel in this configuration?
<re_irc>
<ryan-summers> Yeah, basically I have some ADC channels that are routed to a mezzanine card and then I also want access to the internal CPU temp channel
<re_irc>
<ryan-summers> And yes, it will be a refcell, which is how all this stuff gets done, was just curious if a ready-made library already existed
<re_irc>
<ryan-summers> I thankfully don't need it to be platform-agnostic here, so might just go with roll-my-own
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 245 seconds]
gsalazar has joined #rust-embedded
<re_irc>
<eldruin> PSA: dirbaio is now part of the HAL team! welcome! 🎉
causal has quit [Quit: WeeChat 3.5]
<re_irc>
<Urhengulas> Hi everyone 👋, I am Johann (@urhengulas in the internet), co-maintainer of Knurling-rs ("defmt", "probe-run" etc.).
<re_irc>
We as the Knurling project are (for the first time) running a summer program "Knurling Summer of Code". The goal is to support newcomers to improve their (embedded) Rust knowledge and help them get into open-source 😊
<re_irc>
We selected a mentee and together we thought about working on/with the "embedded-nal" (github.com/rust-embedded-community/embedded-nal) library. We talked about creating implementations (e.g. for the "esp32-c3", "nRF9160" or "Raspberry Pi Pico W"), improving the documentation or working on implementing features.
<re_irc>
Is there anyone here who is engaged with the project and has time to talk about what could or should be done? As I said we have some ideas, but we are also open to adapting our plans.
<re_irc>
<ryan-summers> What's your ultimate goal? Improving embedded-nal, or building something on top of it?
<re_irc>
<ryan-summers> I've been successfully using the NAL for an MQTT client for quite a while. But a thing we've (QUARTIQ) has been interested in is integrating in DNS support
<re_irc>
<Urhengulas> Improving it and mentoring our mentee while doing so.
<re_irc>
<ryan-summers> So maybe something in the DNS realm would be a cool project
<re_irc>
<Urhengulas> I see there is already a DNS module. What is missing there?
<re_irc>
<chrysn (@chrysn:matrix.org)> I'm happy to provide ideas or feedback on NAL development. (But I'll only be actively around here today for about 10 more minutes.)
<re_irc>
<ryan-summers> That's a good question for MathiasKoch - I haven't used it myself. I'm not sure if the NAL itself actually needs a whole lot of work
<re_irc>
<Urhengulas> chrysn: Thank you for the offer!
<re_irc>
<ryan-summers> Also, yeah, feel free to reach out to me as well and I'd be happy to help w/ direction as well
<re_irc>
<chrysn (@chrysn:matrix.org)> ryan-summers: I disagree; it has both concrete feature gaps and architectural aspects that should be revisited.
<re_irc>
<ryan-summers> Ah you've got a good point. Specifically I recall some issues around TCP state management
<re_irc>
<diondokter> Note that I'm working on an up-to-date async nrf9160 modem implementation (don't know what your ideas are with regards to it)
<re_irc>
<Urhengulas> ryan-summers: We also assumed that the NAL is in a rather good shape. But I think there is always the possiblity to improve documentation and otherwise implementing the NAL for some new platforms is probably useful as well. If you have any favorite platforms you would like to see support for, please propose it.
<re_irc>
<Urhengulas> chrysn: Are the existing problems and open features all documented in the issue tracker. Or could you please summarize what needs to be done from your perspective?
<re_irc>
<ryan-summers> I think a lot of what we've discussed here are in the issue tracker so far
<re_irc>
<ryan-summers> Or at least the things that my memory got jogged on are
<re_irc>
<ryan-summers> And hmm, good question about platforms. I don't think there's any existing ESP32 support for the NAL, although there is a smoltcp, w5500, and it sounds like nrf9160 is under development
<re_irc>
<ryan-summers> * smoltcp impl, w5500 impl (alone and via smoltcp),
<re_irc>
<ryan-summers> An equally interesting route is building libraries that leverage the NAL
<re_irc>
<chrysn (@chrysn:matrix.org)> The concrete gaps are on the issue tracker -- things like binding to concrete addresses, sending from a source address etc.
<re_irc>
<chrysn (@chrysn:matrix.org)> As for the architectural things, it's mixed: One topic is zero-copy APIs; there are issues open on that.
<re_irc>
<ryan-summers> Yeah, I'd love to make a zero-copy API
<re_irc>
<ryan-summers> err... have. Making I don't have time for right now :P
<re_irc>
<chrysn (@chrysn:matrix.org)> Also on type state, there is an issue. I find it weird to write a TCP impl where I have to err out on binding a socket -- when really binding could create something in type state.
<re_irc>
<diondokter> One issue I had with the NAL for the nrf9160 is that the DNS trait has both "get_host_by_name" and "get_host_by_address" while I can only provide the first one. So the second one had an "unreachable!()"
<re_irc>
<ryan-summers> Typestate always makes me a bit nervous because it's easy to take overboard. Like, what happens to the type if the connection drops?
<re_irc>
<Urhengulas> diondokter: No concrete ideas. So far we have gathering ideas and thinking about platforms we though would be a good fit. But if you are already working on it we can cross it from our list :)
<re_irc>
<chrysn (@chrysn:matrix.org)> ryan-summers: I agree that it can be taken overboard, and whether the connection is live or not is clearly a runtime state. But a socket that is connected and bound (to which I can send data without addressing) and a socket that is unconnected (to which I have to sendto) have distinct APIs, and it's only the POSIX centric view of "We have our file APIs and we use these" that IMO makes one even think...
<re_irc>
... to put them in the same type.
<re_irc>
<chrysn (@chrysn:matrix.org)> And similar to that, there is the issue of separating socket creation and usage -- that's not covered in any issue AFAICT; I'd summarize here after chatter on the other one calms down.
<re_irc>
<Urhengulas> diondokter: What would be a better solution from your perspective?
<re_irc>
<chrysn (@chrysn:matrix.org)> Separate traits?
<re_irc>
<diondokter> Maybe?
<re_irc>
<diondokter> Like how often does one actually do a "get_host_by_address"?
gsalazar has quit [Remote host closed the connection]
<re_irc>
<ryan-summers> Needs some usecase thought to be honest. I was just about to say the use case of using address -> name is a lot rarer
<re_irc>
<ryan-summers> It seems to be purely informational for an end user?
<re_irc>
<chrysn (@chrysn:matrix.org)> I'm erring out on std-embedded-nal on that one as well.
<re_irc>
<ryan-summers> Or if a user provides an IP you could resolve it to a host, but yeah, I don't think it's required
<re_irc>
<ryan-summers> It's a pretty specific use case
<re_irc>
<diondokter> Urhengulas: Well maybe someone could help? Definitely with docs and maybe some impl as well. I'd be willing to spend a bit of time helping getting someone up to speed
<re_irc>
<chrysn (@chrysn:matrix.org)> I'd put ip-to-name it into the category of the rest of DNS. When you use that, you might also want to provide SRV, PTR etc records.
<re_irc>
<ryan-summers> Oh, I also have a project where I added support for using an external MAC with the smoltcp-NAL. The code is currently closed-source, but we want to pull it into an MIT-licensed crate
<re_irc>
<ryan-summers> Haven't had time to get around to it
<re_irc>
<ryan-summers> E.g. operating a W5500 in MACRAW mode and use smoltcp on top of it with the NAL
<re_irc>
<Urhengulas> diondokter: That's also a good option. Our mentee could pair with you and use that experience for an esp32-c3 implementation
<re_irc>
<diondokter> I'd be open to it!
<re_irc>
<Urhengulas> ryan-summers: Just seeing you discuss it sounds like that method isn't that useful. So it could be dropped, or moved into a separate trait for people who have that specific usecase.
<re_irc>
<Urhengulas> chrysn: Do you mean that it should be part of embedded-nal? Or that it shouldn't?
<re_irc>
<chrysn (@chrysn:matrix.org)> It shouldn't (at least not part of the DNS trait that everyone implements).
<re_irc>
<chrysn (@chrysn:matrix.org)> (The standard library just doesn't provide a means to do that).
<re_irc>
<Urhengulas> Thank you already for all your input. I already have a way better picture of how to go an.
<re_irc>
<Urhengulas> One more question though: Is there any good "starter issue" you have in mind that our mentee could work on to get a bit into the project?
<re_irc>
<chrysn (@chrysn:matrix.org)> #41
<re_irc>
<Urhengulas> I imagine typestate could be rather easy to get started with.
<re_irc>
<ryan-summers> Typestate is also not a bad idea, since you can play around with the API quite a bit
<re_irc>
<chrysn (@chrysn:matrix.org)> I think we should do more as embedded-hal does, and have traits for how to work on a connection. (Like hal has traits for how to read from an ADC channel, but not how to split an ADC device into channels).
<re_irc>
<chrysn (@chrysn:matrix.org)> Having API for creation, binding and connecting of sockets is a good thing, but it should be split from "how to work on them".
<re_irc>
<ryan-summers> That's an interesting point. Needs some implementation thought though, because an error on the connection can cause the socket to just get "lost" and a driver may need to get a new one at some point
<re_irc>
<chrysn (@chrysn:matrix.org)> The former is a vast area, the latter is narrow and well implemented.
<re_irc>
<ryan-summers> E.g. what if you need to close and re-open because of communication issues or lost connections?
<re_irc>
<chrysn (@chrysn:matrix.org)> Three options:
<re_irc>
- Require that the full trait set is provided
<re_irc>
<chrysn (@chrysn:matrix.org)> Three options:
<re_irc>
- Require that the full trait set is provided
<re_irc>
- Ask the caller for a callback to do that
<re_irc>
- Just terminate the task and rely on higher levels to handle it
<re_irc>
<Urhengulas> ryan-summers: Do you have some ideas?
<re_irc>
<chrysn (@chrysn:matrix.org)> Thing is: Creating a connection can have platform specific pit falls.
<re_irc>
<chrysn (@chrysn:matrix.org)> For example, on RIOT I can't just create a socket out of thin air, I have to have something pinned.
<re_irc>
<MathiasKoch> Hmm.. We are actively using the nal as it is, but there are absolutely papercuts! I think some of the more socket directed API being developed and tested as part of the async version is the right direction. It would make it feel much more rusty, where we can take advantage of stuff like Drop etc
<re_irc>
<ryan-summers> Urhengulas: - FTP client
<re_irc>
- Telnet client
<re_irc>
- HTTP client
<re_irc>
- DNS client
<re_irc>
<ryan-summers> FTP would be really cool for enabling bootloaders
<re_irc>
<ryan-summers> I've seen some very successful ftp-based bootloaders, but FTP is also great for extracting datafiles from firmware
<re_irc>
<MathiasKoch> Urhengulas: HTTP server as well, for stuff like hotspot wifi configuration (AP mode)
<re_irc>
<chrysn (@chrysn:matrix.org)> If there is the option to have socket creation platform specific (or just evolve at a different pace than the stabilizing read-and-write traits), a library that does something narrow (like parsing a protocol and handling retransmissions) can just work on what the narrow traits describe.
<re_irc>
<MathiasKoch> +& file upload for bootloaders
<re_irc>
<Urhengulas> chrysn: How do you see that ratio of plaform specific vs general error cases? I'd assume that one could design a good error type which covers most errors, but also has a variant for "this is a platform specific error, ask your implementation how to handle it.".
<re_irc>
<chrysn (@chrysn:matrix.org)> ryan-summers: TFTP is the more common choice for embedded systems, although personally I'd rather go with SUIT over CoAP these days.
<re_irc>
<ryan-summers> Ah you're right, sorry, not FTP, but TFTP is what I'm thinking of
<re_irc>
<chrysn (@chrysn:matrix.org)> Urhengulas: I don't think that errors are what helps here. I can sure err out, but that'd be a runtime error for something where it's clear at composition time that these things don't work that way.
<re_irc>
<ryan-summers> TFTP is nice because there's default linux tools that can be used on the PC side of things
<re_irc>
<ryan-summers> With zero setup on the host PC
<re_irc>
<ryan-summers> Never heard of SUIT tbh
<re_irc>
<chrysn (@chrysn:matrix.org)> In essence, I'd be providing an implementation of UdpFullStack just to say that "This isn't _really_ a full stack, you can only use the sockets, all creation errs out, please use the dedicated API" -- and that'd be idiomatically expressed in separate traits.
<re_irc>
<Urhengulas> chrysn: Excuse if I was unclear. I meant that the error "enum" would have sth like a "PlatformSpecific" variant which the user needs to handle.
<re_irc>
<chrysn (@chrysn:matrix.org)> ryan-summers: It's IETF work that is getting finished, and designed for firmware updates across the Internet (with all integrity and DoS protection bells and whistles).
<re_irc>
<chrysn (@chrysn:matrix.org)> Urhengulas: All the same.
<re_irc>
<Urhengulas> Ok
<re_irc>
<ryan-summers> Does it use SSL, or are things still plaintext?
<re_irc>
<chrysn (@chrysn:matrix.org)> (I might even panic, because if that code finds itself running that, it's irrecoverable)
<re_irc>
<ryan-summers> And TFTP is nice for things even outside of firmware images, e.g. if you have a video file stored on your device that you want to extract
<re_irc>
<ryan-summers> Or if you have a trivial file system with some images loaded into flash or an external memory
<re_irc>
<chrysn (@chrysn:matrix.org)> ryan-summers: It's transport independent, and integrity protected on its own (signed manifest). One way of transporting manifests and data is through CoAP, which for that application could be run with or without a security layer.
<re_irc>
<chrysn (@chrysn:matrix.org)> Yes, a TFTP implementation would be nice to have no matter what one eventually chooses for firmware updtes.
<re_irc>
<chrysn (@chrysn:matrix.org)> (Frankly, if it only serves as a good scaffolding for how to implement other protocols of similar complexity, that alone would make it valuable).
<re_irc>
<ryan-summers> Honestly, I think TFTP is a solid project idea right now. I remember someone was looking for an implementation for a bootloader just a few months back
<re_irc>
<Urhengulas> ryan-summers: I also kinda like it, because it sounds well scoped.
<re_irc>
<Urhengulas> And apparently there is a need for it.
<re_irc>
<Urhengulas> Many good ideas floating around here 🙈
<re_irc>
<ryan-summers> You could do a cool PoC with some images stored on the MCU and then display the images on a screen, then TFTP update them and re-render
<re_irc>
<MathiasKoch> Urhengulas: Another thing that could fit nicely with embedded-nal and the networking is an embedded version of native-tls. Not an actual TLS implementation, but an abstraction that could be implemented for drogue-tls, rustls, offloaded-tls-stacks etc with a common interface for configuration, and embedded-io abstractions as input/output, so it can be dropped in before any actual embedded-nal implementation.. I don't...
<re_irc>
... know how straight forward that one is though
<re_irc>
<ryan-summers> Ah yes, TLS is also very much so needed. Right now, you can't do any kind of secure networking with the NAL, which is unfortunate
<re_irc>
<MathiasKoch> exactly
<re_irc>
<ryan-summers> So any kind of network bootloader is totally unsecure
<re_irc>
<ryan-summers> Fine for closed networks, but still
<re_irc>
<chrysn (@chrysn:matrix.org)> ryan-summers: I have ongoing work porting libOSCORE to coap-message, which has an implementation on embedded-nal.
<re_irc>
<MathiasKoch> We do extension traits ontop of embedded-nal to add the security layer, but it is super tailored for our needs
<re_irc>
<ryan-summers> Anyways, I need to get back to work now, feel free to ping me if you have any specific needs
<re_irc>
<chrysn (@chrysn:matrix.org)> A TLS layer is maybe something that illustrates well the creation-vs-use abstraction issue:
<re_irc>
<chrysn (@chrysn:matrix.org)> Once a TLS connection has been associated (and the authentication properties evaluated), the connection might be passed on to an application that was originally built to run on TCP.
<re_irc>
<chrysn (@chrysn:matrix.org)> That'd use the same trait. Setting up a TLS connection has vastly different configuration parameters.
<re_irc>
<Urhengulas> So you are saying that non-TLS and TLS could share the use-abstraction, but would have different creation-abstractions?
<re_irc>
<chrysn (@chrysn:matrix.org)> Yes.
<re_irc>
<chrysn (@chrysn:matrix.org)> The use abstraction is really more a stream socket in UNIX terminology, although current work on TAPS might provide better names here (as it is revisiting traditional socket abstractions).
<re_irc>
<MathiasKoch> exactly! And the use abstraction could very well be embedded-io for the sockets themselfs.. just like std::io::Read/Write on std::net
<re_irc>
<MathiasKoch> * themselves..
<re_irc>
<chrysn (@chrysn:matrix.org)> Quite possibly -- it might even be a useful abstraction for a "UNIX style" socket if a platform implements them. (I'd be careful to over-generalize here, though: Treating a file would be overly stretching it, because a file is not bidirectional, but then again can seek).
rardiol has joined #rust-embedded
<re_irc>
<Urhengulas> Again, thank you everyone for the input. We should probably summarize this discussion, since there are many interesting topics mentioned.
<re_irc>
I will go back to some other work as well 👋
crabbedhaloablut has quit [Ping timeout: 268 seconds]
crabbedhaloablut has joined #rust-embedded
twopoint718 has joined #rust-embedded
rardiol has quit [Ping timeout: 252 seconds]
limpkin has quit [Quit: limpkin]
limpkin has joined #rust-embedded
twopoint718 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
<re_irc>
<ryan-summers> Does anyone know of an AtomicBool-based basic mutex available for no_std? It's a super common task that I've done by hand more times than I'd care to admit, but I'm oddly not seeing crates for it
<re_irc>
<ryan-summers> E.g. try to lock resource for a closure, send an error if lock fails, else call closure, unlock once complete
rardiol has joined #rust-embedded
twopoint718 has joined #rust-embedded
<re_irc>
<James Munns> whatcha mean by "resource" and "send" in this case?
<re_irc>
<ryan-summers> Actually, looks like "spinning" has what I needed
<re_irc>
<ryan-summers> I just wanted a mutex that would lock a resource and give a result if the unlock failed
<re_irc>
<ryan-summers> By resource, I just meant a variable (in this case an ADC)
<re_irc>
<ryan-summers> Ended up having to make a software module for dividing up an ADC into many owned "AdcChannel" structs, and needed the mutex for pre-emption of the peripheral
<re_irc>
<ryan-summers> Interestingly enough, I _think_ the implementation can be made generic for anyone interested, just like "shared-bus", but "shared-adc"
<re_irc>
<James Munns> Yeah, this sounds generally like a "failable spinlock"
<re_irc>
<James Munns> Which, I also admit I've written a bunch of times in mnemos alone :D
twopoint718 has quit [Quit: My MacBook has gone to sleep. ZZZzzz…]
causal has joined #rust-embedded
<re_irc>
<lu15w1r7h> Hi :)
<re_irc>
I have a kinda random question.
<re_irc>
I was watching this (https://www.youtube.com/watch?v=b4mS5UPHh20) Crust of Rust episode about channels from Jon Gjengset, where he showed a possible implementation of a rust "mpsc::channel". While thinking of my embedded rust project, I thought that the major problem with porting this implementation to a "#[no_std]" bare metal target would be the "CondVar" used for waking up the "mpsc::{Sender, Receiver}". I believe "CondVar"s...
<re_irc>
... are implemented in the OS, so we have to find a different solution. Can interrupts be used for this? Are there other challenges in a embedded implementation of this? And is there a "#[no_std]" implementations of a channel that would work on bare metal (either using interrupts or something else)?
twopoint718 has joined #rust-embedded
<re_irc>
<lu15w1r7h> I just found "heapless::{spsc, mpmc}". So at least one of these questions was solved :)
<re_irc>
<James Munns> heapless spsc/mpmc are very good! RTIC also uses them as backing queues, which means you can have tasks woken when you push into them as a "spawn" mechanism
<re_irc>
<James Munns> There are also some no-std async/await queues, which can do the "task wake" behavior sort of like condvars, if you end up using async/await (via Embassy or otherwise)
<re_irc>
<lu15w1r7h> James Munns: Ah interesting! I'm in fact using RTIC.
<re_irc>
<James Munns> Yeah, "software tasks" use queues under the hood
<re_irc>
<lu15w1r7h> James Munns: I've also heard of embassy. Can you combine RTIC and embassy? Does it make sense to mix them?
<re_irc>
<lu15w1r7h> embassy is basically an async executor, right? So can you use this executor while managing your tasks with RTIC?
<re_irc>
<James Munns> You can use both, but I wouldn't say it makes sense in the general case (but it works very well in specific cases!). Going out for a bit now, but I can expand on that a bit later if no one beats me to it
<re_irc>
<lu15w1r7h> Alright, I'll have a look if it makes sense for me to use both. Thanks :)
<re_irc>
<lu15w1r7h> 996031
<re_irc>
<James Munns> So, no one beat me to it:
<re_irc>
<James Munns> Embassy and RTIC both solve the problem of "how do I schedule tasks, how do I manage resources, and how do I handle interrupts".
<re_irc>
Embassy does it in a cooperative async/await way.
<re_irc>
RTIC does it in a pre-emptive event-response way.
<re_irc>
Embassy's drivers (which use interrupts to provide async/await drivers for different chips) and executor (what runs and schedules the async tasks) can be extracted so that it "fits into" an RTIC project, typically running the executor in the "idle" task. This is already possible, and RTIC is also working on their own async executor as well atm, which can also still use embassy's async-enabled drivers.
<re_irc>
<James Munns> For simple to average complexity projects, either cooperative or pre-emptive approaches will work, so RTIC OR Embassy's models will work well, and honestly be pretty similar.
<re_irc>
However if you are juggling a lot of I/O, embassy can help avoid manually writing state machines, using async code instead. Embassy also has a more tightly integrated ecosystem.
<re_irc>
If you have hard realtime needs, or prefer a not-async, more event reactive way of handling interrupts and scheduling (e.g. "software or interrupt callbacks with safely managed resources", and have good HAL/driver support for your needs, or will/want to build your own HAL, RTIC can help.
<re_irc>
<James Munns> USUALLY you can bend either environment to cover tasks that are also possible in the other.
<re_irc>
Embassy can end up being hard-realtime (or you can layer multiple executors to handle pre-emptive realtime tasks), and you an do async (or async-like) behavior with RTIC. They just have a slightly different set of concerns that make either approach more or less easy to make happen.
<re_irc>
<James Munns> That's why "have both" doesn't make sense for MOST cases, you don't need two ways to schedule tasks and manage resources; unless you do have two different things you need to manage, like time critical motor/sensor control, with lower prio I/O to sensors/comms interfaces), in which case the fact they work together is really nice for composing things.
<re_irc>
<James Munns> Anyway, that's my $0.02, I'm sure others have opinions and preferences, but they are both really good tools, so use whatever makes sense for you or your project.
<re_irc>
<James Munns> But you probably don't need/want to use both. Unless you really do.
<re_irc>
<lu15w1r7h> That makes so much sense. Thanks you so much for clarifying.
<re_irc>
I probably should look into embassy. I already tried to write my own state maschine, like you said and even tried to use the nightly generators feature (which unfortunately is too immature at the moment).
<re_irc>
<lu15w1r7h> Ah the Embassy website states: "Tasks on the same async executor run cooperatively, but you can create multiple executors with different priorities, so that higher priority tasks preempt lower priority ones.".
<re_irc>
Doesn't that make it a superset to RTIC (at least for my application it seems so)?
<re_irc>
<barafael> RTIC eliminates deadlock and priority inversion. It also comes with basically no runtime overhead. This cannot be said for Embassy.
<re_irc>
<lu15w1r7h> Ah, yes. Didn't think of this. The no-deadlock guarantee is pretty nice...
<re_irc>
<barafael> It only extend to the resources shared by RTIC tasks of course... You are free to deadlock in your generated state machines on top :)
<re_irc>
<762spr> I can't get the STM32L4xx-hal crate to build in my project. I add
<re_irc>
stm32l4xx-hal = "0.7.1"
<re_irc>
to my cargo.toml and get
<re_irc>
error: failed to run custom build command for "stm32l4 v0.14.0"
<re_irc>
but my stm32l4 version is 0.15.1. Even if I try switching it back to 0.14.0 it gives me the same error...
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
<re_irc>
<762spr> is there a way to get the HAL crate to try and use 0.15.1 without cloning it and using it locally?
<re_irc>
<762spr> I am new to rust/crates so not 100% on the best approach. if I downgrade stm32l4 to 0.14.0 my code doesn't compile because apparently some of the peripherals werent fully defined beck in 0.14.0
<re_irc>
<762spr> I'm also a little confused about
<re_irc>
<adamgreig> I think that last one is a custom PAC made so a different custom HAL could depend on it, it's not related to the first two
<re_irc>
<adamgreig> you will need to use a local copy of stm32l4xx-hal to have it depend on the new version of stm32l4
<re_irc>
<adamgreig> cargo makes that fairly easy, if you clone it and then update your cargo.toml to say "stm32l4xx-hal = { path = "../stm32l4xx-hal" }" etc
<re_irc>
<adamgreig> at some point stm32l4xx-hal should update to use the new version of stm32l4, but it was released fairly recently
<re_irc>
<762spr> yeah I was confused because it had been updated fairly recently but still pointed to the older version of the PAC. ok that shouldn't be a problem... IF I even decide I have to have a HAL. It would be nice for the convenience but typically I stayed away from then in the past using C because they would be so bloated. Although I do have some high hopes for rust, it seems to do a good job of cutting the fat out. Still...
<re_irc>
... dipping my toe in the pool and haven't quite figured out my workflow yet