<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...
<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]>
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
<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
<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]
<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>
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