<re_irc>
<@adamgreig:matrix.org> ah nice, looks like rust 1.54 coming thursday will include an updated stdarch, which includes all(?) the missing thumbv7e dsp intrinsics
<re_irc>
<@newam:matrix.org> Wow, that stm32-rs change really made it a lot faster to fail when hardware isn't selected (and with a clearer message too!)
<re_irc>
<@newam:matrix.org> New:
<re_irc>
<@newam:matrix.org> thread 'main' panicked at 'No device features selected', /home/alex/.cargo/git/checkouts/stm32wl-rs-1d841b0ed8cdadde/447cde3/build.rs:14:18
<re_irc>
<@newam:matrix.org> note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
<re_irc>
<@adamgreig:matrix.org> aah nice, that's the if/elif/elif/elif/else tree in build.rs?
<re_irc>
<@newam:matrix.org> Yup :D
<re_irc>
<@adamgreig:matrix.org> nice!
<re_irc>
<@adamgreig:matrix.org> it's sort of a shame that cargo doesn't have more powerful 'features'
<re_irc>
<@adamgreig:matrix.org> they're meant to be "always additive" and have a weird overlap with dependency names, but it's all we've got for this sort of thing too
<re_irc>
<@adamgreig:matrix.org> would be cool if cargo supported like 'mutually exclusive feature groups' and 'required choice features' and stuff
<re_irc>
<@adamgreig:matrix.org> but maybe this is a monkey's paw situation and it would be like the nightmare of c library ifdefs, lol
<cr1901>
This hasn't stopped stm32rs from runtime-enforcing mutually exclusive features?
<re_irc>
<@adamgreig:matrix.org> but it's not exactly pretty and if cargo supported it, the error messages could be better and perhaps cfg directives could more easily use groups instead of the sprawling things HALs have to turn on some code for 5 out of 20 devices or whatever
<cr1901>
Anyway, I don't think feature union is powerful enough compared to ifdef shenanigans, but that ultimately seems to be a tradeoff for "Rust favors DAG deps so the same crate can appear multiple times" that the module system leans hard into compared to C.
<re_irc>
<@newam:matrix.org> There's been some discussion on that generated by the rust-for-linux devs; they don't want infallible allocations to be available at all during compilation (not just an after-the-fact lint), so there's a lot of buzz about how to improve features to control the exports of a crate as well as the imports.
<re_irc>
<@newam:matrix.org> Some of the proposed solutions tackle the additive features problem as well as the import/export problem, so hopefully we will have something coming out of that discussion soon 😀
<cr1901>
My understanding is that it horrifically complicates cargo, so they're reluctant to do it (and I kinda agree on that respect)
<re_irc>
<@adamgreig:matrix.org> yea, and I imagine for people not using cargo it's even worse
<re_irc>
<@adamgreig:matrix.org> i would also love like.. defines with values
<re_irc>
<@adamgreig:matrix.org> you can kinda do it with env vars but ugh
<cr1901>
The solution in C is... just don't have a DAG of deps lmao
<re_irc>
<@adamgreig:matrix.org> or like build.rs reads some config file
<re_irc>
<@newam:matrix.org> Package managers in general are giant SAT solver nightmares; but I am hopeful Cargo can do it right being relatively new and having the hindsight of how C/C++ handle conditional compilation.
fabic has joined #rust-embedded
starblue1 has joined #rust-embedded
starblue has quit [Ping timeout: 255 seconds]
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
zBeeble42 has quit [Remote host closed the connection]
zBeeble42 has joined #rust-embedded
dcz_ has joined #rust-embedded
dcz has quit [Ping timeout: 252 seconds]
neceve has joined #rust-embedded
nohit has quit [Ping timeout: 276 seconds]
nohit has joined #rust-embedded
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> adamgreig: That was proposed but turned down.
<re_irc>
<@dirbaio:matrix.org> Aw that's a shame...
<re_irc>
<@dirbaio:matrix.org> It's the that rust should have something like c's defines, where they can have a value other than a bool...
<re_irc>
<@jamesmunns:matrix.org> Somewhere in the deep pages of my notes (pre-lab-notebook) I have a half written RFC for a v2 of cargo features that allows for things like this
<re_irc>
<@jamesmunns:matrix.org> It gets... complicated, though.
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
fabic has quit [Ping timeout: 258 seconds]
<re_irc>
<@lachlansneff:matrix.org> All the talk about Circlelang (C++ metaprogramming language) has made me think that rust needs better ability to introspect types at compile time or at least the ability to create proc macros in-crate.
fabic has joined #rust-embedded
_whitelogger has joined #rust-embedded
<re_irc>
<@thezoq2:matrix.org> This week I did my first embedded rust in a few months, and man, it's getting good.
<re_irc>
<@thezoq2:matrix.org> I started a project last week to build a GPS thingy to show my speed while sailing, and log the path to an SD card. It took me just over a week to get everything working and I had almost 0 software hiccups. https://gitlab.com/TheZoq2/sailgps
<re_irc>
<@thezoq2:matrix.org> Thanks for the work everyone has put in to making it this good!
<re_irc>
<@burrbull:matrix.org> thezoq2: What card reader you've used?
<re_irc>
<@thezoq2:matrix.org> burrbull: I started off with the reader on the back of this thing https://www.adafruit.com/product/358, then moved to https://www.sparkfun.com/products/544. Both worked with the exact same code, and I think all the magic happens in the card itself, and the adapter doesnt have any logic.
<re_irc>
<@adamgreig:matrix.org> @room 👋 meeting time again! agenda is https://hackmd.io/v-GSbLlTQoK6i3Dk-sFyEg, please add anything you'd like to discuss, and we'll start in 5min
<re_irc>
<@adamgreig:matrix.org> ok, let's get started!
<re_irc>
<@adamgreig:matrix.org> couple of announcements first: cortex-m-rt 0.6.15 is released with a few bug fixes, mostly in the linker script, hopefully shouldn't have any impact but as usual please shout if you run into a bug or anything
<re_irc>
<@adamgreig:matrix.org> before we dive into the embedded-hal PRs, let's cover a couple of other points...
<re_irc>
<@adamgreig:matrix.org> first up is cortex-m-rt 0.7; there's a draft PR open to get that released, but there might be some other breaking changes people would like to get in first... however no one has suggested anything yet so I'll probably push forward with the release later this week if nothing else comes up
<re_irc>
<@adamgreig:matrix.org> on cross, we've had some responses already from people interested in helping maintain, but I'm not sure what the best way to coordinate it is: perhaps a new rust-embedded team just for cross? add people directly to that repo instead? just have some PRs for now until new maintainers are more familiar with it?...
<re_irc>
... open to ideas
<re_irc>
<@sh3rm4n:matrix.org> > Happy to consider bumping MSRV to 1.40 instead if anyone has strong feelings.
<re_irc>
<@sh3rm4n:matrix.org> I feel we should not hinder ourself by thinking to about MSVR bumps. Just do it when necessary :)
<re_irc>
<@adamgreig:matrix.org> yea, I'm not too precious about it, though in this case it's easy enough to keep it as 1.39 since it's just one of the tests needed a new dependency. if anything more serious comes up that wants a higher MSRV I won't hesitate.
<re_irc>
<@therealprof:matrix.org> adamgreig: Yeah, we should see how interested people really are.
<re_irc>
<@adamgreig:matrix.org> with the cross teams: I worry a bit that we currently have a lot of teams, but maybe it's not a problem in practice? essentially it's just a way of organising which members have access to which repos, so perhaps not the end of the world to have more
<re_irc>
<@adamgreig:matrix.org> sure, but we're pretty desperate for help here; I'm not looking to put people on a trial period or anything like that, I just wonder what the best way to let people get started is
<re_irc>
<@adamgreig:matrix.org> a new team on github also gives a discussion space, but could also just chat in this room
<re_irc>
<@therealprof:matrix.org> We already extended the resources team with a person who was intersted in cross specifically but their motivation or time budget has dropped to almost zero.
<re_irc>
<@therealprof:matrix.org> Also they never engaged in other WG activity.
<re_irc>
<@adamgreig:matrix.org> is that a problem?
<re_irc>
<@therealprof:matrix.org> Well, normally not but they're also not here to discuss the future about cross.
<re_irc>
<@adamgreig:matrix.org> fair. I don't see it as a roadblock to putting new volunteers on e.g. a new cross team though
<re_irc>
<@adamgreig:matrix.org> if anything not also being on tools might make it easier for people, heh
<re_irc>
<@adamgreig:matrix.org> probably not much overlap in people interested in maintaining cross and maintaining svd2rust
<re_irc>
<@therealprof:matrix.org> I'd say we could add maintainers for cross and if they're motivated we can also onboard them into the WG later.
<re_irc>
<@adamgreig:matrix.org> add them to the repo directly, then?
<re_irc>
<@therealprof:matrix.org> Yes, we still have a few people here and there which are not WG members, like aer.
<re_irc>
<@adamgreig:matrix.org> ok, let's go with that for now then, and maybe add a cross team later or to help with publish permissions etc
<re_irc>
<@adamgreig:matrix.org> oh, actually, we can't easily, the crates.io package is only owned by the tools team and no human user, so can't change publish rights anyway without getting an admin to do something
<re_irc>
<@therealprof:matrix.org> I think we should encourage people to review cross PRs and issues and we can double check their review for a bit.
<re_irc>
<@adamgreig:matrix.org> I sure don't know enough about cross to meaningfully check someone else's review
<re_irc>
<@therealprof:matrix.org> Yeah, but some general shepherding might go a long way.
<re_irc>
<@adamgreig:matrix.org> what do you think the interface is meant to represent, then?
<re_irc>
<@therealprof:matrix.org> I think the idea might have been to specifically cater for the case that one might want to return a different buffer back.
<re_irc>
<@grantm11235:matrix.org> I don't think that is possible because the lifetime would need to match
<re_irc>
<@adamgreig:matrix.org> and it returns a slice, so who'd own it/
<re_irc>
<@therealprof:matrix.org> Could be a static buffer, no?
<re_irc>
<@disasm-ewg:matrix.org> I think the idea is to return an immutable buffer with the correct length "for free", so that you don't have to construct a slice twice
<re_irc>
<@adamgreig:matrix.org> but the length is by definition the same as the mutable slice you passed in, right?
<re_irc>
<@therealprof:matrix.org> I left a note on the issue, maybe we'll get an opinion from the author.
<re_irc>
<@therealprof:matrix.org> adamgreig: You mean as per SPI conventions?
<re_irc>
<@adamgreig:matrix.org> I mean as per the trait docs, but also spi conventions, sure
<re_irc>
<@sh3rm4n:matrix.org> It seems like, if nobody has a clear understanding what the return value meant, we should remove it. If adding it back means a breaking change, we could still add a new default implemented trait function?
<re_irc>
<@therealprof:matrix.org> Removing it is also a breaking change.
<re_irc>
<@adamgreig:matrix.org> well yea, but this is for 1.0, it's not like we're hesitating to clean things up with breaking changes here
<re_irc>
<@adamgreig:matrix.org> gotta be the easiest of all the breaking changes so far in 1.0
<re_irc>
<@therealprof:matrix.org> Nah.
<re_irc>
<@adamgreig:matrix.org> what am I missing?
<re_irc>
<@therealprof:matrix.org> I don't think it's the easiest breaking change. 😉
<re_irc>
<@therealprof:matrix.org> Anyway, no objections from my side but I'd like to hear the opinion of the creator of the API.
<re_irc>
<@adamgreig:matrix.org> ok, let's come back to that one next week then
<re_irc>
<@adamgreig:matrix.org> GrantM11235: do you think the exact same should apply to I²C too?
<re_irc>
<@grantm11235:matrix.org> Maybe, I think the only change would be that the address is stored in the struct instead of being passed in each method call
<re_irc>
<@adamgreig:matrix.org> I guess it's not usual to change bus speed per device since all devices need to work at the highest speed you operate at
<re_irc>
<@grantm11235:matrix.org> I haven't put too much thought in to i2c though
<re_irc>
<@therealprof:matrix.org> adamgreig: For I2C? Not. For SPI it might be necessary to reconfigure the bus.
<re_irc>
<@adamgreig:matrix.org> right, the proposal in 299 is just about SPI and one of the motivating factors is reconfiguring the SPI bus for each device between transactions
<re_irc>
<@adamgreig:matrix.org> but the shared nature seems the same as i2c
<re_irc>
<@grantm11235:matrix.org> The big difference between spi and i2c is chipselect
<re_irc>
<@adamgreig:matrix.org> I guess another consideration is if it can be added alongside the existing SPI traits to make it less tough on HALs to transition, but then drivers would have to know whether or not to control CS themselves so maybe defeats the purpose somewhat
<re_irc>
<@grantm11235:matrix.org> As for eldruin's concerns, I don't know what the timeframe is for 1.0, but I would really like to get this in for that
<re_irc>
<@grantm11235:matrix.org> I think that going forward, drivers should never handle cs, and hals should always handle it
<re_irc>
<@grantm11235:matrix.org> Also, we might need a `FramedCS` trait to assert that the chipselect goes high between transfers
<re_irc>
<@therealprof:matrix.org> GrantM11235: Last year? 😅
<re_irc>
<@dirbaio:matrix.org> about 299: IMO SPI traits represent "something you can do SPI transfers on", so it doesn't really matter if it's the SPI bus or the SPI device
<re_irc>
<@eldruin:matrix.org> GrantM11235: I do not understand this, can you elaborate?
<re_irc>
<@eldruin:matrix.org> as for always using managedCS, as adam said, it is just that both drivers and HALs need to know
<re_irc>
<@dirbaio:matrix.org> if a driver cares, maybe it's better to have marker traits like FramedCS/ManagedCS etc is better?
<re_irc>
<@eldruin:matrix.org> and if there is no difference in code, stuff may break easily
<re_irc>
<@eldruin:matrix.org> that was the point of managedcs
<re_irc>
<@grantm11235:matrix.org> eldruin: A simple implementation of the spi traits might set the cs pin low on initialization and then just leave it low. This would work for many devices, but some require the cs pin to go high between "packets"
<re_irc>
<@eldruin:matrix.org> I think that would be too special behavior to model in e-h
<re_irc>
<@dirbaio:matrix.org> isn't that what ManagedCS would do?
<re_irc>
<@eldruin:matrix.org> managed CS would assert and deassert before and after transfers
<re_irc>
<@eldruin:matrix.org> a managed cs implementation may work as grant described it here
<re_irc>
<@eldruin:matrix.org> but I would not try to model more specifically when the cs is asserted and deasserted than "it's managed for you"
<re_irc>
<@grantm11235:matrix.org> dirbaio: A driver always "cares" in the sense that it wants `self.spi.write(data)` to actually send the data to the device
<re_irc>
<@dirbaio:matrix.org> yeah but I mean
<re_irc>
<@dirbaio:matrix.org> the driver either manages CS manually by taking an OutputPin, or it requires the SPI to manage it with a bound on ManagedCS
<re_irc>
<@grantm11235:matrix.org> I don't think that drivers should need `where: SPI: spi::Write + spi::ActuallyWorksRight`
<re_irc>
<@disasm-ewg:matrix.org> Maybe we just need a universal way to turn non-managed SPI and CS pin into a managed SPI wrapper?
<re_irc>
<@therealprof:matrix.org> I'm not convinced ManagedCS will necessary work. Some peripherals might have timing constraints.
<re_irc>
<@dirbaio:matrix.org> there are legit uses for SPI without managed CS
<re_irc>
<@grantm11235:matrix.org> dirbaio: I don't think that drivers should manage CS manually, it leads to lots of problems
<re_irc>
<@therealprof:matrix.org> GrantM11235: I think some might have to due to the mentioned timing constraints.
<re_irc>
<@eldruin:matrix.org> therealprof: like, how long the asserts should be or a delay after the last transfer? that would be a problem indeed
<re_irc>
<@grantm11235:matrix.org> That is a configuration issue, same with the frequency
<re_irc>
<@dirbaio:matrix.org> 1. just leave CS low all the time because there's only one device in the bus and you want it to go faster. I did that recently with an ST7789 display.
<re_irc>
<@dirbaio:matrix.org> 2. you want to transmit command + address + data, and data is big so you don't want to have to concatenate all 3 in a new buffer.
<re_irc>
<@eldruin:matrix.org> dirbaio: You can use a transactional transfer for number 2
<re_irc>
<@grantm11235:matrix.org> 1. Would take an `spi::Write` without requiring `FramedCS`
<re_irc>
<@dirbaio:matrix.org> No one implements Transactionla...
<re_irc>
<@grantm11235:matrix.org> As the driver author, you don't know how many devices are on the bus, but the user does
<re_irc>
<@dirbaio:matrix.org> and even Transactional is less powerful than manually doing N transfers
<re_irc>
<@dirbaio:matrix.org> with Transactional you need all the data in RAM upfront, with manual you can generate it on the fly by chinks
<re_irc>
<@grantm11235:matrix.org> I have been considering a closure-based api to reduce the overhead of toggling cs and also reconfiguring the bus
<re_irc>
<@disasm-ewg:matrix.org> dirbaio: Maybe it's possible to make an iterator version for this?
<re_irc>
<@dirbaio:matrix.org> iterator writing byte-by-byte? that rules out DMA impls :S
<re_irc>
<@dirbaio:matrix.org> iterator of slices? maybe :D
<re_irc>
<@grantm11235:matrix.org> By the way, I am concerned that we have too many optional traits. There are a lot of useful methods, but driver authors can't rely on them actually being implemented in hals
<re_irc>
<@adamgreig:matrix.org> are a lot part of 1.0 and maybe will see more implementation once it's released?
<re_irc>
<@dirbaio:matrix.org> disasm: you pass a list of operations, so you have to have everything in ram upfront
<re_irc>
<@adamgreig:matrix.org> (oh, also, we're out of time for the meeting, thanks everyone for attending!)
<re_irc>
<@dirbaio:matrix.org> you need to set CS high, send 100x 1k blocks, set CS low? you need 100kb of RAM :D
<re_irc>
<@dirbaio:matrix.org> there's way too many variants 🤣
<re_irc>
<@eldruin:matrix.org> It would be fine to do that for SPI
<re_irc>
<@eldruin:matrix.org> just need some proof impls
<re_irc>
<@sh3rm4n:matrix.org> dirbaio: It's missing a transactional iterator trait, which pulls the next Operation, where `type Item` would be `type Operation`, maybe?
<re_irc>
<@dirbaio:matrix.org> TransactionalIter would definitely work
<re_irc>
<@grantm11235:matrix.org> Hot take: `spi::Write` and `spi::WriteIter` could and should be the same trait if we had an easy way for hals to derive them
<re_irc>
<@disasm-ewg:matrix.org> GrantM11235: But sometimes you can't do WriteIter easily, for example, if you have DMA
<re_irc>
<@dirbaio:matrix.org> trait with 2 methods, write has a default impl that calls writeiter
<re_irc>
<@grantm11235:matrix.org> The hal should be able to easily derive a writeiter method that writes to a buffer and then dmas that
<re_irc>
<@dirbaio:matrix.org> but for nrf's i2c you can't implement writeiter *at all*, it's impossible
<re_irc>
<@disasm-ewg:matrix.org> That's why we had Default markers...
<re_irc>
<@disasm-ewg:matrix.org> So that you can add a default impl explicitly
<re_irc>
<@dirbaio:matrix.org> GrantM11235: how is the buffer allocated? on stack it has to have an aribtrary max size, on heap you need alloc which is not nice
<re_irc>
<@grantm11235:matrix.org> dirbaio: On the stack. Fill it up, send it, repeat
<re_irc>
<@dirbaio:matrix.org> maybe you can't DMA multiple buffers back-to-back
<re_irc>
<@dirbaio:matrix.org> nrf can't do it for i2c
<re_irc>
<@dirbaio:matrix.org> it can for uart, spi
* re_irc
@eldruin:matrix.org needs to leave. bye people!
<re_irc>
<@grantm11235:matrix.org> dirbaio: So any driver that uses `i2c::WriteIter` can never be used on nrf? That sucks
<re_irc>
<@grantm11235:matrix.org> dirbaio: What would happen if someone used `shared-bus` with the driver from 1? It seems like everything would break
<re_irc>
<@dkhayes117:matrix.org> adamgreig Is there a RISC-V wg team, I'd like to be apart of it if so.
<re_irc>
<@adamgreig:matrix.org> yep! https://github.com/rust-embedded/wg#the-risc-v-team, probably chat to one of the current first but the process is to open a PR adding yourself to that list on the README and then that team votes
<re_irc>
<@davidcole1340:matrix.org> Hi all, I'm working on getting cross running properly on arm64 hosts (#567), got most of the dockerfiles however had some problems with having to bump the Ubuntu version significantly as most niche targets don't have toolchains for ARM64 on older versions (MIPS only has toolchains on 21.04 😢
<re_irc>
<@davidcole1340:matrix.org> Anyone got any ideas on how to work around this without compiling the whole toolchain every build?