<re_irc>
<@xiretza:xiretza.xyz> it converts a millisecond period to hertz
<karlp>
that's what it looks like it's trying to do...
<karlp>
so 500ms should be...? 2?
<re_irc>
<@xiretza:xiretza.xyz> yes
<karlp>
ok, so do the maths by hand?
<re_irc>
<@xiretza:xiretza.xyz> it's equivalent to `floor(100/ms + 0.5)`
<karlp>
500/2 first, because / is before +. gives you 1250 / 500
starblue has joined #rust-embedded
<karlp>
that's being implicitly floored back to a u32?
<karlp>
this is what I get for looking at code.
<karlp>
don't peek under the covers...
<re_irc>
<@xiretza:xiretza.xyz> it's a fairly standard rounding integer division, complicated by the factor of `1000` coming from the `m` in `ms`
<karlp>
because that'
<karlp>
s a "From<u32>" not a "From<Millisconds>" that will just magically turn any integer into that truncated world view of 1..1000 if a hertz is required though right?
<karlp>
so if you need a hertz, and you forget to do .sysclk(Hertz(80_000_000))
<karlp>
and do .sysclock(80_000_000) you get just "1" out?
<re_irc>
<@xiretza:xiretza.xyz> no, you'll get a type error
<karlp>
does the from have to be explicitally called with Hertz::from() then?
<re_irc>
<@xiretza:xiretza.xyz> you're right though, it should really be `impl From<MilliSeconds> for Hertz`
<re_irc>
<@xiretza:xiretza.xyz> irc_libera_karlp:psion.agg.io: or `80_000_000.into()`, yes, there is no magic `From`/`Into` conversion in rust
<re_irc>
<@xiretza:xiretza.xyz> the only magic compiler trait that I know of is `Deref`
<karlp>
so yeah, 80_000_000.into() will just turn into "1" here, because that's a from<u32> which is overly broad?
<re_irc>
<@adamgreig:matrix.org> I think usually people write like `.sysclk(80.mhz())`
<re_irc>
<@xiretza:xiretza.xyz> irc_libera_karlp:psion.agg.io: yeah, that less than ideal
cr1901 has quit [Read error: Connection reset by peer]
<re_irc>
<@adamgreig:matrix.org> probably more fairly described as an alternative HAL from scratch that covers multiple families at once, rather than unifying the stm32Xxx-hal repos
<re_irc>
<@adamgreig:matrix.org> karlp: it's essentially historical; different people (with some overlap) maintain each HAL because it's the family they're using/are interested in, and basically one of them came first and later ones copied (and in many cases made small adjustments to) each implementation
<re_irc>
<@dirbaio:matrix.org> there you can see the peripheral versions :)
<re_irc>
<@dirbaio:matrix.org> families with same version have identical registers, they can share the HAL impl
<re_irc>
<@adamgreig:matrix.org> the embassy and stm32-hal2 efforts are newer and organised by a single group/person each, so cover several families with one implementation, though I don't think either cover all the families the individual HALs do yet
<re_irc>
<@korken89:matrix.org> Quite a lot simpler :)
<re_irc>
<@korken89:matrix.org> One could make `stm32-gpio-v1`, `stm32-gpio-v2` etc crates and have the exiting HALs reexport the underlying peripherals
<re_irc>
<@korken89:matrix.org> Not sure if this is being done already?
<re_irc>
<@korken89:matrix.org> I know ChibiOS was following this approach and it was a joy to use
<re_irc>
<@adamgreig:matrix.org> for the more complicated peripherals it is: stm32-eth, stm32-sdmmc, etc
<re_irc>
<@dirbaio:matrix.org> embassy-stm32 does that, not with separate crates though
<re_irc>
<@adamgreig:matrix.org> it's tough for the simpler peripherals, mostly because the types of the PAC structs are different and often have various inconsistencies
<re_irc>
<@adamgreig:matrix.org> the ethernet, sdmmc, usb, etc drivers often bring their own pac essentially
<re_irc>
<@adamgreig:matrix.org> there's also often small differences even within those versions of each peripheral
<re_irc>
<@adamgreig:matrix.org> which I think embassy just ignores and usually you don't need them anyway I guess
<re_irc>
<@adamgreig:matrix.org> (I think the separate -hal crates also typically ignore them...)
<re_irc>
<@adamgreig:matrix.org> (but it makes unifying them harder without removing those fields from the PACs entirely, otherwise the types differ)
<re_irc>
<@dirbaio:matrix.org> hmm I haven't seen such differences in spi/i2c/uart
<re_irc>
<@dirbaio:matrix.org> there are some in the timers
fabic has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> the timers are in a world of their own lol
<re_irc>
<@dirbaio:matrix.org> but relating to the "advanced" stuff such as having timers pace ADC/DMA/whatever
<re_irc>
<@dirbaio:matrix.org> the "basic" stuff is identical
<karlp>
yeah, in libopencm3 we just let you use "advanced" functions on a basic timer, and it just doesn't do anything, we don't try and use types for the timers.
<karlp>
crates for the peripherals would probably be a really nice way of composing it, there'd still be dupe code, but it would be pretty manageable.
<karlp>
those embassy cfg_attrs loook like magical pixie dust :)
<re_irc>
<@therealprof:matrix.org> It seems like the use of const generics might provide a good chance to really unify all the implementations. The macro magic of the past made it really hard to abstract over the peripheral versions in a useful way.
<re_irc>
<@dirbaio:matrix.org> you can unify them just fine without const generics
<re_irc>
<@therealprof:matrix.org> You mean with feature gating and heavy macro magic? Sure.
<re_irc>
<@dirbaio:matrix.org> feature gating is good
<re_irc>
<@dirbaio:matrix.org> if the user is building for stm32f4 which is SPIv1 you don't want them to be able to accidentally use SPIv2
troth has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> you don't want SPIv2 code to even *get built*, which makes for faster builds
<re_irc>
<@therealprof:matrix.org> Yeah, I don't mean that kind of feature gating. I mean adding feature gates for every little tiny detail.
<re_irc>
<@therealprof:matrix.org> If you want to be thorough you'll have to test the create with the product of all possible feature gates.
<re_irc>
<@dirbaio:matrix.org> you just have SPIv1, SPIv2, SPIv3 feature gates
<re_irc>
<@dirbaio:matrix.org> which you *have* to have because there are three different SPI versions, there's no way around that
<re_irc>
<@dirbaio:matrix.org> and const generics don't help with that
<re_irc>
<@dirbaio:matrix.org> yeah organizing the cfg's per version is cleaner
<re_irc>
<@therealprof:matrix.org> I agree you need to have different implementations and feature gates for different versions. I'm talking about features in the impls in the code itself. You don't want any `cfg` based blocks in that code.
<re_irc>
<@dirbaio:matrix.org> hmmhm it depends
<re_irc>
<@dirbaio:matrix.org> if the registers are almost-equal it makes more sense to cfg the different parts inline
<re_irc>
<@dirbaio:matrix.org> it's better than having 5 copypastes of almost-identical code
<re_irc>
<@therealprof:matrix.org> For sure. But const generics might help as well if you can clearly identify and factor our the differences. ;)
<re_irc>
<@dirbaio:matrix.org> how?
<karlp>
organizing per stm32 part number lies madness, we tried that in libopencm3, you've got to do it by peripheral version+extensions
fabic has quit [Ping timeout: 252 seconds]
dcz_ has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc>
<@dirbaio:matrix.org> Is there some usb-to-spi or usb-to-i2c firmware around that you can flash on a cheap board (like blackpill or bluepill)
<re_irc>
<@dirbaio:matrix.org> that would appear to Linux like an spi/i2c device, so you can then use it with linux-embedded-hal?
<re_irc>
<@dirbaio:matrix.org> would be ultra handy to develop drivers, develop them first on linux which is easier/faster then later make them work on nostd
<re_irc>
<@newam:matrix.org> I made this a while ago which is a similar idea, but using FTDI devices which have their own drivers.
<re_irc>
<@dirbaio:matrix.org> ohh neato
<re_irc>
<@dirbaio:matrix.org> I guess buying some ftx232h dongle is simpler yea
<re_irc>
<@adamgreig:matrix.org> there's also some projects on using your hardware but proxying calls to it over usb, like https://github.com/Disasm/avatar-rs
<re_irc>
<@adamgreig:matrix.org> so you still run rust on desktop but the mmio goes to the device
<re_irc>
<@adamgreig:matrix.org> or just buy an rpi which has spi/i2c/uart built in too :P
<re_irc>
<@dirbaio:matrix.org> lol, proxying at the mmio layer sounds fun (and scary)
<re_irc>
<@dirbaio:matrix.org> yeah I thought about the rpi but having to crosscompile and copy it defeats the point a bit
<re_irc>
<@dirbaio:matrix.org> bought some random ft232 dongle from amazon :D
<re_irc>
<@dirbaio:matrix.org> gonna develop a rust driver for the st25r nfc chips
<re_irc>
<@dirbaio:matrix.org> got tired of their shit C driver
<re_irc>
<@dirbaio:matrix.org> it's SO BAD
_whitelogger has joined #rust-embedded
<karlp>
I've been updating eupn's stm32wb-hal to use upstream stm32-rs/stm32wb(pac) and that all has gone mostly well,
<karlp>
I've now got "the trait bound `stm32wb_hal::interrupt: Nr` is not satisfied" building the examples in the -hal project,
<karlp>
that's cortex-m-rt 0.6 vs 0.7 issues right?
<karlp>
is there some simple path throuhg that? the -hal project depends on cortex-m 0.7, but not rt explicitly, only via the pac, which has "version = ">=0.6.15,<0.8"" for cortex-m-rt
<re_irc>
<@dirbaio:matrix.org> it's probably cortex-m, not cortex-m-rt
<re_irc>
<@dirbaio:matrix.org> cortex-m 0.6 uses bare_metal::Nr (reexported as cortex_m::interrupt::Nr)
<re_irc>
<@dirbaio:matrix.org> cortex-m 0.7 has its own cortex_m::interrupt::InterruptNumber
<re_irc>
<@dirbaio:matrix.org> check that PAC, HAL and examples all use cortex-m 0.7 and InterruptNumber