<re_irc>
<@rmja:matrix.org> : Thanks, I will have a look!
<re_irc>
<@jamesmunns:beeper.com> The other typical answer is to use environment variables at build time and the "cfg!()" macro, with parsing in a const-fn
<re_irc>
<@jamesmunns:beeper.com> (this is what defmt/defmt-rtt does, for example)
<re_irc>
<@rmja:matrix.org> Got it. Thanks! I have seen toml-cfg before and at that time I said to myself that I should remember it.
IlPalazzo-ojiisa has quit [Ping timeout: 250 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
lehmrob has quit [Ping timeout: 240 seconds]
lehmrob has joined #rust-embedded
fooker has quit [Ping timeout: 265 seconds]
fooker has joined #rust-embedded
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
<re_irc>
<@halfbit:matrix.org> If it gets really crazy there are some kconfig related crates, possibly useful if you get to that level of build knobs that can be tweaked
lehmrob has quit [Ping timeout: 264 seconds]
<re_irc>
<@halfbit:matrix.org> : continuing thoughts from the discussion the other day... if I want to write a driver against the traits in e-h, I think I'd need to be able to configure clock, phase, mode, etc
<re_irc>
<@dirbaio:matrix.org> that's considered out-of-scope for now
<re_irc>
<@dirbaio:matrix.org> the user is supposed to configure the SPI correctly before handing it to the driver
<re_irc>
<@halfbit:matrix.org> Shouldn't that include any potential delays as well?
<re_irc>
<@halfbit:matrix.org> how is a delay different
<re_irc>
<@ryan-summers:matrix.org> Spi operation mode is generally static for an entire bus (if it changes, you probably did your hardware wrong). Delays are not static for any given device
<re_irc>
<@adamgreig:matrix.org> I could easily imagine two devices that share a bus needing different SPI modes, and there's not really any way to do that right now, but I think the main difference is that the delays happen arbitrarily in between operations in a transaction, they're not something you could ever configure ahead of time
<re_irc>
<@ryan-summers:matrix.org> Device drivers get a "spi bus". What's the value of exposing a mechanism to change the SPI bus operating mode? How does that impact shared-bus systems where multiple devices are on the bus?
<re_irc>
<@adamgreig:matrix.org> they're not like "always delay between asserting CS and sending first byte", they're "this particular transaction needs this delay after the second byte, this other transaction in the same driver doesn't have any delay", etc
<re_irc>
<@halfbit:matrix.org> Linux and Zephyr seem to think so
<re_irc>
<@ryan-summers:matrix.org> I've never seen a sensible design that had multiple SPI operating modes on the same bus
<re_irc>
<@ryan-summers:matrix.org> Just because linux thinks it's a good idea doesn't mean it is
<re_irc>
<@ryan-summers:matrix.org> Linux is a whole different system than embedded
<re_irc>
<@adamgreig:matrix.org> we don't have mode/clock because we currently consider all "setup" to be out of scope, the same as we don't have baud rate setting for serial, but "delay inside a transaction" isn't "setup"
<re_irc>
<@adamgreig:matrix.org> : why not? you could just have two different chips that need different modes, and since only one is selected at a time they shouldn't care at all what happens to the other one
<re_irc>
<@adamgreig:matrix.org> even different clock speeds too
<re_irc>
<@halfbit:matrix.org> this isn't i2c
<re_irc>
<@halfbit:matrix.org> you don't have deal with the lowest common denominator :-)
<re_irc>
<@adamgreig:matrix.org> it's hard enough getting consensus on a sensible trait for just the data exchange portion, and having it seems very valuable and lots of drivers have been written that work amazingly well between different platforms, but maybe one day it would be sensible to add spi mode and perhaps uart baud and so forth to the hal
<re_irc>
<@adamgreig:matrix.org> but i don't think that has anything to do with delay in the spi transactions, it's just a different class of thing to me
<re_irc>
<@ryan-summers:matrix.org> : You could, but like I mentioned, I'd generally say this is a hardware defect that's causing downstream firmware work that can usually be avoided by selecting compatible ICs or using multiple SPI buses. Yeah, there's cases where that's not _always_ possible, but I'd argue that's a pretty rare exception
<re_irc>
<@adamgreig:matrix.org> : I mean, it's true that I can't recall ever seeing such a setup in practice...
<re_irc>
<@ryan-summers:matrix.org> The other case is hobbyist setups where people are just plugging wires into breadboards etc
<re_irc>
<@adamgreig:matrix.org> but I don't see why it couldn't be done and I don't think I'd especially reach to avoid it, if I happened to have two SPI devices I wanted on the same bus and the only reason not to was one was mode 1 and the other mode 3 or whatever
<re_irc>
<@ryan-summers:matrix.org> The only time I've heard of different SPI modes on the same bus was literally because someone messed up the hardware design and it was too late to fix
<re_irc>
<@adamgreig:matrix.org> possibly the nuisance of changing bus settings every time you change which device you talk to is a good reason to avoid it, heh
<re_irc>
<@ryan-summers:matrix.org> It also makes implementation harder on HAL maintainers
<re_irc>
<@adamgreig:matrix.org> certainly it's not something that's really supported with any of the ways of sharing an SpiBus at the moment
<re_irc>
<@ryan-summers:matrix.org> And some buses don't like changing operation modes until you disable the peripheral etc. which might conflict with DMA setups? But I guess that's always the case with a shared SPI setup
<re_irc>
<@halfbit:matrix.org> apparently this same argument for not having a delay operation doesn't hold
<re_irc>
<@adamgreig:matrix.org> why do you think the delay is like the bus mode or clock rate?
<re_irc>
<@ryan-summers:matrix.org> Do you have a specific usecase in mind Tom B ? Most of the e-h design is driven from hardware requirements and/or projects
<re_irc>
<@adamgreig:matrix.org> it's not something you'd be configuring in hardware registers or something you can set up ahead of time
<re_irc>
<@halfbit:matrix.org> because the hardware supports a delay option in some cases with a configuration register?
<re_irc>
<@adamgreig:matrix.org> (I appreciate it does make implementation harder on HAL maintainers)
<re_irc>
<@adamgreig:matrix.org> are you sure that's the same sort of delay being talked about here?
<re_irc>
<@adamgreig:matrix.org> usually hardware delay options are like "time between CS assert and first clock edge"
<re_irc>
<@ryan-summers:matrix.org> Tom B: That's not what the new proposed delay implementation is intended to support though
<re_irc>
<@adamgreig:matrix.org> but what's being discussed is "arbitrary (much longer) delays between specific bytes in a transaction"
<re_irc>
<@ryan-summers:matrix.org> The delay in question is "Write 1 SPI byte, wait for X seconds, write second byte"
<re_irc>
<@ryan-summers:matrix.org> For e.g. the CC1200 radio, which has a funky RESET strobe followed by a required delay then read
<re_irc>
<@adamgreig:matrix.org> though annoyingly I suppose the cc1200 still wouldn't be easily supported by this change to SpiDevice because of needing to drive mosi as io (presumably without clock pulses)?
<re_irc>
<@ryan-summers:matrix.org> Sorry, I realize I was being super standoffish. Been a long day and I'm somewhat stressed, not trying to be an ass, genuinely curious if you have a use
<re_irc>
<@ryan-summers:matrix.org> : I thought it was the CC1200 that drove MISO to a certain point? I don't recall though, but I remember he said you could treat it like a standard SPI operation
<re_irc>
<@ryan-summers:matrix.org> But there was a separate power-on-reset, enable-xtal process that was funky using the GPIOs as IOs
<re_irc>
<@adamgreig:matrix.org> ah, I'm not clear on the details for that one. would be interesting to see if it can be made to work with just the new delay operation in the enum then.
<re_irc>
<@adamgreig:matrix.org> the real villain is IC companies making these bizarro SPI interfaces
<re_irc>
<@ryan-summers:matrix.org> It _sounded_ like it should
<re_irc>
<@ryan-summers:matrix.org> Eh., I kinda get it for the CC radios, but I agree
<re_irc>
<@ryan-summers:matrix.org> Been using the CC1101 for the last 5 years on a project, and man those radios are complex
<re_irc>
<@ryan-summers:matrix.org> Pretty cool that you can stuff all the "give me wireless comms" into a single chip though
<re_irc>
<@halfbit:matrix.org> That looks like some gpio timing that you need to work out
<re_irc>
<@halfbit:matrix.org> and has zero to do with spi
<re_irc>
<@ryan-summers:matrix.org> You can actually do it as a SPI transaction by constantly reading the SO pin for 0x00 or 0xFF apparently
<re_irc>
<@ryan-summers:matrix.org> That's what the person who brought this up said they were doing with the e-h closure-based SPI impl
<re_irc>
<@halfbit:matrix.org> I mean, I can also try to make spi work as a neopixel signal line...
<re_irc>
<@ryan-summers:matrix.org> But this was actually brought up as a fact that the new API doesn't let you read N bytes within a single transfer, where N is unknown before the transfer starts
<re_irc>
<@ryan-summers:matrix.org> So this is a bad example for delays
<re_irc>
<@adamgreig:matrix.org> the ADS1256 is 50 main clock cycles delay, while the SPI clock can be up to 1/4 of the main clock, so up to 12 SPI clock cycles wait
<re_irc>
<@ryan-summers:matrix.org> Like, you can't loop and keep reading a byte until it finally resolves to some value with the new SPI API
<re_irc>
<@adamgreig:matrix.org> whether there's some way around that or not, dunno
<re_irc>
<@ryan-summers:matrix.org> +(within the same CSn assertion transaction)
<re_irc>
<@adamgreig:matrix.org> if we ideally find that actually adding a Delay operation doesn't help very much (maybe it's not enough/not useful for cc1100, and maybe there's some workaround for ads1256, etc etc), I think we'd be happy to not include it, that's why it wasn't there to start with
<re_irc>
<@adamgreig:matrix.org> the discussion came about because a few people had already asked for it in order to support their devices
<re_irc>
<@amb12:matrix.org> The chip I'm interested in needs to have a 16-bit address sent, then a short delay (which varies depending on the mode the chip's in) then further 16-bit transactions. You can't pre-configure the delay, unless you set it to the maximum which is uselessly long for most operations. And you can't raise the CS line during any of that.
<re_irc>
<@ryan-summers:matrix.org> Which chip is that?
<re_irc>
<@ryan-summers:matrix.org> Was that the CambridgeIC one that was linked?
<re_irc>
<@amb12:matrix.org> Yeah, that's the one.
<re_irc>
<@ryan-summers:matrix.org> That sounds truly cursed and could only be done with the closure-based API from what I understand
<re_irc>
<@amb12:matrix.org> Not necessarily.
<re_irc>
<@amb12:matrix.org> You know the delay before asserting the CS line. Just not at initial setup.
<re_irc>
<@ryan-summers:matrix.org> Oh sorry, I thought the delay depended on the response for some reason
<re_irc>
<@ryan-summers:matrix.org> So I thought you had to calculate the delay based on the response during the first 16-byte address (like the CC1101 radio always clocks out the state in the first byte)
<re_irc>
<@amb12:matrix.org> Ha - thankfully not.
<re_irc>
<@ryan-summers:matrix.org> Yeah that's doable with the current API + Delay then
<re_irc>
<@amb12:matrix.org> Indeed.
<re_irc>
<@amb12:matrix.org> It has some other cases where it's useful to poll the state of the MISO line while CS is low. But I'm not pushing that one!
<re_irc>
<@halfbit:matrix.org> lpspi has a native delay between transfer hardware option
<re_irc>
<@halfbit:matrix.org> wouldn't that solve this?
<re_irc>
<@ryan-summers:matrix.org> delay between transfer is not what this is though, this is a delay within a single transfer
<re_irc>
<@ryan-summers:matrix.org> Between specific bytes from what I understand
<re_irc>
<@ryan-summers:matrix.org> i.e. interword delay, only in _some_ cases
<re_irc>
<@amb12:matrix.org> That's right (for me) - the delay is only between the first and second word. All others can go as fast as possible (within reason).
<re_irc>
<@halfbit:matrix.org> someone grab a rubber hose and find the rtl author :-)
<re_irc>
<@halfbit:matrix.org> +This part seems cursed
<re_irc>
<@whitequark:matrix.org> i feel like violence isn't an appropriate reaction to "poorly written RTL"
<re_irc>
<@rmja:matrix.org> Regarding the spi conversation, would it be possible to simply have a SpiOperatipn::Delegate where one could provide a closure with access to the bus?
<re_irc>
<@halfbit:matrix.org> : I jest, truly
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
<re_irc>
<@thejpster:matrix.org> Arm are talking more about running CI/CD on Arm Virtual Hardware. Seems they now support some actual chips not just the generic Arm SoCs you can’t actually buy.
<re_irc>
<@ryan-summers:matrix.org> I wonder if the raspberry Pi / SBC market is driving this, cause it's hard to develop apps for that market right now
<re_irc>
<@ryan-summers:matrix.org> Because GH doesn't have native arm runners
<re_irc>
<@ryan-summers:matrix.org> Just recently had to spin up a google-cloud-platform, expensive ARM build machine just to get a release for forged.dev on arm64
<re_irc>
<@dngrs:matrix.org> "arm runner" sounds like a fun sport
<re_irc>
<@thejpster:matrix.org> With funding I’m pretty sure I could get cortex-m tested on these virtual hardware in CI.
<re_irc>
<@thejpster:matrix.org> Given this is about IoT I think it’s more Cortex M Testing than Cortex A Testing.
<re_irc>
<@thejpster:matrix.org> You can get a Aarch64 Graviton VM from AWS no problem.
<re_irc>
<@thejpster:matrix.org> Not sure of the price compared to GCP. It’s AWS so who knows.
<re_irc>
<@thejpster:matrix.org> And Rust is a great cross compiler, so I think it’s more of a testing question.
GenTooMan has quit [Read error: Connection reset by peer]
GenTooMan has joined #rust-embedded
<re_irc>
<@grantm11235:matrix.org> rmja: No, because that would be impossible to implement using the linux userspace api (which was the entire reason for switching from the closure api to the list-of-transactions api in the first place)
<re_irc>
<@rmja:matrix.org> : What if the delegate is not async? Say, if the bus is really fast and we already have obtained the bus lock in an async way
<re_irc>
<@jannic:matrix.org> What about returning an OperationNotSupported error if such an operation is used on Linux?
<re_irc>
Of course that's not perfect as it can't be detected at compile time. But it could be a viable compromise?
<re_irc>
<@bugadani:matrix.org> Is the problem the closure or bus access in it? Feels to me like inserting a delay doesnt need the bus
<re_irc>
<@bugadani:matrix.org> I may be missing context, though
<re_irc>
<@adamgreig:matrix.org> the closure is hard because linux's spi api is basically "give linux a batch of things to do and it will assert cs, do them, then deassert cs"
<re_irc>
<@adamgreig:matrix.org> the closure requires running arbitrary code in between, which linux doesn't really support
<re_irc>
<@dirbaio:matrix.org> Linux wants to allow different processes to use different devices on the same SPI bus.
<re_irc>
If each process did "assert CS, do transfer 1, do transfer 2, deassert CS", it could have race conditions like:
<re_irc>
process 1: assert CS1
<re_irc>
process 2: assert CS2
<re_irc>
process 1: do transfer 2
<re_irc>
process 1: do transfer 1
<re_irc>
process 2: do transfer 1
<re_irc>
process 1: deassert CS1
<re_irc>
process 2: do transfer 2
<re_irc>
process 2: deassert CS2
<re_irc>
which is wrong. different transfers from different processes cna get interleaved, corrupting stuff.
<re_irc>
Therefore, the linux kernel wants to manage entire transactions. You submit an array of transfers to the kernel, the kernel does "assert CS, do all transfers, deassert CS".
<re_irc>
This way, the kernel can ensure different transactions from different processes don't interleave.
<re_irc>
<@dirbaio:matrix.org> you CANNOT run arbitrary code between different transfers within the same transaction
<re_irc>
<@rmja:matrix.org> It has a "cs_change" field - can that be used to hold cs between ioctl calls?
<re_irc>
<@dirbaio:matrix.org> no
<re_irc>
<@adamgreig:matrix.org> so, the only thing you could do instead is manage CS yourself, as a GPIO, but then you need to be using CS pins that haven't been set up in the device tree as part of an spidev device, and you have to be very sure nothing else will use the same bus at the same time either
<re_irc>
<@dirbaio:matrix.org> it allows you to do multiple cs assert/deassert within one ioctl. there's no way to hold a cs asserted across ioctls
<re_irc>
<@dirbaio:matrix.org> yeah, if you don't let the kernel manage CS, then you can't share the bus between processes
<re_irc>
<@adamgreig:matrix.org> yea
<re_irc>
<@adamgreig:matrix.org> and it's just convenient that linux does support a delay as one of those operations
<re_irc>
<@adamgreig:matrix.org> if it didn't, we also couldn't add Operation::Delay to the e-h trait
<re_irc>
<@adamgreig:matrix.org> but now the end user has to either pass in a DelayUs provider to whatever's managing the bus, or that thing will probably offer some convenience method to use a dummy delay that doesn't really delay, or panics, or something
<re_irc>
<@adamgreig:matrix.org> I'm trying to avoid thinking about why linux also offers an inter-word delay option :P
<re_irc>
<@rmja:matrix.org> Is my understanding correct that the new "SpiOperation" enum is equivalent to one "spi_ioc_transfer" - in the sense that they can be sent as a batch to the bus arbiter?
<re_irc>
<@dirbaio:matrix.org> yes, that's the goal
<re_irc>
<@dirbaio:matrix.org> the impl can translate the ops into an "spi_ioc_transfer[]" and then submit that in a single ioctl
<re_irc>
<@dirbaio:matrix.org> so they all get executed within the same CS assertion
<re_irc>
<@adamgreig:matrix.org> Operation::Delay would probably map to an ioc_transfer with no data and only a delay_usecs, but yea
<re_irc>
<@dirbaio:matrix.org> hopefully the kerne lcan do that :D
<re_irc>
<@dirbaio:matrix.org> or it can be mapped into setting the delay field for the previous operation
<re_irc>
<@adamgreig:matrix.org> it doesn't say len can't be 0 :P
<re_irc>
<@adamgreig:matrix.org> there might not be a previous operation if the first thing is a delay
<re_irc>
<@dirbaio:matrix.org> it's C 🤷
<re_irc>
<@dirbaio:matrix.org> : ah true, grrr
<re_irc>
<@dirbaio:matrix.org> btw
<re_irc>
<@rmja:matrix.org> That delay_usecs is a delay between the last transfer until cs is deasserted
<re_irc>
<@rmja:matrix.org> Not a between transfer delay
<re_irc>
<@dirbaio:matrix.org> there's a related issue, which is there are devices that need some gap time before asserting CS and the first clock edges, or after the last clock edges and deasserting CS
<re_irc>
<@adamgreig:matrix.org> between the last bit of the present transfer and the start of the next transfer in the array of spi_ioc_transfers
<re_irc>
<@adamgreig:matrix.org> the cs deassertion between transfers is optional
<re_irc>
<@adamgreig:matrix.org> : yea, but that's really a setup issue, like mode and clock speed
<re_irc>
<@dirbaio:matrix.org> kinda
<re_irc>
<@adamgreig:matrix.org> well I suppose it depends if it's hardware or software CS...
<re_irc>
<@dirbaio:matrix.org> it's not _bus_ configuration, because the bus doesn't know about CS
<re_irc>
<@adamgreig:matrix.org> but in any event it's not part of SpiDevice I don't think
<re_irc>
<@dirbaio:matrix.org> in the case of software CS, yes
<re_irc>
<@adamgreig:matrix.org> maybe it's something e-h-bus wants to know about, or the HAL if it's providing SpiDevice for you
<re_irc>
<@dirbaio:matrix.org> it's not part of the SpiDevice trait itself, yes.
<re_irc>
but maybe it's something the SpiDevice impls in EHB should support
<re_irc>
<@dirbaio:matrix.org> if these impls are going to take an "impl Delay", they can
<re_irc>
<@adamgreig:matrix.org> yea, possibly, though again I'd probably have a default constructor that doesn't take an impl delay and doesn't do delays which covers 99% of users
<re_irc>
<@adamgreig:matrix.org> and then sure, the one that needs an "impl Delay" for the "Operation::Delay" could also use it for delaying around CS toggles
<re_irc>
<@rmja:matrix.org> (as a note I figured out how to align my cc1200 driver with the new api, so you should not make any changes to help me out) :)
<re_irc>
<@dirbaio:matrix.org> yeah
<re_irc>
<@dirbaio:matrix.org> so
<re_irc>
<@adamgreig:matrix.org> rmja: the new api without delay, or with delay (but no closure)?
<re_irc>
<@rmja:matrix.org> without
<re_irc>
<@dirbaio:matrix.org> should we add "Operation::Delay", and let impls that don't support it just fail?
<re_irc>
<@adamgreig:matrix.org> I wonder if they should be required to panic or can just not delay or what
<re_irc>
<@dirbaio:matrix.org> or we add a "SpiDeviceWithDelay", that takes a "&mut [OperationWithDelay]"?
<re_irc>
<@adamgreig:matrix.org> oh gory, if I highlight code in firefox github on that linux file that uses hard tabs....
<re_irc>
<@adamgreig:matrix.org> the hard tabs seem to misalign the highlight?
<re_irc>
<@rmja:matrix.org> I like that those platforms should simply ignore the delay:-)
<re_irc>
<@rmja:matrix.org> +silently
<re_irc>
<@adamgreig:matrix.org> sure is simple
<re_irc>
<@rmja:matrix.org> And then maybe let it be "Operation::DelayUs"?
<re_irc>
<@jannic:matrix.org> Sorry if it was discussed before (I'm sure it was...): Why are there separate traits SpiBusRead, SpiBusWrite? I read the docs, "for example a bus with a MISO pin but no MOSI pin". But is that a useful distinction? Yes, it can prevent accidentally passing a SPI device without a configured MISO pin to a driver trying to read from SPI. But it would still be possible to configure some unconnected MISO pin, with the same effect.
<re_irc>
So wouldn't it be simpler to just have a single SpiBus trait providing both read and write functions?
<re_irc>
<@jannic:matrix.org> For an UART, having separate Read and Write traits is useful, as you can have a Read and a Write object for the same UART at the same time, and use them independently. But that's not possible with SPI due to the shared CLK line.
<re_irc>
<@dirbaio:matrix.org> : the use cases discussed were stuff like:
<re_irc>
you might want to abuse write-only SPI to bitbang ws2812b
<re_irc>
you might want to abuse read-only SPI to build a logic analyzer
<re_irc>
<@dirbaio:matrix.org> but yeah, I think I agree that in practice having many traits is not that useful
<re_irc>
<@dirbaio:matrix.org> plus impleenting it in the HAL side (like, implementing only SpiBusRead if you only have MISO) requires annoying typelevel hacks
<re_irc>
<@dirbaio:matrix.org> so Embassy doesn't implement them, for example D:
<re_irc>
<@dirbaio:matrix.org> maybe we should remove them
<re_irc>
<@jannic:matrix.org> You can implement a ws2812b driver based on the SpiBus trait. A logic analyzer as well.
<re_irc>
It's obvious that there are some devices which only use one direction. And it's also obviously useful to be able to get an SpiBus device from the HAL without specifying both MISO and MOSI, if you only need one of them. But I think the added type safety you gain by using two separate traits for those use cases is minimal.
<re_irc>
<@dirbaio:matrix.org> yeah...
<re_irc>
<@adamgreig:matrix.org> Making an spidevice with a dummy pin for miso or mosi seems like it buys you most of the flexibility
<re_irc>
<@adamgreig:matrix.org> Bus*
<re_irc>
<@jannic:matrix.org> Yes. And this is nothing embeded-hal specifies. HALs could still provide separate constructors or completely different types for one-directional SPI busses. They'd just all implement the same trait.
vancz has quit []
vancz has joined #rust-embedded
<re_irc>
<@jannic:matrix.org> .oO( shared SPI bus with MOSI connected to ws2812b while using MISO as a logic analyzer, anyone? )
<re_irc>
<@dirbaio:matrix.org> : get outta here lmao
<re_irc>
<@adamgreig:matrix.org> they're very cute. six pins: v+ v- gnd sck dout ain
<re_irc>
<@adamgreig:matrix.org> * gnd cs
<re_irc>
<@adamgreig:matrix.org> 500ksps and you control the bit depth by how many bits you bother to clock out
<re_irc>
<@adamgreig:matrix.org> aiui it does each successive bit approximation on each new clock cycle
<re_irc>
<@dirbaio:matrix.org> lol! very neat and minimalistic
<re_irc>
<@adamgreig:matrix.org> yea! i used them on an fpga thing once, extraordinarily convenient to use from an fpga really
<re_irc>
<@dirbaio:matrix.org> surprisingly expensive? ~$2 at 10k?
<re_irc>
<@grantm11235:matrix.org> It is kinda nice that "spi: impl SpiDeviceWrite" is self-documenting that you don't need to hook up miso. But it probably isn't worth all the extra complexity
<re_irc>
<@dirbaio:matrix.org> yeah... just look at the diff lol
<re_irc>
<@dirbaio:matrix.org> writing the "SpiDevice" impls in e-h-b kinda made me realize it's too many traits
<re_irc>
<@adamgreig:matrix.org> maybe they were cheaper back then, but I probably didn't care that much
<re_irc>
<@dirbaio:matrix.org> should the "DelayUs" be behind the mutex in "e-h-b" shared impls?
<re_irc>
<@dirbaio:matrix.org> so you need one "DelayUs" per bus, not per Device?
<re_irc>
<@dirbaio:matrix.org> probably yes?
<re_irc>
<@adamgreig:matrix.org> Can't see why you'd want one per device, yea
<re_irc>
<@dirbaio:matrix.org> lazyness of the implementor (me)
<re_irc>
<@dirbaio:matrix.org> sharing it means you have to take "&RefCell<(BUS, DELAY)>" which starts to get ugly
<re_irc>
<@dirbaio:matrix.org> or make another struct
<re_irc>
<@dirbaio:matrix.org> ugh
<re_irc>
<@jannic:matrix.org> Could the delay requirement be a reason for HALs to implement "SpiDevice" and not just "SpiBus"? A HAL usually knows how to do delays, so it could implement "SpiDevice" without requiring the user to provide a delay implementation manually.
<re_irc>
<@dirbaio:matrix.org> maybe
<re_irc>
<@dirbaio:matrix.org> or perhaps a convenience wrapper on the "e-h-b" impls instead of a full impl
<re_irc>
<@walstib-alex:matrix.org> It is a common issue with spi, it should be addressed
<re_irc>
<@dirbaio:matrix.org> llet's see how it fares :D :D
<re_irc>
<@dirbaio:matrix.org> * let's
<re_irc>
<@dirbaio:matrix.org> let's see how it fares :D :D
<re_irc>
<@grantm11235:matrix.org> Does linux support a transaction that starts with a delay, or only has a delay? ie "transaction(&mut [Operation::DelayUs(x)])"?
<re_irc>
<@dirbaio:matrix.org> no idea
<re_irc>
<@dirbaio:matrix.org> probably yes, with a zero-length transfer?
<re_irc>
<@jannic:matrix.org> : linux-embedded-hal implements "SpiBus<u8> for Spidev", and "SpiBus" docs say "HALs *must not* add infrastructure for sharing at the ["SpiBus"] level. User code owning a ["SpiBus"] must have the guarantee of exclusive access."
<re_irc>
So, to implement linux-embedded-hal correctly, you already have to be sure that nothing else will use the same bus at the same time.
<re_irc>
<@dirbaio:matrix.org> > User code owning a [SpiBus] must have the guarantee of exclusive access
<re_irc>
that guarantee can be provided by either code, or the user
<re_irc>
<@dirbaio:matrix.org> "linux-embedded-hal" SpiBus constructor should say something like "you must ensure no other process in the system will try to use this bus concurrently"
<re_irc>
<@jannic:matrix.org> Well there is no "SpiBus" constructor, the struct is "Spidev". So the "Spidev" constructor would have that in its docs.
<re_irc>
<@dirbaio:matrix.org> I guess,y es
<re_irc>
<@dirbaio:matrix.org> * guess, yes
<re_irc>
<@dirbaio:matrix.org> not sure if it's WIP or not
<re_irc>
<@jannic:matrix.org> Which doesn't make too much sense if you only want to use the "SpiDevice" trait...
<re_irc>
<@dirbaio:matrix.org> I think the ideal would be to have two structs, one implementing SpiBus, the other SpiDevice
<re_irc>
<@dirbaio:matrix.org> only the SpiBus one would need the warning
<re_irc>
<@dirbaio:matrix.org> the SpiDevice one would use kernel-managed transactions
<re_irc>
<@jannic:matrix.org> Yes. Implementing "SpiBus" and "SpiDevice" for the same struct is a little bit contradictory.
<re_irc>
<@grantm11235:matrix.org> How did this work in the bad old days when everyone was handling chipselect manually?
<re_irc>
<@dirbaio:matrix.org> no bus sharing 🤷
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<re_irc>
<@vulfe:matrix.org> Hi! I have a newbie question; I have been looking into toying around with using the NVMC on my chip to modify data in flash memory, but I can't figure out how to actually configure it because the constructor that takes the peripheral wants a mutable reference to the storage ("&'static mut [u32])" that I cannot really figure out how to obtain.
<re_irc>
I feel like if I had some working code to reference that implements something similar (i.e. successfully does something similar with a "NorFlash" implementation) it would be pretty helpful. Let me know if I should ask somewhere more specific or if I'm barking up the wrong tree!
<re_irc>
<@dirbaio:matrix.org> nRF?
<re_irc>
<@vulfe:matrix.org> yep!
<re_irc>
<@vulfe:matrix.org> nRF52833
<re_irc>
<@dirbaio:matrix.org> yeah the nrf-hal NVMC API is quite strange
<re_irc>
<@dirbaio:matrix.org> the motivation for the "&'static mut [u32]" is that you can otherwise use NVMC to modify running code itself, or otherwise readonly statics
<re_irc>
<@dirbaio:matrix.org> there's no safe way to obtain it, you have to use "unsafe"
<re_irc>
<@dirbaio:matrix.org> like "slice::from_raw_parts_mut()"
<re_irc>
<@vulfe:matrix.org> I sort of suspected as much
<re_irc>
<@dirbaio:matrix.org> as an alternative, there's the "embassy-nrf" HAL
<re_irc>
<@vulfe:matrix.org> I guess I'll probably try just building it from a raw pointer to the memory address I want first (I am already working in RTIC so I'd prefer not to get too many more moving parts involved), but thanks for calling it out!