MartinSivk[m] has quit [Quit: Idle timeout reached: 172800s]
pcs38 has joined #rust-embedded
chrysn[m] has joined #rust-embedded
<chrysn[m]>
<Kaspar[m]> "We're about to merge sth like [..." <- I've tried phrasing it such that both could be enabled. Some more debug statements would break, but only those where a non-Copy value is moved into a print -- and those are often just "FIXME: We should do something with {thing}" lines that need overhaul anyway.
<thejpster[m]>
<dirbaio[m]> "but hey it's 1.0" <- I mean, I'm proud of the commitment Ferrous Systems made to stabilising defmt and I think going to 1.0 is a fair reflection of that, but whatever.
<dirbaio[m]>
thejpster[m]: I didn't mean it in a bad way, I'm sorry if it came across as such
<dirbaio[m]>
Defmt is great, I really appreciate it!
<JamesMunns[m]>
> This memo describes a protocol suite which supports an infinite number of monkeys that sit at an infinite number of typewriters in order to determine when they have either produced the entire works of William Shakespeare or a good television show. This memo provides information for the Internet community.
<JamesMunns[m]>
But generally proc macros have no access to type information, they still just work in tokens, so until we have reflection, I don't think what you hinted at is possible at all
<JamesMunns[m]>
it might? be possible to have a proc macro that strips type hints OUT of the format string, and does something?? to proxy the calls between the defmt or log?
<JamesMunns[m]>
so internally if it sees `"Hello {0=usize}"`, and makes `Hello {0}` for `log` and `Hello {0=usize}` for defmt?
<thejpster[m]>
so if you're happy to give up some performance "Hello {0}" is OK, it just means you get istr!("{=usize}"), x in the byte stream.
<thejpster[m]>
It's the moving of x into the arg list and working out which place it will be in the arg list that I think is tricky.
<JamesMunns[m]>
ahhhhh, got it
<thejpster[m]>
"x = {x}, y = {y}, total = {0}", y maps to .... "x = {1}, y = {0}, total = {0}", y, x. I think.
<thejpster[m]>
but maybe "x = {1}, y = {2}, total = {0}", y, x, y is fine.
<thejpster[m]>
in general, defmt users want to specify types as it saves transferring extra interned strings containing the formatting, so in general throwing the same string at log::info! and defmt::info! is sub-optimal.
<ivmarkov[m]>
thejpster[m]: I must say, a very large portion of the `defmt` user base (all of `embassy-*`, right?) and then `esp-rs` are doling exactly that though...
<thejpster[m]>
> strips type hints OUT of the format string
<thejpster[m]>
that would be neat.
<JamesMunns[m]>
yeah, my suggestion was towards that problem, totally oblivious of the 2795 suggestions
<thejpster[m]>
My preferred approach is just to write a defmt-std transport that processes non-interned-strings (interning a string just gives you a pointer to the string slice) and do all the rendering host side.
<thejpster[m]>
Then you don't need log at all.
<thejpster[m]>
but that means refactoring the decoder to not require ELF symbol tables.
<thejpster[m]>
and I don't have time
<thejpster[m]>
s/host/target/
<ivmarkov[m]>
thejpster[m]: But there are "in-between" project that do live on the border between "embedded MCU" land and "embedded Linux" land, where just "throwing `log` out of the window" might not cut it. Take `rs-matter` for example. It has the (possibly unrealistic ambitions) to just run on both. What do we do for these?
<ivmarkov[m]>
s/project/projects/
<ivmarkov[m]>
I don't think I can say to Linux users "hey, just use defmt"
<thejpster[m]>
there is a wide spectrum of solutions, and I apply the Universal Answer in this scenario
<thejpster[m]>
(the Universal Answer is "it depends")
<thejpster[m]>
I don't know of a way to give you optimum space/performance on a microcontroller, and let you use the same syntax as println!. Someone just has to pick.
<thejpster[m]>
and it's OK if they pick a different choice to you. You can just not use the crate, or fork the crate, or whatever.
<ivmarkov[m]>
I'm not looking for a universal answer. I have a very concrete use case where throwing log out of the window just feels wrong. And then I guess for all of embassy it also kinda feels wrong, as most of these crates also live in this "in between" land. As in - everything in there except the HALs and - hm - embassy-net is perfectly (ab)usable on Embedded Linux too, and I'm proudly abusing it as such all day long.
<Kaspar[m]>
ivmarkov[m]: we could have a `format_args!()` that understands defmt formatting specifiers but formats on device.
<ivmarkov[m]>
All I'm saying is (please don't take me wrong, I don't weant to sound offensive or anything) is that perhaps the "compatible with log" case should not be dismissed too easily.
<ivmarkov[m]>
s/weant/mean/
<ivmarkov[m]>
<Kaspar[m]> "we could have a `format_args!()`..." <- If that does mean a bunch of strings in the flash, then that defeats the whole point of using `defmt` in the first place? As it is all about flash bloat?
<Kaspar[m]>
ivmarkov[m]: Yeah, I mean, for if `defmt` is not used but `log`. `log` uses `format_args!()` to hook into the default std formatting. if it would instead understand the `defmt` formatting specifiers natively (or through some wrappers), the format specifiers could be `defmt` format but `log` could be used.
<ivmarkov[m]>
Kaspar[m]: That actually sounds like a great idea!
<ivmarkov[m]>
So the lib would commit to the "defmt" way of formatting, but then rather than committing on the defmt transport as well, it will do (with proc macros) some sort of mapping of the defmt way of formatting strings into the log way of formatting strings. So the fact that the lib uses defmt formatting strings would remain a hidden detail of the lib, when the `log` crate is selected for usage?
<ivmarkov[m]>
s///, s/on/to/
<ivmarkov[m]>
I think that might be a win-win, because then the lib can put inside its log statements all these =usize (excuse possible syntax typos) that further optimize for defmt and are simply discared for log. Neat.
<ivmarkov[m]>
* That actually sounds like a great idea!
<ivmarkov[m]>
So the lib would commit to the "defmt" way of formatting, but then rather than committing to the defmt transport as well, it will do (with proc macros or whatever) some sort of mapping of the defmt way of formatting strings into the log way of formatting strings. So the fact that the lib uses defmt formatting strings would remain a hidden detail of the lib, when the `log` crate is selected for usage?
<ivmarkov[m]>
<ivmarkov[m]> "I think that might be a win-win,..." <- Kaspar: That might be even implementable completely outside of `defmt`?
<ivmarkov[m]>
<Kaspar[m]> "I think so! But looking at the..." <- Maybe it won't be so simple, as it looks to me that all the proc-macros in the `log` module are hard-wired to generate calls into `defmt::export`, and basically all of it (calling `defmt::export` this and that) needs to be replaced, and then it is not clear whether net-net it is a good idea to enhance the `log` module to also support this `defmt-to-log` transpilation, or just
<ivmarkov[m]>
introduce a new `log_log` module or even a separate crate?
<ivmarkov[m]>
* a separate proc-macro crate?
<ivmarkov[m]>
Oh my, this all sounds like the whole Java logging facade drama from ~ 20 years ago!
dulbaakjas has quit [Changing host]
dulbaakjas has joined #rust-embedded
<thejpster[m]>
in other news, I was single stepping Rust firmware on my AM243x Launchpad within 30 minutes of opening the box. The firmware crashes but I get into fn main(). I think the problem is trying to do semihosting without the vector table pointer set up correctly.
<diondokter[m]>
Ah, the cortex-R board. Very nice!
dulbaakjas has quit [Quit: Client closed]
dulbaakjas has joined #rust-embedded
dulbaakjas has quit [Changing host]
dulbaakjas has joined #rust-embedded
dulbaakjas has quit [Client Quit]
<thejpster[m]>
it's almost like having a Rust runtime crate ready to go significantly reduces the overhead of bringing up new SoCs.
<thejpster[m]>
I am having to use OpenOCD though.
<Kaspar[m]>
<ivmarkov[m]> "Maybe it won't be so simple..." <- I guess this will be a question of trade-offs. In Ariel we're already wrapping `defmt` and `log` `info!()/...` macros already, to centrally dispatch between the two for all crates that use `ariel_os::debug::log`. Probably something like `[defmt-or-log](https://crates.io/crates/defmt-or-log) would be a natural place for this, if it can't be integrated into defmt directly.
<ivmarkov[m]>
* wondering what t-moe would say about this idea ^^^
<ivmarkov[m]>
That would eradicate the fmt.rs gazillion of files dispersed across all of embassy-* if the embassy folks embrace the idea as well.
<chrysn[m]>
I agree that the small differences should be easy to hammer out -- an advanced version of the defmt macros could accept "a {b}" into "a, {}", b, and an optional variant could discard the =[u8] style hints and send everything off to format_args.
<chrysn[m]>
A bit harder things are around semantics -- string formatting distinguishes between Debug and Display, which AIU Format does not. Getting over that may require some tolerance to outputs varying slightly. (Like, I haven't seen the :? for debug-like output make any difference so far).
<chrysn[m]>
But with some pooling of effort I think there is a realistic path for a more builtin defmt_or_log that does all the right things.
<ivmarkov[m]>
I don't think the "new idea" is striving to invent a syntax which a super-set of the defmt syntax at all. With it, you are basically committing yourself to the defmt formatting syntax. When it gets extended - great - but in the meantime you just use what the defmt syntax offers. So yes, that would mean no rfc2795 and I have to change all the 500+ log statements. But it solves the bigger problem for me, which is - that my lib
<ivmarkov[m]>
would remain compatible with the log crate. Or in other words the TL;DR is: with this new crate (or extension to log-or-defmt) you are committing yourself to the defmt syntax (and you'll need to have either defmt itself or defmt-or-log as a non-optional dependency depending on where this new code lands) but users can still use your lib with the log logging if their downstream crates have chosen log as their logger.
<ivmarkov[m]>
It is no different than the existing fmt.rs facades in embassy-* I guess except a tad more complex impl which can generate more efficient code when defmt-the-transport is used, as you'll now be able to put all those =usize in your info!.
<ivmarkov[m]>
* It is no different than the existing fmt.rs facades in embassy-* I guess except that it is a tad more complex impl which can generate more efficient code when defmt-the-transport is used, as you'll now be able to put all those =usize in your info!.
<ivmarkov[m]>
As for - say - Debug vs Format - perhaps we need the opposite of Debug2Format - as in - Format2Debug? In that if you implement Format, that also gives you Debug (as your users in their downstream crates might want to just log a public struct of yours using println! or whatever. And we forget about Display in this context.
<ivmarkov[m]>
* As for - say - Debug vs Format - perhaps we need the opposite of Debug2Format - as in - Format2Debug? In that if you implement Format, that also gives you Debug (as your users in their downstream crates might want to just log a public struct of yours using println! or whatever). And we forget about Display in this context.
<ivmarkov[m]>
(Not sure it all would work, just thinking loud.)
<ivmarkov[m]>
* It is no different than the existing fmt.rs facades in embassy-* I guess except that it is a tad more complex impl which can generate more efficient code when defmt-the-transport is used, as you'll now be able to put all those =usize in your info! (which should be erased when the logging backend is log).
<thejpster[m]>
> Page 1 of 10,419
<thejpster[m]>
RIP macOS Preview.App
WSalmon_ has joined #rust-embedded
<thejpster[m]>
I want to cross-check how a C example sets up the interrupt vector table, because I'm pretty sure Cortex-R5F only supports 0x0000_0000 (Low) or 0xFFF0_0000 (High) and I've got my table at the start of MSRAM at 0x7000_0000. This chip has no on-board flash, but the Launchpad does have a 512MB QSPI Flash part, and the AM243x has a ROM that can boot from QSPI, NOR, USB, PCI-E, UART - basically anything.
<thejpster[m]>
And despite them not offering macOS support in their SDK, I can just run https://dev.ti.com/ and it's installing some kind of Firefox extension that will let me program the hardware from my browser? The future is wild.
vollbrecht[m] has joined #rust-embedded
<vollbrecht[m]>
thejpster[m]: Many would today even do it even without a plugin via webusb, ( though that does not work in firefox, only in chrome)
rafael[m] has quit [Quit: Idle timeout reached: 172800s]
MartinSivk[m]1 has quit [Quit: Idle timeout reached: 172800s]
<thejpster[m]>
I have not been able to get the examples to run, thus far.
<i509vcb[m]>
The web thing is neat, but I doubt it works on aarch64 Linix
<i509vcb[m]>
s/Linix/Linux/
<Lumpio->
I think it was TI that also required you to install some weird browser extension even to use some of their configuration tools that work perfectly fine without connecting to the hardware. Just to generate files.
<thejpster[m]>
I'm installing the macOS version of Code Composer Studio. Let's hope it has AM243x support.
<Lumpio->
Although the worst offender so far was some touch sensing chip company whose configuration tool would not work without their official devkit
<Lumpio->
I don't think it was even meant to be DRM, just incompetence
<Lumpio->
Not like the devkits are their main source of profit anyways
<i509vcb[m]>
I know that on windows the TI web thing required an local application as well
<i509vcb[m]>
My true test of whether something is portable is whether it runs on aarch64 Linux
<thejpster[m]>
my true test is whether something is portable is whether is runs on OpenBSD on Big Endian POWER9
<thejpster[m]>
s/is/of/, s/is/it/
<i509vcb[m]>
Maybe a little bit of a leap lol, but I use aarch64 as the standard since it literally just requires testing on a Pi (Although I have a far better aarch64 machine than a Pi 5)
pcs38 has joined #rust-embedded
cr1901 has quit [Read error: Connection reset by peer]
<JamesMunns[m]>
One of the things I know they are going to ask is "where is Rust being used in production?", if anyone wants to share anything that is public that you think I should namedrop, please let me know!
<JamesMunns[m]>
And if anyone has time to show up and blow up the chat, I'd definitely appreciate that :D
<thejpster[m]>
do they specifically want embedded examples? Have you watch Russinovitch's talk from Rust Nation?
<JamesMunns[m]>
* in production (edit: specifically for embedded)?", if
<JamesMunns[m]>
Yes they do, and no I haven't!
<thejpster[m]>
he had a lot of examples of Microsoft using Rust, many of which I hadn't seen. You may or may not consider the Windows Kernel to be embedded.
<thejpster[m]>
also their Pluton security processor, programmed in Rust.
<JamesMunns[m]>
ooh yeah, I need to remember the 3 or so security processors I'm aware of
<JamesMunns[m]>
Google has one, MS has one, Oxide's is one
<thejpster[m]>
also, the UEFI firmware on a Surface laptop is written in Rust (https://microsoft.github.io/mu/). Mark mentioned that.
<JamesMunns[m]>
(I'll compile all the things people share here into a bullet point blog post, to save the next presenters some hassle 😃 )
<thejpster[m]>
> Espen Albrektsen explains how Rust speeds up our development time and how Sonair is aiming to be among the first to deploy a safety-certified Rust implementation.
<diondokter[m]>
I don't know if there's anything public, but at Embedded World it seemed Mercedes, BMW and Volkswagen were also starting to use Rust
<balbi[m]>
* https://github.com/OpenDevicePartnership \<- microsoft initiative to get more rust in embedded (particularly embedded controllers, secure partitions (i.e. hafnium), and UEFI)
<JamesMunns[m]>
Also if anyone wants to DM me vague things they can't claim in public, happy to mention industries like "products in X space" :)
<JamesMunns[m]>
(please don't break any legal agreements)
<RobinMueller[m]>
There is ttps://activities.esa.int/4000140241 and there is also some activities of the DLR https://elib.dlr.de/208891/ that is actually quite recent. I am fairly certain there are already satellites running rust up there, but i forgot the name of the project
<thejpster[m]>
You can quote Asahi Lina too. I’m sure she’s said that the Apple M1 Linux port would have taken much much longer doing it in C instead of Rust.
<RobinMueller[m]>
I know that Cambrian Works https://www.cambrianworks.com/ used Rust, not sure whether its in their sold hardware though. There is also nexosim https://github.com/asynchronics/nexosim which is super interesting for systems simulation for something like avionics and spacecraft, and xompletely open source
<RobinMueller[m]>
* and spacecraft simulation, and
<i509vcb[m]>
<thejpster[m]> "You can quote Asahi Lina too. I..." <- User of the drivers here on M2
<i509vcb[m]>
I've struggled to find any issues in the AGX driver from just using it
ana_briated has quit [Ping timeout: 246 seconds]
pcs38 has quit [Quit: leaving]
JasperHarrison[m has joined #rust-embedded
<JasperHarrison[m>
I'm developing something in the Industrial Safety sector with firmware fully in Rust