02:41 <lowq> Hi all, I'm looking for a development kit to get started with. I think I read that MSP430 is a good option?

02:42 <lowq> I have a few Tiva-C series dev kits lying around (Cortex M4), but I'm not sure how well supported they are at this point.

02:50 <re_irc> <sajattack> support for those looks like it hasn't been updated in a while https://github.com/rust-embedded-community/tm4c-hal/ https://github.com/thejpster/stellaris-launchpad

02:50 <re_irc> <sajattack> but it at least exists

02:51 <re_irc> <sajattack> stm32 devkits are fairly well supported

02:52 <re_irc> <sajattack> nrf is probably next most widely used

02:52 <re_irc> <sajattack> and atsamd/rp2040 are pretty good too

02:52 <re_irc> <sajattack> lots of options

02:53 <re_irc> <sajattack> and atsamd, rp2040 are pretty good too

02:55 <lowq> Aha, it might have been stm32 I read about

02:57 <lowq> https://github.com/reneherrero/nucleo-l432kc-quickstart www.digikey.com/en/products/detail/stmicroelectronics/NUCLEO-L432KC/6132763

02:58 <lowq> Might just pick one of these up. Thanks!

03:00 <re_irc> <sajattack> board support isn't too common in the stm32-rs project, but it's fairly simple to put your own BSP together

03:01 <re_irc> <sajattack> If I may toot my own horn a bit, atsamd-rs has a bunch of board support crates for adafruit, arduino, sparkfun boards

03:03 <re_irc> <sajattack> the HAL is more important anyways though, and stm32 really shines there

03:06 <lowq> I see. My concern would be getting code at the right address, like I would do in a linker script

03:07 <lowq> And then just flashing the damn thing

03:17 <lowq> The readme for atsamd-rs is pretty helpful! I might have an arduino with a samd on it somewhere, come to think of it.

03:17 <re_irc> <sajattack> yeah you can just check the datasheet and write one of these simple files for the linking https://github.com/reneherrero/nucleo-l432kc-quickstart/blob/master/memory.x (assuming you use cortex-m-rt)

03:17 <re_irc> <sajattack> and there are many different ways of flashing

03:18 <lowq> An onboard bootloader (Arduino) might be the least error prone

03:19 <re_irc> <sajattack> yeah, only warning there is, don't forget to use the offset flag for bossac or you may overwrite your bootloader

03:19 <lowq> lul

03:19 <re_irc> <sajattack> if you choose bossac

03:19 <re_irc> <sajattack> like -o 0x4000 for a 16KB bootloader or -o 0x2000 for a 8KB

03:20 <lowq> good to know

03:20 <lowq> Never did invest in a jtag

03:21 <lowq> No, that's right, did use an arduino as a programmer for an ATTiny once

03:22 <cr1901> lowq: msp430 works, although it's still on nightly, and the embedded-hal support leaves something to be desired

03:23 <cr1901> If you have time, I'd be curious if you'd be up for going through the quickstart, so someone besides me can confirm it works recently: https://github.com/rust-embedded/msp430-quickstart

03:23 <lowq> I actually don't have an msp430 unfortunately

03:34 <cr1901> Ahhh I see. Happy to hear that ppl think msp430 is a good option tho :D

03:35 <lowq> Yeah, I was just shopping around, wasn't really sure if it was (and might have mis-remembered what I read)

11:24 <re_irc> <justacec> Saying something. :). [Resetting my channel timeout]

11:36 <re_irc> <9names (@9names:matrix.org)> if you're concerned about such things, i'm sure that adding a reaction to a comment would be just as effective and 100% less spammy

11:37 <re_irc> <K900> Maybe they got confused by the "ping timeout" messages?

11:37 <re_irc> <K900> Those come from the IRC side

11:37 <re_irc> <9names (@9names:matrix.org)> or... are you behind the bridge? (hard to tell these days)

11:37 <re_irc> <K900> Not Matrix

11:38 <re_irc> <K900> So nothing to worry about really

11:38 <re_irc> <9names (@9names:matrix.org)> oh

11:58 <re_irc> <floofstrid> hi! i have no idea where else to ask this, so hopefully this is a decent place. I'm trying to get a cmsis-dap debug probe running on the only board i can program rn (an STM32F746 discovery). I found this: https://github.com/probe-rs/hs-probe-firmware, does anyone have experience getting this or something similar running on one of these?

