#rust-embedded on 2021-09-10 — irc logs at libera.irclog.whitequark.org

01:00 dcz has joined #rust-embedded

01:56 <re_irc> <@josfemova:matrix.org> Any guide on how to do adc reads in atsamd51/21 MCU's?

01:59 starblue has quit [Ping timeout: 260 seconds]

02:01 starblue has joined #rust-embedded

02:04 <re_irc> <@9names:matrix.org> Have you looked at the examples in the atsamd hal repo?

02:04 <re_irc> <@9names:matrix.org> https://github.com/atsamd-rs/atsamd/blob/9a9e7621e5014e08500eb523b6cfe81c1e374169/boards/feather_m0/examples/adc.rs

02:07 <re_irc> <@josfemova:matrix.org> 9names: Yup but missed that one it seems, thnx a lot

02:18 <re_irc> <@sajattack:matrix.org> josfemova: we have a dedicated room at #atsamd-rs_community:gitter.im if you have more questions

03:01 dcz has quit [Ping timeout: 265 seconds]

04:46 emerent has quit [Ping timeout: 260 seconds]

04:46 emerent has joined #rust-embedded

05:04 <re_irc> <@jorgeig:matrix.org> For all the STM32WL fans: I'm trying to get LoRaWAN to work on an STM32WL, first try is here: https://github.com/jorgeig-space/lorawan-wl

05:05 <re_irc> <@jorgeig:matrix.org> it doesn't work yet, of course 😆

05:19 dcz has joined #rust-embedded

06:02 fabic has joined #rust-embedded

06:53 dfgweb has quit [Quit: Leaving]

07:05 gsalazar has joined #rust-embedded

07:32 gsalazar_ has joined #rust-embedded

07:35 gsalazar has quit [Ping timeout: 265 seconds]

07:36 fabic has quit [Ping timeout: 260 seconds]

07:44 gsalazar_ has quit [Remote host closed the connection]

07:46 gsalazar_ has joined #rust-embedded

10:23 <karlp> man, these svd's have got some absolute garbage in them sometimes don't they...

10:31 <re_irc> <@firefrommoonlight:matrix.org> Haha yeah. Props to the PAC team for all the work fixing them

10:52 <karlp> it makes you feel like you've gotten a lot done, but there's a lot to be said for transcibing by hand from the ref man after having done it this way too...

10:52 <re_irc> <@adamgreig:matrix.org> Yea... when I started I really thought all the work would just be adding the enumerated values (the permitted values for each field and their names and descriptions)

10:53 <re_irc> <@adamgreig:matrix.org> The ability to also make structural changes was secondary and seemed like it would be more occasional, ha ha

10:54 fabic has joined #rust-embedded

10:55 <re_irc> <@adamgreig:matrix.org> Problem with doing it by hand is the unloved peripherals probably wouldn't ever get done, there are just thousands and thousands of fields and it's pretty boring doing the hdmi-cec when you'll never use it

10:55 <re_irc> <@adamgreig:matrix.org> At least the svds have something for them I guess

11:19 <karlp> true, in libopencm3 the unloved periphs can take a long time to turn up, but at least when we have a peripheral, it's done.

11:20 <karlp> in this stm32wb svd, tim17 has completely garbage register offsets, instead of jsut being tim17. so it _looks_ like it works, because all the code is there, but it doesn't. so yeah, yay, got tim17 code from the svd, but... is that really better than nothing?

11:30 <re_irc> <@firefrommoonlight:matrix.org> irc_libera_karlp:psion.agg.io: That becomes untenable across MCUs, or even across the breadth or peripherals and their functionality

11:30 <re_irc> <@adamgreig:matrix.org> In that specific case no, but at least completely wrong peripherals like that are very rare

11:31 <karlp> yar, I know. and also, it's esaier to find people to fix a broken SVD periph than to create the raw periph.

11:33 <re_irc> <@firefrommoonlight:matrix.org> Doing the reg access by hand is fine for a specific project where you know what peripherals you're using, and what functionality of the periphs.

11:33 <re_irc> <@firefrommoonlight:matrix.org> I like the PAC approach because it doesn't tie you to those specifics

11:34 <re_irc> <@firefrommoonlight:matrix.org> IIRC I parched that WB tim17 thing, and agg merged it

11:37 <karlp> there's https://github.com/stm32-rs/stm32-rs/commit/7036fdffb6bb2c4548f13f890fd6bf309373c143#diff-2d9132a6aa7b6d793ed564543bed516fcc4d8cc58d02940f2df65b07d38a1d1b, if that's what you mean, but there's still plenty more :)

11:38 <karlp> i've nearly finished, i'll send it when it's done.

11:42 <re_irc> <@firefrommoonlight:matrix.org> Ah - those offset errors were my mistake, which Adam fixed. The SVD regs were missing or something for those regs

11:43 <re_irc> <@firefrommoonlight:matrix.org> Unfortunately, I think the most practical approach is playing wack-a-mole with these. When you hit a problem, make an issue and/or PR. The more-common MCUs and periphs will be fixed faster

11:54 <karlp> be nice if ST was at all interested in fixing the svds themselves...

11:55 <karlp> firefrommoonlight who are you on github?

12:06 fooker has quit [Ping timeout: 240 seconds]

12:08 <re_irc> <@firefrommoonlight:matrix.org> David OConnor

12:08 <karlp> thanks

12:20 fooker has joined #rust-embedded

13:09 fabic has quit [Remote host closed the connection]

13:10 fabic has joined #rust-embedded

13:57 DepthDeluxe has joined #rust-embedded

14:14 fabic has quit [Ping timeout: 265 seconds]

14:27 <re_irc> <@richarddodd:matrix.org> Question about embassy: is it poll a future without awaiting it? I'm writing some stuff over SPI and I want to fill the next buffer while the previous one is DMA'd. I want to set the DMA off, but only await it after the next one is ready.

14:34 <re_irc> <@dirbaio:matrix.org> nothing guarantees the DMA will be started with a single poll, or that DMA is even in use (an SPI impl could do CPU copy, needing one poll per byte)

14:34 <re_irc> <@dirbaio:matrix.org> if you want to run things concurrently, it's better to use `join` or `select`

14:36 <re_irc> <@dirbaio:matrix.org> or maybe two tasks with a channel as a "queue of buffers to send". More flexible but more heavyweight

14:36 <re_irc> <@richarddodd:matrix.org> I'll try making a 'fake' async fn that does the cpu work, and then joining on them both. Hopefully the executor will organise things reasonably.

14:37 <re_irc> <@richarddodd:matrix.org> It's not a lot of CPU work, but would be nice to run concurrently with the DMA if possible.

14:38 <re_irc> <@dirbaio:matrix.org> if one fut is waiting on DMA and the other does CPU work it'll probably work if you put the DMA one first in the join/select, so that it gets polled first

14:39 <re_irc> <@dirbaio:matrix.org> if you really really want to make sure DMA gets priority then yo ucan do that with two executors + two tasks, spawning the "SPI send" in the higher prio executor

14:39 <re_irc> <@dirbaio:matrix.org> but it's probably not worth it

14:42 <re_irc> <@richarddodd:matrix.org> An alternative is changing the semantics of Spim::write to say "will make as much progress as possible without blocking, including starting DMA". Then you could do your other work and await at the end.

14:42 <re_irc> <@richarddodd:matrix.org> (And Read/Transfer if you wanted to go down that route)

14:46 <re_irc> <@dirbaio:matrix.org> yeah but that's leaking implementation details

14:47 <re_irc> <@dirbaio:matrix.org> the Future contract is just "you must poll every time you get a wake"

14:48 <re_irc> <@dirbaio:matrix.org> so the async SPI trait contract is "write() returns a future that does a SPI write"

14:48 <re_irc> <@dirbaio:matrix.org> that implies that the future MUST be polled according to the Future trait contract

14:48 <re_irc> <@dirbaio:matrix.org> ie it's NOT ok to poll it just once and expect that to kick off the whole write

14:49 <re_irc> <@richarddodd:matrix.org> You'd still have to poll it. It's just that it might have made more progress before the first poll.

14:49 <re_irc> <@richarddodd:matrix.org> ie. how you use it wouldn't change,

14:50 <re_irc> <@dirbaio:matrix.org> ah you mean making Spim::write itself start the write, NOT the first poll?

14:50 <re_irc> <@richarddodd:matrix.org> Yesss

14:50 <re_irc> <@richarddodd:matrix.org> If it can be done in a wait-free way

14:50 <re_irc> <@richarddodd:matrix.org> if not, then do nothing.

14:50 <re_irc> <@dirbaio:matrix.org> this violates the convention that async fns do not do any work, only polling the future does work

14:51 <re_irc> <@richarddodd:matrix.org> The function isn't async: it returns a future.

14:51 <re_irc> <@richarddodd:matrix.org> I guess if you want it to be like an async fn, you couldn't do any work

14:51 <re_irc> <@dirbaio:matrix.org> it's not an async fn because you can't have async fns in traits yet, otherwise it would be

14:51 <re_irc> <@dirbaio:matrix.org> it's "conceptually" still an async fn

14:52 <re_irc> <@richarddodd:matrix.org> Ok so the question is: do we gain anything from it being a fn that does nothing until polled that we would lose if it set off a DMA?

14:54 <re_irc> <@dirbaio:matrix.org> no, it's the other way around

14:54 <re_irc> <@dirbaio:matrix.org> even if you specify in the SPI trait contract "write() may start the write before the first poll"

14:55 <re_irc> <@dirbaio:matrix.org> impls might not do so. For example an impl that does CPU copy can't do so (or maybe it can, but just the first byte)

14:55 <re_irc> <@dirbaio:matrix.org> so a generic driver can't rely on that anyway

14:56 <re_irc> <@richarddodd:matrix.org> ahhh I see I think

14:56 <re_irc> <@dirbaio:matrix.org> so it's not very useful

14:56 <re_irc> <@dirbaio:matrix.org> and

14:56 <re_irc> <@dirbaio:matrix.org> d if you specify in the SPI trait contract "write() MUST start the write before the first poll" then you're ruling out impls that do CPU copy which is not

14:56 <re_irc> <@richarddodd:matrix.org> so it's fine for my use case where I know my hardware, but if someone wants to write a generic driver and they want the parallelism, they need to use another method?

14:57 <re_irc> <@dirbaio:matrix.org> if you do the "poll once" thing you're violating the Futures cotract

14:58 <re_irc> <@dirbaio:matrix.org> in the case of embassy-nrf it'll work because how it works internally (it does start DMA on the first poll)

14:58 <re_irc> <@dirbaio:matrix.org> but you're relying on these implementation details

14:58 <re_irc> <@dirbaio:matrix.org> which 1. may change at any semver-minor release

14:58 <re_irc> <@dirbaio:matrix.org> and 2. may not work at all with other HALs

14:58 <re_irc> <@richarddodd:matrix.org> Ok lemme argue this another way: we do it as an implementation detail on nrf.

14:59 <re_irc> <@richarddodd:matrix.org> hmm maybe not

14:59 <re_irc> <@richarddodd:matrix.org> hmmm. it would be nice if a generic driver could achieve this parallelism (where possible)

14:59 <re_irc> <@dirbaio:matrix.org> it can, with poll/select

15:00 <re_irc> <@dirbaio:matrix.org> not with "poll just once"

15:00 <re_irc> <@richarddodd:matrix.org> dirbaio:matrix.org: Separate question: How do you do a bit-banging impl? Do you not need to have interrupt priority so you can get the timing right? How does that play with the executor?

15:01 <re_irc> <@richarddodd:matrix.org> Like, you can't rely on the work getting poll'd in time.

15:01 <re_irc> <@dirbaio:matrix.org> yeah a bitbanging impl would have to use a classic interrupt-driven timer

15:02 <re_irc> <@richarddodd:matrix.org> How does the CPU copy work? Is that copying into some small buffer?

15:02 <re_irc> <@dirbaio:matrix.org> then just wrap that in a future that gets woken when it's done

15:02 <re_irc> <@dirbaio:matrix.org> by "cpu copy" I mean an impl that manually writes to the "DR" registers, not using DMA

15:02 <re_irc> <@richarddodd:matrix.org> dirbaio:matrix.org: Yeah I'm definitely not advocating this under any circumstances. :)

15:02 <re_irc> <@dirbaio:matrix.org> nrf52 doesn't have such thing in the new DMA-enabled peripherals

15:03 <re_irc> <@dirbaio:matrix.org> but it's super common in stm32 and other chips

15:03 <re_irc> <@richarddodd:matrix.org> cool thnx

15:03 <re_irc> <@dirbaio:matrix.org> there's a "tx buffer empty" interrupt

15:03 <re_irc> <@richarddodd:matrix.org> I'm looking forward to playing with the GIO on the pi for learning more about protocols like SPI

15:03 <re_irc> <@dirbaio:matrix.org> then you have to write data into the DR to push more bytes in the tx buffer

15:04 <re_irc> <@dirbaio:matrix.org> so there could be an impl that wires "tx buffer empty" into "wake", and "poll" does the "write into DR"

15:04 <re_irc> <@dirbaio:matrix.org> it would suck, it would slow down if polls don't come fast enough

15:04 <re_irc> <@dirbaio:matrix.org> DMA is way better

15:05 <re_irc> <@dirbaio:matrix.org> but still, it should be allowed by the async Spi/i2c/uart traits contract

15:06 <re_irc> <@richarddodd:matrix.org> I might have a go at writing a ST7789 driver for embassy, to see how it goes making it board-agnostic.

15:06 <re_irc> <@dirbaio:matrix.org> fun

15:07 <re_irc> <@dirbaio:matrix.org> not sure how would it wokr

15:07 <re_irc> <@dirbaio:matrix.org> turning the entire embedded-graphics into async is probably not worth it

15:08 <re_irc> <@jamwaffles:matrix.org> Wouldn't the iterators it produces work reasonably well with an async driver? I don't think e-g itself needs to be fully async

15:08 <re_irc> <@jamwaffles:matrix.org> Maybe it could provide some async stream adapters though?

15:09 <re_irc> <@dirbaio:matrix.org> dunno

15:09 <re_irc> <@dirbaio:matrix.org> I guess to get it to go faster you want "SPI tx" and "CPU calculating lines/text/whatever" to be done in parallel

15:10 <re_irc> <@dirbaio:matrix.org> if the embedded-graphics DrawTarget impl waits for SPI you're not getting that

15:10 <re_irc> <@dirbaio:matrix.org> even if it's an "async wait" instead of a "blocking wait"

15:10 <re_irc> <@dirbaio:matrix.org> so

15:10 <re_irc> <@dirbaio:matrix.org> the embedded-graphics impl would have to "enqueue" the display commands into a pipe in RAM

15:11 <re_irc> <@dirbaio:matrix.org> and then a higher-prio task would drain that pipe into SPI with DMA

