<JamesMunns[m]>
This moves the `main` branch back to being semver compatible, at the cost of also reverting back to heapless v0.7 (we never released with v0.8 support because its a breaking change).
<JamesMunns[m]>
I've been busier than I've hoped, and haven't been able to dedicate time to a 2.0 release (reminder, this is planned to be a breaking **API** change, and not a **Wire Format** change - so postcard 1.x and 2.x will still be binary compatible!), so unwinding this was the best way to get these fixes released.
lehmrob has quit [Ping timeout: 258 seconds]
lehmrob has joined #rust-embedded
lehmrob has quit [Quit: Konversation terminated!]
lehmrob has joined #rust-embedded
ian_rees[m] has quit [Quit: Idle timeout reached: 172800s]
DanielPeter[m] has left #rust-embedded [#rust-embedded]
<PedroFerreira[m]>
BTW, is there some tool which lets me list the symbols in an elf section as well as their content? I've been trying to do it with objdump/readelf/nm, but only find a way to get either the content or the names
diondokter[m] has joined #rust-embedded
<diondokter[m]>
PedroFerreira[m]: Doesn't objdump with the `-D` work?
<diondokter[m]>
* the `-D` (`--disassemble-all`) work?
<PedroFerreira[m]>
diondokter[m]: that seems to produce assembly code for parts which are not assembly
<diondokter[m]>
Then I don't know... Why do you need it?
<diondokter[m]>
Might be able to write a little program that does it for you? You can use the `object` crate
<PedroFerreira[m]>
I want to check what exactly is being stored in .rodata. Yeah, I could use the elf crate too. But just wondering if there's something which does it already. doesn't seem like an uncommon use case.
<diondokter[m]>
I feel like objdump can do this. I've definitely seen it output the bytes of sections without dissassembly
<diondokter[m]>
Alternatively, find out where the rodata starts and ends. Then do an objcopy to a bin file
<PedroFerreira[m]>
yeah, i'll do something like that. thanks
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
Pedro Ferreira: you can use nm and then grep the output by the Symbol Types. For example to get all .bss you can do something like `nm <your-bin> | rustfilt | grep -i " B ". The output of nm always puts two whitespaces around the symbol name so its easy to grep. Instead of "B" you now can grep for all different Symbol Types.
<vollbrecht[m]>
s/./.`/
<vollbrecht[m]>
s/./.`/, s/name/type/
<vollbrecht[m]>
r and R are local and global readonly iirc
aprl[m] has joined #rust-embedded
<aprl[m]>
hi, i have a rust project setup for esp32 riscv std development, is there a way i can test the std app on x86 std and switch between profiles depending which target i want to compile the same codebase to?
<aprl[m]>
goal is to have one codebase for easier prototyping on x86
<vollbrecht[m]>
aprl[m]: for everything that touches the peripherals/wifi its in general not simply possible since they can only run on the xtensa/riscv targets. What people often do is separate there app logic from the peripheral stuff itself, so you have one crate that only does your stuff that also compiles against x86 and than the rest.
<vollbrecht[m]>
There are also other alternatives like emulating the code on your host, for example through qemu or a bit more user-friendly using using a service like wokwi where you can run your rust esp code directly even with the wifi driver working.
<vollbrecht[m]>
s///, s/using//
<aprl[m]>
vollbrecht[m]: > <@vollbrecht:matrix.org> for everything that touches the peripherals/wifi its in general not simply possible since they can only run on the xtensa/riscv targets. What people often do is separate there app logic from the peripheral stuff itself, so you have one crate that only does your stuff that also... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/YixJDfdzKmqTsefJNtENOapj>)
<vollbrecht[m]>
it did work great in the past, but i didn't check into it the last 6-7 month, but still should work !
<aprl[m]>
is there a guide for it somewhere?
<vollbrecht[m]>
the esp-idf-template itself generate all nececarry wokwi files for a local vscode project under advanced settings. If you have the wokwi vscode extension installed it should "just work"
<vollbrecht[m]>
though i must say with the big improvements in flashing speed in tools like probe-rs, you can always simply develop on the mcu directly most of the time ;D
<vollbrecht[m]>
if dayjob would not kill all my time currently i would also want to put more time into getting embedded-test working but yeah ... another story for another day :p
<aprl[m]>
hehe
<PedroFerreira[m]>
<vollbrecht[m]> "Pedro Ferreira: you can use nm..." <- Does that show the content of the symbol though?
<thejpster[m]>
“rust-objdump -s -j .rodata my.elf” might work - if I remember correctly
<thejpster[m]>
The gnu objdump should work the same as the LLVM one if that’s easier.
lehmrob has quit [Quit: Konversation terminated!]
lehmrob has joined #rust-embedded
lehmrob has quit [Quit: Konversation terminated!]
fooker has quit [Quit: WeeChat 4.2.2]
fooker has joined #rust-embedded
<PedroFerreira[m]>
Stupid question, which crate installs the `rust-*` binutils?
<PedroFerreira[m]>
I have cargo-binutils installed, but I don't think I have those?
crabbedhaloablut has quit [Ping timeout: 260 seconds]
crabbedhaloablut has joined #rust-embedded
lehmrob has joined #rust-embedded
mameluc[m] has quit [Quit: Idle timeout reached: 172800s]
andar1an[m] has quit [Quit: Idle timeout reached: 172800s]
heksa[m] has joined #rust-embedded
<heksa[m]>
TL;DR: we maintain custom bare metal rv32emc target for Rust compiler. We'd like it upstreamed.
<heksa[m]>
We've been developing a RISC-V core for research purposes for some year now. Our core is a RISC-V 32-bit EMC (rv32emc) which is from the Rust compiler's point of view almost exactly the same as rv32imc. Of course there's backend differences and LLVM needs to chime in on the codegen, but the Rust compiler mostly just needs to pick either the +e or the +i flag. Since there's a one-letter difference in the compiler config, we've been
<heksa[m]>
maintaining a configuration of the Rust compiler for our own purposes. However, since the Rust compiler config is a bit of a moving target, this is a bit of an undesirable high burden of maintenance for our research org to maintain this configuration and we were thinking of trying to get rv32emc in upstream maintenance. Would this be a good channel to get started on that?
<heksa[m]>
A common counter-argument is that there's not many real devices using rv32emc but based in our experience it seems like the bare metal target might be trivial to maintain beside the upstream rv32imc target. We haven't had to change anything in the compiler proper to make our target work.
<heksa[m]>
Cool, thanks. The "tier 3 target policy" heading looks appropriate and I guess I can get started on the checklist. I've already looked at some of the Tier 3 PRs and that matches with what we have in our patch-set. With the above posting I wanted to make sure there's not any invisible hurdles we might have to jump before getting started :)
<vollbrecht[m]>
* you can also directly try to reach some of the [embedded](https://github.com/rust-embedded/wg?tab=readme-ov-file#members-9)-hal riscv team members. some of them are also maintaining some upstream rust riscv targets, and ask them for feedback
<vollbrecht[m]>
and for rust specific stuff you reach all the person in zulip
<vollbrecht[m]>
* for rust-lang specific
<heksa[m]>
vollbrecht[m]: Ahyes, these guys are already familiar to me 🙂
adamgreig[m] has joined #rust-embedded
<adamgreig[m]>
hi @room, meeting time again! agenda is https://github.com/rust-embedded/wg/discussions/788, please add a comment for anything you'd like to announce or discuss and we'll start in a few minutes :)
<adamgreig[m]>
ok, let's begin! I don't have many announcements; svd2rust is gearing up for a release in https://github.com/rust-embedded/svd/pull/271 which also includes some new riscv work, we merged a not-yet-released paint-stack feature in cortex-m-rt which also involved fixing CI in https://github.com/rust-embedded/cortex-m/pull/548 so hopefully a c-m-rt release soon with that and the other recent features
<bartmassey[m]>
(All that work and typo the URL. Fixed. Apologies.)
<bartmassey[m]>
(And yes, there will be Embassy and RTIC versions soon)
<thejpster[m]>
I'd like to note that the RP2350 HAL is being upstream to rp-rs at the moment (reviewers welcome), and that you now know why I was so excercised at RustNL about the difference between `#[interupt]
<thejpster[m]>
* between `#[interupt]` on Arm and `interrupt! on RISC-V
<thejpster[m]>
it's a nightmare trying to make one example compile for both architectures.
<bartmassey[m]>
We got so much good press for this being ready at launch.
<thejpster[m]>
* between `#[interupt]` on Arm and `interrupt!` on RISC-V
<thejpster[m]>
I'm glad. It took an absurd amount of my free time for nine months.
<JamesMunns[m]>
Once we're done with announcement, I have my notes written up for the survey :)
<adamgreig[m]>
hope you're relaxing a bit now!
<thejpster[m]>
:rofl:
<adamgreig[m]>
yep, let's go for survey, thanks James Munns!
<adamgreig[m]>
we already enumerate some popular crates in the framework and tools section, so I don't see why not some other libraries if we can think of some that might be useful to know about
<JamesMunns[m]>
(as a note, Kobzol on that PR is the survey team person)
<adamgreig[m]>
otoh i wonder which crates to pick? embedded-hal? postcard?
<JamesMunns[m]>
adamgreig[m]: I just don't know where to start or end on these ones, without being biased :D
<JamesMunns[m]>
I chose not to play, but maybe that's not the right choice.
<JamesMunns[m]>
idk how many we can list either, without it being overwhelming.
<adamgreig[m]>
you go down the crates.io embedded category and sort by recent downloads but a lot aren't really embedded specific I guess
<JamesMunns[m]>
maybe we just leave it free answer, and eat the reduced engagement on those questions? They are optional.
<JamesMunns[m]>
(in fact: ALL questions are optional)
adamhott[m] has joined #rust-embedded
<adamhott[m]>
I think there might be some cases where good data is better than more, generic data. It's nice to get more responses if people can click buttons, but if they have the option to click buttons that might actually leave them lazier even still to fill out the data that we want, which is exactly which crates they use.
<JamesMunns[m]>
heapless, postcard, critical-section, portable-atomic, embedded-hal, then an incredibly long tail of others?
<JamesMunns[m]>
I guess: Does anyone feel strongly about "Yes let's enumerate options"?
<adamgreig[m]>
I guess I'm not sure I especially care about the result here
<adamgreig[m]>
crates.io already has download numbers
<JamesMunns[m]>
or would everyone be okay with "enumerate none instead of trying to find the right 5-10"
<Henk[m]>
What do we want to achieve by asking that question?
<bartmassey[m]>
I don't really care whether people answer, so leave it freeform. If somebody has some crate love, they'll mention it.
<Henk[m]>
Henk[m]: Like, what data do we want to obtain and do we want to do with it?
<adamgreig[m]>
perhaps instead of "most common" we can ask "favourite" lol
<JamesMunns[m]>
Henk[m]: tbh, I was interested to know what people felt like was the most valuable library they use, but "just look at crates-io stats" is probably more compelling
<Henk[m]>
* obtain and what do we
<bartmassey[m]>
I guess I feel like a seeded list of "common blockers" is a bit of a footgun… 😀
<adamgreig[m]>
we could ask most valuable too
<JamesMunns[m]>
I also need to repeat the same feedback for "biggest blockers" too
jannic[m] has joined #rust-embedded
<jannic[m]>
I think the absolute numbers are not very reliable either way: If we provide choices, there will be a bias that people only click on those and don't enter anything else. If we don't people will forget some things they use but don't remember..
<adamgreig[m]>
for blockers I think it might make more sense to have pre-seeded answers tbh
<bartmassey[m]>
"Here's some things people hate about Rust embedded that you may not know about yet."
<adamgreig[m]>
it would be useful to know what things we know about that lots of users agree are problems, as well as what we've not written down
<adamgreig[m]>
bartmassey[m]: hah, well, true
<adamgreig[m]>
but if a lot of users say "yea i don't like this thing" it might be a useful signal to work on that thing
<bartmassey[m]>
Surely a good question, but again I feel like the folks with strong opinions will answer freeform, and the rest apparently don't care?
<Henk[m]>
I gues it'd be nice to order common blockers, so as to give priority on what to work on
<Henk[m]>
Henk[m]: In that case you would enumerate a given list
<JamesMunns[m]>
maybe we just roll with free answer, and next year seed the list(s) with feedback from this year?
<JamesMunns[m]>
(either multiple choice or ranked answers!)
<bartmassey[m]>
brb
<JamesMunns[m]>
k, then the last one (please still object if you feel strongly about the last two!), do we want to ask "what other langs do you use with Rust"?
<adamgreig[m]>
yea, i don't mind leaving it free text
<JamesMunns[m]>
I can see the interest, but I'm not sure what we'd do with that data!
<JamesMunns[m]>
(we don't maintain any particular bindings or portability tools)
<adamgreig[m]>
I guess the interesting point to come out of that might be how many people are using C++ rather than just C
<adamgreig[m]>
I don't imagine there's many other things. maybe micropython?
<adamgreig[m]>
afaik it's not common to mix like ada and rust?
<Henk[m]>
I do like that question, also to find out how many people are mixing languages in embedded
<adamgreig[m]>
I think the earlier question about "mostly c, some rust" and "mostly rust, some c" is perhaps more useful for that though
<JamesMunns[m]>
tbh I would be very very surprised if there was a significant amount of non-C mixers
<JamesMunns[m]>
adamgreig[m]: I did change the language of that to "any other lang", not just C
<adamgreig[m]>
ah yea indeed, makes sense, but my point stands
<Henk[m]>
JamesMunns[m]: Yup. But the state of tooling doesn't quite reflect that imo. So it's a nice piece of data to get some funding going for us, methinks
<JamesMunns[m]>
I'll put it next to the "how do you mix" question, and maybe also include a "None, I only use Rust" option, which sorta overlaps
<JamesMunns[m]>
anyone superstitious about having 13 questions? :D
<JamesMunns[m]>
(we have 12 currently)
<bartmassey[m]>
"14. Would anyone have been bothered by 13 questions?"
<JamesMunns[m]>
And then finally, does anyone have objections on asking to go until Sept 05, which gives us roughly 14-16 calendar days? Too long? Too short?
<adamgreig[m]>
I don't think it's too long
<bartmassey[m]>
Def not too long.
<adamgreig[m]>
I assume more time -> more responses, to some extent
<Henk[m]>
🤷
<JamesMunns[m]>
it's two thursdays from now, so we'll have two more meetings, a bunch of weekly newsletters/podcasts, etc.
<JamesMunns[m]>
I'll plan to PR a blog post to the inside rust blog once it goes live
<bartmassey[m]>
We're up against Rustconf to some degree, so I think that makes sense for length
<adamgreig[m]>
I might be tempted to do 1 month?
<adamgreig[m]>
it's not like we need the results 2 weeks earlier
dirbaio[m] has joined #rust-embedded
<dirbaio[m]>
aren't lots of people on vacation in now?
<dirbaio[m]>
s/in//
<JamesMunns[m]>
I guess "oh it's open for a while" might relieve some of the "do it now!" urgency
<adamgreig[m]>
I wish :P
<dirbaio[m]>
vacations in August / early Sept is common at least here
<JamesMunns[m]>
but I don't feel strongly, if folks generally are inclined to aim for 4 weeks instead of 2.
<JamesMunns[m]>
(I have to double check that's cool, but I don't think theres any specific guidance on it)
<JamesMunns[m]>
If it's 4 weeks, I'll ask for Sept 19th, basically 4 thursdays from now
<adamgreig[m]>
I'd defer to their experience but otherwise feel like 4w might get us a more results, especially if it puts us outside the holiday season a bit
<adamhott[m]>
Seems like 4 weeks is good because of the holidays
<JamesMunns[m]>
cool! That's all I had, I'll go get those changes made now, I'll reping here when I could use some r+'s in the PR, then I'll go get it submitted upstream today!
<JamesMunns[m]>
thanks all!
<Henk[m]>
I'm taking off rn, see you next time!
<adamgreig[m]>
sweet, thanks!
<adamgreig[m]>
want to discuss where to promote it next?
<adamhott[m]>
I'm heading out
<adamgreig[m]>
your list already seems pretty good
<adamgreig[m]>
of course our twitter too
<adamgreig[m]>
and cohost 🥲
<JamesMunns[m]>
yeah, open to suggestions! We can also discuss over the next 4w as well
<bartmassey[m]>
Next meeting soon. See some of you this weekend at the Book Sprint!
<adamgreig[m]>
thanks for sorting that out, looks great! excited to get some results
<adamgreig[m]>
I'll be on holiday when the results come in though, lol
<adamgreig[m]>
ok, that's all for today, thanks everyone!
<JamesMunns[m]>
I guess this means I can plug the survey at RustConf :p
<JamesMunns[m]>
(Sept 10th-13th)
<adamgreig[m]>
oh nice, that's compelling too
ryan-summers[m] has quit [Quit: Idle timeout reached: 172800s]
takkaryx[m] has quit [Quit: Idle timeout reached: 172800s]
radens has quit [Quit: Connection closed for inactivity]
EthanGardner[m] has quit [Quit: Idle timeout reached: 172800s]
<PedroFerreira[m]>
<thejpster[m]> "“rust-objdump -s -j .rodata my...." <- nope, that prints the source data, but doesn't show which symbols are at which addres
<PedroFerreira[m]>
s/addres/address/
<thejpster[m]>
the ELF file doesn't record the size of each object starting at each symbol. Well, the DWARF does, but that's not easy to parse.
<thejpster[m]>
I do the objdump -t in one window and objdump -s -j .rodata in the other, and manually work it out
andar1an[m] has joined #rust-embedded
<andar1an[m]>
<JamesMunns[m]> "I guess this means I can plug..." <- I see ur speaking!