<re_irc>
<@jorgeig:matrix.org> for adding/splitting/removing registers/fields
<re_irc>
<@w00tspeaks:matrix.org> I sent you a copy of the svd via DM if you want to see it.
<re_irc>
<@rahix:matrix.org> Wren T: you can find some examples of that in the `avr-device` crate
<re_irc>
<@jorgeig:matrix.org> I've never used the `enumeratedValues` tags cause my STM MCUs don't have them, but the syntax in svd2rust would be the same as for registers/fields
<re_irc>
<@jorgeig:matrix.org> e.g. this modifies the name of the CHMOD10 field in the CR register of the AES peripheral:
<re_irc>
<@w00tspeaks:matrix.org> I am not sure how to escape the brackets
<re_irc>
<@w00tspeaks:matrix.org> I tried \\
<re_irc>
<@jorgeig:matrix.org> you can just ignore the brackets and place a *
<re_irc>
<@w00tspeaks:matrix.org> i tried \\\\
<re_irc>
<@w00tspeaks:matrix.org> okay, let me try that
hosewiejacke has quit [Quit: Leaving]
<re_irc>
<@w00tspeaks:matrix.org> That seems to have worked.
<re_irc>
<@w00tspeaks:matrix.org> Now I actually need to modify the enum values for a field in that register
<re_irc>
<@jorgeig:matrix.org> then you probably shouldn't delete the register 😅
<re_irc>
<@jorgeig:matrix.org> use _modify
<re_irc>
<@w00tspeaks:matrix.org> I'm not
<re_irc>
<@w00tspeaks:matrix.org> I was just trying to do something simpler
<re_irc>
<@w00tspeaks:matrix.org> Is there some way to remove an enum value?
<re_irc>
<@w00tspeaks:matrix.org> There are a bunch of duplicated enum names that I need to get rid of.
<re_irc>
<@w00tspeaks:matrix.org> I see _replace_enum for replacing all of them
<re_irc>
<@w00tspeaks:matrix.org> but I just need to delete some of them
dcz has joined #rust-embedded
<re_irc>
<@w00tspeaks:matrix.org> I don't think it's possible with the svd without changes to it's code.
<re_irc>
<@adamgreig:matrix.org> You can remove all the existing enum values but no way to just remove one or two of them, I'd suggest removing them all and re-adding the correct ones
dcz_ has joined #rust-embedded
dcz has quit [Ping timeout: 265 seconds]
<re_irc>
<@burrbull:matrix.org> I think _clear is easier then _replace_enum
<re_irc>
<@9names:matrix.org> 9names: wasn't just me, looks like the latest version of the 'syn' crate has broken it :(
<re_irc>
<@9names:matrix.org> it doesn't even directly depend on syn, looks like it's serde that uses it?
<re_irc>
<@9names:matrix.org> how do you even cope with this sort of semver failure mode?
<re_irc>
<@9names:matrix.org> cargo tree says syn is a direct dependency of usbd-hid-macros, but it's not listed in the dependencies section of any of the Cargo.toml files
<re_irc>
<@richarddodd:matrix.org> adamgreig: I hope your holiday was relaxing :)
<re_irc>
<@adamgreig:matrix.org> Thanks ❤️
<re_irc>
<@firefrommoonlight:matrix.org> w00tspeaks:matrix.org: The nRF pac does this for a number of things, and the STM32 H7 PAC does it for DMA streams (channels)
<re_irc>
<@firefrommoonlight:matrix.org> (I may be misusing terminology; assuming enumerated values is the same as when you can index things in the resulting API) When used appropriately, this makes PAC API much nicer
<re_irc>
<@firefrommoonlight:matrix.org> Without it, you end up with match patterns that can be quite long, and you need to include the whole bit of code in the arm since the arms can't return different types. This can lead to loads of DRY, or macros in an attempt to avoid it
<re_irc>
<@firefrommoonlight:matrix.org> Ie I've written GPIO and DMA code with and without the indexing/enumeration, and with is far more compact and maintainable (ie ~1/10 the code in both cases)
<re_irc>
<@adamgreig:matrix.org> enumerated values is the range of allowed values for a field
<re_irc>
<@adamgreig:matrix.org> what you're thinking of is arrays and/or clusters
<re_irc>
<@firefrommoonlight:matrix.org> Oh oops sorry for the faker!
fabic has quit [Ping timeout: 265 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> jordens: Is the intent behind the IDSP lib to only support integers?
fabic has joined #rust-embedded
<re_irc>
<@firefrommoonlight:matrix.org> I'm experimenting with DSP, and am trying to do parallel implementations of CMSIS-DSP and IDSP. Ie I'm trying to do an equiv of this:
<re_irc>
<@firefrommoonlight:matrix.org> // Let's say the whole period = 1s.
<re_irc>
<@firefrommoonlight:matrix.org> Would I just multiply the float by a high value and cast as an int? I'm assuming that internally things always end up as integers when processing to/from DAC/ADC, so Floats are perhaps not good except for in intermediate calcs?
<re_irc>
<@firefrommoonlight:matrix.org> Where `arm_sin_f32` is from jacobrosenthal 's CMSIS lib
<re_irc>
<@firefrommoonlight:matrix.org> Also, is the intent to add FIR support? I don't know WTF I'm doing, but most examples and comparisons seem to prefer that as a default to IIR. I'm happy to add it once I figure out what I'm doing
<re_irc>
<@firefrommoonlight:matrix.org> Right now trying to get lowpass filters set up using both CMSIS and IDSP
<re_irc>
<@firefrommoonlight:matrix.org> I'm assuming integer math is used mainly at the input and output end, but rounding errors would be problematic in intermediate calcs?
fabic has quit [Ping timeout: 268 seconds]
<re_irc>
<@adamgreig:matrix.org> rounding errors can be problematic in f32 too, keeping it all-integer is often better (and much easier to analyse)
<re_irc>
<@adamgreig:matrix.org> floating point makes more sense when you need a high dynamic range or don't want to fuss with the analysis/scaling factors
<re_irc>
<@adamgreig:matrix.org> for a lot of signal processing applications though that's less common
<re_irc>
<@adamgreig:matrix.org> really depends on what you're doing of course!
<re_irc>
<@firefrommoonlight:matrix.org> Oh! Maybe I should dive right in to ints and skip the f32s
<re_irc>
<@firefrommoonlight:matrix.org> I'm learning, with a vague goal of making realtime headphones that process incoming sound with a number of presets. You can consider them SciFI Future Bat headphones, or hearing-aids-for-people-who-hear-good
<re_irc>
<@newam:matrix.org> `num-rational` isn't _small_ depending on what you need, but it does work on embedded.
<re_irc>
<@newam:matrix.org> same for `num-complex` if you need it.
<re_irc>
<@firefrommoonlight:matrix.org> (So audio in/out in range of 20Hz to maybe 60kHz)
<re_irc>
<@firefrommoonlight:matrix.org> Oh - alternative number types?
<re_irc>
<@adamgreig:matrix.org> i'm not an audio dsp expert but i would have expected you'd be best off with fixed-point (i.e. integer) maths only
<re_irc>
<@firefrommoonlight:matrix.org> Thanks for sending me on the right path
<re_irc>
<@newam:matrix.org> yeah, just helpers for `u32 / u32`, `u16 / u16`, ect. Helps when you need rational numbers without floats
<re_irc>
<@firefrommoonlight:matrix.org> My math intuition is all float-based, but I obv need to change that for coding/DSP
<re_irc>
<@jorgeig:matrix.org> in audio fixed point definitely works fine
<re_irc>
<@newam:matrix.org> Yeah for audio you can skip a lot of the fussy bits
<re_irc>
<@jorgeig:matrix.org> you might wanna cut your freqs range? 60 KHz is way above our max range
<re_irc>
<@firefrommoonlight:matrix.org> I was wondering about those Q15/Q31 functions in CMSIS; advanced non-float magic I should probably leran
<re_irc>
<@firefrommoonlight:matrix.org> Well.... maybe I can make it so you hear sound above what your ears hear!
<re_irc>
<@jorgeig:matrix.org> take my money!
<re_irc>
<@jorgeig:matrix.org> maybe not, I'm sure the audio spectrum is as polluted as the RF one haha
<re_irc>
<@firefrommoonlight:matrix.org> Hah. I think this proj has a tiny tiny chance of success, but failure will result in learning some DSP
<re_irc>
<@firefrommoonlight:matrix.org> Also, these 2 libs are both badass, and this would be a non-starter without them
<re_irc>
<@adamgreig:matrix.org> Q15 and Q31 aren't as magic as they first appear: it's just saying "take a i16 or i32, and imagine the full range represents the numbers -1 to +1"
<re_irc>
<@adamgreig:matrix.org> so for Q15, you use a rust i16 type, but -32768 represents -1 and +32768 would be +1 (but you can only store 32767, which is 0.999969482421875)
<re_irc>
<@adamgreig:matrix.org> from rust 1.56 we can put `-Tlink.x` in the `build.rs` instead of `.cargo/config.toml` 😍
Amadiro has quit [Remote host closed the connection]
<re_irc>
<@firefrommoonlight:matrix.org> Thank you for the clear explanation
<re_irc>
<@firefrommoonlight:matrix.org> That really helps
<re_irc>
<@firefrommoonlight:matrix.org> I'd copy and paste that as a comment in my code, but it's clear enough I think I've grokked it
<re_irc>
<@adamgreig:matrix.org> for audio it rarely even matters since you just want to ensure you maintain "full scale"
<re_irc>
<@adamgreig:matrix.org> I think the main use for Q format numbers is the ones that don't just map to -1..1, but instead cover some specific range, like Q3.12 where you represent -8 to +8 with slightly less precision in the fraction part
<re_irc>
<@firefrommoonlight:matrix.org> Thank you. That info makes reading through the CMSIS docs much less... foreign
<re_irc>
<@firefrommoonlight:matrix.org> I think I'd like to start adding features to IDSP as a I need them, perhaps as translations from CMSIS. IDSP seems like the way to go long-term, but is sparse on features and docs ATM
<re_irc>
<@firefrommoonlight:matrix.org> Might need to use the wrapped CMSIS while learning
<re_irc>
<@firefrommoonlight:matrix.org> *actually, the IDSP inline code docs are outstanding; I wasn't looking in the right place
<re_irc>
<@adamgreig:matrix.org> it's probably worth finding a DSP textbook or introductory material to help understand where you might want one or the other, there are also a ton of tricks to implementing FIRs efficiently (especially mutli-rate e.g. up or downsampling), though a fairly simple direct form is pretty straightforward in software at least
<re_irc>
<@adamgreig:matrix.org> I agree with starting out with an FIR for simple low-pass filtering sort of things, easier to analyse without as much theory
<re_irc>
<@firefrommoonlight:matrix.org> I've been going through http://www.dspguide.com, I believe recommended to me here!
<re_irc>
<@lachlansneff:matrix.org> Ooo, that looks like a great book
<re_irc>
<@lachlansneff:matrix.org> I'll add that to my reading list
<re_irc>
<@lachlansneff:matrix.org> If I'm making a new library crate, does it make sense to go for embedded-hal 1.0, or only 0.2.6?
<re_irc>
<@almindor:matrix.org> 1.0.0 might still remove some things before final release (such as DelayXY), so I'd stick to what's released for now
<re_irc>
<@almindor:matrix.org> it should be easy to upgrade once its out
<re_irc>
<@jordens:matrix.org> firefrommoonlight:matrix.org: No. There is for example already a `f32` IIR filter in there. The README lists a couple reasons why one may want int. There is no fixed intent for `idsp`. Currently it's just an implementation of what we need.
<re_irc>
<@therealprof:matrix.org> adamgreig: Yes. But the maths is also special since you can't just add the integers. Rust with all the saturating and wrapping arithmetics has the required primitives the make the implementation rather straight forward and if the MCU/CPU supports those instructions natively (like ARM DSP instructions) generated code is also great without having to reach for assembly. Very intriguing to implement a generic..
<re_irc>
... Q15 and Q31 crate for also for vectors. `fixed` seems to miss a few tricks there.
<re_irc>
<@adamgreig:matrix.org> Can't you just add the integers? iirc addition and subtraction are just as per normal?
<re_irc>
<@adamgreig:matrix.org> like, you might well want saturating addition in some situation and so use those functions but even then it's just normal addition
<re_irc>
<@therealprof:matrix.org> Yeah, overflow/underflow is becoming a problem.
<re_irc>
<@adamgreig:matrix.org> But that's nothing to do with using q format numbers, they're just ordinary two's complement, and sometimes you need to care about saturating or srappini
<re_irc>
<@adamgreig:matrix.org> Multiplication and division requires more care for the scale factors but addition and subtraction are the normal two's complement operation on the underlying integer
<re_irc>
<@almindor:matrix.org> is there any way to prevent rust and/or the linker from optimizing away a function or its parts?
<re_irc>
<@almindor:matrix.org> i'm trying to make a "loadable module" and it always removes most things for me :D (there are no peripherals or anything just math in it)
<re_irc>
<@newam:matrix.org> almindor: I have done this in the past, it isn't great... `if unsafe { core::ptr::read_volatile(KNOWN_CONST_ZERO_MEM) } == 0x1234_5678 { call_fun() };`
<re_irc>
<@newam:matrix.org> I would also like to know if there's a better answer :P
<re_irc>
<@almindor:matrix.org> mainly I need something with .data and .bss > 0 in the elf so I can extract and test
<re_irc>
<@therealprof:matrix.org> adamgreig: You might be right but I forgot a lot of the details since reading up on it some months ago. I thought there's were some additional checks, certainly the C implementations look a bit more gnarly than a Rust implementation would.
<re_irc>
<@newam:matrix.org> You could make a linker section then do `#[link_section]`, but that's a bit of effort to setup.
<re_irc>
<@almindor:matrix.org> I was able to get the entrypoint/main working but it always removes the calculations removing any .data and .bss parts coz I guess it's all so very deterministic since there's no input
<re_irc>
<@almindor:matrix.org> it's funny looking at the optimized code tho heh, it comes up looking so different from expectation :D
<re_irc>
<@dkhayes117:matrix.org> I had problems with a function that got optimized away which held nothingbut inline assembly. I was able to keep it by using `#[inline never]`. It worked, but may have been a fluke.
<re_irc>
<@almindor:matrix.org> my main issue is trying to come up with something that results with > 0 .data section (and .bss). For some reason no matter what I do the main() (if not removed completely) optimizes away all of the cruft so well I end up with some basic math 5 lines of asm :D
<re_irc>
<@lachlansneff:matrix.org> almindor: Ah, I need to be able to delay, so I guess 0.2.6 is it
<re_irc>
<@almindor:matrix.org> dang, even static mut stuff gets optimized into direct register (at least as u32), I'm going to try loading something like that from random memory and do some if > 0 panic stuff
<re_irc>
<@almindor:matrix.org> it's funny but only making X = [0; MAX] makes this fail to keep .data as the compiler is smart enough to memory -> memory copy