ChanServ changed the topic of #rust-embedded to: Welcome to the Rust Embedded IRC channel! Bridged to #rust-embedded:matrix.org and logged at https://libera.irclog.whitequark.org/rust-embedded, code of conduct at https://www.rust-lang.org/conduct.html
cr1901_ is now known as cr1901
lowq has joined #rust-embedded
explore has joined #rust-embedded
cr1901 has quit [Ping timeout: 240 seconds]
lowq has quit [Quit: leaving]
lowq has joined #rust-embedded
cr1901_ has joined #rust-embedded
cr1901_ has quit [Ping timeout: 240 seconds]
cr1901 has joined #rust-embedded
<lowq> Hi all, I'm looking for a development kit to get started with. I think I read that MSP430 is a good option?
<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.
<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
<re_irc> <sajattack> but it at least exists
<re_irc> <sajattack> stm32 devkits are fairly well supported
<re_irc> <sajattack> nrf is probably next most widely used
<re_irc> <sajattack> and atsamd/rp2040 are pretty good too
<re_irc> <sajattack> lots of options
<re_irc> <sajattack> and atsamd, rp2040 are pretty good too
<lowq> Aha, it might have been stm32 I read about
<lowq> Might just pick one of these up. Thanks!
<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
<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
<re_irc> <sajattack> the HAL is more important anyways though, and stm32 really shines there
cr1901_ has joined #rust-embedded
<lowq> I see. My concern would be getting code at the right address, like I would do in a linker script
cr1901 has quit [Read error: Connection reset by peer]
<lowq> And then just flashing the damn thing
<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.
<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)
<re_irc> <sajattack> and there are many different ways of flashing
cr1901_ is now known as cr1901
<lowq> An onboard bootloader (Arduino) might be the least error prone
<re_irc> <sajattack> yeah, only warning there is, don't forget to use the offset flag for bossac or you may overwrite your bootloader
<lowq> lul
<re_irc> <sajattack> if you choose bossac
<re_irc> <sajattack> like -o 0x4000 for a 16KB bootloader or -o 0x2000 for a 8KB
<lowq> good to know
<lowq> Never did invest in a jtag
<lowq> No, that's right, did use an arduino as a programmer for an ATTiny once
<cr1901> lowq: msp430 works, although it's still on nightly, and the embedded-hal support leaves something to be desired
<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
<lowq> I actually don't have an msp430 unfortunately
<cr1901> Ahhh I see. Happy to hear that ppl think msp430 is a good option tho :D
explore has quit [Quit: Connection closed for inactivity]
<lowq> Yeah, I was just shopping around, wasn't really sure if it was (and might have mis-remembered what I read)
cr1901_ has joined #rust-embedded
cr1901__ has joined #rust-embedded
cr1901 has quit [Ping timeout: 240 seconds]
cr1901_ has quit [Ping timeout: 240 seconds]
cr1901 has joined #rust-embedded
cr1901__ has quit [Ping timeout: 240 seconds]
cr1901_ has joined #rust-embedded
cr1901 has quit [Killed (NickServ (GHOST command used by cr1901_))]
cr1901_ is now known as cr1901
cr1901 has quit [Read error: Connection reset by peer]
cr1901 has joined #rust-embedded
emerent has quit [Ping timeout: 240 seconds]
emerent has joined #rust-embedded
Socke has quit [Ping timeout: 240 seconds]
Socke has joined #rust-embedded
lowq has quit [Ping timeout: 240 seconds]
ymwm has joined #rust-embedded
<re_irc> <justacec> Saying something. :). [Resetting my channel timeout]
<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
<re_irc> <K900> Maybe they got confused by the "ping timeout" messages?
<re_irc> <K900> Those come from the IRC side
<re_irc> <9names (@9names:matrix.org)> or... are you behind the bridge? (hard to tell these days)
<re_irc> <K900> Not Matrix
<re_irc> <K900> So nothing to worry about really
<re_irc> <9names (@9names:matrix.org)> oh
<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?
<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
<re_irc> <burrbull> floofstrid: https://matrix.to/#/#probe-rs:matrix.org
<re_irc> <floofstrid> thanks, i'll try there!
<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 :/
<re_irc> <9names (@9names:matrix.org)> the weact usb-c pill works pretty well
<re_irc> i usually use a raspberry pi pico with the dapper-mime firmware or the prototype firmware for the pio-probe.
<re_irc> <9names (@9names:matrix.org)> anything you can run daplink on should also be fine
<re_irc> <floofstrid> do you know if this is available anywhere in EU?
<re_irc> <floofstrid> i see some clones on amazon.de but idk if those are any good
<re_irc> <9names (@9names:matrix.org)> no idea about EU. and generally, availability for everything is pretty bad at the moment
<re_irc> <floofstrid> yeah, i've noticed
<re_irc> <floofstrid> hence trying to make do with what i have :p
ymwm has quit [Ping timeout: 240 seconds]
<re_irc> <therealprof> floofstrid: They're way overpriced and very likely not genuine.
<re_irc> <therealprof> Oh wow, in 2020 I bought 3 genuine ones for less than one fake one costs now.
jackneillll has joined #rust-embedded
re_irc_ has joined #rust-embedded
starblue has quit [Ping timeout: 240 seconds]
jackneilll has quit [Remote host closed the connection]
VShell has joined #rust-embedded
Foxyloxy_ has joined #rust-embedded
Shell has quit [Killed (zirconium.libera.chat (Nickname regained by services))]
VShell is now known as Shell
re_irc has quit [Ping timeout: 240 seconds]
Foxyloxy has quit [Ping timeout: 240 seconds]
re_irc_ is now known as re_irc
<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
<re_irc> <James Munns> If you find Adafruit's P/N for the usb-c pills, you can search that on Digikey
hifi has quit [Ping timeout: 250 seconds]
rektide has quit [Ping timeout: 250 seconds]
rektide has joined #rust-embedded
<re_irc> <TimSmall> floofstrid: Might be best just to go for something RP2040 based for the time being, they aren't in short supply...
hifi has joined #rust-embedded
<re_irc> <floofstrid> digikey is weird with customs but i can do mouser if they have them
<re_irc> <floofstrid> do the rp2040s come with presoldered headers?
<re_irc> <floofstrid> James Munns: this one? https://www.adafruit.com/product/4877
<re_irc> <James Munns> Looks right!
<re_irc> <TimSmall> floofstrid: You can buy rp2040 board with presoldered headers. Either the Raspberry Pi Pico, or others...
<re_irc> <James Munns> So if you search digikey for "4877", and filter by Adafruit, you should find it
<re_irc> <floofstrid> not stocked on mouser, but they do have this one https://www.mouser.dk/new/dfrobot/dfrobot-stm32f411-blackpill-board/
<re_irc> <floofstrid> unless that's also a fake?
<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.).
<re_irc> <TimSmall> (In the meantime, there's https://github.com/majbthrd/DapperMime/ ...and derivatives).
tafa has quit [Quit: ZNC - https://znc.in]
tafa has joined #rust-embedded
lowq has joined #rust-embedded
<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...
<re_irc> ... or not)...
<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...
<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
starblue has joined #rust-embedded
<re_irc> <TimSmall> nm, hacked around it by hard-coding the memory address instead...
<re_irc> &(*USART::ptr()).cr3 as *const _ as u32,
<re_irc> <firefrommoonlight> I think the way to do it more generally is
lowq has quit [Ping timeout: 256 seconds]
diagprov has quit [Quit: diagprov]
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc> <yruama_lairba> hi, where i can find implementation of a non blocking hal ?
<re_irc> <yruama_lairba> or at least, is there some guideline for that ?
<re_irc> <dirbaio> if you want async, check out embassy
<re_irc> <dirbaio> if you want "nb", there are reasons why it's not widely implemented/used, it has some _problems_ :P
<re_irc> <yruama_lairba> dirbaio: weird, because embeded hal seems to use "nb" for some trait and not mention embassy
<re_irc> <dirbaio> "nb" is from before rust async even existed
<re_irc> <dirbaio> embedded-hal 1.0 will support async https://github.com/rust-embedded/embedded-hal/issues/356
<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
<re_irc> <yruama_lairba> one of this issue may a wrong use of the nb API
<re_irc> <yruama_lairba> one function return the Ok() variant of nb::Result while doing blocking io :/
<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
<re_irc> <dirbaio> huh, link?
lowq has joined #rust-embedded
<re_irc> <yruama_lairba> the blocking behaviour is even documented :p
<re_irc> <dirbaio> heh
<re_irc> <dirbaio> yeah
<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
<re_irc> <dirbaio> where do you store that? in "self" is super error prone
<re_irc> <dirbaio> you can return a struct representing an "in-progress" transfer and have the user poll that
<re_irc> <dirbaio> but at that point you're reinventing async futures :)
<re_irc> <dirbaio> so that code goes "meh, too hard, let's just block" :P
<re_irc> <dirbaio> vs with async you do
<re_irc> async fn write_sample(&mut self, sample: S) {
<re_irc> self.write_data(sample.low).await;
<re_irc> self.write_data(sample.high).await;
<re_irc> <yruama_lairba> ok, but i don't use yet async API
<re_irc> <yruama_lairba> it's a paradigm i'm not used to at all
<re_irc> <yruama_lairba> for the moment, i just wonder if i will fully rewrite this crate.
<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
<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).
<re_irc> <yruama_lairba> therealprof: i hope there will be an integration with vim
<cr1901> VSCode seems to be the "blessed" editor for Rust work
<re_irc> <therealprof> yruama_lairba: Works fine.
<re_irc> <therealprof> I've used rust-analyzer with vim for a long time now.
<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.
<re_irc> <yruama_lairba> that me or spi in stmf4xx-hal doesn't support slave opperation ?
dne has quit [Remote host closed the connection]
dne has joined #rust-embedded