<re_irc> <@boxkiller123:matrix.org> https://skidson.online/ Best AQW Private server
<re_irc> <@boxkiller123:matrix.org> AQW Is a free to play browser mmorpg you can play with your friends join us now!
<re_irc> <@boxkiller123:matrix.org> Join our discord below:
<re_irc> <@boxkiller123:matrix.org> https://discord.gg/ZAebPzpsbR
fabic has joined #rust-embedded
dcz_ has joined #rust-embedded
fabic has quit [Ping timeout: 265 seconds]
creich_ has quit [Quit: Leaving]
creich has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
dcz_ has quit [Ping timeout: 260 seconds]
GenTooMan has quit [Ping timeout: 252 seconds]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Excess Flood]
GenTooMan has joined #rust-embedded
GenTooMan has quit [Ping timeout: 252 seconds]
GenTooMan has joined #rust-embedded
<karlp> it seems very odd.
<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> <@xiretza:xiretza.xyz> it was introduced in this incredibly helpfully named commit: https://github.com/stm32-rs/stm32l4xx-hal/commit/bbdf9b09a165f7eb924a01a6114e073e94c357d3
<karlp> there's a MilliSeconds type now, I can maybe suggest a fix.
<karlp> thanks..
cr1901 has joined #rust-embedded
<re_irc> <@korken89:matrix.org> If you make a PR to fix that, I can merge it :)
<re_irc> <@korken89:matrix.org> Looks like a bug to me
<karlp> while I'm testing that, what's the "right" way of specifying a feature for examples to build?
<karlp> like cargo build --release --examples fails in that hal repo because you need to select a specific target feature.
<re_irc> <@xiretza:xiretza.xyz> `cargo build --examples --features foo bar`
<karlp> oh, looks like you can do that on the command line, TIL
<re_irc> <@korken89:matrix.org> `cargo build --examples --target thumbv7em-none-eabihf --features=stm32l4x1,rt,unproven`
<re_irc> <@korken89:matrix.org> That is what I use when I develop in the L4 HAL
<karlp> yeah, I've just submitted a PR to use eabihf by default...
<re_irc> <@korken89:matrix.org> karlp: ^
<karlp> thanks for approving me for workflows whoever did that :)
<re_irc> <@korken89:matrix.org> ✋
* karlp cheers
<re_irc> <@korken89:matrix.org> Hmm, something does not look correct with the implementation though
<re_irc> <@korken89:matrix.org> I'd expect it to be `Hertz(((ms + 500) / 1000).max(1))`
<re_irc> <@korken89:matrix.org> Ah wait, I though about seconds and millis
<re_irc> <@korken89:matrix.org> Nvm
<karlp> man, this lack of any sharing code between stm32 families with the -hal pacakges is a bit tedious.
<karlp> huge swathes of the peripherals are identical :|
<re_irc> <@korken89:matrix.org> Yep, I think there is an effort here to unify: https://github.com/David-OConnor/stm32-hal
<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> there's also the embassy stm32 hal which does similarly: https://github.com/embassy-rs/embassy/tree/master/embassy-stm32
<re_irc> <@korken89:matrix.org> Yeah, that's more accurate
<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> <@dirbaio:matrix.org> 2 gpio versions, 2 usart's, 2 i2c's, 3 spi's
<re_irc> <@dirbaio:matrix.org> vs ~15 families :)
<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> <@dirbaio:matrix.org> they come from here https://github.com/embassy-rs/embassy/blob/master/embassy-stm32/build.rs#L84
<re_irc> <@dirbaio:matrix.org> that macro looks like this https://gist.github.com/Dirbaio/85bb62e46c3835c6baae5be7baa661af
<re_irc> <@dirbaio:matrix.org> which is feeded with data from these yamls https://github.com/embassy-rs/stm32-data/blob/main/data/chips/STM32F429ZI.yaml#L871
<re_irc> <@dirbaio:matrix.org> so yeah 🤣
<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> <@therealprof:matrix.org> I was looking at https://github.com/David-OConnor/stm32-hal/blob/main/src/spi.rs and that's not quite what I'm seeing there.
<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> embassy does that for EXTI for example https://github.com/embassy-rs/embassy/blob/master/embassy-stm32/src/exti.rs#L146-L152
<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
<karlp> all compiled allt he way down the chain now... a few minutes to runtime test somethign to finish the day I guess :)
<karlp> schweet, BLE and blinkies both...
fabic has quit [Ping timeout: 252 seconds]
GenTooMan has quit [Remote host closed the connection]
GenTooMan has joined #rust-embedded
dcz has joined #rust-embedded
dcz_ has quit [Ping timeout: 260 seconds]
dcz has quit [Ping timeout: 260 seconds]
gsalazar has quit [Ping timeout: 245 seconds]