cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
starblue has quit [Ping timeout: 246 seconds]
bjc has joined #rust-embedded
starblue has joined #rust-embedded
brazuca has quit [Quit: Client closed]
bjc has quit [Ping timeout: 255 seconds]
lehmrob has joined #rust-embedded
lehmrob has quit [Ping timeout: 240 seconds]
Foxyloxy has quit [Read error: Connection reset by peer]
Foxyloxy has joined #rust-embedded
starblue has quit [Ping timeout: 255 seconds]
<re_irc>
<@jannic:matrix.org> Which reminds me that I should prepare a new release of that create. Currently you'd probably need a git dependency.
<re_irc>
<@jannic:matrix.org> * crate.
<re_irc>
<@jannic:matrix.org> Done, published rp2040-panic-usb-boot v0.5.0
<cr1901>
Cool. I woke up unexpectedly early, so maybe I'll try to use that crate to pass the time
IlPalazzo-ojiisa has joined #rust-embedded
<cr1901>
jannic: Well, it's not a panic, but I did confirm it works (and also installed picotool while I was at it). Neat little crate
<re_irc>
<@jannic:matrix.org> Perhaps you can add panics at strategic places to get some visibility about what goes wrong. But obviously, it's not a good replacement for a debug probe.
<cr1901>
well, the stlink header on my rp2040 uses a cable pitch that none of my debuggers can interface to easily :(
<cr1901>
rp2040 board*
<cr1901>
But yes I agree
cosj[m] has quit [Ping timeout: 252 seconds]
cosj[m] has joined #rust-embedded
rardiol has joined #rust-embedded
cosj[m] has quit [Ping timeout: 246 seconds]
bjc has joined #rust-embedded
cosj[m] has joined #rust-embedded
rardiol has quit [Ping timeout: 248 seconds]
emerent has quit [Ping timeout: 248 seconds]
emerent has joined #rust-embedded
brazuca has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> I won't be able to attend today's meeting :(
<re_irc>
<@dirbaio:matrix.org> wish you guys lots of happy discussions and merges :)
<re_irc>
<@dirbaio:matrix.org> embedded-hal merges in particular :) :) :)
lehmrob has joined #rust-embedded
brazuca has quit [Quit: Client closed]
dc740 has joined #rust-embedded
<re_irc>
<@jannic:matrix.org> Regarding the meeting: For people with different daylight saving time rules, Europe switched to DST last weekend, so the meeting will be at 6pm UTC today, right? One hour earlier than before, when specified in UTC.
<re_irc>
<@dirbaio:matrix.org> yes
brazuca has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> hi @room , meeting time again! agenda is https://hackmd.io/c_cOzngBTBmgyiHrHQu-sg though i'm still putting it together, anyway add anything you'd like to talk about or announce and we'll start in 5min :)
<re_irc>
<@adamgreig:matrix.org> ok, let's go! i don'tt hink I have any announcements this week, but go for it about, e310x :)
<re_irc>
<@adamgreig:matrix.org> * about
<re_irc>
<@almindor:matrix.org> Thanks, I just wanted to bring this PR up again, since it changes a bunch of things. There's also an ongoing discussion about the PLIC. I'll be merging the PR today or tomorrow and following up with the e310x-hal. If you're an interested party, feel free to ping and/or join in on the PR side
<re_irc>
<@adamgreig:matrix.org> cool, thanks for the update!
<re_irc>
<@adamgreig:matrix.org> , do you want to discuss any of the embedded-hal PRs?I noticed there was a bunch of activity today but not sure if anything wants further chat now (maybe buffered vs unbuffered naming?)
<re_irc>
<@eldruin:matrix.org> yes
<re_irc>
<@eldruin:matrix.org> let's settle that
<re_irc>
<@eldruin:matrix.org> I think the rest is fine
<re_irc>
<@eldruin:matrix.org> : are you around?
<re_irc>
<@adamgreig:matrix.org> so from last week I think we got to agreeing that in principle some drivers work fine with a generic "io" read trait where the contract is "you don't need to poll super often, the buffer is arranged to be 'big enough' that you can read it later"
<re_irc>
<@adamgreig:matrix.org> said he can't make the meeting today
<re_irc>
<@adamgreig:matrix.org> in which case the suggestion is "use embedded-io instead of embedded-hal", with some idea of moving embedded-io into the wg to go with it
<re_irc>
<@adamgreig:matrix.org> whereas other drivers don't require that buffer and can operate fine only reading when they expect data
<re_irc>
<@adamgreig:matrix.org> but I think the sticking point is that even the raw uart case has at least a one-word buffer (i.e. so long as you read it before the next word comes in you're OK), and often a few more words in hardware, so it's not really "unbuffered", i.e. you don't need to have started reading before the word arrives
<re_irc>
<@adamgreig:matrix.org> and also, does anything _need_ unbuffered?
<re_irc>
<@adamgreig:matrix.org> we also didn't really discuss the write side much, I think it's basically identical between the two cases but perhaps some applications do want to write to a buffer that's flushed in the background and others not? but we'd probably have flush() either way
<re_irc>
<@eldruin:matrix.org> yeah, I was also thinking about that distinction existing at all
<re_irc>
<@eldruin:matrix.org> to me it sounds like the same trait, regardless of whether the _impl_ provides a big or small buffer
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@eldruin:matrix.org> it sounds like we are trying to tie traits to some impl configuration
<re_irc>
<@adamgreig:matrix.org> like, a HAL could offer both an "unbuffered" (ie just using the hardware buffer) trait and a separate trait that does have a buffer it handles for you, conceivably
<re_irc>
<@adamgreig:matrix.org> but I wonder if it would ever bother? you could just ask for like a 4 or 8 byte buffer and always use the buffered version
<re_irc>
<@eldruin:matrix.org> yeah or just a function where you provide a buffer for it to use, however big you need
<re_irc>
<@adamgreig:matrix.org> I take dirbaio's point that for many drivers they really do need a buffer because it's not practical for them to poll the uart fast enough to read every byte as it comes in
<re_irc>
<@adamgreig:matrix.org> and the hal really wants to use dma or whatever to manage the buffer for you
<re_irc>
<@adamgreig:matrix.org> there are some differences in the trait as it stands, because the functions for reading are a bit different
<re_irc>
<@eldruin:matrix.org> yeah I was thinking if the problem is the driver not being able to say how big of a buffer it needs but it is really not only up to the driver but also depends on how often the app allows the driver to poll
<re_irc>
<@adamgreig:matrix.org> in particular embedded-io has read(buf: &mut[u8]) -> Result<usize> and read_exact(buf: &mut [u8]) -> Result<()>, while embedded-hal proposes ReadExact and also ReadUntilIdle
<re_irc>
<@eldruin:matrix.org> and I do not think e-h has any way of standarizing that
<re_irc>
<@adamgreig:matrix.org> you wouldn't have ReadUntilIdle in the "io" case I don't think, but
<re_irc>
<@eldruin:matrix.org> ah ok
<re_irc>
<@adamgreig:matrix.org> it seems kind of niche, and you can always implement it with a timeout or something anyway?
<re_irc>
<@almindor:matrix.org> from what I understand the issue really is "early return" though, no?
<re_irc>
<@eldruin:matrix.org> io's read is rather "ReadSome"
<re_irc>
<@eldruin:matrix.org> But that also sounds ok
<re_irc>
<@adamgreig:matrix.org> io has ReadSome and ReadExact, embedded-hal PR has ReadExact and ReadUntilIdle
<re_irc>
<@adamgreig:matrix.org> (ReadExact is just ReadSome and a while loop though)
<re_irc>
<@eldruin:matrix.org> at first sight at least I see no problem in having ReadSome in e-h as well
<re_irc>
<@jannic:matrix.org> ReadSome is needed in some situations, isn't it? (Well depends on the definition of 'Idle')
<re_irc>
<@adamgreig:matrix.org> I guess the question then is what the point is of having a uart trait in e-h at all, if it's the same trait as embedded-io::Read
<re_irc>
<@jannic:matrix.org> And it's more general than ReadExact.
<re_irc>
<@almindor:matrix.org> isn't the proposed "read_until_idle" same as the current "read" ?
<re_irc>
<@adamgreig:matrix.org> which current read, in e-h 1.0 alpha?
<re_irc>
<@eldruin:matrix.org> I understand "ReadSome" as fill it up with all you have, if you have less data than the buffer, either because of idle or because the HW buffer is exhausted, then it does not fill the parameter buffer
<re_irc>
<@adamgreig:matrix.org> I don't think idle really comes into it at all for the embedded-io version
<re_irc>
<@adamgreig:matrix.org> you read whatever's currently in the buffer, or as much as fills the buffer you provided
<re_irc>
<@almindor:matrix.org> ah right, serial read is just a single word case
<re_irc>
<@adamgreig:matrix.org> whereas "idle" in the proposed embedded-hal is specifically "read until either the provided buffer is filled or the serial line has an idle condition"
<re_irc>
<@adamgreig:matrix.org> i.e. in io you don't block, but in hal you do
<re_irc>
<@jannic:matrix.org> For fast links there's no huge difference between ReadUntilIdle and ReadSome. But if the bit rate is low, the buffer can fill slowly without the line becoming idle, so ReadUntilIdle can block a while.
<re_irc>
<@almindor:matrix.org> "ReadUntilIdle" can block technically
<re_irc>
<@eldruin:matrix.org> Sure, but we can have that extra "ReadSome". What would be missing if we had "ReadSome", "ReadExact", "ReadUntilIdle"? too much redundancy?
<re_irc>
<@adamgreig:matrix.org> yea, I think there's a big difference, ReadSome is "give me as much as you can from the buffer and return", while proposed ReadExact and ReadUntilIdle are "block until you fill my buffer" and "until you see an idle on the line or fill my buffer"
<re_irc>
<@jannic:matrix.org> Is ReadExact needed? Or is it just convenience? If you have ReadSome, you can implement ReadExact yourself.
<re_irc>
<@adamgreig:matrix.org> yea, in embedded-io it has a default impl in terms of ReadSome
<re_irc>
<@adamgreig:matrix.org> convenient thing to have when you want to block though so why not
<re_irc>
<@adamgreig:matrix.org> : I don't think it's a redundancy problem, but "ReadSome" implies a buffer that's stored things in the background, which the others don't
<re_irc>
<@almindor:matrix.org> there could be hw specifics that make "ReadExact" more "correct" though? (e.g. blocking in hw without ping-pong)
<re_irc>
<@adamgreig:matrix.org> ReadExact and ReadUntilIdle can operate as "start writing into the buffer I provided, stop on this condition"
<re_irc>
<@adamgreig:matrix.org> whereas ReadSome is quite different, it's "copy me everything you've been receiving and return right away"
<re_irc>
<@eldruin:matrix.org> hmm, true
<re_irc>
<@eldruin:matrix.org> anyway that's not a problem, is it?
<re_irc>
<@eldruin:matrix.org> implying that a buffer is necessary
<re_irc>
<@eldruin:matrix.org> there are buffers all over the place
<re_irc>
<@eldruin:matrix.org> we can say that's how ReadSome works
<re_irc>
<@adamgreig:matrix.org> sure, ReadSome could just be "try to read a byte out the hardware buffer right now, let me know if you got anything"
<re_irc>
<@adamgreig:matrix.org> basically same as the current nb read works
<re_irc>
<@adamgreig:matrix.org> so you can implement it even on hardware with just a single word buffer
<re_irc>
<@eldruin:matrix.org> yeah we can also specify that
<re_irc>
<@adamgreig:matrix.org> but I don't know if it's a helpful trait as such
<re_irc>
<@jannic:matrix.org> : Personally I don't care where the trait lives, as long as it's a well-known place the ecosystem can agree on, to avoid fragmentation.
<re_irc>
<@adamgreig:matrix.org> yea, we could even re-export it from e-h, whatever
<re_irc>
<@adamgreig:matrix.org> it does feel like e-h "should" have something for uarts since they really sit alongside spi and i2c as the obvious serial protocols
<re_irc>
<@almindor:matrix.org> : it depends on the hw implementations no? if a hw can do "i will block for you until this is filled" without ping-pong, then it should be supported rather than forcing a software ping-pong (e.g. repeated calls) because the abstraction just says "meh, you can implement ReadExact via ReadSome anyway"
<re_irc>
<@adamgreig:matrix.org> hmm
<re_irc>
<@grantm11235:matrix.org> Is it also possible to have a bit-banged impl that reads directly into the users buffer without an intermediate buffer? It would have no way to implement "ReadSome" without blocking
<re_irc>
<@adamgreig:matrix.org> but we'd have ReadExact as a method
<re_irc>
<@adamgreig:matrix.org> and HALs could implement it without using ReadSome
<re_irc>
<@adamgreig:matrix.org> that's just a default impl
<re_irc>
<@almindor:matrix.org> oh in that case sure, I was looking at it from the POV of "removing the extras"
<re_irc>
<@adamgreig:matrix.org> embedded-io::read has read_some and also read_exact as a default, so I think those two make sense
<re_irc>
<@adamgreig:matrix.org> : yea, true
<re_irc>
<@adamgreig:matrix.org> a bitbanged impl is the one case that really doesn't have any buffer at all, you're right
<re_irc>
<@adamgreig:matrix.org> ReadSome would have to always return no data read, or would have to block (for how many words?)
cr1901 has quit [Ping timeout: 260 seconds]
<re_irc>
<@adamgreig:matrix.org> I suppose that's the behaviour intended to be captured by the e-h PR: direct access to a uart where you can read n words directly into the provided buffer
<re_irc>
<@adamgreig:matrix.org> would work fine for a bitbanged software uart, or for whatever tiny hardware buffer's in the peripheral, the hal wouldn't ever implement a separate memory buffer (and wouldn't ever need to)
<re_irc>
<@adamgreig:matrix.org> but it's not clear to me that anyone will write a driver using that trait, because almost all drivers will have a much easier time using a buffered read
<re_irc>
<@almindor:matrix.org> wait, so there's a case of calling ReadSome and getting 0/empty back, or does ReadSome guarantee 1 word?
<re_irc>
<@eldruin:matrix.org> I would say it is fine for the buffer size of "ReadSome" to be impl-defined, so this could all be defined by the impls. If you want something else, you can use the other traits
<re_irc>
<@adamgreig:matrix.org> : hmm good question actually, I would have thought it generally being non blocking would be useful (there's readexact when you wanna block)
<re_irc>
<@grantm11235:matrix.org> : It would be useful if you have a protocol where you know exactly when and how much data to recieve
<re_irc>
<@adamgreig:matrix.org> but the docs for embedded-io say "same as std::io" and that says "does not provide any guarantees about whether it blocks waiting for data"
<re_irc>
<@almindor:matrix.org> I think we're conflating 3 things here:
<re_irc>
<@almindor:matrix.org> 1. blocking vs non-blocking
<re_irc>
<@almindor:matrix.org> 2. buffered vs unbuffered
<re_irc>
<@almindor:matrix.org> 3. early vs total return
<re_irc>
<@adamgreig:matrix.org> : it _works_ in that case, but the buffered version is also fine, you can just readexact from the buffer and it'l give you exactly how much data you wanted
<re_irc>
<@adamgreig:matrix.org> without having to worry about "what if i just missed the first byte because i wasn't polled quick enough" or whatever
<re_irc>
<@jannic:matrix.org> Last week we had another dimension which was roughly "needs fast polling to avoid data loss" vs. "buffer is large enough so data loss won't happen"
<re_irc>
<@adamgreig:matrix.org> : right, I think those are the relevant dimensions, though "unbuffered" is kind of a split between "a large enough buffer that you don't worry about it" and "at least a byte or so of buffer so it's at least possible to just poll fast enough without blocking or missing anything"
<re_irc>
<@adamgreig:matrix.org> * "buffered"
<re_irc>
<@almindor:matrix.org> : sure, and you could also say that "return realy" kind of dictates the blocking aspect
<re_irc>
<@almindor:matrix.org> * early"
<re_irc>
<@almindor:matrix.org> it needs to be clear though, if ReadSome guarantees 1 word, then it's blocking (as an example)
<re_irc>
<@almindor:matrix.org> ReadExact is obviously blocking
<re_irc>
<@adamgreig:matrix.org> yea, it would need to be clear
<re_irc>
<@adamgreig:matrix.org> though the version in embedded-io is deliberately not, actually
<re_irc>
<@adamgreig:matrix.org> it might return immediately with 0, or it might block until it has at least 1, or more than 1
<re_irc>
<@almindor:matrix.org> I'd call the non blocking version a ReadAny
<re_irc>
<@adamgreig:matrix.org> good point... "some" does imply >0 but the real name for the method is just "read"
<re_irc>
<@adamgreig:matrix.org> we're saying read_some here to distinguish it
<re_irc>
<@adamgreig:matrix.org> could have ReadAny and ReadSome and ReadExact though...
<re_irc>
<@eldruin:matrix.org> sure, serial protocol is too controversial :D
cr1901 has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> go for it :P
<re_irc>
<@grantm11235:matrix.org> I think that the slice-based api is useful to support linux spidev, but I don't necessarily think that it should replace the closure-based api because it is strictly less powerful.
<re_irc>
With the closure api, you can
<re_irc>
- add a delay inside a transaction
<re_irc>
- send or receive an arbitrarily large amount of data in a single transaction, which might not even be able to fit in ram
<re_irc>
- read data, process it, then reply within a single transaction
<re_irc>
(I don't know how often these patterns come up in practice. If anyone has any examples, please let me know)
<re_irc>
Instead I would propose adding a set of slice-based traits _in addition_ to the existing traits. There can be a blanket impl such that any hal which implements the closure traits will automatically implement the slice traits.
<re_irc>
The main downside to this approach is that it adds even more traits, which will be confusing for users. I think this can be somewhat mitigated with good documentation.
<re_irc>
<@adamgreig:matrix.org> having two sets sounds pretty annoying from a drivers point of view
<re_irc>
<@adamgreig:matrix.org> is there a problem providing an impl for one set in terms of the other if hals wanted to provide both, too?
<re_irc>
<@almindor:matrix.org> would an iterator based approach work for both cases? you could hack all of the edge cases you mentioned into the iterator
<re_irc>
<@grantm11235:matrix.org> : Technically, it would be a third set 😬
<re_irc>
<@eldruin:matrix.org> the thing is that doing stuff like delay inside the closure would be totally broken in spidev
<re_irc>
<@adamgreig:matrix.org> yea, linux-embedded-hal would not implement the closure ones
<re_irc>
<@adamgreig:matrix.org> only the slice one
<re_irc>
<@eldruin:matrix.org> ah I see
<re_irc>
<@adamgreig:matrix.org> and if you wanted to use a driver that picked the closure one, outta luck?
<re_irc>
<@almindor:matrix.org> that's not a solution then IMO
<re_irc>
<@eldruin:matrix.org> iterator does not work for spidev either, if you want a transaction, you need an array of packets upfront
<re_irc>
<@eldruin:matrix.org> spidev only works slice-based
<re_irc>
<@grantm11235:matrix.org> If a driver _needs_ the closure api, you can't use it with spidev, because spidev is fundamentally limited
<re_irc>
<@grantm11235:matrix.org> No amount of traits will ever fix that
<re_irc>
<@adamgreig:matrix.org> but if a driver doesn't need it and just chose it because it was more convenient or the author only needed to use it with a hal that supported it or something?
<re_irc>
<@adamgreig:matrix.org> i guess a big question is how many / if any drivers need those extra capabilities
<re_irc>
<@almindor:matrix.org> drivers need transaction
<re_irc>
<@almindor:matrix.org> e.g. the max usb driver is an example where it's necessary IIRC
<re_irc>
<@adamgreig:matrix.org> you get transaction with the slice api proposal though
<re_irc>
<@almindor:matrix.org> oh you meant extra features from the closure
<re_irc>
<@adamgreig:matrix.org> yea, sorry
<re_irc>
<@almindor:matrix.org> yeah those are probably not needed
<re_irc>
<@adamgreig:matrix.org> being able to delay or do something else in between chunks of the transaction
<re_irc>
<@almindor:matrix.org> i can image the single read/reply kind of thing might pop up
<re_irc>
<@almindor:matrix.org> e.g. the need to ensure it's a single device "transaction" on a shared bus that never flips the CS while a full cycle of things happens
<re_irc>
<@almindor:matrix.org> but that can be ensured in other ways
<re_irc>
<@jannic:matrix.org> Are there things like displays where the display update must be done in a single transaction, but where the amount of data to be sent might be too large to fit in ram? Or is this purely theoretical and no issue in practice?
<re_irc>
<@eldruin:matrix.org> We can readd the closure api in 1.1
<re_irc>
<@adamgreig:matrix.org> yea, conceivably. i think usually with such displays you can toggle cs to send multiple chunks
<re_irc>
<@adamgreig:matrix.org> yea, but we can't delete the slice api in 1.1
<re_irc>
<@almindor:matrix.org> i did a shared displays "demo" setup with 2 display on 1 bus on the e310x (total RAM is 16k, not enough for a frame buffer). Worst you could be forced to do is split the windowing
<re_irc>
<@almindor:matrix.org> (that's with MIPI DCS type displays that do the address window thing)
<re_irc>
<@adamgreig:matrix.org> it is a bit annoying for a driver in that case to have do compute a bit of the window into a buffer, then send it, then repeat that in lots of transactions, rather than start a transaction then compute and send each byte one by one
<re_irc>
<@adamgreig:matrix.org> you can't just say "well use SpiBus instead of device" because it could totally still be a shared bus, too
<re_irc>
<@almindor:matrix.org> : that part is handled by the "user" though not the driver technically
<re_irc>
<@adamgreig:matrix.org> how so?
<re_irc>
<@almindor:matrix.org> the driver just automates whatever chunk you give it
<re_irc>
<@adamgreig:matrix.org> hm, yea, I guess
<re_irc>
<@adamgreig:matrix.org> still, same effect
<re_irc>
<@jannic:matrix.org> We want drivers to use the slice API if possible, so they'll work with spidev. If we later learn that there are actually drivers which can only be implemented using the closure API, we still want most drivers to use the slice API, even if we add the closure-API additionally, no?
<re_irc>
<@almindor:matrix.org> one downside of the slice API (apart from the ones mentioned) is actual ownership hell
<re_irc>
<@adamgreig:matrix.org> : I think that's right, yea
<re_irc>
<@almindor:matrix.org> chugging along a &[] between "threads" etc. in a more complex OS could be problematic (I had that headache before with a similar API that expected a "&[&sometrait]")
<re_irc>
<@almindor:matrix.org> i really wished it was using an iterator instead :D
<re_irc>
<@adamgreig:matrix.org> I still wonder if we could force spidev to work with closures, in the horrible way we discussed where you take a single spidev device on a virtual/unused cs pin, use that for a SpiBus, and have the SpiDevices all provided via gpio cs
<re_irc>
<@adamgreig:matrix.org> the downside is that it breaks if you have a device tree with real spidev for each device already configured because then you can't use those cs as gpio and you can't run the bus without one of them
starblue has joined #rust-embedded
<re_irc>
<@almindor:matrix.org> it does seem like we're being good abstractions due to spidev specifically
<re_irc>
<@adamgreig:matrix.org> but in principle it is an (possibly) option to provide the closure api on linux spidev like that, which works if you can set up the device tree to permit it
<re_irc>
<@almindor:matrix.org> any chance we could force torvalds to reconsider the api? :D
<re_irc>
<@adamgreig:matrix.org> i guess it does mean no one can use spidev for such drivers either :P
<re_irc>
<@almindor:matrix.org> it does seem like we're bending good abstractions due to spidev specifically
<re_irc>
<@adamgreig:matrix.org> though in principle you could just write a driver for each linux soc spi peripheral and access it directly right :P
brazuca55 has joined #rust-embedded
<re_irc>
<@grantm11235:matrix.org> spidev isn't meant to be the perfect api, it is just meant to be good enough most of the time to hack around with in userspace
brazuca55 has quit [Client Quit]
brazuca23 has joined #rust-embedded
<re_irc>
<@almindor:matrix.org> perhaps we can just make a "SpiDeviceTorvalds" trait :P
<re_irc>
<@grantm11235:matrix.org> I'm pretty sure you could implement the closure traits just fine from kernelspace
<re_irc>
<@almindor:matrix.org> hmm, use a module to enable this then?
brazuca2 has joined #rust-embedded
<cr1901>
SpiDeviceTorvalds <-- this but unironically
<re_irc>
<@adamgreig:matrix.org> are there reasons to prefer the slice api besides just it working with spidev?
* cr1901
is finally back after internet gave out
<re_irc>
<@almindor:matrix.org> "hey if you wanna use linux with our spi traits, load this module"
<re_irc>
<@adamgreig:matrix.org> the PR says "Gets rid of the cursed borrow issues in async."
<re_irc>
<@eldruin:matrix.org> : it's simpler. less stuff you can do wrong
<re_irc>
<@adamgreig:matrix.org> yea, true
<re_irc>
<@almindor:matrix.org> I think using an iterator would be the best way to handle the cursed borrows
<re_irc>
<@adamgreig:matrix.org> and for like 90% of all spi use it's probably perfectly fine and easy to use
<re_irc>
<@eldruin:matrix.org> also, works for 90% of the cases I guess
<re_irc>
<@jannic:matrix.org> Probably more, otherwise spidev would be designed differently
<re_irc>
<@grantm11235:matrix.org> : I believe this is only due to a current limitation in the borrowchecker (or maybe the trait system?)
<re_irc>
<@grantm11235:matrix.org> Another thing you can't do with the closure traits is take an arbitrarily large "&[u16]", byte swap it, and send it out in a single transaction
<re_irc>
<@adamgreig:matrix.org> closure or slice?
brazuca has quit [Ping timeout: 260 seconds]
<re_irc>
<@grantm11235:matrix.org> : oops, slice
<re_irc>
<@almindor:matrix.org> that is actually a good use case for displays
<re_irc>
<@grantm11235:matrix.org> Another thing you can't do with the ~closure~ slice traits is take an arbitrarily large "&[u16]", byte swap it, and send it out in a single transaction
<re_irc>
<@eldruin:matrix.org> would you need it to be inside a single transaction? that would mean you read that array from the same device you are immediately writing it into again
brazuca23 has quit [Ping timeout: 260 seconds]
<re_irc>
<@almindor:matrix.org> yes, like a blit update
<re_irc>
<@almindor:matrix.org> for example with a device that cannot fit the framebuffer into memory
<re_irc>
<@grantm11235:matrix.org> I mean the display driver takes a slice from the user, not from the spi device
<re_irc>
<@eldruin:matrix.org> with a slice from the user you can do it with the slice api, just need to swap in the driver beforehand
<re_irc>
<@adamgreig:matrix.org> but you need to make a new buffer the same size as the slice the user gave you
<re_irc>
<@grantm11235:matrix.org> You can't swap an immutable slice
<re_irc>
<@eldruin:matrix.org> I see
<re_irc>
<@eldruin:matrix.org> you can do that with transferinplace
<re_irc>
<@adamgreig:matrix.org> though if you have a u16 slice and you need u8 to give the spi driver you have to do something in the middle anyway
<re_irc>
<@grantm11235:matrix.org> With the closure traits, you can copy to a small buffer, swap that, send, and repeat
<re_irc>
<@eldruin:matrix.org> I do not understand why that needs to me inside the transaction, though
<re_irc>
<@almindor:matrix.org> it doesn't necessarily, not for the display case at least
<re_irc>
<@almindor:matrix.org> you could read a rect -> do whatever (switch CS etc.) -> write updated rect without much issues
<re_irc>
<@almindor:matrix.org> efficiency might be a bit lower but that's about it
<re_irc>
<@eldruin:matrix.org> AIUI, the closure api is needed if you want to read something from the device, then do something with that information, then write something to the device, but your device needs to be selected the whole time
<re_irc>
<@almindor:matrix.org> yes, I think some SPI USB host devices need that
<re_irc>
<@grantm11235:matrix.org> The scenario I am describing doesn't involve reading from spi device at all
<re_irc>
<@eldruin:matrix.org> : there you have the whole SpiBus, though, so it would not be a problem
<re_irc>
<@almindor:matrix.org> no you don't
<re_irc>
<@almindor:matrix.org> it's a normal SpiDevice that you use as a host for USB
<re_irc>
<@almindor:matrix.org> you can have a display on the same Bus
<re_irc>
<@eldruin:matrix.org> : If you do not need to read, why would you need to keep the device selected for a long amount of time?
<re_irc>
<@almindor:matrix.org> i was actually going to use one like that
<re_irc>
<@eldruin:matrix.org> : I do not understand what that is, you mean something different from an FT232xxx, right?
<re_irc>
<@almindor:matrix.org> IIRC there were some comms sessions you want to keep the CS asserted through, I haven't used it for a while though
<re_irc>
<@grantm11235:matrix.org> : because otherwise you would need to have another buffer at least as big as the the "&[u16]" that the user provides, or you would need to split the transaction up into multiple separate transactions that are the size of a smaller buffer
<re_irc>
<@eldruin:matrix.org> hmm, so an USB host chip that is controlled through spi?
<re_irc>
<@eldruin:matrix.org> nice
brazuca2 is now known as brazuca
<re_irc>
<@almindor:matrix.org> yeah, I never got past basic connect/disconnect detection though it was super flakey for me
<re_irc>
<@eldruin:matrix.org> I see
<re_irc>
<@eldruin:matrix.org> it's an interesting chip though
<re_irc>
<@almindor:matrix.org> anyway IIRC there's a combination there where you want to reply to it without deasserting CS
<re_irc>
<@almindor:matrix.org> I gtg. wife is calling :D
<re_irc>
<@adamgreig:matrix.org> yea, we're out of time I think, thanks everyone!
<re_irc>
<@adamgreig:matrix.org> lots of interesting points even if we didn't necessarily get to a conclusion, heh
<re_irc>
let mut buffer = &mut buffer[0..chunk.len()];
<re_irc>
buffer.copy_from_slice(chunk);
<re_irc>
for word in buffer {
<re_irc>
*word = word.to_be();
<re_irc>
}
<re_irc>
let buffer = transmute_u16_to_u8(buffer);
<re_irc>
bus.send(buffer);
<re_irc>
}
<re_irc>
)
<re_irc>
}
<re_irc>
<@grantm11235:matrix.org> That is the sort of thing I was talking about. It isn't possible to rewrite that with a slice api in such a way that it only does one transaction
brazuca has quit [Quit: Client closed]
<re_irc>
<@grantm11235:matrix.org> (unless you use alloc and copy the whole slice to a vec, or impose a limit to the maximum size of the slice)
rardiol has joined #rust-embedded
rardiol has quit [Client Quit]
rardiol has joined #rust-embedded
DepthDeluxe has joined #rust-embedded
rardiol has quit [Quit: No Ping reply in 180 seconds.]
cr1901_ has joined #rust-embedded
rardiol has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
rardiol_ has joined #rust-embedded
rardiol has quit [Ping timeout: 265 seconds]
rardiol_ has quit [Client Quit]
rardiol has joined #rust-embedded
lehmrob has quit [Ping timeout: 248 seconds]
Socke has quit [Ping timeout: 276 seconds]
rardiol has quit [Quit: No Ping reply in 180 seconds.]
rardiol has joined #rust-embedded
<re_irc>
<@grantm11235:matrix.org> : I skimmed the MAX3421E datasheet and I think i found a situation where it is useful, but not strictly necessary, to be able to react to data within a transaction
<re_irc>
<@grantm11235:matrix.org> You could optimistically start a transaction by sending a command byte and simultaneously receiving the status byte. Then, depending on the status, you could choose to continue with the transaction, or abort early
<re_irc>
<@grantm11235:matrix.org> Otherwise, you would need to send a dummy command to get the status byte, then optionally start a second transaction with the real command. This is obviously a bit less efficient
Socke has joined #rust-embedded
rardiol has quit [Quit: No Ping reply in 180 seconds.]
rardiol has joined #rust-embedded
<re_irc>
<@grantm11235:matrix.org> something like this
dc740 has quit [Remote host closed the connection]
dc740 has joined #rust-embedded
rardiol has quit [Quit: No Ping reply in 180 seconds.]
rardiol has joined #rust-embedded
<re_irc>
<@grantm11235:matrix.org> I would also argue that it is not important for a max3421e driver to work with userspace spidev. If you are using such a chip with linux, you will almost certainly want to use it with a kernel driver
rardiol has quit [Ping timeout: 265 seconds]
rardiol has joined #rust-embedded
cr1901_ is now known as cr1901
rardiol has quit [Quit: No Ping reply in 180 seconds.]
rardiol has joined #rust-embedded
<re_irc>
<@almindor:matrix.org> hmm is svd2rust supposed to generate a linking file with the memory region info?
rardiol has quit [Ping timeout: 248 seconds]
<re_irc>
<@almindor:matrix.org> ooh I see build.rs gets overridden with the interrupt handler stuff, but we used it for RAM setting as well in the past so now that's missing o.O
rardiol has joined #rust-embedded
rardiol has quit [Quit: No Ping reply in 180 seconds.]
rardiol has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> back at the computer
<re_irc>
<@dirbaio:matrix.org> damn, so not only uart is still controversial, but also spi is ... D:
rardiol has quit [Ping timeout: 260 seconds]
rardiol has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> haha D:
rardiol has quit [Quit: No Ping reply in 180 seconds.]
rardiol has joined #rust-embedded
brazuca has joined #rust-embedded
brazuca has quit [Quit: Client closed]
dc740 has quit [Remote host closed the connection]