11:59 <re_irc> <floofstrid> i did attempt to flash it as is but it's Not Working(tm) and i don't know where to start figuring out why

12:09 <re_irc> <burrbull> floofstrid: https://matrix.to/#/#probe-rs:matrix.org

12:11 <re_irc> <floofstrid> thanks, i'll try there!

12:13 <re_irc> <floofstrid> failing that, maybe someone here has recommendations for a cheap/accessible board to turn into a probe? i'd get a j-link edu mini but it's chronically sold out everywhere :/

12:54 <re_irc> <9names (@9names:matrix.org)> the weact usb-c pill works pretty well

12:54 <re_irc> i usually use a raspberry pi pico with the dapper-mime firmware or the prototype firmware for the pio-probe.

12:54 <re_irc> https://therealprof.github.io/blog/usb-c-pill-part1/

12:55 <re_irc> <9names (@9names:matrix.org)> anything you can run daplink on should also be fine

13:04 <re_irc> <floofstrid> do you know if this is available anywhere in EU?

13:04 <re_irc> <floofstrid> i see some clones on amazon.de but idk if those are any good

13:13 <re_irc> <9names (@9names:matrix.org)> no idea about EU. and generally, availability for everything is pretty bad at the moment

13:13 <re_irc> <floofstrid> yeah, i've noticed

13:14 <re_irc> <floofstrid> hence trying to make do with what i have :p

15:00 <re_irc> <therealprof> floofstrid: They're way overpriced and very likely not genuine.

15:02 <re_irc> <therealprof> Oh wow, in 2020 I bought 3 genuine ones for less than one fake one costs now.

15:23 <re_irc> <James Munns> I haven't checked recently, but Adafruit stocks them, and Digikey has distribution for most of Adafruit's stock, though you have to hit 50EUR for free shipping from digikey

15:23 <re_irc> <James Munns> If you find Adafruit's P/N for the usb-c pills, you can search that on Digikey

15:29 <re_irc> <TimSmall> floofstrid: Might be best just to go for something RP2040 based for the time being, they aren't in short supply...

15:29 <re_irc> <floofstrid> digikey is weird with customs but i can do mouser if they have them

15:30 <re_irc> <floofstrid> do the rp2040s come with presoldered headers?

15:30 <re_irc> <floofstrid> James Munns: this one? https://www.adafruit.com/product/4877

15:31 <re_irc> <James Munns> Looks right!

15:31 <re_irc> <TimSmall> floofstrid: You can buy rp2040 board with presoldered headers. Either the Raspberry Pi Pico, or others...

15:31 <re_irc> <James Munns> So if you search digikey for "4877", and filter by Adafruit, you should find it

15:33 <re_irc> <TimSmall> https://shop.pimoroni.com/products/raspberry-pi-pico?variant=32402092326995

15:33 <re_irc> <floofstrid> not stocked on mouser, but they do have this one https://www.mouser.dk/new/dfrobot/dfrobot-stm32f411-blackpill-board/

15:33 <re_irc> <floofstrid> unless that's also a fake?

15:44 <re_irc> <TimSmall> floofstrid: There's also this: https://github.com/probe-rs/rusty-probe ...which is still a work in progress, so not yet available, but it does (will) have full Rust firmware (also usable on the Pico etc.).

15:44 <re_irc> <TimSmall> (In the meantime, there's https://github.com/majbthrd/DapperMime/ ...and derivatives).

16:08 <re_irc> <TimSmall> I haven't needed to use raw pointer in rust until now (also haven't done any rust coding since December so lots of things seem to have fallen out of my brain), but I'm debugging what I suspect might be an SVD error, so is there an easy way to get the address of a register (I want to see if there's anything in the next register - which is missing from most of the SVD files, but I'd like to check if it's actually missing...

16:09 <re_irc> ... or not)...

16:09 <re_irc> ... so is there an easy way to say "give me the address of "(*USART::ptr()).cr3", so that I can add 4 to it, and treat it like it's a u32?". This is just throwaway debug code BTW, if it turns out the register is really there, then I'll patch the SVD...

