<re_irc>
<@kevlan:matrix.org> I've played around with the dev kit for the l5cx variant. They are pretty good indoors but not good at all outdoors. It would definitely be possible to make some cool gesture interfaces with it though.
<re_irc>
<@jamesmunns:beeper.com> Interesting. Someone on twitter was saying the L5 was better against ambient IR (e.g. outdoors), but that could have been a relative thing.
<re_irc>
<@kevlan:matrix.org> It's probably a lot better than the old ones. It functioned outdoors for close in stuff alright. We were seeing if it could detect asphalt from half meter to a meter away and it was not super consistent at that outdoors. Indoors it was awesome though.
troth has quit [Ping timeout: 268 seconds]
<re_irc>
<@jamesmunns:beeper.com> I don't have any use case yet, but that's good to know!
troth has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 276 seconds]
crabbedhaloablut has joined #rust-embedded
PyroPeter has quit [Ping timeout: 246 seconds]
PyroPeter has joined #rust-embedded
loki_val has joined #rust-embedded
crabbedhaloablut has quit [Ping timeout: 276 seconds]
troth has quit [Ping timeout: 264 seconds]
loki_val has quit [Ping timeout: 276 seconds]
SanchayanMaity has quit [Ping timeout: 264 seconds]
troth has joined #rust-embedded
SanchayanMaity has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
crabbedhaloablut has quit [Remote host closed the connection]
crabbedhaloablut has joined #rust-embedded
troth has quit [Ping timeout: 245 seconds]
troth has joined #rust-embedded
fabic_ has joined #rust-embedded
fabic_ has quit [Ping timeout: 256 seconds]
starblue has quit [Ping timeout: 260 seconds]
<re_irc>
<@barafael:matrix.org> In case somebody has an as5600 magnetic i2c potentiometer, I'm currently working on a driver for it. If somebody is interested in collaborating, review, ideas or anything: https://github.com/barafael/as5600-rs
<re_irc>
<@barafael:matrix.org> I don't have the hardware yet though :D hoping for another case of "after the usual hardware setup stuff, worked first try". Using embedded-hal-mock
hifi has quit [Remote host closed the connection]
hifi has joined #rust-embedded
<re_irc>
<@gauteh:matrix.org> Hi, with the app-template for defmt-test it seems to me like a lot of structs and modules in the main project need to be made public to be able to write unit-tests for them in the subproject (testsuite)... is that how it's supposed to work or am I missing something?
<Lumpio->
Maybe they're not meant to be tested
troth has quit [Ping timeout: 245 seconds]
starblue has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> gauteh in general, tests in the `tests/` folder only have access to the public API of a crate. This is true for both defmt-test and the regular test machinery.
<re_irc>
<@ryan-summers:matrix.org> If your tests need access to internal private members, they need to be within file-scope (e.g. `#[cfg(test)] mod test{}`). This is a pretty nice differentiation between white/black box testing imo
troth has joined #rust-embedded
troth has quit [Quit: Leaving.]
starblue has quit [Ping timeout: 268 seconds]
troth has joined #rust-embedded
nohit has quit [Ping timeout: 264 seconds]
nohit has joined #rust-embedded
SanchayanMaity has quit [Ping timeout: 250 seconds]
SanchayanMaity has joined #rust-embedded
starblue has joined #rust-embedded
<re_irc>
<@gauteh:matrix.org> ryan-summers:matrix.org: Yeah, that's what I was wondering: is this possible to do with defmt-test?
troth has quit [Ping timeout: 245 seconds]
crabbedhaloablut has quit [Remote host closed the connection]
<re_irc>
<@adamgreig:matrix.org> hi room , meeting time again! agenda is up at https://hackmd.io/weSjTUppRkeXmf-8R_DXLg, please add anything you'd like to discuss and we'll start in 5min
<re_irc>
<@adamgreig:matrix.org> ok, let's start!
<re_irc>
<@adamgreig:matrix.org> first up a couple of announcements, thejpster has offered to join the tools team, so if tools team members could check out https://github.com/rust-embedded/wg/pull/586
<re_irc>
<@therealprof:matrix.org> Newsletter is out. ð
<re_irc>
<@adamgreig:matrix.org> to clarify, the only votes that are required is from tools team members, thejpster do you want to say anything about joining tools team?
<re_irc>
<@therealprof:matrix.org> adamgreig: If you'd approve we'd have majority. ð
<re_irc>
<@adamgreig:matrix.org> i walked in the door 6 minutes ago and just had time to hastily put this together :P
<re_irc>
<@adamgreig:matrix.org> but I think we should briefly chat about having double github accounts later in the meeting
<re_irc>
<@thejpster:matrix.org> I hope to be spending more time on Rust very soon now, so hopefully I can be of use to the tools team.
<re_irc>
<@adamgreig:matrix.org> the rust org doesn't because they have voting automation that it would presumably mess up, though we don't have anything like that yet
<re_irc>
<@thejpster:matrix.org> Also I'd like to wear two hats as I have two accounts - one for personal work and one for work work. It's a PITA having to switch laptops just to approve something I need to work.
<re_irc>
<@adamgreig:matrix.org> but also I think everyone currently in the wg is there representing themselves personally
<re_irc>
<@therealprof:matrix.org> I don't see a problem having two accounts in the wg frontpage and added to the team.
<re_irc>
<@thejpster:matrix.org> You can draw your own conclusions about where I might be going where Rust is my main line of work.
<re_irc>
<@adamgreig:matrix.org> would your work account by representing your work?
<re_irc>
<@thejpster:matrix.org> I think technically if I use jonathanpallant then what I do is copyright my employer as I am on the clock, and using the work PC.
<re_irc>
<@adamgreig:matrix.org> sure, but it's still a new precedent and implies the wg membership might be part of your job rather than something you're doing personally
<re_irc>
<@thejpster:matrix.org> I'm sure there are other members who do WG stuff in work time
<re_irc>
<@thejpster:matrix.org> But maybe less explicitly.
<re_irc>
<@adamgreig:matrix.org> in work time and representing work isn't quite the same thing
<re_irc>
<@therealprof:matrix.org> I'd keep it at one for the Rust rooster though.
<re_irc>
<@adamgreig:matrix.org> yea, I guess if we do use the voting automation it will use the rust/teams info and so should still work, though we'd need to pick one account for it?
<re_irc>
<@thejpster:matrix.org> I'm not sure using my work account constiutes making a statement on behalf of my employer - it's just about making the copyright clear.
<re_irc>
<@therealprof:matrix.org> We don't do voting automation currently.
<re_irc>
<@adamgreig:matrix.org> indeed
<re_irc>
<@therealprof:matrix.org> It's weird but not outlandish so I don't have a problem with it. ð
<re_irc>
<@adamgreig:matrix.org> I'm still a little uncomfortable having two accounts on the list for one person, but not enough to not go ahead with it, and probably mainly just because i've not seen it elsewhere
<re_irc>
<@eldruin:matrix.org> the only thing that would look weird to me is having a person twice on the rust-lang wg page
<re_irc>
<@yatekii:matrix.org> also rules
<re_irc>
<@eldruin:matrix.org> but maybe we can change how that is done so that we can have two GH handles but still only one picture
<re_irc>
<@therealprof:matrix.org> eldruin:matrix.org: Yeah, not going to do that. ð
<re_irc>
<@adamgreig:matrix.org> I guess there's a related question about any conflicts of interest with your new employer but I suppose once that's public we can make sure it's OK
<re_irc>
<@adamgreig:matrix.org> we've had two people who worked at the same company on the core team too so I think it's fine, heh
<re_irc>
<@yatekii:matrix.org> ja?
<re_irc>
<@adamgreig:matrix.org> ok, I'll vote to approve joining the tools team, I can't really foresee any problems with having two accounts listed on the readme or in the github org
<re_irc>
<@thejpster:matrix.org> oh look I was doing knurling bug fixes today, on a unrelated note
<re_irc>
<@adamgreig:matrix.org> which do you want on the rust team roster?
<re_irc>
<@thejpster:matrix.org> Let's use jonathanpallant on the roster. I hope to use that more.
<re_irc>
<@therealprof:matrix.org> Eh?
<re_irc>
<@adamgreig:matrix.org> I thought jonas was doing knurling bug fixes :P
<re_irc>
<@yatekii:matrix.org> sorry, I accidentially spammed weird stuff inbetween your discussion :/ wasn't intended for this channel ...
<re_irc>
<@therealprof:matrix.org> Currently it's **thejpster**. I'd rather not change that.
<re_irc>
<@adamgreig:matrix.org> anyway, that's enough for that announcement, the second was to mention that cargo-binutils 0.3.4 is published with a bugfix for latest llvm, so grab your upgrades
<re_irc>
<@thejpster:matrix.org> ok, that's fine. This is mainly just about me not having to switch github logins to approve PRs.
<re_irc>
<@matoushybl:matrix.org> I believe the people know you more as thejpster too
<re_irc>
<@adamgreig:matrix.org> on the `cross` front, I'm hoping to have the RFC ready soon, and emilgardis has been working on swapping from dockerhub and azure to GHCR and GHA ð
<re_irc>
<@adamgreig:matrix.org> so expect more on that soon I guess
<re_irc>
<@thejpster:matrix.org> ð is emil here?
<re_irc>
<@adamgreig:matrix.org> it's a pretty big merge and change, so I'd love any more eyes on it, I've put a hosted version here: https://agg.io/u/discovery
<re_irc>
<@adamgreig:matrix.org> notably there's a new landing page which so far I've just thrown together but could probably be spruced up
<re_irc>
<@emilgardis:matrix.org> Can I touch on the cross pr, I would appreciate some help with the linking issue
<re_irc>
<@adamgreig:matrix.org> but it would also be good if people could run through the new micro:bit content, especially if you have one to follow along with, and check it all looks good
<re_irc>
<@adamgreig:matrix.org> that's it for discovery, go ahead emilgardis
<re_irc>
<@emilgardis:matrix.org> So cross is a mess, and we _need_ to support centos 7 right now
<re_irc>
<@emilgardis:matrix.org> this is due to compat with old glibc
<re_irc>
<@emilgardis:matrix.org> I'm having issues linking qemu for unknown-linux-gnu targets
<re_irc>
<@emilgardis:matrix.org> do we need qemu in x86_64-unknown-linux-gnu?
<re_irc>
<@emilgardis:matrix.org> there is also an issue with qemu 5.1 hanging on some targets, I can reproduce it on my own machine with many threads, so that needs to be addressed as well
<re_irc>
<@emilgardis:matrix.org> anyway, that's it, progress is on the way :)
<re_irc>
<@adamgreig:matrix.org> emilgardis:matrix.org: because in principle that one can be run natively?
<re_irc>
<@emilgardis:matrix.org> I think so, not 100% on that though
<re_irc>
<@adamgreig:matrix.org> you'd think that wouldn't be the hard target to get qemu for though, heh
<re_irc>
<@therealprof:matrix.org> I think we had individual entries linked in previous TWiR issues, or are you thinking a wholesale link?
<re_irc>
<@adamgreig:matrix.org> just a link to this latest issue I think
<re_irc>
<@adamgreig:matrix.org> for cortex-m-rt, since we have a few cortex-m people here, I wanted to get people's thoughts on updating the linker script to set SP and (on v7) VTOR at startup...
<re_irc>
<@therealprof:matrix.org> Yeah, PRing on the repo is easiest.
<re_irc>
<@adamgreig:matrix.org> it keeps coming up because companies keep writing shoddy bootloaders and debug software that don't set the chip up properly or reset it properly
<re_irc>
<@thejpster:matrix.org> Oh. sad face.
<re_irc>
<@adamgreig:matrix.org> arm guarantees the chips will all set SP correctly
<re_irc>
<@thejpster:matrix.org> That's the nice thing about cortex-m that you just stick a structure at address 0 and it Just Works.
<re_irc>
<@adamgreig:matrix.org> and I really really hate to add redundant instructions to everyone's boot time and flash usage just because some things are broken
<re_irc>
<@dirbaio:matrix.org> i'd make it optional yep
<re_irc>
<@adamgreig:matrix.org> right now we can't add it with a cargo feature because it's part of the pre-built binaries
<re_irc>
<@thejpster:matrix.org> oh no
<re_irc>
<@adamgreig:matrix.org> well, short of shipping binaries for every platform * all features
<re_irc>
<@therealprof:matrix.org> dirbaio:matrix.org: If it is optional, it's pretty much useless.
<re_irc>
<@adamgreig:matrix.org> and, the feature is annoying because the bugs it causes are very hard to track down, e.g. "interrupts don't work, why???"
<re_irc>
<@adamgreig:matrix.org> I'd strongly consider making it optional and enabled by default, because at least you can opt out if you know you don't need it
<re_irc>
<@dirbaio:matrix.org> what would it do in cortex-m0 (no VTOR)?
<re_irc>
<@adamgreig:matrix.org> but until global_asm is stable I don't think it's easy to make it optional
<re_irc>
<@adamgreig:matrix.org> it would not emit VTOR for thumbv6
<re_irc>
<@adamgreig:matrix.org> we already have separate prebuilt binaries for each target, so that's easy
<re_irc>
<@dirbaio:matrix.org> m0+ is thumbv6 and does have VTOR
<re_irc>
<@adamgreig:matrix.org> ah
<re_irc>
<@adamgreig:matrix.org> yes
<re_irc>
<@adamgreig:matrix.org> VTOR is optional on m0+ I think?
<re_irc>
<@adamgreig:matrix.org> it's optional on c-m3 and c-m4 too
<re_irc>
<@dirbaio:matrix.org> not sure lol
<re_irc>
<@dirbaio:matrix.org> but either way, it means can't tell from the target alone
<re_irc>
<@adamgreig:matrix.org> hmm, no, on v7 vtor is "always implemented" actually
<re_irc>
<@adamgreig:matrix.org> but on v6 it's implementation defined
<re_irc>
<@adamgreig:matrix.org> so, you see why _bootloaders should set it_, which already know about their chip, not us
<re_irc>
<@adamgreig:matrix.org> but unfortunately they don't
<re_irc>
<@thejpster:matrix.org> Loading SP is just one instruction, right?
<re_irc>
<@adamgreig:matrix.org> yea, loading SP is just one instruction, no worse than the stack of LR we just added
<re_irc>
<@adamgreig:matrix.org> _but_ SP being broken is super rare - so far it's just some stlinks+some software that does a "reset" by just jumping to reset? it seems?
<re_irc>
<@adamgreig:matrix.org> the ARM promises that SP is initialised after all types of system reset
<re_irc>
<@thejpster:matrix.org> and VTOR is the "vector table offset register", which allows the interrupt vector table to be somewhere other than the bottom of flash.
<re_irc>
<@adamgreig:matrix.org> technically, it's not "the bottom of flash", it's 0x0000_0000 always
<re_irc>
<@adamgreig:matrix.org> VTOR offsets it from 0x0000_0000
<re_irc>
<@thejpster:matrix.org> But STM32s boot from 0x0080_0000 ... ?
<re_irc>
<@adamgreig:matrix.org> you'd think so but nope
<re_irc>
<@thejpster:matrix.org> Or does their ROM bootloader set VTOR for you?
<re_irc>
<@adamgreig:matrix.org> also no
<re_irc>
<@thejpster:matrix.org> :facepalm:
<re_irc>
<@adamgreig:matrix.org> the internal flash is present at 0x0800_0000, and also remapped at 0x0000_0000
<re_irc>
<@adamgreig:matrix.org> you can choose what's mapped to address 0 using the BOOT1/BOOT0 pins
<re_irc>
<@adamgreig:matrix.org> normally, flash, but if you change BOOT0 it maps the system bootloader memory there, and you can also map the SRAM there if you want to boot from sram
<re_irc>
<@adamgreig:matrix.org> but in general on an stm32 you can read your flash by reading from 0x0 just like reading from 0x0800_0000
<re_irc>
<@thejpster:matrix.org> So if this function is core specific, is cortex-m/cortex-m-rt fundamentally broken in thinking only about microarchitectures instead of cores?
<re_irc>
<@adamgreig:matrix.org> typically the cpu just reads the vector table from there and jumps to the reset vector at 0x0800_XXXX anyway though
<re_irc>
<@adamgreig:matrix.org> well, it's implementation specific
<re_irc>
<@adamgreig:matrix.org> can you make a cm0 with a vtor?
<re_irc>
<@adamgreig:matrix.org> ah, you _can_ make a CM0+ _without_ a VTOR
<re_irc>
<@adamgreig:matrix.org> it's optional for the CM0+ configuration
<re_irc>
<@thejpster:matrix.org> Oh, as in you buy the VHDL from Arm and it has some config flags you can fiddle before you send the design to the ASIC house?
<re_irc>
<@adamgreig:matrix.org> yea, exactly so
<re_irc>
<@thejpster:matrix.org> yikes
<re_irc>
<@adamgreig:matrix.org> it's _probably_ fine to just write to the vtor memory even if it's not there, but I don't really like it...
<re_irc>
<@adamgreig:matrix.org> but we do have people ask about it a bunch because their bootloader didn't set it and the only observable effect is none of their interrupts work
<re_irc>
<@thejpster:matrix.org> Surely there are bitfields to tell you which options are enabled?
<re_irc>
<@adamgreig:matrix.org> often they don't even know they're using a bootloader
<re_irc>
<@adamgreig:matrix.org> hmm, afaik there's no way to detect presence of vtor
<re_irc>
<@adamgreig:matrix.org> I guess you could write to it and see if it sticks
<re_irc>
<@gauteh:matrix.org> any way to make cortex-m-rt warn or error (in debug mode) if vtor is wrong?
<re_irc>
<@thejpster:matrix.org> Maybe we should make a ticket and talk about it there. I've asked enough questions.
<re_irc>
<@dirbaio:matrix.org> armv6 RM: Implementations not providing configurability of the table base provide a VTOR with
<re_irc>
<@dirbaio:matrix.org> RAZ/WI behavior.
<re_irc>
<@adamgreig:matrix.org> so you're fine to always write to it, then?
<re_irc>
<@dirbaio:matrix.org> seems like it
<re_irc>
<@dirbaio:matrix.org> also: "The range of values that the VTOR can accept is IMPLEMENTATION DEFINED" :D
<re_irc>
<@adamgreig:matrix.org> RAZ/WI is read-as-zero, writes ignored, btw
<re_irc>
<@adamgreig:matrix.org> they do at least document how to find out what range is supported: write all 1s, read back, see how many are still 1
<re_irc>
<@adamgreig:matrix.org> so it seems you can officially just write to vtor and expect it to be OK, and c-m-rt always knows what to write to vtor since it knows the address of the vector table
<re_irc>
<@adamgreig:matrix.org> I also worry doing this would only encourage more broken bootloaders to exist
<re_irc>
<@thejpster:matrix.org> We're doing to have to do all this in the .s file aren't we. Any chance we can put it back until global_asm is stable?
<re_irc>
<@thejpster:matrix.org> The less ASM we have the better as far as I am concerned.
<re_irc>
<@adamgreig:matrix.org> well, we could update the .s to do the SP and VTOR write, that's v simple
<re_irc>
<@adamgreig:matrix.org> with global_asm we have to write the same amount of asm
<re_irc>
<@adamgreig:matrix.org> just we could feature-gate doing these quirks-mode fixes
<re_irc>
<@adamgreig:matrix.org> but yea, maybe they can wait until global_asm means we can feature-gate them
<re_irc>
<@adamgreig:matrix.org> and put it in the cortex-m-rt FAQs :P
<re_irc>
<@adamgreig:matrix.org> the other thing that would help is most people who are using a bootloader without realising are using a common hardware platform that they're probably also using a HAL for
<re_irc>
<@adamgreig:matrix.org> and the HAL could set the feature on cortex-m-rt
<re_irc>
<@adamgreig:matrix.org> so for many users it would become invisible
<re_irc>
<@thejpster:matrix.org> Can you say which chips / platforms have these broken bootloaders? The other approach is to fix them.
<re_irc>
<@adamgreig:matrix.org> sadly I suspect a number of them are burnt into ROM on the chips and/or are part of its secureboot stuff
<re_irc>
<@adamgreig:matrix.org> the most recent case was the ambiq apollo chips
<re_irc>
<@adamgreig:matrix.org> ok, I'll open an issue on c-m-rt for further discussion / putting-off-til-global-asm
<cr1901>
Just for my own ref: Do HALs for Cortex-M provide Cortex-M specific traits?
<cr1901>
re: "and the HAL could set the feature on cortex-m-rt"
<cr1901>
err not provide*, but rather impl Cortex-M-specific traits
<re_irc>
<@adamgreig:matrix.org> typically the platform HALs (like an STM32 HAL or nRF HAL) will have a dependency on cortex-m-rt via the PAC
<cr1901>
ahh
<re_irc>
<@adamgreig:matrix.org> so they could enable the feature on cortex-m-rt
<re_irc>
<@adamgreig:matrix.org> I don't think traits would come into it
<re_irc>
<@adamgreig:matrix.org> ok, thanks for the discussion about it everyone, I'm glad I'm not totally alone in not really wanting to do it necessarily, heh
<re_irc>
<@adamgreig:matrix.org> for the last 7 minutes or so, any HAL PRs that updated in the last week and want discussing?
<re_irc>
<@therealprof:matrix.org> BTW: e-h alpha.6 was released 4 days ago. ð
<re_irc>
<@adamgreig:matrix.org> oh yea! I'll stick that in announcements too, thanks
<re_irc>
<@dirbaio:matrix.org> with default methods, HALs only had to implement read, write, transfer, transfer_inplace
<re_irc>
<@sh3rm4n:matrix.org> If there is a good blueprint to copy & paste instead of using default methods, I think it is not too bad removing them ðĪ
<re_irc>
<@eldruin:matrix.org> yeah, maybe they can be added as docs
<re_irc>
<@eldruin:matrix.org> I see the annoyance, but I think it is pretty mild, compared to other restructuring work
<re_irc>
<@sh3rm4n:matrix.org> And these docs can also explicitly point out to handle ManagedCS differently.
<re_irc>
<@dirbaio:matrix.org> as if that wasn't enough pain: setting VTOR like that will break apps using the nrf softdevice
<re_irc>
<@adamgreig:matrix.org> lol great
<re_irc>
<@adamgreig:matrix.org> yes, I see
<re_irc>
<@adamgreig:matrix.org> hmm, do I
<re_irc>
<@adamgreig:matrix.org> why?
<re_irc>
<@dirbaio:matrix.org> the softdevice lives at start of flash, it handles some irqs and forwards the rest to your app
<re_irc>
<@adamgreig:matrix.org> ah, so the default situation is: your memory.x puts flash start later in the flash, to leave room for softdevice, and never sets vtor to your vector table
<re_irc>
<@dirbaio:matrix.org> if you set VTOR pointing to your app, the softdevice won't get its irqs
<re_irc>
<@adamgreig:matrix.org> because softdevice reads your own vector table and forwards irqs it doesn't handle?
<re_irc>
<@adamgreig:matrix.org> there's like three things a bootloader needs to do. set vtor, set sp, jump to rv.
<re_irc>
<@dirbaio:matrix.org> nordic's bootloaders use it
<re_irc>
<@adamgreig:matrix.org> bootloader authors managing 1/3 and calling it a day
<re_irc>
<@adamgreig:matrix.org> hah, that's fun
<re_irc>
<@dngrs:matrix.org> dngrs:matrix.org: should I open an issue? Unfortunately I don't have time to fix it myself
<re_irc>
<@adamgreig:matrix.org> nordic's stuff seems fine except it just makes it annoying for us to work around buggy bootloaders generically
<re_irc>
<@adamgreig:matrix.org> but i'd rather support nrf softdevice properly than support buggy bootloaders properly if it was one or the other...
<re_irc>
<@martin_lfs:matrix.org> Hey all, does anyone have experience with yocto/meta-rust? I'm trying to get the rust-hello-world running on a dev board, but all I get in `tmp` right now is .rpm files. I'm still pretty new to yocto and very new to `meta-rust`.
<re_irc>
<@dirbaio:matrix.org> dngrs:matrix.org: probably, i'd say it's a bug
<re_irc>
<@firefrommoonlight:matrix.org> Has anyone run an Stm2H7 or other Cortex-M7 on batteries?
<re_irc>
<@firefrommoonlight:matrix.org> My battery-powered stuff before has been teh sort that is slower and stays asleep most of the time
<re_irc>
<@firefrommoonlight:matrix.org> I'm doing some DSP stuff to make superhero headphones and or hearing aids, and am looking at a lot of FIR taps!
<re_irc>
<@firefrommoonlight:matrix.org> So I may use a dual-core H7 for each ear.
<re_irc>
<@firefrommoonlight:matrix.org> I'm def looking at some sort of daily-charge Lion battery, but would that even do it?
<re_irc>
<@firefrommoonlight:matrix.org> I guess I could just figure out how to wire a few AAs to the dev board I've got and see how long they last...
<re_irc>
<@firefrommoonlight:matrix.org> The M7 core would do the realtime DSP, and the M4 core would periodically (or continuously) recalculate the coefficients
<re_irc>
<@firefrommoonlight:matrix.org> I have 4 channels, L/R and Front/back for each, and when I push up the num taps to what works good in Python prototype, the signal gets screwed up from taking longer than the audio streams at
<re_irc>
<@firefrommoonlight:matrix.org> an MCU per ear with mild links for a few things is easy to conceptualize, but I worry it'll burn the batteries too fast!
<re_irc>
<@dngrs:matrix.org> I'm running an F4 on 2x rechargable AA, it doesn't seem to mind the decreasing voltage *at all*; I've read about voltage dependent wait states in some other STM RMs though
<re_irc>
<@firefrommoonlight:matrix.org> Yea, it's got them
<re_irc>
<@firefrommoonlight:matrix.org> I'm using VOS0 though to get the full 480Mhz
<re_irc>
<@adamgreig:matrix.org> if you use a newer H7, it has a FIR accelerator that can run while the CPU is asleep, probably the fastest and lowest power option
<re_irc>
<@firefrommoonlight:matrix.org> Ie you need full grunt voltage to get max speeds!
<re_irc>
<@dngrs:matrix.org> more like FIRfrommoonlight am I right
<re_irc>
<@adamgreig:matrix.org> I don't think any of the dual core parts have it, though, since they're all the older H7s
<re_irc>
<@adamgreig:matrix.org> but check like the H723
<re_irc>
<@adamgreig:matrix.org> it has a CORDIC unit too, for accelerated integer sin/cos
<re_irc>
<@firefrommoonlight:matrix.org> Nice!! Does that use its own algos, or would I still use CMSIS-DSP?
<re_irc>
<@adamgreig:matrix.org> don't know, it's just a peripheral, I'd be writing to its control registers
<re_irc>
<@firefrommoonlight:matrix.org> I heard something called SIMD can help too, but haven't messed with that
<re_irc>
<@adamgreig:matrix.org> how many taps are you talking about, and at what sample rate?
<re_irc>
<@firefrommoonlight:matrix.org> Nice - going to read that RM section. That would be great
<re_irc>
<@adamgreig:matrix.org> SIMD will only help if you have 16 or 8 bit samples
<re_irc>
<@firefrommoonlight:matrix.org> Short answer is the more the better
<re_irc>
<@firefrommoonlight:matrix.org> Long answer is AT LEAST ~1000 x 4 channels
<re_irc>
<@adamgreig:matrix.org> more taps = more delay which might be pretty painful for audio stuff though#
<re_irc>
<@firefrommoonlight:matrix.org> Maybe x 2 channels if I can combine them
<re_irc>
<@adamgreig:matrix.org> maybe at 1000 taps it's time to look in to IIR filters?
<re_irc>
<@adamgreig:matrix.org> or multi-rate processing
<re_irc>
<@firefrommoonlight:matrix.org> Also there are 2 stages of FIR, since I need to downsamples the DFSDM first, since the hardware sampling leaves freqs above nyquist/4 unusable
<re_irc>
<@dirbaio:matrix.org> do the convoution with FFT? ðĪŠ
<re_irc>
<@adamgreig:matrix.org> heh, yea, a 1024-point fft is probably a lot quicker
<re_irc>
<@firefrommoonlight:matrix.org> It is I think dirbaio
<re_irc>
<@firefrommoonlight:matrix.org> I assumed CMSIS-DSP did that, but I haven't actually confirmed
<re_irc>
<@firefrommoonlight:matrix.org> Could also try with fixed point, but have heard that can cause subtle problems you have to be good at IDing
<re_irc>
<@dirbaio:matrix.org> just make your own ASIC. easy peasy filter squeezy
<re_irc>
<@adamgreig:matrix.org> you can at least simulate the fixed point behaviour in python and compare it to the floating point version to see how the response differs
<re_irc>
<@adamgreig:matrix.org> there are situations where a 1kpt fir might make sense but if you just need a sharp frequency response then other topologies might be much less computationally intensive
<re_irc>
<@adamgreig:matrix.org> of course depends what sorts of things you're doing! maybe if the other core is constantly recomputing the coefficients it makes sense to use fir to keep the coefficients easy to find/check
<re_irc>
<@adamgreig:matrix.org> certainly adds a constraint compared to being able to super optimise it all ahead of time on a computer
<re_irc>
<@adamgreig:matrix.org> I'm sad, I wanted to use the H723 with its filter accelerator (the FMA peripheral btw) on a thing recently but couldn't buy any ;(
<re_irc>
<@adamgreig:matrix.org> ended up buying some H743 instead and will just have to live without it
<re_irc>
<@firefrommoonlight:matrix.org> That's a great point
<re_irc>
<@firefrommoonlight:matrix.org> I've heard mixed things about floating vs fixed on FPU MCUs, but should just test and see what the performance and speed is
<re_irc>
<@firefrommoonlight:matrix.org> I figure float is a good start though, since it eliminates a class of errors
<re_irc>
<@firefrommoonlight:matrix.org> and simplifies code
<re_irc>
<@firefrommoonlight:matrix.org> and is easier to conceptualize
<re_irc>
<@firefrommoonlight:matrix.org> I do need sharp freq response, since I'm adjusting narrow freq bands, at least down low
<re_irc>
<@firefrommoonlight:matrix.org> If the FIR taps are not enough (Or if I try IIR?), the low freq signal/noise separation will probably not work well enough, since we're talking <10Hz bands
<re_irc>
<@firefrommoonlight:matrix.org> I'm scaling the bands logarithmically though, hence teh concern being mainly low freqs
<re_irc>
<@firefrommoonlight:matrix.org> adamgreig: Maybe you could get a dev board?
<re_irc>
<@firefrommoonlight:matrix.org> I'm assuming any production runs with STM32 are out of the question in the near fugure
<re_irc>
<@adamgreig:matrix.org> for small batch production they occasionally pop up and you can nab a few hundred
<re_irc>
<@firefrommoonlight:matrix.org> That's how I snagged the L4's... then got limfaced on external ADCs...
<re_irc>
<@adamgreig:matrix.org> like, digikey have 700 H753, LCSC have 1k H750, mouser have... 16 H742 lol
<re_irc>
<@adamgreig:matrix.org> sucks if you want a particular package or whatever
<re_irc>
<@firefrommoonlight:matrix.org> Oh nice!
<re_irc>
<@firefrommoonlight:matrix.org> Without looking, I predict: All large pin-count BGA
<re_irc>
<@firefrommoonlight:matrix.org> LCSC having any STM32... that's surprising and nice