<re_irc> <@j​amesmunns:m​atrix.org> Reminder that:
<re_irc> <@j​amesmunns:m​atrix.org> 1. `micromath` exists, and is an alternative to libm if you don't *need* the precision
<re_irc> <@j​amesmunns:m​atrix.org> 2. it slaps really hard
<re_irc> <@j​amesmunns:m​atrix.org> https://docs.rs/micromath
<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)
<re_irc> <@j​amesmunns:m​atrix.org> (fading LEDs)
<re_irc> <@d​irbaio:m​atrix.org> gotta render those LEDs at 16666fps!
<re_irc> <@9​names:m​atrix.org> or render 16666 LEDs at 1 fps 😀
<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
<re_irc> <@j​amesmunns:m​atrix.org> 3.6ms total for 60fps is better than 36ms total for 60 fps :D
<re_irc> <@j​amesmunns:m​atrix.org> 0.36% of my budget instead of 3.6% of my budget!
<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)
<re_irc> <@j​amesmunns:m​atrix.org> (372us/update)
<re_irc> <@a​damgreig:m​atrix.org> are you using spi or a timer for sending the led data?
<re_irc> <@a​damgreig:m​atrix.org> i wonder which ends up being more cpu efficient
starblue3 has joined #rust-embedded
<re_irc> <@j​amesmunns:m​atrix.org> PWM
<re_irc> <@j​amesmunns:m​atrix.org> but DMA enabled PWM, just right now it's blocking
<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.
<re_irc> <@j​amesmunns:m​atrix.org> (one u16 per bit, basically, for hi and lo times)
starblue2 has quit [Ping timeout: 272 seconds]
<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
<re_irc> <@j​amesmunns:m​atrix.org> (the smart led spi crate assumes 2.x-3.x mbps IIRC)
<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
<re_irc> <@j​amesmunns:m​atrix.org> so you need a pin just outputting noise to the ether as sacrifice for your I2S smartled
<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"
<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.
<re_irc> <@b​urrbull:m​atrix.org> in readme of `fixed` you can find link to https://docs.rs/cordic/0.1.5/cordic/
Ekho- is now known as Ekho
<re_irc> <@b​radleyharden:m​atrix.org> Ah, I missed that
phoenix has quit [Killed (iridium.libera.chat (Nickname regained by services))]
Guest4180 has joined #rust-embedded
<re_irc> <@j​amesmunns:m​atrix.org> Did the math, this means it only takes me 384 clock cycles to re-render each pixel
<re_irc> <@j​amesmunns:m​atrix.org> which seems like a good number of cycles
<cr1901> It would be better if it was two more cycles
<re_irc> <@j​amesmunns:m​atrix.org> Hah! It was only an estimate, but I see what you're going for :D
<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
<cr1901> Been forgetting to mention
<hifi> first time I see someone talking on irc and the bridge is desynced, uh
<cr1901> of course it is :(
<hifi> the failsafe works alright, though
tokomak has joined #rust-embedded
emerent_ has joined #rust-embedded
emerent has quit [Killed (iridium.libera.chat (Nickname regained by services))]
emerent_ is now known as emerent
gsalazar has joined #rust-embedded
gsalazar has quit [Ping timeout: 264 seconds]
neceve has joined #rust-embedded
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
inara` has quit [Quit: Leaving]
re_irc has quit [Remote host closed the connection]
re_irc has joined #rust-embedded
inara has joined #rust-embedded
<re_irc> <@h​untc:m​atrix.org> Why do we still use AT commands to configure devices over UART? :-)
GenTooMan has quit [Ping timeout: 268 seconds]
GenTooMan has joined #rust-embedded
<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...
<re_irc> ... float.
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 272 seconds]
rjframe has joined #rust-embedded
<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?
<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.
<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!
<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 :)
<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.
<re_irc> <@j​ordens:m​atrix.org> In true Rust style as a "zero-cost feature" ;)
fabic has joined #rust-embedded
<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.
<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
<re_irc> <@d​irbaio:m​atrix.org> @huntc:matrix.org: backwards compatibility
<re_irc> <@d​irbaio:m​atrix.org> rabbit hole goes deeper: AT-command modems can switch to PPP mode to send/receive IP packets
<re_irc> <@d​irbaio:m​atrix.org> LTE no longer speaks PPP over the air
<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
<re_irc> <@d​irbaio:m​atrix.org> all for backwards compatibility 🤪
fabic has quit [Ping timeout: 244 seconds]
Lumpio- has joined #rust-embedded
<Lumpio-> Hum, so this channel exists on this side then
<tokomak> so does ##rust-retro but the bridge keeps not being there
tokomak has quit [Read error: Connection reset by peer]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 244 seconds]
astroanax has joined #rust-embedded
astroanax has left #rust-embedded [WeeChat 3.1]
astroanax has joined #rust-embedded
rjframe has quit [Remote host closed the connection]
fabic has joined #rust-embedded
fabic has quit [Ping timeout: 244 seconds]
neceve has quit [Ping timeout: 272 seconds]
starblue3 has quit [Quit: WeeChat 2.3]
starblue has joined #rust-embedded
rjframe has joined #rust-embedded
<re_irc> <@d​irbaio:m​atrix.org> is there a downside to using stuff from `alloc` when you do have `std`?
<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?
<re_irc> <@d​iondokter:m​atrix.org> I never ran into any trouble
<re_irc> <@d​irbaio:m​atrix.org> or do I have to eg cnditionally import `alloc::vec::Vec` or `std::vec::Vec`?
<re_irc> <@d​iondokter:m​atrix.org> You do have to import the alloc stuff yeah\
<re_irc> <@d​irbaio:m​atrix.org> so always importing `alloc::vec::Vec` should be fine?
<re_irc> <@d​irbaio:m​atrix.org> all platforms that have std have alloc too I guess
<re_irc> <@d​iondokter:m​atrix.org> Oh, I get it now. Yes, always using alloc instad of std is fine
<re_irc> <@d​irbaio:m​atrix.org> 👍️ thanks!
<re_irc> <@d​irbaio:m​atrix.org> is `extern crate alloc;` needed
<re_irc> <@d​irbaio:m​atrix.org> but for some reason you do need it for alloc..?? lol
<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
<re_irc> <@d​irbaio:m​atrix.org> 🤷‍♂️
<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
<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.
<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....
<re_irc> <@t​herealprof:m​atrix.org> @dirbaio:matrix.org: Yeah, I had that, too. And I agree it's weird and annoying.