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
starblue3 has joined #rust-embedded
starblue2 has quit [Ping timeout: 240 seconds]
m5zs7k has quit [Ping timeout: 252 seconds]
m5zs7k has joined #rust-embedded
Sockeee has quit [Ping timeout: 252 seconds]
Sockeee has joined #rust-embedded
Sockeee has quit [Ping timeout: 250 seconds]
duderonomy has quit [Ping timeout: 264 seconds]
Sockeee has joined #rust-embedded
Sockeee has quit [Ping timeout: 264 seconds]
Sockeee has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc> <@azzentys:matrix.org> Just curious, is anyone still maintaining stm32l4xx-hal?
<re_irc> <@sourcebox:matrix.org> : It was stated here by about 2 weeks ago that he does not work on it anymore.
<re_irc> <@azzentys:matrix.org> Understood. However, last commit on Master looks little bit old - https://github.com/stm32-rs/stm32l4xx-hal
<re_irc> <@korken89:matrix.org> I have push rights but I'm not actively maintaining it
<re_irc> <@korken89:matrix.org> We moved to a different MCU in our product so I could not motivate work time to help anymore :/
<re_irc> <@azzentys:matrix.org> Makes sense!
<re_irc> <@korken89:matrix.org> I think the embassy STM32 HAL is well maintained though
<re_irc> <@korken89:matrix.org> Maybe worth a try
<re_irc> <@sourcebox:matrix.org> The question that arises is if this crate should still be recommended for new projects.
<re_irc> <@korken89:matrix.org> : For what we did it was fully functional at least
<re_irc> <@azzentys:matrix.org> Is it this? https://embassy.dev/book/dev/stm32.html
<re_irc> <@korken89:matrix.org> Yep
<re_irc> <@azzentys:matrix.org> Thanks for your answers! That's helpful!
<re_irc> <@korken89:matrix.org> I think can give a more up to date on how well L4 is supported :)
<re_irc> <@korken89:matrix.org> But a quick glance seems to check out
<re_irc> <@korken89:matrix.org> Here starts the list of supported L series https://github.com/embassy-rs/embassy/blob/main/embassy-stm32/Cargo.toml#L1007
<re_irc> <@korken89:matrix.org> L0, L1 and L4s
<re_irc> <@azzentys:matrix.org> I was just looking at that, and they have an astonishing number of devices supported. Wow!
<re_irc> <@sourcebox:matrix.org> There's also the crate from who is actively working on it. Supports L4, too. https://github.com/David-OConnor/stm32-hal
<re_irc> <@korken89:matrix.org> The PAC is written a bit like the ChibiOS HAL, so it's one HAL for all MCUs
<re_irc> <@korken89:matrix.org> * HAL
<re_irc> <@korken89:matrix.org> Same for version as well
<re_irc> <@azzentys:matrix.org> I like that design.
<re_irc> <@azzentys:matrix.org> I'll place it on my list to study that.
<re_irc> <@korken89:matrix.org> The design is the rest of the ecosystem is a bit weird tbh, I think what and is doing is the right direction
<re_irc> <@azzentys:matrix.org> I've been trying to understand/read/design/think about HALs in Rust for a year. I feel a bit confident now to read them.
<re_irc> <@korken89:matrix.org> STM32s in particular use the same peripherals in multiple chips, so no need to rewrite the same driver multiple times
<re_irc> <@korken89:matrix.org> More or less, is the motivation
<re_irc> <@korken89:matrix.org> :)
<re_irc> <@korken89:matrix.org> For more details I'll let the authors answer :D
<re_irc> <@azzentys:matrix.org> Thanks again! My study material just increased in size! :)
<re_irc> <@korken89:matrix.org> No problem :)
<re_irc> <@azzentys:matrix.org> At work, we have a small project - where I want to use Rust (just for fun). I hope I can make use of the great resources people have written!
<re_irc> <@korken89:matrix.org> That should be no problem :)
<re_irc> <@korken89:matrix.org> We use Rust in 5 different HW products now with 2 different MCU families
<re_irc> <@azzentys:matrix.org> I also hope to get competent enough to help out if help is needed. Might need more experience overall.
<re_irc> <@korken89:matrix.org> There is a lot of help to get here :)
<re_irc> <@korken89:matrix.org> It's generally good to all in the right room though, so if you have RTIC questions ask in that room, if you have embassy questions, ask in that room, etc
<re_irc> <@korken89:matrix.org> And here for general or if you don't know where to ask :)
<re_irc> <@korken89:matrix.org> People will answer or point you in the right direction :)
<re_irc> <@azzentys:matrix.org> Appreciate that!
<re_irc> <@azzentys:matrix.org> RTIC seems like a mini RTOS, is that what it is? Looking at the features, it does seem to offer Tasks, IPC like features.
<re_irc> <@diondokter:matrix.org> : Pretty much, but it uses interrupts instead of threads
<re_irc> <@sourcebox:matrix.org> Yes, it's an RTOS. I haven't looked into it recently because it was initially closely tied to Cortex-M while I was looking for an RTOS that was more cross-platform.
<re_irc> <@sourcebox:matrix.org> I don't know if there's something like FreeRTOS but purely Rust.
starblue3 has quit [Ping timeout: 250 seconds]
<re_irc> <@azzentys:matrix.org> Rtic does deserve a place in my study material!
<re_irc> <@azzentys:matrix.org> : A lot of that is written in C, even Zephyr.
<re_irc> <@sourcebox:matrix.org> One of the advantages with Rust is that it guarantees to build your code in all future releases, as long as you use stable.
<re_irc> <@sourcebox:matrix.org> As soon as C/C++ gets involved, this is not the case anymore. And I have spent enough time in the past just to get projects build again.
loki_val has quit []
<re_irc> <@lambdafriend:matrix.org> I'm finding that just leaking some memory from SDRAM is corrupting my audio.
<re_irc> #[no_mangle]
<re_irc> const SDRAM_SIZE: usize = 32 * 1_024 * 1_024; // 32MiB
<re_irc> #[link_section = ".sdram"]
<re_irc> static SDRAM: static_alloc::Bump<[u8; SDRAM_SIZE]> = static_alloc::Bump::uninit();
<re_irc> ...elsewhere down the call chain
<re_irc> let dl1_sdram = sdram.leak([0.0; 12_000]).unwrap();
<re_irc> If I comment out that line, the audio is fine. If that line is there, the audio is corrupted. I'm not event doing anything with it.
<re_irc> My best guess is the memory layout is overlapping with the audio buffer, but it seems they're two different sections.
<re_irc> pub const BLOCK_SIZE_MAX: usize = 1024;
<re_irc> pub const DMA_BUFFER_SIZE: usize = BLOCK_SIZE_MAX * 2 * 2;
<re_irc> #[link_section = ".sram1_bss"]
<re_irc> #[no_mangle]
<re_irc> static mut TX_BUFFER: DmaBuffer = [0; DMA_BUFFER_SIZE];
<re_irc> #[link_section = ".sram1_bss"]
<re_irc> #[no_mangle]
<re_irc> static mut RX_BUFFER: DmaBuffer = [0; DMA_BUFFER_SIZE];
<re_irc> Does anyone have an advice, or threads to pull on?
<re_irc> <@lambdafriend:matrix.org> I'm finding that just leaking some memory from SDRAM is corrupting my audio.
<re_irc> const SDRAM_SIZE: usize = 32 * 1_024 * 1_024; // 32MiB
<re_irc> #[no_mangle]
<re_irc> #[link_section = ".sdram"]
<re_irc> static SDRAM: static_alloc::Bump<[u8; SDRAM_SIZE]> = static_alloc::Bump::uninit();
<re_irc> ...elsewhere down the call chain
<re_irc> let dl1_sdram = sdram.leak([0.0; 12_000]).unwrap();
<re_irc> If I comment out that line, the audio is fine. If that line is there, the audio is corrupted. I'm not event doing anything with it.
<re_irc> My best guess is the memory layout is overlapping with the audio buffer, but it seems they're two different sections.
<re_irc> pub const BLOCK_SIZE_MAX: usize = 1024;
<re_irc> pub const DMA_BUFFER_SIZE: usize = BLOCK_SIZE_MAX * 2 * 2;
<re_irc> #[link_section = ".sram1_bss"]
<re_irc> #[no_mangle]
<re_irc> static mut TX_BUFFER: DmaBuffer = [0; DMA_BUFFER_SIZE];
<re_irc> #[link_section = ".sram1_bss"]
<re_irc> #[no_mangle]
<re_irc> static mut RX_BUFFER: DmaBuffer = [0; DMA_BUFFER_SIZE];
<re_irc> Does anyone have an advice, or threads to pull on?
crabbedhaloablut has joined #rust-embedded
<re_irc> <@lambdafriend:matrix.org> +I'm not even sure how to debug this.
<re_irc> <@lambdafriend:matrix.org> +// even [0.0; 0] breaks it!
emerent has quit [Ping timeout: 245 seconds]
emerent has joined #rust-embedded
<re_irc> <@lambdafriend:matrix.org> -// even [0.0; 0] breaks it!
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
<re_irc> <@lambdafriend:matrix.org> Never did figure this out, but it turns out that the BSP I'm using already has an sdram abstraction so I just used that and everything seems to be working.
starblue3 has joined #rust-embedded
limpkin has quit [Quit: limpkin]
limpkin has joined #rust-embedded
starblue3 has quit [Ping timeout: 240 seconds]
dc740 has quit [Remote host closed the connection]
DisconSented has quit [Quit: No Ping reply in 180 seconds.]
starblue3 has joined #rust-embedded
DisconSented has joined #rust-embedded
duderonomy has joined #rust-embedded