<JamesMunns[m]1>
<avery71[m]> "is there a list out there of..." <- There's probably a few dozen that I could name and cite publicly, but there's no compiled list afaik.
<JamesMunns[m]1>
"older school" embedded/engineering companies don't tend to be as public with their tech stacks of choice as much as frontend/backend teams are.
<JamesMunns[m]1>
The easiest list is probably to go through the speakers of various Oxidize, RustNL, RustConf, RustFest, and Tock World conferences over the years. For many of those companies, especially the larger ones like Google, it's likely only some teams inside are using it, it's not a company-wide choice.
<JamesMunns[m]1>
(a lot of "rust on embedded linux" listings there)
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 240 seconds]
<JamesMunns[m]1>
Also, plugging this again, if any of y'all are on Bluesky, and are talking about your rust projects there, lemme know so I can follow you!
<JamesMunns[m]1>
I run the rustembedded twitter, and as soon as there are enough folks on bsky posting regularly, I'm planning on setting up a rustembedded bsky account as well to signal boost projects
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 252 seconds]
pronvis has joined #rust-embedded
<JamesMunns[m]1>
Hey pronvis / pronvis - any chance you could look at your IRC client? for some reason your account is the only one that joins and leaves this room like 30-40 times a day, and it adds a lot of join/leave noise.
<BenPh[m]>
* I'll not be spending any more time on the RFC, I don't think.
<BenPh[m]>
The solution to portability isn't to pretend that different platforms aren't different, which seems to be what everyone in conversation is demanding, but to make managing these differences approachable and ergonomic.
<BenPh[m]>
Instead of discussing strategies to achieve the latter, I now learn that this project has enshrined the approach of the former. Probably explains why I've been frustrated.
<BenPh[m]>
thanks James Munns for getting involved and providing constructive commentry. mabez you really gave some encouraging and constructive feedback. and the original embedded-time author for showing what might've been.
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 252 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 246 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 260 seconds]
<ryan-summers[m]>
Honestly I think a lot of value could be acquired by forking embedded-time. It's a shame that it got dropped and abandoned
<ryan-summers[m]>
In my opinion, there's too many facts around abstracting time measurement that need to be tested in practice before we can think about incorporating them into e-h, which is why it was nice to keep it as a separate crate until a good solution was found, since there's less concern about broken APIs
<BenPh[m]>
I mean yeah, but rust-embedded seems to be fixated on making a portable ecosystem by erasing the notion that hardware is diverse, rather than creating a framework that makes said diversity easy to work with, so I don't think any conversation that would be productive in this forum.
<BenPh[m]>
I would love to be proven wrong, but that's where my thinking is right now.
<ryan-summers[m]>
I think its precisely the fact that hardware is so diverse that makes this difficult. The E-h strives to be zero- or very-low-cost. Time is one of those things that's super tricky to do in that manner imho
<ryan-summers[m]>
Every project has different needs from time management and different requirements
<BenPh[m]>
Yes. it is a very difficult challange to overcome. Pretending that the challenge doesn't exist is not a solution I want to be part of.
<ryan-summers[m]>
I find it unfortunate you feel that way, but the people voicing their opinions on the topic also have equally valid concerns that they want to ensure are addressed, which I'm sure is fair of them as well
<ryan-summers[m]>
That being said, I have not read through your PR or any of the comments. Just voicing my thoughts here
<ryan-summers[m]>
Also, I'd still highly encourage you to try implementing your RFC as an external crate and see how it works :)
pronvis has joined #rust-embedded
<BenPh[m]>
I already put it to good use. it's rough around the edges. works quite nicely with the caveates of roughness. Key point...
<BenPh[m]>
...but it will never get any good-faith consideration by the e-hal team, so long as the answer to "hardware is diverse" with "well then, pretend it isn't, problem solved", so until that is fixed, then I'm not gonna bother investing into it in a way that can be "upstreamed".
<BenPh[m]>
s/Key//, s/point...//, s///
<BenPh[m]>
* I already put it to good use. it's rough around the edges. works quite nicely with the caveates of roughness.
<BenPh[m]>
...but it will never get any good-faith consideration by the e-hal team, so long as the answer to "hardware is diverse" with "well then, pretend it isn't, problem solved", so until that is fixed, I'm not gonna bother investing into it in a way that can be "upstreamed".
<ryan-summers[m]>
I'm not seeing anything in the PR that hints at it not getting good-faith consideration by the rust-embedded hal teams? Are you referring to one of the meetings?
<BenPh[m]>
yeah. the people commenting in the rfc were actually quite helpful. My issue is from comments and discussions in this channel.
pronvis has quit [Ping timeout: 268 seconds]
<ryan-summers[m]>
I don't think I'd read too much into random chatter here, often times we're a bit more loose with opinions here. When things are written down in formal PRs and RFCs, it's much easier to logic about them and consider the pros/cons
<ryan-summers[m]>
But this channel is more for ad-hoc discussion etc.
<ryan-summers[m]>
Just because I have opinions that time is super hard doesn't mean I think it's impossible to implement in the e-h and I'd love to see a nice try
<ryan-summers[m]>
The main issue I've seen is that in the past we've had a lot of bad implementations and they've somewhat harmed the ecosystem, so people are a bit adverse to potentially incomplete solutions
<ryan-summers[m]>
Well, not bad, but not complete or useful
<ryan-summers[m]>
I guess what I'm saying is I wouldn't get discouraged. The biggest motivator for me is to see actual code. Reading RFCs and proposals is what people pay me to do, but reasoning about them is much harder since they're generally abstract
<BenPh[m]>
> opinions that time is super hard
<BenPh[m]>
I think this is a demonstrerable fact, rather than an opinion, and like I said/implied: pretending that it isn't is a _bad_ solution.
<ryan-summers[m]>
Anyways, gotta get to actual work no matter how much I love procrastinating it
<ryan-summers[m]>
Would love to see a proposal implementation :)
<ryan-summers[m]>
I had a need for this stuff in https://github.com/quartiq/minimq to manage session timing for MQTT clients etc. but ended up having to rip out embedded-time
<BenPh[m]>
"rip out embedded-time"?
<ryan-summers[m]>
Removed it from the dependency tree. I used it previously but we ended up factoring it out of the client because it was unmaintained
<JamesMunns[m]1>
> it will never get any good-faith consideration by the e-hal team
<JamesMunns[m]1>
Moderation note: Please be respectful here. You're welcome to voice your opinion, and disagree with the direction the embedded hal team is leading in, but as I said before, I'd disagree the embedded hal team has acted in bad faith.
<JamesMunns[m]1>
> Respect that people have differences of opinion and that every design or implementation choice carries a trade-off and numerous costs. There is seldom a right answer.
<BenPh[m]>
to be clear, I don't have any confidence that a solution to this challenge that doesn't pretend this challenge doesn't exist will not be met with constructive feedback. Not without some more systemic change in approach.
<ryan-summers[m]>
I'd be happy to provide you constructive feedback if you show me some code :)
<BenPh[m]>
s/not//
<ryan-summers[m]>
I'm not a member of the e-h team, but I've been doing lots of embedded rust and have hit a lot of common problems
<ryan-summers[m]>
And I think I've given some examples of common pitfalls in past chats over the last few weeks
pronvis has joined #rust-embedded
<BenPh[m]>
ryan-summers[m]: maybe I'll DM you at some point.
<ryan-summers[m]>
BenPh[m]: But statements like this are unfair to the community. There's a lot of people that put in a lot of free, hard work to the embedded Rust team
<ryan-summers[m]>
* Rust team and organization
badyjoke[m] has quit [Quit: Idle timeout reached: 172800s]
pronvis has quit [Ping timeout: 240 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
<BenPh[m]>
It's my experience. If you feel it's unfair, I suppose it's up to you to make a judgement call on whether I'm being unreasonable/communicating poorly and my experience and feelings are invalid, or there's a root-cause that points to a more fundamental discussion that needs to happen so that _actual_ solutions got explored.
<BenPh[m]>
I suspect it's somewhere in between, but I would bet my bottom dollar it's not just me.
<BenPh[m]>
Anyway, I've said my peace. I don't feel so happy discussing this further. feel free to DM me.
<JamesMunns[m]1>
If you feel that someone is violating these rules, please feel to contact the ewg core team privately to report this (listed on the wg readme), or escalate to the Rust Lang Moderation team: https://www.rust-lang.org/governance/teams/moderation if you feel you are unable to discuss this with the EWG core team.
<JamesMunns[m]1>
This warning isn't in relation to the technical aspects of the discussion, but regarding hostility and accusations towards members of the EWG team.
<BenPh[m]>
s/just/100%/
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 252 seconds]
<embassy-learner[>
@jamesmunns:beeper.com i am near to make my board work with postcard...just another dumb question, to simulate host side I am using my pc connected via USBSerial to the board and I am using this ultra dumb code to create cobs slice to send, I use the printend data sendig them via terminal reception seems... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/cUfqWFDaTeTMtObzkQsKmDLK>)
pronvis has joined #rust-embedded
DominicFischer[m has quit [Quit: Idle timeout reached: 172800s]
pronvis has quit [Remote host closed the connection]
pronvis has joined #rust-embedded
Oleksandr[m] has quit [Quit: Idle timeout reached: 172800s]
sourcebox[m] has joined #rust-embedded
<sourcebox[m]>
Would it help to issue a transfer request for embedded-time' to move it to rust-embedded-community`? Maybe some of the ideas mentioned here could just be implemented then.
<sourcebox[m]>
* Would it help to issue a transfer request for embedded-time to move it to rust-embedded-community\? Maybe some of the ideas mentioned here could just be implemented then.
<sourcebox[m]>
s//`/, s/'/`/, s//`/
fooker has quit [Ping timeout: 255 seconds]
<ryan-summers[m]>
Maybe? I haven't had any luck reaching the author since they wrote it. We could fork it, but would need an active maintainer base. And tbh fugit essentially is a redone version of it
fooker has joined #rust-embedded
<ryan-summers[m]>
Although I don't think fugit has the Clock abstraction
<ryan-summers[m]>
Buuut I'm not certain you'd need it. You can always just have your process() function accept the timestamp as well
<ryan-summers[m]>
* Buuut I'm not certain you'd need it. You can always just have your process() function accept the current timestamp as well
IlPalazzo-ojiisa has joined #rust-embedded
<sourcebox[m]>
It's been a while I had a look at fugit, I just remember that is does the calculation part, but not any common interface between HAL, drivers and user code like what's done with the clock trait.
firefrommoonligh has joined #rust-embedded
<firefrommoonligh>
Ben Ph: - Publish the lib you want to make. No need to get anyone's approval
<firefrommoonligh>
That's a nice attribute about doing hobby work: You don't have a boss.
<embassy-learner[>
<embassy-learner[> "@jamesmunns:beeper.com i am near..." <- > <@embassy-learner:matrix.org> @jamesmunns:beeper.com i am near to make my board work with postcard...just another dumb question, to simulate host side I am using my pc connected via USBSerial to the board and I am using this ultra dumb code to... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/qyBhqywLsaYgRYxUajtdSIHF>)
<M9names[m]>
what was the solution?
pflanze_ has quit [Remote host closed the connection]
pflanze_ has joined #rust-embedded
frere_jacques[m] has joined #rust-embedded
<frere_jacques[m]>
I saw that STM32-hals seem to rely on fugit. Is the use of it also widespread among hals for other vendors?
RobertJrdens[m] has quit [Quit: Idle timeout reached: 172800s]
pronvis has quit [Remote host closed the connection]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 246 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 256 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 240 seconds]
pronvis has joined #rust-embedded
<pronvis>
JamesMunns[m]1 ok, will take a look
pronvis has left #rust-embedded [#rust-embedded]
<JamesMunns[m]1>
<pronvis> "James Munns ok, will take a look" <- thank you!
pronvis_ has joined #rust-embedded
<pronvis_>
change LimeChat to Textual. Hope leave/reconnect spam will stop
pronvis_ is now known as pronvis
<JamesMunns[m]1>
<pronvis_> "change LimeChat to Textual. Hope..." <- Thanks! I'll let you know if it doesn't clear up in the next day or two.
gdamjan[m]1 has joined #rust-embedded
<gdamjan[m]1>
James Munns: it would be nice if the postcard README/docs say in a sentence or two "Why would you use Postcard"
<gdamjan[m]1>
I remember reading either your blog posts or tweets back at the time, but couldn't find it now
<JamesMunns[m]1>
Anything in particular you're interested in? IMO the readme says "Postcard is a #![no_std] focused serializer and deserializer for Serde. Postcard aims to be convenient for developers in constrained environments, while allowing for flexibility to customize behavior as needed.", and my short answer would be "use postcard if you want to use serde on a microcontroller"
PinballWIzard[m] has quit [Quit: Idle timeout reached: 172800s]
cr1901 has quit [Read error: Connection reset by peer]
cr1901_ has joined #rust-embedded
cr1901 has joined #rust-embedded
cr1901_ has quit [Ping timeout: 246 seconds]
cr1901 has quit [Ping timeout: 246 seconds]
<gdamjan[m]1>
for storage or communication ?
<gdamjan[m]1>
IMHO it's more appropriate for communication right?
cr1901 has joined #rust-embedded
<JamesMunns[m]1>
Could be either! I know folks using it for both.
<ryan-summers[m]>
We use it for both
<ryan-summers[m]>
It's a nice, defined, compact binary repr if you want to shove something into storage
<ryan-summers[m]>
* something into embedded storage
<NickStevens[m]>
I did a little poking around on the actions-rs stuff, and it seems like it was mostly one person who wasn't able to keep up and then archived the project to stop people from messaging them. There were at least a few people asking to take over ownership. It seems like it'd be really useful to revive since it provided a lot deeper integration with GitHub features.
<thejpster[m]>
and was immediately told a bunch of other people had already pinged the project, and nothing happened. Infra don't want to own it because they don't have the capacity.
<adamgreig[m]>
drivers are a pretty short-term worry I think, specific chips you need drivers for come and go, and you can always write new drivers
<adamgreig[m]>
there is a lot of (typically older) hardware that can run C and probably won't ever be sensible to run rust on, but you could have probably have a long and happy embedded career without ever touching any of it
<adamgreig[m]>
a lot of bare-metal embedded work today and for the foreseeable future is on arm and risc-v platforms, where rust is well supported and widely used, but if you wanted to target older things like pic and 8051 you'd have a much harder time in rust
m5zs7k has quit [Ping timeout: 268 seconds]
m5zs7k has joined #rust-embedded
trinhtuan[m] has joined #rust-embedded
<trinhtuan[m]>
Hi there,
<trinhtuan[m]>
What di you think?
<trinhtuan[m]>
It seems Rust has very limited supports from vendors officially, not like C/C++. The only vendor I know so far having official SDK in Rust for their products is the Espressif although they are still in development and maybe not ready for production yet.