00:53 <re_irc> <@j​amesmunns:m​atrix.org> Reminder that:

00:53 <re_irc> <@j​amesmunns:m​atrix.org> 1. `micromath` exists, and is an alternative to libm if you don't *need* the precision

00:53 <re_irc> <@j​amesmunns:m​atrix.org> 2. it slaps really hard

00:53 <re_irc> <@j​amesmunns:m​atrix.org> https://docs.rs/micromath

00:54 <re_irc> <@j​amesmunns:m​atrix.org> For my sin/cos heavy application, on a 64MHz CPU w/ HF, it dropped my rendering time an order of magnitude (600us -> 60us)

00:54 <re_irc> <@j​amesmunns:m​atrix.org> (fading LEDs)

00:59 <re_irc> <@d​irbaio:m​atrix.org> gotta render those LEDs at 16666fps!

01:02 <re_irc> <@9​names:m​atrix.org> or render 16666 LEDs at 1 fps 😀

01:04 <re_irc> <@j​amesmunns:m​atrix.org> I gotta lot of other things to do! For once the primary objective is not the LEDs themselves :D

01:05 <re_irc> <@j​amesmunns:m​atrix.org> 3.6ms total for 60fps is better than 36ms total for 60 fps :D

01:05 <re_irc> <@j​amesmunns:m​atrix.org> 0.36% of my budget instead of 3.6% of my budget!

01:07 <re_irc> <@j​amesmunns:m​atrix.org> It also incentivizes me to optimize the 372uS I spend in blocking send for updating the LED display (or make it nonblocking/DMA like everything else I'm doing here)

01:07 <re_irc> <@j​amesmunns:m​atrix.org> (372us/update)

01:09 <re_irc> <@a​damgreig:m​atrix.org> are you using spi or a timer for sending the led data?

01:09 <re_irc> <@a​damgreig:m​atrix.org> i wonder which ends up being more cpu efficient

01:14 <re_irc> <@j​amesmunns:m​atrix.org> PWM

01:15 <re_irc> <@j​amesmunns:m​atrix.org> but DMA enabled PWM, just right now it's blocking

01:16 <re_irc> <@j​amesmunns:m​atrix.org> I2S would actually be better, probably. using the PWM engine on the nrf52 (which is really powerful) is not very space efficient, it takes 48 bytes/LED + 80 bytes for the terminator.

01:17 <re_irc> <@j​amesmunns:m​atrix.org> (one u16 per bit, basically, for hi and lo times)

01:18 <re_irc> <@j​amesmunns:m​atrix.org> I don't use SPI on the nrf52, since it can only do 2 or 4mpbs, and 2 seems sort of flaky on some LEDs in my experience

01:19 <re_irc> <@j​amesmunns:m​atrix.org> (the smart led spi crate assumes 2.x-3.x mbps IIRC)

01:20 <re_irc> <@j​amesmunns:m​atrix.org> IIRC I didn't impl the I2S flavor for my nrf-smartled crate because it required having a "throwaway" pin for MCLK or something. If you don't map a pin to it the I2S engine doesn't actually run

01:20 <re_irc> <@j​amesmunns:m​atrix.org> so you need a pin just outputting noise to the ether as sacrifice for your I2S smartled

01:23 <re_irc> <@j​amesmunns:m​atrix.org> With nonblocking DMA, it would probably come down to whichever uses fewer bytes to generate/simulate the bitstream (I2S is much better than PWM iirc on the nrf52), just in terms of "time to render stream" and "AHB usage"

02:16 <re_irc> <@b​radleyharden:m​atrix.org> jamesmunns, is there any equivalent for fixed-point numbers? I've been using `fixed`, but it doesn't have math operations.

02:27 <re_irc> <@b​urrbull:m​atrix.org> in readme of `fixed` you can find link to https://docs.rs/cordic/0.1.5/cordic/

02:41 <re_irc> <@b​radleyharden:m​atrix.org> Ah, I missed that

04:27 <re_irc> <@j​amesmunns:m​atrix.org> Did the math, this means it only takes me 384 clock cycles to re-render each pixel

04:27 <re_irc> <@j​amesmunns:m​atrix.org> which seems like a good number of cycles

04:51 <cr1901> It would be better if it was two more cycles

04:52 <re_irc> <@j​amesmunns:m​atrix.org> Hah! It was only an estimate, but I see what you're going for :D

04:58 <cr1901> Btw, jamesmunns: https://github.com/rust-lang/rust/issues/67819#issuecomment-856284714 I linked one of your blog posts here. It _may_ be relevant to ARM too

04:58 <cr1901> Been forgetting to mention

05:01 <hifi> first time I see someone talking on irc and the bridge is desynced, uh

05:01 <cr1901> of course it is :(

05:02 <hifi> the failsafe works alright, though

10:23 <re_irc> <@h​untc:m​atrix.org> Why do we still use AT commands to configure devices over UART? :-)

10:42 <re_irc> <@j​ordens:m​atrix.org> @jamesmunns:matrix.org: You can do much better (accuracy and speed) than the usual poly expansions or CORDIC with a tiny LUT and linear interpolation: https://github.com/quartiq/stabilizer/blob/master/dsp/src/cossin.rs This is only some 40 cycles to get both cos and sin to about 18 bit accuracy. No need for...

10:42 <re_irc> ... float.

11:45 <re_irc> <@h​untc:m​atrix.org> @huntc:matrix.org: I get why we used to i.e. to command a device in some OOB manner - pretty cool. But why do we continue to config devices this way where the UART is already OOB?

11:46 <re_irc> <@h​untc:m​atrix.org> I'm thinking that it is just because we are creatures of habit, but I'm curious to learn if others here have a different perspective.

12:14 <re_irc> <@j​amesmunns:m​atrix.org> jordens: nice! I'm not optimizing that far down yet, but it's good to know I have options!

12:17 <re_irc> <@j​amesmunns:m​atrix.org> I knew "LUT" was the best answer, but I was also sorta hacking this together as fast as possible too :)

