ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
emerent has quit [Ping timeout: 256 seconds]
emerent has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
jcroisant has quit [Quit: Connection closed for inactivity]
<JamesMunns[m]> btw, hats off to the `embedded-hal-async` folks making ErrorTypes a re-export of the analogous `embedded-hal` ErrorTypes.
<JamesMunns[m]> It's such a small thing, but makes abstracting over async/blocking *so damn easy*: https://github.com/jamesmunns/max31855-rs/commit/beebbfb932990cb6b626aef3d94214518c70878b
<JamesMunns[m]> tho I just realized the new spi model already handles the CS pin, so I get to go pull that out too :D
crabbedhaloablut has joined #rust-embedded
notgull has quit [Ping timeout: 252 seconds]
<Lumpio-> Is the convention now to add extra methods to SPI...? "spi.read_all" does _not_ sound like it's reading a thermocouple to me...
<JamesMunns[m]> I probably wouldn't (and specifically wouldn't use an extension trait for this), but this is a change to an existing driver.
<JamesMunns[m]> so, I kept it as-is for consistency.
notgull has joined #rust-embedded
Guest7282 has joined #rust-embedded
<Lumpio-> oh all right
<JamesMunns[m]> Do we ever publicly document whether 7-bit i2c address should be left- or right-justified?
<JamesMunns[m]> For example, if an address is:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/VadgfBFfyUWakICgWmasSyzx>)
<Lumpio-> Putting the read/write bit as the LSB was a design mistake
<Lumpio-> If it was the MSB nobody would be tempted to sometimes shift the address and sometimes not
<JamesMunns[m]> I don't disagree, but we should probably have it in the e-hal docs so HAL implementors aren't confused
<JamesMunns[m]> * so HAL/Driver implementors
<M9names[m]> it's almost exclusively those who are writing drivers themselves without doing any research that are impacted.
<M9names[m]> as such, the documentation will almost certainly not help them
<M9names[m]> not disagreeing either, just noting that we'll still get exactly the same issues we currently have (but we'll be able to link to docs)
<M9names[m]> * to docs instead of spending time explaining)
<Lumpio-> JamesMunns[m]: I mean it was a design mistake in I2C :) I don't think we're going to be fixing that any time soon.
<Lumpio-> Should definitely be documented.
marmrt[m] has joined #rust-embedded
<marmrt[m]> Will they fix it in the I3C release?
<M9names[m]> i3c is already released
<JamesMunns[m]> <M9names[m]> "it's almost exclusively those..." <- > <@9names:matrix.org> it's almost exclusively those who are writing drivers themselves without doing any research that are impacted.
<JamesMunns[m]> > as such, the documentation will almost certainly not help them
<JamesMunns[m]> This take feels a little icky to me. "we didn't document a confusing thing because if you didn't research it yourself you would have gotten it wrong anyway" is maybe not what you meant, but how I read it.
<JamesMunns[m]> I had to go look at how existing drivers and hals implemented it, because I haven't written a driver in a while, but I did look to see if e-hal documented it first.
IlPalazzo-ojiisa has joined #rust-embedded
<JamesMunns[m]> The answer seems to be "right aligned" (e.g. `0x00..=0x7F`), but I could still be wrong :)
<JamesMunns[m]> Anyway, I'll go add a PR to add it to the docs now.
<Lumpio-> I wonder how many bugs there are in I3C implementations out there already, I've seen too many devices get even I2C wrong and that's supposed to be simple
<M9names[m]> JamesMunns[m]: not my intention. more "please document but don't expect it to stop the questions", because i've been guilty of skipping the docs and asking the question
<M9names[m]> <JamesMunns[m]> "The answer seems to be "right..." <- isn't the common one "left aligned"? the address is in the most significant bits so the read/write bit doesn't change it
<Lumpio-> I'm not sure there even is a "the common way"
<Lumpio-> I've seen both a lot, our documentation lists both addresses for everything...
<JamesMunns[m]> M9names[m]: Does not appear so:
<JamesMunns[m]> So that would be right aligned, shifted left to apply the read/write bit.
<M9names[m]> the 7bit address is in the leftmost space of the 8bit value. is that left or right aligned?
<M9names[m]> have i misinterpreted what you mean here?
<JamesMunns[m]> in "right aligned", the most significant bit is always zero
<JamesMunns[m]> More evidence, the nrf52 peripheral expects you to write a 7-bit address, right aligned:
<M9names[m]> ah, sure, if you frame it like that I suppose it makes sense?
<M9names[m]> but it's a 7-bit field in an 8-bit space, we don't usually refer to the value of fields by their position though
<JamesMunns[m]> Maybe I made up the term "right aligned", but it makes sense to me :p
<diondokter[m]> JamesMunns[m]: I think I heard the term before
<JamesMunns[m]> If there is a more standard way of describing "the msbit must always be zero", I'm happy to update the docs.
<M9names[m]> no right padding bytes is true
<M9names[m]> * no right padding in the address that the user specifies is true
barnabyw[m] has joined #rust-embedded
<barnabyw[m]> I’ve always seen i2c’s 7-bit addresses with LSB indicating r/w as an implementation detail which should (and in my experience always is) be hidden from library users, so expecting right-aligned always made sense to me. Addresses are a number, so you provide that number, anything else would be a huge footgun
<JamesMunns[m]> I know I've seen datasheets with both lol
<M9names[m]> same
<JamesMunns[m]> so: worth being explicit when there is even a potential for confusion
<barnabyw[m]> (not that embedded isn’t full of similar footguns at every corner, but I’m at least glad it isn’t in this case)
<barnabyw[m]> definitely worth being explicit though!
<barnabyw[m]> having the addresses right-aligned allows libraries or tooling to check for invalid (>127) addresses too, whereas left-aligned would be stuck just ignoring the lsb and hoping for the best
<JamesMunns[m]> You'd have to check "are you trying to write with a trailing `1` or trying to read with a trailing `0` (both of which would be errors)
<diondokter[m]> Don't know if checking is worth it. You can only detect it if the highest bit of the address is set
<JamesMunns[m]> Yeah, imo we'd throw an error if you pass in a seven bit addr > 0x7F, to help people from footgunning
<JamesMunns[m]> but someone will be sad about that extra 2-4 instructions in every call, so I imagine it won't actually happen (consistently) :p
<diondokter[m]> JamesMunns[m]: My point is that that only helps with half the possible addresses. If an address is 0x10 left aligned, then it will be 0x20 right aligned. The check doesn't work here
<JamesMunns[m]> ah, gotcha
<JamesMunns[m]> This is a fun list: https://learn.adafruit.com/i2c-addresses/the-list
<JamesMunns[m]> Seems to be slightly heavier stacked in `>=0x40`, but still, lots that are smaller
<Darius> nice
<Darius> needs a checklist so you can pick various parts and see if they'll work :D
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded
<Ecco> Does embassy-stm32 support LPTIM and more specifically LPTIM-based PWM?
<adamgreig[m]> I don't believe there's any LPTIM support at the moment, no
<Ecco> ok thanks
<dirbaio[m]> PRs welcome, as usual 🙃
<Ecco> Of course :)
<Ecco> I'm trying to debug some hardware atm
<Ecco> and haven't played with LPTIM (from a low-level standpoint)
<Ecco> but I'd be glad to contribute a PR once I'm up-to-speed
<Ecco> dirbaio[m]: For STM32WB, did you re-use an ST-provided code? I'm looking at STM32WBA right now, and apparently on this chip the only way to do BLE is to use an ST-provided static library. AFAIK there is *no* low-level documentation (e.g. register addresses and behavior).
<Ecco> How would you address that in embassy? Should it just use the ST-provided library? I'm not even sure the license allows redistribution
<dirbaio[m]> STM32WB has a binary you have to flash at a fixed offset
<dirbaio[m]> the 2nd core boots from it
<dirbaio[m]> then you communicate with it with some shared memory mailbox
<Ecco> ok, so apparently WBA is very different
<dirbaio[m]> ST's C code to use that mailbox was open, so embassy-stm32 has a Rust port of that
<Ecco> my understanding on WBA nothing is documented
<Ecco> maybe there's a separate radio core. maybe not. It's not explicit. ST provides a static lib and some C headers.
<dirbaio[m]> in WB nothing is documented either, it's only the 2nd core's binary that touches the radio registers
<Ecco> (I mean, in a way, it is convenient)
<Ecco> (assuming said static lib works well)
<dirbaio[m]> but thanks to the 2nd core, you don't actually need linking with C code
<dirbaio[m]> WBA is completely different yes...
<Ecco> it seems like we could embed the static lib in embassy after all, even tho the license is weird
<Ecco> ok, so, I'm *very* new to Rust
<Ecco> I've done a *lot* of embedded C tho
<Ecco> So I might try and get something working
<Ecco> Honestly, maybe it's really just a matter of using bindgen + embedding the static lib
<Ecco> Oh wow, actually they just released a new version of that library like 4 days ago
<Ecco> with support for zigbee and thread?
<Ecco> Might be for the newer yet-to-be-announced WBA tho
AdrianGeipert[m] has joined #rust-embedded
<AdrianGeipert[m]> About the discussion of how to implement the delay and that using core::time::duration isn't wanted because of it's size.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/tPkpAtwQJbfprLPsvZzBQHZl>)
nadja has quit [Ping timeout: 240 seconds]
nadja has joined #rust-embedded
Guest7282 has left #rust-embedded [Error from remote client]
hyphened[m] has quit [Quit: Idle timeout reached: 172800s]
Orange_Murker[m] has joined #rust-embedded
<Orange_Murker[m]> Does anyone know of a library to generate sin lookup tables at compile-time?
firefrommoonligh has joined #rust-embedded
<firefrommoonligh> Not exactly what you're looking for, but CMSIS-DSP has very fast approximate sin fns
<firefrommoonligh> That use LUTs internally I believe
<Orange_Murker[m]> firefrommoonligh: Thanks. I'll look into it
<Orange_Murker[m]> May also just make something myself using const fn
<firefrommoonligh> To generate at compile time, you might need a macro?
<adamgreig[m]> Orange_Murker: https://crates.io/crates/idsp has a fast cossin via LUT
<adamgreig[m]> and being pure rust it's probably easier to handle than cmsis-dsp
Guest7282 has joined #rust-embedded
Guest7282 has quit [Changing host]
Guest7282 has joined #rust-embedded
<Orange_Murker[m]> <adamgreig[m]> "Orange_Murker: https://crates.io..." <- Thanks!
<Orange_Murker[m]> Interesting how it takes an i32 as the phase. I assume that 0-2^31-1 is mapped to 0-2pi?
<adamgreig[m]> it could have clearer documentation, for sure. I don't know what the mapping is.
<adamgreig[m]> probably it's 0 to 2pi, but since it's signed it might be -pi to +pi
<Orange_Murker[m]> It is -pi to pi it seems
<adamgreig[m]> makes sense!
<firefrommoonligh> <adamgreig[m]> "and being pure rust it's..." <- Can confirm for other purposes idsp is easier than wrapping CMSIS
<firefrommoonligh> I think those integer types are called q15, q31 etc
<firefrommoonligh> The intent is to make computations faster by using fixed point
<adamgreig[m]> q31 would be -1 to 1 mapping to -2^31-1 to 2^31, but here it's -pi to pi, so it's not a normal Q format fixed point number, it's "just" a fraction of pi
sigmaris has quit [Quit: ZNC - https://znc.in]
sigmaris has joined #rust-embedded
spinfast[m] has joined #rust-embedded
<spinfast[m]> Using fixed point isn’t always faster when an fpu is around 
merFurkanDemirci has joined #rust-embedded
<merFurkanDemirci> <adamgreig[m]> "👻" <- How could this message have come from the past?
therealprof[m] has joined #rust-embedded
<therealprof[m]> <spinfast[m]> "Using fixed point isn’t always..." <- True, but floating point with an FPU present is often also not faster than fixed point.
<therealprof[m]> That depends on a lot of factors, including the kind of operations, the number format, the speed of the FPU and the overhead for data conversion and transfer.
Tyalie7098[m] has joined #rust-embedded
<Tyalie7098[m]> hi. I'm relatively new here. I have worked professionally quite a bit with embedded hardware using C and Zephyr, but I would love to get hang of using Rust in this environment and maybe learn to write drivers in it.
<Tyalie7098[m]> Is there an extensive introductory resource available somewhere?
Guest7282 has left #rust-embedded [Error from remote client]
badrb[m] has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]> https://docs.rust-embedded.org/ is a good place to start.
<thejpster[m]> Various places also offer private and open trainings (like my company).
<Orange_Murker[m]> <adamgreig[m]> "Orange_Murker: https://crates.io..." <- Can confirm that it is really fast
<spinfast[m]> Like fir filters in f32 outdo even q15 fir      
<adamgreig[m]> seems surprising, given those mcus can do vector q15 operations
<spinfast[m]> right, and this is presumably using those (cmsis-dsp)
<Tyalie7098[m]> <thejpster[m]> "Various places also offer..." <- Ohh what do you mean with that? ^^
<thejpster[m]> like, people will teach you embedded rust in exchange for money.
bartmassey[m] has joined #rust-embedded
<bartmassey[m]> Anybody have a DTS (device tree) to Rust PAC program handy? If not, should we be building one? It looks like Device Tree doesn't support nearly as much as SVD, but in my case (CV1800B) it looks like all that's out there right now…
Guest7282 has joined #rust-embedded
<thejpster[m]> I don't think I've ever seen a device tree that tells you where the registers are in memory? They tell a kernel what hardware is on the system, but that assumes the kernel already has drivers and they just need some parameters configuring.
<thejpster[m]> The PAC is a register-access layer, such as you would need for writing the drivers in the first place.
<thejpster[m]> but if you have some examples, it sound fascinating
<spinfast[m]> It provides base register addresses
<spinfast[m]> But not full regmaps
K900 has joined #rust-embedded
<K900> Device trees do usually have addresses for peripherals that are at a fixed address
<firefrommoonligh> Hey PSA my life is changed; join my cult. In all of your Rust programs, add a `rustfmt.toml` file with this contents:... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/uSbTylvhkQsQtAByUdAHWqXM>)
<firefrommoonligh> It does what I've been doing by hand for years and is a constant battle esp when using the IDE to auto-import and refactor
<firefrommoonligh> s/for years//
<thejpster[m]> spinfast[m]: that tells you where the registers start (and that makes sense, because you could drop a PL011 UART peripheral pretty much anywhere in the I/O address space), but it doesn't tell you what registers are in the peripheral, or what their fields are, or what the rules are for what can go in each field.
<thejpster[m]> I know Zephyr uses generic drivers and device trees for configuration. I've not seen anyone do it in Rust. Yet.
<thejpster[m]> But then Zephyr is basically Linux without support for processes.
<spinfast[m]> thejpster[m]: thats about right, it expects the driver to know the regmap
<thejpster[m]> The datasheet has the register maps in it, that's enough to write a driver: https://github.com/milkv-duo/duo-files/blob/main/hardware/CV1800B/CV1800B-CV1801B-Preliminary-Datasheet-full-en.pdf
<thejpster[m]> a PAC is a nice to have, but you can still do it the old fashioned way and poke the registers with a core::ptr::volatile_write.
<thejpster[m]> And SVD is an Arm standard (it's CMSIS-SVD) so I don't expect many RISC-V chip makers to pick it up.
<spinfast[m]> Can generate your own with yaml and chiptool
<spinfast[m]> Rip a pdf table and whatnot
GrantM11235[m] has quit [Quit: Idle timeout reached: 172800s]
<M9names[m]> You can generate an SVD with chiptool?
<spinfast[m]> No, but you can generate your own pac from writing yaml, which could be obtained ripping a pdf table 
<spinfast[m]> And yaml is arguably nicer than svd xml
<spinfast[m]> * writing yaml that chiptool understands, which
<JamesMunns[m]> <thejpster[m]> "I know Zephyr uses generic..." <- The original original rust framework, Zinc-rs, did this
<dirbaio[m]> stm32-data is sort of that
<dirbaio[m]> chiptool can do yaml->svd, but it'd be really cool if it could do yaml->svd. PRs welcome, wink wink
<spinfast[m]> JamesMunns[m]: that's actually neat, platformtree, I guess I never saw that before
<JamesMunns[m]> It was already inactive in 2018, this is the long long ago in embedded rust time :)
Guest7282 has left #rust-embedded [Error from remote client]
Guest7282 has joined #rust-embedded
crabbedhaloablut has quit []
kenny has joined #rust-embedded
inara has quit [Quit: Leaving]
inara has joined #rust-embedded