<Noah[m]1>
Hmm is there any way to use alloc on stable these days? Or do I always need nightly to register the allocator?
AshconMohseninia has joined #rust-embedded
<AshconMohseninia>
Question, how does one get probe-rs to flash custom segments of flash? I have a FLASH_VAR segment that is after main program flash, but it seems probe-rs does not flash this region at all
<AshconMohseninia>
I see probe-rs has a skip-section flash, but not something to specify a custom section to flash
glitchy has quit [Remote host closed the connection]
glitchy has joined #rust-embedded
jannic[m] has joined #rust-embedded
<jannic[m]>
<Noah[m]1> Hmm is there any way to use alloc on stable these days? Or do I always need nightly to register the allocator?
<Noah[m]1>
<AshconMohseninia> Question, how does one get probe-rs to flash custom segments of flash? I have a FLASH_VAR segment that is after main program flash, but it seems probe-rs does not flash this region at all
<Noah[m]1>
the section needs to be marked as load :)
ni has quit [Server closed connection]
ni has joined #rust-embedded
RobinMueller[m] has joined #rust-embedded
<RobinMueller[m]>
Are there any neovim enjoyers here? I recently updated my rustaceanvim to v6 and now have problems with the nvim-cmp replace behavior (always replaces for rust analyzer suggestions, which is really annoying), specifically in Rust files. maybe someone else uses a similar setup and encountered the same issue?
<RobinMueller[m]>
* the nvim-cmp confirm/replace behavior
<RobWells[m]>
<RobinMueller[m]> Are there any neovim enjoyers here? I recently updated my rustaceanvim to v6 and now have problems with the nvim-cmp replace behavior (always replaces for rust analyzer suggestions, which is really annoying), specifically in Rust files. maybe someone else uses a similar setup and encountered the...
<RobWells[m]>
I believe that's a configuration option in nvim-cmp. I remember being bitten by it when I first started using the plugin. Let me quickly check the docs.
<RobWells[m]>
Hm, yeah, odd that it's just rust. I'll have a think
tamme[m] has joined #rust-embedded
<tamme[m]>
<RobWells[m]> Does anyone know of a common SPI device that does full duplex communication (write to MOSI and read from MISO simultaneously)? I'm looking for something to test an implementation of eh::spi::SpiDevice::transfer against.
<tamme[m]>
Hey, as diondokter said we currently have a master student (vivian) working on developing a test suite for embedded-hal, where an RP2040 plays the role of a tester that emulates all kinds of devices. Unfortunately we started with I2C and have nothing for SPI yet.
ivche has joined #rust-embedded
<RobinMueller[m]>
<RobWells[m]> Hm, yeah, odd that it's just rust. I'll have a think
<RobinMueller[m]>
switched to blink.cmp now and the issue disappeared, at least for the default settings
<RobWells[m]>
Good. I looked through recent rustaceanvim & nvim-cmp(-lsp) changes but couldn't spot anything, beyond rediscovering the issues from last year that pushed me to switch myself.
corecode[m] has quit [Quit: Idle timeout reached: 172800s]
<dngrs[m]>
<RockBoynton[m]> AFAIK you can't do that on stable rust yet, you need `#![feature(generic_const_exprs)]`. If you need stable, you can make another const param and compute it ahead of time, e.g....
<dngrs[m]>
now that's a neat trick
<rjmp[m]>
Yeah...I would sure love this feature to stabilize! If I could validate the N/M relationship at build time, or hide it inside my library API, that would be a lot more palatable, but I can't really do either I dont think...
<rjmp[m]>
Hmm...I guess a non-const new could panic at least if they are wrong
<thejpster[m]>
I’m also not convinced it’s not a breaking change because there might be a bunch of trace level logs out there that do not work and we’d suddenly break all those builds. I agree it’s better to check them but we don’t have the luxury of breaking changes in defmt due to how it works (with magic extern symbols).