cr1901 has quit [Read error: Connection reset by peer]
m5zs7k has quit [Ping timeout: 250 seconds]
m5zs7k has joined #rust-embedded
cr1901 has joined #rust-embedded
loki_val has quit [Quit: No Ping reply in 180 seconds.]
crabbedhaloablut has joined #rust-embedded
seer has quit [Ping timeout: 268 seconds]
starblue has quit [Ping timeout: 252 seconds]
starblue has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
causal has quit [Quit: WeeChat 3.6]
crabbedhaloablut has quit [Write error: Connection reset by peer]
crabbedhaloablut has joined #rust-embedded
rardiol has joined #rust-embedded
seer has joined #rust-embedded
<re_irc>
<adamgreig> hi room, meeting time again! agenda is https://hackmd.io/g5aneOXWTiOusiskvT3rdg, please add anything you'd like to announce or discuss, and we'll start in 5min
rardiol has quit [Ping timeout: 265 seconds]
<cr1901>
Oh good, you added my issue thanks
dc740 has joined #rust-embedded
<re_irc>
<adamgreig> ok, let's start! just a few bits on the agenda this week, first up a quick announcement that there's now a pr to stabilise default_alloc_error_handler which should eventually mean stable custom allocators on no_std aiui, https://github.com/rust-lang/rust/pull/102318
<re_irc>
<adamgreig> (albeit always with a panic on oom instead of a custom error)
<re_irc>
<adamgreig> hm that's all my announcements, anyone have anything else?
<cr1901>
Interesting that no_std can't customize the error
<re_irc>
<eldruin> the e-h split was merged
<re_irc>
<eldruin> the first e-h-nb release will be out soon
<re_irc>
<eldruin> thanks go to dirbaio !
<re_irc>
<almindor> I do declare that I can't wait for e-h v1 release :)
<re_irc>
<adamgreig> cr1901 has opened an issue on rust to investigate the bloat caused by swapping to c-s when the compiler sometimes duplicates the inlined release method, https://github.com/rust-lang/rust/issues/102295
<re_irc>
<eldruin> jannic: can do, let's talk about it tomorrow
<re_irc>
<GrantM11235> I'm pretty sure it is impossible to implement the current spi traits with the userspace spidev
<re_irc>
<adamgreig> I'm hoping we can at least find something that mostly works, at least if e.g. your cs pins are all done using gpio, and you just use one spidev with cs control disabled to run the bus itself, but it does seem like the two abstractions don't play well
<re_irc>
<adamgreig> i don't know if linux has any alternative generic/cross-platform spi interface, besides spidev it's mostly chip-specific drivers?
<re_irc>
<adamgreig> i have seen e.g. a userspace driver for the rpi spi peripheral
<re_irc>
<adamgreig> almindor: is that bare metal riscv though, not on linux?
<re_irc>
<almindor> that is bare metal correct, is this a linux specific issue only?
<re_irc>
<GrantM11235> yes
<re_irc>
<adamgreig> yea, the problem is that linux only exposes an abstraction that basically already is a single spi device with linux managing the cs and sharing
<re_irc>
<adamgreig> with no way to directly access the bus and control the cs pins yourself
<re_irc>
<almindor> oh that sucks...
<re_irc>
<almindor> any way we could.. change linux then? :D
<re_irc>
<adamgreig> the current linux-embedded-hal crate has a basically totally broken implementation of the e-h 1.0 spi traits that doesn't work as soon as you do more than one thing in a "transaction" or have multiple devices
<re_irc>
<adamgreig> but, the new e-h 1.0 spi trait is really nice for all the microcontrollers, so... 😢
<re_irc>
<GrantM11235> The e-h spi traits require/guarantee a lot of manual control over the CS. Most drivers don't need that level of control, and linux doesn't allow that level of control
<re_irc>
<almindor> do we have any workaround ideas?
<re_irc>
<adamgreig> GrantM11235: if you assume it's permissible to do a custom device tree, you can have just one cs pin on some unused gpio, use normal gpio for the real cs pins, and use that single spidev driver as the 'bus'
<re_irc>
<adamgreig> and then i think it's possible to fully comply with the e-h trait requirements, but i haven't tried this to be sure
<re_irc>
<adamgreig> however it stinks because everything else can happily use the device tree spi devices
<re_irc>
<adamgreig> i couldn't find a way to take over an spidev cs pin as a gpio, but maybe it's possible
<re_irc>
<GrantM11235> IMO, the current spi traits guarantee/require waay more control over the behavior of CS than almost anyone needs. It also makes it pretty much impossible to use hardware CS
<re_irc>
<adamgreig> hardware CS for master-mode SPI seems like it doesn't really serve much purpose?
<re_irc>
<adamgreig> like it takes as much work to write to a gpio register as to a spi control register to change the output state of cs
<re_irc>
<almindor> GrantM11235: do you suggest dropping the CS assumptions from the traits?
<re_irc>
<adamgreig> and you typically only get one "hardware" cs output
<re_irc>
<adamgreig> you wouldn't want the spi peripheral itself to do automatic cs control because it doesn't in general know about transactions, unless it's integrated into dma or something...
<re_irc>
<almindor> adamgreig: i've had trouble with manual pin control due to timing issues
<re_irc>
<adamgreig> and that was resolved using hardware cs?
<re_irc>
<almindor> my MCU for example has CS time configurations, so using the CS pin in HW mode gives certain guarantees
<re_irc>
<adamgreig> how does it know when the last data is sent?
<re_irc>
<adamgreig> do you tell it a number of bytes in advance sort of thing?
<re_irc>
<therealprof> Doesn't it just (de-)assert CS whenever there's data to be sent?
<re_irc>
<adamgreig> in any event any conforming e-h 1.0 driver has to be sure data is completely sent on the bus before de-asserting cs at the end of a transaction, so it's something the hal should take care of for you
<re_irc>
<almindor> there are CS to SCK and SCK to CS delay configs
<re_irc>
<almindor> one SCK period.
<re_irc>
The sckcs field specifies the delay between the last trailing edge of SCK and the deassertion of
<re_irc>
The cssck field specifies the delay between the assertion of CS and the first leading edge of
<re_irc>
SCK. When sckmode.pha = 0, an additional half-period delay is implicit. The reset value is 0x1.
<re_irc>
<therealprof> I think the only standard requirement is that CS has be asserted/deasserted at least (half) a clock cycle before the edge (depending on the mode).
<re_irc>
<GrantM11235> almindor: I'm not sure, maybe
<re_irc>
<GrantM11235> _some_ of the CS assumptions
<re_irc>
<therealprof> adamgreig: What does completely sent mean in this context? You could be doing wild interleaving on the bus, too.
<re_irc>
<adamgreig> which requirements do you think are overkill atm?
<re_irc>
<adamgreig> therealprof: it means whatever events were put in the transaction closure are done, e.g. not just sitting in the fifo still being tx'd
<re_irc>
<newam> almindor: What MCU specifically? Just curious.
<re_irc>
<therealprof> So complete in terms of the buffer which sent by the application...
<re_irc>
<therealprof> +was
<re_irc>
<almindor> adamgreig: yes there's that, if CS is controlled manually you need to implement some sort of "i'm done" detection from the HW side
<re_irc>
<almindor> newam: e310x, hifive1 or redv boards for example
<re_irc>
<adamgreig> how does your hardware control CS automatically though?
<re_irc>
<adamgreig> I mean, how do you tell it "this is the last byte"?
<re_irc>
<adamgreig> is it just a race to keep the FIFO full, or is it by the DMA finishing a buffer, or you pre-load a number of bytes, or..?
<re_irc>
<therealprof> adamgreig: I think they go by data in the transmit buffer.
<re_irc>
<adamgreig> is it deep? usually the buffer's just a few bytes, but I guess you can just hope to keep it non-empty until finished, and if you set up a dma transfer that would ensure it
<re_irc>
<therealprof> If you use DMA, it'll be kept full. 😉
<re_irc>
<adamgreig> it seems like you could use such a hardware cs to implement the e-h 1.0 trait, though, so long as you only allowed one device on the bus
<re_irc>
<adamgreig> i mean, maybe, but it's not guaranteed, dma could stall waiting for bus access
<re_irc>
<almindor> there's a watermark for the tx buffer you can use and then reading back also guarantees that tx fifo side is done IIRC
<re_irc>
<therealprof> If the buffer runs empty, the hardware will automatically deassert CS and if you fill it it'll start over.
<re_irc>
<GrantM11235> I believe that there are devices that don't care at all if cs is de-asserted temporarily during a transaction, as long as it doesn't happen in the middle of a word
<re_irc>
<adamgreig> I think pretty much everything i've seen resets the internal state machine when cs is deasserted, how else do you frame commands?
<re_irc>
<adamgreig> unless you have some other signal for that, of course
<re_irc>
<adamgreig> but yea, I appreciate all kinds of spi devices exist
<re_irc>
<adamgreig> but it certainly seems common for devices to not permit cs to be deasserted in the middle of a transaction
<re_irc>
<adamgreig> almindor: does it have multiple hardware cs outputs?
<re_irc>
<almindor> in general I think it's defined as "CS assets can only happen out of frames" and frames are usually 8bit
<re_irc>
<almindor> yes, 3
<re_irc>
<adamgreig> neat
<re_irc>
<almindor> i drove 2 displays with it at the "same time"
<re_irc>
<adamgreig> I wonder if the hal could implement the e-h 1.0 trait using the three hardware cs pins and give you three SpiDevices basically, or something like that
<re_irc>
<adamgreig> hmm
<re_irc>
<almindor> well technically, the issue is in how we codify the requirements
<re_irc>
<adamgreig> I guess the problem is that the user-provided closure might block without transmitting data
<re_irc>
<adamgreig> and then your hardware would deassert cs and reassert it later
<re_irc>
<adamgreig> and the requirement on the transaction method is clear that that's not permitted
<re_irc>
<almindor> for exclusive devices it's trivial, CS is optional and should be handled on the "which pins did you give me here" compile time
<re_irc>
<almindor> for shared a CS control is required though...
<re_irc>
<almindor> we could make that optional on the HAL level though
<re_irc>
<GrantM11235> almindor: what happens when you do that? does it interleave the transactions, or does it wait for one to finish first?
<re_irc>
<almindor> GrantM11235: well thing is this MCU is single core, so it's time shared, I just sort of split the ops myself between the two displays to get a "at the same time" looking effect. But the current e-h abstraction does allow that nicely, I j ust end up having "display1, display2" to work with
<re_irc>
<almindor> it does have to reconfigure the spi bus each switch though
<re_irc>
<eldruin> due to timing differences or was there a problem with the abstraction?
<re_irc>
<almindor> you mean the reconfigure? it's how the sharing works, it's 1 spi bus with up to 3 cs hw controlled lines
<re_irc>
<almindor> I have to switch the modes/speeds etc. for each device as I switch them. This is handled by the hal of course
<re_irc>
<adamgreig> ah cool, I didn't realise the current hal is already using the hardware CS
<re_irc>
<almindor> it can :D
<re_irc>
<adamgreig> so technically if the user closure just blocks for a few milliseconds the hardware cs will de-assert in the middle of the "transaction"?
<re_irc>
<adamgreig> or does start_frame() hold cs low?
<re_irc>
<adamgreig> ah it does, cool
<re_irc>
<adamgreig> so in your case the e-h 1.0 spi trait works ok for the hal, even with hardware cs?
<re_irc>
<almindor> yes, and the nice bonus of not having to bother with manual CS -> SCK clock delays
<re_irc>
<almindor> i suspect there are MCUs where this might not be possible if the CS is handled in some more autonomous way
<re_irc>
<adamgreig> and in principle a user could still use a plain gpio for cs and some other locking mechanism that provides SpiDevice over your SpiBus, if they needed >3 CS pins or whatever?
<re_irc>
<almindor> yes, you can do that now by using Spi::from(pins) where pins don't contain a CsPin
<re_irc>
<almindor> i mean in the e310x hal specifically
<re_irc>
<almindor> you make the bus and then the devices giving them the cs pin
<re_irc>
<almindor> for shared though right now IIRC the cs pin is a requirement
<re_irc>
<almindor> but that's just specific to this hal implementation it's not an abstraction requirement
<re_irc>
<GrantM11235> What about per-word auto CS? Do people use that? I assume so, because I don't know why else they would put it in chips
<re_irc>
<almindor> basically you either do Bus from (miso, mosi, sck, CSx) and get a exclusive device only bus, or you do a Bus from (miso, mosi, sck) and then create shared devices with CSx each (miso is always optional)
<re_irc>
<adamgreig> and in the second case it's specific hardware CS pins?
<re_irc>
<almindor> you mean assert, send word, de-assert, re-asset, send word, de-assert but in one device send?
<re_irc>
<adamgreig> but in the first case you could then use some other library to get shared devices using gpio cs pins
<re_irc>
<therealprof> So I just checked STM documentation. CS is asserted as soon as SPI is enabled and deasserted when disabled. There's a pulse mode which allows NSS to toggle after each frame.
<re_irc>
<almindor> adamgreig: yes in iof setup atm. but we can implement manual output pin ones too
<re_irc>
<adamgreig> therealprof: usually in that mode you then write the cs control bit on spi to enable/disable if you want to leave spi enabled, or yea just enable/disable spi i guess works
<re_irc>
<almindor> GrantM11235: for per-word CS re-asserts just use separate writes
<re_irc>
<almindor> although IIRC there's a config in the e310x for that in the HW control setup, I think I had to use that once for a device that wanted it
<re_irc>
<GrantM11235> I know you can do it in software, I'm wondering if there is any reason to support doing it in hardware
rardiol has joined #rust-embedded
<re_irc>
<almindor> there are some funny SPI peripherals with odd CS use cases
<re_irc>
<jannic> Looks like there is also something called "Texas Instruments synchronous serial frame format" which pulses CS high during the MSB to announce that another byte will follow.
<re_irc>
<almindor> I think the max usb host chip did that, but i might be wrong
<re_irc>
<jannic> (Found that in the rp2040 datasheet - no idea if anybody actually uses it)
<re_irc>
<adamgreig> the stm32 spi also supports that weird TI thing
<re_irc>
<therealprof> adamgreig: No, in this case you have the choice of software management, in which case CS is a regular GPIO. Or you use hardware management, then you can only controll whether you're using CS as input (multi-master/slave mode) or output. The only way to control the output is via SPI enable.
<re_irc>
<therealprof> * control
<re_irc>
<therealprof> adamgreig: Indeed. Then the CS pulse mode is not available.
<re_irc>
<almindor> in my MCU case you can tell the HW controller to re-assert via a config IIRC. I suspect this might not be available everywhere though
<re_irc>
<almindor> maybe we should document all these cases so hals can expose what they support in each mode
<re_irc>
<adamgreig> therealprof: iirc you can just toggle SSM or SSOE etc to control CS while SPI is enabled
<re_irc>
<adamgreig> anyway
<re_irc>
<adamgreig> SPI 🙃
<re_irc>
<adamgreig> at least in principle the "pulse cs for every byte" can be done using the current e-h trait, but the TI mode cannot (I guess specific HALs could expose this option)
<re_irc>
<adamgreig> and it's not clear what linux support could look like at all
<re_irc>
<adamgreig> so, maybe a little more exploration of use cases for both hardware support and talking to weird devices is worthwhile
<re_irc>
<therealprof> adamgreig: Maybe that's possible. According to the docs this is the bit to use to select input or output mode. 😅
<re_irc>
<GrantM11235> adamgreig: I don't think so, doesn't the current trait specify that CS stays active for the whole transaction?
<re_irc>
<almindor> just so I understand the linux situation better, linux gives you a "device" already with CS hidden behind it atm with no bus access?
<re_irc>
<almindor> GrantM11235: if it does it's just a documentation (which should be changed) coz I can configure mine (as a user) to not do so
<re_irc>
<adamgreig> yea, but you can do a single word write per transaction
<re_irc>
<adamgreig> almindor: yea
<re_irc>
<adamgreig> you can enqueue one or multiple transfers which all execute with CS asserted
<re_irc>
<adamgreig> you can disable it changing CS, but there's no manual CS control
<re_irc>
<therealprof> almindor: There're tons of different usecases though. Like parallel ganged, etc. Going to be a big document.
<re_irc>
<GrantM11235> adamgreig: Oh, you mean in software? I thought you meant supporting hardware pulsed cs
<re_irc>
<adamgreig> and the abstraction is indeed device-level, not bus+devices or bus or anything
<re_irc>
<adamgreig> GrantM11235: sorry yea, the trait doesn't have anything for cs-per-word but a driver for a device that needs it can still be written using the trait, albeit possibly inefficiently
<re_irc>
<GrantM11235> adamgreig: You can _ask_ it to leave cs active between system calls, but if something else needs to use the bus in the mean time, it will deassert cs
<re_irc>
<almindor> thing is.. you can configure HW SPI in very varied ways on some MCUs. i don't think our abstraction should dictate how they perform. So I'm for loosening and maybe providing some sort of expected defaults (e.g. assert per transfer by default)
<re_irc>
<jannic> What about specifying some kind of soft requirements. Implementations should follow them if the hardware allows it, and must document if the implementation does something else?
<re_irc>
<almindor> right now I can break the CS invariant by just changing the SPI bus config struct when I construct mine and it's using the traits
<re_irc>
<adamgreig> GrantM11235: the "cs_change" parameter? i thought that was about deasserting it between multiple transfers in one syscall or something...
<re_irc>
<adamgreig> i don't know much about spidev really 😅
<re_irc>
<GrantM11235> It does that too. It changes meaning depending on if it is the last transfer or not
<re_irc>
<almindor> IMO drivers should document their expectations, not the other way around
<re_irc>
<almindor> the hal should just provide some sane defaults
<re_irc>
<almindor> there will be drivers with weird CS expectations that some HW cannot handle, without manual CS specific operation
<re_irc>
<adamgreig> the objective is to provide a baseline that drivers can target and know should work on anything implementing the trait, though
<re_irc>
<adamgreig> on the whole we probably can't let drivers control the CS pin, if that's needed they should probably take an OutputPin instead?
<re_irc>
<GrantM11235> Yeah, otherwise we might as well just have a single "DoAThing" trait and tell everyone to read the docs to find out what that thing is
<re_irc>
<almindor> IMO if we do a "cs asserts for the whole data transfer" default with "see your SPI config/constructor for additional options" should be good enough for the HW controlled use cases
<re_irc>
<GrantM11235> IMO, the current trait is perfect for low level usage with software CS
<re_irc>
<almindor> for SW CS control, I'm not sure you'd have to tell the HAL somehow what you expect
<re_irc>
<jannic> So it would be allowed to break the "cs asserts for the whole data transfer" contract for some configurations, while still implementing the e-h traits?
<re_irc>
<adamgreig> it's not like it's illegal, we can't stop you, but i don't think we should permit it in the e-h docs, because then driver authors can't rely on it and probably need to
<re_irc>
<adamgreig> the e310 driver manages to use hardware cs without possibly deasserting cs in the middle too
<re_irc>
<almindor> well this is already possible in e310x-hal even exposed via the BusConfig
<re_irc>
<almindor> i don't think there's a good non-complicated compile time way to limit that
<re_irc>
<GrantM11235> I think we should make a distinction between interesting hardware CS and "basically just a gpio" style hardware CS
<re_irc>
<almindor> the default holds tho, if you need specifics like re-asserts per byte, just make the config, you're the user
<re_irc>
<almindor> in other words I don't think the abstraction should limit the less standard configurations on the abstraction level
<re_irc>
<adamgreig> perhaps "cs will remain asserted during the transaction unless the end user has specifically configured otherwise"?
<re_irc>
<jannic> adamgreig: I'm not sure if that isn't too restrictive. Of course it's the safest approach in the sense of "if it compiles, it works". But it would prevent to use the traits for cases where the HW requirements are less strict or different.
<re_irc>
<adamgreig> so driver authors can rely on it knowing that if it breaks it's because the end user did something specific, not just that the hal had a hard time implementing the trait
<re_irc>
<GrantM11235> If you aren't going to do what the abstraction says, why use the abstraction?
<re_irc>
<almindor> GrantM11235: but I am, I'm just unblocking you from using it with some funky peripheral for which your MCU has control settings that'd work
<re_irc>
<adamgreig> what I'd want to avoid is HALs where it's not possible that CS remains asserted throughout transaction, but HALs that optionally provide some weird extra non-default configuration doesn't seem so bad
<re_irc>
<adamgreig> the important thing is that they do _offer_ the conformant implementation, so the driver _could_ work
<re_irc>
<almindor> yes defaults should reflect the abstraction
<re_irc>
<almindor> I think 90% or more of devices work with the base CS assumption, but there are the few that need funky setups. we shouldn't block device drivers out for them. I don't see a good way to compile-time check their requirements though
<re_irc>
<GrantM11235> I kinda regret derailing us with talking about hardware cs, because I am realizing that I don't actually care about hardware cs at all lol
<re_irc>
<adamgreig> yea, short of a bunch of weird new SPI traits
<re_irc>
<jannic> If I understand the datasheet correctly, rp2040 also has the issue that it would de-assert CS if the tx fifo became empty mid-transaction.
<re_irc>
<adamgreig> don't want CSPerWordSPI or TIModeSPI really
<re_irc>
<adamgreig> I guess CSPerWordSPI could be a default-provided but ugh
<re_irc>
<almindor> we can't abstract our way into making incompatible MCUs work with exotic SPI peripherals :D
<re_irc>
<adamgreig> jannic: yea, so I guess atm you'd have to use gpio for cs on the rp2040, but you could maybe have a config mode that uses the hardware CS but notes it might break some drivers
<re_irc>
<adamgreig> (unless it has some setting bit to hold CS asserted even if the tx fifo becomes empty, like the e310 seems to)
<re_irc>
<almindor> on SW CS side, I think we'd want some sort of config of the CS behaviors so hals can implement that properly given an OutputPin instead of a IOF
<re_irc>
<jannic> IIRC you can override the pin manually. But that would essentially not be different from just configuring it as a GPIO.
<re_irc>
<almindor> there are two ways to use a CS pin in SW right?
<re_irc>
<adamgreig> how do you mean?
<re_irc>
<almindor> the hal can use it with the device, or you can ignore it on the hal side and then use it on the driver end
<re_irc>
<adamgreig> oh, yea
<re_irc>
<adamgreig> the recommendation is for the hal to not bother if it's just using gpio
<re_irc>
<almindor> it breaks the limitations though
<re_irc>
<adamgreig> > HALs may additionally implement SpiDevice to take advantage of hardware CS management, which may provide some performance benefits. (There’s no point in a HAL implementing SpiDevice if the CS management is software-only, this task is better left to the HAL-independent implementations).
<re_irc>
<almindor> e.g. the CS pin can be set wrong and the hal has no idea
<re_irc>
<adamgreig> "wrong" how?
<re_irc>
<adamgreig> so long as it's an OutputPin it should do the trait thing, right?
<re_irc>
<almindor> well maybe the driver forgot to deassert
<re_irc>
<adamgreig> which driver?
<re_irc>
<almindor> oh you're talking about the case where CS is provided to the HAL
<re_irc>
<adamgreig> oh, hang on
<re_irc>
<almindor> I meant the case where the HAL ignores the CS and it's directly used by the driver
<re_irc>
<adamgreig> sorry, there's sort of a third case
<re_irc>
<adamgreig> the driver shouldn't ever be given a CS OutputPin
<re_irc>
<almindor> agreed
<re_irc>
<adamgreig> but instead some third crate like shared_bus can be given an ExclusiveBus and a bunch of OutputPins and it can make SpiDevices by using some sort of lock
<re_irc>
<almindor> so that means though, that we need the HALs to allow users to describe the CS usage in SW mode (e.g. assert behavior between bytes)
<re_irc>
<adamgreig> assert-between-bytes atm would be the driver doing lots of small transactions, or the HAL having a hardware CS mode for it
<re_irc>
<adamgreig> but instead some third crate like shared_bus can be given an SpiBus and a bunch of OutputPins and it can make SpiDevices by using some sort of lock
<re_irc>
<almindor> well what if the MCU doesn't support that right?
<re_irc>
<almindor> you can still do it SW side but the hal has to implement it then
<re_irc>
<adamgreig> then the driver has to do lots of small transactions
<re_irc>
<adamgreig> the hal isn't touching CS unless you're using hardware CS
<re_irc>
<GrantM11235> I would be happy to say "we only support software cs (and hardware cs that is sufficiently similar to software cs)" _except_ for the linux problem
<re_irc>
<almindor> just so i understand the SW CS use case here, if you use SW CS with the hal and give a GPIO pin to a "Device" it'll drive low pre transaction and drive high post transaction correct?
<re_irc>
<GrantM11235> The driver doesn't do that, the bus-sharing-thing does
<re_irc>
<adamgreig> if you're using SW CS, the general idea is you give an SpiBus and 1+ OutputPins to some third crate that provides the SpiDevice and CS management, and yes it will drive low before transaction and high afterwards
<re_irc>
<almindor> yes, the "device"
<re_irc>
<almindor> ok so for funky re-asserts-per-byte you'd have to split it manually in the driver then
<re_irc>
<almindor> there wouldn't be a "please do this for me hal" option
<re_irc>
<adamgreig> yea indeed
<re_irc>
<adamgreig> I think as it stands the driver would just have to split into lots of word sized transactions
<re_irc>
<almindor> ok, SGTM
<re_irc>
<adamgreig> conceivably a HAL could offer a mode where it does hardware CS with that toggling, and a driver that knew about it could have an option to not do splitting and rely on the HAL doing it, but it wouldn't be compile time checked
<re_irc>
<adamgreig> and seems a bit cursed lol
<re_irc>
<adamgreig> thankfully the TI mode thing seems even rarer
<re_irc>
<adamgreig> so.. we've way overshot the meeting time lol
<re_irc>
<almindor> sorry :D
<re_irc>
<GrantM11235> adamgreig: your welcome lol
<re_irc>
<adamgreig> sadly the spidev linux issue is also troublesome
<re_irc>
<almindor> i gtg too, late for lunch
<re_irc>
<adamgreig> yea i have to run, but maybe let's continue discussion next week or so, it would be good to have more confidence in the spi traits before we publish e-h 1.0
<re_irc>
<adamgreig> it would be sad if it turns out they just can't be done on spidev but maybe we can find some suitable workaround....
<re_irc>
<adamgreig> right, thanks everyone 👋
<re_irc>
<GrantM11235> If it is impossible to impl the e-h traits with spidev, but it is easy to impl an spidev style interface with the e-h traits, maybe we should also have an spidev style trait with a default impl for anything that impls the e-h traits
<cr1901>
^This seems like a very reasonable compromise to me
<re_irc>
<almindor> one thing I'd love to see in the end is a unification of the "SPI bus options" for things like we discusse d(e.g. assertion logic, delays to SCK etc.) with an extensible HW set (something like "struct<HWOPTS> { cs_assert_logic, ..., additional_hw_opts: HWOPTS }" so that even the SW control can be configured (with the same defaults we discussed of course).
<re_irc>
<almindor> this way it won't feel so disjoint between hw and sw CS setups
<re_irc>
<jannic> I wonder if the linux developers chose that model using a predefined list of transfers (SPI_IOC_MESSAGE) because they knew that there is some hardware where CS gets cleared as soon as the tx buffer is empty. Its less flexible than the current e-h transaction, but it should be easier to implement it correctly.
<re_irc>
<GrantM11235> I assume they did it that way because it prevents misbehaving userspace programs from locking the entire bus