<re_irc>
< (@adamgreig:matrix.org)> : aah cool, I didn't know cargo-release has stuff for multi-crate repos, that will be worth checking out, thanks!
<re_irc>
< (@adamgreig:matrix.org)> github's lack of support for multi-project repos like that is my main nuisance of monorepos
Amanieu has quit [Ping timeout: 255 seconds]
Amanieu has joined #rust-embedded
Socke has quit [Ping timeout: 248 seconds]
Socke has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
brazuca has joined #rust-embedded
rardiol has quit [Ping timeout: 246 seconds]
bjc has quit [Remote host closed the connection]
bjc has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
bjc has quit [Ping timeout: 255 seconds]
fabic_ has quit [Ping timeout: 246 seconds]
dc740 has joined #rust-embedded
<re_irc>
< (@crzyrndm:matrix.org)> Evening all
<re_irc>
I have a C lib that outputs a large (for an MCU anyway) array of floats. I don't need the precision and the post-processing happens way quicker if done with integers/fixed point (prototyped / benchmarked/ etc.)
<re_irc>
However at full size, I don't have the memory to allocate the array for both f32 and u16/u32. Is there a standard pattern / crate for transforming an array in place
<re_irc>
< (@crzyrndm:matrix.org)> * place?
<re_irc>
< (@crzyrndm:matrix.org)> (I realise that w/e way I do this there's probably going to be plenty of unsafe and probably a few pointers)
crabbedhaloablut has quit [Ping timeout: 255 seconds]
crabbedhaloablut has joined #rust-embedded
fabic_ has joined #rust-embedded
lehmrob has joined #rust-embedded
<re_irc>
< (@chrysn:matrix.org)> : If you want to use different sized types, you can use a union (https://doc.rust-lang.org/std/keyword.union.html), eg. "union F32orI16 { f: f32, i: i16 }" as an "[F32orI16; 2048]". This will not take "&mut [i16]" / give you a "&[i16]" ever, but using these will be tricky anyway due to alignment.
<re_irc>
< (@chrysn:matrix.org)> If you build a newtype (like "struct ConversionBuffer([F32orI16; 2048]);"), you can not have an unsafe ".assume_i16(&self) -> &[i16]", but you can have a "struct I16View<'a>)(&'a ConversionBuffer)" where the ConversiionBuffer has a ".assume_i16(&self) -> I16View<'_>", and I16View could implement iteration and indexing.
<re_irc>
< (@chrysn:matrix.org)> This would give you safe usability of the resulting buffer view and contain the unsafety to the ConversionBuffer.
jsolano has joined #rust-embedded
jsolano has quit [Quit: leaving]
jsolano has joined #rust-embedded
IlPalazzo-ojiisa has joined #rust-embedded
brazuca has quit [Quit: Client closed]
bjc has joined #rust-embedded
lehmrob has quit [Ping timeout: 248 seconds]
<re_irc>
< (@htms:matrix.org)> Hi, I have a problem with defmt prints with custom STM32L451 board.
<re_irc>
Knurling-rs app template and defmt steps:
<re_irc>
- cargo generated project from main branch
<re_irc>
- fullfilled TODOs (changed target, chip, memory layout, etc.)
<re_irc>
< (@korken89:matrix.org)> : Have you set the env variable? Like "DEFMT_LOG=trace" ?
<re_irc>
< (@htms:matrix.org)> : Yes. I was wandering over issues in defmt repo, it seems like it's a bug in defmt-rtt. Changing version of it from 0.4 to 0.3 worked for me.
<re_irc>
(but with your path) would be pretty enlightening
<re_irc>
< (@jamesmunns:beeper.com)> (and looking at the specific function that was choosing between those two key options)
<re_irc>
< (@boiethios:matrix.org)> Hello, I'm shopping to build my own keyboard, and I'm thinking about buying the rp2040. Is it well supported by Rust frameworks?
<re_irc>
< (@ithinuel:matrix.org)> : but there are some async drivers ready to be added to rp2040-hal as soon as they won't require an unstable feature ("async_fn_in_trait")
<re_irc>
< (@boiethios:matrix.org)> : Nice, I plan to build a Kyria. I'll definitely check your repo out.
<re_irc>
< (@ithinuel:matrix.org)> +EDIT: Bt least 1 (i2c) 😛
<re_irc>
< (@thejpster:matrix.org)> : what am I looking for to spot miscompilation?
<re_irc>
< (@thebutlah:matrix.org)> does doing a "delay_ms" have any effect at all on interrupts? Interrrupts will still fire as normal during a delay right?
<re_irc>
< (@jamesmunns:beeper.com)> Any hint to the functions that were making that one key vs the other decision?
<re_irc>
< (@jamesmunns:beeper.com)> I'm heading out for a bit, I can peek later if you can point me where to look.
<re_irc>
< (@dirbaio:matrix.org)> the pattern to trigger it was: indexing a small on-stack array with a value the compiler knows is bounded (like a "bool", or an enum variant casted as usize)
<re_irc>
< (@dirbaio:matrix.org)> perhaps you have something like that in the keyboard code?
<re_irc>
< (@dirbaio:matrix.org)> that's the pattern we found, nothing guarantees it's the only one though!
<re_irc>
< (@dirbaio:matrix.org)> so it could be anything
<re_irc>
< (@ithinuel:matrix.org)> : It might be something specific to your target. Which HAL is that from?
<re_irc>
< (@thejpster:matrix.org)> oh for sure. Keyboard HID events come from the BIOS into the OS as a struct of a u8 keycode and a small enum.
<re_irc>
< (@thejpster:matrix.org)> cmd_kbtest goes into a loop pumping the BIOS function hid_get_events, running the events through pc_keyboard EventDecoder and printing the results to the console.
<re_irc>
< (@thejpster:matrix.org)> It would sometimes just print the wrong keyboard code.
<re_irc>
< (@thejpster:matrix.org)> I recall that instead of pc_keyboard::KeyCode::RAlt2 it would say pc_keyboard::KeyCode::LShift, but then it would also get stuck somehow and not report all the key events. You'd press a key and then more key events would turn up, including the missing one from earlier. But not always? It was weird.
<re_irc>
< (@dirbaio:matrix.org)> welp finding it in a dump of 20k asm lines is going to be impossible
<re_irc>
< (@thejpster:matrix.org)> I mashed on the keys a whole bunch just now and it didn't seem to miss out anything or mis decode something. But you know, it could just be my bad programming.
brazuca has joined #rust-embedded
<re_irc>
< (@adamgreig:matrix.org)> I _think_ you'd expect to see it always hit the bug and never work, rather than sometimes work and sometimes not on the same execution
<re_irc>
< (@adamgreig:matrix.org)> but yea, perhaps it's some totally different manifestation of bug
IlPalazzo-ojiisa has quit [Quit: Leaving.]
dc740 has quit [Remote host closed the connection]
lehmrob has joined #rust-embedded
lehmrob has quit [Quit: Konversation terminated!]
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]