<re_irc>
<@windfisch42:matrix.org> thanks for the pointer to embassy, newam. I am not sure how intrusive embassy is, if I understood it correctly, it requires one to write the whole application around it, right? Do you think I could profit from embassy (using it or just copying from / being inspired by it) while only using it for the USB driver's internal code?
<re_irc>
<@newam:matrix.org> I suspect it should be possible to use it just for the USB code, but that could turn out either way. At the very least it is good inspiration.
<re_irc>
<@firefrommoonlight:matrix.org> alex:matrix.sempto.net: Thanks for correcting - that makes sense!
<re_irc>
<@alex:matrix.sempto.net> firefrommoonlight:matrix.org: Sorry, was asleep. Anyways, the issue is:
<re_irc>
<@alex:matrix.sempto.net> - ISR 1 reads the status register for RMW
<re_irc>
<@alex:matrix.sempto.net> So right now my workaround is ```unsafe{timer.sr.write(|w|w.bits(FFFFFFFD));} //Clear CC1IF```
starblue has quit [Ping timeout: 260 seconds]
starblue has joined #rust-embedded
radens has quit [Quit: Connection closed for inactivity]
<re_irc>
<@grantm11235:matrix.org> alex:matrix.sempto.net: You could also do `w.bits(0xFFFFFFFF).cc1if().clear_bit()`
<re_irc>
<@alex:matrix.sempto.net> Right, that is clearer. thanks!
<re_irc>
<@grantm11235:matrix.org> You could also replace `0xFFFFFFFF` with `u32::MAX`, I'm not sure which is more readable
<re_irc>
<@alex:matrix.sempto.net> In that case I think the hex literal conveys the intent somewhat better. Though u32::MAX is good for not making the reader count the number of "F"
PyroPeter has quit [Ping timeout: 265 seconds]
PyroPeter has joined #rust-embedded
<re_irc>
<@burrbull:matrix.org> you could also use underscore 0xFFFF_FFFF
<re_irc>
<@burrbull:matrix.org> `!0` 😃
cr1901 has quit [Ping timeout: 245 seconds]
cr1901 has joined #rust-embedded
richardeoin has quit [*.net *.split]
ni has quit [*.net *.split]
ni has joined #rust-embedded
richardeoin has joined #rust-embedded
cyrozap has quit [*.net *.split]
cyrozap has joined #rust-embedded
ni has quit [Quit: WeeChat 3.0]
ni has joined #rust-embedded
jackneilll has quit [Read error: Connection reset by peer]
<re_irc>
<@l0uisc:matrix.org> burrbull:matrix.org: TIL that works in Rust. I thought it wouldn't work because Rust doesn't allow for non-boolean expressions as conditions.
<re_irc>
<@dirbaio:matrix.org> C's `~` is `!` in Rust
<re_irc>
<@l0uisc:matrix.org> dirbaio:matrix.org: I'm confused now. How is unary `-` in C the same as `!` in Rust?
<re_irc>
<@dirbaio:matrix.org> `~`, not `-`
<re_irc>
<@dirbaio:matrix.org> unaty bitwise not
<re_irc>
<@l0uisc:matrix.org> Ah, makes sense. My browser is rendering `~` extremely flat for some reason...
<re_irc>
<@dirbaio:matrix.org> precisely because rust doesn't allow boolean ops with integers, `!0` can be unambiguous: it's bitwise not instead of boolean not
<re_irc>
<@dirbaio:matrix.org> so it can be the same operator
<re_irc>
<@dirbaio:matrix.org> IMO it's inconsistent though
<re_irc>
<@dirbaio:matrix.org> and/or have different operators for bitwise vs boolean: `&`, `|` vs `&&`, `||`
<re_irc>
<@dirbaio:matrix.org> while not is the same: `!`
<re_irc>
<@dirbaio:matrix.org> 🤷
<re_irc>
<@dirbaio:matrix.org> maybe this is why:
<re_irc>
<@dirbaio:matrix.org> > Note that the && and || operators short-circuit, i.e., they only evaluate their second operand if it contributes to the result. Since this behavior is not enforceable by traits, && and || are not supported as overloadable operators.
<re_irc>
<@l0uisc:matrix.org> I don't think so. The type dictates whether it performs a negation of a whole byte representing a single boolean, or an n-byte wide bitfield where every bit represents a single boolean, and thus the entire bitfield of n*8 boolean values needs to be flipped.
<re_irc>
<@l0uisc:matrix.org> dirbaio:matrix.org: I think you are correct, and IIRC Rust used `~` for `Box` a long time ago. So it is a combination of that and a historical vestige probably.
<re_irc>
<@dirbaio:matrix.org> wow TIL ~ was a thing
<re_irc>
<@dirbaio:matrix.org> and they were talking about `Box<T, A>` custom allocators back then in 2014! something that's just now becoming a thing in 2021. Insane foresight :D
<re_irc>
<@l0uisc:matrix.org> dirbaio:matrix.org: Well, or C++ started adding their overloads which takes an allocator around then and thus it was a buzz word.
GenTooMan has joined #rust-embedded
emerent has quit [Ping timeout: 268 seconds]
emerent has joined #rust-embedded
<re_irc>
<@richarddodd:matrix.org> I feel like there were some pragmatic decisions taken at the beginning, because there was a singular use-case back then: make components for a browser that aren't going to have security vulnerabilities in them. Embedded/kernel/etc applications came later.
<re_irc>
<@richarddodd:matrix.org> (I did get involved in Rust back then, but not as much as I am now)
<re_irc>
<@richarddodd:matrix.org> IIRC there was also a 3rd type of pointer for garbage-collected memory.
<re_irc>
<@richarddodd:matrix.org> And green threads (like go-routines in Go)
<re_irc>
<@whitequark:matrix.org> dirbaio:matrix.org: i feel old now >_<
<re_irc>
<@whitequark:matrix.org> richarddodd: yeah, was for GC'd pointers... which were never actually garbage-collected
<re_irc>
<@whitequark:matrix.org> as for a singular use case: perhaps that's how the upstream felt, but back in 2013 i decided to stop developing a language i was working on targeting embedded in favor of Rust
<re_irc>
<@whitequark:matrix.org> because it was immediately obvious that Rust is doing what I wanted to do, but better and with much brighter prospects
<re_irc>
<@whitequark:matrix.org> took more than a few years for it to happen :D
<re_irc>
<@richarddodd:matrix.org> :)
<re_irc>
<@richarddodd:matrix.org> I do think that some kind of garbage collection could be a nice addition (optional of course).
<re_irc>
<@richarddodd:matrix.org> There are some things that you just can't do as efficiently with Rc
<re_irc>
<@grantm11235:matrix.org> I don't really like the fact that `self.with_chipselect(|inner| inner.write(words))` returns `Result<Result<(), SpiErr>, CsErr>`
<re_irc>
<@grantm11235:matrix.org> Some `Into` trait bounds might help, but that could cause other problems too
<re_irc>
<@grantm11235:matrix.org> I could also try to force `<T as Chipselect>::Error` and `<T as Write>::Error` to be the same
<re_irc>
<@grantm11235:matrix.org> Which I think means that I would need `<T::Inner as Write>::Error: Into<T as Write>::Error`
<re_irc>
<@ubik:matrix.org> x-post from stm32-rs: Any suggestions with regards to playing sound files from an SD card? I'd like to avoid blocking operations. I see the STM32F4xx has an SDIO interface which can use DMA, but I guess there are no libs in the rust world which gives me a usable file system on that? I am currently using the great `embedded_sdmmc`, but it doesn't seem to support DMA transfers under the hood.
<re_irc>
<@dirbaio:matrix.org> ubik:matrix.org: embassy-stm32 has async sdmmc for stm32h7
<re_irc>
<@dirbaio:matrix.org> no example though, but iirc thalesfragoso had one somewhere with async fat32
<re_irc>
<@dirbaio:matrix.org> not sure how hard it'll be to adapt to the F4
<re_irc>
<@thalesfragoso:matrix.org> The peripheral is a bit different, but I guess it shouldn't be too hard, you mostly need to change configuration steps, the public interface should remain pretty much the same
<re_irc>
<@thalesfragoso:matrix.org> And I used a fork from embedded-sdmmc, to make it async
<re_irc>
<@thalesfragoso:matrix.org> Oh, wait, not sure if the F4 has a exclusive DMA for the sdmmc like the H7 has
<re_irc>
<@thalesfragoso:matrix.org> If it doesn't, the change will need to be bigger
<re_irc>
<@grantm11235:matrix.org> I think that the
<re_irc>
<@grantm11235:matrix.org> <T as Chipselect>::Error: From<<T::Inner as Write>::Error>
<re_irc>
<@grantm11235:matrix.org> ```rust
<re_irc>
<@grantm11235:matrix.org> clause is a problem. I think it would make it too difficult to implement a generic spi mutex that is independent of any HAL
<re_irc>
<@ubik:matrix.org> I see it uses a patched branch of `embedded-sdmmc`?
<re_irc>
<@dirbaio:matrix.org> yeah, adding async support
<re_irc>
<@ubik:matrix.org> hm... but then I'd have to switch my project to async
<re_irc>
<@dirbaio:matrix.org> what you want then is nonblocking-but-not-async fat32?
<re_irc>
<@dirbaio:matrix.org> implementing that sounds like giant state machine spaghetti, good luck...
<re_irc>
<@ubik:matrix.org> I was thinking of just using ISRs
<re_irc>
<@ubik:matrix.org> but I clearly haven't made my decision yet, hence why I'm asking :)
<re_irc>
<@dirbaio:matrix.org> to read files out of a FAT filesystem you have to do lots of things
<re_irc>
<@dirbaio:matrix.org> read the root dir, find the dir you want, read the next dirs, find the file, look up which blocks it is in the FAT, read the actual blocks
<re_irc>
<@dirbaio:matrix.org> all that "do this, then that, then that" stuff is easy to do in a blocking way: you just do it
<re_irc>
<@dirbaio:matrix.org> if you want to do it non-blocking you have to convert everything into a giant state machine: you store what state you're in and what operation you're doing, when the irq fires you check the state then start a new operation then return, etcetc
<re_irc>
<@dirbaio:matrix.org> OR
<re_irc>
<@dirbaio:matrix.org> you use async/await, so you can write code that "looks like" blocking code, but the compiler automatically translates it into a state machine just like the one you'd have written by hand
<re_irc>
<@ubik:matrix.org> yeah, it does make sense
<re_irc>
<@adamgreig:matrix.org> Could you more or less easily just use an async fn for they one isr, with the isr being an executor that just polls the one future?
<re_irc>
<@dirbaio:matrix.org> yup you totally can
<re_irc>
<@adamgreig:matrix.org> seems like a cute way to just write a state machine without even reaching for a whole async framework
<re_irc>
<@adamgreig:matrix.org> I guess you pretty quickly want the rest of the framework though
<re_irc>
<@dirbaio:matrix.org> the main problem is you're "coupling" the Future to "where" it should be polled
<re_irc>
<@dirbaio:matrix.org> for example if you want to read data from sdmmc then write it to usart, you have to arrange for both sdmmc and usart (and dma?) irqs to poll the future
<re_irc>
<@adamgreig:matrix.org> yea, fair
<re_irc>
<@adamgreig:matrix.org> I'm thinking of like my little IR protocol decoder that lives in a timer capture IR and accumulates bits until it spits out whole commands
<re_irc>
<@ubik:matrix.org> anyway, giving embassy a try
<re_irc>
<@dirbaio:matrix.org> how can I get my cargo to be like rustup's cargo?
<re_irc>
<@firefrommoonlight:matrix.org> Do you need a normal file system? Is that due to how SD cards work? I'm looking to play audio files as well, but they just need to be a few short ones. Going to go on onboard flash, or if too large, external QSPI flash, as a `u16` array.
<re_irc>
<@firefrommoonlight:matrix.org> Probably not relevant since you likely are dealing with standard audio files or something user editable on a PC etc
<re_irc>
<@firefrommoonlight:matrix.org> Or long music files or w/w
<re_irc>
<@firefrommoonlight:matrix.org> I'm going with flash since I'm just playing a few short clips of voice instructions
<re_irc>
<@firefrommoonlight:matrix.org> Hmm... back of the napkin calculations indicate ~2Mb, so probably QSPI flash
<re_irc>
<@firefrommoonlight:matrix.org> for 20s of high quality audio
<re_irc>
<@firefrommoonlight:matrix.org> dirbaio: Rando question - do you have a background in web servers / backend?
<re_irc>
<@dirbaio:matrix.org> before akiles I used to do mostly backend yep
<re_irc>
<@dirbaio:matrix.org> python/go
<re_irc>
<@firefrommoonlight:matrix.org> Gotcha!
<re_irc>
<@dirbaio:matrix.org> I've done most of the akiles backend too
<re_irc>
<@dirbaio:matrix.org> why? 🤣
<re_irc>
<@firefrommoonlight:matrix.org> I have a theory that Async/Await gained popularity for that use case
<re_irc>
<@ubik:matrix.org> firefrommoonlight: yeah, I want to actually play different samples you could write on the card. I thought of just ditching FAT and jsut write sequencially to it like in tape storage, but then I'd lose the possibility to change them.
<re_irc>
<@dirbaio:matrix.org> lol
<re_irc>
<@firefrommoonlight:matrix.org> Ie on Python, it's used heavily by a crop of server-side frameworks, and in Rust, it's also that use case that it's v popular with
<re_irc>
<@ubik:matrix.org> oh, no I2S libs for embassy yet, I imagine
<re_irc>
<@firefrommoonlight:matrix.org> Same with Node.js
<re_irc>
<@dirbaio:matrix.org> I used python async veeery little
<re_irc>
<@dirbaio:matrix.org> and nodejs sucks
<re_irc>
<@dirbaio:matrix.org> Go is "kind of" async by default with the goroutine stuff
<re_irc>
<@firefrommoonlight:matrix.org> ub|k: Sounds like you can't take the shortcut I'm doing
<re_irc>
<@firefrommoonlight:matrix.org> Gotcha. And amen on Node!
<re_irc>
<@dirbaio:matrix.org> but I'd say rust async's advantages are very different for backend and for embedded
<re_irc>
<@firefrommoonlight:matrix.org> Node feels like a "I am a JS programmer who won't learn another language" tool. See also micropython
<re_irc>
<@dirbaio:matrix.org> for backend it's "being able to serve 1000s of connections without paying the cost of 1000s of real OS threads"
<re_irc>
<@dirbaio:matrix.org> for embedded it's "being able to do multiple things concurrently when *you don't have real OS threads at all*"
<re_irc>
<@firefrommoonlight:matrix.org> Without a doubt - that was my assumption to re processing diff connections
<re_irc>
<@firefrommoonlight:matrix.org> You're doing the best course of action for demonstrating that - building / running a popular Async embedded framework.
<re_irc>
<@firefrommoonlight:matrix.org> And have made it work
<re_irc>
<@dirbaio:matrix.org> or "being able to do multiple things concurrently without paying for a "real" fat RTOS and without state machine spaghetti hell" 🤣
<re_irc>
<@firefrommoonlight:matrix.org> I don't think I've worked on anything complicated enough to warrant an RTOS or async yet
<re_irc>
<@firefrommoonlight:matrix.org> From what I gather from casual polling of C embedded devs, in C, they're quick to use an RTOS for any concurrency
<re_irc>
<@firefrommoonlight:matrix.org> For resource sharing, timer management etc
<re_irc>
<@dirbaio:matrix.org> because they don't have async 😎
<re_irc>
<@firefrommoonlight:matrix.org> Yea - it seems to fill the same need
<re_irc>
<@dirbaio:matrix.org> many C RTOS's also have the role of embedded-hal too. common apis for spi, i2c, gpio.. so that drivers can run on any chip
<re_irc>
<@dirbaio:matrix.org> because they don't have traits either 😎
<re_irc>
<@dirbaio:matrix.org> dirbaio:matrix.org: to answer my own question: `LIBZ_SYS_STATIC=1 cargo build --release --features vendored-openssl,libgit2-sys/vendored,curl-sys/static-curl`
<re_irc>
<@dirbaio:matrix.org> I hate it that there's no standard for -sys crates for these things 🤮
<re_irc>
<@dirbaio:matrix.org> /usr/local/bin/cargo-batch: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.32' not found (required by /usr/local/bin/cargo-batch)
<re_irc>
<@dirbaio:matrix.org> /usr/local/bin/cargo-batch: /lib/x86_64-linux-gnu/libc.so.6: version `GLIBC_2.33' not found (required by /usr/local/bin/cargo-batch)
<re_irc>
<@dirbaio:matrix.org> goddamnit
<re_irc>
<@adamgreig:matrix.org> build for musl :p
<re_irc>
<@dirbaio:matrix.org> yep this worked `LIBZ_SYS_STATIC=1 cargo build --release --features vendored-openssl,libgit2-sys/vendored,curl-sys/static-curl --target x86_64-unknown-linux-musl`
<re_irc>
<@adamgreig:matrix.org> I love the four different ways to ask deps to static link
<re_irc>
<@huntc:matrix.org> Hey there. I'm developing "A client/multi-server event-bus protocol suitable for half-duplex communications" and was wondering if anyone knew of something similar in the spirit of avoiding the re-invention of wheels etc. The protocol lends itself to RS485 being used at the physical layer, but not exclusively. Being event driven is key. Note that I've not yet written any code, but I'll start that today as I...
<re_irc>
... need something like this for a client's project.
<re_irc>
<@huntc:matrix.org> adamgreig: Yeah. Been chatting with him and looking into his fabulous activities. James appears to have adopted an MQTT style of approach. MQTT doesn’t lend itself well to subscribing to events in the past. Events are emphemeral there and so unsuitable for me.
<re_irc>
<@therealprof:matrix.org> huntc:matrix.org: Not quite true. That's only the case for QoS level 0. In QoS level 1 the broker has to cache the messages until they've been transferred at least once.
<re_irc>
<@huntc:matrix.org> I also find MQTT a bit chatty and not particularly suitable to half-duplex communications.
<re_irc>
<@huntc:matrix.org> And... the MQTT spec itself assumes TCP.
<re_irc>
<@therealprof:matrix.org> MQTT 3.11 is okay, MQTT 5 can be extremely verbose and chatty. Not a big fan of MQTT myself but the world has certainly seen worse.
<re_irc>
<@huntc:matrix.org> therealprof:matrix.org: Agreed. I should also say that I've fully implemented MQTT 3.1 from a client and server perspective. At least mqtt org has dropped the "simple" messaging that they had as it wasn't simple to implement! Although, it is still promoted as light and efficient...
<re_irc>
<@therealprof:matrix.org> Yeah, I've also implemented a MQTT 3.11 and 5.0 client from scratch. 😉
<re_irc>
<@therealprof:matrix.org> Things get really weird when you try to implement a request/response mechanism on top of MQTT.
<re_irc>
<@huntc:matrix.org> Probably not the correct thing to use for request/reply. :-)
<re_irc>
<@huntc:matrix.org> Flip-flop is similar in that you can send a command, but the events you get back can be entirely unrelated.
<re_irc>
<@therealprof:matrix.org> Well, not my idea. Just making some lemonade out of the lemons handed to me. 😉
<re_irc>
<@therealprof:matrix.org> A lot of people really love MQTT; I have no idea why.
<re_irc>
<@huntc:matrix.org> I think because of how it was indeed promoted - lightweight and simple.
<re_irc>
<@huntc:matrix.org> I guess the tooling and language support for it is good too.
<re_irc>
<@therealprof:matrix.org> It's okay for homegamer stuff, I'm talking about professionals.
<re_irc>
<@huntc:matrix.org> If the goal is interoperability then I guess it makes senses.
<re_irc>
<@therealprof:matrix.org> huntc:matrix.org: Well, the transport is super interoperable. The problem is: there's really nothing on top of it, it's all proprietary.
<re_irc>
<@huntc:matrix.org> True
<re_irc>
<@therealprof:matrix.org> How do you provision a MQTT connection? Easy, download and integrate the AWS IoT SDK and they'll sort it for you. Not happy with AWS, do the same with MS Azure IoT, not happy with that either? Move on to IBM... 😉
<re_irc>
<@huntc:matrix.org> :-)
<re_irc>
<@huntc:matrix.org> I'm amazed with the use of MQTT and TLS over NB-IOT...
<re_irc>
<@therealprof:matrix.org> How do you transfer data? Easy, pick any serialisation and put it on a message. Where do you get the topic from? Uhhh....
<re_irc>
<@huntc:matrix.org> Try getting that chatty connection to a cell tower 20kms away and through a field of crops :-)
<re_irc>
<@huntc:matrix.org> Yet the perception is that we can do this because MQTT has become synonymous with IoT.
<re_irc>
<@therealprof:matrix.org> Yeah, but the industry I'm working in is not that fit in IoT despite some weird attempts every now and then to prove that they would be.
<re_irc>
<@huntc:matrix.org> Interesting, outside of IoT I would have thought that Kafka would be more the choice.
<re_irc>
<@huntc:matrix.org> (it has been for me)
<re_irc>
<@huntc:matrix.org> (there's also RabbitMQ and others of course)
<re_irc>
<@therealprof:matrix.org> "We want to use MQTT". "Fine by me, if you know how to scale it up to millions of connections...", "nonono, you bring the MQTT setup!"
fooker has quit [Ping timeout: 245 seconds]
<re_irc>
<@huntc:matrix.org> Always important to ask why. :-)
<re_irc>
<@therealprof:matrix.org> huntc:matrix.org: Kafka is definitely a thing in IT, not so much for exchange between millions of devices with their master.
<re_irc>
<@therealprof:matrix.org> huntc:matrix.org: That is not a question you will receive an answer to.
<re_irc>
<@9names:matrix.org> ubik:matrix.org: In the simplest case you can assume files are contiguous. If you never delete files from the filesystem this will be what happens, in practice. A read-only FAT library that assumes this can be very lean - of course then you have to remember to follow that rule or you'll get chunks of some other file's data during playback.
<re_irc>
<@9names:matrix.org> There's also a tool for windows (contig) you can use to make all files on a fat filesystem contiguous
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
fooker has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> Christopher Hunt I have some feelings on this topic, and though anachro is currently MQTT-SN QoS 0 inspired, I do intend to have some other comms styles (just haven't needed it yet).
<re_irc>
<@jamesmunns:beeper.com> Happy to chat if polishing up/building out anachro/Powerbus is interesting for you.
<re_irc>
<@jamesmunns:beeper.com> (shoot me a DM, or this would be on-topic for the anachro room)