Urhengulas[m] has quit [Quit: Idle timeout reached: 172800s]
vancz has quit []
vancz has joined #rust-embedded
NiaLinaLunaStorm has quit [Quit: Idle timeout reached: 172800s]
IlPalazzo-ojiisa has joined #rust-embedded
starblue has quit [Quit: WeeChat 3.8]
barnabyw[m] has quit [Quit: Idle timeout reached: 172800s]
Foxyloxy_ has joined #rust-embedded
Foxyloxy has quit [Ping timeout: 252 seconds]
<fuse117[m]>
does anyone have experience using the Cortex-Debug with gdb in VSCode while also using defmt and defmt-rtt. the console outoput is garbled. if i switch to rtt-target instead, it works.
<diondokter[m]>
Yeah, cortex-debug doesn't know about defmt
<diondokter[m]>
Defmt is a special protocol. It's not just sending text
<fuse117[m]>
that is what i thought
<fuse117[m]>
* i thought, but wasn't completely sure
osbj_nova[m] has quit [Quit: Idle timeout reached: 172800s]
TrevorRHClarke[m has joined #rust-embedded
<TrevorRHClarke[m>
anyone have an example of using stm32f1xx_hal::dac ?
brutality228[m] has joined #rust-embedded
<brutality228[m]>
I started learning rust, but I know c++
<brutality228[m]>
How to use life times?
<JamesMunns[m]>
Hey brutality228, you might have the best luck looking at the material here: https://www.rust-lang.org/learn
<JamesMunns[m]>
there are a lot of resources for learning Rust, it's worth starting with the basics even if you are an experienced programmer, as some of the concepts are slightly different, and it can be hard to do more complex things if you don't end up understand things like ownership and Rust's rules.
<JamesMunns[m]>
The Rust book is very good, I also have heard very good things about rustlings which is more exercise driven: https://github.com/rust-lang/rustlings
<brutality228[m]>
I like rust ownership concept
<JamesMunns[m]>
Once you're comfortable in Rust "on the desktop", we can add some more resources that will help you get up to speed with embedded Rust as well!
<brutality228[m]>
It is like std::move
<JamesMunns[m]>
sort of! I'm not an expert in C++, though definitely be careful about saying things like "X in Rust is like Y in C++", there are usually subtle and important differences! That's why I say it's worth going through the Rust teaching material, even if you are experienced. It's easy to jump ahead and miss the important differences.
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
<brutality228[m]> "How to use life times?" <- Don't, unless you get a compile error. Then do some digging with the aim of fixing that error.
<firefrommoonligh>
You generally only need to specify lifetimes when storing references in structs and similar. This can be useful, or you can use a style that avoids this.
<firefrommoonligh>
You will get a compile error if you need to specify a lifetime, and fail to due so. You will get a clippy (or compiler?) warning if you specify a lifetime that is not required
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
Honestly, I've never found an explanation of lifetimes that I really understood. I can deal with them in some way, but it's often just try and error.
<sourcebox[m]>
James Munns: In your talk about postcard you said that the keys are not serialized. What happens e.g. when a serialized struct is stored to flash and reloaded with a new firmware that has added some fields to it? Will it return an error?
<dirbaio[m]>
IANJ (I Am Not James), but I think for raw postcard it can error or silently return wrong data. for postcard-rpc it'll error because of the schema hash.
IlPalazzo-ojiisa has quit [Quit: Leaving.]
<JamesMunns[m]>
yeah, that's correct. if you add fields, it'll probably ignore them IF they are at the end, but if they are in the middle it'll just corrupt the messages.
<sourcebox[m]>
In my case, I store a struct with application preferences. Ideally, all non-existing keys should be set to a default.
<JamesMunns[m]>
or rather - if you add fields, serde will fail either because it gets confused or run out of data
<sourcebox[m]>
I would just append the new fields at the end.
<JamesMunns[m]>
yeah, postcard has no way of saying "oops out of data use default"
<sourcebox[m]>
I always thought that serde would ignore non-existing keys e.g. when using JSON.
<JamesMunns[m]>
keys literally don't exist in postcard data
<JamesMunns[m]>
so there are no ways to tell what keys are there or not
<JamesMunns[m]>
at least if you mean "keys" as in "fields of a struct"
<sourcebox[m]>
Doesn't serde require some kind of keys?
<JamesMunns[m]>
no - that's what makes postcard a non self describing format
<JamesMunns[m]>
struct A { x: 1u8, y: 2u16, z: 3u32 } is serialized to the wire as [1, 2, 3]
<sourcebox[m]>
But serde passes them to postcard which just ignores them?
<JamesMunns[m]>
yep
<sourcebox[m]>
Because with JSON, the output contains the field names.
<sourcebox[m]>
And you can redefine them with attributes.
<JamesMunns[m]>
correct, serde has keys, but postcard does not.
<JamesMunns[m]>
(and redefining them breaks postcard)
<JamesMunns[m]>
because serde doesn't just rename them, it does weird different things on the serialization and deserialization to "touch up" the ser/de process.
<JamesMunns[m]>
(maybe not rename? but definitely things like flatten)
<brutality228[m]>
<sourcebox[m]> "Honestly, I've never found an..." <- Can u send me that
<sourcebox[m]>
brutality228[m]: Hmm, what should I send you?
<brutality228[m]>
sourcebox[m]: Explanation of lifetimes in rust
<sourcebox[m]>
brutality228[m]: Just google for "rust lifetimes", that's essentially what I did. Plenty of results, but I've never found one really good.
<brutality228[m]>
sourcebox[m]: OK,sorry for asking
<sourcebox[m]>
brutality228[m]: No need to excuse, I just don't have a better answer.
<JamesMunns[m]>
Just noting again: if you are new to Rust brutality228, I would not focus on learning lifetimes. You can pretty much ignore them for a while, and they will make a lot more sense when you understand more of the language.
<JamesMunns[m]>
like, I would try and go through the material I sent you, build some stuff ignoring lifetimes as much as you can, and learn them when you are "forced" to.
<brutality228[m]>
JamesMunns[m]: I made a List struct successfuly
eddie1o[m] has quit [Quit: Idle timeout reached: 172800s]
<JamesMunns[m]>
(or rather, don't try to learn lifetimes FIRST. learn the other stuff, it will make lifetimes make more sense).
<brutality228[m]>
Why rust has many types of strings?
<sourcebox[m]>
You mean &str and String?
<brutality228[m]>
sourcebox[m]: No
xiretza[cis] has joined #rust-embedded
<xiretza[cis]>
brutality228[m]: I think you may have misread, sourcebox originally said "I've never found an explanation", i.e. they don't have a good explanation they can give you
kit[m] has joined #rust-embedded
<kit[m]>
If there's one thing I would recommend, it's that you should avoid trying to make your own datastructures when learning Rust
<sourcebox[m]>
brutality228[m]: Then things like OsString?
<brutality228[m]>
Yes
<JamesMunns[m]>
because in Rust `String` and `&str` are always valid UTF-8, and OS strings are not necessarily
<brutality228[m]>
Cstr and '&static str
<JamesMunns[m]>
most operating systems don't require utf-8
<sourcebox[m]>
OsString e.g. is platform dependent
<brutality228[m]>
JamesMunns[m]: Thanks
<JamesMunns[m]>
and strings in rust are not null terminated, like strings in C
<JamesMunns[m]>
so OsString matches whatever OS you are running on, and Cstr is null terminated strings like C has.
<brutality228[m]>
JamesMunns[m]: Thanks
sajattack[m] has joined #rust-embedded
<sajattack[m]>
are there any good tools for no_std perf profiling? specifically like something that dumps a log that I can convert to a flamegraph on a pc
<JamesMunns[m]>
I don't know any cheap ones :p
<JamesMunns[m]>
There are expensive professional tools like JTrace, Segger Ozone, and Lauterbach tools (very expensive). There is also some tooling for using ITM, that's what `rtic-scope` was aiming to do AFAIR
<JamesMunns[m]>
* (very expensive, not rust specific). There
<JamesMunns[m]>
but that's like offering you a cadillac or some sticks to build it yourself.
<brutality228[m]>
In rust when Box will be deallocated defines in compile time?
<PhilMarkgraf[m]>
I am updating a driver to embedded-hal 1.0 and am having difficulties with the matching version of embedded-hal-mock. The driver is given ownership of the the i2c::I2c device, so in test contexts the driver owns and eventually destroys the mock. The current version of embedded-hal-mock has added a check to... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/vhSkUnUJLzOPsgaNvYeIozwk>)
<JamesMunns[m]>
brutality228[m]: Also a heads up brutality228 - this isn't a general Rust room, this room is specifically for embedded systems discussions.
<Henk[m]>
brutality228[m]: Any value is dropped once it goes out of scope, that at the end of a function or scope block (right before the `}`). If a `Box` goes out of scope, it's heap allocation will be freed. Same goes for `Vec`. You can use `std::mem::drop` to explicitly drop something, or `core::mem::drop` if you're in a `no_std` context
JNadalRodz67 has joined #rust-embedded
JNadalRodz67 has quit [Write error: Broken pipe]
JNadalRodz92 has joined #rust-embedded
JNadalRodz has joined #rust-embedded
JNadalRodz has left #rust-embedded [#rust-embedded]
JNadalRodz92 has quit [Quit: Client closed]
Amit[m] has quit [Quit: Idle timeout reached: 172800s]
Danilo[m] has joined #rust-embedded
<Danilo[m]>
<PhilMarkgraf[m]> "I am updating a driver to..." <- > <@shakencodes:matrix.org> I am updating a driver to embedded-hal 1.0 and am having difficulties with the matching version of embedded-hal-mock. The driver is given ownership of the the i2c::I2c device, so in test contexts the driver owns and eventually destroys the mock. The current version... (full message at
<TomB[m]>
<JamesMunns[m]> "oh wow I didn't realize this..." <- I noticed it last time I used probe-rs help, but didn't try it yet, I guess it'd be a sampling profiler? Did you end up trying it?
<TomB[m]>
Actually really neat, I keep thinking I want to try and setup a probe-rs frontend program for Zephyr... so tired of the esoteric tools (particularly the vendor tools) that kind of work, kind of don't work
<TomB[m]>
and profiling + rtt logging would be pretty amazing to have out of the box
<dirbaio[m]>
it samples PC, yes
<TomB[m]>
e.g. instead of pyocd/openocd/linkserver/nrf/jlink/whatever...
<TomB[m]>
very nice
<TomB[m]>
* dirbaio: very nice
<TomB[m]>
does that work only on arm them at the moment or does it work more generally across archs?
<TomB[m]>
Support all the esoteric archs in Zephyr has its fun "quirks"
<TomB[m]>
* across archs? e.g. riscv and xtensa in particular
<TomB[m]>
s/Support/Supporting/
thejpster[m] has joined #rust-embedded
<thejpster[m]>
<fuse117[m]> "does anyone have experience..." <- There’s a probe-rs VS Code plugin such lets you debug, and read defmt logs
vollbrecht[m] has quit [Quit: Idle timeout reached: 172800s]
<PhilMarkgraf[m]>
<Danilo[m]> "> <@shakencodes:matrix.org> I am..." <- Done! - I think I have a solution for my problem. I'm going to push the failing creation into the input parameter that has potential illegal state. This would mean that the driver's new is no longer fallible, which eliminates the odd case for the mock.
bartmassey[m] has quit [Quit: Idle timeout reached: 172800s]
AdamHott[m] has quit [Quit: Idle timeout reached: 172800s]
NickStevens[m] has quit [Quit: Idle timeout reached: 172800s]
romancardenas[m] has quit [Quit: Idle timeout reached: 172800s]
bpye6 has joined #rust-embedded
dreamcat4 has quit [Read error: Connection reset by peer]
stephe has quit [Read error: Connection reset by peer]
seds has quit [Ping timeout: 256 seconds]
stephe has joined #rust-embedded
dnm_ has joined #rust-embedded
dnm has quit [Read error: Connection reset by peer]
dnm_ is now known as dnm
seds has joined #rust-embedded
dreamcat4 has joined #rust-embedded
bpye has quit [Ping timeout: 268 seconds]
bpye6 is now known as bpye
ivche has quit [Quit: %bye%]
ivche has joined #rust-embedded
wose has quit [Ping timeout: 256 seconds]
wose has joined #rust-embedded
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
<TomB[m]> "does that work only on arm..." <- it works on all esp32 so xtensa + riscv should be g2g
<vollbrecht[m]>
ah you were talking about the profiling in particular?
<TomB[m]>
profiling in particular, but I suppose also rtt for output (would be cool to have bidirection rtt for zephyr's shell, I could probably work it out with probe-rs and a custom front end cli tool)
<TomB[m]>
* profiling in particular, but I suppose also rtt for output (would be cool to have bidirection rtt for zephyr's shell, I could probably work it out with probe-rs and a custom front end cli tool
<TomB[m]>
* profiling in particular, but I suppose also rtt for output. Would be cool to have bidirection rtt for zephyr's shell, I could probably work it out with probe-rs and a custom front end cli tool
Shell has left #rust-embedded [WeeChat 3.5]
<vollbrecht[m]>
rtt is just a memory_buffer with a magic header, that should be simple to add to zepyhr, works good on esp-idf
<TomB[m]>
like one thing in particular, for usage with zephyr's runner setup, is something akin to pyocd's interactive probe selection and automatic part detection would be useful
<vollbrecht[m]>
* rtt is just a memory_buffer with a magic header, that should be simple to add to zepyhr, works good on esp-idf with probe-rs
<TomB[m]>
but yeah, some other things too that probe-rs run does different enough I think
<dirbaio[m]>
> automatic part detection
<dirbaio[m]>
oh boi that's a spicy topic :D
<xiretza[cis]>
TomB[m]: huh? zephyr has support for RTT
<xiretza[cis]>
> <@halfbit:matrix.org> profiling in particular, but I suppose also rtt for output. Would be cool to have bidirection rtt for zephyr's shell, I could probably work it out with probe-rs and a custom front end cli tool
<xiretza[cis]>
* huh? zephyr already has support for RTT, there's a shell backend and everything
<TomB[m]>
xiretza[cis]: yes, but its not the default (uart is typically), and certainly not anything with defmt, it has its own dictionary logger
<TomB[m]>
so like having a probe-rs that understand all of this would be cool, so probe-rs run could perhaps look at some elf symbols to figure out what to do intelligently
<dirbaio[m]>
ARM defines a "standard" way of doing it, but almost no manufacturer follows it. for example ST has heaps of XMLs with tables like "read from this addr, AND it with this mask, if it equals this then it's this chip" 💩
<TomB[m]>
* cool, so a custom probe-rs, * probe-rs cli tool run could
<danielb[m]>
dirbaio[m]: I'm kinda-sorta working on decoding ST's mess
<TomB[m]>
* cool, so a custom probe-rs, * probe-rs cli tool run could, * elf symbols or device tree junk to figure
<dirbaio[m]>
internal XMLs in their cubeprog tool. all officially undocumented of course
<dirbaio[m]>
danielb[m]: oh? with the cubeprog xmls?
<danielb[m]>
dirbaio[m]: no, openocd's source :D
<danielb[m]>
but the XMLs may be better
<dirbaio[m]>
hmhmhmgoodluck
<danielb[m]>
Microchip has its own ROM table and peripheral that has the same info, so... one method per manufacturer because someone wants me to not sleep
<dirbaio[m]>
to make stuff even more fun, the cubeprog chip names don't match the cubemx chip names don't match the cmsispack/probe-rs names
<dirbaio[m]>
* the cmsispack/probe-rs chip names
<danielb[m]>
* Microchip has its own ROM table and peripheral that has the part info in a register, so... one method per manufacturer because someone wants me to not sleep
<dirbaio[m]>
they're "grouped" in different ways
<dirbaio[m]>
and they don't match the stm32-data chip names either because I decided to group more than the st xmls 🤣
<TomB[m]>
dirbaio[m]: right, pyocd seems to have some custom logic for all this I take it? I can't imagine pyocd code is nearly as convoluted as openocd
<JamesMunns[m]>
danielb[m]: archaeologist
<dirbaio[m]>
I said embassy supports all stm32 chips, okay??? 😡
<TomB[m]>
* as openocd. It does a good enough job mostly
<dirbaio[m]>
ALLLL Of them
<danielb[m]>
dirbaio[m]: you said to ST: hold my beer. In turn, ST said: hold OUR beer
<JamesMunns[m]>
STHORM support when?
<dirbaio[m]>
lmao
<TomB[m]>
also, and I guess this is maybe a thing, pyocd support for st parts does seem quirky compared to nxp parts, coincidence? perhaps not?
<TomB[m]>
like doesn't seem to be happy with my stm32f446re nucleo, had to use stlink (ugh)
<danielb[m]>
is the pyocd project still alive btw?
<TomB[m]>
probe-rs worked fine, after I typed the pid:vid:serial which I have to say is my biggest complaint, the lack of an interactive probe selector
<danielb[m]>
JamesMunns[m]: it's not stm32 so it's not covered in dirbaio's guarantee, is it? :D
<danielb[m]>
btw what's up with cortex m35p, which has exactly one implementation and no reference manual for the last 6 years of its existence?
<danielb[m]>
* one implementation (an STM) and no
<dirbaio[m]>
cursed_silicon.jpg
<danielb[m]>
TomB[m]: we'll be happy to merge that as a PR
<danielb[m]>
> <@halfbit:matrix.org> probe-rs worked fine, after I typed the pid:vid:serial which I have to say is my biggest complaint, the lack of an interactive probe selector
<danielb[m]>
* we'll be happy to merge that if you PR it :)
<danielb[m]>
JamesMunns[m]: yes, that one :D
<TomB[m]>
danielb[m]: Interesting, I may work on it then if I'm for sure going to get a merge out of it, don't want to waste time if it doesn't happen :-) done so many PRs in my life that never even get a look
<TomB[m]>
* a look, kind of turns you off from contributing sometimes
<TomB[m]>
so many wasted efforts :(
<danielb[m]>
TomB[m]: we try not to do that but often end up with "please change THIS" and hear no more of the author
<TomB[m]>
I try to make sure I look at zephyr PRs as much as I can because of that
<TomB[m]>
danielb[m]: those are the worst... many sensor drivers in zephyr come that way
<TomB[m]>
someone does a drive by code drop never to be seen again
<JamesMunns[m]>
matklad, from rust-analyzer, has a really good post on this, lemme find it
<TomB[m]>
100+ sensor drivers in zephyr, probably close to that many one time zephyr contributors
<JamesMunns[m]>
JamesMunns[m]: he makes a case for "make it stupid easy to merge any drive by, have a dedicated maintainer (ideally paid) who focuses on cleaning up merges and refactoring when needed" or so, I have to find it
<JamesMunns[m]>
dirbaio[m]: they are starting to sound like names of guns
<danielb[m]>
JamesMunns[m]: > (ideally paid)
<danielb[m]>
🥲
<TomB[m]>
its give and take, you review, and if people don't come back that's part of the deal, but many people do come back and fix things, but yeah certainly one benefit of zephyr is many people are being paid to work on it (myself included that category)
<danielb[m]>
> <@jamesmunns:beeper.com> he makes a case for "make it stupid easy to merge any drive by, have a dedicated maintainer (ideally paid) who focuses on cleaning up merges and refactoring when needed" or so, I have to find it
<danielb[m]>
* > (ideally paid)
<danielb[m]>
🥲
<danielb[m]>
* > (ideally paid)
<danielb[m]>
🥲
<TomB[m]>
* its give and take, you review, and if people don't come back that's part of the deal, but many people do come back and fix things, but yeah certainly one benefit of zephyr is many people are being paid to work on it (myself included in that category)
therealprof[m] has quit [Quit: Idle timeout reached: 172800s]
<TomB[m]>
dirbaio: btw did you ever run into a quirk with stm32 v2 i2c reload flag in doing embassy?
<TomB[m]>
is there like a mile long list of errata for these things?
<dirbaio[m]>
dunno, I haven't written the i2c drivers
<TomB[m]>
* these things I haven't seen?
<dirbaio[m]>
v1 has been more quirky I think
adamgreig[m] has quit [Quit: Idle timeout reached: 172800s]