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
starblue1 has quit [Ping timeout: 272 seconds]
starblue1 has joined #rust-embedded
jcroisant has joined #rust-embedded
<re_irc> <thejpster> Does anyone what to draft up a This Year in Rust 2022?
<re_irc> <thejpster> There’s a few topics on the ticket but we could do with tapping up all the HAL teams for updates.
<re_irc> <henrik_alser> I guess a big theme of this year has been the async ecosystem?
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc> <henrik_alser> Enabled by some long ”awaited” language features _taking shelter_
starblue1 has quit [Ping timeout: 265 seconds]
starblue1 has joined #rust-embedded
wes_ has quit [Ping timeout: 248 seconds]
<jcroisant> Hello! I'm totally new to embedded programming. I want to try Rust on a micro:bit, but not permanently alter the device. Will following the Discovery book overwrite the secondary MCU firmware (DAPLink)? If so, can I restore it later? Alternatively, can I compile Rust to a .hex file to install via USB?
<re_irc> < (@k900:0upti.me)> It's not possible to "permanently" alter the hardware really
<re_irc> < (@k900:0upti.me)> Even if you overwrite the bootloader, you can always flash it back
<jcroisant> I have found this page which seems to have .hex files for the interface/bootloader. https://tech.microbit.org/software/daplink-interface/ -- What tool would I use to flash the bootloader? The page mentions blhost, but that section says "V2.00 only", and I have V2.21 which uses a different MCU.
<re_irc> < (@ryan-summers:matrix.org)> Generally, you'd flash the microbit with an external programmer. It looks like the microbit has two MCUs though, and the interface MCU is a built-in programmer
<re_irc> < (@ryan-summers:matrix.org)> Does the micro:bit even use a bootloader, given that it has a built-in programmer?
<re_irc> < (@dirbaio:matrix.org)> jcroisant: no, nothing from the discovery book will overwrite any daplink firmware
<re_irc> < (@dirbaio:matrix.org)> it only _uses_ it
<re_irc> < (@ryan-summers:matrix.org)> There's an "interface MCU" and "target MCU". If you reprogram the target MCU, the "interface MCU" should always be able to just reprogram it. I.e. there is no permanent state that can be removed from the "target MCU"
<re_irc> < (@ryan-summers:matrix.org)> Which is definitely a change in perspective if you're used to something like Arduino
<jcroisant> dirbaio: Thank you, I'm very glad to hear that :)
<jcroisant> Hooray! I got an LED to turn on with Rust, and then I was still able to install and run a .hex made with MakeCode like before, so DAPLink is indeed still intact on the interface MCU. I'm happy :D
<jcroisant> I did run into "hidapi error: Permission denied" but the updated udev rule here solved it: https://github.com/rust-embedded/discovery/issues/490
<re_irc> < (@therealprof:matrix.org)> jcroisant: Indeed the DAPlink MCU is quite isolated and almost impossible to reflash, so no worries it's safe. You should be aware that it's possible to hang it though which might cause the impression of an overwritten firmware though. If that happens, simply disconnect the power for a while.
<jcroisant> therealprof: Thanks, that's good to know!
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Client Quit]
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc> < (@therealprof:matrix.org)> jcroisant: To flash a new DAPLink image, you simply hold the reset button while plugging it in and then drop the image on the MAINTENANCE drive.
starblue1 has quit [Ping timeout: 256 seconds]
vancz_ has joined #rust-embedded
bjc has quit [Ping timeout: 252 seconds]
radens_ has joined #rust-embedded
radens_ is now known as radens
<re_irc> < (@barafael:matrix.org)> How many ways to count the number of edges on a digital input can you think of?
<re_irc> This was my "research question" a while ago. So I built a couple firmwares which count edges and can be read out over serial port (destructive read).
<re_irc> So far, I got these:
<re_irc> - Polling with PAC and HAL,
<re_irc> < (@barafael:matrix.org)> I'd also appreciate "wrong" approaches. I already have a couple racy examples as well as an example using an "embassy_futures::select::Select3" which is a little unresponsive
<re_irc> < (@9names:matrix.org)> I assume you're excluding hardware peripheral solutions, like using a counter peripheral?
starblue1 has joined #rust-embedded
<re_irc> < (@barafael:matrix.org)> : so far yes I have excluded them, of course as a reference those would be interesting. My target is an STM32F411
IlPalazzo-ojiisa has quit [Remote host closed the connection]
<re_irc> <Dlaw> Here is an example from a project I am working on which configures a STM32F411 hardware timer as an edge counter. I use RTIC and the HAL where possible, but the HAL does not support edge counting.
<re_irc> < (@burrbull:matrix.org)> qei?