00:04 <re_irc> <@adamgreig:matrix.org> the paper is https://arxiv.org/pdf/2105.05818.pdf

00:04 <re_irc> <@adamgreig:matrix.org> that news article is somewhat shy on details

00:12 <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

00:35 <re_irc> <@lachlansneff:matrix.org> This has gotta be something they’re gonna patent or something down the line then.

00:36 <re_irc> <@lachlansneff:matrix.org> It’d be pointless to write a paper that doesn’t actually say how the process works otherwise.

00:38 <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

00:39 <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?

00:40 <re_irc> <@lachlansneff:matrix.org> Ah, interesting.

00:41 <re_irc> <@lachlansneff:matrix.org> So, a folding ADC would let you read a signal larger than reference voltage?

00:41 <re_irc> <@adamgreig:matrix.org> A resistor divider lets you read a signal greater than the reference voltage :p

00:42 <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)

00:42 <re_irc> <@adamgreig:matrix.org> http://www.analog.com/static/imported-files/tutorials/MT-025.pdf has some designs

00:42 <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

00:43 <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)

00:44 <re_irc> <@lachlansneff:matrix.org> That’s quite neat.

00:44 <re_irc> <@lachlansneff:matrix.org> Something in the arsenal I guess

00:45 <re_irc> <@adamgreig:matrix.org> Yea! Probably having this signal processing might encourage people to design other modulo sensors for example

00:46 <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

00:48 <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

01:02 <re_irc> <@lachlansneff:matrix.org> adamgreig: Oh huh, this would be super useful

01:44 <re_irc> <@jorgeig:matrix.org> lulf_:matrix.org: In the stm32 Hal, ST uses the radio to get random numbers

03:47 <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

03:47 <re_irc> <@nihal.pasham:matrix.org> ```toml

03:47 <re_irc> <@nihal.pasham:matrix.org> # =============================================================================

03:47 <re_irc> <@nihal.pasham:matrix.org> # Build configuration options for Cortex-M

03:47 <re_irc> ... long message truncated: https://psion.agg.io/_matrix/media/r0/download/psion.agg.io/6538c56467f281beb11a951f0008196b43979d812e7ab22fac26f5bef97a4abd (26 lines)

03:48 <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.

03:51 <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.

06:52 <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

06:52 <re_irc> <@thejpster:matrix.org> cargo build --target=foo.bar.baz

07:38 <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.

08:11 <re_irc> <@henrik_alser:matrix.org> martb99:matrix.org: Use `#[derive(Format)]` for defmt

08:12 <re_irc> <@henrik_alser:matrix.org> defmt::Format that is :)

08:27 <re_irc> <@martb99:matrix.org> henrik_alser:matrix.org: that fixed the issue, thank you!

09:37 <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

09:38 <re_irc> <@thejpster:matrix.org> See https://github.com/rust-embedded/cortex-m-rt/blob/master/.cargo/config

20:57 <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?

20:59 <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

20:59 <re_irc> <@adamgreig:matrix.org> For example though, https://github.com/rust-embedded/alloc-cortex-m

21:01 <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 ?

21:49 <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