<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.
<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>
<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>
<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
<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