16:10 <re_irc> <TimSmall> The register in question is GTPR on UART peripherals - and I can't think of any reason that this would only be present on stm32f413, but not on others f4xx (at least the ones that have UARTs as well as USARTS) - https://stm32-rs.github.io/stm32-rs/stm32f/stm32f4/UART4_0x40004C00_GTPR_0x0018.html

16:32 <re_irc> <TimSmall> nm, hacked around it by hard-coding the memory address instead...

17:01 <re_irc> &(*USART::ptr()).cr3 as *const _ as u32,

17:01 <re_irc> <firefrommoonlight> I think the way to do it more generally is

21:41 <re_irc> <yruama_lairba> hi, where i can find implementation of a non blocking hal ?

21:42 <re_irc> <yruama_lairba> or at least, is there some guideline for that ?

21:42 <re_irc> <dirbaio> if you want async, check out embassy

21:43 <re_irc> <dirbaio> if you want "nb", there are reasons why it's not widely implemented/used, it has some _problems_ :P

21:46 <re_irc> <yruama_lairba> dirbaio: weird, because embeded hal seems to use "nb" for some trait and not mention embassy

21:47 <re_irc> <dirbaio> "nb" is from before rust async even existed

21:47 <re_irc> <dirbaio> embedded-hal 1.0 will support async https://github.com/rust-embedded/embedded-hal/issues/356

21:50 <re_irc> <yruama_lairba> in fact, i'm trying to implment full duplex I2s on stm32_i2s_v12 crates and as i progress into my work, i find issues in the current work

21:51 <re_irc> <yruama_lairba> one of this issue may a wrong use of the nb API

21:57 <re_irc> <yruama_lairba> one function return the Ok() variant of nb::Result while doing blocking io :/

22:01 <re_irc> <yruama_lairba> this function is supposed to transmit one audio sample, but depending the audio bit depth, 2 writes to the peripheral may required

22:03 <re_irc> <dirbaio> huh, link?

22:04 <re_irc> <yruama_lairba> https://docs.rs/stm32_i2s_v12x/0.2.0/stm32_i2s_v12x/struct.I2s.html#method.transmit

22:05 <re_irc> <yruama_lairba> the blocking behaviour is even documented :p

22:06 <re_irc> <dirbaio> heh

22:07 <re_irc> <dirbaio> yeah

22:08 <re_irc> <dirbaio> if a fn returning "nb::Result" has to do two writes, and the first write completes and the second fails with WouldBlock, it has to somehow "remember" it has a write "half done" so that it continues the next time the user calls it

22:09 <re_irc> <dirbaio> where do you store that? in "self" is super error prone

22:09 <re_irc> <dirbaio> you can return a struct representing an "in-progress" transfer and have the user poll that

22:09 <re_irc> <dirbaio> but at that point you're reinventing async futures :)

22:10 <re_irc> <dirbaio> so that code goes "meh, too hard, let's just block" :P

22:12 <re_irc> <dirbaio> vs with async you do

22:12 <re_irc> async fn write_sample(&mut self, sample: S) {

22:12 <re_irc> self.write_data(sample.low).await;

22:12 <re_irc> self.write_data(sample.high).await;

22:12 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/b08880684194d9fffd00eb3381549ed0c1b1b64551d0170d25e7a6290468b8cf (6 lines)

22:13 <re_irc> <yruama_lairba> ok, but i don't use yet async API

22:14 <re_irc> <yruama_lairba> it's a paradigm i'm not used to at all

22:18 <re_irc> <yruama_lairba> for the moment, i just wonder if i will fully rewrite this crate.

22:27 <re_irc> <yruama_lairba> who use rls here ? I have a lint error about missing "test" crate, i'd like to know what option is wrong

22:32 <re_irc> <therealprof> rls is close to obsolete now. rust-analyzer is going to officially replace rls soon (inofficially it has long replaced it already).

22:47 <re_irc> <yruama_lairba> therealprof: i hope there will be an integration with vim

22:48 <cr1901> VSCode seems to be the "blessed" editor for Rust work

22:57 <re_irc> <therealprof> yruama_lairba: Works fine.

22:58 <re_irc> <therealprof> I've used rust-analyzer with vim for a long time now.

22:59 <re_irc> <therealprof> I even forgot what the first integration bridge was, before I switched to neovim (also a while ago) I was using coc.

23:10 <re_irc> <yruama_lairba> that me or spi in stmf4xx-hal doesn't support slave opperation ?