<re_irc>
<@ryan-summers:matrix.org> : Honestly, there's nothing that ever equates to running hardware-in-the-loop. I try to set it up on all my projects. But I also do option 2 primarily
<re_irc>
<@ryan-summers:matrix.org> Emulators only do so much
<re_irc>
<@romancardenas:matrix.org> I have a couple of noob questions, hopefully you can illuminate me:
<re_irc>
2. Why does the atomic emulation thing need the 32 registers if "riscv-rt" does not?
<re_irc>
1. Why does "riscv-rt" NOT store the 32 user registers in its trap?
<re_irc>
<@thejpster:matrix.org> TIL that the libcore tests for Rust mostly require libstd to run.
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> (both because the test runner requires libstd, but also individual tests often use libstd when testing some libcore function or feature)
<re_irc>
<@thejpster:matrix.org> "How do they run the libcore test suite on ARMv6-M?" you might ask. Well, they don't. The thumbv6m-unknown-none-eabi target is only Tier 2.
<re_irc>
<@adamgreig:matrix.org> That's basically what it means to be tier 2 though right? Only very few targets are tier 1, it was a big deal when aarch64 on Linux got promoted, and only due to commitments from Arm iirc?
kenny has joined #rust-embedded
<re_irc>
<@onsdag:matrix.org> : for the 1st one my guess would be performance, only caller saved registers are stacked, since they're the only ones running the risk of getting ruined. for the 2nd one, afaik, the emulation takes the stack pointer as an argument then performs the atomic operation on the stacked registers, not on the registers directly. in that case, if the requested atomic instruction operates on registers outside of what is usually...
<re_irc>
... stacked, it couldn't be emulated.
<re_irc>
<@onsdag:matrix.org> maybe you could add the stacking of the remaining registers to the exception handler you want to provide to keep whatever gains are made by cutting the trap frame short for regular interrupts
<re_irc>
<@romancardenas:matrix.org> I've been studying both crates and it makes sense. the emulation trap needs the trap frame to store all the user registers in order from x0 to x31, so keeping the minimal stacking seems difficult.
<re_irc>
<@romancardenas:matrix.org> I was thinking that "riscv-rt" could always leave space for the 32 registers and conditionally filling them exhaustively with a feature gate, but probably we should before move all the assembly code in "riscv-rt" to "global_asm!" macros instead of pre-built binaries (as in "cortex-m-rt")
<re_irc>
<@onsdag:matrix.org> that's the way esp-riscv-rt does it anyway, i think it makes sense
<re_irc>
<@onsdag:matrix.org> i mean the global_asm part
<re_irc>
<@romancardenas:matrix.org> My guess is that the current implementation of "riscv-rt" is older than the stabilized version of "global_asm!", and that is why it is not implemented this way
<re_irc>
<@firefrommoonlight:matrix.org> Thank you. This sort of basic level work is a critical platform to all the other stuff
<re_irc>
<@firefrommoonlight:matrix.org> * work on the fundamentals
<re_irc>
<@thejpster:matrix.org> if anyone is thinking "but it doesn't list Cortex-M3 any more", my answer is "No, and it doesn't list the Intel Core i3-7700U either". I can't recall what documentation we have around the Arm and RISC-V targets, but that would be a place to help people work out which CPUs are supported in which targets.
<re_irc>
<@almindor:matrix.org> : Probably so. I do tend to like the separate asm more personally though, it just seems cleaner
<re_irc>
<@dirbaio:matrix.org> : should we release nb too?
<re_irc>
<@dirbaio:matrix.org> I guess yes
<re_irc>
<@eldruin:matrix.org> yes
<re_irc>
<@dirbaio:matrix.org> : done
<re_irc>
<@dirbaio:matrix.org> <3 thanks
<re_irc>
<@dirbaio:matrix.org> so, only blocker left for 1.0 is the serial traits
<re_irc>
<@dirbaio:matrix.org> released
<re_irc>
- embedded-hal-async 0.2-alpha.2
<re_irc>
- embedded-hal-bus 0.1-alpha.3
<re_irc>
- embedded-hal-nb 1.0-alpha.3
<re_irc>
- embedded-hal 1.0-alpha.11
emerent has quit [Ping timeout: 246 seconds]
emerent_ has joined #rust-embedded
emerent_ is now known as emerent
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> @room meeting time again! agenda is https://hackmd.io/ms-_36kSQHWF-yTOK6T-xw, please add anything you want to announce or discuss, we'll start in a few mins 👋
<re_irc>
<@jamesmunns:beeper.com> I hope everyone has had a great week!
<re_irc>
<@adamgreig:matrix.org> I'm testing university student rocket engines all week, so far so hot :D
<re_irc>
<@thejpster:matrix.org> I’ve been building gcc all day, so, not so much today.
<re_irc>
<@thejpster:matrix.org> I even made the fan come on on my MacBook. I didn’t even know it had a fan.
<re_irc>
<@jamesmunns:beeper.com> : When do we get the slowmoguys footage?
<re_irc>
<@thejpster:matrix.org> Do you liquidise the university students to get better combustion, or are they packed in as solid fuel?
<re_irc>
<@thejpster:matrix.org> I mean kerosene is traditional but I suppose students are carbon neutral.
<re_irc>
<@adamgreig:matrix.org> lots of things look like a fuel if you squint.. and apply enough oxidiser
<re_irc>
<@adamgreig:matrix.org> the alcohol we pump in... the cutting fluid they left on the machined parts... the metal of the combustion chamber once it gets a bit too hot...
<re_irc>
<@thejpster:matrix.org> And if you were to stand at the business end.
<re_irc>
<@jannic:matrix.org> I only demasted a single sailing dinghy last week. Nothing noteworthy :-)
<re_irc>
<@adamgreig:matrix.org> we try to avoid them standing at the business end!
<re_irc>
<@adamgreig:matrix.org> did you.... intend to demast it
<re_irc>
<@jannic:matrix.org> No I intended to be at the next buoy first. But without the mast, the other laser was faster for some reason.
<re_irc>
<@jannic:matrix.org> He was probably cheating. I have no other explanation.
<re_irc>
<@adamgreig:matrix.org> that must be it
<re_irc>
<@adamgreig:matrix.org> anyway, let's begin! my only announcement is cribbed from a couple hours ago when released the new embedded-hal alpha
<re_irc>
<@adamgreig:matrix.org> does anyone else have announcements?
<re_irc>
<@thejpster:matrix.org> I made a sparc-unknown-none-elf target and it booted in the Leon3 simulator first try.
<re_irc>
<@thejpster:matrix.org> But don’t tell anyone because it’s a surprise for a conference later in the year.
<re_irc>
<@adamgreig:matrix.org> oh fun, with stock llvm?
<re_irc>
<@thejpster:matrix.org> Yea
<re_irc>
<@thejpster:matrix.org> We’ll need a SPARC Team soon!
<re_irc>
<@jessebraham:matrix.org> : I just now cut the releases, but there are new HALs out for the Espressif chips! Full release notes can be found here:
<re_irc>
<@adamgreig:matrix.org> I think the simplest option is probably to see if they would like to join the existing cortex-a team and therefore can maintain aarch64-cpu
<re_irc>
<@adamgreig:matrix.org> but with probably a smaller than usual number of approving votes from other team members :P
<re_irc>
<@adamgreig:matrix.org> we have in the past had this situation where it might make sense for someone to help maintain just a particular repo/crate, rather than joining a team, and I think we punted on the idea then too
<re_irc>
<@adamgreig:matrix.org> but I wanted to check if anyone had particular thoughts about the concept of people helping to maintain a single crate rather than a team?
<re_irc>
<@thejpster:matrix.org> Is the issue that by joining the team they then feel responsible for a bunch of other crates they don’t care about?
<re_irc>
<@adamgreig:matrix.org> yea. it's a real buy-one-get-some-free deal
<re_irc>
<@thejpster:matrix.org> I’m not sure we have the machinery for anything smaller than a team and I’m not sure I like the idea of just randomly adding people to GitHub or crates.io outside of the normal mechanism
<cr1901>
I don't personally have a problem w/ it, but I defer to what others think.
<re_irc>
<@thejpster:matrix.org> And we should put more people on the cortex-a team either way.
<re_irc>
Where’s our VACANCIES.md?
<cr1901>
adamgreig: Btw, the svd2rust link is a copy of the aarch64 link in the hackmd file
<re_irc>
<@adamgreig:matrix.org> oops, thanks
<re_irc>
<@therealprof:matrix.org> : Same. We had some single members in the past but have assimilated them into the org.
<re_irc>
<@eldruin:matrix.org> we should list this repo as being maintained by cortex-a
<re_irc>
<@adamgreig:matrix.org> yea, good point
<re_irc>
<@eldruin:matrix.org> it's also not listed in the wg readme
<re_irc>
<@eldruin:matrix.org> minor point anyway
<re_irc>
<@adamgreig:matrix.org> I'll get those updated
<re_irc>
<@adamgreig:matrix.org> OK, next up is the ongoing bors business, book repo is swapped 🎉, no docs yet on the general procedure though, I've been too busy to put much of anything together
<re_irc>
<@adamgreig:matrix.org> the cortex-m-rt hardfault handler PR is I think still waiting for a bug fix, then good to go after that, no update this week (https://github.com/rust-embedded/cortex-m/pull/476)
<re_irc>
<@adamgreig:matrix.org> the svd2rust per-peripheral steal() is I think also good to merge now? https://github.com/rust-embedded/svd2rust/pull/723 I'll drop a comment and unless any tools team people have specific problems we can merge that today
<re_irc>
<@adamgreig:matrix.org> which finally leaves embedded-hal 1.0 I guess
<re_irc>
<@eldruin:matrix.org> not much left I think
<re_irc>
<@thejpster:matrix.org> How many HALs have a 1.0 alpha implementation ready to go?
<re_irc>
<@thejpster:matrix.org> And if we don’t know, does anyone have time to do a quick survey?
<re_irc>
<@jessebraham:matrix.org> I'm updating "esp-hal" to the latest "embedded-hal-*" versions as we speak
<re_irc>
<@vollbrecht:matrix.org> what do you guys thing, that we maybe define a timeframe where some hal crates needs to implement all the embeddedl-hal 1.0 alphas - so its battle tested - and then we really know we are ready for a 1.0 release
<re_irc>
<@thejpster:matrix.org> We’ll also need a blog post to walk through the changes.
<re_irc>
<@vollbrecht:matrix.org> esp-idf-hal needs updating from .10 to .11 but will get it in the couple next days
<re_irc>
<@eldruin:matrix.org> yes we should probably do a beta release beforehand as well
<re_irc>
<@thejpster:matrix.org> alpha says “not finished”. I second the beta.
<re_irc>
<@dirbaio:matrix.org> embassy nrf, stm32, rp are updated to latest, no issues to report
<re_irc>
alpha10 -> alpha11 was a nice to cut bloat. diff +177 −386 :)
<re_irc>
<@jannic:matrix.org> rp2040-hal is still at alpha.10. I can care about the update to alpha.11.
<re_irc>
<@vollbrecht:matrix.org> i also think about acceptance from the users, so it needs to be there for i dont know 3 months in multiple major hals
<re_irc>
<@adamgreig:matrix.org> stm32f4xx-hal has alpha.10 already, I think a few other stm32-rs hals do too
<cr1901>
I do not have the bandwidth to make an MSP430 HAL rn. My inline HALs seemed to work fine tho, and upgrading to alpha.11 should be easy enough
<re_irc>
<@adamgreig:matrix.org> hopefully the beta can be basically identical to alpha.11 so at least hals can update to it and test it fairly easily, but given how prevalent alpha support is already I wonder how much difference a beta makes?
<re_irc>
<@adamgreig:matrix.org> no objection to it though, hopefully one pass at a beta will be enough
<re_irc>
<@dirbaio:matrix.org> I wouldn't put a timeout like "3 months"
<re_irc>
<@thejpster:matrix.org> I think it makes a statement. And practicing releases is no bad thing.
<re_irc>
<@dirbaio:matrix.org> people are either fast to update, or never update because they want to stick to non-alpha/beta stuff
<re_irc>
<@vollbrecht:matrix.org> i think the feedback from the hal's authors are mostly, do we have enough feedback from driver authors?
<re_irc>
<@vollbrecht:matrix.org> * mostly there,
<re_irc>
<@dirbaio:matrix.org> especially for drivers, people don't like using alpha/beta releases because it limits compatibility
<re_irc>
<@dirbaio:matrix.org> vs hals which can impl 0.2 and 1.0 at the same time
<re_irc>
<@dirbaio:matrix.org> anyway
<re_irc>
<@dirbaio:matrix.org> before we do the 1.0 beta / rc
<re_irc>
<@dirbaio:matrix.org> we have to decide what happens with the serial traits
<re_irc>
<@thejpster:matrix.org> Wait, what? I feel like we spent years talking about these traits.
<re_irc>
<@dirbaio:matrix.org> yeah, lots of talking, but no decisions
<re_irc>
<@eldruin:matrix.org> the PR was retracted, right?
<re_irc>
<@eldruin:matrix.org> it was about adding traits
<re_irc>
<@eldruin:matrix.org> or do you mean removing serial::Write as well?
<re_irc>
<@dirbaio:matrix.org> that was the "buffered vs unbuffered" one
<re_irc>
<@dirbaio:matrix.org> the conclusion was we don't want two sets of traits because
<re_irc>
1. too confusing
<re_irc>
2. the vast majority of the drivers need buffered
<re_irc>
<@dirbaio:matrix.org> but then stuff stalled
<re_irc>
<@dirbaio:matrix.org> there was no decision on what to do next
<re_irc>
<@dirbaio:matrix.org> add traits for Read? remove the existing Write trait, adopt embedded-io?
<re_irc>
<@dirbaio:matrix.org> there were also concerns about blocking read
<re_irc>
<@eldruin:matrix.org> in principle, I would tend to having some serial traits inside e-h, just like the other protocols
<re_irc>
<@thejpster:matrix.org> Ok, we’ll I guess we need tickets for these and we can do the work in GitHub and look again at a 1.0 beta once they are resolved.
<re_irc>
<@dirbaio:matrix.org> well all the stuff has been discussed a lot already...
<re_irc>
<@dirbaio:matrix.org> pros and cons have been laid out
<re_irc>
<@dirbaio:matrix.org> like
<re_irc>
<@dirbaio:matrix.org> imo the next step is to lay out the options and then decide
<re_irc>
<@adamgreig:matrix.org> in summary: we decided having only buffered traits makes sense, but haven't changed anything about the current serial::write to document this; we could just use embedded-io traits directly for serial since they match perfectly except for just "aren't literally in embedded-hal", and we didn't work out what to do about a non-blocking version?
<re_irc>
<@adamgreig:matrix.org> (and an adjacent question of whether embedded-io should therefore move to the wg/hal team too)
<re_irc>
<@dirbaio:matrix.org> re nb I think the consensus was to leave the nb traits as-is. the byte-by-byte model is consistent with the rest of e-h-nb
<re_irc>
<@dirbaio:matrix.org> the concern was more like "blocking read is not useful in practice"
<re_irc>
<@adamgreig:matrix.org> right, I think that was what I meant by non-blocking, rather than the stuff in e-h-nb
<re_irc>
<@adamgreig:matrix.org> i.e. should e-h::serial::read return immediately if the buffer is emtpy
<re_irc>
<@adamgreig:matrix.org> since otherwise it is basically useless
<re_irc>
<@dirbaio:matrix.org> yeah, so whether to make the "embedded_hal::serial::Read" trait (which would traditionally be blocking) blocking or nonblocking
<re_irc>
<@dirbaio:matrix.org> it's not useless, you can use it if you set a timeout on the underlying serial port
<re_irc>
<@dirbaio:matrix.org> just like you'd do on blocking std
<re_irc>
<@adamgreig:matrix.org> the embedded-io trait is ambiguous iirc, implementations could choose to have it return immediately on an empty buffer and users have to handle that, but probably most implementations wouldn't
<re_irc>
<@thejpster:matrix.org> blocking until what though? the buffer is full? a newline is seen?
<re_irc>
<@adamgreig:matrix.org> until there's enough data to satisfy the read size
<re_irc>
<@adamgreig:matrix.org> or any data, maybe, depends on the implementation
<re_irc>
<@thejpster:matrix.org> I have previously found it's almost impossible to know how much is coming.
<re_irc>
<@adamgreig:matrix.org> yea, that's why it seems unhelpful to have it block, basically
<re_irc>
<@dirbaio:matrix.org> : my intention was to mandate the existing Read trait MUST be blocking (and perhaps add another nonblocking trait)
<re_irc>
<@dirbaio:matrix.org> like, NOT do what "std::io::Read" does, which is "it might be blocking, it might not, depending on whether you've set O_NONBLOCK", which sucks
<re_irc>
<@adamgreig:matrix.org> block until EOF/enough data for the read, so only returns less than read size if no more data could possibly arrive?
<re_irc>
<@thejpster:matrix.org> rather than do all this in sync chat, we can do it in issues and PRs? An issue to describe what the problem is and a PR to propose a fix.
<re_irc>
<@dirbaio:matrix.org> : PRs already have been made and rejected
<re_irc>
<@dirbaio:matrix.org> this is why we want to discuss here to reach consensus to _then_ make a PR that fits that consensus
<re_irc>
<@thejpster:matrix.org> Well, I'm still not sure I understand the problem well enough based on what was said above.
<re_irc>
<@dirbaio:matrix.org> it's been discussed in many past meetings too
<re_irc>
<@therealprof:matrix.org> I don't see blocking as a problem as long as there's a way to check whether there's data in the buffer. The alternative would be something like <cough> "nb".
<re_irc>
<@dirbaio:matrix.org> I think all the possible options we have are:
<re_irc>
<@adamgreig:matrix.org> yea, the question for write is "does it remain or do we replace it with embedded-io", I think independently of exactly what happens to read
<re_irc>
<@dirbaio:matrix.org> imo if we decide to not have "Read" and adopt "embedded-io" instead, we shouldn't have "Write".
<re_irc>
<@adamgreig:matrix.org> but it does make sense to try and have read and write next to each other, I think, weird to just have write alone
<re_irc>
<@dirbaio:matrix.org> it's super inconsistent
<re_irc>
<@dirbaio:matrix.org> "you're telling me I have to use embedded-io for reading... but embedded-io also has a write trait, so what should I use for writing? yours or embedded-io?"
<re_irc>
<@dirbaio:matrix.org> I think all the possible options we have are:
<re_irc>
- Add blocking "embedded_hal::serial::Read" trait -- downside, less useful
<re_irc>
<@thejpster:matrix.org> UARTs should be treated like any other byte pipe, and so I like the idea of using something like embedded-io as a no-std version of std::io::Read and std::io::Write.
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@thejpster:matrix.org> (whether we should have a HAL for setting the UART baud rate, data bits, parity bits and stop bits, is another matter for another day)
<re_irc>
<@therealprof:matrix.org> I think we should have both "Read" and "Write". However they would behave differently. For "Write" you pretty much always know how data you'll be sending so why not allow to send it all at once. For "Read" not knowing how much data to read is the norm rather than the exception so we should cater for that.
<re_irc>
<@dirbaio:matrix.org> writing can also block indefinitely if using RTS/CTS
<re_irc>
<@dirbaio:matrix.org> +and the other side is dead
<re_irc>
<@adamgreig:matrix.org> but it's not possible for the implementation to know that, whereas with read it does know what's in the buffer
<re_irc>
<@therealprof:matrix.org> : Well, we could also define that the impl has to fail if CTS is not asserted.
<re_irc>
<@thejpster:matrix.org> well, maybe. Or maybe the data all hits the transmit buffer and it's stuck in the buffer indefinitely, but the write call has returned.
<re_irc>
<@dirbaio:matrix.org> it's possible for the implementation to know whether the tx buffer is full
<re_irc>
<@dirbaio:matrix.org> this is consistent with how nonblocking io works on e.g. Linux
<re_irc>
<@adamgreig:matrix.org> sure, but I'd expect commonly a write call to include more data than the tx buffer can fit anyway?
<re_irc>
<@thejpster:matrix.org> It depends.
<re_irc>
<@adamgreig:matrix.org> I guess for async you probably _do_ maintain a separate write buffer, but for sync write it seems needless
<re_irc>
<@dirbaio:matrix.org> "read ready" means "I have some data ready for you in the rx buffer. if you call read() now, it's guaranteed not to block"
<re_irc>
"write ready" means "I have some free space in the tx buffer. if you call write() now, it's guaranteed not to block"
<re_irc>
<@adamgreig:matrix.org> well, depending on how much data you read/write
<re_irc>
<@therealprof:matrix.org> : For single bytes.
<re_irc>
<@dirbaio:matrix.org> this makes sense if "short writes" are allowed. ie if you write 100 bytes but the buffer only has space for 10, it returns Ok(10), so you have to retry sending the next 90 later
<re_irc>
<@thejpster:matrix.org> a UART TX buffer means you don't need ownership of the bytes being sent, and the caller can go away and do something else (like sleep) whilst the UART TXs the bytes very very slowly.
<re_irc>
<@dirbaio:matrix.org> and then there's ".write_all()" which does this loop for you
<re_irc>
<@therealprof:matrix.org> : Plus with DMA it's all moot anyway.
<re_irc>
<@adamgreig:matrix.org> : sure, but not for a blocking write() call, in that case you have ownership while it blocks anyway
<re_irc>
<@adamgreig:matrix.org> that's the distinction between blocking write and nonblocking/async write, which is a separate thing
<re_irc>
<@dirbaio:matrix.org> what I'm saying is not anything new, it's how unix io has worked since forever
<re_irc>
<@dirbaio:matrix.org> embedded-io is the same design as std::io
<re_irc>
<@eldruin:matrix.org> or should at least, so that we do not have things like EAGAIN and similar meaning something else every time
<re_irc>
<@dirbaio:matrix.org> I wouldn't worry much about serial-specific errorkinds..
<re_irc>
<@dirbaio:matrix.org> drivers never handle stuff like "parity error" in practice
<re_irc>
<@eldruin:matrix.org> I'm not sure that is true for all kinds of I/O, which is what this would be
<re_irc>
<@eldruin:matrix.org> but anyway, I need to leave.
<re_irc>
<@eldruin:matrix.org> It would be great to have a PR and we can discuss there in detail
<re_irc>
<@dirbaio:matrix.org> PR adding embedded-io to the embedded-hal repo?
<re_irc>
<@dirbaio:matrix.org> or I transfer the entire repo?
<re_irc>
<@dirbaio:matrix.org> perhaps adding embedded-io to the embedded-hal repo, "by parts"? so the parts can be reviewed
<re_irc>
<@dirbaio:matrix.org> and I do the "make it ready for 1.0" refactors as I go
<re_irc>
<@dirbaio:matrix.org> it'll have to be "embedded-io", "embedded-io-async"
<re_irc>
<@dirbaio:matrix.org> i'm fine with that, it makes it consistent with e-h
<re_irc>
<@eldruin:matrix.org> sounds good
<re_irc>
<@dirbaio:matrix.org> and doesn't need the ugly "asynch" :D
<re_irc>
<@dirbaio:matrix.org> cool
<re_irc>
<@dirbaio:matrix.org> will do
<re_irc>
<@dirbaio:matrix.org> 👷♂️🚧🏗️
<re_irc>
<@dirbaio:matrix.org> if we remove "Write" now, we can start the 1.0 rc
<re_irc>
<@dirbaio:matrix.org> +right away
<re_irc>
<@dirbaio:matrix.org> and add the io reexport later
<re_irc>
<@dirbaio:matrix.org> ?
<re_irc>
<@eldruin:matrix.org> let's leave a couple of days between breaking e-h releases
<re_irc>
<@dirbaio:matrix.org> and we're not closing any doors any doors by doing that. if embedded-io doesn't work out for whatever reason we can still add serial Write/Read later
dc740 has joined #rust-embedded
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
zagura has quit [Server closed connection]
zagura has joined #rust-embedded
<re_irc>
<@vollbrecht:matrix.org> Public Github repository's that are using embedded-hal in there Cargo.toml : 7200