15:11 <re_irc> <@dirbaio:matrix.org> that way you do get parallel "SPI tx" and "CPU drawing stuff"

15:21 <karlp> I'm trying to extract functions for code currently in my "init" and running into all sorts of problems with per port types and things, am i missing something basic? https://paste.jvnv.net/view/VZk3v

15:23 fabic has joined #rust-embedded

15:24 <re_irc> <@dirbaio:matrix.org> karlp: which HAL is it?

15:25 <karlp> this is stm32wb, but ~same gpios as l4.

15:27 <re_irc> <@richarddodd:matrix.org> dirbaio:matrix.org: I'm just trying to get a method that takes a u8 iterator and writes it to screen. Not even worrying about endianness.

15:28 <re_irc> <@dirbaio:matrix.org> karlp: what you want to do is unfortunatley not possible :(

15:28 <re_irc> <@richarddodd:matrix.org> I've already got the code - just need to make it generic

15:28 <re_irc> <@dirbaio:matrix.org> because `into_pullup_input` is defined for all the individual GPIO pin types with a macro

15:28 <karlp> dirbaio: this does not give me warm fuzzies :)

15:28 <re_irc> <@dirbaio:matrix.org> https://github.com/eupn/stm32wb-hal/blob/master/src/gpio.rs#L407

15:28 <re_irc> <@dirbaio:matrix.org> and it's not part of any trait

15:29 <karlp> this seems common in the stm32 hals, yet decidedly unhelpful?

15:29 <re_irc> <@dirbaio:matrix.org> so there's no way to say "I take any type that has a `into_pullup_input` function`, you need a trait for that

15:29 <karlp> same with the ports as a whole as far as I can tell?

15:30 <re_irc> <@dirbaio:matrix.org> yeah

15:30 <re_irc> <@dirbaio:matrix.org> This is why the macro-based gpio sucks

15:30 <karlp> there's a GpioExt->Parts that is a trait, so nominally that's what could be passed for the port param,

15:31 <re_irc> <@dirbaio:matrix.org> kinda, but the "parts" is an associated type you know nothing about, so you won't be able to get the individual pins out of it either

15:31 <karlp> as best I can tell, ~all the periphs on ~all the families are implemented like this, and the "use embassy" solution isn't appealing yet, rust is niche enough...

15:31 <re_irc> <@dirbaio:matrix.org> https://github.com/eupn/stm32wb-hal/blob/master/src/gpio.rs#L11

15:31 <re_irc> <@dirbaio:matrix.org> hehe I was about to say that

15:31 <re_irc> <@dirbaio:matrix.org> embassy's gpio design doesn't have this problem

15:31 <re_irc> <@dirbaio:matrix.org> but yeah

15:31 <re_irc> <@dirbaio:matrix.org> everyone keeps copypasting the macro-based GPIO around

15:31 <re_irc> <@dirbaio:matrix.org> :(

15:31 <karlp> so... spaghettic code all in the same init function... like all the examples in all the repos...

15:33 <re_irc> <@richarddodd:matrix.org> dirbaio: I don't think a driver is feasible atm. The problems I had were around actually initializing: the driver needs to have some control over the SPI config, and also the Pin config for chip select etc. I think it would need generic versions of `embassy_nrf::gpio::Output::new`.

15:33 <re_irc> <@richarddodd:matrix.org> Was interesting to look at it :)

15:34 <re_irc> <@dirbaio:matrix.org> karlp: you *can* avoid copypasting the gpio setup in your code, but with a macro instead of a generic function

15:34 <re_irc> <@dirbaio:matrix.org> MOAR macros

