rardiol has quit [Ping timeout: 240 seconds]
SanchayanMaity has quit [Ping timeout: 245 seconds]
SanchayanMaity has joined #rust-embedded
procton_ has joined #rust-embedded
procton__ has quit [Ping timeout: 268 seconds]
<re_irc> <@xnorman:matrix.org> last week, maybe longer, James Munns suggested i might check into zerocopy as using postcard and my big struct was causing me to blow up my stack and segfault..
<re_irc> <@xnorman:matrix.org> unfortunately, I have options in my data.. I could work around that but I do quite like option.. are there any other libs that i should check into?
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter has joined #rust-embedded
<re_irc> <@henrik_alser:matrix.org> Alex Norman: in what situation does the problem occur?
<re_irc> <@henrik_alser:matrix.org> Can you have it statically allocated and pass around a pointer instead?
<re_irc> <@henrik_alser:matrix.org> Or if it’s a transfer, do it in chunks?
<re_irc> <@fragadaleta:matrix.org> is this a decent soldering station? https://www.amazon.de/-/en/gp/product/B07X5P2WLZ/ref=ox_sc_act_title_1?smid=A3TSTKIZ79LR1Y&psc=1
cr1901 has joined #rust-embedded
cr1901_ has quit [Ping timeout: 240 seconds]
<re_irc> <@eldruin:matrix.org> Nice blog posts from someone at the University of Stuttgart: https://robamu.github.io/post/rust-ecosystem/
<re_irc> <@henrik_alser:matrix.org> frag: What are you soldering? 60W might be a little low if you're using lead free solder, also consider what tips are available and for future replacement
<re_irc> <@fragadaleta:matrix.org> yeah there are 5 different tips. What's the power i should be looking at?
<re_irc> <@fragadaleta:matrix.org> eldruin:matrix.org: really cool article! thanks for sharing
<re_irc> <@henrik_alser:matrix.org> frag: In this price range i'd go for Yihua 939D+
<re_irc> <@henrik_alser:matrix.org> Or if you're willing to spend a little more the AiXun T3A
<re_irc> <@henrik_alser:matrix.org> Or yet more the JBC CD-2BE
<re_irc> <@henrik_alser:matrix.org> Yeah that's a great choice for the price
<re_irc> <@eldruin:matrix.org> you will probably not use those clips and magnifier. like physically it would be difficult to use
<re_irc> <@ryan-summers:matrix.org> I think I bought a similar station a year or two back and have been very disappointed with the quality of the tips
<re_irc> <@ryan-summers:matrix.org> Other than that it works fine
<re_irc> <@fragadaleta:matrix.org> ryan-summers:matrix.org: you are speaking about the Yihua?
<re_irc> <@ryan-summers:matrix.org> Ah, no I got a NEWACALOX 60W
<re_irc> <@ryan-summers:matrix.org> Although I have found 60W to be pretty sufficient for my needs, but I only use it for minor rework etc
<re_irc> <@fragadaleta:matrix.org> alright so i guess i'll go with Yihua 939D+
<re_irc> <@fragadaleta:matrix.org> 🙂
<re_irc> <@k900:0upti.me> Honestly if you're just starting, you probably don't need a soldering station at all
<re_irc> <@k900:0upti.me> You can just use a breadboard, or your grandpa's soldering iron and some luck
<re_irc> <@luojia65:matrix.org> I got RustSBI run on HiFive Unmatched board with FU740 five-core heterogeneous RISC-V processor
<re_irc> <@luojia65:matrix.org> It's no_std environment and uses embedded-hal, serde and other Rust libraries. Link: https://github.com/rustsbi/rustsbi-hifive-unmatched
<re_irc> <@fragadaleta:matrix.org> k900:0upti.me: yeah i thought of that. Thing is that i have a project with xbee/zigbee stuff and some dongles for which some soldering might be needed. But you are right. My tasks at the moment are pretty much on the software part to flash on the chips
<re_irc> <@fragadaleta:matrix.org> for the record i am looking for folks with network/comm. low level skills, Rust and paid contract 😉
<re_irc> <@fragadaleta:matrix.org> in case there's anyone, DM me
rardiol has joined #rust-embedded
<re_irc> <@adamgreig:matrix.org> does anyone have any ideas why codegen for the cortex-m asm would have gotten much worse going from nightly-2020-08-20 to nightly-2021-12-16? https://github.com/rust-embedded/cortex-m/pull/372#issuecomment-996496973
<re_irc> <@adamgreig:matrix.org> or, well, I have "ideas" (blame llvm) but nothing specific heh
<re_irc> <@adamgreig:matrix.org> maybe `options(nostack)` will help... 🤔
procton_ has quit [Remote host closed the connection]
<re_irc> <@fragadaleta:matrix.org> can you run your app bare metal on a beagleboard or is it a pain like with the Rpi with the proprietary bootloader?
<re_irc> <@k900:0upti.me> Less pain than RPI, but definitely still some pain
<re_irc> <@k900:0upti.me> In general, the more complex the SoC, the more effort it will take to run things on the "bare metal"
<re_irc> <@k900:0upti.me> Also, you can generally just search for "[board name] u-boot", and if it exists, then you probably need a bootloader
<re_irc> <@k900:0upti.me> Or at least want a bootloader
<re_irc> <@k900:0upti.me> In this particular case https://github.com/beagleboard/u-boot
<re_irc> <@firefrommoonlight:matrix.org> Has anyone programmed Cortex-A using Rust? Any examples, guides etc? I don't have a project for it ATM, but would like to add to my toolkit
<re_irc> <@k900:0upti.me> There's a HAL for it: https://github.com/rust-embedded/cortex-a
<re_irc> <@adamgreig:matrix.org> https://github.com/rust-embedded/cortex-a
<re_irc> <@adamgreig:matrix.org> snap :D
<re_irc> <@firefrommoonlight:matrix.org> https://docs.rs/crate/cortex-a/2.5.0
<re_irc> <@firefrommoonlight:matrix.org> Hell yea!
<re_irc> <@k900:0upti.me> But honestly it's probably going to be a pain
<re_irc> <@k900:0upti.me> Because most chips with A-cores are complex enough that you probably want to just run Linux on them
<re_irc> <@firefrommoonlight:matrix.org> Hah oh no! One of embedded's appeal for me is not having a GPOS and is associated latency
<re_irc> <@firefrommoonlight:matrix.org> Seems like you could also use them for the speed?
<re_irc> <@k900:0upti.me> Well, A-cores aren't really _designed_ for "embedded"
<re_irc> <@k900:0upti.me> If you want performance _and_ hard real time, you probably want an M33 or an M55
<re_irc> <@adamgreig:matrix.org> or probably a cortex-r, which is sort of like a realtime cortex-a
<re_irc> <@k900:0upti.me> Do those exist if you're not a Silicon Company?
<re_irc> <@k900:0upti.me> Last time I checked, literally no one was making complete SoCs with those
<re_irc> <@adamgreig:matrix.org> they're less common but you can definitely just buy them off the shelf
<re_irc> <@adamgreig:matrix.org> TI have a few, like https://www.ti.com/product/RM42L432
<re_irc> <@adamgreig:matrix.org> and they're embedded in some Xilinx Zync FPGAs too
<re_irc> <@adamgreig:matrix.org> sort of a chore though
<re_irc> <@firefrommoonlight:matrix.org> The options!
<re_irc> <@adamgreig:matrix.org> I'd have thought for highest performance realtime these days a chunky CM7 is probably better than an M55? stm32h7 or iMXRT1062 sort of thing
<re_irc> <@firefrommoonlight:matrix.org> For M33, nRF53 and StmL5 are both well supported in Rust
<re_irc> <@firefrommoonlight:matrix.org> Yea H7s are great!!
<re_irc> <@firefrommoonlight:matrix.org> Looking into M55 now
<re_irc> <@k900:0upti.me> adamgreig: The M55 is wider, but less deep, so probably depends on the workload?
<re_irc> <@adamgreig:matrix.org> true, if you can use the new dsp it's probably good
<re_irc> <@adamgreig:matrix.org> are there any high-clock-speed socs with it in yet?
<re_irc> <@k900:0upti.me> It's also aarch64 which should also help a bunch if you have a smart enough compiler
<re_irc> <@k900:0upti.me> adamgreig: I'm looking now and I can't find anything
<re_irc> <@k900:0upti.me> But I feel like I've seen an announcement or two recently
<re_irc> <@adamgreig:matrix.org> it's aarch64???
<re_irc> <@k900:0upti.me> I think so
<re_irc> <@xiretza:xiretza.xyz> according to wikipedia it's ARMv8.1-M, which doesn't include AArch64
<re_irc> <@k900:0upti.me> OK I looked it up
<re_irc> <@adamgreig:matrix.org> yea, aarch64 is part of armv8 but armv8-m is only T32 instructions I believe
<re_irc> <@k900:0upti.me> It's aarch32, but with a 64-bit memory bus and 64-bit load/store
<re_irc> <@k900:0upti.me> Which is ... interesting
<re_irc> <@adamgreig:matrix.org> I don't think it's aarch32 either is it?
<re_irc> <@adamgreig:matrix.org> armv8-a supports A64, A32, T32 instructions, armv8-m only supports T32
<re_irc> <@adamgreig:matrix.org> cortex-m7 is also a 64 bit instruction and data bus (and armv7-m)
<re_irc> <@k900:0upti.me> GCC says it supports aarch32, Clang only has t32, I am confused
<re_irc> <@josfemova:matrix.org> eldruin:matrix.org: Nice, I'm currently shilling rust in the space systems lab of my Uni and this is good propaganda material haha
hwj has joined #rust-embedded
<re_irc> <@firefrommoonlight:matrix.org> It looks like M55 has potential to be an even faster M7 replacement, but seems like the chips aren't there yet
<re_irc> <@firefrommoonlight:matrix.org> And may not be for a few years
<re_irc> <@jamesmunns:beeper.com> At some point I'm just gunna have to switch over to Cortex-A. Once we start hitting GHz and all the peripherals, there's probably not much left to benefit the simplicity of an MCU.
<re_irc> <@dirbaio:matrix.org> low-power maybe
<re_irc> <@dirbaio:matrix.org> or cost
<re_irc> <@jamesmunns:beeper.com> I actually would love to see more usable Cortex A+M designs, where you can do the real time stuff on the M, and delegate all the hard UI and networking stuff up to the A.
<re_irc> <@jamesmunns:beeper.com> I mean maybe, but stuff like the imxrt family aren't appreciably cheaper than a low cost A part
<re_irc> <@jamesmunns:beeper.com> re: power, I'd love to see a device with split power domains that allows the M to keep running with the A full-off
<re_irc> <@jamesmunns:beeper.com> I've seen a lot of heterogeneous parts like the imx7 and STM's parts, but I think they keep all of the core RAM on the same domain
<re_irc> <@jamesmunns:beeper.com> and it's DDR that kills you
<re_irc> <@jamesmunns:beeper.com> (idle power usage wise)
<re_irc> <@dirbaio:matrix.org> reliability maybe?
<re_irc> <@jamesmunns:beeper.com> I mean sure, there's always a niche for everything
<re_irc> <@jamesmunns:beeper.com> But you can design reliable, non-Linux systems for Cortex-A too.
<re_irc> <@jamesmunns:beeper.com> that's what all the auto OEMs do
<re_irc> <@dirbaio:matrix.org> on ur minimum-viable-product attempts (first was rpi+raspbian, second was orange pi + yocto) we kept having the stuff randomly freeze/hang or drop off the network for no reason whatsoever, coming back when powercycled 🤷
<re_irc> <@jamesmunns:beeper.com> I mean
<re_irc> <@jamesmunns:beeper.com> fair
<re_irc> <@dirbaio:matrix.org> even using the hardware watchdog >_<
<re_irc> <@dirbaio:matrix.org> but who knows why though. Sd cards, dodgy hardware (orange pi is crazy cost optimized), or me having no idea how to do embedded linux (yocto is crazy complex)
<re_irc> <@jamesmunns:beeper.com> They make external watchdogs you can use with a FET to do a whole power domain cycle :p
<re_irc> <@jamesmunns:beeper.com> Just make sure you service it with your app layer, not your OS, since it can keep going when everything is still busted
<re_irc> <@dirbaio:matrix.org> yeah, I was feeding it from my app's mainloop, so it'd trigger if my app crashed or hanged
<re_irc> <@jamesmunns:beeper.com> Some of them even give you warning, which you can use with an OS driver to flush disks and attempt to gracefully shut down first
<re_irc> <@dirbaio:matrix.org> and still it'd completely hang sometimes. no network, no uart console 🤷
<re_irc> <@jamesmunns:beeper.com> Yeah, honestly if I wanted something reliable, I'd use bare-metal-but-with-allocator
<re_irc> <@dirbaio:matrix.org> vs now with everything on nrf52 there's absolutely zero reliability issues
<re_irc> <@jamesmunns:beeper.com> maybe set up my own flavor of `std`
<re_irc> <@jamesmunns:beeper.com> like the esp32 folks do
<re_irc> <@jamesmunns:beeper.com> Which again, isn't far off what the auto OEMs do, they either use a reliable RTOS, or use a hypervisor under the linux layer
<re_irc> <@jamesmunns:beeper.com> Not saying your solution is wrong/bad! But bare-metal/no-alloc is a pretty uphill battle for a couple of tasks, especially networking and UI.
<re_irc> <@dirbaio:matrix.org> networking? with async it's as easy as on std+threads :)
<re_irc> <@k900:0upti.me> The only heterogeneous design like that I can remember is Intel's Quark
<re_irc> <@k900:0upti.me> And we all know how that ended
<re_irc> <@jamesmunns:beeper.com> and having a mostly-separate Cortex-M domain to act as your babysitter, with full power to kick the Cortex-A domain, would be pretty neat
<re_irc> <@dirbaio:matrix.org> I do super complex networking on my products (ethernet, mobile/ppp, bluetooth, all mesh routed, with end-to-end encryption), with no std, no alloc :)
<re_irc> <@jamesmunns:beeper.com> k900:0upti.me: There's quite a few in the arm world. Especially with Cortex-A + Cortex-M for commercial usage, or Cortex-A + Cortex-R for automotive/safety critical usage
<re_irc> <@jamesmunns:beeper.com> dirbaio:matrix.org: Yeah, if you're dirbaio :D
<re_irc> <@k900:0upti.me> No, I mean ones that can disable the big cores entirely
<re_irc> <@dirbaio:matrix.org> and it's as easy as on std linux (because I've done it in the previous iterations...)
<re_irc> <@jamesmunns:beeper.com> ahhh
<re_irc> <@k900:0upti.me> To be fair, Intel _did_ fuck up impressively hard on that one, even by Intel side project standards
<re_irc> <@dirbaio:matrix.org> jamesmunns:beeper.com: all that stuff is opensource, just sayin' :D
<re_irc> <@dirbaio:matrix.org> vs on cortex-a I don't think I could've done it. On Linux I tried and failed. And custom cortex-a RTOS sounds like work for a 10+ engineer team
<re_irc> <@jamesmunns:beeper.com> I mean, not an impossible battle: https://github.com/iqlusioninc/usbarmory.rs
<re_irc> <@adamgreig:matrix.org> jamesmunns:beeper.com: h7 splits ram into like 6 banks, most of which can be turned on and off separately
<re_irc> <@adamgreig:matrix.org> so you can have the cm7 and its axisram and dtcm off, the cm4 on with one of its two ram banks, the backup domain bank off, then turn off the cm4, turn on the basic dma and backup ram, have the dma copy something out to a uart while both cores sleep, etc
<re_irc> <@adamgreig:matrix.org> complexity++
<re_irc> <@jamesmunns:beeper.com> Most of my research was on the imx7, when I thought about using it for that a couple of years back. Both CPUs were on the same vcore
<re_irc> <@jamesmunns:beeper.com> but yeah, it certainly makes it simpler the more is common/locked together.
<re_irc> <@adamgreig:matrix.org> I guess you've seen https://jaycarlson.net/embedded-linux/ ?
<re_irc> <@adamgreig:matrix.org> super cheap and easy cortex-a linux stuff
<re_irc> <@adamgreig:matrix.org> and clocks way faster than cortex-m
<re_irc> <@jamesmunns:beeper.com> Yeah, I've been thinking about trying out some of the SAMA parts, since they have on-chip RAM
<re_irc> <@jamesmunns:beeper.com> Drop a https://www.tindie.com/products/c298f627/hanesom/ next to a https://www.tindie.com/products/arturo182/rp2040-stamp/ ? baby you got a stew going
<re_irc> <@adamgreig:matrix.org> wow, that's a cute module
<re_irc> <@adamgreig:matrix.org> my tweezer fingers are hurting just imagining placing all those passives
<re_irc> <@jamesmunns:beeper.com> I hope for their sanity it was all done with a pnp :/
<re_irc> <@adamgreig:matrix.org> yea...
<re_irc> <@adamgreig:matrix.org> the beaglebone stuff has something a bit like this right? the PRUs
<re_irc> <@adamgreig:matrix.org> maybe they're more like the rp2040 pio
<re_irc> <@firefrommoonlight:matrix.org> adamgreig: A neat thing about this is being able to use an H7 for both high perf, and low power uses
<re_irc> <@adamgreig:matrix.org> yea, the range of power is frightening
<re_irc> <@adamgreig:matrix.org> I think the lowest is about 20nA and the highest is like 600mA?
<re_irc> <@adamgreig:matrix.org> wipes the floor of any cortex-a part for low-power stuff
<re_irc> <@adamgreig:matrix.org> but even the cm7 at 500MHz is not going to do anything like as much number crunching as a newish quad-core cortex-a with neon etc
<re_irc> <@ryan-summers:matrix.org> I assume you mean the H7 in the deepest sleep mode? I haven't many actual uses of those modes in reality
<re_irc> <@ryan-summers:matrix.org> Because the only way to generally wake them is with external stimuli
<re_irc> <@ryan-summers:matrix.org> At lowest practical power points, generally you have the 32KHz clock running or something, and I assume that's a few orders of magnitude above 20nA, but I've never measured
<re_irc> <@adamgreig:matrix.org> yea, 20nA is extreme, that's running just off vbat with rtc and lse and backup ram all off
<re_irc> <@adamgreig:matrix.org> lowest power where it can still wake itself up from a timer or whatever is about 2µA
<re_irc> <@adamgreig:matrix.org> (which I have measured on an h743)
<re_irc> <@adamgreig:matrix.org> (I haven't measured the 20nA but I am a little curious, heh)
<re_irc> <@dirbaio:matrix.org> wow 2uA on timer wakeup is really good!
<re_irc> <@dirbaio:matrix.org> slightly better than nrf52840 (2.7uA)
<re_irc> <@adamgreig:matrix.org> it in the 2-3µA region depending on temperature and voltage
<re_irc> <@adamgreig:matrix.org> well it climbs pretty quickly at temperature actually, don't run these things at 100C and hope for much battery life lol
<re_irc> <@ryan-summers:matrix.org> That's still a lot better than I was expecting tbh
<re_irc> <@ryan-summers:matrix.org> For how massive of an MCU it is
<re_irc> <@adamgreig:matrix.org> yea! you don't think of it as a low-power option, like it's not an L4 or whatever
<re_irc> <@adamgreig:matrix.org> but it's surprisingly decent, especially since you can do a great job of waking up briefly, storming through some numbers, then sleeping while the low-power dma does its job in the low-power ram or whatever
<re_irc> <@adamgreig:matrix.org> they have some wild demos for "autonomous mode"
<re_irc> <@jamesmunns:beeper.com> dI/dt on 2uA -> 600mA seems like it would make the caps pretty angery lol
<re_irc> <@jamesmunns:beeper.com> I'm guessing it takes a couple steps to go from off-off to on-on, especially if you have to start some DC/DCs up
<re_irc> <@adamgreig:matrix.org> yea, I think you'd wake up in run0* or whatever and have to turn on the plls, spin them up, switch up run mode, etc
<re_irc> <@ryan-summers:matrix.org> Does the H7 have an internal core regulator like the nrfs?
<re_irc> <@ryan-summers:matrix.org> Yes, looks like it does. Don't know if its a switcher or not
<re_irc> <@adamgreig:matrix.org> I think almost all stm32s have an internal ldo to run the cpu at ~1v
<re_irc> <@adamgreig:matrix.org> a few h7s also have an smps in some packages which you can use for that instead
<re_irc> <@ryan-summers:matrix.org> Ah, so very similar to the nRF architecture
<re_irc> <@ryan-summers:matrix.org> SMPS for efficiency gains
<re_irc> <@adamgreig:matrix.org> or you can usually feed the vcore yourself, but you have to handle scaling for run mode yourself too in that case
<re_irc> <@adamgreig:matrix.org> yea, on the big h7 using the built-in smps is a real efficiency saver
<re_irc> <@adamgreig:matrix.org> it's also a super easy way to confuse yourself because the smps state persists through a reset, so if your firmware configures the power stuff wrong it's quite annoying
<re_irc> <@ryan-summers:matrix.org> Oh really? I guess that makes sense
<re_irc> <@ryan-summers:matrix.org> POR vs PUC and all that
<re_irc> <@dirbaio:matrix.org> yeah it's an almost-brick 🤣
<re_irc> <@ryan-summers:matrix.org> Just hold it in reset while you power it up. We've all made mistakes like that ;)
<re_irc> <@adamgreig:matrix.org> yea. easier said than done with most tools though
<re_irc> <@adamgreig:matrix.org> they can hold it in reset while attaching debug, but not through a power cycle
<re_irc> <@ryan-summers:matrix.org> There's always just holding a wire to the reset line when push comes to shove
<re_irc> <@adamgreig:matrix.org> usually simplest is to reset it into the system bootloader
<re_irc> <@dirbaio:matrix.org> it was really confusing because most stm32 screwups you can fix with --connect-under-reset, but not this one
<re_irc> <@xnorman:matrix.org> henrik_alser:matrix.org: (a bit late in the response).. I saving/restoring to/from flash memory.. basically the entire state of my program
<re_irc> <@dngrs:matrix.org> I have an interrupt based usb-uart. where/how exactly should I issue pending serial writes when those are not caused by incoming data? do I pend the interrupt then?
<re_irc> <@jamesmunns:beeper.com> rtic::pend
<re_irc> <@jamesmunns:beeper.com> oh, sorry, misread the question
<re_irc> <@dngrs:matrix.org> aye, used this already. So this would be the right thing to do here?
<re_irc> <@jamesmunns:beeper.com> if you want to pend, that'll do it
<re_irc> <@jamesmunns:beeper.com> I've definitely done that to process writes before
<re_irc> <@dngrs:matrix.org> Ok
<re_irc> <@dngrs:matrix.org> so in the case of `defmt-bbq` (logging messages over usb-uart here) I'd have to pend for every log call?
<re_irc> <@jamesmunns:beeper.com> I mean, it depends on how quickly you want to flush the buffer. I *think* depending on your hardware, that interrupt might fire every 1ms or whatever automatically
<re_irc> <@jamesmunns:beeper.com> not sure for the stm32 you're using
<re_irc> <@jamesmunns:beeper.com> (the USB interrupt)
<re_irc> <@dngrs:matrix.org> I think it's mandatory for usb to fire in regular and quite short intervals
<re_irc> <@dngrs:matrix.org> in other words I probably don't need any pend to ensure messages are getting processed *at all*, it would just potentially lower the latency
<re_irc> <@dngrs:matrix.org> right?
<re_irc> <@jamesmunns:beeper.com> I guess? I can't remember why I did it :D
<re_irc> <@dngrs:matrix.org> gonna try some LED logging
<re_irc> <@jamesmunns:beeper.com> :D
<re_irc> <@jamesmunns:beeper.com> 1khz might be too fast to see, but you could step down like 128:1 or so
<re_irc> <@dngrs:matrix.org> yeah,
hwj has quit [Ping timeout: 245 seconds]
<re_irc> <@dngrs:matrix.org> James Munns: ok so it seems USB polling is only required when there's stuff to process (in other words the hosts wants to set up the device or there's data incoming) and there's not automatic 1kHz or anything timer that does it. (but when you're not reacting to USB interrupts that then means you have to do a busy waiting poll). so yeah it does seem to me that when I'm using usb interrupts and only polling in...
<re_irc> ... them, I now do have to pend after each defmt log; at least that does fix my problem
<re_irc> <@dngrs:matrix.org> that's a bit inconvenient but I guess one can write forwarding macros
<re_irc> <@jamesmunns:beeper.com> You could also just set up a 10-100hz timer that boops the usb interrupt to keep things moving
<re_irc> <@dngrs:matrix.org> true
<re_irc> <@jamesmunns:beeper.com> Or, set a 10ms one-shot timer in each usb-poll that causes it to retrigger on a time out
<re_irc> <@dngrs:matrix.org> anyway, this is all still mighty cool, I now have a device that presents itself as a usb midi controller and also logs to uart over the same usb connection
<re_irc> <@jamesmunns:beeper.com> e.g. if you get usb interrupts a bunch, you keep resetting the timer, otherwise you get a 100hz idle boop to keep the queue draining
<re_irc> <@dngrs:matrix.org> aye
<re_irc> <@jamesmunns:beeper.com> but now I'm just getting fancy. Glad it's working!
<re_irc> <@jamesmunns:beeper.com> Does this fix your "must send one byte" issue?
<re_irc> <@dngrs:matrix.org> yup! I think that really only worked because I never emptied the rx buffer :D
<re_irc> <@jamesmunns:beeper.com> ahhhh
<re_irc> <@dngrs:matrix.org> actually since defmt only occupies tx I guess I could still use rx as a device control channel, *how cool is that*
<re_irc> <@jamesmunns:beeper.com> If you don't have power concerns, I usually just poll queues like that in the idle task
<re_irc> <@dngrs:matrix.org> yeah, I'll assume USB power here anyway
<re_irc> <@jamesmunns:beeper.com> also: you could also wrap your TX channel in postcard to mux logging and control response
<re_irc> <@jamesmunns:beeper.com> (that's what I'm going to do over rs-485)
<re_irc> <@dngrs:matrix.org> pffffssht, logging *is* a control response! (but yeah, that'd be even fancier)
<re_irc> <@jamesmunns:beeper.com> Since you can serde borrow, it'd be basically free too.
<re_irc> <@jamesmunns:beeper.com> ```rust
<re_irc> <@jamesmunns:beeper.com> #[derive(Serialize, Deserialize)]
<re_irc> <@jamesmunns:beeper.com> enum Response<'a> {
<re_irc> <@jamesmunns:beeper.com> PostcardBlob(&'a [u8]),
<re_irc> <@dngrs:matrix.org> *noice*
<re_irc> <@jamesmunns:beeper.com> (on both the sending and the receiving side!)
<re_irc> <@jamesmunns:beeper.com> I guess you'll incur one extra copy on serialization
<re_irc> <@jamesmunns:beeper.com> but not on deserialization
<re_irc> <@jamesmunns:beeper.com> and the copy will be a straight memcpy, so as fast as can be
hwj has joined #rust-embedded
hwj has quit [Remote host closed the connection]
<re_irc> <@tholmie:matrix.org> Anyone have a recommendation for an embedded friendly DSP library? pretty simple things like filters and maybe an FFT. I found https://crates.io/crates/signalo but wasn't too sold on it at a cursory glance..
<re_irc> <@dbrgn:matrix.coredump.ch> In the STM32L0x1 SVD file, the CNT (counter register) for LPTIM is set to `<access>read-only</access>`. Is this really the case, is this register not writable? I can't really find anything in the reference manual about counter reset...
<re_irc> <@firefrommoonlight:matrix.org> https://www.keil.com/pack/doc/CMSIS/DSP/html/index.html
<re_irc> <@firefrommoonlight:matrix.org> 100%
<re_irc> <@firefrommoonlight:matrix.org> Wrapped here: https://github.com/jacobrosenthal/cmsis-dsp-sys
<re_irc> <@firefrommoonlight:matrix.org> I further wrapped some of it [here](https://github.com/David-OConnor/cmsis-dsp-api) to replace the pointer API with references, and remove some redundant arguments etc. Mainly for Q31 and F32 FIR and IIR
<re_irc> <@firefrommoonlight:matrix.org> Filtering: https://www.keil.com/pack/doc/CMSIS/DSP/html/group__groupFilters.html
<re_irc> <@firefrommoonlight:matrix.org> Danilo: Good question. I noticed that the normal TIMx_CNT is rw
<re_irc> <@firefrommoonlight:matrix.org> On G4, check this:
<re_irc> <@firefrommoonlight:matrix.org> ```rust
<re_irc> <@firefrommoonlight:matrix.org> In order to reset the content of LPTIM_CNT register to zero, two reset mechanisms are
<re_irc> <@firefrommoonlight:matrix.org> implemented:
<re_irc> <@firefrommoonlight:matrix.org> I didn't see that section in G0, but it's wroth a shot
<re_irc> <@firefrommoonlight:matrix.org> *Looks like L0 doesn' thave `cntreset`. Maybe you can't, but they added the ability in newer versions. So in summary: Across the STM32 lineup, it appears TIMx_CNT is rw, and LPTIM_CNT is r only. On newer variants, there's a procedure to reset CNT, but maybe not on L0?
<re_irc> <@dbrgn:matrix.coredump.ch> firefrommoonlight: yeah, the TIMx timers have a writable counter. I need the timer for RTIC (monotonic), so as a workaround I'll only enable it in the `reset` method, then it should start at 0 🙂
<re_irc> <@burrbull:matrix.org> tholmie:matrix.org: https://docs.rs/cmsis_dsp/