02:10 <wllenyj[m]> Does anyone know why the cortex-r crate is not implemented in rust-embedded?

02:13 <JamesMunns[m]> wllenyj[m]: We've had a couple people interested, but basically: because nobody has written/maintained it

02:13 <JamesMunns[m]> There were a couple folks a couple of years back, but they seem not to have continued with it.

02:58 <wllenyj[m]> <JamesMunns[m]> "There were a couple folks a..." <- Thanks, maybe `cortex-r` 32bit is not widely used enough.

05:02 <ian_rees[m]> is this embedded-hal issue the latest on DMA trait discussion? https://github.com/rust-embedded/embedded-hal/issues/37

11:46 <Farooq> Is the soldering good?

11:53 <K900> Uhh

11:53 <K900> Burned is usually bad

12:01 <Farooq> what do you mean?

12:01 <Farooq> it's not burned. my soldering thing was dirty

12:01 <K900> That is also usually bad

12:02 <Farooq> how should I clean it?

12:02 <Farooq> hmm I need a soldering tutorial

12:03 <ryan-summers[m]> Honestly it looks like the PCB may not have a sufficient fiducial ring where the pins go in, so there's not a great wetting surface for the solder. But yeah, I'd agree that there are likely some issues you should work out with either heat, quality of solder, application, preheating, etc.

12:04 <ryan-summers[m]> Usually a solder joint should be shiny, rounded, well-wetted etc.

12:04 <ryan-summers[m]> The burned particulate could likely be rosin flux that burned off during the soldering process. Flux is often incorporated directly into hand solders

12:05 <Farooq> okay it's time for YT then

12:05 <ryan-summers[m]> Yeah definitely go watch a few tutorials. Hand soldering is a bit of an art

12:42 <therealprof[m]> Farooq: So which iron did you get?

13:02 <Farooq> ummm

13:02 <Farooq> a very lowend 10 usd one for now

13:03 <Farooq> I will get a better one later

13:10 <therealprof[m]> Just double checking.

15:02 <TomB[m]> anyone see the new beagleboard based around a microchip polaris?

15:02 <TomB[m]> looks cool

15:11 <d3zd3z[m]> It seems that, although regex-lite has a 'std' feature, disabling it merely generates a compiler error that 'std' is currently required, and to file a ticket.

15:11 <d3zd3z[m]> Anyone know of possible options?

15:18 <TomB[m]> https://crates.io/crates/safe-regex says no_std

18:33 <d3zd3z[m]> <TomB[m]> "https://crates.io/crates/safe-..."; <- Definitely worth looking at.

19:06 <lkostka[m]> Hi.

19:06 <lkostka[m]> Let's say that I have board A and board B. Same MCU. Different LED pins. How using stm32f1xx-hal I can define a different LED pin to use depending on board ?

19:06 <lkostka[m]> https://github.com/luqasz/gbot/blob/main/src/bin/firmware.rs#L25

19:06 <lkostka[m]> * Hi.... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/VShRwPQSqOLWqJADSDGZiKer>)

19:07 <K900> Crate features, probably

19:07 <K900> You can't detect the board at runtime unless the board provides some smart way of doing it

19:08 <K900> (and both boards agree on what that way is0

19:08 <K900> s/is0/is)/

19:10 <lkostka[m]> Not at runtime. I will build each firmware for each board

19:10 <K900> Then crate features, yes

19:11 <lkostka[m]> Ok then use cfg macro detecting features ?

19:11 <K900> Yes

19:12 <lkostka[m]> Ugh. Then I need to change function signature `hal::gpio::Pin<'C', 13, Output>` and conditionally compile 2 lines... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/ELjjFIthnyQiWGRzBXIIXaxv>)

19:13 <lkostka[m]> s/let//, s/mut//, s/gpioc = dp.GPIOC.split();//

19:13 <lkostka[m]> * Ugh. Then I need to change function signature `hal::gpio::Pin<'C', 13, Output>` and conditionally compile 2 lines... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/INaKdSvsxqlhldoaqxavuXne>)

19:14 <GrantM11235[m]> I would suggest `type Led = hal::gpio::Pin<'C', 13, Output>;`

19:14 <newam[m]> this is one of the parts where rust is sadly not as good as C/C++, conditional compilation.

19:15 <lkostka[m]> It would be much easier If hal provided some way to instantiate given type from `type Led = hal::gpio::Pin<'C', 13, Output>`

19:15 <lkostka[m]> then only thing needed would be `type Led = hal::gpio::Pin<'C', 13, Output>`

19:18 <lkostka[m]> or maybe come macro that will do all the required stuff

19:38 <ian_rees[m]> lkostka - I don't have any experience with the stm32 HAL, but in the ATSAM world the HAL (hardware abstraction layer) and BSP (board support package) are separate, which allows you to define the types as suggested above in a BSP for each board, then in your main use cfg to select either `extern crate board_a as bsp;` or `extern crate board_b as bsp;`

20:00 <lkostka[m]> <ian_rees[m]> "lkostka - I don't have any..." <- can you provide some crate names so I can examine source code to look for possible solutions

20:09 <ian_rees[m]> sure - these are the boards used to provide examples, but if you've got a custom board the normal approach would be to make a BSP with correct pin definitions https://github.com/atsamd-rs/atsamd/tree/master/boards