15:35 <re_irc> <@dirbaio:matrix.org> that's the problem with macro-based HALs, they don't work well with generics/traits so then user code needs more macros :(

15:36 <karlp> dirbaio: yeah, I thought of that, but none of that makes me want to use rust.

15:36 fabic has quit [Ping timeout: 252 seconds]

15:36 <karlp> if I wanted to get into template meta programming, I just... wouldn't get into that.

15:36 <re_irc> <@dirbaio:matrix.org> hehehe

15:37 <re_irc> <@dirbaio:matrix.org> totally understandable!

15:37 <re_irc> <@dirbaio:matrix.org> :(

15:39 <re_irc> <@richarddodd:matrix.org> Rust (the language) is really good for newcomers now, but go back to 2014 when I started and it was definitely not! I think the embedded community will get there eventually as well.

15:39 <re_irc> <@richarddodd:matrix.org> It will probably take a rethink of the HALs

15:40 <re_irc> <@richarddodd:matrix.org> (IMO)

15:40 <re_irc> <@dirbaio:matrix.org> I find it quite disappoiting that people see stm32-rs, nrf-rs etc as the "official" HALs and then don't want to even consider using other HALs

15:41 <re_irc> <@dirbaio:matrix.org> they're *not* "official" as in they're not a rust-embedded working group project

15:42 <re_irc> <@dirbaio:matrix.org> it's just an opensource project that was the first and had the luck to grab the stm32-rs name

15:44 <re_irc> <@dirbaio:matrix.org> and as seen above this is hindering embedded rust adoption

15:50 <karlp> well, if I go by active forks, and commits, it's also indiciative of community size.

15:50 <karlp> embassy is "you're going to like coroutines right?" which is not for everyone, right off the bat,

15:52 <re_irc> <@dirbaio:matrix.org> embassy started out as "let's make an async runtime for embedded"

15:52 <re_irc> <@dirbaio:matrix.org> for that to be useful, it needed "stm32 HALs that support async"

15:53 <karlp> and beyond that it's a couple of one person shows? Sure, they're rust, so they're awesome, and there's some really good code around, but... I mean, starlightmoon's "hal2" looks like a nice idea, but it's a one person show with a handful of users.

15:53 <re_irc> <@dirbaio:matrix.org> first attempt was to build `embassy-stm32f4` on top of `stm32f4xx-hal`, etc etc for each family

15:53 <karlp> I'm not really looking for a new project to build foundations, I was hoping that I could use rust as a serious alternative to c+freertos.

15:54 <re_irc> <@dirbaio:matrix.org> it was soon clear that that was NOT going to be maintainable: macro mess AND copypaste for each stm32 family

15:54 <re_irc> <@therealprof:matrix.org> I think const generics provide a way out of macro hell... Look at how small the current gpio instantiation macro in `stm32f4xx-hal` is now: https://github.com/stm32-rs/stm32f4xx-hal/blob/979ff1555f79e3e268a600caa5c43b8d3de95217/src/gpio.rs#L592-L630

15:54 <re_irc> <@dirbaio:matrix.org> so the project shifted to "OK let's make an `embassy-stm32` HAL from scratch, fixing the technical decisions that led to the current stm32xxxx-hal state"

15:56 <re_irc> <@dirbaio:matrix.org> AND while we're at it, make `embassy-stm32` support async AND blocking operation, because once you setup all the scaffolding to support all families etc, adding blocking support costs nothing

15:57 <re_irc> <@dirbaio:matrix.org> so you *can* use embassy-stm32 without async (without coroutines)

16:01 * karlp runs into more errors in the svd.

16:05 <re_irc> <@dirbaio:matrix.org> I'm not very convinced of the F4 const-generics gpio either :S

16:05 <re_irc> <@dirbaio:matrix.org> it still has copypaste for full/erased pins

16:06 <re_irc> <@dirbaio:matrix.org> 300 lines of From impls

16:07 <re_irc> <@dirbaio:matrix.org> and has 3 (or more?) ways to change mode

16:07 <re_irc> <@dirbaio:matrix.org> using From/Into, using into_xxxx methods, using the closure-based with_mode

16:10 <re_irc> <@dirbaio:matrix.org> and the const generics make it so that `Pin<_, 'Z', 123>` is a valid type even though `PZ123` is not a thing

16:13 <re_irc> <@dirbaio:matrix.org> it's 2126 lines total

16:13 <re_irc> <@therealprof:matrix.org> Is it perfect? No, but it's a lot better than what we had in the past and could be used as a foundation of a generic GPIO driver... (sans the legacy stuff).

16:14 <re_irc> <@therealprof:matrix.org> And it shows that improvements are possible without having to reinvent the wheel...

16:14 <re_irc> <@dirbaio:matrix.org> if the wheel is broken it HAS to be reinvented

16:15 <re_irc> <@dirbaio:matrix.org> having 15 HALs with everything copypasted from each other is broken

16:16 <re_irc> <@dirbaio:matrix.org> it's not maintainable

16:16 <re_irc> <@dirbaio:matrix.org> PRs are stuck for months because maintainers (understandably) don't have time to review the same thing 15 times

16:17 <re_irc> <@dirbaio:matrix.org> improvements to one HAL stay in that one HAL the contributor personally uses (such as the F4 gpio)

16:17 <re_irc> <@dirbaio:matrix.org> because why would that contributor do 15x the work of porting that to 15 copypasted HALs?

16:18 <re_irc> <@therealprof:matrix.org> I don't think there was a good solution in the past which is why all the copy-pasta exists. I agree it's not maintainable but as I said, with const generics we now have better ways to address this and in a backwards compatible way.

16:19 <re_irc> <@dirbaio:matrix.org> const generics is not the solution

16:19 <re_irc> <@dirbaio:matrix.org> const generics add new problems such as the PZ123 thing

16:19 <re_irc> <@therealprof:matrix.org> It is part of the solution because you maintain the efficiency of a direct implementation without the cognitive and maintenance overhead of a multiple thousand lines long macro.

16:20 <re_irc> <@dirbaio:matrix.org> embassy unifies all STM32 HALs without const generics

16:20 <re_irc> <@dirbaio:matrix.org> and it doesn't have the PZ123 problem

16:20 <re_irc> <@dirbaio:matrix.org> nor the AF200 problem

16:20 <re_irc> <@thejpster:matrix.org> What's the PZ123 thing?

16:21 <re_irc> <@dirbaio:matrix.org> if you do `struct Pin<const PORT: char, const PIN: u8>`, then `Pin<'Z', 123>` is a valid type, when it shouldn

16:21 <re_irc> <@dirbaio:matrix.org> same as `AlternateFunction<const AF: u8>`, you can have AF200 which makes no sensse

16:21 <re_irc> <@dirbaio:matrix.org> the stm32-rs problems aren't caused by lack of const generics

16:22 <re_irc> <@thejpster:matrix.org> I see.

16:23 <re_irc> <@thejpster:matrix.org> What does embassy do then?

16:24 <re_irc> <@dirbaio:matrix.org> `trait Pin { fn port() -> u8, fn pin() -> u8 }`

16:25 <re_irc> <@dirbaio:matrix.org> then generate `PA1, PA2...` singletons, impl Pin for them

16:25 <re_irc> <@dirbaio:matrix.org> also do `struct AnyPin { pin_port: u8 }`, impl Pin for it

16:25 <re_irc> <@dirbaio:matrix.org> then you build everything on top of Pin

16:25 <re_irc> <@dirbaio:matrix.org> `struct Input<P: PIn>`, impls InputPin

16:25 <re_irc> <@dirbaio:matrix.org> `struct Output<P: PIn>`, impls OutputPin

16:25 <re_irc> <@dirbaio:matrix.org> etc

16:26 <re_irc> <@dirbaio:matrix.org> - no `PZ123` problem

16:26 <re_irc> <@dirbaio:matrix.org> - No copypaste between concrete `PA1` and type-erased `AnyPin`, everything such as`Input` and `Output` etc Just Works with both

16:27 <re_irc> <@thejpster:matrix.org> So the pin mode is a type containing the pin, rather than having a pin containing the mode as a ZST?

16:27 <re_irc> <@dirbaio:matrix.org> yep

16:27 <re_irc> <@dirbaio:matrix.org> `PA1` represents ownership of PA1, in an "unconfigured" state

16:27 <re_irc> <@thejpster:matrix.org> How do you deal with IP block versioning?

16:28 <re_irc> <@thejpster:matrix.org> As in F4 has GPIO v4 and F3 has GPIO v1.3, or whatever

16:28 <re_irc> <@dirbaio:matrix.org> `Input<PA1>` represents owneship of PA1, configured as input

16:28 <re_irc> <@dirbaio:matrix.org> and you can create an `Input` with a `&mut PA1` too if you want to use it as input only temporarily

16:29 <re_irc> <@dirbaio:matrix.org> GPIO is identical in all stm32's except F1

16:29 <re_irc> <@dirbaio:matrix.org> but for other stuff

16:29 <re_irc> <@dirbaio:matrix.org> there's cfg's to pull in the right driver

16:29 <re_irc> <@dirbaio:matrix.org> https://github.com/embassy-rs/embassy/blob/master/embassy-stm32/src/usart/mod.rs#L3

16:30 <re_irc> <@dirbaio:matrix.org> the source of truth is these yamls https://github.com/embassy-rs/stm32-data/blob/main/data/chips/STM32F030CC.yaml#L622

16:30 <re_irc> <@dirbaio:matrix.org> so you don't need 1000s of handwritten lines to wire up everything in Rust

16:31 <re_irc> <@dirbaio:matrix.org> these yamls are generated from XMLs from stm32cube, so they're correct (they're MUCH more reliable than SVDs)

16:32 theJPster has joined #rust-embedded

16:33 theJPster has quit [Changing host]

16:33 theJPster has joined #rust-embedded

16:34 <re_irc> <@dirbaio:matrix.org> once you have that, you write impls for UARTv1, UARTv2 and GPIO

16:34 <re_irc> <@dirbaio:matrix.org> and everything gets wired up automatically according the yamls

16:34 theJPster has left #rust-embedded [#rust-embedded]

16:34 <re_irc> <@dirbaio:matrix.org> which GPIO pins are usable for which USARTx in which AF, etc

16:35 <re_irc> <@dirbaio:matrix.org> and boom, you get USART support for ALL stm32 chips

16:35 <re_irc> <@dirbaio:matrix.org> it's wayyyyyyy more maintainable

16:35 <re_irc> <@jamesmunns:matrix.org> I'm going to start streaming to do an update on the PowerBus stuff, probably more hardware than firmware this week, but feel free to come hang out if that's your kind of thing:

16:35 <re_irc> <@jamesmunns:matrix.org> Off topic:

16:36 <re_irc> <@jamesmunns:matrix.org> https://youtu.be/1qF0x7jpfs0

16:38 <re_irc> <@dirbaio:matrix.org> but

16:38 <re_irc> <@dirbaio:matrix.org> it gets dismissed as "reinventing the wheel" 🤷‍♂️

16:41 <re_irc> <@lulf_:matrix.org> dirbaio:matrix.org: I think this part is undercommunicated and we can do a better job with examples of how to use it without the embassy “runtime”

16:42 <re_irc> <@dirbaio:matrix.org> yeah, we could do better "marketing"

16:42 <re_irc> <@lulf_:matrix.org> I do websites this week 😅

16:42 <re_irc> <@dirbaio:matrix.org> what's embassy? "async for embedded" or "next-gen embedded hals"?

16:42 <re_irc> <@dirbaio:matrix.org> (that as part of being "next gen", support async in addition to the classic blocking)

16:44 <re_irc> <@dirbaio:matrix.org> also therealprof I *would* work on contributing stuff to stm32-rs to unify the HALs to make them maintainable if you didn't dismiss my work as "reinventing the wheel"

16:44 <re_irc> <@dirbaio:matrix.org> the reason why I'm doing the work on embassy instead of stm32-rs is I don't feel it's welcome in stm32-rs, with you as a maintainer dismissing it

16:45 <re_irc> <@lulf_:matrix.org> Though I have little experience with existing HALs, I find the “peripheral version centric” structure very sensible when I see how easily one can reuse gpio, spi etc implementations across the different stm32 families with barely adding any special code for each.

16:46 <re_irc> <@dirbaio:matrix.org> stm32-rs needs two things

16:46 <re_irc> <@dirbaio:matrix.org> 1. unifying the HALs

16:47 <re_irc> <@dirbaio:matrix.org> 2. cleaning up the HALs (mostly changing from ubermacros to generics)

16:47 <re_irc> <@dirbaio:matrix.org> doing 2 without doing 1 first is a giant waste of time, it's literally 15x the work

16:48 <re_irc> <@dirbaio:matrix.org> and doing 1 HAS to be a "clean break": start a new HAL with a structure that accomodates per-IP-version organization, then port over all the functionality until it has caught up with the legacy HALs

16:49 <re_irc> <@dirbaio:matrix.org> there's no way to do that while maintaining backwards compatibiltiy

16:49 <re_irc> <@dirbaio:matrix.org> the wheel HAS to be reinvented

16:49 <re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: You're interpreting the world in your own unique way. Nothing I can say will stop you from misrepresenting me and my words so I'm not going to even try and give up.

16:51 <re_irc> <@firefrommoonlight:matrix.org> I tried patching the stm32yxx HALS and moved on when my issues and PRd went ignored for weeks-months. Started fresh when it became the only viable option

16:52 <re_irc> <@firefrommoonlight:matrix.org> A less discussed downside is their code is generally poorly documented

16:53 <re_irc> <@firefrommoonlight:matrix.org> Ie not something you can easily QC against a RM. And have more code related to obfuscating abstractions than documented reg writes

16:53 <re_irc> <@dirbaio:matrix.org> therealprof: as a stm32 maintainer: do you agree the stm32yxx-hals have to be unified, yes or no?

16:53 <re_irc> <@firefrommoonlight:matrix.org> They will never be suitable for a commercial or otherwise serious project without ground-up rewrites and leadership changes

16:53 <re_irc> <@therealprof:matrix.org> Yes, I agree. And I mentioned it some minutes ago.

16:54 <re_irc> <@dirbaio:matrix.org> okay, we're on the same page on that

16:54 <re_irc> <@therealprof:matrix.org> And BTW: I am one of *many* maintainers of *parts* of the repos in the org.

16:54 <re_irc> <@dirbaio:matrix.org> next question: how do you propose we proceed with the unifying

16:55 <re_irc> <@dirbaio:matrix.org> firefrommoonlight has explored making a unified HAL on top of the existing stm32-rs PACs

16:55 <re_irc> <@dirbaio:matrix.org> embassy has explored making a unified HAL by unifying the PACs first

16:55 <re_irc> <@therealprof:matrix.org> People are using the legacy interfaces, any approach that will preserve those interfaces will work.

16:56 <re_irc> <@firefrommoonlight:matrix.org> Btw, even though I took a diff approach, I think the Embassy approach of unifying PACs for STM32 is great. The only reason I don't use it is never having been comfortable with Async with workflows

16:56 <re_irc> <@dirbaio:matrix.org> how are you going to preserve the interfaces if stm32f4xx-hal and stm32f7xx-hal GPIO interfaces are completely incompatible?

16:57 <re_irc> <@therealprof:matrix.org> As mentioned the F4 has been refactored in a backwards compatible way and also as mentioned I see that as a possible options to come to generic GPIO driver.

16:57 <re_irc> <@firefrommoonlight:matrix.org> Probably from being burned in JS and Python and no giving it a fait shake in Rust/embedded

16:57 <re_irc> <@dirbaio:matrix.org> okay, another example, the H7 hal handles peripheral `new()` in a completely different way than other HALs

16:57 DepthDeluxe has quit [Ping timeout: 260 seconds]

16:58 <re_irc> <@therealprof:matrix.org> No doubt there different APIs out there.

16:58 <re_irc> <@dirbaio:matrix.org> so

16:58 <re_irc> <@dirbaio:matrix.org> you're saying the unified HAL must be a drop-in replacement for *all* legacy stm32yxx-hals

16:59 <re_irc> <@dirbaio:matrix.org> backwards-compatible with every single different API flavor?

16:59 <re_irc> <@therealprof:matrix.org> In a way.

16:59 <re_irc> <@lulf_:matrix.org> That seems a bit contradictory... they don't even have the same interface even today

16:59 <re_irc> <@dirbaio:matrix.org> that's not feasible

16:59 <re_irc> <@dirbaio:matrix.org> and you know it

17:00 <re_irc> <@therealprof:matrix.org> The only thing I know is that this is not a greenfield situation.

17:00 <re_irc> <@dirbaio:matrix.org> and it also strikes me as contradictory with the fact that almost every stm32-rs release is semver-major

17:01 <re_irc> <@dirbaio:matrix.org> stm32f4xx-hal is at 0.9, so there's been 8 semver-breaking releases

17:01 <re_irc> <@lulf_:matrix.org> therealprof:matrix.org: I'm curious why you say that. Afaict, there are not many 'production' users of rust embedded anyway?

17:01 <re_irc> <@therealprof:matrix.org> Any new PAC is semver incompatible, so yes.

17:01 <re_irc> <@dirbaio:matrix.org> and the const-generics GPIO will have to be released as 0.10 because it is NOT semver-compatible even if you say "the F4 has been refactored in a backwards compatible"

17:02 <re_irc> <@therealprof:matrix.org> lulf_:matrix.org: As was pointed out a few pages ago, people keep on using stm32-rs HALs instead of going embassy or other alternatives despite them being arguably better.

17:03 <re_irc> <@almindor:matrix.org> i don't think we need to be backwards compatible, I'd for one love things like GPIO "stack" be unified over hals even if it meant a breaking change from existing stuff

17:04 <re_irc> <@lulf_:matrix.org> therealprof:matrix.org: Embassy HALs haven't really stabilized until recently, and I think we can do a better way of showing its use with non-async as well. Maybe that will help. I think it suffers a bit with users wanting to use whatever seems the most official

17:04 <re_irc> <@almindor:matrix.org> we're not even on v1+ backwards compatibility is meaningless right now (provided you keep the versioning logical)

17:05 <re_irc> <@ryan-summers:matrix.org> As both a maintainer, contributor, and production user of stm32h7xx-hals, I can confirm we really would like backward compat of any rewrites, and rust is definitely used in production.

17:05 <re_irc> <@ryan-summers:matrix.org> It's also unfair to put all of this on therealprof

17:05 <re_irc> <@firefrommoonlight:matrix.org> H7xx is easily the nicest

17:05 <re_irc> <@dirbaio:matrix.org> it's backwards compat XOR unified hal

17:06 <re_irc> <@ryan-summers:matrix.org> That being said, I think the best approach is to just go greenfield for now and see if you can make something better

17:06 <re_irc> <@almindor:matrix.org> when you say backwards compatible, let's first define that. Are we talking at level of embedded-hal traits, or at level of individual xyz-hal crates and their "organizational" logic? (e.g. accessing GPIOs from resources and so on)

17:06 <re_irc> <@ryan-summers:matrix.org> If that proves true, the ecosystem starts shifting. The problem is, there's already a lot of apps using the existing HALs that won't be able to merge without significant financial investment

17:06 <re_irc> <@ryan-summers:matrix.org> And a lot of companies won't want to do that

17:07 <re_irc> <@dirbaio:matrix.org> the new HAL would impl the e-h traits of course

17:07 <re_irc> <@ryan-summers:matrix.org> That's only relevant on the interface to e.g. peripheral drivers

17:07 <re_irc> <@dirbaio:matrix.org> the breakages would be in the part that's not covered by the e-h traits

17:07 <re_irc> <@dirbaio:matrix.org> gpio/uart/spi/i2c setup etc

17:07 <re_irc> <@ryan-summers:matrix.org> From the perspective of an app using stm32h7xx-hal as a dep, the e-h isn't super relevant

17:07 <re_irc> <@ryan-summers:matrix.org> I still would need to rewrite our whole repo to use the new APIs

17:07 <re_irc> <@ryan-summers:matrix.org> and I don't think I could sell that

17:08 <re_irc> <@ryan-summers:matrix.org> So we'd probably just keep using the existing stm32h7xx-hal for example

17:08 <re_irc> <@ryan-summers:matrix.org> Unless, as was mentioned, it _was_ a perfect replacement, which we've already stated is pretty much impossible

17:08 <re_irc> <@dirbaio:matrix.org> is gpio+peripheral setup such a high % of your code?

17:08 <re_irc> <@ryan-summers:matrix.org> So at this point, given it's not a greenfield implementation, I think you need to be okay with taking the hit of diverging

17:08 <re_irc> <@ryan-summers:matrix.org> It's definitely non-trivial

17:09 <re_irc> <@therealprof:matrix.org> lulf_:matrix.org: Nothing is really officially blessed by the WG. The existing crates have earned their reputation by existing for some time and being usable "enough", alternative approaches will have to do the same. Stability is a definitely a reputation concern, it's hard to build trust when reinwhenting the wheel is the name of the game.

17:09 <re_irc> <@dirbaio:matrix.org> therealprof: newcomers see "stm32-rs" and they go "Okay, that's THE rust stm32 hal"

17:09 <re_irc> <@ryan-summers:matrix.org> From Quartiq's perspective, all of the code in https://github.com/quartiq/stabilizer/tree/master/src/hardware would have to be rewritten

17:09 <re_irc> <@firefrommoonlight:matrix.org> ryan-summers:matrix.org: Yea - I don't use EH at all in my projects, and it's feature-gated in HAL

17:10 <re_irc> <@almindor:matrix.org> the e-h traits only help with drivers IMO

17:10 <re_irc> <@almindor:matrix.org> not board unifying at all

17:10 <re_irc> <@ryan-summers:matrix.org> ^ And that's what it was designed for

17:10 <karlp> well, I'm going to push up the last of what I've managed to fix on my way, but I've got no more time to put into this experiment. I was _very_ happy with some of how this has gone, but too much has been too much pain.

17:10 <re_irc> <@dirbaio:matrix.org> also you could mix stm32-unified-hal with stm32h7xx-hal

17:10 <re_irc> <@almindor:matrix.org> for board/mcu level stuff I think we should implement a new "hal"

17:10 fabic has joined #rust-embedded

17:10 <re_irc> <@dirbaio:matrix.org> having a "graceful transition period"

17:10 <re_irc> <@dirbaio:matrix.org> you can definitely mix stm32-rs and embassy hals today

17:11 <re_irc> <@ryan-summers:matrix.org> You could, but it's just more work on our end honestly

17:11 <re_irc> <@dirbaio:matrix.org> using unsafe to steal stuff, just making sure you don't use the same peripheral with both at the same time

17:11 <re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: Uhm, stm32-rs contains a wild assortment of things. I have zero issue with you putting an "embassy-hal" in there.

17:11 <re_irc> <@ryan-summers:matrix.org> I think you need to be okay with the fact that not everyone would transition

17:11 <re_irc> <@dirbaio:matrix.org> therealprof:matrix.org: such "thing I would put there" would be the unified hal, which you just said MUST be backwards compatible with all HALs

17:11 <re_irc> <@dirbaio:matrix.org> so you DO have issues with it

17:12 <re_irc> <@almindor:matrix.org> is the problem unifying something like "I need physical pin2 of this thing" or are we talking something else?

17:12 <re_irc> <@dirbaio:matrix.org> ryan-summers:matrix.org: yeah, but at least the rust embedded would have a solid value proposition to newcomers that are not already invested in the legacy HALs

17:12 <re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: Again you're misrepresenting me.

17:12 <re_irc> <@ryan-summers:matrix.org> I would argue it already does

17:12 <re_irc> <@dirbaio:matrix.org> the current stm32-rs HALs are driving people away from Rust

17:13 <re_irc> <@ryan-summers:matrix.org> I would soundly disagree personally

17:13 <re_irc> <@ryan-summers:matrix.org> No one is forced to use a HAL if they don't like it

17:13 <re_irc> <@ryan-summers:matrix.org> In fact in C, you often never have a HAL in the first place

17:13 <re_irc> <@lulf_:matrix.org> How about creating something like stm32-rs/stm32-unified-hal

17:13 <re_irc> <@ryan-summers:matrix.org> So the HAL is purely value added, and you can work around it and work register-level whenever you want anyways

17:14 <re_irc> <@ryan-summers:matrix.org> I do that a lot when HALs don't expose all the stuff I need

17:14 <re_irc> <@therealprof:matrix.org> lulf_:matrix.org: I kind of just proposed that. 😉

17:14 <re_irc> <@dirbaio:matrix.org> ryan-summers:matrix.org: see the conversation with karlp above 🤷

17:15 <re_irc> <@lulf_:matrix.org> Ok, so what I mean by that is that == embassy-stm32

17:15 <re_irc> <@dirbaio:matrix.org> and it's a recurring thing in this channel

17:15 <re_irc> <@lulf_:matrix.org> and just move it there

17:15 <re_irc> <@therealprof:matrix.org> lulf_:matrix.org: Yes.

17:15 <re_irc> <@lulf_:matrix.org> wdyt about that dirbaio ?

17:16 <re_irc> <@lulf_:matrix.org> maybe it would increase adoption/visibility for people wanting to take part

17:16 <re_irc> <@lulf_:matrix.org> (i haven't given a thought how easy/hard it would be to move it yet)

17:18 <karlp> ryan: I cna't really just skip the hal, not without a lot more investment. I need the bluetooth stack, which depends on the hal, but the hal causes pain. I could rewrite chunks of it, but the goal was "look, rust is advanced, I can write my _application_ and _not_ spend my time rewriting hal-type-layering foundational blobs"

17:19 <re_irc> <@dirbaio:matrix.org> - What about the older HALs? Are they deprecated? Which one should newcomers use? Which one should contributors contribute to?

17:19 <re_irc> <@dirbaio:matrix.org> - What about the decision making process? For example embassy-stm32 has typestate-less GPIO, which therealprof has spoken very strongly against that in the past.

17:20 <re_irc> <@almindor:matrix.org> could we maybe split this problem into parts and document the issues separately? I feel like a lot will just get lost here if we keep it matrix only

17:20 <re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: Nope, those will continue to exist.

17:20 <re_irc> <@dirbaio:matrix.org> The problem is not whether the hal is under the embassy org or the stm32-rs org

17:21 <re_irc> <@therealprof:matrix.org> > - What about the decision making process? For example embassy-stm32 has typestate-less GPIO, which therealprof has spoken very strongly against that in the past.

17:21 <re_irc> <@therealprof:matrix.org> You have free reign about everything.

17:21 <re_irc> <@almindor:matrix.org> well I see a couple mentioned 1. GPIO traits/structure 2. deprecation strategy/making onboarding new users easier 3. similar mcu hal unification strategy

17:22 <re_irc> <@dirbaio:matrix.org> The problem is newcomers trying to use the legacy stm32xxx-hals and getting frustrated

17:23 <re_irc> <@dirbaio:matrix.org> newcomer learning effort will still go to stm32xxx-hal and get wasted

17:23 <re_irc> <@dirbaio:matrix.org> contributor effort will still go to stm32xxx-hal and get wasted

17:23 <re_irc> <@almindor:matrix.org> I'm just proposing to split this into subissues make something more permanent like github issues and keep a civil discussion there, at least on the higher level, otherwise I feel like this will just fizz out and nothing will get done

17:23 <re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: You said it's a visibility problem because everything unter stm32-rs is automatically blessed. You might as well take the advantage. 😛

17:25 <re_irc> <@dirbaio:matrix.org> yeah but there's still the old HALs with more stars and more downloads and no "this HAL is deprecated" message

17:25 <re_irc> <@therealprof:matrix.org> (and of course I shouldn't make too many promises here since it's Adams org)

17:26 <re_irc> <@dirbaio:matrix.org> so newcomers will still use those

17:27 <re_irc> <@lulf_:matrix.org> Re: the existing HALs, whatever people want to maintain is their choice, also what users want to use. However, having the unified hal in the stm32-rs org I think signals that this is an stm32-rs community thing and not async only etc, and also lower the barrier for trying it out

17:27 <re_irc> <@thejpster:matrix.org> dirbaio:matrix.org: The current stm32 HALs are driving me away from STM32.

17:27 <re_irc> <@lulf_:matrix.org> Ultimately, examples and docs are important as well

17:28 <re_irc> <@dirbaio:matrix.org> the purpose of unifying the HALs is avoiding wasting effort in maintaining 15 HALs in parallel

17:28 <re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: I told you that those HALs need to remain compatible. But if embassy HALs are really the greatest thing since sliced bread then people will quickly adopt it and everything HALs will be declared deprecated in favour of the better approach.

17:28 <re_irc> <@dirbaio:matrix.org> if you add the new unified HAL but don't deprecate the old HALs now you're mainaining 16 HALs in parallel

17:28 <re_irc> <@firefrommoonlight:matrix.org> Hey, this isn't a giant problem

17:28 <re_irc> <@dirbaio:matrix.org> it does NOT solve the problem

17:29 <re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: No, I'm maintaining 3 HALs, and you maintain 1 HAL.

17:29 <re_irc> <@lulf_:matrix.org> dirbaio:matrix.org: sure, people are free to use their time as they wish. I think unified-hal will demonstrate its advantages over time

17:29 <re_irc> <@dirbaio:matrix.org> it's still wasted effort

17:29 <re_irc> <@dirbaio:matrix.org> you+me could maintain 1 HAL

17:29 <re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: I somehow doubt that.

17:29 <re_irc> <@firefrommoonlight:matrix.org> I'm not convinced TRP maintains any HALs

17:30 <re_irc> <@dirbaio:matrix.org> if there's N people using rust+stm32, this one HAL would get the work from N people

17:30 <re_irc> <@dirbaio:matrix.org> currently we have 15 HALs getting the work from N/15 people

17:30 <re_irc> <@henrik_alser:matrix.org> What amazes me is how these inconsistencies be a reason to drive people away from embedded rust while the C competition has NONE of the above and is way behind in this regard, despite having 40 years head start

17:31 <re_irc> <@dirbaio:matrix.org> henrik_alser: with the C STM32 HALs you can write a function that configures a pin by number. With the Rust stm32xxx-hals you have to write a macro or copypaste the code for each pin

17:31 <re_irc> <@dirbaio:matrix.org> they're WORSE than C's in many aspects

17:32 <re_irc> <@firefrommoonlight:matrix.org> henrik_alser Good point. I think there just isn't much interest in Rust embedded atm

17:32 <re_irc> <@dirbaio:matrix.org> and these aspects are immediately and painfully obvious to people trying to switch from C to Rust

17:32 <re_irc> <@firefrommoonlight:matrix.org> And I expect that to change gradually over the next few years

17:32 <re_irc> <@lulf_:matrix.org> dirbaio:matrix.org: I share your frustration in this, but again people are free to decide what they want to spend time on. We just have to make stm32-unified-hal seem like the better way to spend the time, but that also takes time :)

17:33 <re_irc> <@henrik_alser:matrix.org> For me the experience was the opposite

17:33 <re_irc> <@lulf_:matrix.org> anyone got any extra time to hand me, let me know :)

