<re_irc>
<@762spr:matrix.org> Hugo Lageneste: It sounds like you have established communication and gotten atleast one command working, so the I2C aspect should be working. My guess is the payload is malformed. Have you tried checking the formed payload to make sure it is correct?
crabbedhaloablut has joined #rust-embedded
<re_irc>
<@hugolgst:matrix.org> : Exactly, the wakeup call gets the proper response. I coded my PoC in Go and compared the payload, there are identical.
cosj[m] has quit [Quit: You have been kicked for being idle]
crabbedhaloablut has quit [Ping timeout: 255 seconds]
crabbedhaloablut has joined #rust-embedded
rardiol has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@9names:matrix.org> noxime has started a blog series about his experience getting rust going for the ch32v003. it's covers adding a new target to rust (rv32ec), using a custom llvm tree when building rust, and making a blinky program with that rustc:
<re_irc>
<@9names:matrix.org> i managed to get a toolchain and a blinky working by (loosely) following his guide. it's not prescriptive yet, but it's close enough to everything you need that with a bit of effort you can fill in the blanks
<re_irc>
<@adamgreig:matrix.org> how come the startup needs to zero all the registers?
<re_irc>
<@9names:matrix.org> it's a copy-paste from riscv-rt. i didn't even think about it, i just fixed the assembler errors and crossed my fingers.
<re_irc>
<@9names:matrix.org> i've been meaning to dig into riscv early boot and asm but it's not that high on my list yet...
rardiol has quit [Read error: Connection reset by peer]
rardiol has joined #rust-embedded
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
dc740 has joined #rust-embedded
<re_irc>
<@almindor:matrix.org> : Good question, I can't remember tbh :)
<re_irc>
<@jannic:matrix.org> Perhaps just to aid debugging, so you can easily see if the register has been used?
brazuca has joined #rust-embedded
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 252 seconds]
brazuca has quit [Ping timeout: 260 seconds]
rardiol has quit [Quit: No Ping reply in 180 seconds.]
rardiol has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> hi @room , meeting time again! agenda is https://hackmd.io/OfUnVXfxQhORdKMtHo8Emw, please add anything you'd like to announce or discuss and we'll start in 5 min or so
<re_irc>
<@adamgreig:matrix.org> we're having some rare nice weather in oxford for the first time in ages, i hope it's pleasant wherever you all are too!
<re_irc>
<@adamgreig:matrix.org> it helps that it's finally summer time again I guess!
<cr1901>
spring?
<re_irc>
<@almindor:matrix.org> we had some light snow yesterday
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> ok, let's start!
<re_irc>
<@adamgreig:matrix.org> first off, as I mentioned a couple weeks back I won't be able to run meetings for the next three weeks (until the 2nd May)
<re_irc>
<@adamgreig:matrix.org> if anyone's interested in running one or some of them please shout
<re_irc>
<@adamgreig:matrix.org> or otherwise you'll have to manage without meetings for a few weeks :P
<re_irc>
<@eldruin:matrix.org> what brings me to: I will not be there for the next two meetings :)
<re_irc>
<@adamgreig:matrix.org> , do you wanna mention defmt-brtt?
<re_irc>
<@datdenkikniet:matrix.org> Yes :) Me and have cooked up "defmt-brtt". It's "defmt-rtt" and "defmt-bbq" in one crate, so you can do "defmt" logging over both "rtt" and/or using the "bbqueue" mechanism!
<re_irc>
<@datdenkikniet:matrix.org> it's not quite finished yet (pending review :tm:), but I figured we should put word out rather sooner than later
<re_irc>
<@datdenkikniet:matrix.org> it is, of course, based on the amazing work by and the people that made "defmt-rtt"
<re_irc>
<@jamesmunns:beeper.com> Don't credit defmt to me!
<re_irc>
<@datdenkikniet:matrix.org> but it is neat, because it allows for almost-debuggerless debugging while still being able to use "defmt" (by shipping logs over USB), while maintaining easy availability of defmt over RTT
<re_irc>
<@jamesmunns:beeper.com> Oh, just read the context, I'll take credit for defmt bbq 😅
<re_irc>
<@datdenkikniet:matrix.org> : Hahahaha nono, but you made "defmt-bbq" right?
<re_irc>
<@adamgreig:matrix.org> is that part of how the logs-over-usb for rs-probe works?
<re_irc>
<@eldruin:matrix.org> props for the name :)
<re_irc>
<@adamgreig:matrix.org> so, quick mention about some recent svd/svd2rust/svdtools work that's been flying by, it turns out arm's tools have secret extra requirements on svds that aren't part of the spec/schema, so there's been some recent PRs to try and make what we generate a bit more compatible with other svd tooling
<re_irc>
<@adamgreig:matrix.org> in particular things like "can't generate a derivedFrom that refers to something that is later on in the file"
<re_irc>
<@adamgreig:matrix.org> ok, the remaining points are a couple of e-h things it would be nice to see if we can get some agreement on before we all forget about it in may lol
<re_irc>
<@adamgreig:matrix.org> soooooo
<re_irc>
<@adamgreig:matrix.org> let's start with the SPI one because I think we were pretty close to resolved on that last week
<cr1901>
msp430 is unaffected :D: 1. the svd files I generate mildly violate the XML spec anyway (svd2rust handles it just fine), and there's no existing svd tooling :D
<re_irc>
<@adamgreig:matrix.org> which got merged 🎉
<re_irc>
<@almindor:matrix.org> well that makes this short :D
<re_irc>
<@adamgreig:matrix.org> so the conclusion in the end was "maybe the closure model can come back alongside it later on, if we find it's needed, but the baseline support should be through the new slice approach"
<re_irc>
<@adamgreig:matrix.org> well that gives us more time for the second item, the serial traits
<re_irc>
<@dirbaio:matrix.org> the spicy serial traits
<re_irc>
<@eldruin:matrix.org> please feel free to contest the decision if you feel like it
<re_irc>
<@adamgreig:matrix.org> no I think that's where we got to last week, I hoped we'd just merge it now but totally missed the merge happening during the week
<re_irc>
<@dirbaio:matrix.org> if we go with the slice-based transaction API, I don't think we want a closure one
<re_irc>
<@dirbaio:matrix.org> there's very few use cases that require the closure, plus those wouldn't be implementable on linux and esp-idf
<re_irc>
<@adamgreig:matrix.org> let's fight about that when someone proposes adding it for 1.1
<re_irc>
<@dirbaio:matrix.org> I think drivers that need those would be better off with SpiBus + OutputPin (handling CS manually). This does mean they give up on bus sharing, but at least they'll be usable everywhere...
<re_irc>
<@adamgreig:matrix.org> : except that SpiBus might not be available on linux?
<re_irc>
<@dirbaio:matrix.org> why wouldn't it be?
<re_irc>
<@dirbaio:matrix.org> there's some ioctl to tell it to not toggle any CS, isn't it?
<re_irc>
<@eldruin:matrix.org> sorry, let's do serial :P
<re_irc>
<@dirbaio:matrix.org> yeah
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@dirbaio:matrix.org> about serial: seeing the discussions in the last 2 meetings, and the confusion it has caused
<re_irc>
<@dirbaio:matrix.org> I'm started to think it'd be better to not have traits for "raw" UART at all
<re_irc>
<@adamgreig:matrix.org> I think one of the questions last time is whether embedded-io's read() would be expected to always block until something is available, or never block and always return right away (maybe returning 0), or implementation-defined
<re_irc>
<@almindor:matrix.org> let's leave raw UART to the PAC essentially?
<re_irc>
<@adamgreig:matrix.org> to the HAL?
<re_irc>
<@adamgreig:matrix.org> I think pretty much any driver talking serial should be able to work with a buffered interface through the embedded-io style traits, but it might be kind of annoying to use without something a bit like ReadUntilIdle?
<re_irc>
<@dirbaio:matrix.org> because most drivers need the buffered uart, the amount of cases where you can use the raw (unbuffered) uart is very small
<re_irc>
<@adamgreig:matrix.org> are there any compelling cases where you _need_ the raw uart?
<re_irc>
<@dirbaio:matrix.org> and having two traits for uart, with such a subtle distinction, is a recipe for mass confusion...
<re_irc>
<@jamesmunns:beeper.com> : I haven't heard you talk about this before, but this actually sounds like a really interesting idea
<re_irc>
<@dirbaio:matrix.org> HALs can still have a raw UART driver, yes, but it wouldn't implement any e-h trait
<re_irc>
<@jamesmunns:beeper.com> (like, there's usually a billion ways to use every peripheral, but USUALLY only 2-3 common ones)
<re_irc>
<@dirbaio:matrix.org> : no... it's mostly to save RAM by skipping the intermediate buffer
<cr1901>
I can envision simple FPGA RISCV designs w/ an unbuffered UART peripheral
<re_irc>
<@adamgreig:matrix.org> but if the HAL lets the user specify a buffer size, or offers a small buffer or whatever...
<re_irc>
<@adamgreig:matrix.org> not having a UART trait in the embedded-hal crate feels kind of weird, though
<re_irc>
<@adamgreig:matrix.org> cr1901: yea, we expect most hardware to be essentially unbuffered (well - I'd always expect like a one-word buffer)
<re_irc>
<@adamgreig:matrix.org> but the HAL can provide a buffered interface on top, by using interrupts/dma/whatever to read data into a buffer and the driver consumes it from that buffer
<re_irc>
<@grantm11235:matrix.org> And bitbanged impls can be fully bufferless
<cr1901>
ahhh, that type of buffer
<re_irc>
<@adamgreig:matrix.org> but I wonder if we can provide a more featureful interface than embedded_io::blocking::Read, like "how many bytes are available to be read" or "read what's available and return, don't block"
<re_irc>
<@jamesmunns:beeper.com> (off topic, where's maybe a good place to ping y'all about brtt? probe-rs room? rtic room? here after the meeting?)
<re_irc>
<@jamesmunns:beeper.com> : introducing the stty trait! /s
<re_irc>
<@dirbaio:matrix.org> : embedded-io has focused on blocking+async so far, there could also be a nonblocking non-async API. I think that's orthogonal to this discussion though
<re_irc>
<@adamgreig:matrix.org> and I'm not really sure how BufRead fits in, is it then buffered twice?
<re_irc>
<@jamesmunns:beeper.com> (off topic, where's maybe a good place to ping y'all about brtt? probe-rs room? rtic room? here after the meeting? edit: to )
<re_irc>
<@dirbaio:matrix.org> : BufRead is the capability of returning borrowed slices from the internal buffer
<re_irc>
<@adamgreig:matrix.org> : the blocking API says "it does what std does", and std says "it does whatever the hell it wants"
<re_irc>
<@adamgreig:matrix.org> so is it a blocking api or a sort-of-blocking api or...
<re_irc>
<@dirbaio:matrix.org> yeah, true, lol
<re_irc>
<@adamgreig:matrix.org> when I'm writing uart drivers I often want to like "get whatever you've received and return right away", which might be an empty slice/0 bytes, or some bytes, whatever
<re_irc>
<@adamgreig:matrix.org> other times you might well want to say "just block until you've filled this buffer"
<re_irc>
<@dirbaio:matrix.org> IIUC, it is required that if some bytes have been received, "read()" returns these immediately instead of blocking waiting for more
<re_irc>
<@adamgreig:matrix.org> I think in principle having a single trait is good, and it could well be embedded_io and we just point at it from e-h (maybe move e-io into the hal team?)
<re_irc>
<@datdenkikniet:matrix.org> : That's a good question :P I think this room makes the most sense
<re_irc>
<@datdenkikniet:matrix.org> but we probably don't want to mess up the meeting and I'm not sure if there's another relevant channel
<re_irc>
<@dirbaio:matrix.org> it only blocks if no bytes have been received at all
<re_irc>
<@adamgreig:matrix.org> : that would be something but it just says "This function does not provide any guarantees about whether it blocks waiting for data"
<re_irc>
<@datdenkikniet:matrix.org> +(assuming you want to chat about it right now)
<re_irc>
<@dirbaio:matrix.org> uh
<re_irc>
<@adamgreig:matrix.org> if it's always going to block if there's no data, then an available() or similar method might be nice
<re_irc>
<@dirbaio:matrix.org> i think that's referring to O_NONBLOCK
<re_irc>
<@dirbaio:matrix.org> like
<re_irc>
<@dirbaio:matrix.org> if no data has been received, it can either block or not
<cr1901>
Isn't there _already_ a nonblocking Uart trait for Read?
<re_irc>
<@dirbaio:matrix.org> but if some data HAS been received, it doesn't block
<cr1901>
in the embedded-hal-nb crate
<re_irc>
<@adamgreig:matrix.org> well, could we say that instead of saying "it's like std"?
<re_irc>
<@dirbaio:matrix.org> cr1901: yes. the discussion originally started when adding uart async Read, and then expanded to both blocking+async because so far all the async traits are identical to the blocking ones but with "async" added.
<re_irc>
<@eldruin:matrix.org> : I think we should specify which one it is or offer two different methods. It sounds like something that a driver needs to know
<re_irc>
<@dirbaio:matrix.org> : yes, I agree. I was explaining what "std::io" specifies, not "embedded-io"
<re_irc>
<@adamgreig:matrix.org> and if so, does it still make sense to just use e_io::Read or should it stay a e_h::uart trait?
<re_irc>
<@dirbaio:matrix.org> though there's a high "cost" of "embedded-io" diverging from "std::io"
<re_irc>
<@adamgreig:matrix.org> std says it can return a 0-length immediately, e.g. at EOF, which doesn't necessarily mean future calls won't return more data, like if the file gets written to later.. lol
brazuca has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> which arguably is like "the uart rx buffer is empty right now, returns 0, but might return some data later if more comes in"?
<re_irc>
<@dirbaio:matrix.org> because there's adapters both ways
<re_irc>
<@dirbaio:matrix.org> traditionally read returning 0 means EOF, not "no data"
<re_irc>
<@dirbaio:matrix.org> "no data" is returning EAGAIN
<re_irc>
<@adamgreig:matrix.org> right, depending on whether the underlying handle/socket is NONBLOCK too?
<re_irc>
<@dirbaio:matrix.org> if "embedded-io" diverges from "std::io", it creates a giant mess in the adapters
<re_irc>
<@dirbaio:matrix.org> and a giant mess when porting code
<re_irc>
<@adamgreig:matrix.org> fair
<re_irc>
<@adamgreig:matrix.org> so e-io wants to keep saying "it's the same semantics as std", is that still ok for a uart?
<re_irc>
<@eldruin:matrix.org> but then we need a way to specify whether we want to work NONBLOCK or not
<re_irc>
<@dirbaio:matrix.org> I think e-io could tighten down a bit the "is it nonblocking?" part
<re_irc>
<@adamgreig:matrix.org> (on linux I think it's normal to use the std::io::Read to access uarts, right?)
<re_irc>
<@grantm11235:matrix.org> : Wouldn't that make a std to e-io adapter invalid?
<re_irc>
<@adamgreig:matrix.org> but it has set_timeout() methods that configure whether it's going to be blocking or not
<re_irc>
<@dirbaio:matrix.org> like, you could do "where R: embedded_io::Read + embedded_io::Blocking", or "where R: embedded_io::Read + embedded_io::NonBlocking"
<re_irc>
<@dirbaio:matrix.org> idk
<cr1901>
> Wouldn't that make a std to e-io adapter invalid? <-- why?
<re_irc>
<@dirbaio:matrix.org> : and the adapters would have some warning in "new" like "make sure the underlying fd is in the right blocking/nonblocking mode"
<re_irc>
<@adamgreig:matrix.org> or do we end up with a Uart trait in e-h that requires e_io::Read and e_io::Write, but has some way to indicate blocking/nb/other methods like available()
<re_irc>
<@adamgreig:matrix.org> but I dunno what the point of that is really. that's for HALs to do.
<re_irc>
<@dirbaio:matrix.org> I think it's good that serial uses the plain io traits, no extra trait
<re_irc>
<@adamgreig:matrix.org> or we leave it vague and say "well read() might block until _some_ data is available, _probably_ won't block until the whole buffer is full but could, and might return with no data if it wants, handle those cases"
<re_irc>
<@dirbaio:matrix.org> it makes it easy to run some terminal CLI over either hardware serial or telnet, for example
<re_irc>
<@adamgreig:matrix.org> but if you're a driver and you want to check "is there any data available to process", you basically can't?
<re_irc>
<@dirbaio:matrix.org> and adapt a std serial to e-io and have it just work, without jumping through hoops like "implement the ThisIsASerialReally marker trait"
<re_irc>
<@adamgreig:matrix.org> I don't think that's OK for the e-h blocking AIP
<re_irc>
<@adamgreig:matrix.org> * API
<re_irc>
<@dirbaio:matrix.org> (jk)
* cr1901
couldn't tell it was a joke :P
<re_irc>
<@vollbrecht:matrix.org> sorry for the late suggestion, but i have some idea about the mentioned problems regarding the spi Closure cases that are not currently implementable by the slice API. The core problem for the Closure api was the CS problem. I would suggest maybe add an Operation::Clousure( ...) When we expose a closure with an Operation than we still can do more funky stuff and still only uses one transaction api. So inside the closure...
<re_irc>
... you can wait for other stuff . But because we got an Operation::Clousure the transaction knows it still needs to assert the cs line over the chained operations
<re_irc>
<@dirbaio:matrix.org> I do sortof think "nonblocking but not async" io is a bit of an antipattern, it forces you to poll in a hot loop wasting CPU and energy
<re_irc>
<@adamgreig:matrix.org> it doesn't need to be a hot loop, because it's buffered
<re_irc>
<@adamgreig:matrix.org> you could even be sleeping for a second, wake up and quickly check the buffer (which has been dma'd/interrupt'd), do some processing if anything's there, back to sleep
<re_irc>
<@dirbaio:matrix.org> even if it's buffered, you usually want to process data when it's received ASAP
<re_irc>
<@adamgreig:matrix.org> in any event it's certainly a common pattern and I think people would reasonably expect to be able to do it?
<re_irc>
<@dirbaio:matrix.org> polling every 1 second adds unneceessary latency
<re_irc>
<@dirbaio:matrix.org> : yes, agreed
<re_irc>
<@adamgreig:matrix.org> replace "1 second" with whatever latency's acceptable for your problem, but same point I think
<re_irc>
<@dirbaio:matrix.org> though it's reasonable for the _blocking_ traits to block
<re_irc>
<@adamgreig:matrix.org> I think it's fine for them to block, just you need to also ask "are you going to block" in that case?
<re_irc>
<@dirbaio:matrix.org> IMO 😅
<re_irc>
<@adamgreig:matrix.org> +be able to
<re_irc>
<@adamgreig:matrix.org> otherwise we're right back at "nb" :P
<re_irc>
<@adamgreig:matrix.org> but for a "buffered uart", it seems very natural to want to know "how much is in the buffer?"
<re_irc>
<@dirbaio:matrix.org> "nonblocking will_you_block() + blocking read()" is the same as "nonblocking read()" anyway
<re_irc>
<@eldruin:matrix.org> vollbrecht: The problem is that something like that is not implementable for linux for example. That is why we settled for slices, which work everywhere. If you have real-world use cases, please feel free to open a new issue in the embedded-hal repo and we can discuss it there.
<re_irc>
<@dirbaio:matrix.org> plus on "std::io" you can't do "will_you_block()", you have to actually try to read
<re_irc>
<@adamgreig:matrix.org> sure, nonblocking read would serve the same purpose
<re_irc>
<@adamgreig:matrix.org> : yea, but if it's a serial port you can tell it "set timeout to 0s" or "set timeout to 0.1s" before calling read
<re_irc>
<@adamgreig:matrix.org> do we just say "well HALs should probably expose some sort of timeout option, users set it before handing the eio::read trait object over to the driver"?
<re_irc>
<@adamgreig:matrix.org> yea, it sounds awful for HALs :P
<re_irc>
<@dirbaio:matrix.org> timeouts below the IO layer are cursed
<re_irc>
<@adamgreig:matrix.org> and timeouts aren't necessarily the most natural way
<re_irc>
<@adamgreig:matrix.org> maybe the driver wants to be able to say "i don't care until 16 bytes are available, then write it into this slice for me"
<re_irc>
<@adamgreig:matrix.org> it doesn't want to hold on to data in-between because now it needs its own long-lived buffer, so just saying read() with a 16-byte buffer is annoynig if it comes back half-empty
<re_irc>
<@adamgreig:matrix.org> and it doesn't want to block forever if there's no data
<re_irc>
<@adamgreig:matrix.org> so ideally it says "if available() >= 16: read(&mut my_16_byte_buffer[..])" or so
<re_irc>
<@dirbaio:matrix.org> you can't easily impl "available()" on linux
<re_irc>
<@vollbrecht:matrix.org> : No i have not a real example that's just what i thought about the points presented inside the discussion thread on that point and how it might be solvable. The idea behind it have something that can be between transaction but are not real transactions . I didn't need it to implement it on esp-idf though so far
<re_irc>
<@adamgreig:matrix.org> well, you can, you just read it into your own buffer :P
<re_irc>
<@eldruin:matrix.org> the half-empty buffer problem could still be work-arounded but I see more of a problem in "are you going to block forever if communication broke down or whatever"
<re_irc>
<@grantm11235:matrix.org> : What if the HAL's buffer is less than 16 bytes?
<re_irc>
<@adamgreig:matrix.org> it's not allowed to be, it has to be "big enough"
<re_irc>
<@adamgreig:matrix.org> (is the concept of these buffered interface, that the driver doesn't need to read 'quick'y' or worry unduly about the buffer filling up)
<re_irc>
<@grantm11235:matrix.org> I don't think everyone will be able to agree on what is "big enough"
<re_irc>
<@eldruin:matrix.org> the hal could provide a method where you pass in a buffer, for example
<cr1901>
Use const generics to be generic over all buffer sizes :P
<re_irc>
<@adamgreig:matrix.org> yea, I think ideally the HALs would either use alloc or let the user specify how big a buffer they want (and pass it in), and the user ensures it's big enough for whatever the driver needs
<re_irc>
<@adamgreig:matrix.org> but ideally the driver doesn't then need to have a second internal buffer it reads into until it has enough data to process, imo
<re_irc>
<@dirbaio:matrix.org> can we take a step back? we're stuck bikeshedding how the buffered-serial traits would look, but I think there's 2 decisions we should make before that:
<re_irc>
1. do we want traits for unbuffered + buffered? Or just buffered?
<re_irc>
2. for buffered traits, are we OK with using some generic io traits (like "embedded-io" or something else) or do we want uart-specific traits in "embedded-hal"?
<re_irc>
<@dirbaio:matrix.org> for "1" my opinion is "just buffered". If we agree on this, I'll go ahead and close the PR, since those are for unbuffered.
<re_irc>
<@eldruin:matrix.org> if they would be additional traits, we have the option to add them in 1.1
<cr1901>
Unbuffered can be discussed later if necessary.
<re_irc>
<@grantm11235:matrix.org> Don't you need unbuffered if you are trying to detect idle?
<re_irc>
<@dirbaio:matrix.org> yeah, this is just for EH1.0
<re_irc>
<@adamgreig:matrix.org> my feeling is "just buffered" should be OK, but I'm not yet sure that embedded-io alone is enough for it
<re_irc>
<@adamgreig:matrix.org> so it might still be an e-h 1.0 trait
<cr1901>
Anyways, I don't have strong feelings over 1 trait vs 2
<re_irc>
<@adamgreig:matrix.org> your points about the weakness of unbuffered uart traits are pretty valid I think, the use cases are niche, it's prone to confusion, it makes drivers difficult
<re_irc>
<@adamgreig:matrix.org> not unreasonable to maybe add to e-h later but it shouldn't be the first thing people reach to for a uart
<re_irc>
<@dirbaio:matrix.org> I think all drivers that can use unbuffered uart can be written easier with buffered uart. The only downside is a bit more RAM usage and code size
<re_irc>
<@adamgreig:matrix.org> but if the drivers can use the hal's buffer and not have to double buffer it, hopefully there isn't really much extra ram usage
<re_irc>
<@adamgreig:matrix.org> the problem is if the driver has to read from the hal buffer into its own buffer to assemble a message... though even then I guess you could aim for a small hal buffer or something
<cr1901>
code size increase _sounds_ negligible
<re_irc>
<@adamgreig:matrix.org> anyway, yea, I agree
<re_irc>
<@adamgreig:matrix.org> (it does remove the ability to detect idle from the generic traits, but that's hopefully expected to be more niche?)
<re_irc>
<@dirbaio:matrix.org> yeah, with ReadBuf you can. Embassy has had trouble implementing ReadBuf due to the classic DMA unsoundness issues, but it's not something fundamentally undoable
<re_irc>
<@dirbaio:matrix.org> with ReadBuf you can use the HAL's buffer*
<re_irc>
<@adamgreig:matrix.org> or with some other buffered design, maybe like read() + available()
<re_irc>
<@adamgreig:matrix.org> or like read_block_until_you_fill_my_buffer() and read_dont_block_at_all()
<re_irc>
<@grantm11235:matrix.org> Is there any way for the driver to specify the size of the buffer?
<cr1901>
wouldn't that be part of the slice passed in?
<re_irc>
<@adamgreig:matrix.org> (having it be directly e-io::Read and compatible with std::Read definitely has a bunch of advantages in terms of portability though, I take that point)
<re_irc>
<@dirbaio:matrix.org> okay, do we agree to not have unbuffered traits on 1.0? shall I close the PR?
<re_irc>
<@eldruin:matrix.org> I think in practice drivers will need to fill a second buffer iteratively themselves because you can never really be sure what your HAL will offer
<re_irc>
<@eldruin:matrix.org> like, if somebody uses your driver with bitbang-hal, you need to fill up word by word
<re_irc>
<@eldruin:matrix.org> (or does not work at all because bitbang-hal is too slow and misses the data, lol)
<re_irc>
<@adamgreig:matrix.org> bitbang-hal would have to provide a buffer in this scenario, and ideally one the user can size when they set it up
<re_irc>
<@adamgreig:matrix.org> so if the driver says "btw i need the hal to have at least a 32 byte buffer" then the user sets that on bitbang-hal?
<re_irc>
<@dirbaio:matrix.org> to support buffered, bitbang-hal would have to setup a timer interrupt and do the RXing there, so it's still receiving while the user is not actively waiting in a "read()" call
<cr1901>
And the HAL doesn't support interrupts directly, so it's not portable :(
<re_irc>
<@grantm11235:matrix.org> Yeah a bitbanged impl would need to be an ISR in order to implement a buffered uart
<re_irc>
<@eldruin:matrix.org> : that would be a more elaborate impl, yes
<re_irc>
<@dirbaio:matrix.org> buffered uart explicitly requires bytes to not be lost even if you're not actively waiting on "read()"
<re_irc>
<@eldruin:matrix.org> IIUC, read will return a number of bytes up to the size of my input buffer, right? if it can return any smaller number than the full slice, I need to do the fill up in the driver
<re_irc>
<@dirbaio:matrix.org> if it did the bitbangy things synchronously on "read()", it could impl only unbuffered, not buffered traits
<re_irc>
<@adamgreig:matrix.org> : yea, I'm imagining if you had available() and it returns N, then a subsequent read() will always return at least N
<re_irc>
<@eldruin:matrix.org> because I do not know how fast I will be actually polling and thus cannot know how much data I will get
<re_irc>
<@adamgreig:matrix.org> (and if you read into a slice that's N long, you can't get more than N either)
<re_irc>
<@eldruin:matrix.org> : ah ok, I missed that. that clarifies
<re_irc>
<@eldruin:matrix.org> then it is only a documentation issue and the user and hal have to see how to set up a big enough buffer. I agree
<re_irc>
<@adamgreig:matrix.org> so you can wait until the hal buffer has all the data you want, and then read and use it, without having to hold onto some of it in between calls
<re_irc>
<@eldruin:matrix.org> sounds wonderful
<re_irc>
<@adamgreig:matrix.org> if you do need to read the first byte or two to work out how much data you need in total it's a bit messier, but maybe you hold onto just those few bytes. or the API allows peeking, and now it's sort of BufRead, heh
<re_irc>
<@adamgreig:matrix.org> I dunno. that sounds nice but so does compatibility with std and just having drivers do their own buffering
<re_irc>
<@dirbaio:matrix.org> you can't impl "available()" on linux, there's no syscall for it
<re_irc>
<@adamgreig:matrix.org> yea, linux-embedded-hal would have to read from the os into its own buffer (at least it has alloc) and then tell you how big that buffer is
<re_irc>
<@dirbaio:matrix.org> you'd have to buffer in userspace and spawn _a background thread_ to fill it because "read()" is blocking
<re_irc>
<@adamgreig:matrix.org> but that's pretty easily done
<re_irc>
<@dirbaio:matrix.org> or do horrible things with "select/poll/epoll"
<re_irc>
<@adamgreig:matrix.org> linux-embedded-hal can just set the serial port to nonblocking
<re_irc>
<@adamgreig:matrix.org> then read() always returns right away, maybe with 0 data?
<re_irc>
<@dirbaio:matrix.org> ah, so read the data when the user calls "available()"
<re_irc>
<@dirbaio:matrix.org> ?
<re_irc>
<@adamgreig:matrix.org> you could do, pretty easily, I think?
<re_irc>
<@adamgreig:matrix.org> and also when they call read()
<re_irc>
<@dirbaio:matrix.org> dunno
<re_irc>
<@dirbaio:matrix.org> seems a lot of trouble, for little benefit
<re_irc>
<@dirbaio:matrix.org> in practice you'll still need to copy to your own buffer
<re_irc>
<@adamgreig:matrix.org> the benefit is "don't have to double buffer everything you read"
<re_irc>
<@adamgreig:matrix.org> hmm
<re_irc>
<@dirbaio:matrix.org> because "read_buf()" is not guaranteed to return all the "available()" bytes, they might not be contiguous
<re_irc>
<@adamgreig:matrix.org> yea, but that can at least be some transient stack-allocated thing for the duration of this function call
<re_irc>
<@adamgreig:matrix.org> hm, that's true and annoying
<re_irc>
<@dirbaio:matrix.org> : yeah, that's the only advantage
brazuca has quit [Quit: Client closed]
<re_irc>
<@adamgreig:matrix.org> so if drivers do have to buffer everything themselves between calls, the main remaining point is about whether it's possible for them to tell if a call to read() will block indefinitely before doing so
brazuca has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> maybe we can specify "blocking::* traits always block" and introduce a _third_ set of traits instead?
<re_irc>
<@adamgreig:matrix.org> if std could guarnatee it will block until _some_ data is available or otherwise it's something like EOF then maybe?
<re_irc>
<@dirbaio:matrix.org> an UART would never have an EOF
<re_irc>
<@adamgreig:matrix.org> kinda a cool way to signal idle though 👀
<re_irc>
<@adamgreig:matrix.org> (not really... I don't think)
<re_irc>
<@dirbaio:matrix.org> : in std, EOF is always returned as Ok(0) and WouldBlock as Err(EAGAIN)
<re_irc>
<@eldruin:matrix.org> I'm having trouble understanding EOF for uart. can't you always just receive more data?
<re_irc>
<@dirbaio:matrix.org> so that's fine
<re_irc>
<@dirbaio:matrix.org> yeah, uart would have no EOF
<re_irc>
<@adamgreig:matrix.org> in files someone might write to it and what was EOF can stop being EOF, too
<re_irc>
<@dirbaio:matrix.org> but this is embedded-io, the byte stream could be something other than a UART
<re_irc>
<@dirbaio:matrix.org> like a unix pipe, a TCP socket, a file
<re_irc>
<@dirbaio:matrix.org> these can be EOF'd
<re_irc>
<@eldruin:matrix.org> yeah but let's focus on the serial use case
<re_irc>
<@adamgreig:matrix.org> I guess on std people either set timeouts or use threads to get around the blocking forever thing
<re_irc>
<@dirbaio:matrix.org> on std people just use tokio :P
<re_irc>
<@adamgreig:matrix.org> maybe, I've done some amount of serial and socket stuff on std without tokio
<re_irc>
<@adamgreig:matrix.org> I have to run for a bit and we're out of time for the meeting, if agrees I think you could close the PR for the unbuffered traits
<re_irc>
<@adamgreig:matrix.org> so far I feel like maybe e-io could be used for uart but ideally hals have an option to make it blocking/nonblocking (would return Ok(0)) and drivers might say "if your hal is blocking then the driver will be too" but otherwise handle Ok(0) as "no data currently available"? which sort of maps to reading a file and getting eof... and should still work OK with a std stream?
<re_irc>
<@adamgreig:matrix.org> what does read return on a closed tcp stream? Err eventually?
<re_irc>
<@adamgreig:matrix.org> which feels like a closer match to the "serial" crate for std
<re_irc>
<@adamgreig:matrix.org> I still dunno if that's quite good enough for drivers that might break if they do block forever at a time when no more data is going to come until they send something, though
<re_irc>
<@dirbaio:matrix.org> : EOF (if it was closed properly with FIN)
<re_irc>
<@dirbaio:matrix.org> so the way I see it is, we can either
<re_irc>
<@dirbaio:matrix.org> 1- have separate blocking, nonblocking traits, or
<re_irc>
2- have a single set of traits, where the behavior depends on the "mode" of the underlying stream
<re_irc>
<@dirbaio:matrix.org> so drivers have to say "please give me a nonblocking uart", but have no way to enforce it at compile time
<re_irc>
<@dirbaio:matrix.org> which is the status quo with "std::io"
<re_irc>
<@dirbaio:matrix.org> with "2", so drivers have to say "please give me a nonblocking uart", but have no way to enforce it at compile time
<re_irc>
<@dirbaio:matrix.org> with "1" the driver can enforce the behavior at compile time, but the adapters are less clean, they'll need some warning like "it's on you to ensure the "std" stream is in the right mode"
<re_irc>
<@eldruin:matrix.org> : could you add that summary somewhere?
<re_irc>
<@dirbaio:matrix.org> where? this is not "embedded-hal" anymore
<re_irc>
<@eldruin:matrix.org> hmm don't know, just thought it was valuable
<re_irc>
<@grantm11235:matrix.org> : To circle back to this, I just wanted to point out that this doesn't work on linux spidev for the same reason that the closure traits don't work: there is no way to hold exclusive access to a spi bus between syscalls
brazuca has quit [Quit: Client closed]
<re_irc>
<@dirbaio:matrix.org> the user would have to ensure only their program uses that bus, yes
<re_irc>
<@grantm11235:matrix.org> In that case, they can just as easily impl the closure traits
<re_irc>
<@grantm11235:matrix.org> They wouldn't even need to impl them, just make an ExclusiveDevice out of the SpiBus + OutputPin as usual
<re_irc>
<@dirbaio:matrix.org> the tradeoff is:
<re_irc>
1- Slice-based SpiDevice: implementable everywhere, with bus sharing support everywhere, but a bit less powerful
<re_irc>
2- Closure-based SpiDevice: a bit more powerful, but not implementable on Linux or esp-idf with kernel-based bus sharing. Also causes ugly lifetime issues with async.
<re_irc>
3- have two traits: slice and closure: Works on all use cases, but having 2 ways of doing the same thing is a big disadvantage in itself (confusion for driver writers, more work for HAL authors, compat problems if driver needs one and HAL impls the other)
<re_irc>
<@grantm11235:matrix.org> My point was that _if the closure traits exist_ there is no benefit to using SpiBus + OutputPin instead. It has the same compatibility limitations, and it also doesn't allow bus sharing
brazuca has joined #rust-embedded
<re_irc>
<@grantm11235:matrix.org> BTW, adding closure traits shouldn't have any impact on HAL authors, since they should only be writing SpiBus impls, not any impls for slice or closure traits
<re_irc>
<@dirbaio:matrix.org> agreed
<re_irc>
<@dirbaio:matrix.org> I think that overall we're better off with "slice-based SpiDevice, even if it means some drivers have to fall back to SpiBus+OutputPin" than with "two different traits for the same thing"
<re_irc>
<@vollbrecht:matrix.org> on another note: is there a roadmap or a blocker list with all this changes for releasing an new alpha version ?
brazuca has quit [Quit: Client closed]
<re_irc>
<@vollbrecht:matrix.org> would be nice with all the master changes to have an 1.0.0-alpha.10 release
<re_irc>
<@dirbaio:matrix.org> agreed
<re_irc>
<@dirbaio:matrix.org> there's no blockers for an alpha, no
<re_irc>
<@diondokter:matrix.org> Just read through it all, very interesting!
<re_irc>
Just one thing I want to point out that hasn't really been mentioned (with enough gravity) is that a fully blocking read (give N bytes and wait until they are all filled) would suck. Imagine having some serial device that crashes and stops sending data. Now your program is waiting forever and is as good as crashed as well (aside from interrupts).
<re_irc>
So I don't that would work. Only thing left is a non-blocking read or a blocking read with some sort of idle detection.
<re_irc>
Actually, could that last one be done? Read is blocking until all bytes have been received or until the bus is idle?
<re_irc>
In that case an Ok(0) would be valid... Which yeah... Std compatibility... Might not be an option either
<re_irc>
<@datdenkikniet:matrix.org> : (because I feel like I remember that you mentioned that your matrix client doesn't like threads: here after the meeting seems most appropriate, IMO)
<re_irc>
<@jamesmunns:beeper.com> Oh hey perfect, i took my dog out and had dinner since the serial chat was still going :D
<re_irc>
<@diondokter:matrix.org> Just read through it all, very interesting!
<re_irc>
Just one thing I want to point out about the serial that hasn't really been mentioned (with enough gravity) is that a fully blocking read (give N bytes and wait until they are all filled) would suck. Imagine having some serial device that crashes and stops sending data. Now your program is waiting forever and is as good as crashed as well (aside from interrupts).
<re_irc>
So I don't think that would work. Only thing left is a non-blocking read or a blocking read with some sort of idle detection.
<re_irc>
Actually, could that last one be done? Read is blocking until all bytes have been received or until the bus is idle?
<re_irc>
In that case an Ok(0) would be valid... Which yeah... Std compatibility... Might not be an option either
<re_irc>
<@jamesmunns:beeper.com> So tl;dr: i wanna make a sort of environment where there's "out of the box services" for apps, to make it faster when you're not really cranking up the perf or squeezing out the last resources
<re_irc>
<@jamesmunns:beeper.com> Sorta "no decisions, reasonable defaults boilerplate" sorta stuff
<re_irc>
<@jannic:matrix.org> "serial chat" - new episode each Tuesday?
<re_irc>
<@jamesmunns:beeper.com> Right now I manage the USB link, and provide a command interface, as well as a USB bootloader, and stain/stout/stderr mapping
<re_irc>
<@dirbaio:matrix.org> : embedded-io doesn't block until buffer full, it blocks until at least 1 byte received
<re_irc>
<@diondokter:matrix.org> : Well same problem with just 1 byte
<re_irc>
<@jamesmunns:beeper.com> I'm thinking about adding log and/or defmt endpoints so you can do that over the USB link as well
<re_irc>
<@dirbaio:matrix.org> : it's not a problem, it's just "blocking". That trait is only usable if you have real threads, yes
<re_irc>
<@jamesmunns:beeper.com> It seemed similar, though "N things over one transport" might be less close to "defmt over N transports" than I originally thought :p
<re_irc>
<@dirbaio:matrix.org> but anyway, that's why we discussed adding a nonblocking io trait
<re_irc>
<@jamesmunns:beeper.com> I should probably just go look at your code :D
<re_irc>
<@datdenkikniet:matrix.org> : Yeah, I think the app you're building is a lot "bigger" :P I do think it looks really nice! theorized about doing softdevice-like blobs but written in Rust instead at some point, something like that might be nice for it!
<re_irc>
<@datdenkikniet:matrix.org> "defmt-brtt" is really just the "Logger" impls of "defmt-bbq" and "defmt-rtt" under one hood :P
<re_irc>
<@diondokter:matrix.org> : Well I think that'd be very unusable on embedded then. With just the hals or rtic we don't have threads
<re_irc>
<@datdenkikniet:matrix.org> Yeah, I think the app you're building is a lot "bigger" :P I do think it looks really nice! theorized about doing softdevice-like blobs but written in Rust instead at some point, something like that might be nice/cool for it! (We were thinking "what if we can have a "smoltcp" blob that we can use both in the bootloader and in the app)
<re_irc>
<@dirbaio:matrix.org> : esp-idf does have threads
<re_irc>
<@jamesmunns:beeper.com> : Yeah, I'm super intentionally breaking the "one simple thing per crate" trend, a lotta people just need _something_ that works well out of the box, even if imperfect.
<re_irc>
<@dirbaio:matrix.org> * threads, and I imagine more of these use cases that do will pop up in the future, such as rust-on-zephyr
<re_irc>
<@diondokter:matrix.org> Anyways, let's not continue the discussion, it's been long enough. I would like a non-blocking trait though.
<re_irc>
<@jamesmunns:beeper.com> Sorta going for "simple to start as Arduino/circuitpython, but still Rust under the hood, and isn't scary if you actually look how it works"
<re_irc>
<@datdenkikniet:matrix.org> Integrating "defmt-brtt" might be handy, though! We mostly wanted it because it means we can log over RTT (when doing debugging) without losing the logs in our aggregator service thingie, even while debugging
<re_irc>
<@grantm11235:matrix.org> If there is a way to ask "are you going to block", how are drivers expected to use it? Do they each need to implement their own form of timeout? Or will they just keep polling in a hot loop, leading to the exact same problem
<re_irc>
<@datdenkikniet:matrix.org> * though/then! Some more log capability without worrying tooo much about formatting bloat can be nice.
<re_irc>
<@datdenkikniet:matrix.org> * thingie (that is supposed to go out into production too :P),
<re_irc>
<@jamesmunns:beeper.com> : Could be! I'm targeting boards w/o a debugger tho, so I'm not sure if the RTT part would help
<re_irc>
<@diondokter:matrix.org> : Hmmm you have a point there
<re_irc>
<@dirbaio:matrix.org> keep polling in a hot loop 🤪
<re_irc>
<@jamesmunns:beeper.com> I still have never used nb traits without "block!()" :p
<re_irc>
<@dirbaio:matrix.org> and bye bye battery life
<re_irc>
<@datdenkikniet:matrix.org> Just get a bigger battery????????????? xD
<re_irc>
<@datdenkikniet:matrix.org> +Ez solution
<re_irc>
<@datdenkikniet:matrix.org> * solution, no more design discussion necessary
<re_irc>
<@dirbaio:matrix.org> and toast your user's raspberry pi if they every try to use your driver in it
<re_irc>
<@dirbaio:matrix.org> * one
<re_irc>
<@jamesmunns:beeper.com> : Wait embedded systems run when they aren't attached to two of your USB ports?
<re_irc>
<@dirbaio:matrix.org> OVERCURRENT DETECTED ON HUB 1 PORT 5
<re_irc>
<@jannic:matrix.org> : I've already been thinking about something like that, but didn't find a good API yet. IMHO it should fulfill at least two requirements:
<re_irc>
1. trivial to use, you can write stuff like "give me GPIO 17 and set it to high" without knowing about generics and lifetimes
<re_irc>
2. compatible with the usual embedded rust ecosystem so you can use existing drivers, and (more important) you gently gain knowledge which is generally applicable in a broader context
<re_irc>
<@jamesmunns:beeper.com> Imma just keep building until I'm happy with it, but generally in those directions.
<re_irc>
<@grantm11235:matrix.org> Are there any adapters like ExclusiveDevice that are async?
<re_irc>
<@dirbaio:matrix.org> : "embassy-embedded-hal" has them
<re_irc>
<@dirbaio:matrix.org> * shared devices
<re_irc>
<@dirbaio:matrix.org> "embedded-hal-async" itself has an exclusive one (maybe we should move it to e-h-bus)
<re_irc>
<@grantm11235:matrix.org> If you drop the transaction future, it doesn't de-assert cs 😬
<re_irc>
<@dirbaio:matrix.org> very good point
<re_irc>
<@dirbaio:matrix.org> whoops
<re_irc>
<@grantm11235:matrix.org> I don't think that any of the current adapters have any way to properly handle CS failure
<re_irc>
<@dirbaio:matrix.org> if "set_high()/set_low()" itself fails?
<re_irc>
<@grantm11235:matrix.org> yeah
<re_irc>
<@dirbaio:matrix.org> not much you can do in that case, isn't it
<re_irc>
<@dirbaio:matrix.org> ?
<re_irc>
<@grantm11235:matrix.org> Also, if you get any error at all, you might also have a CS error
<re_irc>
<@dirbaio:matrix.org> imo the current error handling is reasonable given most OutputPins are infallible
<re_irc>
<@dirbaio:matrix.org> also most programs will just abort on these kinds of errors
<re_irc>
<@dirbaio:matrix.org> your hardware is so broken if toggling CS fails...
<re_irc>
<@grantm11235:matrix.org> In that case, I think it makes more sense to require an infallible OutputPin
<re_irc>
<@dirbaio:matrix.org> why?
<re_irc>
<@dirbaio:matrix.org> the adapter does its best, trying to set CS back to high on failure
<re_irc>
<@dirbaio:matrix.org> if your CS is really fallible, what're you supposed to do? wrap it into an infallible one that panics?
<re_irc>
<@dirbaio:matrix.org> the end result is the same
<re_irc>
<@explodingwaffle101:matrix.org> : (not sure if the meeting is over or not… sorry? 😅)
<re_irc>
any reason not to have an option 3- single set of traits but with marker traits if something wants to be picky?
<re_irc>
<@grantm11235:matrix.org> : Yeah. That has the benefit of making the adapter simpler
<re_irc>
<@dirbaio:matrix.org> at the cost of making using it harder
<re_irc>
<@grantm11235:matrix.org> You can get rid of DeviceError
<re_irc>
<@dirbaio:matrix.org> with the current adapter you can do "dev.transation(...).unwrap()" just fine
<re_irc>
<@dirbaio:matrix.org> with your proposal, the user would get confusing trait errors, and would have to unwrap-wrap the OutputPin to make it fake-infallible
<re_irc>
<@grantm11235:matrix.org> Alternatively, the adapters could unwrap the CS errors internally
<re_irc>
<@grantm11235:matrix.org> The situation is even worse with shared busses. If CS fails on one device, you could have another thread try to access another device while the first CS is still active
<re_irc>
<@grantm11235:matrix.org> You could add some form of mutex poisoning, but that just adds a bunch of code that is unnecessary for 99% of use cases
<re_irc>
<@thejpster:matrix.org> I’m pretty sure I’ve used non blocking APIs without block! et al. You just drop into a wfe and wait for an interrupt (one from any Subsystem - UART, radio, etc). Then you whip around and poll everyone, then drop back to sleep.
<re_irc>
<@thejpster:matrix.org> It’s like async but I write the state machines by hand.
<re_irc>
<@dirbaio:matrix.org> writing state machines by hand sucks big time
<re_irc>
<@dirbaio:matrix.org> and if you have "channels" between tasks, waiting for interrupts is not enough
<re_irc>
<@thejpster:matrix.org> So, I’d be concerned if that option was being taken away. As an driver author I’d like to expose a ‘fn poll(&mut self)’ or whatever that pokes the underlying transport and pulls whatever happens to be available.
<re_irc>
I don’t generally drop bytes because the hardware has a small fifo, interrupt latency is small, and uarts are dog slow.
<re_irc>
- poll task B: sends something to the channel
<re_irc>
<@dirbaio:matrix.org> - poll task A: tries to recv from channel, gets WoudBlock
<re_irc>
- wfi
<re_irc>
- deadlock!!
<re_irc>
<@thejpster:matrix.org> well, yeah, don’t do that. Can safely say I’ve managed to not deadlock thus far.
<re_irc>
And one person’s “sucks big time” is another person’s “I can design these FSMs on paper and get all the sequence charts reviewed, and the machine code will largely match the code we wrote”. It’s not for everyone, but that doesn’t make it wrong or invalid.
<re_irc>
<@thejpster:matrix.org> In the channel case, posting to a channel counts as work, and the reactor loops until a work free cycle occurs.
<re_irc>
<@dirbaio:matrix.org> and there's already embedded-hal-nb serial read
<re_irc>
<@dirbaio:matrix.org> nodoby is proposing removing that
<re_irc>
<@dirbaio:matrix.org> the discussion was how to do async traits in the blocking and async cases
<re_irc>
<@dirbaio:matrix.org> * serial
<re_irc>
<@thejpster:matrix.org> Ok, I didn’t get the “async” post on my read through
<re_irc>
<@d3zd3z:matrix.org> Hopefully this is simple: I'm building thumbv7em-none-eabihf (M4F), when I do floating point operations, the compiler seems to be generating calls to things like "__aeabi_dmul" instead of just using floating point instructions. Any ideas?
<re_irc>
<@thejpster:matrix.org> I think I disagree with your assertion that unbuffered is useless. But then I use hardware flow control.
<re_irc>
<@dirbaio:matrix.org> : I believe M4F can only do float in hardware, not double?
<re_irc>
<@d3zd3z:matrix.org> Ahh, let me try f32 instead, that would be nice if it is that simple.
<re_irc>
<@dirbaio:matrix.org> : not everyone can. I've seen many people in embassy chats with issues about losing bytes, and they can't use rts/cts because they're out of pins or the board is already manufactured etc
<re_irc>
<@dirbaio:matrix.org> if you write a driver with the buffered traits, it can work well either with or without rts/cts
<re_irc>
<@dirbaio:matrix.org> if you write it with unbuffered, it'll only work with
<re_irc>
<@dirbaio:matrix.org> so for drivers that intend to be portable, buffered is best
<re_irc>
<@dirbaio:matrix.org> if the driver doesn't intend to be portable you don't need a trait at all
<re_irc>
<@grantm11235:matrix.org> Don't the SpiDevice adapters need to make sure that CS is high at initialization?