IlPalazzo-ojiisa has quit [Remote host closed the connection]
emerent has quit [Ping timeout: 260 seconds]
emerent has joined #rust-embedded
<StephenD[m]>
I have learned that if my text section is just the right size, the bss section will overflow the available flash. This doesn't throw a compile-time error like overflowing the text section does, but it does cause my program to behave extremely wackily
<StephenD[m]>
Fun bonus is that whenever I set a breakpoint anywhere weird, my code would start behaving properly in just that area
<spinfast[m]>
You can probably add an assert in the linker script to catch it
<adamgreig[m]>
hm, the linker should definitely error on this
<adamgreig[m]>
are you sure bss is overflowing, rather than the stack?
ian_rees[m] has quit [Quit: Idle timeout reached: 172800s]
stephe has quit [Server closed connection]
stephe has joined #rust-embedded
rmsyn[m] has quit [Quit: Idle timeout reached: 172800s]
Darius has quit [Server closed connection]
Darius has joined #rust-embedded
Abhishek_ has quit [Server closed connection]
Abhishek_ has joined #rust-embedded
inara has quit [Quit: Leaving]
nohit has quit [Server closed connection]
inara has joined #rust-embedded
nohit has joined #rust-embedded
crabbedhaloablut has joined #rust-embedded
sajattack[m]1 has quit [Quit: Idle timeout reached: 172800s]
Lumpio- has quit [Server closed connection]
Lumpio- has joined #rust-embedded
Guest7221 has joined #rust-embedded
<thejpster[m]>
I'll take "Knowledge I wish I had never learned for $300 please Alex"
<thejpster[m]>
the --nmagic flag refers to the "New Magic Number" at the start of a PDP-11 a.out file, as opposed to the "Old Magic Number".
sourcebox[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
<adamgreig[m]>
i swear, everything to do with linkers is like this
<adamgreig[m]>
like "why is it called bss"
* dav1d
guesses bullshit section
<JamesMunns[m]>
> block starting symbol
<dav1d>
close
<JamesMunns[m]>
> Historically, BSS (from Block Started by Symbol) is a pseudo-operation in UA-SAP (United Aircraft Symbolic Assembly Program), the assembler developed in the mid-1950s for the IBM 704 by Roy Nutt, Walter Ramshaw, and others at United Aircraft Corporation.[
<JamesMunns[m]>
lmao
<StephenD[m]>
<adamgreig[m]> "are you sure bss is overflowing,..." <- Yeah I'm pretty sure, just based on the size of `bss + text` in `size` vs how much flash I have. And when I added some more compile options to reduce the size it fixed everything
<StephenD[m]>
If it matters, I'm using a 512KB flash chip, but only the first 384KB I've specified in my memory.x (the last 128KB is for config storage)
<adamgreig[m]>
bss doesn't go in flash, though
<adamgreig[m]>
just rodata, data, text
<StephenD[m]>
Where does bss go then?
<JamesMunns[m]>
StephenD[m]: RAM
<adamgreig[m]>
it's for things that are initialised to zero, so no data for them needs to be stored in flash
<StephenD[m]>
welp. I have no idea what's going on then
<adamgreig[m]>
so it just allocates space for them statically in your sram, and at startup, the core sets all their memory to 0 (and copies the initial data for .data from flash into sram too)
<adamgreig[m]>
if everything is going wacky depending on how much stuff you have allocated it could be stack overflow instead, but it's hard to guess
<JamesMunns[m]>
what are you adding that is increasing .bss?
<JamesMunns[m]>
If you are declaring a large, zero initialized static variable (that goes in bss), but initializing it at startup/runtime, but you end up putting the whole initialization value on the stack to create it, you could stack overflow then
<JamesMunns[m]>
This would happen if you use a large StaticCell or something like that
<StephenD[m]>
I don't think I was stack overflowing since that normally causes a hard fault on my chip
<StephenD[m]>
Whereas I was just seeing extremely strange behaviour
<JamesMunns[m]>
stack overflow wouldn't cause a hard fault until after it corrupts all of your static memory
<JamesMunns[m]>
stack starts at the top of RAM, and grows down towards your global variables
<JamesMunns[m]>
(unless you are using flip-link)
<StephenD[m]>
Ah
<StephenD[m]>
Sounds like a ram issue then
<JamesMunns[m]>
flip-link changes that, it puts all your globals at the top of ram, and the stack just underneath that, so you do get a hard fault when you stack overflow (because it underflows your RAM)
<adamgreig[m]>
on some chips you can get a fault on stack overflow but it generally requires additional setup
<adamgreig[m]>
like enabling an mpu with a guard band, or using the stack limit registers on armv8
<JamesMunns[m]>
adamgreig[m]: you mean thumbv8, or something with an MPU guard page?
<JamesMunns[m]>
ah
<JamesMunns[m]>
lol exactly
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiisa has quit [Quit: Leaving.]
IlPalazzo-ojiis1 has joined #rust-embedded
IlPalazzo-ojiis1 has quit [Ping timeout: 255 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
Hi! Does anyone have any no-std IIR filters they recommend, pure Rust? I am trying not to bring in CMSIS-DSP here because it's a small firmware and CMSIS increases compile times by a lot. Ty!
<firefrommoonligh>
I remember there was a good one some of the guys here recommended a while back, maybe called filter-rs, but I can't find it
<firefrommoonligh>
* I remember there was a good one some of the guys here recommended a while back, maybe called `filter-rs`, but I can't find it. I just tried the [biquad](https://docs.rs/biquad/latest/biquad/) crate, but got surprising results
<firefrommoonligh>
I think that was it!
<firefrommoonligh>
Going to give it a shot
dngrsspookyvisio has joined #rust-embedded
<dngrsspookyvisio>
<firefrommoonligh> "Hi! Does anyone have any no-..." <- does it necessarily? [cmsis-dsp-rs](https://github.com/samcrow/cmsis_dsp.rs) comes with prebuilt code, I don't recall long build times using it
<ryan-summers[m]>
<firefrommoonligh> "I remember there was a good..." <- https://crates.io/crates/idsp is maintained by QUARTIQ and we use it for a lot of really fast DSP
<ryan-summers[m]>
Oh, adam beat me
<ryan-summers[m]>
For context, there was a lot of work that went into characterizing IDSP's trig functions and making them blazingly fast
<firefrommoonligh>
<dngrsspookyvisio> "does it necessarily? [cmsis-dsp..." <- Anecdotally, yes. I use it in a few firmwares, with a light wrapper that uses references instead of pointers etc. Not a bad experience, but requires a specific LLVM version installed or you get nasty linker errors, and multiplies compile time
<firefrommoonligh>
Great package with lots upsides, but those are the downsides I've seen
<dngrsspookyvisio>
Fair
<dngrsspookyvisio>
<ryan-summers[m]> "https://crates.io/crates/idsp is..." <- it looks really cool! unfortunately what I need most are FFTs
<firefrommoonligh>
So, noob question here about IDSP: It uses, for IIR, 5-len array of BA coefficients. I've worked with coefficients in 3 formats recently: BA of 4 coefficients, SOS of 6 coefficeints, and a modified version of the latter to turn it into 5 by dividing each by the fourth with negations on a few
<firefrommoonligh>
Is there an easy way to get the 5-len BA coefficients from one of those formats, or from scipy?
<firefrommoonligh>
dngrsspookyvisio: Yea I would use CMSIS for that
<firefrommoonligh>
(or fork/PR IDSP for extra credit...)
<adamgreig[m]>
firefrommoonlight: their Vec5 is [b0, b1, b2, -a1, -a2] where a0 is implicitly 1, it's basically the SOS 6 coefficients normalised as you describe at the end of your sentence, from what I can see
<firefrommoonligh>
(I think Scipy, which I've been using to generate the coeffs, uses a nonstandard format for the BA output; CHATGPT seems to use the 5-value format...)
<firefrommoonligh>
adamgreig[m]: Great; ty!
<adamgreig[m]>
note a1 and a2 are negated!
<firefrommoonligh>
Interesting; so maybe same format as CMSIS
<adamgreig[m]>
yes, looks like it's exactly the same as cmsis
<dirbaio[m]>
make sure embassy-net feature nightly is enabled, otherwise it doesn't implement embedded-io-async
<adamgreig[m]>
that reminded me about wanting to plot the user count in here, but it seems I can only download a list of joins and leaves, but sum(joins)-sum(leaves) is about a thousand people more than are currently here :/
<andodeki2[m]>
embassy-net = { version = "0.2.1", features = ["nightly","tcp","proto-ipv4","medium-ethernet","dhcpv4", "dns", "log", "udp", "medium-ip" ], optional = true }
<dirbaio[m]>
if that still doesn't fix it, check that the versions of embassy-net and rust-mqtt you're using use the exact same embedded-io-async version
<xiretza[cis]>
adamgreig[m]: fwiw at least my homeserver seems to have split slightly, I have never seen any IRC puppets in here afaict
<adamgreig[m]>
what! do their messages get through?
<xiretza[cis]>
nope
<agg>
so you can't see this?
<adamgreig[m]>
almost as bad as mastodon 😆
<xiretza[cis]>
agg: ah actually I guess catircservices fixed that, I remember the libera bridge being broken for me in here
<adamgreig[m]>
curious
<adamgreig[m]>
well I'm glad it's working now
<adamgreig[m]>
but yea, I suspect the intense bridge joins/parts has confused my count
<adamgreig[m]>
could probably try and make the software smarter by tracking specific users joining and leaving and see which users it thinks are still here
<adamgreig[m]>
what on earth happened in july 21 though
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]
Guest7221 has left #rust-embedded [Error from remote client]
IlPalazzo-ojiisa has joined #rust-embedded
IlPalazzo-ojiis1 has quit [Read error: Connection reset by peer]
Guest7221 has joined #rust-embedded
notgull has quit [Ping timeout: 255 seconds]
notgull has joined #rust-embedded
notgull has quit [Ping timeout: 255 seconds]
notgull has joined #rust-embedded
zaven[m] has joined #rust-embedded
<zaven[m]>
Could use a little help... I'm using HAL for stm32f103rb, set up i2c following the example but running an i2c scan hangs waiting for a start condition. looks like start condition is never generated. Could there be something missing from the example? My old stmduino based C code works file. Example I am working off of is here: https://github.com/stm32-rs/stm32f1xx-hal/blob/master/examples/i2c-bme280/src/main.rs
IlPalazzo-ojiis1 has joined #rust-embedded
IlPalazzo-ojiisa has quit [Read error: Connection reset by peer]
IlPalazzo-ojiis1 has quit [Ping timeout: 255 seconds]
IlPalazzo-ojiisa has joined #rust-embedded
<adamgreig[m]>
Have you got pull-ups on the i2c lines?
bpye has quit [Ping timeout: 240 seconds]
bpye has joined #rust-embedded
jr-oss has quit [Server closed connection]
jr-oss has joined #rust-embedded
<firefrommoonligh>
Classic adam
<firefrommoonligh>
That's like asking if you enabled the RCC for STM32 periph programs
<firefrommoonligh>
And is right a remarkable amount of the time!
<firefrommoonligh>
s/programs/problems/
<zaven[m]>
The problem appears when I use rust and the HAL with this board. My old stmduino based C code works fine (same board)
<zaven[m]>
Ah ok I got it, the old build was using the HSI. There's a problem with the HSE on this board.
<zaven[m]>
Thanks for the dialogue, always helps to trigger new thoughts on a weird debug.