17:33 <re_irc> <@dirbaio:matrix.org> so

17:35 <re_irc> <@henrik_alser:matrix.org> I can’t imagine going back to my ~20 years with C

17:35 <re_irc> <@henrik_alser:matrix.org> Ymmv

17:35 <re_irc> <@henrik_alser:matrix.org> :D

17:35 <re_irc> <@firefrommoonlight:matrix.org> IMO Dirbaio and I have already solved this

17:35 <re_irc> <@dirbaio:matrix.org> so, therealprof agrees the stm32 hals should be unified, agrees they're not maintainable in the current state, but doesn't want to deprecate them in favor of a unified HAL

17:36 <re_irc> <@firefrommoonlight:matrix.org> And the answer is just to incrementally improve functionality and documentation on these, for Async and non respectively

17:36 <re_irc> <@dirbaio:matrix.org> "make a stm32 unified HAL" is a solved problem

17:36 <re_irc> <@thejpster:matrix.org> dirbaio: I feel you'll have more success here if you stop dragging other people

17:36 fabic has quit [Remote host closed the connection]

17:36 <re_irc> <@thejpster:matrix.org> work the problem, not the people

17:36 <re_irc> <@dirbaio:matrix.org> There's 2 problems

17:36 <re_irc> <@dirbaio:matrix.org> 1. make a unified hal => SOLVED

17:37 <re_irc> <@dirbaio:matrix.org> 2. Newcomers to Rust see 3+ competing HALs and the ones that looks "more official" are the worst maintained => NOT SOLVED

17:37 <re_irc> <@dirbaio:matrix.org> I'm trying to solve problem 2

17:38 <re_irc> <@thejpster:matrix.org> OK, so where do newcomers see this?

17:38 <re_irc> <@dirbaio:matrix.org> google "stm32f4 rust", you get stm32f4xx-hal

17:38 <re_irc> <@firefrommoonlight:matrix.org> Sounds like a SEO issue!

17:39 <re_irc> <@thejpster:matrix.org> OK, so all you have to do is do better in the google rankings

17:39 <re_irc> <@firefrommoonlight:matrix.org> I think the answer is to publish content demonstrating what you built

17:39 <re_irc> <@thejpster:matrix.org> Hell, buy stm32-rust.org and write all about it

17:40 <re_irc> <@dirbaio:matrix.org> that would be quite hostile IMO

17:40 <re_irc> <@firefrommoonlight:matrix.org> Publish source code for a project you made, either a DIY demo or something commercial

17:40 <re_irc> <@dirbaio:matrix.org> the solution is: have the ecosystem agree on one HAL, invest efforts in make that the best one, deprecate the others

17:40 <re_irc> <@dirbaio:matrix.org> the thing is I gain nothing from people using embassy instead of stm32-rs hals

17:40 <re_irc> <@firefrommoonlight:matrix.org> I think competition is important

17:40 <re_irc> <@firefrommoonlight:matrix.org> For drawing out the best features and new ideaa

17:40 <re_irc> <@thejpster:matrix.org> but that's the problem. you can't force what other people do.

17:41 <re_irc> <@dirbaio:matrix.org> Why would I invest effort in SEO and making shady domains trying to position embassy as the "official stm32 rust" project?

17:41 <re_irc> <@dirbaio:matrix.org> I'm pointing out that this is bad for the *rust embedded ecosystem*

17:41 <re_irc> <@dirbaio:matrix.org> therefore it's in the *rust embedded ecosystem*'s interest to fix it

17:41 <re_irc> <@dirbaio:matrix.org> it's not bad *for me*

17:41 <re_irc> <@dirbaio:matrix.org> I'm shipping stuff with embassy just fine

17:42 <re_irc> <@firefrommoonlight:matrix.org> I don't mean SEO in a manipulative way. I mean publish content. Get those backlinks legitimately

17:42 <re_irc> <@dirbaio:matrix.org> why would I invest time in that? As I said, I have zero commercial interes in people using embassy

17:42 <re_irc> <@xiretza:xiretza.xyz> thejpster:matrix.org: aww man, stm32.rs is already taken by ST

17:42 <re_irc> <@dirbaio:matrix.org> I have commercial interest in embassy *existing* so I can use it to ship stuff, that's it

17:43 <re_irc> <@dirbaio:matrix.org> so I bring it up to the wider rust embedded community

17:43 <re_irc> <@dirbaio:matrix.org> but the community wants to do nothing about it

17:43 <re_irc> <@henrik_alser:matrix.org> (My point was, how come newcomers have so much higher demands for the Rust ecosystem while at the same time having no problems with all the crap associated with C?)

17:43 <re_irc> <@dirbaio:matrix.org> the ones that have the "authority" (hard authority or soft authority) to improve this don't

17:44 <re_irc> <@dirbaio:matrix.org> henrik_alser: as I said the current HALs are worse than C's in many things

17:45 <re_irc> <@firefrommoonlight:matrix.org> dirbaio:matrix.org: This is all you need!

17:45 <re_irc> <@dirbaio:matrix.org> yeah

17:45 <re_irc> <@firefrommoonlight:matrix.org> At least, that's how I look at it. I have a robust platform that let's me build whatever I want

17:45 <re_irc> <@dirbaio:matrix.org> but then people will keep coming to this channel with stm32-rs hal issues

17:45 <re_irc> <@dirbaio:matrix.org> struggling with the ubermacros

17:45 <re_irc> <@firefrommoonlight:matrix.org> For existing, planned, and non-yet-planned projects. I couldn't do what I needed with what existed, so I fixed that

17:45 <re_irc> <@dirbaio:matrix.org> and they'll give up and tell their engineering teams and bosses "Rust embedded sucks, let's stick with C"

17:47 <re_irc> <@dirbaio:matrix.org> and once you hear that from a coworker

17:47 <re_irc> <@dirbaio:matrix.org> rust is dead for you

17:47 <re_irc> <@dirbaio:matrix.org> you won't look "oh maybe it was the *HAL* that sucked, not Rust, and oh look! there are other HALs!"

17:47 <re_irc> <@firefrommoonlight:matrix.org> I agree that's a concern. It's easy to conflate the ecosystem with Rust if you're new. It took me a while to separate then

17:48 <re_irc> <@dirbaio:matrix.org> you won't try Rust again *at all*

17:51 <re_irc> <@thejpster:matrix.org> OK, but why are people finding the 'classic' stm32-hals instead of this new one?

17:52 <re_irc> <@thejpster:matrix.org> one answer to that might be the Discovery book.

17:52 <re_irc> <@thejpster:matrix.org> Although isn't that changing to use the nRF5x Micro Bit?

17:52 <re_irc> <@dirbaio:matrix.org> yep that's a very official "blessing" from the REWG

17:52 <re_irc> <@firefrommoonlight:matrix.org> There was a Reddit Rust post yesterday where a newcomer worried Rust's easy dependency management would lead to abuse and bloat. It does! But this isn't a fault in the language; just how some people use it. Solution: Use rust, and don't use dependencies that are bloated it have too many sub deps

17:52 <re_irc> <@henrik_alser:matrix.org> dirbaio:matrix.org: I prefer every second of it compared to my WAY longer C history, but maybe it’s just me then :)

17:52 <re_irc> <@thejpster:matrix.org> Not really. It was basically the only thing that existed when jorge wrote it

17:54 <re_irc> <@dirbaio:matrix.org> henrik_alser: you prefer it now that you've learned all the workarounds with macro tricks and stuff :D

17:54 <re_irc> <@dirbaio:matrix.org> yes many (most) things are way better in Rust hals than C hals

17:54 <re_irc> <@dirbaio:matrix.org> but the basic things such as GPIO should be "at least as good"

17:55 <re_irc> <@dirbaio:matrix.org> something as basic as obtaining the GPIO singletons and configuring 5 pins as exti input without copypasting the same code 5 times

17:56 <re_irc> <@xiretza:xiretza.xyz> honestly I prefer typed GPIOs over untyped ones - how often do I really have to select *any* GPIO at runtime?

17:56 <re_irc> <@dirbaio:matrix.org> - You have to know what "extension traits" are (GpioExt) to call .split(). You search the docs for GPIOA and you do *not* see `.split()` listed as a method. Discoverability in the docs is *awful*

17:57 <re_irc> <@dirbaio:matrix.org> - You have to be fairly proficient in generics to use the typestates

17:57 <re_irc> <@almindor:matrix.org> I agree to ^ it was definitely a blocker to me when I started

17:58 <re_irc> <@almindor:matrix.org> it's still scary when I switch platforms since each one does it slightly differently

17:58 <re_irc> <@dirbaio:matrix.org> - Then you finally get it working for the 5 pins, copypasting the same code 5 times

17:58 <re_irc> <@firefrommoonlight:matrix.org> I even forked the nRF HAL to avoid the GPIO syntax

17:58 <re_irc> <@dirbaio:matrix.org> - You then want to DRYfy that code, by making a "setup GPIO" function and calling it 5 times. And surprise, YOU CAN'T. AT ALL.

17:58 <re_irc> <@dirbaio:matrix.org> You have to write A MACRO

17:58 <re_irc> <@thejpster:matrix.org> I agree split/constrait are a terrible API and it is poorly discoverable. I don't, however, have a particular need to set my IO pins in a for loop.

17:59 <re_irc> <@firefrommoonlight:matrix.org> Have y'all read the Rust Docs for an Stm32 or nRF GPIO module?

17:59 <re_irc> <@thejpster:matrix.org> I much prefer it when the compiler tells me that I've got a pin wrong.

17:59 <re_irc> <@dirbaio:matrix.org> Macros are the MOST CURSED thing of Rust. And one of the value propositions of Rust to C devs should be "throw away all the C preprocessor/macro shit because you have a real type system now"

17:59 <re_irc> <@dirbaio:matrix.org> and still

