<re_irc>
<@whitequark:matrix.org> : i think we can probably patch the appservice to adjust the message
<re_irc>
<@avery71:matrix.org> does anybody have much experience with svdtools?
<re_irc>
<@avery71:matrix.org> basically I have to make a lot of fields that are like this
<re_irc>
_add:
<re_irc>
bitOffset: 15
<re_irc>
PDR15:
<re_irc>
bitWidth: 1
<re_irc>
bitOffset: 14
<re_irc>
PDR14:
<re_irc>
bitWidth: 1
<re_irc>
and down onto 0, is there a good way to avoid the repetition
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
<re_irc>
<@guenther_rostig:matrix.org> In the discovery book openocd is used. For debbuging I want to use a Segger J-Link. So I have to make the J-Link working with openocd or use the J-Link GDB Server. I would prefer the second option.
<re_irc>
<@ryan-summers:matrix.org> guenther_rost: What chip are you targeting again? probe-rs's GDB support is far easier to use with Rust IMO
<re_irc>
<@ryan-summers:matrix.org> But if you insist on using the J-Link GDB implementation, I think that's well outside of the discovery book and you'll need to refer to Segger's docs on how to set it up
<re_irc>
<@guenther_rostig:matrix.org> I use the MSP432E401Y. I found out how to use none-eabi-gdb with a J-Link. I'll tell you about my experience.
<re_irc>
<@ryan-summers:matrix.org> If you want, I think probe-rs works just fine with a JLink, so you can use probe-rs's GDB server
<re_irc>
<@ryan-summers:matrix.org> Ah wait but it doesn't support that chip. Nevermind
<re_irc>
<@9names:perthchat.org> I made a PR to add support for that chip 13 months ago 🥲
<re_irc>
<@9names:perthchat.org> It wouldn't be much work to update to the PR if you get motivated guenther_rost.
<re_irc>
<@ruabmbua:matrix.org> I have a recurring annoyance with rust when it comes to debugging: it seems to not be possible to compile a single function or module with different compilation options. Most notably the optimization level.
<re_irc>
Does anyone know a way to do this? If not, is anyone aware of some work being done on it?
<re_irc>
If there is really nothing, this might become my first project for rustc
<re_irc>
<@ruabmbua:matrix.org> There must be some level of support, since for example in inline assembly you can push and pop regions with different assembler options. Eg for riscv turning off compressed instructions for a small section of code
<re_irc>
<@yatekii:matrix.org> : I think you need to make a separate crate
<re_irc>
<@ruabmbua:matrix.org> Yep I guess keeping around an extra crate and move functions to there is the only option.
<re_irc>
<@ruabmbua:matrix.org> But for temporary quick debugging where I want to change this quickly, it's a pain
<re_irc>
<@ruabmbua:matrix.org> In GCC I use the pragmas or the relevant attributes which is nice
elmcrest has joined #rust-embedded
<elmcrest>
Hey everybody. are there recommended alternatives for the `STM32F3DISCOVERY` board mentioned in the rust embedded book? I'd like to give it a try but I'd need a board with WiFi and ideally bluetooth - if that's possible.
<elmcrest>
at least I've already managed to use the `tiny` IRC client which is implemented in Rust :)
<re_irc>
<@ryan-summers:matrix.org> The only device I know with wifi are the esp32-series chips, but also, wifi and BL/BLE are very advanced embedded things if you're looking at just doing the discovery book
<elmcrest>
I was hoping to get there at some point - not only with the discovery book
<elmcrest>
my hope was that there are libraries available which make the wifi and/or bluetooth available for me :P
<re_irc>
<@ryan-summers:matrix.org> If you want wifi, Espressif's ESP32 is the only one I know of. The nrf9160 has an embedded modem for cell networks as well
<elmcrest>
ok, is the ESP32 well supported with Rust?
<re_irc>
<@ryan-summers:matrix.org> They pay some full time engineers to maintain support
<re_irc>
<@mabez:matrix.org> elmcrest: Sure is! Come checkout https://matrix.to/#/#esp-rs:matrix.org
<elmcrest>
I managed to solve my problem with C++ and platform.io - so pretty noob level I'd say ... so I'm not an expert
<elmcrest>
oh that sounds great, thx
<re_irc>
<@ryan-summers:matrix.org> WiFi is harder because not many embedded chips actually have the capability to talk to a wifi network. Espressif is one of the exceptions
<elmcrest>
finally a use case for my Element messenger ... it's ideling since years
<re_irc>
<@ryan-summers:matrix.org> If you want BLE, you probably want a nordic nRF chip
<elmcrest>
must have is Wifi, nice to have would be BLE
<re_irc>
<@ryan-summers:matrix.org> BLE is _hard_. Nordic provides a firmware blob that does all the actual BLE heavy lifting
<elmcrest>
it seems the chip has it, so Rust support will follow maybe?
<re_irc>
<@mabez:matrix.org> elmcrest: It doesn't currently, but the hardware supports it. will be working on that at some point
<re_irc>
<@ryan-summers:matrix.org> Just a heads up, esp rust is definitely somewhat non-traditional
<elmcrest>
yeah, I'm fine with that then :P
<re_irc>
<@ryan-summers:matrix.org> I.e. it uses a fork of the rust compiler etc. to support the esp chips
<re_irc>
<@mabez:matrix.org> : On the Xtensa chips, ESP32, ESP32S2 & ESP32S3, every other chip is supported in Rust upstream today
<re_irc>
<@mabez:matrix.org> and that includes the standard library port for esp-idf too
<re_irc>
<@mabez:matrix.org> Only the Xtensa chips, ESP32, ESP32S2 & ESP32S3, every other chip is supported in Rust upstream today
<elmcrest>
so ESP32S3 would be a more robust option?
<elmcrest>
most probably I wouldn't need more performance
<re_irc>
<@mabez:matrix.org> Only the Xtensa chips, ESP32, ESP32S2 & ESP32S3. Every other chip (ESP32C2, ESP32C3, ESP32C6, ESP32H2) is supported in Rust upstream today
<elmcrest>
currently things are running on a espressif8266
<elmcrest>
ehm ESP8266 I think is the correct term
<re_irc>
<@mabez:matrix.org> elmcrest: It's our most powerful chip at the moment, but requires a custom compiler (which we provide builds for and an installer)
<elmcrest>
sounds also nice to me
<re_irc>
<@louis.renuart.qteal:matrix.org> Hello, I am trying to wrap the "defmt::debug!" macro to add my own decoration to the text
<re_irc>
<@mabez:matrix.org> I haven't seen anyone running rocket on an esp, but I've seen people running tokio. Bear in mind this won't be bare metal, this will be using the standard libary port. You can read more about this here: https://esp-rs.github.io/book/overview/index.html
<elmcrest>
well, I'll give it a try
elmcrest has quit [Quit: elmcrest]
<re_irc>
<@like2wise:matrix.org> @mabez I would consider the standard library port to still be called bare metal, as there is no operating system layer between the application and metal, just a bunch of functions. Like how you would call newlib- or picolibc-based systems bare-metal in C.
<re_irc>
<@like2wise:matrix.org> (or is this seen differently in Rust context?)
<re_irc>
<@vollbrecht:matrix.org> likewise: thats not true as it runs FreeRTOS under the hood as a OS
<re_irc>
<@mabez:matrix.org> Yeah like said it runs FreeRTOS inside esp-idf and esp-idf also implements most of newlib (networking via lwip etc) to a point where you can run Rust STD on top of it. So I'd consider it not bare metal, though the lines are a little blurry
<re_irc>
<@avery71:matrix.org> I am struggling to understand why svd2rust did a thing it did. There are multiple places in the SVD that use the %s syntax, but in some of the places it combines the registers into arrays, but others it doesn't, I am not seeing any difference in the two sets of registers for why it would happen
IlPalazzo-ojiisa has joined #rust-embedded
duderonomy has quit [Remote host closed the connection]
duderonomy has joined #rust-embedded
dc740 has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> RTIC Question - I just realized that the reason I often get borrow-check errors when having multiple locks in the same ISR is actually a function of the tuple syntax used to lock multiple items. Is there a way around this that doesn't look like this, or a single mega-lock?:
<re_irc>
<@firefrommoonlight:matrix.org> RTIC Question - I just realized that the reason I often get borrow-check errors when having multiple locks in the same ISR is actually a function of the tuple syntax used to lock multiple items. Is there a way around this that doesn't look like this, or a single mega-lock?:
<re_irc>
| ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ value borrowed here after move
<re_irc>
...
<re_irc>
663 | cx.shared.config.lock(|config| {
<re_irc>
| ---------------- borrow occurs due to use in closure
<re_irc>
|
<re_irc>
= note: move occurs because `cx.shared.config` has type `config_that_needs_to_be_locked<'_>`, which does not implement the `Copy` trait
<re_irc>
<@firefrommoonlight:matrix.org> If I use the syntax you posted instead of the triple-nest above
<re_irc>
<@firefrommoonlight:matrix.org> The tuple is _moving_ it
<re_irc>
<@firefrommoonlight:matrix.org> So the rest of the ISR can't get it anymore
<re_irc>
<@firefrommoonlight:matrix.org> It's pretty easy to rep; lock the same resource more than once in an ISR, with the tuple syntax being used for both (or the first) case
<re_irc>
<@firefrommoonlight:matrix.org> -pretty
<re_irc>
<@jamesmunns:beeper.com> just a dumb question, can you do this instead?