<cr1901>
RobertJrdens[m]: So re: miniconf, I want some clarification... if I have an Option<> in a struct that derives Tree, and by default that Option is initialized to None, there is no way to set that particular entry by deserialize_by_key (i.e. it will return Traversal::Absent). Is that correct?
<cr1901>
If I initialize that Option to Some(Default::default()), load settings from non-volatile storage, realize that that Option's key is _not_ in non-volatile storage, can I programmatically set that setting to None given its Packed() key (thus locking out from further modification/traversal for the rest of the program)
<cr1901>
Basically, I have Option<_> in Settings (derives Tree), I wrote that Option<_> to NV storage, but since my Settings by default sets that Option<_> to None on boot, deserialization given that Option's key fails with Absent.
<cr1901>
So I can't actually _load_ Option<_> settings from NV storage. But I don't know apriori whether the Option<_> is on NV storage to begin with, so None seems like the appropriate default
<cr1901>
seems like a catch-22 lol
<cr1901>
>deserialization given that Option's key fails with Absent <-- (AFTER loading it from NV storage- I checked the I2C bus :D)
pronvis has quit [Ping timeout: 240 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 260 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 264 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 260 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 264 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 252 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 264 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 260 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 256 seconds]
<JamesMunns[m]1>
<M9names[m]> "Could you more explicitly define..." <- Yep, I'm probably throwing stones in a glass house. In short: names that could be taken as offensive - but that's subjective for sure
<JamesMunns[m]1>
JamesMunns[m]1: My complaint on rtfm was that I did have a lot of meetings with companies where I introduced rtfm, and I always had at least one person raise an eyebrow or reference "read the f'n manual", and I'd have to spend time in the meeting explaining the name, instead of the tool.
<JamesMunns[m]1>
JamesMunns[m]1: At the time - rtfm/rtic was the primary tool I was recommending to customers when they asked how to structure their projects, so it came up a lot.
<JamesMunns[m]1>
JamesMunns[m]1: So maybe more concisely: when it turns out the name of a project is odd enough to distract attention away from the content of the project itself.
<JamesMunns[m]1>
Like GIMP vs Photoshop, for example. It's less that it's a "bad word", it's just wasted time explaining away the name, instead of making a case for using a good tool.
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 272 seconds]
<andreas[m]>
> My complaint on rtfm was that I did have a lot of meetings with companies where I introduced rtfm, and I always had at least one person raise an eyebrow or reference "read the f'n manual"
<andreas[m]>
If a for-profit commercial customer doesn't like the name of a no license cost open source tool, they should call their Lauterbach Sales-Rep and place an order ;-)
<andreas[m]>
* an order instead ;-)
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 264 seconds]
bguruprasath5[m] has joined #rust-embedded
<bguruprasath5[m]>
Hi everyone, i'm trying to communicate with CC1200 via spi on nrf52840 but always getting 0 as response. Anyone tried this before ? is there anything i'm missing?
pronvis has joined #rust-embedded
<JamesMunns[m]1>
<andreas[m]> "> My complaint on rtfm was..." <- Yep, that's totally valid. I 100% agree the maintainer is under no obligation, and is totally within their right to name it whatever they want.
<JamesMunns[m]1>
Adoption is not necessarily success for free OSS.
<JamesMunns[m]1>
JamesMunns[m]1: But "paying for" is a step above "using", and if they laugh it off they won't do either.
pronvis has quit [Ping timeout: 240 seconds]
pronvis has joined #rust-embedded
<sourcebox[m]>
Thanks for finishing the instructions for the crate transfer. My question is now: should we generally encourage the maintainers of class crates to transfer over their crates to rust-embedded-community? Maybe at least the ones that are linked in the usb-device readme. For now, only usbd-serial is within the r-e-c group.
<M9names[m]>
r-e-c primarily exists for under-maintained crates that lots of people depend on. you don't have to push every crate into r-e-c.
<sourcebox[m]>
It's mainly to address the version update problems with usb-device because the class crates are typically not always following it.
<sourcebox[m]>
In addition, the idea of moving the relevant traits into a separate crate with more stabiliy should be taken into account.
<sourcebox[m]>
But after having a look into the code, I have no idea if it is simple to do.
<Lumpio->
Oh that thing needs a rewrite
<Lumpio->
Or just for everybody to move over to embassy (although it's still a bit wordy for my taste)
<M9names[m]>
PRs welcome :P
pronvis has quit [Ping timeout: 256 seconds]
<M9names[m]>
(yes i know who i'm talking to)
<sourcebox[m]>
Yesterday, ryan-summers mentioned the pain of doing updates to usb-device because of that version dependencies. So we either have to reduce the pain or ignore it by just pushing out new releases.
<sourcebox[m]>
In best case, only Cargo.toml has to be updates in those class crates and someone in r-e-c can just do it without having the original maintainer to be involved.
<Lumpio->
Somebody should put "interface trait in separate crate" in some kind of general Rust guidelines
<Lumpio->
It even rhymes kinda
<M9names[m]>
r-e-c is a best-effort fallback maintainer.
<M9names[m]>
if you care about something being actively maintained/developed and it isn't currently, consider volunteering to maintain/develop it yourself or forking the project.
<JamesMunns[m]1>
Lumpio-: We just call it ITISC like it's one of the weird unstable features for rustc
<JamesMunns[m]1>
that being said - it's also what we do with all of embedded hal, so it sorta tracks.
<sourcebox[m]>
It will not really help the ecosystem in general by just doing forks that have still a bus factor of 1.
<M9names[m]>
a bus factor of 1 is greater than a bus factor of 0
<JamesMunns[m]1>
yeah, r-e-c was our version of rust-bus
<sourcebox[m]>
But in general, each crate with a bus factor of 1 will be naturally abandoned at some point in time.
pronvis has joined #rust-embedded
<M9names[m]>
either a project attracts and sustains maintainers, or it is abandoned and then forked or replaced.
<M9names[m]>
you can't do it forever yourself, but you also can't rely on others to do it forever for you.
<sourcebox[m]>
With those class crates, they have to be maintained because of the dependency. There's no real choice like "the code is good enough, it's finished".
<sourcebox[m]>
If you put yourself in the position of the application developer, you want that your code at least compiles.
pronvis has quit [Ping timeout: 268 seconds]
<sourcebox[m]>
Even if no features or fixes are implemented.
<JamesMunns[m]1>
sourcebox[m]: yes, but maintenance is at the grace of the maintainers. It might not be finished, but the maintainer might be done.
<JamesMunns[m]1>
r-e-c is primarily for "the main developer is more or less done, we can merge urgent PRs, or at least handle a yank if that's the last choice.
<JamesMunns[m]1>
* last choice."
<JamesMunns[m]1>
IMO if a crate in r-e-c attracted enough maintainers to start back up, it'd be better off moving back out of r-e-c into a new org or something.
<JamesMunns[m]1>
(that's just MY opinion tho, I can't speak for everyone on r-e-c)
<sourcebox[m]>
But the original maintainer can still work on it while it's in r-e-c.
<sourcebox[m]>
And they even should, imo.
<JamesMunns[m]1>
¯\_(ツ)_/¯ people can do what they'd like. You can't force someone to spend time on something they aren't paid for, or actively using themselves anymore. r-e-c is the alternative to just archiving the project and leaving it abandoned.
<JamesMunns[m]1>
Maybe we're arguing different points though.
<M9names[m]>
maybe i'm also tilting at windmills here - how many class crates are there? how many are not updated as fast as you need? how many of those are actually used?
<sourcebox[m]>
If we want some progress with USB, we need to provide some kind of package like tinyusb does. Either as a single crate like embassy-usb or as a collection of crates that work together.
<JamesMunns[m]1>
I mean - you could also just use embassy-usb!
<diondokter[m]>
sourcebox[m]: Not unless you have a contract and/or pay them
<sourcebox[m]>
diondokter[m]: Understand it like: they should still be encouraged to work on it. It's not like: transfer it over because we want to get rid of you.
<diondokter[m]>
Encouraging is fine of course
pronvis has joined #rust-embedded
<JamesMunns[m]1>
sourcebox[m]: nah, they totally *can*! "should/must" is maybe a little strong.
<JamesMunns[m]1>
like I said, if it gets really active again, it might be easier to collaborate in a dedicated repo/project.
<JamesMunns[m]1>
(like smoltcp-rs for example - where it's clear it's not just one person's project anymore)
<sourcebox[m]>
JamesMunns[m]1: Of course I can, and I will probably do it. But if that is the advice, why do we maintain usb-device at all.
<M9names[m]>
some people's idea of "encouraging" is quite demoralising tbh
<sourcebox[m]>
s/./?/
<JamesMunns[m]1>
it's maintained because ryan-summers and other folks are still using it, but afaik mostly keeping the lights on for THEIR existing projects, because that's easier than switching over to embassy-usb for them
<JamesMunns[m]1>
it's not "official" in anyway, it's in r-e-c because the original author wasn't interested in maintaining it actively, and that's fine! but as many folks were (and are?) using it today, moving it to r-e-c was preferable to abandoning and forcing a fork.
<JamesMunns[m]1>
I'd imagine most repos in r-e-c would be "free to a good home", if there were people willing to pick the crates back up
<JamesMunns[m]1>
(I might be underselling Ryan's intent - you'd have to ask him! That's just my current understanding of intent)
pronvis has quit [Ping timeout: 252 seconds]
<JamesMunns[m]1>
<M9names[m]> "some people's idea of "encouragi..." <- yeah, when it becomes "demanding" it's a bummer, esp if your excitement for the project has already evaporated.
<sourcebox[m]>
Ok, then we maybe should have a clear vision if the usb-device ecosystem should be developed. Don't forget that some HALs rely on it.
<JamesMunns[m]1>
I'm unclear who you mean by "we"!
<JamesMunns[m]1>
if you mean the wg? Then it is clear that the wg has no official position on usb at the moment.
<sourcebox[m]>
"We" is maybe an abstract term for people here in the chat.
<M9names[m]>
<JamesMunns[m]1> "I'd imagine most repos in r-e-..." <- i think it would be also a good fit if you weren't sure you could be in it for the long run - you can drive the project for a while and decide whether you care enough to keep it alive.
<M9names[m]>
r-e-c's mission statment explicitly mentions "experimental but widely used crates" so they're probably okay with doing the needful when you aren't available or if you just need a reviewer.
<JamesMunns[m]1>
Ah! In that case - if you find a collection of people willing to maintain and design things, then it'd be just as easy to actively refer folks here to that project, the same as we do for embassy-usb, or other non wg-affiliated but still very good options!
<sourcebox[m]>
For usbd-midi (if it gets transferred), I would at least do basic things to keep it running.
<JamesMunns[m]1>
yep, I think r-e-c is a great holding place while you're still Looking For Group to have more folks interested in the same project!
<sourcebox[m]>
There's a need for an audio class, I would also work on that under certain premises (mainly because it's not really working well currently and I have no real idea yet how to fix it).
<JamesMunns[m]1>
yep! There are unending nice to haves, and it comes down to finding the right people to make that happen. There are lots of crates I happily use but wouldn't be able to drive development of - usb-device and embassy-usb included!
<sourcebox[m]>
My idea is also to ask on RustAudio Discord if someone there is interested to help. There are some people doing embedded which are not here on Matrix, I think.
<sourcebox[m]>
The guy who is working on the firmware of a recently shown synthesizer told me over there that everything works quite well with Rust beside of USB. So there's some C library doing that, probably tinyusb.
pronvis has joined #rust-embedded
<andreas[m]>
FWIW, I just created the [usb-rust](https://github.com/usb-rust) GH org. Perhaps we can start by asking people to move Rust USB repos (other than embassy-usb) over to that repo.
<andreas[m]>
Of course, I'm more than willing to move ownership of the org to whomever wants to take over and invite whoever is interested. If there is no interest, I will delete the Org again, because I'm actually not a friend of name-squatting.
<JamesMunns[m]1>
Like I said - things happen when people do them, not when we talk about them here. If you do things, talk about them here, and we'll point as many people your way as we can.
<andreas[m]>
s/repo/org/, s///
pronvis has quit [Ping timeout: 252 seconds]
<sourcebox[m]>
If it's the intention for r-e-c to finc a new home for the crates, then why not just moving all USB crates to rust-usb?
<sourcebox[m]>
s/finc/find/
<JamesMunns[m]1>
I think that's a reasonable idea, personally! If you want to try it out before you make it "github official", then start in r-e-c! If it gets some traction, then move it out! Or move it out now, see if it works, and give it back to r-e-c if you decide not to continue.
<JamesMunns[m]1>
There's no formal process. Go with what seems right, and maybe ideally prevents a little extra churn or work for others if you aren't sure :)
<andreas[m]>
sourcebox[m]: Looked at that first, just couldn't figure out who owns the org. So I claimed the other available name, just in case.
<sourcebox[m]>
r-e-c has to decide whether if it wants to actively being used for new development or if it's just like a fallback solution/experimental space.
<sourcebox[m]>
Ok, with that mission statement (which sometimes can be outdated) then next steps should be clear: move USB crates completely out unless they should be abandoned anyway.
<JamesMunns[m]1>
if your intent is to resume maintenance, and don't think you need a trial period to make it happen in case you change your mind, I think that's a reasonable proposal.
<JamesMunns[m]1>
I can't decide that, but asking the people who have committed to usb-device in the last months (really thinking of Ryan here), and getting them to agree, is a reasonable next step.
<M9names[m]>
as 1/5th of r-e-c i think they probably speak meaningfully for that group too
<JamesMunns[m]1>
M9names[m]: (r-e-c has more than 5 members, but most are not public)
<M9names[m]>
ah. good to know
<JamesMunns[m]1>
(10 members, plus 7 "outside collaborators", not sure how many of those are really active, I'm certainly not, but here with permissions if someone needs to be added or removed)
<JamesMunns[m]1>
there are four owners: me, disasm, eldruin, and thejpster
<JamesMunns[m]1>
(reverse deps only typically shows libraries that rely on a crate, not applications)
<sourcebox[m]>
I only mention it because if it's decided not to put much effort in usb-device anymore, HALs have to look for an alternative and I'm not sure if Embassy is the one in all cases.
<JamesMunns[m]1>
yep, and they will have to make those decisions!
<JamesMunns[m]1>
there is no obligation from anyone.
<M9names[m]>
also HALs don't care. they go where users go, and can provide multiple implementations.
<ryan-summers[m]>
Just coming online and reading all the chat. In general, James' assessment of the situation is extremely accurate
<ryan-summers[m]>
I'm maintaining usb-device in the R-E-C because I needed to fix bugs in it and we use it in Stabilizer for one of my clients. I don't have a vested interest in anything really more than just making it work. I also know it needs a rewrite, it was written a long time ago. But the fact of that matter is that it works (about 80% of the time ;)) and I don't have the time to do a rewrite, and no one else does either
<ryan-summers[m]>
So for now, I've just been landing patches to issues as I find them to help make Stabilizer more usable
pronvis has quit [Ping timeout: 255 seconds]
<ryan-summers[m]>
By all means, if someone wants to fork and rewrite usb-device and it ends up being better and not too hard to switch to, I'd do it in a heartbeat. Might even look at embassy-usb tbh
<ryan-summers[m]>
But as mentioned, the R-E-C is entirely for maintaining abandoned crates so we can still keep using them. If usbd-midi is abandoned, see if you can get it transferred to the org and I'd be happy to add you as a maintainer in the org (following the R-E-C process of course), but I have no interest in MIDI or usb-audio (because I don't use it), so I wouldn't be interested in spending lots of time maintaining it unfortunately
MikePanetta[m]1 has quit [Quit: Idle timeout reached: 172800s]
M762spr[m]1 has quit [Quit: Idle timeout reached: 172800s]
<ryan-summers[m]>
sourcebox[m]: To be frank, HALs don't need to provide USB support at all. Users can implement this entirely independently of the HAL as well. It's just been convenient until now. Feel free to write something better :)
<ryan-summers[m]>
s/until now//
jedugsem[m] has quit [Quit: Idle timeout reached: 172800s]
<sourcebox[m]>
That's normal. Since USB classes cover a lot of different use cases, no one interested in all of them.
<sourcebox[m]>
ryan-summers[m]: It's only that USB is one of the hardest things to do.
pronvis has joined #rust-embedded
<ryan-summers[m]>
<sourcebox[m]> "I only mention it because if it..." <- There's no "decision" to not put much effort in. I put exactly as much effort as I need to into usb-device for my projects needs. I have nothing against someone else also putting in effort on the crate for their needs (and I've given a number of reviews to just this over the last few months!)
<ryan-summers[m]>
But ultimately this all comes down to the fact that time is a finite resource
<sourcebox[m]>
Ideally, companies would pay people to do it.
<JamesMunns[m]1>
sourcebox[m]: that would be very cool, and doesn't happen very often!
<sourcebox[m]>
But we are not in that situation.
<ryan-summers[m]>
So I think my thoughts are as follows:
<ryan-summers[m]>
2. Should all usb crates be in the R-E-C? Maybe. But it just depends if they are actively maintained or not
<ryan-summers[m]>
1. If you'd like usb-midi to be maintained, getting it transferred to the R-E-C is well within the R-E-C mission. However, that's only half the battle. You also need to have someone within the R-E-C (or outside) that will do the maintaince. The R-E-C is just a vehicle to manage repo and crates.io crate permissions. I would imagine in this case that the maintainer would need to be you.
<ryan-summers[m]>
And they still hit the problem of "Need to have a maintainer"
<JamesMunns[m]1>
Though for example, embassy IS at least partially driven by people nominally using it for work, though certainly not even a majority of the moving parts anymore.
pronvis has quit [Ping timeout: 268 seconds]
<sourcebox[m]>
I cannot really promise to do much active maintainance on usbd-midi, but I can at least keep it in a state that is usable. And even if I'm not doing simple version bump to keep it compile, then someone else can do it as last resort.
<sourcebox[m]>
Currently, I have to keep 2 class crates locally in the code, simple because the releases are not following usb-device.
<sourcebox[m]>
And yes, I did some more work on it, but that's another thing.
<ryan-summers[m]>
Again, the purpose of the R-E-C is largely to be a vehicle to expand ownership and publishing permissions. Offering to do some maintainenance isn't some lifelong commitment
<sourcebox[m]>
s/it/them/
<sourcebox[m]>
I had a look at the crates listed in the usb-device readme, they are all maintained to use the 0.3 release. That's a good thing. But it can change in the future, of course.
<sourcebox[m]>
Overall, since we're trying to convince people to get into Rust embedded, we surely have to put some effort into having things organized rather than the pure code. Otherwise, people wil always state: "Rust promises a lot, but it doesn't work that well in practice."
<ryan-summers[m]>
I don't think using the term "we" here is helpful. I'm putting in precisely as much effort and time as I can currently afford. And for what it is, no one has ever told me that about rust. It's almost entirely related to finding Rust talent or being risk averse to new tools
<ryan-summers[m]>
Rust is miles ahead of any other embedded language with regard to library management, so I would say that just because it's not perfect doesn't mean its going to be a reason that people don't use it
<sourcebox[m]>
It's miles ahead, yes. But it does not organize the collaboration.
<dirbaio[m]>
Cargo makes dependency hell much easier to fall into though
<ryan-summers[m]>
Yeah but I get the same issues with tools like pip
<dirbaio[m]>
Tinyusb in C: single repo with core, hal impls and class impls
<dirbaio[m]>
USB-device in Rust: one crate with the core, 15 hal crates maintained in different repos by different people, 10 class impl crates maintained in different repos by different people
<M9names[m]>
and no dependencies is also hell
<ryan-summers[m]>
Still better than "Oh we wrote the whole library in C++ header files so make this simple" imo
<JamesMunns[m]1>
yeah, I mean in Rust you can still always vendor and patch the deps as an app dev, and I absolutely have done that for projects
<JamesMunns[m]1>
we're not helplessly bound to crates-io
<ryan-summers[m]>
Yeah patches are super easy to maintain, esp. if you're finishing something and shipping it
<JamesMunns[m]1>
but it's a sucky alternative to "it all just works and I don't have that extra maintenance step/cost"
<ryan-summers[m]>
Hey if someone wants to pay me to rewrite usb-device, I'd be game
pronvis has joined #rust-embedded
<sourcebox[m]>
About using the term "we": I have no better idea what to use. Everybody here tries to do the best he can, simply the amount of time spending here proves it.
<M9names[m]>
sourcebox[m]: > they
<ryan-summers[m]>
It's fine to refer to the matrix and people of the rust community as "we", but I would hesitate to use the term when demanding action of said group
<sourcebox[m]>
"Demanding action" is probably true in some way, but my intention is not to put anyone under pressure.
<ryan-summers[m]>
Also: tinyUSB is sponsored by adafruit to make it all possible
<JamesMunns[m]1>
sourcebox[m]: if that's you're intent, then maybe ease off the "should"s.
<JamesMunns[m]1>
s/you're/your/
<JamesMunns[m]1>
Otherwise, I think you'll make your intent more clear with "I'm going to do X", or "I'm looking for people to do X with me".
<JamesMunns[m]1>
"my goal is to make it easier to do X", etc.
pronvis has quit [Ping timeout: 252 seconds]
<sourcebox[m]>
Maybe. Honestly, as a non-native English speaker I have some problems of expressing the right intent in just written conversation.
<ryan-summers[m]>
Yeah I have the same problems in German, I feel you
<JamesMunns[m]1>
No worries! This wasn't meant as an admonishment, I feel the same way in German (I'm conversational, but far less fluent than you are in english!). Hopefully it was useful to explain the pushback on some of the suggestions.
pronvis has joined #rust-embedded
pronvis has quit [Remote host closed the connection]
pronvis has joined #rust-embedded
<sourcebox[m]>
Btw. don't know what the situation is with USB video i.e. UVC class. On ESP32 someone will probably want to do that.
<ryan-summers[m]>
Video is pretty rare (and really hard) on embedded because of the huge memory requirements
<ryan-summers[m]>
And most of the USB interfaces on microcontrollers don't support a high enough data rate to send video data at any decent fidelity
<ryan-summers[m]>
^ These are just reasons why it likely isn't done yet, not saying it won't ever be done
<ryan-summers[m]>
I did a streaming video camera a while back with a full H.264 stream to an SD card and it's really resource intensive to do on battery power
<sourcebox[m]>
Seems that it becomes more popular with MCUs offering USB HS.
<ryan-summers[m]>
You need a lot of RAM and processor power to do it though. A decent MP4 is going to run you at somewhere near 60 Mbps
<ryan-summers[m]>
So it's not just the USB PHY
<Lumpio->
The chips I've seen that do stuff like fast MIPI to USB have a microcontroller but dedicated hardware for all the USB streaming data
<Lumpio->
So the microcontroller does the enumeration bit and all the complicated stuff but data streaming is done in dedicated hardware
<ryan-summers[m]>
Yeah that's enitrely what I would expect. When I did it, the microcontroller was getting the MP4 stream from an FPGA and it took all the processing power just to move the RX from FPGA into the SD card
<ryan-summers[m]>
The MCU RAM just became a giant MP4 buffer
<JamesMunns[m]1>
Yep, I've seen stuff like that in hybrid android + mcu setups, MCU manages the camera ICs, android takes the actual datastreams
<Lumpio->
I've worked with some Cypress chip that was much more dedicated, no Android or FPGA, just a bunch of hardware settings
mabez[m] has joined #rust-embedded
<mabez[m]>
Imo it depends on what you need to do (as with all things embedded :D) passing through to a webpage for example is quite simple, because you can accept compressed frames and send them as is - there are a bunch of examples using esp32s3 for this already. If you need to do any kind of frame processing then yeah you need to jump to a more powerful class of chip or have dedicated hw
<Lumpio->
UVC sounds like streaming video to me
<sourcebox[m]>
Yeah, I was sure some simple webcam applications for ESP32 already exist.
<Lumpio->
I guess technically you could do a really low frame rate...
<Lumpio->
I have one of those ESP32-CAM boards and it can stream reasonably fast low resolution over wifi
<Lumpio->
I guess I should say data rate not frame rate, can always do 60fps at postage stamp size
<JamesMunns[m]1>
yeah, 1fps security cam stuff is reasonable, and I've seen dev boards like that. I think I've even seen 5ish fps mini "computer vision" stuff on the higher end ESP32s.
<JamesMunns[m]1>
(not in prod, but really specific example projects)
<sourcebox[m]>
But for the technical background, video streaming is somewhat similar to audio in the sense that it requires isochronuos endpoints. I'm not sure if the current API is already suited for that. Maybe I'm just understanding it wrong.
<sourcebox[m]>
* current API in usb-device is already
<BenPh[m]>
<andreas[m]> "> My complaint on rtfm was..." <- > <@adoerr:matrix.org> > My complaint on rtfm was that I did have a lot of meetings with companies where I introduced rtfm, and I always had at least one person raise an eyebrow or reference "read the f'n manual"... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/FDHzcFSulPRoSwctoAcgfXTQ>)
<sourcebox[m]>
I agree that I always feel a certain amount of responsibilty for the projects I put public.
<sourcebox[m]>
But there's a limit, of course.
<JamesMunns[m]1>
you can have criticisms and preferences, but it's not reasonable to make demands, IMO.
<JamesMunns[m]1>
yes, you can call a maintainer an asshole, but also they don't owe anyone anything. Open source is a gift, take it at the value given, but it takes privilege to have the time to spare for the gift.
<JamesMunns[m]1>
that's the contract: if you disagree, you have rights to fork it and do it your way.
<JamesMunns[m]1>
the source is free, not the maintainers time.
<sourcebox[m]>
But open source is also a social contract of give and take. What you give is not always in the same domain of what you take.
<JamesMunns[m]1>
sourcebox[m]: that's an opinion, and not a globally agreed upon one. I don't agree, personally.
<JamesMunns[m]1>
I have business contracts with the people I have commitment to. The rest is me sharing my work to thank the people who have shared their work with me.
<sourcebox[m]>
But e.g. you "take" rustc without being a contributor to the code in most cases.
<BenPh[m]>
JamesMunns[m]1: Agreed. It's tough to write down the nuance of my thoughts without writing a 10 page blog post. I think my take really only comes into scope when a FOSS project becomes bigger than just those working on it. Again, Linux is a great example. Linus is notorious for being an egomaniac, asshole, etc., but the way the project is set up, is that the scope of his negative traits (I'm only refering to those that he has
<BenPh[m]>
personally acknowledged), are constrained so that what is _him_ doesn't go beyond just _him_.
<JamesMunns[m]1>
sourcebox[m]: I *have* contributed a significant amount of my time to the Rust project over the last 6 years. And I still don't think they owe me anything.
IlPalazzo-ojiisa has joined #rust-embedded
<JamesMunns[m]1>
On the other side, I have seen people demand a lot from rustc contributors, and seen a lot of very good engineers get burned out by it and leave the project, over the same timeline.
<sourcebox[m]>
That's what I'm referring to. You give something to the whole Rust project, but not a specific code base.
<JamesMunns[m]1>
Even in the embedded project, there are names you don't see active anymore because they've realized they aren't interested in keeping up with the demands made of them.
<dirbaio[m]>
<BenPh[m]> "> <@adoerr:matrix.org> > My..." <- > <@random-task:matrix.org> I have some counter-view to this. A FOSS tool that has a large presence (an extreme case: linux), then it is taking up a not-insignificant volume with respect to attention, development resources, support, etc. I've run into some projects... (full message at <https://catircservices.org/_matrix/media/v3/download/catircservices.org/DrJiSDFkgXhsiljYsZZkZtgZ>)
pronvis has quit [Read error: Connection reset by peer]
pronvis has joined #rust-embedded
lulf[m] has joined #rust-embedded
<lulf[m]>
100% agreed with James Munns, and this is even if you're being paid by a company to work on open source. As long as you don't have a contract with a legal entity, you have no rights to demand anything from maintainers. I think companies that seek to commercialise OSS would benefit more from distinguishing between the oss project, and the product/support/service they sell. This clearly distinguishes the commitments you can expect as a
<lulf[m]>
user/customer.
<dirbaio[m]>
The case of Linus is different because he's paid by the Linux foundation which is then paid by the sponsors. By even then the max accountability he has is the Linux foundation can threaten to fire him. He doesn't owe accountability to the general public.
<BenPh[m]>
to use embedded-hal as a case study. Imagine if it was just one person, and through a combination of timing, choices made, raw productive talent, etc. the world of embedded rust really only had this project as an option for writing portable code.
<BenPh[m]>
...but you will only accept PRs that feed your ego. you reject contributions that are potentially valuable, then write your own changes that are, essentially, just re-writes of the things you reject, claiming the work as your own.
<JamesMunns[m]1>
then don't use that project?
<sourcebox[m]>
So in my case, I would maybe request something from the maintainer of usb-device and provide a class driver in exchange.
<JamesMunns[m]1>
again - embedded-hal is not particularly blessed
<JamesMunns[m]1>
beyond the work done to make it what it is. There is nothing stopping someone from deciding we suck, or making a better one, or just not using it because they don't like it.
<JamesMunns[m]1>
For example: tock-os uses very few rust-embedded/wg projects
<JamesMunns[m]1>
that doesn't make them wrong, and it's not even because they don't like us!
<JamesMunns[m]1>
They just don't! And that's fine!
<BenPh[m]>
JamesMunns[m]1: there's that. I don't think we are in disagreement in the large part. I should have clarified much earlier and strongly that I feel that the take I shared is quite limited in scope.
<JamesMunns[m]1>
wg members generally have some commitment to each other, but that's ephemeral, people join because they want to, and should feel free to leave whenever they'd like! We've had many people rotate in and out over time.
<JamesMunns[m]1>
But even then, folks are welcome to take or leave our opinions and projects as they'd like! No need to kiss the ring - you're covered by MIT/Apache2 licenses.
<sourcebox[m]>
The motivations for doing open source are of course different across people. For me it's always an invitition to collaborate. And making suggestions is also a form of collaboration, not just code.
pronvis has quit [Ping timeout: 272 seconds]
<JamesMunns[m]1>
sourcebox[m]: yep! totally agree! It's the expectations that matter. If someone opens a PR you don't like, you're under no obligations to merge it, or to support requests, or even take requests, if you don'
<JamesMunns[m]1>
* you don't want them!
<JamesMunns[m]1>
I think setting boundaries, like "feel free to take this code, but it does what I want, and I don't have time to maintain it, it's permissively licensed, fork away" is one very healthy and mature strategy that should be expected.
<JamesMunns[m]1>
anyway, those are my opinions, feel free to take them for what you've paid for them.
<sourcebox[m]>
If so, it has to be made clear. Otherwise, one could even feel personally offensed by just having the code forked instead of being asked for changes.
<sourcebox[m]>
I would like to have people ask me for some improvements first instead of fragmenting the code base.
<JamesMunns[m]1>
I think proactively communicating your desires is useful, but I have no control over what people do with my code, within the bounds of the license I set.
<JamesMunns[m]1>
I can call them an asshole, I can't demand they don't fork postcard.
<JamesMunns[m]1>
proactively communicating will make for healthier relationships, but relationships are made by consent of both (or all) parties.
<JamesMunns[m]1>
I don't need to have a relationship made with everyone who uses my code.
<BenPh[m]>
I would honestly be surprised if the PR goes through. I aspire to embody the "strong opinions, weakly held" ideal on const-generics vs type-system. My _hope_ is that it gets accepted in some form, but my _expectation_ is good-faith discussion. Fortunately, in the vast majority of cases, this expectation is mutual. Mistakes are made, but they are usually made in good faith, and serve as learning experiences.
<vollbrecht[m]>
on no guys what are you doing 😭 my favorite morning chat into as a twitter clone 🙈 All the hot takes! Is something wrong with the weather today ? ( I am joking here and please don't feel attacked ;D ) I now take my ☕️ and get some sun🌞
<vollbrecht[m]>
* on no guys what are you doing 😭 using my favorite morning chat as a twitter clone 🙈 All the hot takes! Is something wrong with the weather today ? ( I am joking here and please don't feel attacked ;D ) I now take my ☕️ and get some sun🌞
<BenPh[m]>
vollbrecht[m]: Honestly, it's probably me. I never intend it, but given the right environment, I bring similar energy as the stereotypical "Everywhere I go, I create social drama", but it ends up like **scrolls up**, yeah that. sorry.
<JamesMunns[m]1>
BenPh[m]: Sometimes it's good to disengage and take a walk instead of pushing and pushing the conversation. It helps to read the room, sometimes.
<diondokter[m]>
BenPh[m]: Not saying it's super bad! I've often wondered myself. I would not be offended
<BenPh[m]>
My take:
<BenPh[m]>
- For pre 1.0, my take is every change on the release branch, almost without exception, should come with a patch-bump.
<BenPh[m]>
- As a rule-of-thumb, if your PR warrents a minor version bump, it should happen under clearly understood/communicated context. Think of it like re-arranging furniture at a house-party. Your house, your rules. You're a familiar guest, the dynamic is already established. An unknown person, read the room and be super mindful of giving due respect.
<sourcebox[m]>
ryan-summers: My suggestion for usb-device:
<sourcebox[m]>
- After that, take a breath and decide about the future. Whether to transfer it to rust-usb or not, find someone else to help or whatever.
<sourcebox[m]>
- Do a 0.4 release because 0.3 is broken for large config descriptors and the control-buffer-256 feature is removed in master.
eldruin[m] has joined #rust-embedded
<eldruin[m]>
My understanding is that PRs should never change the version number, just add a note about the changes to the changelog. If it is a breaking change, note it as such. That's it.
<eldruin[m]>
The most authoritative source of this I know is [cargo-release](https://github.com/crate-ci/cargo-release), which many people use. Version bumping is done during the release and doing it beforehand would break that workflow.
<eldruin[m]>
Otherwise several PRs could bump it several times, for example, and somebody needs to keep track of what the actual number should be.
<eldruin[m]>
By convention at least for me. Probably somebody has written this down somewhere, though.
<eldruin[m]>
You can do it in other ways, though. For me this is just simpler, more flexible w.r.t. versioning and creates less conflicts
pronvis has joined #rust-embedded
pronvis_ has joined #rust-embedded
pronvis has quit [Read error: Connection reset by peer]
dark[m] has joined #rust-embedded
<dark[m]>
Hello there guys, I know the Raspberry Pi Zero W isn't a microcontroller, but is it possible to write baremetal embedded programs written in Rust with Slint GUI for RPi zero w with a Waveshare OLED and camera module?
<JamesMunns[m]1>
The short answer, possible: yes, it would be a LOT of work tho, very much not a good first project in Rust if that's where you are.
<JamesMunns[m]1>
also, the wifi module on the W has no Rust driver, AFAIK, and it is bizzarely complex and hard to write drivers for, and pretty much the only docs are the linux drivers themselves (also 100s of thousands of lines of code)
<JamesMunns[m]1>
there aren't any existing Zero-W projects in Rust I am aware of.
<dark[m]>
Actually, pardon for a small mistake, I would be using the RPi zero non W and my program would not be using the WiFi at all
<JamesMunns[m]1>
That takes you from two really big problems to one really big problem :)
<JamesMunns[m]1>
it's certainly possible, just probably not in a reasonable amount of time.
<dark[m]>
Thank you mate, although it's a bummer to know it would take a lot of time
<dark[m]>
Would running on top of Linux be a good compromise?
<JamesMunns[m]1>
you can definitely run Rust on top of linux much easier!
<JamesMunns[m]1>
And most of the bare-metal drivers will work there too!
<JamesMunns[m]1>
Depends on what your goals are. Battery life is usually the challenge when running off the shelf linux boards
<dark[m]>
Although ideally I would want to reduce Linux down to what's only necessary for my program to save resources
<M9names[m]>
that's still the case whether you're running linux or bare metal though
<JamesMunns[m]1>
(that being said - I'm not sure if the hardware itself has any low power states that would make that easier to save power even on bare metal)
<M9names[m]>
* > Battery life is usually the challenge
<M9names[m]>
that's still the case whether you're running linux or bare metal though
<M9names[m]>
* > Battery life is usually the challenge
<M9names[m]>
that's still the case whether you're running linux or bare metal though
<JamesMunns[m]1>
and battery life is always a size/weight tradeoff anyway, it'll do just fine for months if you have a car battery :D
<M9names[m]>
dark[m]: you can set up your binary to be the entirety of userspace if you want. totally depends on what it is you want to do, and why.
<M9names[m]>
you should definitely work out whether that is necessary before you go cutting stuff out. and you know, it's a lot easier to test things when you've got an ssh server, debugger, etc
<dark[m]>
But do you guys know any simulator for me to use, rather than compiling changes every time on my zero non W?
<JamesMunns[m]1>
I've been meaning to write some code to use this board to allow you to "pass through" the I/O from a normal PC to the RP2040's Pi-like header: https://www.waveshare.com/wiki/RP2040-PiZero
<JamesMunns[m]1>
but... that's just ideas now :D
<M9names[m]>
dark[m]: it's just linux, you can do the GUI stuff on a linux PC or in a linux VM.
<M9names[m]>
and you should cross-compile for your zero from your PC too.
<M9names[m]>
if your hardware is just USB, can plug that in too. if it uses hardware specific to the pi, you'll have to run it there
<JamesMunns[m]1>
I'd be surprised if Slint didn't have a "desktop simulator" you could use for the GUI parts
<JamesMunns[m]1>
the camera part is trickier, for sure.
<M9names[m]>
it doesn't really need a simulator, it runs on desktops as well
<dark[m]>
M9names[m]: > <@9names:matrix.org> it's just linux, you can do the GUI stuff on a linux PC or in a linux VM.
<dark[m]>
> and you should cross-compile for your zero from your PC too.
<dark[m]>
Yeah but in case me and my friends decide to go baremetal, we would like to know how to compile to baremetal too
<M9names[m]>
compiling isn't the hard part, configuring and accessing hardware in a microprocessor (when the vendor does not provide any docs without an NDA) is the hard part
<M9names[m]>
if your goal is to learn about writing firmware, ditch the zero and choose a well-supported microcontroller platform with the hardware you need
<M9names[m]>
i think you're going to learn a lot no matter which way you do this, but if you try to skip learning the basics first you're going to have a very hard time
leons has quit [Quit: Idle timeout reached: 172800s]
thejpster[m] has quit [Quit: Idle timeout reached: 172800s]
<BenPh[m]>
<M9names[m]> "if your goal is to learn about..." <- my experience with esp32 has been very... _very_ positive in this respect.
bpye has quit [Quit: Ping timeout (120 seconds)]
bpye has joined #rust-embedded
pronvis_ has quit [Read error: Connection reset by peer]
pronvis has joined #rust-embedded
holo[m] has quit [Quit: Idle timeout reached: 172800s]
Klemens[m] has quit [Quit: Idle timeout reached: 172800s]
pronvis_ has joined #rust-embedded
pronvis has quit [Read error: Connection reset by peer]
AlexandervanSaas has quit [Quit: Idle timeout reached: 172800s]
LucasVella[m] has quit [Quit: Idle timeout reached: 172800s]
NickStevens[m] has joined #rust-embedded
<NickStevens[m]>
dark: Take a look at Yocto, it is designed for exactly what you're looking to do (customizing a Linux image for a board), and configurations (called "layers" in Yocto) exist for all the RPi models https://www.yoctoproject.org/
<NickStevens[m]>
A few people here, myself included, maintain https://github.com/rust-embedded/meta-rust-bin, a Yocto layer for using the Rust project binaries for cross-compiling. You can also use Rust directly from Yocto, but that will require you to build the Rust compiler from source as part of your Yocto build.
<NickStevens[m]>
As mentioned above the big tradeoff IMO for using Linux for embedded projects is battery life. You gain a lot of niceties like having hardware drivers provided by the OS, debugging tools like SSH and core-dumps, and an easy to access filesystem. But all those things require power, and getting a Linux system down to low power levels is possible but tricky.
GrantM11235[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: 240 seconds]
jannic[m] has quit [Quit: Idle timeout reached: 172800s]
AlexandrosLiarok has quit [Quit: Idle timeout reached: 172800s]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 264 seconds]
pronvis has joined #rust-embedded
pronvis has quit [Ping timeout: 268 seconds]
crabbedhaloablut has quit []
crabbedhaloablut has joined #rust-embedded
dngrs[m] has joined #rust-embedded
<dngrs[m]>
boot time is also something that can be annoying - depends on your use case