17:59 <re_irc> <@dirbaio:matrix.org> one of the FIRST things you see with stm32xx-hals is "you can't do this without macros at all"

18:01 <re_irc> <@dirbaio:matrix.org> thejpster:matrix.org: you can still get full type-level safety while still not having the giant papercuts I'm describing above

18:02 <re_irc> <@thejpster:matrix.org> and still set the I/O pins in a for loop?

18:02 <re_irc> <@dirbaio:matrix.org> what do you mean?

18:02 <re_irc> <@xiretza:xiretza.xyz> thejpster:matrix.org: yeah, I'm curious how that would work

18:03 <re_irc> <@thejpster:matrix.org> dirbaio:matrix.org: ^^

18:03 <re_irc> <@thejpster:matrix.org> Can you DRYfy code with the embassy HAL?

18:04 <re_irc> <@firefrommoonlight:matrix.org> Someone new to Rust posted this gem of GPIO code yesterday: https://github.com/caemor/epd-waveshare/issues/49#issuecomment-916589039

18:04 <re_irc> <@firefrommoonlight:matrix.org> Questions on why GPIO typestates as implemented are unsat!

18:06 <re_irc> <@firefrommoonlight:matrix.org> Docs: https://docs.rs/stm32l4xx-hal/0.6.0/stm32l4xx_hal/gpio/index.html

18:06 <re_irc> <@dirbaio:matrix.org> thejpster:matrix.org: sure you can

18:06 <re_irc> <@dirbaio:matrix.org> ```rust

18:06 <re_irc> <@dirbaio:matrix.org> fn main() -> ! {

18:06 <re_irc> <@dirbaio:matrix.org> #[cortex_m_rt::entry]

18:06 <re_irc> <@dirbaio:matrix.org> info!("Hello World!");

18:06 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/355e127a703a26aed3e5679d3941aaaf5dbb6a4e3776dc167dfa7dd7e0c86ca9 (17 lines)

18:07 <re_irc> <@dirbaio:matrix.org> - No `.split()`, no need to know what "extension traits" are

18:07 <re_irc> <@dirbaio:matrix.org> - No `.into_af6_push_pull(&mut gpioc.moder, &mut gpioc.otyper, &mut gpioc.afrh);`

18:07 <re_irc> <@dirbaio:matrix.org> - No copypaste between concrete (PA4) and type-erased (AnyPin) pins

18:09 <re_irc> <@thejpster:matrix.org> If I make an SPI object, can I restrict at compile time which pins you can pass to it?

18:10 <re_irc> <@dirbaio:matrix.org> Yep!

18:10 <re_irc> <@dirbaio:matrix.org> #[cortex_m_rt::entry]

18:10 <re_irc> <@dirbaio:matrix.org> fn main() -> ! {

18:10 <re_irc> <@dirbaio:matrix.org> ```rust

18:10 <re_irc> <@dirbaio:matrix.org> info!("Hello World!");

18:10 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/b67654b628eab35a14ac5199590dda4418a7454908e87211d8a9a494899e7d21 (24 lines)

18:10 <re_irc> <@dirbaio:matrix.org> Spi::new takes `impl SckPin` and co

18:10 <re_irc> <@henrik_alser:matrix.org> I don’t mean the Rust hals are fine as is and i truly support all these unifying efforts, i just mean i think it’s interesting why C can get away with any crap associated with it while details like this can be a dealbreaker for choosing Rust

18:11 <re_irc> <@dirbaio:matrix.org> so if you try to create an SPI with the wrong pins, it won't build

18:11 DepthDeluxe has joined #rust-embedded

18:11 <re_irc> <@dirbaio:matrix.org> and also interesting: no `.into_alternate_af5()`. SPI switches it to the right AF automatically

18:11 <re_irc> <@dirbaio:matrix.org> there's no typestates for AFs at all

18:11 <re_irc> <@dirbaio:matrix.org> they're useless, AFs are a SPI implementatino detail

18:11 <re_irc> <@dirbaio:matrix.org> you just do "Gimme an SPI with these pins", it does the right thing

18:12 <re_irc> <@thejpster:matrix.org> How about if the README for your HAL acknowledges the existences of stm32-rs and links to it, and we ask the stm32-rs devs to put a link in each HAL readme to your "unified" HAL?

18:12 <re_irc> <@thejpster:matrix.org> Does that solve the discoverability issue?

18:12 <re_irc> <@dirbaio:matrix.org> 🤷

18:12 <re_irc> <@dirbaio:matrix.org> maybe

18:12 <re_irc> <@thejpster:matrix.org> It doesn't involve deprecation or telling people their code sucks. It just improves discoverability, and allows the best ideas to get the most visibility.

18:17 <re_irc> <@dkhayes117:matrix.org> Embedded rust was very hard when I first started and there are still things about it that make me scratch my head. Despite that, I really enjoy using it, and much rather use it than C.

18:17 <re_irc> <@dkhayes117:matrix.org> The unifying hal sounds like the way to go.

18:17 <re_irc> <@dirbaio:matrix.org> You get people that have been coding in C forever, and probably have even limited C++ experience

18:18 <re_irc> <@dirbaio:matrix.org> so they're learning Rust (borrow checker, generics, traits...) AND rust embedded at the same time

18:18 <re_irc> <@dirbaio:matrix.org> while the people writing HALs are proficient rust experts

18:18 <re_irc> <@dkhayes117:matrix.org> Macros are what I hate the most, except for writing tests

18:19 <re_irc> <@dirbaio:matrix.org> current HALs make insanely extensive use of generics, typestates, traits, extension traits (and yeah... macros), which is OK for a rust expert

18:19 <re_irc> <@dirbaio:matrix.org> but is absolutely brutal for a newcomer

18:20 <re_irc> <@dirbaio:matrix.org> and there's no reason whatsoever to use such advanced things

18:20 <re_irc> <@dirbaio:matrix.org> embassy uses only basic generics (traits, generics with trait bounds)

18:21 <re_irc> <@dirbaio:matrix.org> and is still equally type-safe as stm32-rs hals

18:21 <re_irc> <@dirbaio:matrix.org> No typestates, no extension traits, no const generics, no ubermacros

18:21 <re_irc> <@dkhayes117:matrix.org> Riscv could be a good platform for change, much less production users, buy has a high ceiling. At least me thinks so. 😄

18:22 <re_irc> <@dirbaio:matrix.org> it seems to me sometimes it's a "when you have a hammer everything looks like a nail" problem

18:22 <re_irc> <@dirbaio:matrix.org> Rust has typestates, so let's put typestates in EVERYTHING

18:23 <re_irc> <@dirbaio:matrix.org> and now the latest fancy hammer we have is const generics

18:23 <re_irc> <@thalesfragoso:matrix.org> Wow, seems a lot of discussion happened, haven't read it, but let me share a quick opinion:

18:23 <re_irc> <@thalesfragoso:matrix.org> stm32-rs' HALs probably made the right choices for the time they were written, I started my rust journey with them and it wasn't bad, some boilerplate, but I really don't mind that.

18:23 <re_irc> <@thalesfragoso:matrix.org> embassy-stm32 could leveraged all the baggage learned from all of that and decided to turn things upside down, the real change isn't in the HAL itself, far from it, we actually re-used a lot of code from stm32-rs' HALS. The real catch is in svd2rust, by removing singletons, which in turn allowed the HAL to use "freestyle" singletons to not need `split` and family. It also went the route of...

18:23 <re_irc> ... "hand-crafted" registers definitions, which allowed the HAL to work better for different devices families

18:23 <re_irc> <@dirbaio:matrix.org> so let's rewrite GPIO to use typestates AND const generics!

18:23 <re_irc> <@dirbaio:matrix.org> Surely newcomers from C will appreciate that!

18:24 <re_irc> <@thalesfragoso:matrix.org> Neither of them sucks

18:24 <re_irc> <@thalesfragoso:matrix.org> In the end we just be discussing svd2rust instead of the HAL, because most of the changes in embassy-stm32 were only possible because of that

18:29 <re_irc> <@thalesfragoso:matrix.org> Of course, embassy-stm32 also had some good ideas by itself, the `Unborrow` trait that allows for drivers to not store all pin type-states because we don't need to free them, since the user can provide just a borrow instead of owned types

18:30 <re_irc> <@thalesfragoso:matrix.org> And some other ideas that maybe aren't a clear win for some people, like the driver configuring the pin itself instead of expecting the user to configure it

18:32 <re_irc> <@thalesfragoso:matrix.org> Which means that the driver must de-configure it on drop, otherwise the user don't have the correct pin configured type stated

18:32 <re_irc> <@thalesfragoso:matrix.org> Which in turns means that `mem::forget` can leave people a bit confused

18:33 <re_irc> <@dkhayes117:matrix.org> dirbaio when you start on RV embassy, I will be happy to help however I can. mabez mentioned some people he knows is working up a new esp32-c3 dev board 😁

18:33 <re_irc> <@dirbaio:matrix.org> porting the executor to riscv should be trivial

18:34 <re_irc> <@dirbaio:matrix.org> the hart part is async hals

18:34 <re_irc> <@thalesfragoso:matrix.org> dirbaio:matrix.org: maybe not the "InterruptExecutor"

18:34 <re_irc> <@dirbaio:matrix.org> but there's no reason "async hal that works with embassy" has to be part of the embassy project

18:34 <re_irc> <@thalesfragoso:matrix.org> I'm still to understand how interrupts really works on riscv, it seems that it might be different from chip to chip

18:35 <re_irc> <@dirbaio:matrix.org> I am definitely planning to look at the esp32-c3 though :D :D

18:35 <re_irc> <@dirbaio:matrix.org> I have one in the mail coming

18:37 <re_irc> <@newam:matrix.org> thalesfragoso:matrix.org: There is no NVIC/GIC equivalent, so your interrupt controller is always vendor defined. At the lower levels it works the same way.

18:38 <re_irc> <@thalesfragoso:matrix.org> yeah, but even the interrupt vector itself seem a bit different and vendor defined

18:39 <re_irc> <@newam:matrix.org> Oh, interesting. That would make life difficult.

18:40 <re_irc> <@newam:matrix.org> In what ways are they different?

18:41 <re_irc> <@thalesfragoso:matrix.org> But don't take me too serious, I didn't dig it too much

18:41 <re_irc> <@thalesfragoso:matrix.org> just tried to use riscv-rt for interrupts and got real lost

18:41 <re_irc> <@thalesfragoso:matrix.org> and went to read some manuals on the gd32v which probably got me a bit confused w.r.t all this

18:43 <re_irc> <@dirbaio:matrix.org> isn't htere a few standard interrupt controller "models"?

18:43 <re_irc> <@thalesfragoso:matrix.org> IIRC there was 2 models, yeah

18:43 <re_irc> <@dirbaio:matrix.org> so you could add support for each and be "done"?

18:47 <re_irc> <@thalesfragoso:matrix.org> anyway, lunch time is over, back to work. But remember, stm32-rs and embassy-stm32 should be friends, and we probably should discuss (again) removing singletons from svd2rust and make it all unsafe, and probably add a pac implementations that behaves like today's pac, so adam can keep not using HALs without needing unsafe everywhere

18:52 <re_irc> <@thalesfragoso:matrix.org> or maybe stm32-rs can just change to use stm32-metapac and stm32-data once they're more complete

18:52 <re_irc> <@almindor:matrix.org> dkhayes117:matrix.org: I'm definitely open to changes here. The hal is not too complex we should be able to "Test out" some of the new unifying concepts in riscv-land. The SPI change was a big success for example (at least in my book)

18:53 <re_irc> <@almindor:matrix.org> as for GPIO I agree that anything outside of Input/Output state is useless, the driver/user will switch to what they need, but that's a separate issue I guess.

18:57 <re_irc> <@almindor:matrix.org> for GPIO specifically I think we should consider writing a proposal for the new API. There are a lot of things a good GPIO wrapper should do e.g. `GPIO.pin_physical(usize)` to get a physical pin, or `GPIO.pin_spi_sck(usize)` to get SPIx clock pin etc. We did a lot of these things with macros. I wrote them, and I still hit my head on them

18:58 <re_irc> <@almindor:matrix.org> this goes deeper into specific board crates too

18:59 <re_irc> <@dirbaio:matrix.org> embassy generates the singletons from the yamls in stm32-data

18:59 <re_irc> <@almindor:matrix.org> we could use something like that sure

18:59 <re_irc> <@almindor:matrix.org> main thing is to provide the expected interface definition and list of accessors (in this specific case)

19:00 <re_irc> <@dirbaio:matrix.org> so you can do a `foreach pin that exists { struct $pin {... } }`

19:00 <re_irc> <@dirbaio:matrix.org> but ALWAYS making the codegen'd structs "dumb". JUST the singleton, no functionality

19:00 <re_irc> <@dirbaio:matrix.org> so there's no actual "logic" code inside the macro-generated code

19:01 <re_irc> <@dirbaio:matrix.org> ONLY one trait impl, then everything else is non-macro code using the traits

19:01 <re_irc> <@dirbaio:matrix.org> it's like

19:01 <re_irc> <@dirbaio:matrix.org> you take the YAML, which is like a "database" describing the chip

19:01 <re_irc> <@almindor:matrix.org> it's sad that traits don't support const fn yet

19:02 <re_irc> <@dirbaio:matrix.org> and you "translate" that to the "database" of the rust type system

19:02 <re_irc> <@almindor:matrix.org> I mean the yaml approach makes it possible to just do this directly, you could just codegen rust code so it's more readable

19:02 <re_irc> <@dirbaio:matrix.org> and then the HAL makes use of that via trait bounds

19:03 <re_irc> <@almindor:matrix.org> i just wished we could have trait X { const fn accessor() }

19:04 <re_irc> <@dirbaio:matrix.org> yea

19:04 <re_irc> <@dirbaio:matrix.org> it's been proposed but it's not likely to happen soon

19:05 <re_irc> <@dirbaio:matrix.org> in practice the compiler will inline and const-propagate everything though, so you're not losing performance

19:05 <re_irc> <@almindor:matrix.org> true, so on top of the yaml generator we could have things like trait GpioSpiPins, trait GpioI2CPins etc.

19:06 <re_irc> <@almindor:matrix.org> combine with const generics and you can get what I described above

19:06 <re_irc> <@dirbaio:matrix.org> for example embassy's `Pin` trait has `port*16 + pin`, and everything else is calculated from that

19:06 <re_irc> <@dirbaio:matrix.org> https://github.com/embassy-rs/embassy/blob/master/embassy-stm32/src/gpio.rs#L439-L451

19:06 <re_irc> <@dirbaio:matrix.org> to get the register address it needs to do some maths

19:06 <re_irc> <@dirbaio:matrix.org> but if you do `.set_high()` on a concrete pin type such as PA5, the compiler inlines everything

19:07 <re_irc> <@dirbaio:matrix.org> it ends up compiled as `*CONST_ADDR = const_value`

