01:37 <re_irc> <James Munns> btw, (pdf warning), SiFive's "Interrupt Cookbook" is a REALLY good resource for how all this stuff works:

01:37 <re_irc> https://sifive.cdn.prismic.io/sifive/0d163928-2128-42be-a75a-464df65e04e0_sifive-interrupt-cookbook.pdf

10:29 <re_irc> <hartan> Hi, I have a question regarding SPI in embedded-hal 0.2.7. In the docs I can't find a mention anywhere of whether write may return early or not (Unlike e.g. in the latest alpha docs). Is that specified anywhere, or do I have to assume that both are equally true depending on the concrete driver/hal?

10:36 <re_irc> <dirbaio> it wasn't specified, no

10:36 <re_irc> <dirbaio> and it did cause compatibility problems yup (driver assuming it can't return early, hal assuming it can)

10:46 <re_irc> <hartan> Sounds fun... Thanks!

10:46 <re_irc> <dirbaio> I think currently most drivers/hal assume "can't return early"

11:00 <re_irc> <Urhengulas> Hello hello, it's me again about the Knurling Summer of Code 😁 Our mentee Mariya ("sor-ca" on GitHub) started this week and together we decided that she will be working on the "embedded-nal" based TFTP client, as proposed by ryan-summers and chrysn 🎉

11:00 <re_irc> She will start with one or two of the starter issues we've talked about, to understand "embedded-nal" a bit better and afterwards will continue with the proof of concept for the TFTP client. Stay tuned! 💪

11:00 <re_irc> <ryan-summers> Would be very awesome to see a TFTP bootloader implementation somewhere :P

11:01 <re_irc> <Urhengulas> _(lol, did the 🎉 emoji just trigger a confetti animation in the element app?)_

11:01 <re_irc> <ryan-summers> Yes, it indeed does

11:01 <re_irc> <Urhengulas> funny xD

11:01 <re_irc> <Urhengulas> ryan-summers: If you give me a bit more details how that would look like, I can talk to her about it.

11:03 <re_irc> <ryan-summers> I have no direct need currently, it's more an interesting thought. Something like https://github.com/AirborneEngineering/blethrs, but with the TCP transport mechanism replaced with TFTP

11:06 <re_irc> <Urhengulas> I'll put it on the list

11:18 <re_irc> <hartan> ryan-summers: Amazing to see what people have already implemented for embedded devices in rust.

11:19 <re_irc> <ryan-summers> People have been shipping products for years on embedded rust, they just don't teach you it in school yet

11:21 <re_irc> <hartan> ryan-summers: Heh, that's right. I've been asked _not_ to pick up rust for embedded development because it's such a "niche thing"...

11:22 <re_irc> <ryan-summers> Just find the right companies. I think it's miles above both C and C++, having done professional development in both

11:22 <re_irc> <ryan-summers> I write _far fewer_ bugs in Rust than I do in C/C++

11:22 <re_irc> <diondokter> ryan-summers: Me too!

11:22 <re_irc> <ryan-summers> And I write a lot of bugs ;)

11:23 <re_irc> <diondokter> Lots of good reasons here: https://tweedegolf.nl/en/blog/70/we-asked-5-people-why-they-like-embedded-rust

14:55 <re_irc> <henrik_alser> ryan-summers: In Sweden we do ;)

15:05 <re_irc> <henrik_alser> So be ahead of the curve, there are already millions of C developers out there, and Rust is growing fast…

15:06 <re_irc> <henrik_alser> hartan ^^

15:09 <re_irc> <hartan> henrik_alser: I did some fiddling with OS internals in C last year, I decided I'll never go back there for my own mental health...