<haobogu[m]>
Hi everyone. I found that defmt + defmt rtt make code size quite large. I tried to replace defmt rtt using an empty demt global logger implementation, then my code size was reduced from 96kb to 60kb. I’m wondering is it normal that defmt rtt uses so much flash?
<thejpster[m]>
Doesn’t sound normal. Are you building in release profile, and did you use Debug2Format anywhere?
<thejpster[m]>
Note to all - I’m at the Leadership Summit next week. Do let me know if you have any questions or burning issues.
<Darius>
36k of flash is massive
<Darius>
even a full on printf implementation shouldn't be that large
<M9names[m]>
is it possible that it's mostly panic messages, and an empty defmt impl is sufficient for the compiler to optimise them away?
<Lumpio->
For that kind of size changes it might even be possible to see if it's a bunch of text taking up the space by just looking at the binary in a text editor
<Lumpio->
If they're that big that is.
<RobertJrdens[m]>
<thejpster[m]> "does that enable double precisio..." <- the `d` is for double.
<thejpster[m]>
d16 means it can hold 16 doubles, or 32 singles, but that doesn’t mean it can do maths on them
<thejpster[m]>
The M4 has a VFP4-SP-D16 if I remember correctly. Single precision but can hold 32 doubles.
badyjoke[m] has joined #rust-embedded
<badyjoke[m]>
Hello ! Do you guys know if it's supported to use "chipDescriptionPath" in the launch configuration of probe-rs extension ?
<badyjoke[m]>
* probe-rs extension for VSCode ?
<thejpster[m]>
s/32/16/
<RobertJrdens[m]>
<thejpster[m]> "d16 means it can hold 16 doubles..." <- Then it's the armv8 that implies double insns. https://rust.godbolt.org/z/vheG5neKK
<RobertJrdens[m]>
We did have this discussion ~half a year ago, IIRC. Maybe it's worth writing this down somewhere...
<RobertJrdens[m]>
n.b. Is there a way to suppress the warnings about the non-rustc target-feature? The only risk appears to be that the features might mean something else when and if it becomes a rustc feature. I can't think of a scenario where that would be the case.
<thejpster[m]>
I'm trying to write it down this time :)
<thejpster[m]>
I have a branch where I'm updating the target docs, but then I fell down this hole of the FPU support being totally random
<RobertJrdens[m]>
Yeah. I have little notes in several .cargo/config.toml that I don't understand anymore after a few weeks.
<RobertJrdens[m]>
Great. Would be cool to have a similar table for m4, m7. For the latter it would at least be +fp-armv8d16 as well (according to my "reasearch" which I unfortunately can't reproduce anymore...)
<thejpster[m]>
well, fpv5-d16, technically
<thejpster[m]>
the m4 is a vfp4
<thejpster[m]>
and yes, the v moves, because one is Vector Floating Point 4, and the other is Floating Point Version 5
<thejpster[m]>
arm, bless their hearts
<thejpster[m]>
or fvp5-sp-d16, because you can get an M7 with no FPU, single precision, or double precision
<thejpster[m]>
it did have a little low power PRU though, which could handle external edges and do some basic data reception before waiting up the bigger M4 core. Overall we got about 10 years on a single cell, running an LF field receiver.
<diondokter[m]>
Cool!
<thejpster[m]>
hmm, I could redesign the Neotron Pico to use an STM32U0 instead of the Dallas RTC.
<thejpster[m]>
I could. But obviously I won't.
<diondokter[m]>
Haha, but yeah instead of an RTC you could have a more power efficient RTC that also is a fully fledged mcu :D
<thejpster[m]>
well it would let me delete the STM32F030. And possibly the low-power 3.3V LDO I use to run it.
<thejpster[m]>
just run it from the coin cell, or the main 3.3V rail once that is up
<diondokter[m]>
What's the STM32F030 used for?
<thejpster[m]>
power and reset button debouncing, voltage rail monitoring, PS/2 interface, extra I2C bus, extra UART
<thejpster[m]>
power supply state machine
<diondokter[m]>
Right, yeah the U0 would be pretty good at that
<thejpster[m]>
it's an SPI device
<thejpster[m]>
so the Pico just sends it commands. Oh, it drives the PC speaker too. Basically my Pico was out of pins, so a bunch of stuff got put on the STM32
<thejpster[m]>
£1.90 at digikey for the cheapest U0.
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
not cheap! 🤔
<diondokter[m]>
STM announced it'd be $0.68 @ 1k units
<thejpster[m]>
hey, that is RTC money
<diondokter[m]>
So... Not sure. Maybe the price will drop?
<diondokter[m]>
But maybe that's the sales price STM does
<thejpster[m]>
1% internal 16 MHz RC, or you can use a 32k crystal to trim it to 0.25%
<thejpster[m]>
so you will still need a 32K crystal for timekeeping
<diondokter[m]>
Sure, but the RTC we used also needed that anyways
<dirbaio[m]>
it has BDMA+DMAMUX, huh. I thought they'd kill BDMA for good in favor of GPDMA but no
<dirbaio[m]>
at least it's not yet another new DMA controller 🤣
<JamesMunns[m]>
At least for STM32, the new chips tend to be expensive when they first come out, and steadily drop over the next 2-3 years. Probably just a volume/process thing
<JamesMunns[m]>
C0 is/was more expensive than G0 recently, even though C0 is the cost-down'd version of the G0, but I expect it'll drop as they start hitting volumes
<haobogu[m]>
<thejpster[m]> "Doesn’t sound normal. Are you..." <- yes in release profile and removed all Debug2Format. I tried to replace panic-probe(uses print-defmt feature) by panic-halt, the binary size reduced to about 65kb. Do you have any clue on it? thanks very much!
explodingwaffle1 has joined #rust-embedded
<explodingwaffle1>
c0 doesn’t even have a VBAT domain iirc so it’s probably a non starter for super low power stuff
<haobogu[m]>
<haobogu[m]> "Hi everyone. I found that defmt..." <- I got some progress on it. I removed panic-probe which uses defmt, used panic-halt instead. The binary size reduced a lot as well(about 20KB). So I suspect that panic messages might take a lot of flash in my program.
<dirbaio[m]>
you can set panic_immediate_abort to slim it down further (nightly-only)
<haobogu[m]>
just tried panic_immediate_abort, saved about 4KB flash even more 👍️
IlPalazzo-ojiisa has quit [Quit: Leaving.]
TomB[m] has joined #rust-embedded
<TomB[m]>
<dirbaio[m]> "at least it's not yet another..." <- I'm doing some stuff with zephyr and stm32 and was a bit mind boggled by the mdma/dma/bdma madness
<TomB[m]>
compared to the simplicity that is nxp's edma anyways
<TomB[m]>
i take it there's yet another dma they have named gpdma, or is that simply the dma 1/2 peripherals?
Lister has joined #rust-embedded
<Lister>
hey, is anyone here familiar with using he BME280 crate? does it work with no_std
marmrt[m] has joined #rust-embedded
<marmrt[m]>
it has a with_std feature, so it should be no_std by default
<Lister>
oh. I didn't see this
<Lister>
thanks
<Lister>
marmrt[m]: Also, I've noticed that in the documentation, the defenition for measurements is not mutable. Do I have to rewrite the output of the bme280 to measurement every time I want to take a new measurement?
<marmrt[m]>
I'm not actually familiar with the BME280, I just looked at the feature list
Lister has quit [Ping timeout: 256 seconds]
wyager[m] has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
Lister has joined #rust-embedded
starblue has quit [Ping timeout: 260 seconds]
Lister has quit [Ping timeout: 252 seconds]
Lister has joined #rust-embedded
corecode has joined #rust-embedded
Lister has quit [Ping timeout: 255 seconds]
starblue has joined #rust-embedded
<adamgreig[m]>
hi @room, it's meeting time again! agenda is https://hackmd.io/TwDW4ulSQZu8H6bLs3MjPA, please add anything you'd like to announce or discuss and we'll start in a few minutes
bartmassey[m] has joined #rust-embedded
<bartmassey[m]>
Won't be able to attend again this week. Apologies. I will be back next week.
<adamgreig[m]>
ok, let's start! just one announcement from me, rust 1.77 is out thurs with a few interesting features for embedded like c-strings, a new lint any time you take &mut to a static mut, and core::net stable
<adamgreig[m]>
presumably the new lint will cause some anguish for everyone who hasn't been listening to James Munns's campaigning :P
<adamgreig[m]>
any other announcements from anyone?
<JamesMunns[m]>
Shame there's no pitchfork and torch emoji
<JamesMunns[m]>
RustNL talks and workshops got announced (shameless stuff plug for both)
<JamesMunns[m]>
Lots of other cfps open now too, would be good to see more embedded talks so over the world
<JamesMunns[m]>
Oxidize, RustConf, RustFest Vienna, probably more
<dirbaio[m]>
i'm still salty about the static mut lint :D
<JamesMunns[m]>
No comment
<adamgreig[m]>
the only other thing I had for this week is this new PR on cortex-m-rt about making HardFault take `&mut ExceptionFrame` so it can be modified in-place, https://github.com/rust-embedded/cortex-m/pull/515
<adamgreig[m]>
I haven't had a chance to look over it in detail yet though, and since it's also a breaking change and we were considering removing ExceptionFrame (or at least making it non-default) in the next breaking release anyway, not sure how it fits in
<adamgreig[m]>
not sure it even works but I guess we do bounce into the user handler with the stack pointer in r0 so I guess you can just modify it in-place...
<thejpster[m]>
Sounds unsafe, lol
<thejpster[m]>
Does anyone know if you can write the macro to take either signature?
<adamgreig[m]>
yea, wildly
<thejpster[m]>
To avoid breakage
<adamgreig[m]>
the macro already accepts having the argument or not, so I don't see why it couldn't handle having either mutability
<thejpster[m]>
I wanted to talk a bit about Cortex m as well
<adamgreig[m]>
the hardfault handler must already be unsafe so I guess that's covered
<adamgreig[m]>
go for it
<thejpster[m]>
The target cpu definitions are completely bananas
<thejpster[m]>
Is that rustc or llvm and how do we fix it?
<adamgreig[m]>
target-cpu is llvm I believe
<thejpster[m]>
I convinced Erik at Linaro that it was an issue. Maybe I can get them to look in to it
<adamgreig[m]>
as in the defaults for cortex-m7 etc aren't what you want?
<thejpster[m]>
They aren’t what anyone wants
<thejpster[m]>
Especially on the soft float target
<adamgreig[m]>
is it mainly the fpu stuff? iirc the cortex-m7 target sets up different optimisations to account for the dual-issue cpu pipeline too, which presumably is good
<thejpster[m]>
Well I assumed it did that too
<thejpster[m]>
But I have no evidence it actually does
<adamgreig[m]>
interesting
<adamgreig[m]>
I feel like at some point there was some godbolt links here showing some differences but not sure I can find them...
<thejpster[m]>
I need to lock an arm expert and an llvm expert and a rustc expert in a room
<adamgreig[m]>
step one: become an expert in arm, llvm, and rustc :p
<adamgreig[m]>
the fpu stuff isn't helped by arm's generally confusing and inconsistent naming strategy for the embedded fpus
<thejpster[m]>
Step one is annoy linaro until they do it for me
<thejpster[m]>
Ugh totally
<thejpster[m]>
See vfp4 vs fvp5
<adamgreig[m]>
do we have actually wrong codegen atm or just that it's hard to get off the default-but-at-least-works path?
<adamgreig[m]>
yea indeed
<adamgreig[m]>
and then llvm's naming on top of that
<adamgreig[m]>
and specific mcu manufacturers then not being explicit about how they configured their cores
<thejpster[m]>
I would argue Cortex-m7 on the eabi target should not emit FPU instructions
<thejpster[m]>
And it’s hard to turn them off because features are additive
<thejpster[m]>
M7 on eabihf not using f64 is still an issue, but it won’t break anything
<thejpster[m]>
This all came about because I wanted to update the target docs
<dirbaio[m]>
thejpster[m]: wtf it does that? that's so broken
<thejpster[m]>
The target picks an architecture and some features, AFAIK
<thejpster[m]>
Specifying your own extras is unstable
<thejpster[m]>
Note: d32 is about storing doubles, not doing maths on doubles.
<thejpster[m]>
-d32 just says you only have half the FPU registers
<M9names[m]>
What's blocking stabilisation?
<thejpster[m]>
General apathy towards stabilising things? Lack of a push from users? I don’t know.
<dirbaio[m]>
turbo bikeshedding
<thejpster[m]>
If there was a t-no-std, they could perhaps push it more easily than we can
<M9names[m]>
It doesn't affect most users so "no push" is pretty likely
<adamgreig[m]>
and it's mostly just stuff rust passes directly to llvm?
<M9names[m]>
Right. Which theoretically could change under rustc
<thejpster[m]>
If I had an M7 with a DP FPU I’d want to use it. So this is where this started - documenting what exists and how to make optimal use of it
<adamgreig[m]>
even if you didn't use double precision floats you'd want to be able to access all the fpu registers huh
<thejpster[m]>
Right now the instructions I have seem stupid because the target-cpu features are too aggressive
<adamgreig[m]>
even for m7?
<thejpster[m]>
yes because it turns on FPU on the eabi target
<thejpster[m]>
But m55 turns on mve and FPU
crabbedhaloablut has quit []
ithinuel[m] has quit [Quit: Idle timeout reached: 172800s]
<adamgreig[m]>
is FPU optional on cm7?
<thejpster[m]>
Anyway. If anyone sees an arm expert, a rust expert and an llvm expert walk into a bar, tell them I want to buy them a drink
<thejpster[m]>
adamgreig[m]: Yup
<adamgreig[m]>
ah, so it is, the landing page wasn't clear but the datasheet sure is
<adamgreig[m]>
so current conclusion is "target-cpu enables features that might actually be optional, target-feature makes rustc give scary messages even though it does let you use the dp fpu, the documentation for doing so is lacking"?
crabbedhaloablut has joined #rust-embedded
<M9names[m]>
Which M55 is for sale? I went looking and only found "special customers can get samples" chips, not stocked at any distributor
<thejpster[m]>
Renesas
<JamesMunns[m]>
thejpster[m]: Amanieu?
<thejpster[m]>
JamesMunns[m]: Buying one drink is cheaper USB three, sure
<thejpster[m]>
s/USB/than/
<JamesMunns[m]>
thejpster[m]: Better buy three drinks just in case
burrbull[m] has joined #rust-embedded
<burrbull[m]>
Last days I've found esp-hal guys use variant to get round unsafe on fieldwriter bits generated by svd2rust. This is hole and I don't know how to fix it nice without adding advanced marker trait for all enums. variant should not be implemented on fields without enums. https://github.com/esp-rs/esp-hal/issues/1304
<thejpster[m]>
M9names[m]: Wait. I might be mixed up with Cortex-R52. I did a lot of work on that lately. I’ll come back to you.
<thejpster[m]>
Oh yeah, that’s a thing. We got Aarch32 Armv8-R working in Ferrocene.
ithinuel[m] has joined #rust-embedded
<ithinuel[m]>
hello 👋 what’s the question about M55?
<JamesMunns[m]>
ithinuel[m]: Where can we buy one without an NDA and a field rep?
<thejpster[m]>
ithinuel[m]: Can I buy one
<ithinuel[m]>
🤔 let me check a few names I have in minds
<thejpster[m]>
Is there a cortex-r-rt crate? Should there be?
<thejpster[m]>
I don't know if they generally boot the same like Cortex-M does. For my demo I wrote a few lines of asm from scratch to drop it into _start, and ignored the problem of global variables.
<AdamHott[m]>
<ithinuel[m]> "Something like this: https://www..." <- This one needs an approval from the Alif folks, I got a guy who will approve the sale of 1 to me but I don't have the money
<NiaLinaLunaStorm>
(yes, there are more things to fix but that's the first one I picked)
<NiaLinaLunaStorm>
in the end this is supposed to transmit a number of buttons and pots via USB HID
GrantM11235[m] has joined #rust-embedded
<GrantM11235[m]>
Is PA1 and PA2 supposed to be a digital input or an analog input? It looks like you are configuring them as analog but trying to use them as digital
<GrantM11235[m]>
Try changing into_analog to into_input
<NiaLinaLunaStorm>
analog input (pots connected)
<GrantM11235[m]>
In that case, you can't use dyn InputPin, that's only for digital inputs
<NiaLinaLunaStorm>
that thought I had too but I couldn't figure out what to use instead
<NiaLinaLunaStorm>
already tried a few things but ig I don't really understand rust stuff yet
<NiaLinaLunaStorm>
GrantM11235[m]: is that easier? should I do that?
<NiaLinaLunaStorm>
how much difference is there? how much would I have to rewrite?
<NiaLinaLunaStorm>
I'm completely new and flexible (no legacy) so if there's a better way, I'd like to take that before I need to possibly turn around in the future
barnabyw[m] has joined #rust-embedded
<barnabyw[m]>
well right now most of your code is framework setup and boilerplate which would all need changing
<barnabyw[m]>
fwiw I’m also fairly new to rust (especially on embedded devices) and have had nothing but good experiences with embassy-stm32
<GrantM11235[m]>
Yes, I think I would recommend it. As barnabyw said would need to rewrite the setup and boilerplate code, but there is a lot less boilerplate required. Once you have everything set up, I think embassy-stm32 is easier
<NiaLinaLunaStorm>
oki
<NiaLinaLunaStorm>
then I'll look at that
<NiaLinaLunaStorm>
better change early on rather than on a big code base
<NiaLinaLunaStorm>
yes, just that it shouldn't be a keyboard but an events input (USB specs with all the different HID modes and so on is so confusing)
<NiaLinaLunaStorm>
do I need that otg fs setup? my device doesn't need usb otg stufff
<GrantM11235[m]>
USB_OTG_FS is just what stm calls the usb peripheral
<NiaLinaLunaStorm>
like the above line gets terminated with ;
<GrantM11235[m]>
I think it is just so that the use embassy_stm32::rcc::*; is confined to that block
<barnabyw[m]>
those create a temporary scope for setting up the clocks, and allows short forms of all the items required for that to be imported without contaminating the namespace for the rest of the program
<NiaLinaLunaStorm>
so I use a 16kHz crystal for the hse, I've already changed the config thing which has the frequency in it. do I also need to mess with the frequency deviders? if yes, how do I know which one to change?
<barnabyw[m]>
plain scopes like that are really useful in rust for a variety of things, doing quarantined glob imports like this is one of them
<NiaLinaLunaStorm>
oki, thanks
<GrantM11235[m]>
16MHz, not kHz, I assume?
<barnabyw[m]>
for clock configuration I recommend downloading STM’s cubeIDE and using the clock configuration GUI to find pre/postscaler values which create all the correct clock values you need
<NiaLinaLunaStorm>
GrantM11235[m]: yes
<barnabyw[m]>
in this case you can probably get away with using DIV2 for the prediv rather than DIV1, as you’re doubling the XTAL frequency
<barnabyw[m]>
but for anything more complicated, the cubeIDE tool is really useful, especially if you end up using more powerful families than the f1 with very complex clock systems
<NiaLinaLunaStorm>
will probably use a different family for the next project... so good to know
<NiaLinaLunaStorm>
(or rather next iteration cause this thing has a bunch of hw issues)
<barnabyw[m]>
sounds good, there’s little reason to use the old, weird f1 family any more
<NiaLinaLunaStorm>
I can't find that XTAL on here
<barnabyw[m]>
oh that was just referring to the crystal frequency, sorry
<GrantM11235[m]>
I never figured out how to install cubeIDE, so I just stare for a while at the clock tree diagram in the data sheet (page 93) 😅
<barnabyw[m]>
HSE in STM language (high-speed external)
<NiaLinaLunaStorm>
barnabyw[m]: yeah, I got that
<barnabyw[m]>
GrantM11235[m]: what operating system are you using? on kubuntu I could install the flatpak really easily, the text is just tiny because high DPI screen
Lister_ has joined #rust-embedded
<NiaLinaLunaStorm>
NiaLinaLunaStorm: I think I've figured it out