<re_irc>
<James Munns> yruama_lairba: "AVDD" is usually the analog power source. I'm not too familiar with that chip or board, but often you can provide a different power supply to the analog voltage. Sometimes this can be to limit the voltage range - e.g. if you have 14 bits of precision, it'll be more precise across 1.0v instead of 3.0v, or sometimes you provide it with a smoother power supply, buffered from other parts of the system,...
<re_irc>
... to have a "cleaner" analog rail to have better precision
<re_irc>
<James Munns> that being said, in like 99% of cases, I just see it connected to the same power bus as the main CPU, maybe with an extra capacitor for decoupling.
<re_irc>
<James Munns> But the info you're looking for would probably be:
<re_irc>
- See if the datasheet for that chip mentions AVDD, and what you can do with it (probably near the ADC section of the datasheet)
<re_irc>
- If it doesn't, look at the schematic to figure out what MCU pin is connected to the "AVDD" pin on the board.
<re_irc>
<yruama_lairba> wich schematics ?
<re_irc>
<James Munns> What nucleo board do you have?
<re_irc>
<yruama_lairba> found
<re_irc>
<James Munns> (STM32 publishes the schematics of all of their nucleo and discovery boards - most other manufacturers do for their development kits as well)
<re_irc>
<yruama_lairba> so avdd drive many *vref+ pin
<re_irc>
<yruama_lairba> thanks i would never search for a schematic
<re_irc>
<yruama_lairba> i hoped to have a stabilized +5v on nucleo board :p
bpye has joined #rust-embedded
<re_irc>
<James Munns> The CPU probably runs at 3.3v. Very few Cortex-Ms run at 5v, but there is probably a "VBUS" or "VUSB" rail that is 5v.
<re_irc>
<James Munns> (but that will be stepped down to somewhere between 1.8V to 3.3v for the CPU)
<re_irc>
<James Munns> Specifically the "A" in "AVDD" is for analog.
<re_irc>
<James Munns> VDD and VDD are legacy terms that basically just mean the "Positive" voltage rail (this comes from transistors)
<re_irc>
<yruama_lairba> weird, with last version of stm32f4xx-hal, i need to bring many trait in scope to use methods like "split" or "constrain"
<re_irc>
<yruama_lairba> lol, just forgot to use the prelude :p
<re_irc>
<James Munns> therealprof you've been mentioning that I can do sine math with fixed point and a LUT much faster for as long as I've known you, and I finally had a need for it, and just wanted to confirm, you are right :D
<re_irc>
<James Munns> Using Micromath (with the FPU) for "sine(f32) -> f32" took 114 clock cycles, and I wrote a LUT method, and "sine(i16) -> i16" takes 22 CPU cycles :D
<re_irc>
<James Munns> Basically requires a couple of floating point ops when you pick a frequency, e.g. "441.0 hz", but then you can generate as many samples as you want using only i32 math.
<re_irc>
<firefrommoonlight> I'm curious how it compares. Uses a hybrid LUT/interpolation approach
<re_irc>
<James Munns> If you have rust code handy that I can drop in, let me know and I can bench it!
<re_irc>
<rjo> James Munns: There is also "idsp" which gives you both sine and cosine at the same time with more precision than i16 in similar (fewer?) cycles .
<re_irc>
<James Munns> My output is 16 bit PCM audio, so I don't need MUCH more precision than that
<re_irc>
<James Munns> but yeah, I can try that too at some point :)
<re_irc>
<James Munns> Think it could do "sin" in less than 22 cycles?
<re_irc>
<James Munns> (well, 22 cycles average, that includes loops and assignment, call it 20 CPU cycles or so)
<re_irc>
<James Munns> (pulling in both now, will bench quickly...
<re_irc>
<firefrommoonlight> I think this may get into an area of balancing accuracy vs performance
<re_irc>
<James Munns> My calculated worst case error (for an i16) was 0.012%.
<re_irc>
<James Munns> (4/32768)
<re_irc>
<rjo> 37 insns for "cossin". 9e-6 max and 4e-6 RMS error.
<re_irc>
<firefrommoonlight> Nice
<re_irc>
<rjo> I actually haven't measured cycles. Depends a lot on the processor. CM7 might be significantly below 20 cycles.
<re_irc>
<firefrommoonlight> I look fwd to seeing how IDSP progresses
<re_irc>
<firefrommoonlight> RN I don't use it because its feature set is limited. I don't think it has FIR, for example
<re_irc>
<firefrommoonlight> It would be nice to have something native rust
<re_irc>
<rjo> James Munns: The problem with a 16 bit phase input is that you get significant phase truncation spurs on a 16 bit output. That's why you usually would want ~19 or 20 bit phase for a 16 bit output.
<re_irc>
<firefrommoonlight> *Looks like IDSP ha ATAN2, which CMSIS doesn't. micromath/libm/num_traits (the latter wraps one of the former?) have it, but I asssume those are slower
<re_irc>
<James Munns> thread 'main' panicked at 'Unable to find libclang: "couldn't find any valid shared libraries matching: ['libclang.so', 'libclang-*.so', 'libclang.so.*', 'libclang-*.so.*'], set the `LIBCLANG_PATH` environment variable to a path where one of these files can be found (invalid: [])"', /home/james/.cargo/registry/src/github.com-1ecc6299db9ec823/bindgen-0.58.1/src/lib.rs:2057:31
<re_irc>
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
<re_irc>
// Generate 100 samples of a 441hz sine wave.
<re_irc>
<James Munns> rjo: Ah, gotcha! I admit my DSP chops are not very good
<re_irc>
<firefrommoonlight> What are you using to time them? I want to learn how to do this!
<re_irc>
<James Munns> I'm just using a 1us resolution timer, generating 100 samples, counting the 1uS ticks, x64 (to get 64MHz clock), then /100 to average
<re_irc>
<James Munns> this is currently my "benchmark playground"
<re_irc>
<firefrommoonlight> Awesome!
<re_irc>
<James Munns> I probably could use CYCCNT instead, but I already had the 1us timer handy :p
<re_irc>
<James Munns> so assume like +/-1% error on all of my reported values
<re_irc>
<rjo> James Munns: Can't see anything obviously wrong. you appear to include the storing, shifting, accumulation in the count.
<re_irc>
<firefrommoonlight> rjo: I noticed you're the top contributor on IDSP. Are there plans to add support for more features like FIR, decimators etc?
<re_irc>
<firefrommoonlight> Would like to switch to it eventually, since CMSIS is a bit heavy to set up, and its API isn't great unless you wrap it (More so for filters etc than sin/cos)
<re_irc>
<rjo> At some point sure! So far we don't need them or have implemented them differently that one would for a generic impl.
<re_irc>
<rjo> Fir is also an area where hand tuning and simd etc. helps a lot.
<re_irc>
<firefrommoonlight> Gotcha
<re_irc>
<James Munns> fwiw, idsp and DSP were both faster than micromath, and probably much more accurate than my approach
<re_irc>
<James Munns> I'm just happy with a little bit of loss of precision for the sake of speed.
<re_irc>
<firefrommoonlight> I guess the right tool depends on use case - and for many cases, you could choose any!
<re_irc>
<adamgreig> I just about finished my FPGA FIR and it just eats up samples, very pleasing. Loads of great tricks you can do with FIR filters that are usually pretty application specific
<re_irc>
<adamgreig> Though a well written polyphase decimator/integrator with abstract data types could probably cover a ton of use cases pretty efficiently...
<re_irc>
<bradleyharden> jamesmunns, I just saw your blog post on Reddit. Are you familiar with the "fixed" crate? If so, is there some reason you didn't use it? I've done something similar using "fixed", and it saves a lot of the work you do manually with bit shifting, etc.
<re_irc>
<James Munns> I did try "fixed" + "cordic", but it was DRASTICALLY slower than any other option, something like 640 cycles an iter or something
<re_irc>
<James Munns> that being said - I've not really used either crate, so I totally could have been "holding it wrong".
<re_irc>
<James Munns> I'm also really not in love with "typenum" if I can avoid it.
<cr1901>
fixed is an excellent crate, but it's format impl is large. I rewrote my own version for ufmt
<cr1901>
(not published b/c I haven't decided whether to contribute it back to fixed crate or make my own crate)
<re_irc>
<James Munns> If you are familiar with it, and could port my approach to using that, I'd be happy to benchmark it though! I also think that the"cordic" crate also probably is a very accurate approximation, so maybe if I used my LUT + interpolation algorithm, it'd be faster.
<re_irc>
<kevlan> That looks fun! I still haven't seen any hardware released with an M55 on it yet though... I want to play with the helium SIMD stuff. I've used the Neon SIMD on A cores for video processing and it was really powerful. It would be cool to move that workload to an M class MCU.
Foxyloxy has quit [Remote host closed the connection]
Foxyloxy has joined #rust-embedded
<re_irc>
<bradleyharden> James Munns, yeah, I definitely wouldn't use CORDIC if the LUT approach is good enough. But I think it might have been easier to express the linear interpolation using "fixed". I'm not sure. I'd have to investigate.
<re_irc>
I've done essentially the exact same thing in VHDL with the IEEE fixed point libraries, and I thought it was a very elegant approach. In fact, I was able to easily generalize the module to accept and interpolate any real-valued, periodic function.
<re_irc>
<James Munns> Gotcha! Most of my fixed point math knowledge comes from a company where we had to do a lot of trig very quickly on a CPU with no hardfloat (arm9), so I had seen most of these tricks implemented in macros and C functions
<re_irc>
<James Munns> (basically doing a lot of polar coordinate object tracking)
<re_irc>
<bradleyharden> Oh, also FYI, there is a "fixed" 2.0 available on nightly that uses const generics. I'm excited for the day I can use it on stable.
Socke has quit [Ping timeout: 276 seconds]
Socke has joined #rust-embedded
Socke has quit [Ping timeout: 246 seconds]
Socke has joined #rust-embedded
<re_irc>
<firefrommoonlight> Cool! I'm in the camp where I'd buy an M55 or 85 MCU, but if they're not yet available...
<re_irc>
<firefrommoonlight> James Munns: I guess the calculus changes without an FPU
<re_irc>
<firefrommoonlight> Ie, much more incentive to use fixed point, and learn its limitations
<re_irc>
<adamgreig> hi room, meeting time again! agenda is https://hackmd.io/6X2RVrg6Q1mj3P_WHgqA9Q, please add anything you would like to announce or discuss and we'll start in 5min :)
<re_irc>
<therealprof> Can you open up the hackmd?
<re_irc>
<almindor> can't make it in full but I'll lurk around
<re_irc>
<James Munns> Lurking a bit, am around :)
<re_irc>
<adamgreig> oops, sorry, it's public
<re_irc>
<James Munns> CTFT did open issues for dirbaio and I, we're waiting on scheduling.
<re_irc>
<James Munns> (so progress, but nothing to report this week)
<re_irc>
<adamgreig> cool :)
<re_irc>
<adamgreig> ok, couple of release announcements: riscv 0.8 is out, with the new inline asm macro, beating cortex-m to a release with it :P
<re_irc>
<adamgreig> and svd2rust 0.23 is also out, thanks to burrbull's tireless work on that and the underlying svd crate
<re_irc>
<adamgreig> anyone have anything else to announce?
<re_irc>
<burrbull> VSCode now have support debug SVD peripherals. Including arrays and cluster
<re_irc>
<adamgreig> on cortex-m, still release "soon" and that documentation fix we discussed last week, plus two new issues
<re_irc>
<adamgreig> first is https://github.com/rust-embedded/cortex-m/pull/433 which I think probably makes sense and isn't as drastic as it looks, but basically we've bumped to bare-metal 1.0, which changed the CriticalSection token to be a copyable ZST type because that's lower overhead than passing actual references around
<re_irc>
<adamgreig> consequently the signature of interrupt::free should change to pass an actual CS into the closure instead of a reference to it
<re_irc>
<adamgreig> the downside is this is a breaking api change to a fairly majorly used API...
<re_irc>
<adamgreig> ...but it's a pretty trivial one-letter fix, and I think the majority of critical section code probably just names it "_" anyway
<re_irc>
<dirbaio> ... api which should be deprecated
<re_irc>
<adamgreig> well yea, that's the thing
<re_irc>
<dirbaio> because multicore, unprivileged mode, rtos's...
<re_irc>
<adamgreig> still wanna drop/deprecate this to use critical-section in cortex-m
<re_irc>
<adamgreig> so I think it probably makes sense to merge this PR since it's still right, but then probably never release it or at least mark it deprecated for the 0.8 release
<re_irc>
<adamgreig> (or maybe it changes to be a wrapper before the release)
<re_irc>
<dirbaio> if we're going to break it, why not remove it outright?
<re_irc>
<dirbaio> or make it not give the CS token
<re_irc>
<dirbaio> so it does what it says on the tin, it "runs the closure with irqs disabled in the current core"
<re_irc>
<dirbaio> but it no longer incorrectly asserts that's enough for a CS
<re_irc>
<GrantM11235> dirbaio: - unless you are in unprivileged mode
<re_irc>
<dirbaio> "runs the closure with irqs disabled in the current core, or noop if in unprivileged mode" 😂
<re_irc>
<adamgreig> well it still runs the closure in unpriv :X
<re_irc>
<dirbaio> then:
<re_irc>
in unprivileged mode: runs the closure
<re_irc>
in privileged mode: runs the closure with irqs disabled in the current core
<re_irc>
<dirbaio> is there a way to query if we're in unprivileged mode?
<re_irc>
<dirbaio> maybe it could check and panic
<re_irc>
<adamgreig> yea, though it adds more cost to each CS which isn't hugely popular, hm
<re_irc>
<dirbaio> if it doesn't return the CS token it's no longer "wrong"
<re_irc>
<adamgreig> yea
<re_irc>
<dirbaio> * "dangerous
<re_irc>
<dirbaio> * "dangerous"
<re_irc>
<dirbaio> it shouldn't be used for CSs in the first place
<re_irc>
<adamgreig> but you then can't access any Mutex either?
<re_irc>
<dirbaio> you'd use "critical_section::with"
<re_irc>
<adamgreig> yea
<re_irc>
<dirbaio> which you're supposed to have configured with an impl that's sound for your target (multicore or not, privileged or not)
<re_irc>
<adamgreig> ok, so for now perhaps best for this PR to just drop the CriticalSection entirely, with an understanding that we'll be integrating c-s into c-m before 0.8?
<re_irc>
<dirbaio> I've been thinking of changing "critical_section" so that it no longer assumes singlecore by default
<re_irc>
<dirbaio> by default it gets no impl
<re_irc>
<dirbaio> and you opt-in via cargo features to the right impl, or to supply a custom one
<re_irc>
<adamgreig> and then cortex-m could enable a default impl, heh
<re_irc>
<dirbaio> no, cortex-m can't know if you're singlecore or not
<re_irc>
<adamgreig> (via its own default feature)
<re_irc>
<adamgreig> it can't know, but it can assume by default, I think
<re_irc>
<adamgreig> make it easy to turn off but it seems like a reasonable default
<re_irc>
<adamgreig> ugh
<re_irc>
<adamgreig> no, that's super annoying
<re_irc>
<adamgreig> because every lib that depends on c-m won't default-features=false
<re_irc>
<dirbaio> default features are dangerous, one lib will depend on "cortex-m" and forget "default-features=false" and ruin everything
<re_irc>
<dirbaio> yep
<re_irc>
<adamgreig> but a bit of a pain to add yet more friction to setting up a new project, hmm
<re_irc>
<dirbaio> imo it has to be the user explicitly settin git
<re_irc>
<dirbaio> * setting it
<re_irc>
<adamgreig> perhaps HALs can enable it by default for many users
<re_irc>
<dirbaio> and setting it is "unsafe", as in if you get it wrong you'll have unsoundness
<re_irc>
<adamgreig> the HALs aren't likely to be depended on as a library, and they have a better chance of getting the guess right
<re_irc>
<adamgreig> in the same way I guess your HALs for nrfs might enable a suitable c-s for the softdevice?
<re_irc>
<adamgreig> there were a bunch but the one about interrupt::free and about fixing the inlnie asm got moved out
<re_irc>
<therealprof> Looks good to me but linker magic is soo fragile...
<re_irc>
<adamgreig> hmm yea also changes to the macros, huh
<re_irc>
<dirbaio> prio grouping could be added in a minor release, and the other breaking changes could be for 0.8
<re_irc>
<adamgreig> I think mostly that's some commits that need backing out of this PR? it's got the asm changes and stuff still
<re_irc>
<adamgreig> #434 doesn't look too bad to me
<re_irc>
<adamgreig> though yes every PR that touches the linker script adds at least as many bugs as it removes
<re_irc>
<adamgreig> at least it's down in .sgstubs beyond where most people will venture though
<re_irc>
<adamgreig> so the new bug can grow in peace, heh
<re_irc>
<adamgreig> I wonder if the doubled up ". = ALIGN(32)" is needed
<re_irc>
<adamgreig> would have thought it mostly makes a difference for anyone doing "INSERT AFTER .sgstubs" but I didn't know that was a widely done thing
<re_irc>
<adamgreig> idk, if anyone has any guesses why the change is needed to stop __veneer_limit being equal to __veneer_base even when there's stuff in (.gnu.sgstubs) between, please shout
<re_irc>
<adamgreig> it's currently following the same general pattern for the other sections which seems to work fine
<re_irc>
<therealprof> It could also be linker dependent which is super annoying.
<re_irc>
<adamgreig> ugh, yea. in principle we could test for that in CI, we already run over all supported linkers
<re_irc>
<adamgreig> but we don't have any tests that look like that at the moment
<re_irc>
<adamgreig> well, I guess it warrants a little more investigation to try and work out what's causing it exactly
<re_irc>
<dirbaio> turns out async closures are a giant dumpster fire in today's Rust
<re_irc>
<dirbaio> so the trait needs workarounds
<re_irc>
<dirbaio> the original workaround didn't work
<re_irc>
<dirbaio> I found this new one
<re_irc>
<dirbaio> I'm not sure which one is "less bad"
<re_irc>
<dirbaio> so if anyone has ideas on other workarounds, I'm all ears
<re_irc>
<adamgreig> too cursed, too close to the void :P
<re_irc>
<dirbaio> yeah
<re_irc>
<dirbaio> ideally this would get fixed in Rust, but apparently it's Very Complicated
<re_irc>
<dirbaio> :(
<re_irc>
<dirbaio> non-embedded people just do "Box<dyn Future>", it's only us who feel the pain :'(
<re_irc>
<dirbaio> I don't think it's acceptable to make the the EHA traits require alloc..
<re_irc>
<adamgreig> given how all the rest of async works without it would seem a huge shame
<re_irc>
<GrantM11235> I think this hack is closer to the "ideal" solution than the previous hack
<re_irc>
<adamgreig> and at least SpiDeviceExt methods avoid the raw pointer?
<re_irc>
<GrantM11235> Once rust supports the "ideal" version, everyone just needs to delete the "let bus = unsafe { &mut *bus };" line
<re_irc>
<GrantM11235> And everything should work the same
<re_irc>
<adamgreig> ok, I think that's all for today, thanks everyone!
<re_irc>
<adamgreig> if you do have any good ideas about the weird linker script bug or better hacks for the spi thing please check the relevant PRs
<re_irc>
<James Munns> btw, has anyone here tried using tracing v0.2 on embedded? It looks like they removed the "liballoc" requirement that existed in v0.1
<re_irc>
<James Munns> (I plan to look into this for _reasons_ in the next days, but if anyone has a head start, I'd be happy to share notes)