19:07 <re_irc> <@dirbaio:matrix.org> same as the macro-based gpios

19:07 <re_irc> <@dirbaio:matrix.org> *you don't need const generics* for this!!

19:08 <re_irc> <@dirbaio:matrix.org> let's stop putting const generics in everything just because it's the new shiny hammer we just got :D

19:09 <cr1901> This but without a hint of irony

19:11 gsalazar_ has quit [Ping timeout: 260 seconds]

19:12 <cr1901> The moment you bless a shiny new feature, lots of ppl will use it whether they actually need it or not.

19:12 <re_irc> <@dirbaio:matrix.org> I wasn't being ironic

19:12 <cr1901> Oh... sorry

19:12 <re_irc> <@dirbaio:matrix.org> I legit think typestates are ultra overused (and now const generics)

19:13 <re_irc> <@dirbaio:matrix.org> in places where *you don't need them* and make the APIs much harder to learn and unergonomic

19:13 <re_irc> <@dirbaio:matrix.org> it's like when Go was new

19:13 <re_irc> <@dirbaio:matrix.org> everything was FULL of goroutine/channel spaghetti

19:13 <cr1901> (What's a typestate?)

19:13 <cr1901> Hard to tell in general, because the reception I saw to const generics was "it was an unmitigated good"

19:14 <re_irc> <@dirbaio:matrix.org> it is good for array lenghts

19:14 <re_irc> <@dirbaio:matrix.org> it is not good for pin numbers

19:14 <re_irc> <@dirbaio:matrix.org> or peripheral addresses

19:14 <re_irc> <@dirbaio:matrix.org> which are uses people are legit proposing

19:15 <cr1901> https://docs.rust-embedded.org/book/static-guarantees/typestate-programming.html typestate programming?

19:15 <re_irc> <@dirbaio:matrix.org> or even shipping

19:15 <re_irc> <@dirbaio:matrix.org> builders are overused too

19:16 <re_irc> <@dirbaio:matrix.org> everything you can do with a builder you can do with a `#[non_exhaustive]` Config struct

19:16 <re_irc> <@dirbaio:matrix.org> with 5x less lines of code

19:16 <cr1901> I'm asking if that's what you meant by >(3:12:54 PM) re_irc: <@dirbaio:matrix.org> I legit think typestates are ultra overused

19:17 <re_irc> <@dirbaio:matrix.org> `Pin<Analog>`

19:17 <re_irc> <@dirbaio:matrix.org> `Pin<Input<Floating>>`

19:17 <re_irc> <@dirbaio:matrix.org> `Pin<Input<PullUp>>`

19:17 <re_irc> <@dirbaio:matrix.org> `Pin<Input<PullDown>>`

19:17 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/dc351bbc86523144929f00f2beb71acf3b277fcd34b845b82c9a3959af424e98 (7 lines)

19:18 <re_irc> <@dirbaio:matrix.org> these typestates

19:19 <re_irc> <@dirbaio:matrix.org> or stuff like Foo<Initialized>, Foo<Enabled>, Foo<Disabled>

19:19 <re_irc> <@dirbaio:matrix.org> *you don't need them at all*

19:20 <re_irc> <@xiretza:xiretza.xyz> how are the pin types in embassy defined? every pin does have its own type, right?

19:23 <re_irc> <@dirbaio:matrix.org> There's a struct for each pin, like `PA5`, and a type-erased `AnyPin` struct

19:25 <re_irc> <@dirbaio:matrix.org> and an `Input<T>` and an `Output<T>` driver, and that's it. No typestates on the pin structs

19:29 DepthDeluxe has quit [Ping timeout: 252 seconds]

19:31 <re_irc> <@pinealservo:matrix.org> You don't *need* types on pins, either. Wanting various things to be apparent in the type system is a preference that's going to vary. I really like seeing different approaches to satisfying these preferences being explored, but I get really turned off by people talking crap about the alternatives other than their preferred one.

19:33 <re_irc> <@almindor:matrix.org> I didn't mean const generics by the numbers I just meant pin numbers as mapped for given use case

19:33 <re_irc> <@almindor:matrix.org> so e.g. GPIO.pin_physical(1) becomes GPIO.pin6 or something while GPIO.pin_spi_sck(0) becomes GPIO.pin10

19:37 <re_irc> <@almindor:matrix.org> with a generator we could avoid the const number problem to and just opt for something like GPIO.pin_physical_1() etc. it'd make things super straightforward, if not nice to look at

19:38 <re_irc> <@dirbaio:matrix.org> yeah, when eg SPI can only use some pins and not others, you need them to be different types

19:38 <re_irc> <@almindor:matrix.org> the return type should be the specific actual Pin

19:39 <re_irc> <@almindor:matrix.org> so GPIO.pin_physical1() == GPIO.pin5 == GPIO.pin_spi_sck_0() or such

19:39 <re_irc> <@dirbaio:matrix.org> you lose compile-time checking if you make all pins `struct Pin { num: u8 }`

19:39 <re_irc> <@dirbaio:matrix.org> you do *not* lose compile-time checking by removing the typestates though

19:39 <re_irc> <@almindor:matrix.org> no no each pin its own type for things like Spi::new(PINS) where PINS enforces the right combo

19:39 <re_irc> <@dirbaio:matrix.org> so imo the sweet spot is "individual type per pin yes, typestates no"

19:39 <re_irc> <@almindor:matrix.org> state is useless

19:40 <re_irc> <@almindor:matrix.org> each peripheral abstraction or driver should switch their pins to what they need and we should always consider them as unknown state

19:45 <re_irc> <@pinealservo:matrix.org> "state is useless" is a bad take, and "each peripheral abstraction or driver should switch their pins" is just not going to fly in all scenarios either. Any simplifying assumptions you make are going to be vehemently disagreed with by people with legitimate use cases. Not saying you shouldn't make them, but you can't expect that you're going to bring everyone along with you.

19:46 <re_irc> <@almindor:matrix.org> they can keep using the old hals, I'm not forcing anything

19:46 <re_irc> <@dirbaio:matrix.org> State is useless in types

19:47 <re_irc> <@dirbaio:matrix.org> Why would you care whether it's `Pin<Input<Floating>>` or `Pin<Input<PullUp>>`?

19:47 <re_irc> <@almindor:matrix.org> but it really makes sense to prepare state in the outer context before handing off resources to the user/driver

19:47 <re_irc> <@dirbaio:matrix.org> it's an input, you can read from it

19:47 <re_irc> <@almindor:matrix.org> s/sense/no sense/

19:48 <re_irc> <@dirbaio:matrix.org> same for `Pin<Output<PushPull>>` vs `Pin<Output<OpenDrain>>`

19:48 <re_irc> <@almindor:matrix.org> why should the main() be concerned with switching pin5 to "iof0" (named differently on each setup btw) before handing that pin over to Spi::new ?

19:49 <re_irc> <@dirbaio:matrix.org> one usecase for distinguising is i2c MUST be opendrain, so in today's HALs typestates are used by the SPI driver to force the user to set the pin to OpenDrain

19:49 <re_irc> <@dirbaio:matrix.org> BUT

19:49 <re_irc> <@dirbaio:matrix.org> if the i2C driver knows it has to be OpenDrain, why can't it switch it itself?

19:49 <re_irc> <@dirbaio:matrix.org> you're forcing the user to write useless boilerplate

19:49 <re_irc> <@almindor:matrix.org> yes exactly, that's my whole point

19:49 <re_irc> <@dirbaio:matrix.org> it doesn't make the HAL any safer

19:50 <re_irc> <@dirbaio:matrix.org> just harder to use

19:50 <re_irc> <@almindor:matrix.org> if you're consuming or borrowing (mutably) a resource, it's your playground

19:50 <re_irc> <@pinealservo:matrix.org> I'm not saying that's an invalid perspective, I'm just saying it's not the only one.

19:50 <re_irc> <@almindor:matrix.org> I think the alternative which is currently "mainstream" was a mistake that just got used too much

19:51 <re_irc> <@almindor:matrix.org> this typestate concept is basically a coincidental rustism

19:51 <re_irc> <@dirbaio:matrix.org> a proverbial hammer :)

19:51 <re_irc> <@pinealservo:matrix.org> I agree that not everyone needs or wants the typestate stuff, so I'm happy that you're working on alternatives.

19:52 <re_irc> <@xiretza:xiretza.xyz> not really applicable in this case, but forcing the consumer to do the setup unconditionally means you may do unnecessary work

19:52 <re_irc> <@almindor:matrix.org> also AFAIK the typestate is not part of embedded-hal in any form, it's just a strange standard that got adopted by the implementors

19:52 <re_irc> <@almindor:matrix.org> copy paste fossil

19:52 <re_irc> <@dirbaio:matrix.org> one register write that takes one clock cycle, and only at program startup? it's negligible

19:53 <re_irc> <@xiretza:xiretza.xyz> dirbaio:matrix.org: exactly

19:53 <re_irc> <@dirbaio:matrix.org> plus how often do you destruct+construct the i2c like that? you usually construct it once, so you're doing the "set as opendrain" once both with and without typestates

19:54 <re_irc> <@almindor:matrix.org> if you have a peripheral controller or driver construction in hot path I suspect the design is non-standard at best, but I'm open to being shown a good use case with this kind of problem

19:54 <re_irc> <@dirbaio:matrix.org> and if it's such a hot path and you really really need the optimization you'll use the PAC directly

19:55 <re_irc> <@almindor:matrix.org> also, in those cases you can code your way out of it by splitting construction from init

19:55 <re_irc> <@dirbaio:matrix.org> SPI/i2C construction alerady does many other expensive things that you'll want to get rid of too

19:55 <re_irc> <@dirbaio:matrix.org> for example it often calculates baudrates/dividers/frequencies, which often involve expensive divisions

19:55 dcz has quit [Ping timeout: 260 seconds]

19:56 <re_irc> <@pinealservo:matrix.org> So, a while back, I wrote a bunch of drivers for a family of chips that would eventually get integrated into a project using some 3rd party runtime that I had no access to or information about for about the first half of the project. Turned out that the integration required separating out all the initialization stuff so it could go in the system startup vs. the "driver" interface. If I'd baked either...

19:56 <re_irc> ... way into my interfaces, I'd have been up a creek at integration time.

19:56 <re_irc> <@dirbaio:matrix.org> if you're creating/destroying your SPI in a hot loop you're gonna have a bad time

19:57 <re_irc> <@dirbaio:matrix.org> with or without typestates :D

20:00 <re_irc> <@eldruin:matrix.org> hmm I have not followed the discussion, and cannot discuss right now, but that about drivers configuring their own resources seems non-tenable to me. It makes sense that configuring (read: transform/modify the nature of) a resource requires more power/knowledge than merely using it. For me it does not seem obvious at all that a generic piece of software (e.g. a driver) should need to know about how to...

20:00 <re_irc> ... configure a pin to be an output. I would rather prioritize code that needs to know _less_, not _more_

20:00 <re_irc> <@dirbaio:matrix.org> the "drivers" we're talking about are the in-hal drivers such as i2c, spi, uart

20:01 <re_irc> <@dirbaio:matrix.org> stm32f4 i2c driver can change stm32f4 pins to opendrain no problem

20:01 <re_irc> <@dirbaio:matrix.org> hal-independent drivers take `T: OutputPin/InputPin` which the user has to manually configure with the HAL, that makes total sense

20:01 <re_irc> <@almindor:matrix.org> yes, the states are input/output, any "functional switched pins" are out keeping it simple. any top level driver should be ok with input or output

20:01 <re_irc> <@eldruin:matrix.org> ok, I call that MCU peripherals

20:02 <re_irc> <@dirbaio:matrix.org> the "mcu peripheral driver"

20:02 <re_irc> <@dirbaio:matrix.org> yeah terminology is confusing :D

20:02 <re_irc> <@eldruin:matrix.org> alright that makes sense

20:02 <re_irc> <@eldruin:matrix.org> anyway the discussion seemed pretty heated

20:03 <re_irc> <@dirbaio:matrix.org> that was the stm32 unified HAL, which is something else :D

20:04 <re_irc> <@eldruin:matrix.org> I see there are a bunch of people passionate about the success of Rust in embedded here but I think the tone needs to be lowered an inch

20:04 <re_irc> <@eldruin:matrix.org> we are all in for the same thing

20:13 <re_irc> <@dirbaio:matrix.org> I've been repeatedly accused of "forking by default", "reinventing the wheel" and "not caring about the community" 🤷‍♂️

20:13 <re_irc> <@oddstr13:matrix.org> dirbaio:matrix.org: Can confirm, Arduino -> embedded rust is a major pain. I'm longing for the the point where embedded rust is as mature as the Arduino ecosystem!

20:13 <re_irc> <@oddstr13:matrix.org> As for which package to pick, I tend to look at downloads, last updated and dependents on crates.io and github.

20:13 <re_irc> <@oddstr13:matrix.org> As for promoting the HAL you think is best, just make a good collection of examples to copypasta from. That's how people probably are used to doing things coming from Arduino (or stackoverflow 😆).

20:17 <re_irc> <@dkhayes117:matrix.org> I have no pronlem with *reinventing the wheel* if we get a better wheel 🙂

20:17 <re_irc> <@oddstr13:matrix.org> https://psion.agg.io/_matrix/media/r0/download/matrix.org/VFFDQzWlCzczvalVuuSuJfvl/image.png

20:18 <re_irc> <@oddstr13:matrix.org> dirbaio: and, yes, things like this is downright exhausting when first starting to learn a new language and ecosystem, all the boilerplate 😭

20:19 <re_irc> <@almindor:matrix.org> I wonder if peripheral drivers that use GPIO should just take the pins out themselves now :D

20:19 <re_irc> <@almindor:matrix.org> Spi::new(p.GPIO) with possibly a "which SPI" selection

20:20 <re_irc> <@pinealservo:matrix.org> The "Arduino -> embedded rust" leap is crossing both a language and and abstraction level boundary; we don't really have anything that's aiming to be equivalent to Arduino yet.

20:20 <re_irc> <@dirbaio:matrix.org> almindor: that works if SPI2 can only use a fixed set of pins

20:20 <re_irc> <@almindor:matrix.org> right, the CS problem

20:20 <re_irc> <@oddstr13:matrix.org> almindor: nah, that doesn't sound like a good idea, some chip allows 3+ I2C peripherals on any pins

20:20 <re_irc> <@almindor:matrix.org> gt run bb in 20

20:20 <re_irc> <@dirbaio:matrix.org> in most MCUs there's at least some choice, like SPI1 CLK can pick 1 out of 4-8 pins

20:20 <re_irc> <@dirbaio:matrix.org> and in some there's full choice: in nrf (almost) all peripherals can use any pin for any function

20:20 <re_irc> <@pinealservo:matrix.org> Arduino to standard embedded C or C++ can be a pretty daunting leap itself.

