<re_irc> <@adamgreig:matrix.org> the paper is https://arxiv.org/pdf/2105.05818.pdf
<re_irc> <@adamgreig:matrix.org> that news article is somewhat shy on details
<re_irc> <@adamgreig:matrix.org> I think the research interest is in the signal processing for the reconstruction, more or less assuming someone gives you such a folded signal, but in any event the paper doesn't discuss how their prototype hardware works at all
ni has quit [Ping timeout: 252 seconds]
<re_irc> <@lachlansneff:matrix.org> This has gotta be something they’re gonna patent or something down the line then.
<re_irc> <@lachlansneff:matrix.org> It’d be pointless to write a paper that doesn’t actually say how the process works otherwise.
<re_irc> <@adamgreig:matrix.org> Maybe, but the tricks and novelty seems to all be in their reconstruction algorithm, I feel like the hardware is just a fun demo to show the algorithm working on some real signals
<re_irc> <@adamgreig:matrix.org> If looks like folding or self-resetting ADCs are a separate research area with some recent developments including CMOS sensors and things, and I guess that validates their research interest?
<re_irc> <@lachlansneff:matrix.org> Ah, interesting.
<re_irc> <@lachlansneff:matrix.org> So, a folding ADC would let you read a signal larger than reference voltage?
<re_irc> <@adamgreig:matrix.org> A resistor divider lets you read a signal greater than the reference voltage :p
<re_irc> <@adamgreig:matrix.org> A folding adc gives you the remainder of the input voltage after division by some voltage (in other words the modulo)
<re_irc> <@adamgreig:matrix.org> http://www.analog.com/static/imported-files/tutorials/MT-025.pdf has some designs
<re_irc> <@adamgreig:matrix.org> It's not usually very useful to get this because it's not clear how you would reconstruct the original signal
<re_irc> <@adamgreig:matrix.org> But it seems like in some very niche applications it might be useful to just get the modulo, and then this new paper is proposing a signal processing technique to do reconstruction (under some conditions which might be quite limiting)
<re_irc> <@lachlansneff:matrix.org> That’s quite neat.
<re_irc> <@lachlansneff:matrix.org> Something in the arsenal I guess
<re_irc> <@adamgreig:matrix.org> Yea! Probably having this signal processing might encourage people to design other modulo sensors for example
<re_irc> <@adamgreig:matrix.org> A camera sensor could then have very good dynamic range. It's a bit like some recent advances in reconstruction allowing single pixel cameras I guess
<re_irc> <@adamgreig:matrix.org> It would be cool to see how their pcb works, for sure! the paper says they'll release details eventually, but perhaps it's very similar to the circuits in that AD paper
<re_irc> <@lachlansneff:matrix.org> adamgreig: Oh huh, this would be super useful
ni has joined #rust-embedded
<re_irc> <@jorgeig:matrix.org> lulf_:matrix.org: In the stm32 Hal, ST uses the radio to get random numbers
PyroPeter has quit [Ping timeout: 264 seconds]
PyroPeter has joined #rust-embedded
fabic has joined #rust-embedded
<re_irc> <@nihal.pasham:matrix.org> quick question: Is there a way to conditionally select build targets via `config.toml`? For ex: I have this config.toml file and was wondering if there is a way to conditional a cortex-m Vs cortex-a target during the build process
<re_irc> <@nihal.pasham:matrix.org> ```toml
<re_irc> <@nihal.pasham:matrix.org> # =============================================================================
<re_irc> <@nihal.pasham:matrix.org> # Build configuration options for Cortex-M
<re_irc> <@nihal.pasham:matrix.org> for now - I'm having to comment out all other targets and explicitly uncomment the one I'm building for.
<re_irc> <@nihal.pasham:matrix.org> `config.toml` says I can have only one build target per file. So, just wanted to check if there is some other way to (you know) avoid having to comment/uncomment stuff for each build.
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
dcz_ has joined #rust-embedded
<re_irc> <@thejpster:matrix.org> You can have multiple [target.foo-bar-baz] blocks, but you have to pick one target when you call cargo
<re_irc> <@thejpster:matrix.org> cargo build --target=foo.bar.baz
fabic has quit [Ping timeout: 252 seconds]
fabic has joined #rust-embedded
<re_irc> <@martb99:matrix.org> does anyone know if #[derive(Debug)] works for defmt printing? I keep getting compilling when trying to print a enum with the debug! macro.
fabic has quit [Ping timeout: 265 seconds]
<re_irc> <@henrik_alser:matrix.org> martb99:matrix.org: Use `#[derive(Format)]` for defmt
<re_irc> <@henrik_alser:matrix.org> defmt::Format that is :)
<re_irc> <@martb99:matrix.org> henrik_alser:matrix.org: that fixed the issue, thank you!
\\ has joined #rust-embedded
\\ has left #rust-embedded [Leaving]
<re_irc> <@nihal.pasham:matrix.org> thejpster:matrix.org: had to step out for a bit. So, I could have multiple target blocks and specify extra options (such as rustflags) for each block
starblue1 has quit [Ping timeout: 252 seconds]
fabic has joined #rust-embedded
starblue1 has joined #rust-embedded
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 276 seconds]
dcz_ has quit [Read error: Connection reset by peer]
dcz_ has joined #rust-embedded
fabic has quit [Ping timeout: 260 seconds]
dcz_ has quit [Read error: Connection reset by peer]
dcz_ has joined #rust-embedded
dfgweb has quit [Quit: Leaving]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 252 seconds]
dcz_ has quit [Ping timeout: 252 seconds]
emerent has quit [Ping timeout: 252 seconds]
emerent has joined #rust-embedded
<re_irc> <@gauteh:matrix.org> Hi. I am a bit confused about the lack of system allocators for embedded systems. Many platforms have heap alloc in C, e.g. many arduino boards (both avr and arm). I realize this is not an OS provided allocator, but it is supported by the system in some way. What is the reason that this is available in C but not in rust? Could it be made available by wrapping malloc/free in libc for these platforms?
<re_irc> <@adamgreig:matrix.org> There are some for embedded, though the interface in rust to provide a global allocator that everything can use by default is still unstable
<re_irc> <@adamgreig:matrix.org> For example though, https://github.com/rust-embedded/alloc-cortex-m
<re_irc> <@gauteh:matrix.org> ok, and that could possibly live somewhere like: https://github.com/rust-lang/rust/blob/master/library/std/src/sys/unix/alloc.rs#L14 ?
<re_irc> <@adamgreig:matrix.org> If wouldn't live in there, if you use that alloc-cortex-m crate it would provide an allocator for everything in rust that needs to allocate, like Box or Vec
tokomak has joined #rust-embedded