<re_irc>
<@grantm11235:matrix.org> I am still not entirely happy with the error handling. If there is an error deasserting cs, the result of the closure is thrown away.
<re_irc>
<@grantm11235:matrix.org> The closure will almost always be returning some kind of `Result`, so I might include that in the method signature
<re_irc>
<@grantm11235:matrix.org> If the closure returns a `Result`, there are five possible outcomes:
<re_irc>
<@ryan-summers:matrix.org> I would generally just make it something with a `Pin(csErr)` and `Closure(ClosureErr)`. I doubt the end user cares about _when_ the error happened, just _what_ the error is
<re_irc>
<@ryan-summers:matrix.org> For example, if the error is a CS pin error, it could be that some I2C transaction to an IO expander failed. I doubt it matters to the user whether that occurs before or after
<re_irc>
<@ryan-summers:matrix.org> But if you want it to be versatile, you can go with said approach. There's certainly times where it does matter (e.g. if enabling an IO could cause large power draw and cause that portion of the circuit to enter brownout)
<re_irc>
<@firefrommoonlight:matrix.org> How would that look in application code?
<re_irc>
<@ubik:matrix.org> 9names: Yeah, thanks for the suggestion. I figured that could be done, but then you'd have to do that every time after writing to the card. Also in the embedded device.
<re_irc>
<@firefrommoonlight:matrix.org> I think the overall question is "Is this worth the complication over setting a pin low, performing an action, then setting it high"
<re_irc>
<@firefrommoonlight:matrix.org> It reminds me a bit of the Python `with` syntax, eg:
<re_irc>
<@null_ptr:keksdie.be> huh... quoting seems to be somewhat broken here... :|
<re_irc>
<@null_ptr:keksdie.be> GrantM11235: ^ meant to quote you.
gsalazar has joined #rust-embedded
gsalazar has quit [Client Quit]
gsalazar has joined #rust-embedded
gsalazar has quit [Client Quit]
gsalazar has joined #rust-embedded
gsalazar_ has quit [Ping timeout: 250 seconds]
fabic has quit [Ping timeout: 265 seconds]
richbridger has quit [Remote host closed the connection]
richbridger has joined #rust-embedded
emerent has quit [Ping timeout: 250 seconds]
emerent has joined #rust-embedded
fabic has joined #rust-embedded
troth has quit [Ping timeout: 265 seconds]
fabic has quit [Ping timeout: 260 seconds]
<re_irc>
<@gauteh:matrix.org> I've gone down a rabbit-hole in trying to get defmt-rtt output in gdb with jlink: is there by any chance a python (2.7) parser for defmt?
<re_irc>
<@grantm11235:matrix.org> ryan-summers:matrix.org: The thing that I don't like about this is that it is ambiguous and throws away a lot of information. If you get a cs error, did your closure run? Did it succeed or fail? If you get a closure error, did cs successfully deassert?
<re_irc>
<@ryan-summers:matrix.org> I've had situations where I actually did care whether or not the closure executed, but in reality, I simplified the logic to essentially key off just the associated error and ignored the concept of when it occurred. I find that it rarely matters when the error occurred. Generally, there's just a defined action that has to happen when an error on an interface happens
<re_irc>
<@ryan-summers:matrix.org> For example, power-cycle that subcircuit, reset the microcontroller, reset the I2C bus, etc.
<re_irc>
<@ryan-summers:matrix.org> Sorry, this is SPI, so resetting the I2C bus is obviously not relevant :)
emerent has quit [Remote host closed the connection]
emerent has joined #rust-embedded
troth has joined #rust-embedded
troth has quit [Ping timeout: 250 seconds]
<re_irc>
<@grantm11235:matrix.org> null_ptr:keksdie.be: The main use cases for this trait is to use it to implement the other spi traits and to be used as a marker trait. This means that for any type that impls `Chipselect` and `Write`, cs must activate right before the write and deactivate right afterwards, or return an error. Returning successfully and only failing on the next write call would violate that contract.
<re_irc>
<@grantm11235:matrix.org> A guard based design would allow for a bit more flexibility, for example a driver could hold the guard (and therefore cs) between method calls. That seems like a recipe for deadlocks though. Also, `mem::forget`ing a guard would cause all sorts of problems.
troth has joined #rust-embedded
<re_irc>
<@grantm11235:matrix.org> ryan-summers:matrix.org: If you get a cs error after the closure succeeds, you could reinitialize the cs pin and continue as normal without resetting the spi device or redoing the spi operation
troth has quit [Ping timeout: 250 seconds]
<re_irc>
<@grantm11235:matrix.org> After listening to your feedback, I have decide to... try making it more complicated 🙃
<re_irc>
<@grantm11235:matrix.org> /// Error returned by Chipselect
<re_irc>
<@dirbaio:matrix.org> 4 generic params, it's starting to get spicy 🌶️
troth has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> hi room, meeting time again! agenda is https://hackmd.io/b746R1L8RzOpnxnWgXeZkw, please add anything you'd like to discuss, we'll start in 5 min or so 👋
<re_irc>
<@adamgreig:matrix.org> ok, let's go!
<re_irc>
<@adamgreig:matrix.org> does anyone have any announcements first?
<re_irc>
<@grantm11235:matrix.org> The RFC for static async functions in traits was accepted
<re_irc>
<@emilgardis:matrix.org> nice!
<re_irc>
<@adamgreig:matrix.org> cool!
<re_irc>
<@adamgreig:matrix.org> ok, if there's anything else please feel free to mention it throughout the meeting
<re_irc>
<@adamgreig:matrix.org> next up is cross again, since last week I've been added as an owner on crates.io so we can actually reassign/add/change owners now
<re_irc>
<@adamgreig:matrix.org> emilgardis, did you have an update here?
<re_irc>
<@emilgardis:matrix.org> No update from infra, reached out to DPC which offered to help, they would not be available to do so in a few months though
<re_irc>
<@emilgardis:matrix.org> im wondering if instead asking core is the better team to ask for general guidence
<re_irc>
<@adamgreig:matrix.org> beyond offering to take it over, what sort of guidance do you think they might be able to give?
<re_irc>
<@emilgardis:matrix.org> how this has been handled before, and if there's something to think about
<re_irc>
<@adamgreig:matrix.org> my personal feeling atm is still to set up a new org, perhaps with the existing tools team members and external contributors who want as new owners, so at least it's easier for people to start putting together a release, but perhaps that's the wrong way to think about it and we should focus on a release in the current location first and then think about moving?
<re_irc>
<@emilgardis:matrix.org> we just need to generate movement imo
<re_irc>
<@emilgardis:matrix.org> ill brb
<re_irc>
<@adamgreig:matrix.org> yea, and maybe a new org is the way to do that
<re_irc>
<@adamgreig:matrix.org> sure
<re_irc>
<@adamgreig:matrix.org> let's move on to discovery book for now and come back to cross after
<re_irc>
<@emilgardis:matrix.org> im back
<re_irc>
<@emilgardis:matrix.org> i think the general consensus is to make a new org, I suppose that should go through some kind of RFC maybe?
<re_irc>
<@adamgreig:matrix.org> hah ok
<re_irc>
<@adamgreig:matrix.org> yea, I think an RFC for tools team to vote on?
<re_irc>
<@adamgreig:matrix.org> that's who would vote on adopting a new crate so it seems fair for removing a crate, though if any non-tools-team members disagree please say so
<re_irc>
<@adamgreig:matrix.org> ok, shall I put a draft together and we can then discuss it on the rfc thread?
<re_irc>
<@emilgardis:matrix.org> yes, that sounds perfect
<re_irc>
<@emilgardis:matrix.org> we should also focus on fixing a new release at the same time, currently we're having issues with CI and dockerhub
<re_irc>
<@adamgreig:matrix.org> yep
<re_irc>
<@emilgardis:matrix.org> I don't have access to azure or dh, so haven't been able to poke at it
<re_irc>
<@adamgreig:matrix.org> I have/can give access to dh, don't know about azure
<re_irc>
<@adamgreig:matrix.org> our idea the last time it was discussed was to have the new version be the prominent front page but keep the old one published too for people with the f3disco hardware
<re_irc>
<@adamgreig:matrix.org> so probably next step is to do some monster pr that merges the branch and updates the index page and ci to make it do the right thing
<re_irc>
<@adamgreig:matrix.org> if anyone's interested in helping with that please shout here/on that pr/go ahead and have a play, i'll mention it again when some more resources team members are around
<re_irc>
<@adamgreig:matrix.org> I'll quickly jump ahead to cargo-binutils, emilgardis you added it?
<re_irc>
<@adamgreig:matrix.org> just that it needs a new release with the recent pr that fixes arch-name?
<re_irc>
<@emilgardis:matrix.org> a fix for llvm 11 was added
<re_irc>
<@emilgardis:matrix.org> we need to do a release
<re_irc>
<@adamgreig:matrix.org> any other issues or blockers in the way of a release?
<re_irc>
<@emilgardis:matrix.org> shouldn't be, im not comfortable making a release myself so if someone else on tools could do it i'd be happy :)
<re_irc>
<@adamgreig:matrix.org> 👍️ I'll put together a pr and I guess you or therealprof can check
<re_irc>
<@adamgreig:matrix.org> does anyone want to volunteer any PRs to talk about first?
<re_irc>
<@adamgreig:matrix.org> maybe not this week then :) there's been ongoing discussion in the various recent PRs like removing the traits with Time associated types and regrouping the SPI traits, so I'm happy to let that discussion continue on the threads if no one wants to discuss anything specific
<re_irc>
<@adamgreig:matrix.org> cool, therealprof anything to say about newsletter?
<re_irc>
<@thejpster:matrix.org> is there an emoji for crickets?
<re_irc>
<@emilgardis:matrix.org> 🦗
<re_irc>
<@l0uisc:matrix.org> 🦗🦗🦗
<re_irc>
<@l0uisc:matrix.org> (plural)
<re_irc>
<@firefrommoonlight:matrix.org> 🦗
<re_irc>
<@firefrommoonlight:matrix.org> 🏏🏏🏏
<re_irc>
<@adamgreig:matrix.org> well, unless anyone has anything else they'd like to discuss I think we can end early this week :P
<re_irc>
<@thejpster:matrix.org> Well everyone woke up at least]
<re_irc>
<@l0uisc:matrix.org> Remind me how regularly the newsletter is published?
<re_irc>
<@therealprof:matrix.org> Sorry, didn't get to it and was absent for a few minutes.
<re_irc>
<@adamgreig:matrix.org> it was monthly for a while, but moving towards "when there's a reasonable chunk of content and >1 month"
<re_irc>
<@therealprof:matrix.org> I'll take care of it right now.
<re_irc>
<@emilgardis:matrix.org> I'd just like to reach out to all wg members and give out a huge <3 to everyone, been seeing a lot more people interact with embedded-wg online and it's so much fun to see :D
<re_irc>
<@l0uisc:matrix.org> Was `cargo-binutils` discussed already?
<re_irc>
<@emilgardis:matrix.org> adamgreig: yes l0uisc , here
troth has quit [Ping timeout: 265 seconds]
<re_irc>
<@thejpster:matrix.org> If we're finished, just to say that I'm unemployed this week so if you need a hand with any Rust things, lmk. EWG stuff and HALs are fair game. If you want me to fix your personal project, we should talk first to set expectations.
<re_irc>
<@l0uisc:matrix.org> thejpster:matrix.org: If I didn't have to study for exam this week I'd have taken you on your word on this one...
<re_irc>
<@eldruin:matrix.org> hmm, if you are interested in chores as well, there is the ever pending rename of r-e-c to rust-embedded-unofficial
<re_irc>
<@eldruin:matrix.org> I have not come to do that yet because it takes some time
<re_irc>
<@eldruin:matrix.org> hi everyone BTW, I was late today but I catched up
<re_irc>
<@eldruin:matrix.org> as for the e-h PRs, continuing discussion in the PRs SGTM
troth has joined #rust-embedded
<re_irc>
<@adamgreig:matrix.org> hmm, I can't work out anything about the azure permissions, but i _can_ break their login by trying to log in with github and then telling it my old xbox live email address
<re_irc>
<@adamgreig:matrix.org> the dockerhub thing seems like it needs someone's personal access token which seems a bit annoynig, but it would need to be added as a secret in azure I guess, which is troublesome if we can't log in to azure
<re_irc>
<@thejpster:matrix.org> I've used docker hub with what I call a "machine account"
<re_irc>
<@thejpster:matrix.org> An email address, username and password that are well known to the team, and not tied to a person.
<re_irc>
<@emilgardis:matrix.org> we have a limited amount of team members on dh though
<re_irc>
<@adamgreig:matrix.org> kinda sucks that dockerhub charge for basically everything we'd want to do
<re_irc>
<@adamgreig:matrix.org> yea, limit is 3 team members and we currently have 6
<re_irc>
<@emilgardis:matrix.org> we should just jump ahead and use ghc
<re_irc>
<@adamgreig:matrix.org> that sounds generally better, are there downsides to not being on dockerhub? is that where people will generally expect to pull from or is it fine to be on ghc?
<re_irc>
<@thejpster:matrix.org> Yeah, but better blowing an account than having your Personal Access Tokens all need rolling over because someone left.
<re_irc>
<@adamgreig:matrix.org> thejpster: yea for sure
<re_irc>
<@adamgreig:matrix.org> we'd have to kick 4 current team members from the org to add a machine acct but i totally would if that's the only option
<re_irc>
<@therealprof:matrix.org> adamgreig: Not reallly.
<re_irc>
<@thejpster:matrix.org> A "Personal" docker account can have unlimited contributors on public repos.
<re_irc>
<@thejpster:matrix.org> Where does the limit of 3 come in?
<re_irc>
<@adamgreig:matrix.org> but not an organisation?
<re_irc>
<@thejpster:matrix.org> Oh, maybe they took that away from the free tier. They've been changing rules trying to drum up cash recently.
<re_irc>
<@adamgreig:matrix.org> yea, looks like it
<re_irc>
<@therealprof:matrix.org> Docker is trying to find ways to monetize their services.
<re_irc>
<@thejpster:matrix.org> Like how you can't use Docker Dekstop for your business without a paid account now
<re_irc>
<@thejpster:matrix.org> I like to refer to this as Oracalization
<re_irc>
<@therealprof:matrix.org> LOL, yeah.
<re_irc>
<@adamgreig:matrix.org> heh, yea...
<re_irc>
<@thejpster:matrix.org> Pfft, switch to Github Container Registry
<re_irc>
<@emilgardis:matrix.org> what are the specs of the azure ci?
<re_irc>
<@adamgreig:matrix.org> instead let's just use the totally free and unlimited github stuff thanks microsoft 👼
<re_irc>
<@thejpster:matrix.org> We're already neck-deep in the Microsoft Monster
<re_irc>
<@therealprof:matrix.org> I mean we do have options. I don't think people really need use docker to pull cross images.
<re_irc>
<@adamgreig:matrix.org> docker or dockerhub?
<re_irc>
<@therealprof:matrix.org> the latter.
<re_irc>
<@adamgreig:matrix.org> are people using the cross images with other container tools?
<re_irc>
<@thejpster:matrix.org> I presume you can pull from GHCR with Docker CLI?
<re_irc>
<@emilgardis:matrix.org> i hope not
<re_irc>
<@emilgardis:matrix.org> thejpster: yes, just specify ghcr.io/org/name
<re_irc>
<@therealprof:matrix.org> Yeah. Docker is pretty standardised nowadays.
<re_irc>
<@therealprof:matrix.org> Don't even need to use docker software to host your own repository.
<re_irc>
<@thejpster:matrix.org> I don't like it when tools, formats and on-line services all have the same name.
<re_irc>
<@therealprof:matrix.org> Yeah.
<re_irc>
<@thejpster:matrix.org> Microsoft: Hey, you love Git and we love Git, so we're renaming Github to Git.
<re_irc>
<@therealprof:matrix.org> We could just starting to refer to is as sneezlebrub from now on...
<re_irc>
<@fralalonde:matrix.org> what's the expected minimum size overhead of async? I've devised my own executor (based on the "woke" crate) and as soon as I turn it on my .bss size explodes making the binary too large to embed on my atsamd21e (32K RAM, 256K Flash). The app doesn't do much apart from flash the red led.
<re_irc>
<@grantm11235:matrix.org> Did you compile with `--release` ?
<re_irc>
<@dirbaio:matrix.org> embassy executor is <1k flash and just a few bytes of RAM (plus the actual size of your futures)
<re_irc>
<@fralalonde:matrix.org> yeah of course. I have another app (non-trivial) running on STM32F4 where I use RTIC, I feel like I usually have a good understanding of what's happening
<re_irc>
<@fralalonde:matrix.org> this is my first foray into async... maybe I bit off more than I can chew. Is there a binutil that allows seeing what's in the .bss of the binary?
<re_irc>
<@dirbaio:matrix.org> `cargo size` which invokes `llvm-size`
<re_irc>
<@fralalonde:matrix.org> embassy being less than 1K is reassuring. I must be including something big. `cargo bloat` shows my biggest fn is ~2.5K
<re_irc>
<@jamesmunns:beeper.com> You can see the items in between the start and end of bss
<re_irc>
<@dirbaio:matrix.org> but last time I tried it it was broken with rust
<re_irc>
<@fralalonde:matrix.org> Ha! My heap was set to 48K (probably copied from my other app), I've lowered it to 8K, now it works! The question is, how did it work before? Introducing async triggered an extra check.
cr1901 has quit [Quit: Leaving]
cr1901 has joined #rust-embedded
<re_irc>
<@fralalonde:matrix.org> It's all small buffers (MIDI messages), alloc/heap is mostly for convenience
<re_irc>
<@dirbaio:matrix.org> perhaps stack was overflowing into the heap but it didn't blow up because you weren't using it as much (?)
<re_irc>
<@jamesmunns:beeper.com> If you never used the heap, it might have been optimized out
<re_irc>
<@dirbaio:matrix.org> no heap at allis way nicer IMO
<re_irc>
<@jamesmunns:beeper.com> You could probably verify the stack overflow with flip-link
<re_irc>
<@dirbaio:matrix.org> in .bss you see exactly your app's RAM usage
<re_irc>
<@dirbaio:matrix.org> and you can't have "out of memory" errors at runtime
<re_irc>
<@jamesmunns:beeper.com> I mean
<re_irc>
<@jamesmunns:beeper.com> Stack overflows are still a thing
<re_irc>
<@dirbaio:matrix.org> yeah true true
<re_irc>
<@jamesmunns:beeper.com> You can do some static stack usage analysis, but rust doesn't have that by default, and if it did, indirect function calls and recursion make it very difficult to get reliable numbers
<re_irc>
<@fralalonde:matrix.org> I agree no heap is the goal, but having alloc simplifies a few things when getting started
<cr1901>
indirect function calls?
<re_irc>
<@jamesmunns:beeper.com> Function pointers, dyn dispatch, etc
<cr1901>
Basically "anywhere you don't know what function call will take place"?
<re_irc>
<@jamesmunns:beeper.com> Yeah
<cr1901>
(or "whether a function call will take place", in the case of recursion)
<re_irc>
<@jamesmunns:beeper.com> I've seen some of Jorge's work to analyze the options to get a better upper estimate, but it's still a challenge
<re_irc>
<@jamesmunns:beeper.com> But yeah, you can't statically calculate what isn't deterministically known at compile time.
<cr1901>
How are they doing, btw? I don't see them at all anymore
<cr1901>
(Ditto w/ Jonas, to a lesser extent)
<re_irc>
<@jamesmunns:beeper.com> Very busy with Ferrous stuff :)
<cr1901>
It's like when ppl start working for you, they get busy ;)
<re_irc>
<@jamesmunns:beeper.com> (btw, my last day at Ferrous was Monday)
<re_irc>
<@jamesmunns:beeper.com> But yeah, Ferrous is doing a ton of stuff at the moment.
<cr1901>
ahh interesting... hope it was amicable
<cr1901>
(I thought Ferrous was your company)
<re_irc>
<@jamesmunns:beeper.com> For sure! I just need a break from all the business
<re_irc>
<@jamesmunns:beeper.com> It is, still a shareholder, but I wasn't the only founder, and ferrous is 15+ people now
<cr1901>
Ahhh nice
<re_irc>
<@jamesmunns:beeper.com> It's like a successful OSS project: you know it's a success when it continues on without the original folks :)
<re_irc>
<@per.lindgren:matrix.org> The work on stack analyses basically uses LLVM output, and searches for candidate implementations (and selects the worst case).
<re_irc>
<@jamesmunns:beeper.com> Yup, familiar with the work! Based on KLEE still, right?
<re_irc>
<@per.lindgren:matrix.org> There are some limitations, e.g., recursion cannot typically be bounded (unless inlined or turned into tail recursion, not sure that its done currently for Rust+LLVM).
<re_irc>
<@per.lindgren:matrix.org> You can do this directly on the elf. With KLEE you could potentially do better, e.g., finding max recursion depth under some assumptions.
<cr1901>
The Zig ppl have plans for bounded recursion, but Idk if they apply to Rust land
<re_irc>
<@per.lindgren:matrix.org> Would you annotate recursion depth somehow in Zig?
<re_irc>
<@per.lindgren:matrix.org> In general its undecidable (as everything else :)
<cr1901>
Yes, there's gonna be some sort of way to annotate it, but Idk the details. And in the undecidable case, reject the code?
<cr1901>
Undecidable != "Can never find the answer", thankfully :P
<re_irc>
<@per.lindgren:matrix.org> Rust could do it as well, by MIRI interpretation, but not in the general case, you would have to help.
<re_irc>
<@dirbaio:matrix.org> you never have recursion in "real world" code
<re_irc>
<@dirbaio:matrix.org> or almost never
<re_irc>
<@dirbaio:matrix.org> if you want to guarantee your stack usage, just forbid using recusrsion
<re_irc>
<@per.lindgren:matrix.org> Agreed, its not the most common idiom for embedded.
<re_irc>
<@per.lindgren:matrix.org> And not the most useful one.
<re_irc>
<@per.lindgren:matrix.org> But with "guaranteed" tail recursion -> turned into loops at compile time, it becomes more useful.
<re_irc>
<@per.lindgren:matrix.org> Its convenient when dealing with self referential types (lists etc.)
<re_irc>
<@per.lindgren:matrix.org> But..... who needs that :) :)
<re_irc>
<@jamesmunns:beeper.com> Which is totally possible
<re_irc>
<@per.lindgren:matrix.org> As soon you want to process self referential types you either need to build a stack on your own or do it by recursion.
<re_irc>
<@jamesmunns:beeper.com> I do still use recursion pretty often, but more rarely on embedded, admittedly
<cr1901>
I use it in OCaml and Lisp, avoid it basically everywhere else when possible
<re_irc>
<@per.lindgren:matrix.org> Yea, typically because we want to avoid it, ...
<Shell>
which source-rewrites your tail-calling functions. :)
<re_irc>
<@adamgreig:matrix.org> hah, fun
<re_irc>
<@adamgreig:matrix.org> rust macros are pretty wild
<re_irc>
<@dirbaio:matrix.org> shell? lol
<Shell>
that is my name. :P
<cr1901>
Is it Shell as in "the ones at the ocean?" Or "the one on your computer"?
<Shell>
mostly the ones at the ocean.
<re_irc>
<@adamgreig:matrix.org> (for some reason the IRC bridge hasn't been able to make a puppet user on matrix for you, so it's relaying your messages from itself instead)
<re_irc>
<@adamgreig:matrix.org> (in the same way it does all the matrix->irc messages)
<re_irc>
<@adamgreig:matrix.org> hmm, if we wait until tomorrow it will be a year to-the-day since the last cargo-binutils release
<re_irc>
<@dirbaio:matrix.org> ah I thought it was you adam from the server cli shell or something
<re_irc>
<@adamgreig:matrix.org> but if we do it this evening, we can say it's been less than a year since the last one
<re_irc>
<@dirbaio:matrix.org> it loooks "special"
<Shell>
yay I'm special
<Shell>
actually I was a very early Matrix adopter and something is probably weirdly broken on matrix.org for me.
<re_irc>
<@adamgreig:matrix.org> yea, that's due to not having a puppet user, and also shell's IRC hostname being a libera mask so it really drives home the shell point :P
<re_irc>
<@adamgreig:matrix.org> could be!
<cr1901>
Speaking on which... any idea if they'll ever get the bridge situation sorted out for this channel?
<cr1901>
So e.g. all the matrix users appear on this side of the bridge
<re_irc>
<@adamgreig:matrix.org> not sure, I admit I haven't been chasing it and no one from libera or rust-lang ever got back to me
<re_irc>
<@adamgreig:matrix.org> afaik the rust- namespace isn't yet registered on libera
<re_irc>
<@adamgreig:matrix.org> and at least with this setup the bridge doesn't keep kicking all the idle matrix users
<re_irc>
<@adamgreig:matrix.org> sure does look worse from the irc side though :/
<cr1901>
I just set up a new IRC client. Not going to join the dark side anytime soon :)
<re_irc>
<@adamgreig:matrix.org> hehe
<re_irc>
<@adamgreig:matrix.org> I think there are bridges you could use that work like your own irc server that you join and it creates irc users for all the matrix ones, and it would connect to matrix as a single matrix user
<re_irc>
<@adamgreig:matrix.org> so you'd stay in irc but get a somewhat better matrix experience
<re_irc>
<@adamgreig:matrix.org> a lot of irc clients can also just connect to matrix though I think
<re_irc>
<@adamgreig:matrix.org> by "a lot" I mean, weechat
<cr1901>
I'd rather Libera staff just accommodate us lol
<re_irc>
<@adamgreig:matrix.org> heh
<re_irc>
<@adamgreig:matrix.org> actually I think the main people who didn't get back are the matrix.org team running the irc bridge
<cr1901>
Poke them again when you get the chance and/or are bored?
<re_irc>
<@adamgreig:matrix.org> we'd need rust foundation (?) to register the rust namespace as a group with libera and delegate the channel to us, and matrix.org to set up the bridge despite the large number of users (and delete the broken old one)
<re_irc>
<@adamgreig:matrix.org> yea, OK
<cr1901>
Not that I would expect this to be something you're DYING to do
<cr1901>
I mean, isn't it exciting? The prospect of going thru all this bureaucracy?
<re_irc>
<@adamgreig:matrix.org> you know it's what I live for, yep
cr1901 has quit [Quit: Leaving]
cr1901 has joined #rust-embedded
cr1901 has quit [Remote host closed the connection]
cr1901 has joined #rust-embedded
cr1901 has quit [Client Quit]
cr1901 has joined #rust-embedded
aquijoule_ has joined #rust-embedded
richbridger has quit [Ping timeout: 256 seconds]
<re_irc>
<@sympatron:matrix.org> GrantM11235: Why do you want Chipselect de-/assertion to be fallible? I think it would be an extremely rare case and would make writing drivers much more annoying without providing any real benefit.
<re_irc>
<@therealprof:matrix.org> sympatron:matrix.org: What's wrong with fallible? If you prefer a panic you can always just unwrap it.
<re_irc>
<@grantm11235:matrix.org> Good question. I want to be able to implement generic spi proxies that take an `OutputPin`, which means I will need to deal with fallibility at some point or another, unless I required `OutputPin<Error = Infallible>`
<re_irc>
<@therealprof:matrix.org> adamgreig: Are you going to publish it or would you prefer me to?
<re_irc>
<@adamgreig:matrix.org> I don't mind
<re_irc>
<@therealprof:matrix.org> Which way now? 😀 Just want to prevent overlapping action. 😉
<re_irc>
<@adamgreig:matrix.org> I'll do it
<re_irc>
<@adamgreig:matrix.org> though I think crates.io would just pick a winner :P I've pushed a tag too
<re_irc>
<@adamgreig:matrix.org> done 🎉
<re_irc>
<@grantm11235:matrix.org> sympatron:matrix.org: The spi proxies are definitely more complicated, but it's not too bad and it won't make much of a difference for most drivers
<re_irc>
<@grantm11235:matrix.org> Most drivers won't even call `with_chipselect`, they will just use `Chipselect` as a marker trait and use the other spi traits as normal
<re_irc>
<@thejpster:matrix.org> I got DMA working on the RP2040 ...
<re_irc>
<@dirbaio:matrix.org> neeeat :D only 4kb? text is rendered on the fly?
<re_irc>
<@thejpster:matrix.org> yup
<re_irc>
<@dirbaio:matrix.org> ⚡️
<re_irc>
<@jamesmunns:beeper.com> 🚀
<re_irc>
<@dirbaio:matrix.org> core writes scanline to RAM then DMAs it out?
<re_irc>
<@thejpster:matrix.org> It was touch and go to be honest. Monotron never managed 80 column mode in colour. The Pico is doing 80 columns, and at 12-bpp instead of 3-bpp.
<re_irc>
<@dirbaio:matrix.org> I wonder if making the core write directly to the PIO's DR would work... probably not due to timing?
<re_irc>
<@thejpster:matrix.org> > core writes scanline to RAM then DMAs it out?
<re_irc>
<@thejpster:matrix.org> Yes, it ping-pongs. One PIO State Machine drives the timing and a second drives the pixels. The first starts the second with an IRQ at the right moment.
<re_irc>
<@dirbaio:matrix.org> neat
<re_irc>
<@dirbaio:matrix.org> they have some spi display example where they do write directly from the CPU, but I guess SPI can tolerate stalling while VGA can't
<re_irc>
<@thejpster:matrix.org> The first version pushed pixels into the FIFO directly, but it's a waste of CPU time as you have to spin on the fifo_full flag. The DMA can pull on demand whenever the FIFO is non-full.
<re_irc>
<@dirbaio:matrix.org> ah right, better cpu usage too! :D
<re_irc>
<@thejpster:matrix.org> You can only do this because the SRAM is sharded across four banks by default.
<re_irc>
<@thejpster:matrix.org> The memory bandwidth is wild for a 75 cents chip.
<re_irc>
<@dirbaio:matrix.org> yeah
<re_irc>
<@thejpster:matrix.org> Each of the four banks can serve up a 32-bit word every clock cycle.
<re_irc>
<@dirbaio:matrix.org> it's such a *unique* chip :o
<re_irc>
<@thejpster:matrix.org> I haven't even moved my code into SRAM - it's all executing out of the XIP cache from the QSPI flash.
<re_irc>
<@dirbaio:matrix.org> wow
<re_irc>
<@thejpster:matrix.org> Monotron was at about 80% CPU doing the video. This is probably pushing 90% ... but I still have a whole core left (and plenty of memory bandwidth).
<re_irc>
<@thejpster:matrix.org> I haven't needed any of Monotron's terrible workarounds - such as firing a pre-interrupt interrupt which puts the CPU into wfi, to make the ISR entry latency constant and get rid of a bunch of jitter.
<re_irc>
<@thejpster:matrix.org> The PIO is doing it all.
<re_irc>
<@dirbaio:matrix.org> ther'es also the two small 4kb banks for MOAR bandwidth
<re_irc>
<@thejpster:matrix.org> Yeah, I should put the stack in one of those.
<re_irc>
<@pinealservo:matrix.org> A lot of people really didn't get the RP2040, thinking it just incredibly inferior to STM32 or ESP32. And I guess it is if you're just going to treat it like a basic Arduino or something. But it's a pretty amazing little chip if you are prepared to dig into its fairly unique features.
<Lumpio->
But... I just want to digitalRead()
<re_irc>
<@dirbaio:matrix.org> the builtin peripherals like uart/i2c/spi are *very underwhelming*
<Lumpio->
Using the PIO feels a bit like Shenzen I/O and it's pretty cool.
<re_irc>
<@grantm11235:matrix.org> ```rust
<re_irc>
<@grantm11235:matrix.org> Why can I do either of these? 😭
<re_irc>
<@grantm11235:matrix.org> impl<T, E> Into<E> for ChipselectError<Infallible, T, E, Infallible>
<re_irc>
<@grantm11235:matrix.org> impl<T, E> From<ChipselectError<Infallible, T, E, Infallible>> for E
<re_irc>
<@dirbaio:matrix.org> because rust is evil
<re_irc>
<@dirbaio:matrix.org> (jk(
<re_irc>
<@dirbaio:matrix.org> these look like they should be valid 🤔
<re_irc>
<@dirbaio:matrix.org> can you paste a playground?
<re_irc>
<@grantm11235:matrix.org> The first one conflicts with the blanket from/into
<re_irc>
<@dirbaio:matrix.org> hm you want to impl just `From`, because `Into` is derived from `From`
<re_irc>
<@dirbaio:matrix.org> but just `From` gives this
<re_irc>
<@dirbaio:matrix.org> > error[E0210]: type parameter `E` must be covered by another type when it appears before the first local type (`ChipselectError<Infallible, T, E, Infallible>`)
<re_irc>
<@dirbaio:matrix.org> wtf.jpg
<re_irc>
<@dirbaio:matrix.org> I've never seen this error before lol
<re_irc>
<@grantm11235:matrix.org> > implementing a foreign trait is only possible if at least one of the types for which it is implemented is local [...]
<re_irc>
<@grantm11235:matrix.org> That part is okay, I am impl'ing `From<ChipselectError<_, _, _, _>>`, and `ChipselectError` is a local type
<re_irc>
<@grantm11235:matrix.org> > [...] and no uncovered type parameters appear before that first local type
<re_irc>
<@grantm11235:matrix.org> Not sure what that means
<re_irc>
<@grantm11235:matrix.org> `E` is the first type parameter, and I guess it is uncovered
<Shell>
Covered Type: A type which appears as a parameter to another type. For example, T is uncovered, but the T in Vec<T> is covered. This is only relevant for type parameters.
<re_irc>
<@dirbaio:matrix.org> so yeah looks like it's not possible
<re_irc>
<@dirbaio:matrix.org> what would that From impl do anyway?
<re_irc>
<@dirbaio:matrix.org> you can't convert ChipselectError to E if the ChipselectError is not the right variant
<re_irc>
<@grantm11235:matrix.org> If `BeforeErr` and `AfterErr` are infallible, the only possible variant is ChipselectError::During(E)
<re_irc>
<@dirbaio:matrix.org> ooooooooh
<re_irc>
<@dirbaio:matrix.org> 🧠
<re_irc>
<@grantm11235:matrix.org> I wonder if specialization will allow us to override `impl<T, U: From<T>> Into<U> for T`
<re_irc>
<@dirbaio:matrix.org> hmhm
<re_irc>
<@dirbaio:matrix.org> you always want into to be derived from From, though
<re_irc>
<@dirbaio:matrix.org> you never impl Into directly, clippy even shouts at you if you try
<re_irc>
<@dirbaio:matrix.org> wow the proposed error messages in RFC2451 are way clearer than what ended up shipping
<re_irc>
<@dirbaio:matrix.org> > Rust's orphan rule always permits an impl if either the trait or the type being implemented are local to the current crate. Therefore, we can't allow `impl<T> ForeignTrait<LocalTypeCrateA> for T`, because it might conflict with another crate writing `impl<T> ForeignTrait<T> for LocalTypeCrateB`, which we will always permit.
GenTooMan has quit [Quit: Leaving]
<re_irc>
<@dirbaio:matrix.org> that's the reason for the weird "local type must come first" rule