12:17 <re_irc> <@j​ordens:m​atrix.org> Also, as with all good fixed point DSP implementations, it uses the integer wraparound to naturally implement the 2\pi modulo.

12:17 <re_irc> <@j​ordens:m​atrix.org> In true Rust style as a "zero-cost feature" ;)

13:46 <re_irc> <@9​names:m​atrix.org> @huntc:matrix.org: Implementation is already there. Easy to debug. Lots of tools that support it already exist.

13:46 <re_irc> <@9​names:m​atrix.org> It's a combination of laziness and not wanting to design and support another 12 standards that implement basically the same thing

13:52 <re_irc> <@d​irbaio:m​atrix.org> @huntc:matrix.org: backwards compatibility

13:54 <re_irc> <@d​irbaio:m​atrix.org> rabbit hole goes deeper: AT-command modems can switch to PPP mode to send/receive IP packets

13:54 <re_irc> <@d​irbaio:m​atrix.org> LTE no longer speaks PPP over the air

13:54 <re_irc> <@d​irbaio:m​atrix.org> so *the modem emulates the PPP server* and translates the IP packets to/from PPP and whatever LTE uses

13:54 <re_irc> <@d​irbaio:m​atrix.org> all for backwards compatibility 🤪

13:59 <Lumpio-> Hum, so this channel exists on this side then

14:00 <tokomak> so does ##rust-retro but the bridge keeps not being there

22:05 <re_irc> <@d​irbaio:m​atrix.org> is there a downside to using stuff from `alloc` when you do have `std`?

22:06 <re_irc> <@d​irbaio:m​atrix.org> ie, if I want to support both std and nostd-with-alloc, can I simply always pull stuff from alloc?

22:06 <re_irc> <@d​iondokter:m​atrix.org> I never ran into any trouble

22:06 <re_irc> <@d​irbaio:m​atrix.org> or do I have to eg cnditionally import `alloc::vec::Vec` or `std::vec::Vec`?

22:06 <re_irc> <@d​iondokter:m​atrix.org> You do have to import the alloc stuff yeah\

22:07 <re_irc> <@d​irbaio:m​atrix.org> so always importing `alloc::vec::Vec` should be fine?

22:07 <re_irc> <@d​irbaio:m​atrix.org> all platforms that have std have alloc too I guess

22:07 <re_irc> <@d​iondokter:m​atrix.org> Oh, I get it now. Yes, always using alloc instad of std is fine

22:07 <re_irc> <@d​irbaio:m​atrix.org> 👍️ thanks!

22:10 <re_irc> <@d​irbaio:m​atrix.org> is `extern crate alloc;` needed

22:10 <re_irc> <@d​irbaio:m​atrix.org> but for some reason you do need it for alloc..?? lol

22:12 <re_irc> <@d​iondokter:m​atrix.org> Oh yeah you may be right. I don't know why that is. Probably something to implement the alloc crate in a backwards compatible way. But that's just me guessing

22:12 <re_irc> <@d​irbaio:m​atrix.org> 🤷‍♂️

22:12 <re_irc> <@d​irbaio:m​atrix.org> but either way, it seems like `extern crate alloc; use alloc::vec::Vec;` always works, even in std targets

22:15 <re_irc> <@d​iondokter:m​atrix.org> https://doc.rust-lang.org/edition-guide/rust-next/alloc.html

22:15 <re_irc> <@d​iondokter:m​atrix.org> This doesn't really explain why. It does say though that std just re-exports the alloc crate.

22:18 <re_irc> <@d​irbaio:m​atrix.org> the "approve and run" GHA thing is so annoying... plus it's supposed to be only the first time for each contributor but I find myself having to click it multiple times for the same contributor....

22:51 <re_irc> <@t​herealprof:m​atrix.org> @dirbaio:matrix.org: Yeah, I had that, too. And I agree it's weird and annoying.