emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
starblue1 has quit [Ping timeout: 256 seconds]
starblue1 has joined #rust-embedded
mrkajetanp has quit [Ping timeout: 260 seconds]
mrkajetanp has joined #rust-embedded
<re_irc> <nebelgrau> Hi everyone, not sure how to ask a questions in a proper way here :) I'll try anyway.
<re_irc> I have an STM32F411 board, the so-called black pill. Done some coding with it already, it's a nice board. The only drawback: you either need to use the ST-Link, or the DFU uploader, and the DFU uploader is a real PITA, as getting it to work is close to a magic trick, happens right maybe 5% of times. Sub-optimal, to put it mildly. So I flashed it with the TinyUF2 bootloader from Adafruit, this one here:...
<re_irc> The board now shows up as an USB device as soon as plugged in, and I can drag and drop code on it. So I tried converting my binary file to .uf2 with this Python script here: https://github.com/microsoft/uf2/blob/master/utils/uf2conv.md. But after I drag and drop the resulting .uf2 file on the board, it does seem to flash it, but nothing really happens.
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
<re_irc> <monacoprinsen> nebelgrau: I have use the stm32f411 "blackpill", never had a problem with the st-link so I haven't tried the other options.
<re_irc> You might find it helpful to look at the discovery book for the stm32f3discovery.
<re_irc> One tip would be to see if you have all the tools installed, and the correct rights.
<re_irc> You will have to change some things to fit the f4 but should be almost the same
<re_irc> <monacoprinsen> If you have the correct setup you should be able to flash it with cargo run
Guest2 has joined #rust-embedded
<re_irc> <nebelgrau> monacoprinsen: What do you mean by a correct setup? I tried using hf2-cli, setting the runner to:
<re_irc> <nebelgrau> +runner = "hf2 --vid 0x239a --pid 0x0069 elf"
<re_irc> <nebelgrau> +but I'm getting a panic from bininfo module, as if it weren't recognizing the bootloader.
<re_irc> <monacoprinsen> Why don't you use ST-Link?
<re_irc> <nebelgrau> Oh I can use it no problem, I was just looking for a more friendly way to do it :)
<re_irc> <monacoprinsen> Have you tried the cortex m quickstart?
<re_irc> <monacoprinsen> cargo generate --git https://github.com/rust-embedded/cortex-m-quickstart
<re_irc> <nebelgrau> +The DFU bootloader works, too, it's just a real pain: I guess it's something related to the DFU bootloader or the board itself, it really takes lots of luck to get the correct timing between pressing and releasing the NRST and BOOT0 and also "KEY" for some reason. Hence the pursuit of a friendly drag-n-drop option.
<re_irc> <monacoprinsen> You can setup all commands in the cargo config file to make more user friendly
<re_irc> <nebelgrau> monacoprinsen: I know, I have it all set up, and the firmware works on the board if flashed with STLink, or with the DFU bootloader. Just trying to get it to work with the UF2 bootloader, and I'm not sure what else it needs: I'm assuming that the beginning of the flash, and the flash size as well, must take into account the space taken by the bootloader. That's why I tried modifying the memory.x. But it doesn't seem...
<re_irc> ... to work.
<re_irc> <monacoprinsen> Ok,
<re_irc> Tried removing +64 and -64 in the memory.x ?
<re_irc> I have not tried anything else than the st link.
<re_irc> <nebelgrau> I did try that, but it doesn't really make sense: the flash size must be somehow adjusted, as the TinyUF2 bootloader reserves 64K. I tried various combinations of this, between setting the start of the flash in memory.x and leaving unchanged in the Python uf2conv script setting, or vice versa, but no luck.
<re_irc> There must be something I'm missing here for sure :)
<re_irc> <henrik_alser> nebelgrau: The best developer experience is using the stlink and probe run, instant flashing and fast logging over rtt
<re_irc> <henrik_alser> Fast and easy setup with this app template https://github.com/knurling-rs/app-template
<re_irc> <nebelgrau> Yeah, I'll just get back to STLink I guess. It was worth trying (and I suppose I can just leave the bootloader for other things, like MicroPython, just need to keep the adjusted flash size). Thanks!
<re_irc> <henrik_alser> Or same but with RTIC: https://github.com/rtic-rs/defmt-app-template
<re_irc> <James Munns> Anyone interested in me setting up a "pretty hal machine" to do "embedded-hal RPC"-over-usb in order to write a firmware and driver for my I2C keypad device? Trying to build the motivation necessary to clean my office up enough to stream :D
<re_irc> <James Munns> (I'd stream later tonight, like 5-6 hours from now probably)
<re_irc> <James Munns> Okay, convinced myself. I guess keep an eye on https://www.youtube.com/c/JamesOfficeHours/ if you wanna join :D. Aiming for 18:00-19:00ish CET.
<re_irc> <James Munns> Here's a link to the stream: https://youtu.be/2S6G7wd8Kpo
Guest2 has quit [Ping timeout: 256 seconds]
<re_irc> <TimSmall> "Implementing the NTFS filesystem in [no_std] Rust" is currently streaming at #misc:fosdem.org with live Q&A to follow.
<re_irc> <James Munns> Going live on my stream now: https://youtu.be/2S6G7wd8Kpo
dreamcat4 has joined #rust-embedded
seds has joined #rust-embedded
<seds> In C, we can define a set of macros to use them as instruction mnemonic on .S files when handling 32- 64-bits architecture. What would be the equivalent in Rust? I've tried `const LOAD_W: &str = "lw"` and calling it from my .S file, but no luck, getting a warning of `unrecognized instruction mnemonic`. Thoughts?
<Shell> continue using the C preprocessor (or another preprocessor) for your assembly files, they have nothing to do with Rust.
<seds> I know, but I am migrating all to rust. Didn't want to have a random .h header in a rust repository, so I was wondering how projects in rust handle this situation