20:21 <re_irc> <@almindor:matrix.org> the way I rewrote it for the e310x-hal was to split Spi bus from SpiDevice as GrantM11235 suggested, it works nicely

20:22 <re_irc> <@therealprof:matrix.org> pinealservo:matrix.org: I don't think "being like Arduino" is a desirable outcome.

20:22 <re_irc> <@almindor:matrix.org> anything I saw for C embedded was always terribad

20:22 <re_irc> <@almindor:matrix.org> we're leaps ahead already, just a bit tedious at places

20:23 <re_irc> <@oddstr13:matrix.org> pinealservo:matrix.org: Keyword here being «yet», I think it should be a goal to get the rust ecosystem up to a state where you could point a noob at it and say it's just as easy to get started as with Arduino, while also being more suited production

20:23 <re_irc> <@dirbaio:matrix.org> lol, Arduino does make lots of choices that do sacrifice performance for ease of use

20:23 <re_irc> <@almindor:matrix.org> oddstr13:matrix.org: there's a ton of IDE level abstraction in the arduino land, we'd have to either build something like that, or be compatible to it which, I think is unattainable

20:24 <re_irc> <@dirbaio:matrix.org> Rust embedded will never be as easy as arduino

20:25 <re_irc> <@dirbaio:matrix.org> Well I guess you could make a HAL specifically with the goal of "being as easy as Arduino but in Rust"

20:25 <re_irc> <@oddstr13:matrix.org> almindor: I actually think that vscode + embedded rust is getting close to what Arduino was 10-15 years ago

20:25 <re_irc> <@dirbaio:matrix.org> but it probably wouldn't be a good hal for "production" use

20:26 <re_irc> <@almindor:matrix.org> I'm not sure I want to go where arduino is today tbh. it's just so hazy on what's happening. Similar with things like "freedom studio" from sifive etc.

20:26 <re_irc> <@almindor:matrix.org> huge abstractions on top of even bigger "tools" that are super cumbersome and hard to properly understand (when it comes to how it works at least)

20:27 <re_irc> <@newam:matrix.org> Arduino is generally not suitable for production because of expensive abstractions to make the hardware sort of work the same (re-labeling pins as 0-13, A0-5 for example). I see rust as a competitor for things like STM32-Cube, Atmel studio, and other vendor-provided C/C++ ecosystems that are suitable for production.

20:28 <re_irc> <@newam:matrix.org> I don't think there is anything necessarily wrong about leaving the embedded newcomer problem to projects like Arduino and circuit python.

20:28 <re_irc> <@therealprof:matrix.org> "ease of use" is very relative. It's outright oversimplified which causes a ton of hidden issues, especially for uncommon chips.

20:28 <re_irc> <@almindor:matrix.org> therealprof:matrix.org: +1, and when you do hit an actual upstream snag you're stuck completely

20:29 <re_irc> <@almindor:matrix.org> I think we can get very "easy to start with" if we standardize the "how" of implementing the main embedded-hal for each mcu

20:29 <re_irc> <@oddstr13:matrix.org> Well, I guess what I want from Arduino is the ease of getting a project started, an extensive library of examples and so on

20:29 <re_irc> <@oddstr13:matrix.org> also the boilerplate stuff, reducing that would be great

20:31 <re_irc> <@newam:matrix.org> Rust is pretty much there, no? It took me just as long to get going with Arduino (back in 2009) as it did rust a year ago.

20:31 <re_irc> <@newam:matrix.org> That being said I know a lot more now, but it was pretty much install rustup, install probe rs, run example, vs install arduino IDE, run example. One extra step for rust isn't too bad.

20:31 <re_irc> <@pinealservo:matrix.org> Arduino being used in production is very much "scope creep"; it was originally intended to help artistic folks put some simple lights and servos in their art projects without having to really dive deep into embedded systems. And I think there's room for something that makes it really easy to do those sorts of things in Rust on top of the base abstractions that'd make porting the higher-level stuff to a...

20:31 <re_irc> ... lot of chips feasible.

20:32 <re_irc> <@oddstr13:matrix.org> newam:matrix.org: Indeed, This is starting to look like the Arduino examples! :3 https://github.com/embassy-rs/embassy/blob/master/examples/nrf/src/bin/uart.rs

20:33 <re_irc> <@pinealservo:matrix.org> A lot of the "magic" of Arduino was just scoping things really narrowly at first and shipping a set of stuff that worked together.

20:36 <re_irc> <@pinealservo:matrix.org> You had one MCU family, the base tools to work with it, a bootloader for the MCU, some easy-to-learn abstraction layers over some of the core peripherals, and a template project to start from that assumed you'd be doing really simplistic code. The "Arduino" ecosystem of today happened very gradually over a long period of time.

20:37 <re_irc> <@therealprof:matrix.org> True.

20:41 <re_irc> <@oddstr13:matrix.org> I guess the main pain-point for embedded rust *right now* is this weird state between embedded-hal 0.2 and 1.0, which bit me enough to put rust on the shelf for a while at least a couple of times now (one component implement one, but the other component implements only the other)

20:41 <re_irc> <@oddstr13:matrix.org> for me anyways

20:41 <re_irc> <@therealprof:matrix.org> I agree. We should definitely put a lid on and ship it finally.

20:42 <re_irc> <@oddstr13:matrix.org> trying to hook up the modem bits of particle boron/argon (some months ago) was very much not fun, and I spent a week getting nothing done and gave up

20:42 <re_irc> <@therealprof:matrix.org> It has been simmering for a long time, some things have been discussed and tossed over multiple times.

20:43 <re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: I'm aware, been following along for almost a year now (I think)

20:44 <re_irc> <@oddstr13:matrix.org> haven't been touching rust in a while, but when usb-uart hit nrf-hal, I couldn't help but play with it some :P

20:46 <re_irc> <@oddstr13:matrix.org> here's my playground for that, in case someone are interested in taking a look 🙈 https://github.com/oddstr13/rust-radio-usb-dongle/blob/master/src/main.rs

20:47 <re_irc> <@pinealservo:matrix.org> When it comes down to it, industrial embedded systems coding and hobby/prototype Arduino coding are very different use cases, and it's super difficult to design one set of development tools and libraries that are going to serve both of them well. I find it pretty impressive how well the embedded-wg folks have straddled the divide so far, but I think there will eventually need to be some higher-level...

20:47 <re_irc> ... thing for hobby stuff once there's more experience with the lower level stuff.

