<re_irc> <@dngrs:matrix.org> aww yiss more DSP things
<re_irc> <@tholmie:matrix.org> In my poking around I also found https://docs.rs/idsp/latest/idsp/ which is the core DSP used in this neat piece of ADC/DAC HW: https://github.com/quartiq/stabilizer
<re_irc> <@firefrommoonlight:matrix.org> IDSP is pretty sparse. I moved on when I noticed it can't do FIR
<re_irc> <@firefrommoonlight:matrix.org> Which is a pretty fundamental filter class
<re_irc> <@tholmie:matrix.org> yeah I was thinking the same. I'm contemplating taking a crack at some pure rust implementations in micromath
bpye7 has joined #rust-embedded
bpye72 has joined #rust-embedded
bpye7 has quit [Ping timeout: 240 seconds]
bpye72 is now known as bpye7
<re_irc> <@firefrommoonlight:matrix.org> It would be nice to have a full-featured Rust DSP lib
<re_irc> <@firefrommoonlight:matrix.org> That said... CMSIS-DSP has lots of functionality, works well, and is reasonably-well documented. Calling it from Rust is straightforward. You would have to do better than that
<re_irc> <@firefrommoonlight:matrix.org> The main caveats I have are #1: You may need to install some system dependencies for bindgen to work. #2 The pointer API
bpye71 has joined #rust-embedded
<re_irc> <@9names:matrix.org> there's also the portability issue, if you want to use your DSP functions on x86/riscv/etc
<re_irc> <@firefrommoonlight:matrix.org> One of Rust's nice features is good C FFI, ie being able to use a lib like this without much hassle
<re_irc> <@firefrommoonlight:matrix.org> Great point - I assume CMSIS only works on Arm
bpye7 has quit [Ping timeout: 256 seconds]
bpye71 is now known as bpye7
<re_irc> <@firefrommoonlight:matrix.org> It would be nice to have something that works on other platforms. Not sure if the answer is to start fresh, or expand IDSP
<re_irc> <@tholmie:matrix.org> Always the conundrum! This is mostly just for fun though so I’m not going to worry too much about what the exact best thing to do is 😛
rardiol has quit [Ping timeout: 256 seconds]
<re_irc> <@firefrommoonlight:matrix.org> Yea - maybe just solve the current problem. Ie CMSIS-DSP wrapped if on Arm; hand-code what you need or use IDSP if not
<re_irc> <@firefrommoonlight:matrix.org> I've been using the FIR, IIR, FIR decimator, and trig functions, which all worked in CMSIS directly, on ARM
starblue has quit [Ping timeout: 256 seconds]
starblue has joined #rust-embedded
<re_irc> <@tholmie:matrix.org> Woof. I’m not sure I’ve seen an errata before where the CPU halts. At least your fix isn’t burdensome
<re_irc> <@jamesmunns:beeper.com> It halted so hard the debugger couldn't revite it 😬
<re_irc> <@jamesmunns:beeper.com> Also, did arm-none-eabi-gdb get way more segfault-y in recent months?
<re_irc> <@tholmie:matrix.org> I wonder what’s happening in the chip fabric to cause it to crash and burn so hard
<re_irc> <@dirbaio:matrix.org> halt and catch fire 🔥
<re_irc> <@jamesmunns:beeper.com> it was *murder* to try and step through the code. It would segfault if I ever loaded the assembly pane
<re_irc> <@jamesmunns:beeper.com> (gdb, not the chip)
<re_irc> <@jamesmunns:beeper.com> and of course, it messed up terminal wrapping, so I had to open a new window
<re_irc> <@jamesmunns:beeper.com> luckily, it kept the CPU halted, so I could just re-open gdb, and keep single stepping
radens has quit [Quit: Connection closed for inactivity]
<re_irc> <@luojia65:matrix.org> Is there a way to forbid global allocator? I'm developing motherboard firmware, and require all memory allocation failure to be handled.
<re_irc> <@luojia65:matrix.org> For example it will force to use Box<T, A>, Vec<T, A> etc. and try_new_in functions in application
<re_irc> <@jamesmunns:beeper.com> Not officially
<re_irc> <@jamesmunns:beeper.com> You could probably define some symbols that would cause linker errors if someone included an allocator
<re_irc> <@dngrs:matrix.org> yeah, https://doc.rust-lang.org/std/alloc/index.html
<re_irc> <@dngrs:matrix.org> however that might be too blunt
<re_irc> <@dngrs:matrix.org> how about `no_global_oom_handling`
jackneillll has joined #rust-embedded
jackneilll has quit [Ping timeout: 260 seconds]
PyroPeter has quit [Ping timeout: 240 seconds]
PyroPeter has joined #rust-embedded
<re_irc> <@9names:matrix.org> AVR doesn't always build with every version of the compiler. try the last known good nightly and see if that works?
<re_irc> <@9names:matrix.org> here's what I dug up from a quick search in https://matrix.to/#/#avr-rust_Lobby:gitter.im
<re_irc> <@9names:matrix.org> > rahix
<re_irc> <@9names:matrix.org> 2. there are problems with nightlies beyond 2021-01-07, you should probably stick to that version of the compiler for now
<re_irc> <@alex:matrix.sempto.net> 9names: That did the trick, thank you!
rardiol has joined #rust-embedded
rardiol has quit [Ping timeout: 240 seconds]
rardiol has joined #rust-embedded
rardiol has quit [Ping timeout: 240 seconds]
rardiol has joined #rust-embedded
rardiol_ has joined #rust-embedded
rardiol has quit [Ping timeout: 268 seconds]
rardiol_ has quit [Ping timeout: 268 seconds]
<re_irc> <@lidialiker:matrix.org> another newbie question, it seems that my device (blue pill), loses program after I plug off st-link after flashing
<re_irc> <@lidialiker:matrix.org> is this expected and I need to persist it somehow or cargo-flash should persist it anyway? thanks
<re_irc> <@yatekii:matrix.org> lidialiker:matrix.org: it should persist as per cargo flash. It is written into the flash, which is persistent. What reset or other signals might do in combination with your program, I can't tell
<re_irc> <@dngrs:matrix.org> are you running it via gdb/cortex-debug? Then I think it will run from ram
<re_irc> <@lidialiker:matrix.org> I'm just doing
<re_irc> <@lidialiker:matrix.org> cargo flash --release --chip stm32f103C8
<re_irc> <@lidialiker:matrix.org> then it runs fine but when I unplug it and plug in again via st link or just by giving power through usb port it does not run anymore
<re_irc> <@dngrs:matrix.org> how are you determining "does not run"?
<re_irc> <@dngrs:matrix.org> maybe it's stuck in some boot loader mode
<re_irc> <@lidialiker:matrix.org> I'm reading gyro input and blinking the led depending on the values there
<re_irc> <@dngrs:matrix.org> ok
<re_irc> <@dngrs:matrix.org> make sure the BOOT0 jumper is set to 0
<re_irc> <@lidialiker:matrix.org> but you are right I can't for sure determine whether it runs or not
<re_irc> <@lidialiker:matrix.org> but jumper is on 0
<re_irc> <@lidialiker:matrix.org> I'll try to dig deeper, thanks
<re_irc> <@dngrs:matrix.org> odd. Maybe try a blinky program
<re_irc> <@lidialiker:matrix.org> okay, so the program was indeed running, it's just for some reason it was unable to initiate the gyro during startup but adding delay before trying to establish i2c connecting solved the issue 🤔
<re_irc> <@lidialiker:matrix.org> thanks for help dngrs (spookyvisiongithub) !
<re_irc> <@dngrs:matrix.org> wheeeeeee
<re_irc> <@henrik_alser:matrix.org> lidialiker: this can happen because some chips require longer time between power-up and accepting communication and/or if the sensor has its own regulator powered from the main board its rail might take a while to stabilize when input power is applied
rardiol has joined #rust-embedded
<re_irc> <@lidialiker:matrix.org> henrik_alser thanks, is there way for i2c to send "heartbeat" or something to check if other side is online?
<re_irc> <@lidialiker:matrix.org> right now I just do sleep 1sec which is not cool😅
<re_irc> <@thejpster:matrix.org> adamgreig: as promised, here's a starter for 10 on a "This year in Embedded Rust": https://hackmd.io/znpl-20YQ0icKHOXR9EpQw/SywUu_iqK
<re_irc> <@thejpster:matrix.org> Yes I did write a script to get the git stats, and yes I wrote it in Rust, and no, I don't really like the git2 API.
<re_irc> <@thejpster:matrix.org> It needs some more chip related news (lest anyone claims we forget their <my-chip-here>-rs group) and a head's up for what's coming in 2022.
<re_irc> <@thejpster:matrix.org> https://github.com/thejpster/repo-stats - but be warned, it's pretty kludge-y.
<re_irc> <@thejpster:matrix.org> I need to talk to some embassy folks, but it looks like #embassy:matrix.org is invite-only? I tried the link at https://embassy.dev/embassy/dev/index.html but it said "You are not invited to this room."
<re_irc> <@dngrs:matrix.org> https://matrix.to/#/#embassy-rs:matrix.org
<re_irc> <@dngrs:matrix.org> sounds like the docs need updating 🙃
<re_irc> <@firefrommoonlight:matrix.org> Re our DSP lib chat earlier: Does anyone know of a go-to for Hilbert xforming a signal? Could probably hand code. Can't find in CMSIS
<re_irc> <@firefrommoonlight:matrix.org> Could probably translate [this C lib](https://github.com/KushalKQB/ARM-Cortex-M-Hilbert-Transform/blob/master/arm_chilbert_f32.c), which makes use of CMSIS's FFT
<re_irc> <@dngrs:matrix.org> is there an easy way to concat `&str`s without a heap?
<re_irc> <@tholmie:matrix.org> `heapless` `String`? https://docs.rs/heapless/0.7.9/heapless/struct.String.html
<re_irc> <@dngrs:matrix.org> more specifically I'd like to avoid `format!` - my strs are actually all known at compile time
<re_irc> <@dngrs:matrix.org> wait, can I maybe just use `concat!`...
<re_irc> <@tholmie:matrix.org> yeah if it's at compile time I'm sure you can use some sort of proc macro crate or builtin
<re_irc> <@dngrs:matrix.org> meeehhh it only works with literals
<re_irc> <@dngrs:matrix.org> but maybe there's a `const fn`…
<re_irc> <@dngrs:matrix.org> https://github.com/Vurich/const-concat 👀
<re_irc> <@tholmie:matrix.org> you know it's a good crate when it's described as heinous hackery
<re_irc> <@dngrs:matrix.org> right?
<re_irc> <@bugadani:matrix.org> wow that is evil
<re_irc> <@k900:0upti.me> Absolutely horrifying, I love it
<re_irc> <@firefrommoonlight:matrix.org> I have some messy fns to do it
<re_irc> <@firefrommoonlight:matrix.org> You can do it with in-place buffer manipulation
<re_irc> <@thejpster:matrix.org> I want a const path join. concat!(env!("OUT_DIR"), "/file.txt") is incorrect if your path delimiter isn't /
<re_irc> <@tholmie:matrix.org> could you do this in a build script?
<re_irc> <@dngrs:matrix.org> or it could make the case for mandating that `OUT_DIR` ends with the path separator
<re_irc> <@dbrgn:matrix.coredump.ch> I'm thinking about using defmt for an embedded project that will be mostly out in the field, but where we may want to access logs occasionally to view what the system is doing (without attaching a debugger).
<re_irc> <@dbrgn:matrix.coredump.ch> Right now we simply write to the serial output. This works fine, no matter whether a UART receiver is connected or not. We lose messages that were sent while no receiver was connected, but that's probably OK.
<re_irc> <@dbrgn:matrix.coredump.ch> If we'd use defmt-bbq, we could consume the logs from an RTIC task and write them out to serial, right? The main issue right now is probably the lack of a standardized protocol(?), so if we'd use defmt right now and then attach a laptop for debugging in 2 years, we'd have to use today's version of defmt to decode the messages (even if better tools would be available by then). Is that correct? If yes,...
<re_irc> ... are there any plans for stabilization of the formats used?
<re_irc> <@dngrs:matrix.org> I mean, today's `defmt` will also work in 5 years - that's what the `edition` field in `Cargo.toml` is for
inara has quit [Quit: Leaving]
<re_irc> <@dbrgn:matrix.coredump.ch> Yeah, but for 3 different revisions there might be 3 different defmt versions required, if I understand the warning at https://github.com/knurling-rs/defmt/tree/main/print ("There's no stable library API to decode defmt log frames") correctly.
inara has joined #rust-embedded
<re_irc> <@dngrs:matrix.org> that's correct - I'd weigh the effort required to keep those revisions around + scripts to handle different wire formats against having your own logging implementation. Honestly if you're only logging strings and can afford the inefficiency you're probably better off doing just that
<re_irc> <@dngrs:matrix.org> (you could however *also* pin `defmnt` to today's version…)
<re_irc> <@dngrs:matrix.org> (it depends on your requirements really)
<re_irc> <@firefrommoonlight:matrix.org> Yea - breaking changes are a maintenance issue
<re_irc> <@firefrommoonlight:matrix.org> Anecdotally, I'm fine with the breaking defmt etc changes since I don't have a ton of other deps in my projects. I consider defmt critical enough that I'm willing to spend the time keeping it updated in my projects
<re_irc> <@firefrommoonlight:matrix.org> But your concern is valid
<re_irc> <@firefrommoonlight:matrix.org> And yea - if you look at the example boilerplate a year or two ago, it was quite diff from now
<re_irc> <@firefrommoonlight:matrix.org> RTFM dependencies, ITT, RTT etc
<re_irc> <@firefrommoonlight:matrix.org> I'm using the knurling-app-template now, and love it... Just hope it stays stable
<re_irc> <@firefrommoonlight:matrix.org> (Albeit I'd welcome incremental improvements)
<re_irc> <@firefrommoonlight:matrix.org> A few weeks ago, I had to change all my `defmt::info` to `defmt::println` due to a breaking change
<re_irc> <@jamesmunns:beeper.com> Yeah Danilo , I'd probably agree with dngrs (spookyvisiongithub) here. If you're shipping things to the field and it matters, I'd probably recommend keeping a 'cargo vendor' version of your project somewhere safe, and if you'd like to make sure your tools could be backwards-compatible, you could always wrap your logs in a header that states the defmt version so you could support multiple versions.
<re_irc> <@jamesmunns:beeper.com> This is a more common "binary format" vs "plain text format" concern though: plain text will always be plain text, which *should* be readable forever, though you pay the cost of density, and you'll always need to write your own parsers and such to extract content, unless your only use of the messages is to have a human read it
<re_irc> <@jamesmunns:beeper.com> Like, you could also consider switching from the text "ERROR" in your logs to "ERR" a breaking change, of your parser/regex is still looking for "ERROR"! A human wouldn't care, but your tooling might!
<re_irc> <@dngrs:matrix.org> (insert long rant about cmdline tools' output being far too brittle for machine reading here)
<re_irc> <@jamesmunns:beeper.com> Yeah, it depends on your use case!
<re_irc> <@jamesmunns:beeper.com> firefrommoonlight:matrix.org: Which breaking change was that? The move to using env vars to set log level?
bpye7 is now known as bpye
<re_irc> <@firefrommoonlight:matrix.org> I dunno
<re_irc> <@firefrommoonlight:matrix.org> Probably
<re_irc> <@firefrommoonlight:matrix.org> I have env vars
<re_irc> <@firefrommoonlight:matrix.org> They embody one of my biggest linux beefs
<re_irc> <@firefrommoonlight:matrix.org> of relying on hidden state