20:47 <re_irc> <@oddstr13:matrix.org> (I've messed a bit with the HAL to get async, so it won't run out of the box right now https://github.com/nrf-rs/nrf-hal/pull/355)

20:49 <re_irc> <@therealprof:matrix.org> Oooh, 802.15.4.

20:49 <re_irc> <@oddstr13:matrix.org> pinealservo:matrix.org: I personally think a good set of *stand-alone* examples will help at least some hobby/prototype people along quite a bit

20:50 <re_irc> <@therealprof:matrix.org> 6LoWPAN?

20:50 <re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: I'd love ZigBee, but I don't think we have that stack up and running properly yet

20:51 <re_irc> <@therealprof:matrix.org> ZigBee is tricky, I'd probably skip that and go straight to Thread.

20:52 <re_irc> <@oddstr13:matrix.org> I've got a small stack of IKEA TRÄDFRI stuff up and running with Home Assistant already, and I'd love to be able to get my own custom stuff hooked up to the same mesh

20:53 <re_irc> <@oddstr13:matrix.org> Thread is also an alternative, yea, altho I haven't been able to find much more documentation on that either. There's also that new IoT protocol from google and friends, I forget what it's named

20:54 <re_irc> <@oddstr13:matrix.org> oh, wait, Thread was the one with a NDA/don't share this file kinda thing to download the specs wasn't it?

20:54 <re_irc> <@dirbaio:matrix.org> smoltcp will soon get 6lowpan support! https://github.com/smoltcp-rs/smoltcp/pull/469

20:55 <re_irc> <@therealprof:matrix.org> oddstr13:matrix.org: Was called CHiP at some point. No idea what they're at at the moment.

20:55 <re_irc> <@dirbaio:matrix.org> Matter

20:55 <re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: There was at least one rename, yea >.<

20:55 <re_irc> <@therealprof:matrix.org> oddstr13:matrix.org: Uhm, that sounds more like ZigBee.

20:56 <re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: nah, ZigBee specs you can't even get without being a organization and joining the work group for a non-insignificant slump of money iirc

20:56 <re_irc> <@oddstr13:matrix.org> I could be mixing things up tho

20:58 <re_irc> <@oddstr13:matrix.org> Bit tired of the «this totally awesome, "open" standard» that you can't get your hands on without being a corporation

20:58 <re_irc> <@therealprof:matrix.org> Strike that. You have to accept an EULA for Thread.

20:59 <re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: yep, and the downloaded PDF is plastered with your name.

20:59 <re_irc> <@dirbaio:matrix.org> lol

20:59 <re_irc> <@therealprof:matrix.org> There's an open implementation but the specification is closed...

20:59 <re_irc> <@dirbaio:matrix.org> and you need CeRTiFicaTioN

21:00 <re_irc> <@oddstr13:matrix.org> wouldn't take too much to strip all that out, but just gimme a god damn well documented, actually open one that's also used by commercial products

21:00 <re_irc> <@ryan-summers:matrix.org> Sounds like USB with VIDs...

21:05 <re_irc> <@oddstr13:matrix.org> > «Matter, formerly Project Connected Home over IP (CHIP), is a proprietary, royalty-free home automation connectivity standard.» … «Although the Matter code repository is open-source under the Apache license, the Matter specification is licensed by CSA.»

21:05 <re_irc> <@oddstr13:matrix.org> Urgh, yep, yet another not really accessible protocol

21:05 <re_irc> <@dkhayes117:matrix.org> Have you heard of Wi-SUN?

21:06 <re_irc> <@oddstr13:matrix.org> can't say I have

21:06 <re_irc> <@dkhayes117:matrix.org> https://www.silabs.com/wireless/wi-sun

21:07 <re_irc> <@therealprof:matrix.org> Matter also has no interest of collaborating with other standardisation organizations. It's pretty much dominated by a fusion of the patent pool and existing implementation of the big whales...

21:09 <re_irc> <@dirbaio:matrix.org> matter works on wifi or iee802154+6lowpan, presumably the only "new" layer is the "application" layer

21:09 <re_irc> <@therealprof:matrix.org> ... and the management.

21:10 <re_irc> <@thejpster:matrix.org> newam:matrix.org: Arduino is not suitable for production because the core is LGPL

21:12 <re_irc> <@oddstr13:matrix.org> dkhayes117:matrix.org: I did a quick search, and it looks interesting, but sounds like it's in the same space as LoRaWAN?

21:12 <re_irc> <@oddstr13:matrix.org> A few nodes with low frequency/data rate per house kinda thing?

21:14 <re_irc> <@oddstr13:matrix.org> What I'm aiming for right now is more of the ZigBee kinda thing, with many devices per room (one per light, heating, sensors, window shutters etc)

21:15 <re_irc> <@dkhayes117:matrix.org> There are differences. Its been a while since I looked, there are great talks on both from Moores Lobby podcast

21:15 <re_irc> <@thejpster:matrix.org> If they can all hear each other, you can just use Enhanced Shock Burst

21:15 <re_irc> <@oddstr13:matrix.org> short-medium range, sensor readings at least once per minute

21:15 <re_irc> <@thejpster:matrix.org> Ferrous use it for the Decawave based rust workshops

21:17 <re_irc> <@oddstr13:matrix.org> the plan for initial implementation right now was actually something like UKHASnet; simple flood style mesh

21:17 <re_irc> <@oddstr13:matrix.org> https://ukhas.net/

21:18 <re_irc> <@therealprof:matrix.org> 6LoWPAN? 😉

21:18 <re_irc> <@oddstr13:matrix.org> already got a few 868MHz RFM69 radio nodes running that protocol, but it's more suited for lower frequency longer range stuff (same as lora)

21:19 <re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: I haven't looked enough into the specifics, but it's certainly been on my radar more than once

21:21 <re_irc> <@oddstr13:matrix.org> I'd still need to handle the mesh bit tho, which is what's nice about ZigBee – it's built into the protocol xD

21:21 <re_irc> <@oddstr13:matrix.org> https://en.wikipedia.org/wiki/6LoWPAN#Routing_considerations_and_protocols_for_mesh_topologies_in_6LoWPAN

21:32 <re_irc> <@therealprof:matrix.org> Yeah, OpenThread provide that on top.

21:33 <re_irc> <@therealprof:matrix.org> But you don't necessarily need the mesh if you want to cover one household.

21:41 <re_irc> <@jamesmunns:matrix.org> thejpster:matrix.org: The old (Decawave based) ones use 802.15.4 over the UWB radio, the newer ones use 802.15.4 over the 2.4GHz radio built in to the nrf52s

21:41 <re_irc> <@jamesmunns:matrix.org> but we just use "raw" 802.15.4 to do point-to-point packet transmission

21:41 <re_irc> <@thejpster:matrix.org> oh, my bad

21:41 <re_irc> <@jamesmunns:matrix.org> no worries :D

21:41 <re_irc> <@jamesmunns:matrix.org> It's been... two years since you gave that training?

21:42 <re_irc> <@jamesmunns:matrix.org> (how long has it been since the first Oxidize? 2019?)

21:42 <re_irc> <@thejpster:matrix.org> yes, 2019

21:42 <re_irc> <@jamesmunns:matrix.org> so yeah, close to 2.5 years

21:47 <re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: 4 floors (basement included), people moving around. I could possibly get away with one central master node, but I think it would be more reliable with a mesh topology of sorts.

21:47 <re_irc> <@oddstr13:matrix.org> Then we add the fact that I live on a farm, and that there's multiple buildings :P

21:48 <re_irc> <@dirbaio:matrix.org> time to implement RPL? 😜

21:48 <re_irc> <@oddstr13:matrix.org> not the typical household, and a bunch of space for fun wireless gadgets :3

21:51 <re_irc> <@oddstr13:matrix.org> dirbaio:matrix.org: That sounds like a relatively large project :P

21:51 <re_irc> <@dirbaio:matrix.org> indeed

21:52 <re_irc> <@therealprof:matrix.org> Yeah, I have also 4 floors with concrete floors; good old ZigBee (without repeaters) works just fine.

21:53 <re_irc> <@therealprof:matrix.org> In 6LoWPAN you can also increase the reach by throwing in more routers.

21:53 DepthDeluxe has joined #rust-embedded

21:53 <re_irc> <@oddstr13:matrix.org> therealprof:matrix.org: oh, but you most likely do have repeaters, even if it isn't used much

21:54 <re_irc> <@therealprof:matrix.org> No, the devices inbetween are connected to a hard switch and powered on only rarely.

21:55 <re_irc> <@oddstr13:matrix.org> https://psion.agg.io/_matrix/media/r0/download/matrix.org/cTsHSVodlJzgzXIouiHxoTIG/image.png

21:55 <re_irc> <@therealprof:matrix.org> So no repeating happening. E.g. right now with the kids in bed I can still control the lights just under the roof top. 😉

21:56 <re_irc> <@oddstr13:matrix.org> Anything with mains power acts as a repeater (if needed)

21:57 <re_irc> <@therealprof:matrix.org> Right, but they're not connected to mains power at the moment. 😉

22:07 <re_irc> <@oddstr13:matrix.org> dirbaio:matrix.org: Anyways, this looks like it may be a interesting alternative, thanks for the link!

22:07 <re_irc> <@dirbaio:matrix.org> :D

22:07 <re_irc> <@dirbaio:matrix.org> help is welcome, even if just testing!

22:08 <re_irc> <@dirbaio:matrix.org> It can talk to Linux fine, and the author has successfully tested it against Contiki too :D

22:09 <re_irc> <@therealprof:matrix.org> Hm, I just noticed the latest OpenWRT release still has support for the rotting Ci40 hardware...

22:11 <re_irc> <@therealprof:matrix.org> dirbaio:matrix.org: Using wireless or Ethernet? Which hardware?

22:11 <re_irc> <@dirbaio:matrix.org> to linux using ieee802154_hwsim

22:12 <re_irc> <@therealprof:matrix.org> I mean how was Contiki tested, simulator only?

22:13 <re_irc> <@dirbaio:matrix.org> Contiki was on real hardware *I think*, on this https://github.com/Zolertia/Resources/wiki/RE-Mote

22:14 <re_irc> <@dirbaio:matrix.org> both the smoltcp and contiki nodes

22:15 <re_irc> <@dirbaio:matrix.org> it'll be cool to get it up and running on nrf's :D

22:15 <re_irc> <@oddstr13:matrix.org> I've got a small stack of nRF52840 devices, so if I could use those to test… :P

22:16 <re_irc> <@therealprof:matrix.org> Ah, I know the Re-Mote.

22:16 <re_irc> <@adamgreig:matrix.org> omg, I go on holiday for one day 😭

22:16 <re_irc> <@therealprof:matrix.org> I do have the abandonware CreatorDev CI40 Kit lying around http://summit.riot-os.org/wp-content/uploads/2016/07/4-Hardware-Session-Imgtec-MIPS-Keno1.pdf

22:17 <re_irc> <@oddstr13:matrix.org> adamgreig: haha, welcome back to the 300 messages wall of text! 🙈

22:18 <re_irc> <@adamgreig:matrix.org> 💀

22:20 <re_irc> <@adamgreig:matrix.org> I'm still on holiday for a week, so please try to restrain yourselves to one fight a day

22:22 <re_irc> <@adamgreig:matrix.org> In seriousness, I should clarify that stm32-rs, in addition to obviously not being officially blessed by the wg in any sense, is basically a disparate group of separate projects; (almost) all the hals were started by one person and later asked to move into the org and retained autonomy which I don't interfere with, but I run the PAC project and am the only one with administrative access to the org

22:23 <re_irc> <@adamgreig:matrix.org> (started by different people, I should say)

22:24 <re_irc> <@adamgreig:matrix.org> So, it's not like there's some cabel behind the scenes deciding anything should be one particular way and enforcing everyone copy and pasted the ubermacros

22:25 <re_irc> <@adamgreig:matrix.org> Conversely there's no central planning and the hals developed at different times and more or less independently, which is the cause of the sorts of concerns identified earlier

22:26 <re_irc> <@adamgreig:matrix.org> I think it's fair to say they enjoy a first mover advantage in terms of popularity and perception of being the main active hals, but I think that same first mover effect is also why they have a lot of these issues that newer hals are much more easily able to identify and do something about

22:27 <re_irc> <@adamgreig:matrix.org> (embassy's stm32 pacs started by ingesting all the stm32-rs svds too, right?)

22:27 <re_irc> <@dirbaio:matrix.org> yep

22:28 <re_irc> <@adamgreig:matrix.org> I can't imagine successfully doing something like embassy-stm32 back in 2017 or whatever when f1xx-hal and f4xx-hal started; rust didn't even support generating no_std binaries on stable, many stm32 families didn't exist yet, etc etc, the aim was to get support going for just one family as best as people could imagine then

22:29 <re_irc> <@adamgreig:matrix.org> These days there are clearly much nicer ways to solve a lot of these problems and support all the stm32 families at once, and maybe it's clearer that it's worth doing too

22:34 <re_irc> <@adamgreig:matrix.org> I'm really not involved in the HALs and can't speak for them, all I know about is the PACs and svd2rust side of things, where I agree with thalesfragoso earlier about trying to bring some of the chiptool improvements back upstream

22:35 <re_irc> <@adamgreig:matrix.org> If people think the current hals need more unified leadership then perhaps we can work together with their various maintainers to organise something

22:36 <re_irc> <@adamgreig:matrix.org> I think their concerns around backwards compatibility are legitimate, the new HALs desires for interoperation and newer designs are good, and it doesn't worry me in the grand scheme of things to have multiple competing HALs either

22:37 <re_irc> <@adamgreig:matrix.org> But I appreciate the confusion for newcomers to rust and we could probably do a better job there, one way or another

22:38 <re_irc> <@adamgreig:matrix.org> It does seem unfair that people apparently don't have the same confusion between libopencm3 and stcubemx and chibios and freertos despite them all having very different and competing HALs in C, but I think that's just how it is with a new language alas

22:39 <re_irc> <@adamgreig:matrix.org> I'm monologuing too much and I don't want to restart the heated arguments from earlier so I'll leave it there I think, with a gentle reminder to everyone to assume good intentions and that we're all working to make embedded rust better

22:40 <re_irc> <@thalesfragoso:matrix.org> Tbh the change I proposed to svd2rust was more to allow different HALs to work together (by having a very simple crate just for the singletons shared by different HALs), and not to transform everything into a single HAL implementation

22:43 <re_irc> <@adamgreig:matrix.org> 👍 I was wondering if something along those lines could work well, e.g. a stm32-gpio-v1 crate that a bunch of HALs can re-export, as intermediate steps towards reducing code duplication without just outright scrapping everything for a new thing

22:43 <re_irc> <@adamgreig:matrix.org> The same model as is used for ethernet and usb and sdmmc etc

22:43 <re_irc> <@adamgreig:matrix.org> Certainly becomes much much easier with the new owned peripherals

22:44 <re_irc> <@dirbaio:matrix.org> The more I think about the "singletons" crate the more I think it won't work... HALs may want to split things differently

22:45 <re_irc> <@dirbaio:matrix.org> embassy splits pins, DMA channels, EXTI lines in the singletons

22:45 <re_irc> <@thalesfragoso:matrix.org> Yeah, I was thinking about that, but without it, using two different HALs become unsound :/

22:45 <re_irc> <@adamgreig:matrix.org> I guess I more meant having the lack of owned peripherals and just unsafe access

22:45 <re_irc> <@dirbaio:matrix.org> that's too opinionated to put in a "blessed singletons crate" to coordinate all HALs

22:46 <re_irc> <@dirbaio:matrix.org> ah just for safe PAC use? so it would be one singleton per SVD peripheral?

22:46 <re_irc> <@dirbaio:matrix.org> then aren't we back to the problems with the current PAC singletons?

22:46 <re_irc> <@adamgreig:matrix.org> dirbaio:matrix.org: You could probably work around it to some extent, like a DMA singleton that gets consumed if you want individual DMA channels instead or whatever, but it's not as clean

22:47 <re_irc> <@dirbaio:matrix.org> well, the purpose of pre-splitting was to reduce `.splt()` boilerplate

22:47 <re_irc> <@dirbaio:matrix.org> which is very confusing because you need an extension trait to do it, because the singleton is from another crate

22:47 <re_irc> <@adamgreig:matrix.org> Use features 🙈

22:48 <re_irc> <@dirbaio:matrix.org> you have to do `p.GPIOA.split()`, but you look up the docs for GPIOA (in the PAC) and the `split` methods in nowhere to be seen

22:49 <re_irc> <@dirbaio:matrix.org> features won't allow the crate to coordinate HALs that have done incompatible choices...

22:49 <re_irc> <@thalesfragoso:matrix.org> split is being dephased for some time now, giving space to a Gpio::new, etc

22:49 <re_irc> <@thalesfragoso:matrix.org> It's just that there is a lot of code using it, and you need some work to fix it

22:50 <re_irc> <@dirbaio:matrix.org> ah yeah nrf-hal does this

22:50 <re_irc> <@dirbaio:matrix.org> it's nicer, but not having to split at all is nicest

22:50 <re_irc> <@thalesfragoso:matrix.org> But I don't think anyone would oppose to remove split in favor of a new on a new type

22:51 <re_irc> <@thalesfragoso:matrix.org> Hmm, now Im thinking if the status quo is that bad ?

22:52 <re_irc> <@thalesfragoso:matrix.org> embassy-stm32 is already an alternative for people that want something different

22:52 <re_irc> <@dirbaio:matrix.org> yeah, it's probably how it's going to stay

22:53 <re_irc> <@thalesfragoso:matrix.org> embassy-stm32 plays with a lot of trade-offs that aren't a clear cut for everyone

22:53 <re_irc> <@dirbaio:matrix.org> we just have to release it, and \market it more :P

22:55 <re_irc> <@thalesfragoso:matrix.org> For people that just want to use the PAC for their chip, stm32-metapac is definitely not as nice as the current ones

22:55 <re_irc> <@adamgreig:matrix.org> With my wg hat on instead of the stm32-rs hat, it seems like some completion in HALs is not necessarily a bad thing

22:56 <re_irc> <@adamgreig:matrix.org> Certainly it is driving innovation in hal technology

22:56 <re_irc> <@dirbaio:matrix.org> yeah metapac's goal is just "support writing a cross-family hal"

22:56 <re_irc> <@thalesfragoso:matrix.org> We just need to get rid of the de-referenceable problem on svd2rust...

22:56 <re_irc> <@adamgreig:matrix.org> "check it out, our language is mature enough to have three different HALs for your chip, although admittedly the authors do all hang out in the same three matrix rooms"

22:57 <re_irc> <@adamgreig:matrix.org> As the pac maintainer I feel the metapac competition much more keenly :p

22:58 <re_irc> <@thalesfragoso:matrix.org> "And some maintainers are the same..."

22:58 <re_irc> <@adamgreig:matrix.org> Can't wait for stcubers, that will show us

23:00 <re_irc> <@dirbaio:matrix.org> the svd2rust derefereanceable fix will be a big breaking change D:

23:00 <re_irc> <@adamgreig:matrix.org> When I started stm32-rs, the typical thing was lots of separate PACs, one per svd file, with hand updated svd files, chunks copy pasted from each other

23:00 <re_irc> <@dirbaio:matrix.org> 😱

23:01 <re_irc> <@adamgreig:matrix.org> So there was an stm32f303 crate and so on, and i was like yep I should make one thing to do every stm32, and then once that's done I'll write one hal for them all using it

23:02 <re_irc> <@dirbaio:matrix.org> you'd have needed like 400 PACs :D

23:02 <re_irc> <@adamgreig:matrix.org> As usual if I knew then what I know now I probably wouldn't have started it but it's amusing how similar it is

23:02 <re_irc> <@adamgreig:matrix.org> I only split it into one pac per stm32 family because of the 10mb crates.io limit

23:03 <re_irc> <@adamgreig:matrix.org> The original plan was one single crate with all the PACs, which I guess I layer got to with stm32ral too

23:03 <re_irc> <@adamgreig:matrix.org> It sure seemed like writing a new hal was the next step at the time anyway

23:03 <re_irc> <@thalesfragoso:matrix.org> Hah, imagine the compile times...

23:03 <re_irc> <@adamgreig:matrix.org> It wouldn't be any worse would it? It's feature gated to a single device each time anyway

23:04 <re_irc> <@thalesfragoso:matrix.org> Hmm, yeah, only sad for docs.rs

23:04 <re_irc> <@adamgreig:matrix.org> In many ways stm32ral was an attempt to do automatically the shared identical structs of metapac

23:04 <re_irc> <@adamgreig:matrix.org> Anyway I finished my phd and got a job instead and didn't write the hal companion

23:05 <re_irc> <@adamgreig:matrix.org> So basically I am in favour of unified support :p

23:09 <re_irc> <@adamgreig:matrix.org> But I think it basically became apparent in 2018(19?) that a single unified hal was going to be very hard and in the meantime the per family HALs provided a lot of things that people wanted and were getting widely used and starting to use the single family PACs from stm32-rs instruct of single device PACs and HALs from before, so it made sense to create an org for them ( therealprof especially pushed for...

23:10 <re_irc> ... it), and people kept making new HALs for the family they were using, so many of them moved into the org too, and it was basically the only practical way at the time to coordinate enough people to develop enough support for lots of stm32 families: separate groups for each, with some overlap, doing their own thing and copying each other's good ideas

23:11 <re_irc> <@adamgreig:matrix.org> More history monologue 🙈

23:15 <re_irc> <@firefrommoonlight:matrix.org> adamgreig: The PACs and SVD2Rust are outstanding

23:19 <re_irc> <@firefrommoonlight:matrix.org> The inconsistencies etc I run into are almost all rooted in the SVDs

23:19 <re_irc> <@firefrommoonlight:matrix.org> Which stm32-rs, nrf-rs etc fix with YAML patches

23:19 <re_irc> <@dirbaio:matrix.org> nrf doesn't even patch anything

23:20 <re_irc> <@adamgreig:matrix.org> For all six of their chips ;p

23:20 <re_irc> <@dirbaio:matrix.org> nordic's docs and C headers seem generated from the svd's, maybe that has something to do with it too :D

23:21 <re_irc> <@dirbaio:matrix.org> or docs, headers, svd's generated from some internal source of truth

23:21 <re_irc> <@adamgreig:matrix.org> I only jest because I'm jealous of it, sounds great

23:21 <re_irc> <@dirbaio:matrix.org> stm32's svds seem handwritten by interns

23:21 <re_irc> <@dirbaio:matrix.org> typos in reg names

23:23 <re_irc> <@adamgreig:matrix.org> Some of the new ones actually have some enumerated values in the svd

23:23 DepthDeluxe has quit [Ping timeout: 260 seconds]

23:23 <re_irc> <@adamgreig:matrix.org> But they're wrong or worse so we had to add a feature to svdtools to remove existing enumerated values lol

23:23 <re_irc> <@dirbaio:matrix.org> what a luxury :D

23:24 <re_irc> <@adamgreig:matrix.org> More excitingly the new ones are explicitly released under an Apache 2.0 license

23:24 <re_irc> <@adamgreig:matrix.org> But yea they're not necessarily much better data quality