<re_irc>
thread 'main' panicked at 'called `Result::unwrap()` on an `Err` value: Error { code: Session(-14), msg: "Error parsing PEM: offset out of bounds" }', src/main.rs:71:69
<re_irc>
note: run with `RUST_BACKTRACE=1` environment variable to display a backtrace
<re_irc>
<@matt:ucc.asn.au> wonder if it only handles old-format openssh private keys not new format, or something?
<re_irc>
<@matt:ucc.asn.au> could see if docs.rs/ssh-key crate is useful
<re_irc>
<@sourcebox:matrix.org> : One of the things I'd like to try soon is to interface a TFT display with a parallel bus. I think there's no preferred API to do this. I could imagine a function that takes a "port", a "pin_offset", a "pin_count" and the "value" to write. This value could be generic with the trait that it can be converted into a "u16" (because of STM32 port width). Something similar for read. Do you think that would make sense to have...
<re_irc>
<@sourcebox:matrix.org> On the HAL level, I would suggest to keep the data width flexible, not just "u8" or "u16" because some use cases have something inbetween, displays could often also be driven with a 4-bit bus.
<re_irc>
<@jamesmunns:beeper.com> (which also builds on top of display-interface)
<re_irc>
<@sourcebox:matrix.org> : I've already come across that but need to look into the details.
<re_irc>
<@sourcebox:matrix.org> The overall question for me is: should there be some trait in embedded-hal or alike that defines the API for reading/writing such parallel interfaces?
<re_irc>
<@sourcebox:matrix.org> Something that can describe a range of pins.
<re_irc>
<@sourcebox:matrix.org> Obviously, this can only work when all pins are on one port and continuous.
<re_irc>
<@jamesmunns:beeper.com> In general, it's better to experiment with traits like that outside of embedded-hal, which tends to be a "minimal subset" of extremely common and over reaching interfaces
<re_irc>
<@jamesmunns:beeper.com> there are quite a few "interface trait" libraries out there like the smartleds one, display interface, etc., which are still fairly widely used.
<re_irc>
<@sourcebox:matrix.org> On the HAL level though, there shouldn't be any dependency on a display or smartled crate.
<re_irc>
<@jamesmunns:beeper.com> If you experiment and find a good "port" abstraction, that could be eventually upstreamed, if it is useful for multiple folks. Not all chips have a "full port" interface exposed, though (nrf52, afaik, has no way of writing a whole port-at-a-time, for example)
<re_irc>
<@sourcebox:matrix.org> Yes, that's a problem. On the other hand, you could argue that not every chip has all peripherals.
<re_irc>
<@jamesmunns:beeper.com> Sure! I'm not sure what you're trying to abstract over tho yet! You led with a TFT display, but it seems like you are trying to abstract over parallel port actions in general?
<re_irc>
<@sourcebox:matrix.org> TFT is only one possible use case for parallel GPIO.
<re_irc>
<@sourcebox:matrix.org> So as a HAL writer I would offer it in a more general way.
<re_irc>
<@jamesmunns:beeper.com> Sure! You could definitely do that without an embedded-hal trait (within a single hal), and if you find that helpful across multiple hals, it could make sense to abstract that as a trait.
<re_irc>
I find that "turn it into a trait" works best when you already have defined multiple "providers" (e.g. chip hals) and "consumers" (e.g. drivers that need that interface, such as TFT displays, and whatever else).
<re_irc>
<@sourcebox:matrix.org> But that's a bit of a hen-and-egg problem.
<re_irc>
<@jamesmunns:beeper.com> how so?
<re_irc>
<@sourcebox:matrix.org> Because when no trait is provided, no chip HAL will implement it.
<re_irc>
<@jamesmunns:beeper.com> but if you haven't implemented it in multiple places, how do you know if the trait is a good abstraction of the reality of differences between, say, the stm32 port interface and the nxp port interface?
<re_irc>
<@jamesmunns:beeper.com> in general, this is why "make your own trait library and iterate on it first" is usually what is recommended before moving to embedded-hal, where it is harder to make breaking changes.
<re_irc>
<@jamesmunns:beeper.com> so make an "embedded-hal-port" library of your own, take it for a spin in a couple places, then once you are fairly certain about it, discuss upstreaming it to embedded-hal.
<re_irc>
<@sourcebox:matrix.org> One could have a look for what chips it would work. STM32 surely, but ESP32 should also (even if it often has not enough pins for such applications in general).
<re_irc>
<@sourcebox:matrix.org> iMX.RT I haven't checked yet.
IlPalazzo-ojiisa has joined #rust-embedded
<re_irc>
<@jamesmunns:beeper.com> just wanted to point out, you don't have to wait for embedded-hal or the associated team to make some sort of approval or blessing to get started! In fact, most things work better the other way around: "here, we have proof this works in X crates and Y drivers, we think this should move to embedded-hal"
<re_irc>
<@sourcebox:matrix.org> I don't wait for embedded-hal anymore since it will probably not get to stable release in the next time.
<re_irc>
<@jamesmunns:beeper.com> I think I've lost the point then. Sorry if that wasn't helpful.
Amanieu has quit [*.net *.split]
Ekho has quit [*.net *.split]
sknebel has quit [*.net *.split]
fabic has quit [Ping timeout: 255 seconds]
sknebel has joined #rust-embedded
Ekho has joined #rust-embedded
Amanieu has joined #rust-embedded
<re_irc>
<@sourcebox:matrix.org> I find this all a bit difficult. I would like to have embedded-hal get stable and offer some suggestions. Also because currently there's not really that much in.
<re_irc>
<@sourcebox:matrix.org> But anyway, it's not necessary to have it in embedded-hal, we can do without.
<re_irc>
<@therealprof:matrix.org> : display-interface provides the glue between the display driver and the hardware. The mentioned parallel GPIO implementation is the bare minimum which works with any regular embedded-hal GPIO pins.
<re_irc>
<@sourcebox:matrix.org> But please answer me a question: should e-h be a guide for new implementors how to do APIs or will it pickup APIs from existing projects?
<re_irc>
<@therealprof:matrix.org> : embedded-hal provides traits which are more like API contracts rather than a full API. There're still two additional pieces needed, the HAL implementation (fulfilling the contract) and the application using the HAL according to the contract.
<re_irc>
<@sourcebox:matrix.org> : That's all obvious, but how is the decision made what should go inside?
<re_irc>
<@therealprof:matrix.org> : Into embedded-hal? Come back in a bit over 2 hours and you might find out... We have our weekly meeting today at 8PM CET. 😉
<re_irc>
<@sourcebox:matrix.org> I follow your meetings (or the minutes) but I don't see much progress. Someone stated already that 1.0 is approached asymptotically ;-)
<re_irc>
<@sourcebox:matrix.org> If e-h provides a "contract", then someone has to write it.
<re_irc>
<@therealprof:matrix.org> The whole process is contribution driven, no contribution == no progress.
<re_irc>
<@sourcebox:matrix.org> To be honest: even with best intention to contribute, I would not know where to start and what the roadmap is.
<re_irc>
<@sourcebox:matrix.org> That's not to offend anyone, it's just a thing that naturally happens if there isn't some clear plan.
<re_irc>
<@therealprof:matrix.org> Well, repeating your question from earlier(maybe slightly rephrased) might yield some answers or starting points: "What's missing for embedded-hal to go 1.0?"
<re_irc>
<@sourcebox:matrix.org> If you ask me, some things should be finally decided. E.g. if "nb" is kept or dropped.
<re_irc>
<@therealprof:matrix.org> There had been some sorts around making a GPIO Port trait a long time ago, however it is really hard to define some useful semantics and a generic trait around that.
<re_irc>
<@therealprof:matrix.org> : 😄
<re_irc>
<@sourcebox:matrix.org> Another one is my favourite topic. Will e-h define some traits about time related functions at all? You already have "delay.rs" but no way to get some time info.
<re_irc>
<@sourcebox:matrix.org> Embassy solved it, but what they did could be probably extracted as traits.
<re_irc>
<@sourcebox:matrix.org> From user perspective, e.g. setting up parameters for a UART is always defining, baudrate, parity, stop bits. Wouldn't it make sense to have some trait for doing such a setup.
dc740 has joined #rust-embedded
<re_irc>
<@therealprof:matrix.org> : Nope. There're already multiple crates taking care of time (e.g. embedded-time and fugit).
<re_irc>
<@romancardenas:matrix.org> Hi! I'm relatively new in Rust for embedded systems, and I think that it would be great in e-h adopted a unified way to represent time/duration/clock related stuff (e.g., fugit). But from I read here maybe a good approach could be defining some traits that different time crates can implement and build on top of these traits.
<re_irc>
<@therealprof:matrix.org> : Initialisation is out of scope of e-h. We /could/ create some definitions of common properties if they exist, however things like protocols speeds are highly custom, e.g. serial protocols often use multiples of 300 but that doesn't mean that one couldn't pick any random other value and indeed those do exist.
<re_irc>
<@romancardenas:matrix.org> * if
<re_irc>
<@sourcebox:matrix.org> : Sorry, but this is a decision I can't understand at all. "fugit" and "embedded-time" are advanced crates for converting different formats. But they don't provide any trait how to get time information from the hardware.
<re_irc>
<@therealprof:matrix.org> : It is not a "decision" but the current state (dare I say: conclusion?) out of discussions, some of which happened a long time ago. Again: All of this is contribution based... without anyone (not necessarily an individual) bringing it up, raising interest, doing some research, driving discussions and making a proposal this is simply not going to happen.
<re_irc>
<@therealprof:matrix.org> At the moment I can't even tell whether you're interested in measuring elapsed time, providing ticks or working with a real time clock which are very different topics and would require vastly different interfaces (with RTC probably being the easiest and most feasible interface).
<re_irc>
<@sourcebox:matrix.org> I basically need a microseconds monotonic clock, that's a requirement I have in every single project. Everything else like RTC or converting to certain date formats is something that's out of scope and should be handled by something dedicated.
<re_irc>
<@sourcebox:matrix.org> RTC e.g. is something that is not even present on every chip.
<re_irc>
<@dirbaio:matrix.org> fwiw "embedded-time" has a "Clock" trait (though the design isn't great imo)
<re_irc>
<@jamesmunns:beeper.com> One really overarching challenge in embedded: Everyone wants one, really specific, "simple", thing. These are almost universally divergent.
<re_irc>
<@jamesmunns:beeper.com> I mean, don't get me wrong, I need a microsecond monotonic (well, kinda) clock, which is why I wrote groundhog (https://github.com/jamesmunns/groundhog). But like, really, I promise you there is no "universal use case" in embedded.
<re_irc>
<@jamesmunns:beeper.com> if you find one, you can find 10 counter examples.
<re_irc>
<@dirbaio:matrix.org> "embassy-time" doesn't, it was an explicit design decision to have only one global clock, so that you don't have to pass it through generics everywhere.
<re_irc>
<@sourcebox:matrix.org> My proposal for that is quite simple: provide an "Instant" of "u64" which represent ticks and also the information about how many ticks per second.
<re_irc>
<@dirbaio:matrix.org> that's what embassy-time does :)
<re_irc>
<@dirbaio:matrix.org> you can directly use it from drivers, they'll use the global clock
<re_irc>
<@sourcebox:matrix.org> : That's the reason I said, it was solved in embassy.
<re_irc>
<@jamesmunns:beeper.com> I think that is a very reasonable API! And it makes sense for embassy.
<re_irc>
But if you don't control the implementation (like embassy does), how do you implement that?
<re_irc>
<@jamesmunns:beeper.com> An interrupt every microsecond? Every timer overflow? How do you sync a local 16-bit timer with the global 64-bit timer?
<re_irc>
<@jamesmunns:beeper.com> How do you handle the 64-bit math for multiplication and division on size-constrained targets?
<re_irc>
If your HAL doesn't, you can implement the time driver on top of it.
<re_irc>
<@dirbaio:matrix.org> if you do that, the driver is portable to everywhere.
<re_irc>
If your HAL that provides the time driver (like embassy's HALs) you don't have to do anything.
<re_irc>
<@sourcebox:matrix.org> : That's up to the HAL.
<re_irc>
<@dirbaio:matrix.org> embassy doesn't control the implementation
<re_irc>
<@jamesmunns:beeper.com> (embassy uses timer queues very effectively! but does that become a required API surface area?)
<re_irc>
<@dirbaio:matrix.org> embassy-time requires just "a rolling u64 timer that "never" overflows"
<re_irc>
<@dirbaio:matrix.org> how interrupts are handled etc is up to the driver implementation (likely in a HAL)
<re_irc>
<@jamesmunns:beeper.com> anyway, just wanted to provide some counterexamples because things that are "obvious" have often been discussed previously.
<re_irc>
<@jamesmunns:beeper.com> I think embassy has done a great job of proving out the design choices it has made, and is a very reasonable one.
<re_irc>
<@dirbaio:matrix.org> the "embassy-time" crate is "trait-like", as in, it's just an API
<re_irc>
<@dirbaio:matrix.org> so you can directly use it in drivers
<re_irc>
<@dirbaio:matrix.org> a driver using it will require an "embassy-time" impl? sure
<re_irc>
<@dirbaio:matrix.org> but so would a driver using this hypothetical "embedded-hal" "Clock" trait
<re_irc>
<@dirbaio:matrix.org> a driver using it will require an "embassy-time" impl? yes
<re_irc>
<@jamesmunns:beeper.com> Then it sounds clear! We just need someone (maybe ?) to propose upstreaming embassy-time to embedded-hal!
<re_irc>
<@sourcebox:matrix.org> : As I understand it, it would be perfectly possible to move over this trait from embassy to e-h so it can be implemented by any HAL.
<re_irc>
<@dirbaio:matrix.org> yes
<re_irc>
- some people won't want to pay the cost of u64 to get "never overflows"
<re_irc>
- some people will want multiple clocks in the same binary
<re_irc>
<@dirbaio:matrix.org> but then it'll get stuck in bikeshedding
<re_irc>
<@jamesmunns:beeper.com> Ah! But people can use embassy-time outside of embedded-hal, right?
<re_irc>
<@jamesmunns:beeper.com> Like we don't need to upstream it for everyone to derive the value from it?
<re_irc>
<@sourcebox:matrix.org> Btw. I did this crate some time ago which I basically stole from embassy Supports multiple clocks: https://github.com/sourcebox/emtick-rs
<re_irc>
<@dirbaio:matrix.org> my point is, I don't think embassy-time is upstreamable as-is
<re_irc>
<@dirbaio:matrix.org> it's very opinionated, while people expect "embedded-hal" to be unopinionated
<re_irc>
<@dirbaio:matrix.org> my point is, I don't think "embassy-time" is upstreamable as-is
<re_irc>
<@sourcebox:matrix.org> But I see my solution as a starting point, not a final solution.
<re_irc>
<@therealprof:matrix.org> : It's not a trait based API if you have restrictions like that. It if was you could easily have multiple timers and you need to explicitly pass to the users.
<re_irc>
<@dirbaio:matrix.org> plus some linker magic to ensure there's only one global instance of the trait
<re_irc>
<@therealprof:matrix.org> : That's the issue.
<re_irc>
<@dirbaio:matrix.org> so that you don't have to carry "Clock" and "const NUM, DENOM: usize" generic params everywhere
<re_irc>
<@dirbaio:matrix.org> that's what makes it easy to use
<re_irc>
<@dirbaio:matrix.org> if you take "embassy-time" and remove the "only one global instance" you end up with "embedded-time"
<re_irc>
<@therealprof:matrix.org> : Yes, and unsuitable for use "as-is" in e-h.
<re_irc>
<@dirbaio:matrix.org> and "embedded-time" / "fugit" are much harder to use
<re_irc>
<@sourcebox:matrix.org> To me it would be already a good step to have one clock available. If someone likes to have more, than he needs to put in additional code.
<re_irc>
<@dirbaio:matrix.org> : that's exactly what I said
<re_irc>
<@therealprof:matrix.org> : Fine.
<re_irc>
<@jamesmunns:beeper.com> To maybe clear the air a bit:
<re_irc>
<@jamesmunns:beeper.com> embedded-hal generally aims to make as few assumptions or opinionated choices. This often has other tradeoffs, including difficult decisions on what to include or not.
<re_irc>
<@jamesmunns:beeper.com> This doesn't mean other approaches are WRONG, or BAD in any way.
<re_irc>
<@therealprof:matrix.org> : That concept is incompatible with e-h, though.
<re_irc>
<@jamesmunns:beeper.com> sometimes you might be very aligned with them. In cases like embassy-time, it might be a very good choice for a lot of people to use, if they can live with the decisions of that library.
<re_irc>
<@jamesmunns:beeper.com> it doesn't _have_ to be in embedded-hal to be useful.
<re_irc>
<@therealprof:matrix.org> : Exactly.
<re_irc>
<@jamesmunns:beeper.com> the ecosystem can choose which libraries they want to support. Supporting multiple might not even be mutually exclusive.
<re_irc>
<@jamesmunns:beeper.com> we also can't MAKE anyone implement some or all of embedded-hal
<re_irc>
<@jamesmunns:beeper.com> we are at the whims of what OTHER PEOPLE do.
<re_irc>
<@sourcebox:matrix.org> So in the end, you don't have anything in e-h at all.
<re_irc>
<@jamesmunns:beeper.com> We have what people agreed to place in there.
<re_irc>
<@jamesmunns:beeper.com> That is stopping no-one from going above and beyond, or making other choices.
<re_irc>
<@jamesmunns:beeper.com> We are, unfortunately, not the boss of anyone here.
<re_irc>
<@therealprof:matrix.org> : Which is kind of a weird claim given what we _do_ have in e-h and which is widely used by a plethora of crates.
<re_irc>
<@jamesmunns:beeper.com> Simply a group of volunteers trying to make useful things for other people, out of the time we give.
<re_irc>
<@sourcebox:matrix.org> : Sorry, that was a bit sarcastic.
<re_irc>
<@sourcebox:matrix.org> I regard the wg as kind of authority, whatever that means in practice. So it should give some directions.
<re_irc>
<@therealprof:matrix.org> : It's actually part of the problem why people are scared to make changes or agree to something exactly because it is widely used!
<re_irc>
<@jamesmunns:beeper.com> : Honestly, the space is too wide for us to speak with any authority. the wg is more a place for people to talk about things and share our experience.
<re_irc>
<@jamesmunns:beeper.com> See also: we are not the bosses of anyone here.
<re_irc>
<@jamesmunns:beeper.com> is very good proof you can build within the ecosystem, while also diverging, but also share that experience back here.
<re_irc>
<@therealprof:matrix.org> : We're handing out maps and help people to find interesting places and ways to get there. We also help how to read and improve the maps.
<re_irc>
<@dirbaio:matrix.org> For many traits (uart, spi, i2c, delay...) there exists one way to write the trait that's relatively unopinionated and works for everyone. So that trait goes in embedded-hal
<re_irc>
For"Clock", it seems such one way doesn't exist. Or no one has found it yet. Therefore no "Clock" in "embedded-hal" for now.
<re_irc>
<@jamesmunns:beeper.com> "build it and show us the way" is a very effective way of gaining community consensus.
<re_irc>
<@therealprof:matrix.org> : This!
<re_irc>
<@dirbaio:matrix.org> Drivers can use "embassy-time" if they're OK with "delay / measure time with good-enough precision, without annoying generics"
<re_irc>
and they can use "fugit" or "embedded-time" if they need "exact precision with no rounding, faster math but having to worry about overflows and with annoying generics"
<re_irc>
<@halfbit:matrix.org> I'm kind of surprised by the lack of a Timer trait actually, at least a minimal one that has a count and a single comparator
<re_irc>
<@jamesmunns:beeper.com> halfbit: Propose one! And we will have the discussion. Or someone will link a previous discussion, if there has been one.
<re_irc>
<@jamesmunns:beeper.com> or just build it! And show us all how good it can be.
<re_irc>
<@dirbaio:matrix.org> there was one before, it got removed for 1.0
<re_irc>
<@dirbaio:matrix.org> the problem was it used associated types with no bounds to represent time
<re_irc>
<@dirbaio:matrix.org> so it wasn't useful to build hal-independent drivers
<re_irc>
<@jamesmunns:beeper.com> scoped threads got chucked out of std for _years_ before it made it back in.
<re_irc>
<@dirbaio:matrix.org> plus
<re_irc>
<@jamesmunns:beeper.com> sometimes the ecosystem and the lang need to grow before the right abstraction is actually useful.
<re_irc>
<@dirbaio:matrix.org> I think such "basic timer" traits are somewhat harmful. They encourage drivers to take ownership of full hardware timers, which is annoying when you run out of them.
<re_irc>
<@dirbaio:matrix.org> vs with a free-running "Clock" trait you can create infinite timers out of it
<re_irc>
<@halfbit:matrix.org> So no compares, just a trait saying this is a clock source with a count and a known rate? Would need compares to build a timer queue
<re_irc>
<@halfbit:matrix.org> which I mean... presumably everything needs
<re_irc>
<@halfbit:matrix.org> at some point anyways
<re_irc>
<@dirbaio:matrix.org> the compare is not useful if there's no trait for interrupts
<re_irc>
<@dirbaio:matrix.org> and the idea of "trait for interrupts" has lots problems
<re_irc>
<@dirbaio:matrix.org> +of
<re_irc>
<@jamesmunns:beeper.com> (again - not saying groundhog should be embedded-hal either, IT SHOULDN'T. It's just another opinionated take on the same problem)
<re_irc>
<@sourcebox:matrix.org> To reduce what I have to the bare minimum, I would end up with this:
<re_irc>
/// Trait to be implemented by clock sources.
<re_irc>
/// Number of ticks per second.
<re_irc>
pub trait ClockTick {
<re_irc>
const TICKS_PER_SECOND: u64;
<re_irc>
/// Return elapsed ticks since start.
<re_irc>
fn ticks() -> u64;
<re_irc>
}
<re_irc>
pub struct Instant<C>
<re_irc>
where
<re_irc>
C: ClockTick,
<re_irc>
{
<re_irc>
ticks: u64,
<re_irc>
clock: PhantomData<C>,
<re_irc>
}
<re_irc>
<@jamesmunns:beeper.com> (is global, only needs one timer, fewer generics, no timer queues, no callbacks, no interrupts)
<re_irc>
<@halfbit:matrix.org> hmm? there's potentially many clock sources, not just systick/mtimer
<re_irc>
<@jamesmunns:beeper.com> but then there's the question "what do you do with your timer, and how do you feed it", which aren't shown in either of our traits.
<re_irc>
<@dirbaio:matrix.org> : this is what "embedded-time" does
<re_irc>
<@sourcebox:matrix.org> halfbit: In my case you have an "Instant<C>"
<re_irc>
<@sourcebox:matrix.org> : Yes, but embedded-time does much more than what should be included in e-h
<re_irc>
<@jamesmunns:beeper.com> I think we've reached full circle of this conversation, and I suggest we all stop and get a beverage before the meeting starts in 30m :)
<re_irc>
<@dirbaio:matrix.org> "embedded-time" does all that stuff because someone has needed it
<re_irc>
<@dirbaio:matrix.org> for example allowing using an integer other than "u64"
<re_irc>
<@dirbaio:matrix.org> if you propose that trait with "u64" to "embedded-hal", it will get objections
<re_irc>
<@dirbaio:matrix.org> because it forces you to do 64bit math, it forces impls to "extend" the 16bit/32bit hardware timers to 64bit
<re_irc>
<@sourcebox:matrix.org> But how do you want to solve the overflow problem otherwise?
<re_irc>
<@jamesmunns:beeper.com> If you have a 1 second, 32-bit timer, perhaps 136 years is enough for your use case?
<re_irc>
<@jamesmunns:beeper.com> it's not YOUR use case, for sure!
<re_irc>
<@jamesmunns:beeper.com> But it could be somebodies.
<re_irc>
<@dirbaio:matrix.org> some people do "2^32 at 1MHz is 1.19 hours, I know I'll never measure a time longer than that, so I just let it overflow and let twos-complement math take care of it so I get the righ results when subtracting across overflow"
<re_irc>
<@jamesmunns:beeper.com> and why should they need 64-bit (or 128-bit in case of multiplication!) math to do it?
<re_irc>
<@dirbaio:matrix.org> (which IMO is a GIANT footgun, which is why I went for u64 in "embassy-time")
<re_irc>
<@dirbaio:matrix.org> but some people think otherwise
<re_irc>
<@dirbaio:matrix.org> or they need the extra perf
<re_irc>
<@jamesmunns:beeper.com> (hello! It is me! I at least warn you the rolling foot gun exists in groundhog :) )
<re_irc>
<@dirbaio:matrix.org> or their MCU is 8bit and it can't do 64bit math
<re_irc>
<@dirbaio:matrix.org> so forcing "u64" is too opinionated 🥲
<re_irc>
<@sourcebox:matrix.org> u64 add and sub is not that expensive. And also, you don't do it all the time.
<re_irc>
<@dirbaio:matrix.org> to opinionated for an "embedded-hal" trait
<re_irc>
<@dirbaio:matrix.org> yeah, I agree with you
<re_irc>
<@dirbaio:matrix.org> but not everyone does
<re_irc>
<@therealprof:matrix.org> ... but then again people are not required to implement/use the trait...
<re_irc>
<@sourcebox:matrix.org> I have to leave for now. Good luck with the meeting.
<re_irc>
<@therealprof:matrix.org> The larger issue is: How do you guarantee updates? What's the contract for the HAL implementation?
<re_irc>
<@therealprof:matrix.org> Just creating a trait to fetch the current value is probably not enough, there would also be a need to actually update it.
<re_irc>
<@therealprof:matrix.org> (or it auto-updates with every query but then the user needs to invoke the "ticks()" function often enough to keep the flow going and how often is often enough? 😉)
<re_irc>
<@dirbaio:matrix.org> presumably the implementer would be in charge of writing the interrupt handler to update the overflow count etc
<re_irc>
<@dirbaio:matrix.org> that's what "embassy-time" does
<re_irc>
<@dirbaio:matrix.org> otherwise it's too fiddly, yes
wes_ has quit [Quit: WeeChat 2.8]
<re_irc>
<@adamgreig:matrix.org> hi @room , meeting time again! agenda is https://hackmd.io/EZZdBUFOStG4K5lnYU-vAA, please add anything you'd like to discuss or announce and we'll start in 5 min :)
<re_irc>
<@adamgreig:matrix.org> including this giant conversation about timers I missed and was jsut scrolling back through, if someone wants, heh
<re_irc>
<@lulf_:matrix.org> Usually the discussion is after the meeting!
<re_irc>
<@lulf_:matrix.org> * long discussions are
<re_irc>
<@jannic:matrix.org> Perhaps the timer is running backwards, today?
<re_irc>
<@lulf_:matrix.org> Sooo... I released a crate 'itsdns' (https://crates.io/crates/itsdns) a while back, it's a DNS client based on embedded-nal-async UDP traits. Given that there are few implementations of that trait, and the already builtin DNS client in smoltcp, I'm not sure how many use cases there are for it. But it was fun!
<re_irc>
<@adamgreig:matrix.org> nice!
<re_irc>
<@adamgreig:matrix.org> someone opened https://github.com/rust-embedded/cortex-m/issues/473 on cortex-m-rt to suggest a sort of "lite" version of the macros that are declarative, to avoid the heavy proc macro dependencies
<re_irc>
<@adamgreig:matrix.org> we used to have a declarative macro for this iirc, but it was a bit less ergonomic and less flexible to use
<re_irc>
<@adamgreig:matrix.org> it seems like for small projects the compile time shouldn't be too bad anyway, and for bigger projects it's likely those deps are already in-tree, but I'm sympathetic to seeing proc-macro and syn and such take up the majority of your build time on a tiny hello-world project
<re_irc>
<@jamesmunns:beeper.com> it'd be interesting to see what build improvement you get from that. pacs eat everything still, afaiu
<re_irc>
<@adamgreig:matrix.org> just for emitting a "no_mangle extern "C" fn main()"
<re_irc>
<@dirbaio:matrix.org> -1 from me. The only advantage is compile time, and only if you're aleady not using any other proc macro. In any reasonable-sized project most likely you're already using some other proc macro. Serde, defmt derives...
<re_irc>
<@jamesmunns:beeper.com> might be a good pair for rals :D
<re_irc>
<@dirbaio:matrix.org> and the syntax for that macro is horrible
<re_irc>
<@dirbaio:matrix.org> -1 from me. The only advantage is compile time, and only if you're not aleady using any other proc macro. In any reasonable-sized project most likely you're already using some other proc macro. Serde, defmt derives...
<re_irc>
<@dirbaio:matrix.org> if there was "declarative attribute macros" then sure, but there isn't
<re_irc>
<@therealprof:matrix.org> : I agree.
<re_irc>
<@dirbaio:matrix.org> and do we really want to maintain 2 macros that do the same?
<re_irc>
<@mabez:matrix.org> What about allowing a feature to disable compilation of the macros, then let the users manage making the "no_mangle extern "C" fn main()"?
<re_irc>
<@adamgreig:matrix.org> I wonder if we could "stabalise" the API instead, so if someone doesn't want to use the macro, they can just write the extern fn themselves, and then the macros could be made optional
<re_irc>
<@adamgreig:matrix.org> beat me to it
<re_irc>
<@adamgreig:matrix.org> you could still ask "why", though, there's not much gain except for some compile time in very small projects
<re_irc>
<@therealprof:matrix.org> Convince the rust team to provide a built-in attribute?
<re_irc>
<@dirbaio:matrix.org> 👍️ to stabilizing the ABI. I've needed to bypass the macros in the past, to avoid the "HardFault" trampoline
<re_irc>
<@adamgreig:matrix.org> ah, true, it might mean we could support that
<re_irc>
<@adamgreig:matrix.org> I don't think we foresee wanting to _change_ that ABI either
<re_irc>
<@dirbaio:matrix.org> (but that could also be achieved by supporting trampoline-less HardFault in the macro)
<re_irc>
<@jamesmunns:beeper.com> happy to help write a semiformal doc, basically capturing the current abi reality, similar to what I did for the postcard spec: https://postcard.jamesmunns.com/
<re_irc>
<@jamesmunns:beeper.com> like, I don't think we have to go all AAPCS32 on it, but "enough to stick a versioned abi on it" doc is something I can help with, if we go that way.
<re_irc>
<@adamgreig:matrix.org> I guess really the ABI is just rust, though, and "API" is more accurate
<re_irc>
<@jamesmunns:beeper.com> (honestly like everything already exists in the code docs and comments)
<re_irc>
<@adamgreig:matrix.org> yea, you can already just write these functions yourself, the docs just don't promise to not change them one day
<re_irc>
<@adamgreig:matrix.org> how would we make the macros optional in that case?
<re_irc>
<@adamgreig:matrix.org> given that all the PACs just depend on c-m-rt, typically without setting default-features=false...
<re_irc>
<@jamesmunns:beeper.com> well, if you have the written abi, and the current (proc macro) crate meets it, and the alternative (mbe) crate meets it, we have a standard?
<re_irc>
<@dirbaio:matrix.org> non-default feature? and then have people confused by why aren't the macrosworking
<re_irc>
<@dirbaio:matrix.org> * macros working
<re_irc>
<@dirbaio:matrix.org> honeslty
<re_irc>
<@dirbaio:matrix.org> * honestly
<re_irc>
<@dirbaio:matrix.org> I don't think it's worth the trouble
<re_irc>
<@dirbaio:matrix.org> also, it should be possible to write the proc macros without "syn"/"quote"
<re_irc>
<@dirbaio:matrix.org> _that_ would optimize compile time with no downsides
<re_irc>
<@dirbaio:matrix.org> treating the function body as a black box instead of parsing it
<re_irc>
<@dirbaio:matrix.org> (probably would have to remove the "static mut" transform)
<re_irc>
<@jamesmunns:beeper.com> could we do it all in asm + linker scripts, no macros? :p
<re_irc>
<@jamesmunns:beeper.com> maybe not without specifying certain names/no mangle
<re_irc>
<@adamgreig:matrix.org> it already is all asm and linker scripts, really
<re_irc>
<@adamgreig:matrix.org> the macros just emit functions with particular names that the asm/linker script knows about
<re_irc>
<@adamgreig:matrix.org> right now we don't document those names or promise they won't change, so you couldn't rely on it yourself, but nothing stops you doing it anyway
<re_irc>
<@adamgreig:matrix.org> documenting them seems fair enough, but making the macros optional in cmrt seems much more annoying for more marginal benefit, perhaps
<re_irc>
<@adamgreig:matrix.org> though yea if they could avoid syn/quote that might be enough of a win
<re_irc>
<@jamesmunns:beeper.com> I'd generally prefer "keep cmrt as-is, but document the requirements so alt impls are on firmer ground" as preferrable to last-mile tweaks like living without syn.
<re_irc>
<@adamgreig:matrix.org> well, an alt impl would have to bring its own linker script and startup, so can have its own names anyway
<re_irc>
<@adamgreig:matrix.org> you can't use just cmrt's startup and linker script without necessarily having its macros available atm
<re_irc>
<@adamgreig:matrix.org> and there's no obvious benefit to sharing the names with an alt impl, because nothing outside of cmrt needs them
<re_irc>
<@adamgreig:matrix.org> (though, _still_, we could document them)
<re_irc>
<@romancardenas:matrix.org> Can you currently skip using the macros with hardcoded function names? If so, maybe a feature gate could be enough
<re_irc>
<@halfbit:matrix.org> speaking of cmrt was there ever any consensus on code/data placement attributes?
<re_irc>
<@adamgreig:matrix.org> you can use hardcoded function names, but that doesn't stop the macros being compiled; adding a feature gate would be a breaking change or we'd make it on-by-default, but since all the PACs depend on cmrt, it would end up enabled anyway
<re_irc>
<@romancardenas:matrix.org> I see... So then all the PACs and HALs would need an update
<re_irc>
<@adamgreig:matrix.org> yea, so it seems on balance not that worthwhile
<re_irc>
<@adamgreig:matrix.org> ok, thanks everyone, I'll add some notes to the issue thread
<re_irc>
<@dirbaio:matrix.org> I think this is good to go. Shall we merge it?
<re_irc>
<@dirbaio:matrix.org> seems are not around though
<re_irc>
<@grantm11235:matrix.org> Oh, there was one more bikeshed about the pwm trait that I almost forgot about
<re_irc>
<@adamgreig:matrix.org> yea, I think it's had plenty of discussion, happy for the hal team to decide and merge it
<re_irc>
<@adamgreig:matrix.org> oh no
<re_irc>
<@grantm11235:matrix.org> It's really minor though, just renaming "SetDuty" to "SetDutyCycle"
<re_irc>
<@dirbaio:matrix.org> and the method too?
<re_irc>
<@grantm11235:matrix.org> yeah
<re_irc>
<@dirbaio:matrix.org> and should the other methods be "set_duty_cycle_fraction" etc?
<re_irc>
<@grantm11235:matrix.org> hmm, maybe
<re_irc>
<@therealprof:matrix.org> : Also happy to merge it.
<re_irc>
<@dirbaio:matrix.org> is "duty" incorrect?
<re_irc>
<@dirbaio:matrix.org> probably, it's a shortening of "duty cycle"
<re_irc>
<@adamgreig:matrix.org> it's definitely short for either duty cycle or duty factor, yea
<re_irc>
<@grantm11235:matrix.org> Is it a commonly accepted shortening, or are we just being lazy?
<re_irc>
<@adamgreig:matrix.org> eugh. it's common enough to me that I didn't think anything of it being "SetDuty" but
<re_irc>
<@adamgreig:matrix.org> I think it's almost always written out as duty cycle in prose, even if you might just say duty in speech occasionally
<re_irc>
<@adamgreig:matrix.org> yea, I think +1 on renaming it
<re_irc>
<@grantm11235:matrix.org> I just googled "pwm duty", and almost every result was "duty cycle"
<re_irc>
<@adamgreig:matrix.org> whether the methods should be set_duty_cycle_fraction or just set_fraction I don't know, but when you call methods you don't usually write the trait name so perhaps they should be renamed too
<re_irc>
<@dirbaio:matrix.org> renamed
<re_irc>
<@adamgreig:matrix.org> the more interesting google is like "50% duty -cycle" and see if you get _anything_ about pwm :P
<re_irc>
<@jannic:matrix.org> Also probably something which won't be called from too many places, so an ugly long name wouldn't matter much.
<re_irc>
<@adamgreig:matrix.org> cool, well you have a +1 from too, so I think go ahead if you're happy
<re_irc>
<@grantm11235:matrix.org> I'm not as sure about "set_duty_cycle_on"
<re_irc>
<@adamgreig:matrix.org> maybe write up a quick note that in conclusion we'll keep the panic-on-denom=0 and expect that in the majority of cases the compiler will see through and remove it
<re_irc>
<@dirbaio:matrix.org> : what name would be best? "set_duty_cycle_fully_on"?
<re_irc>
<@grantm11235:matrix.org> Maybe keep it as "set_on"?
<re_irc>
<@grantm11235:matrix.org> : Kinda, but not really. There aren't pulses anymore
<re_irc>
<@adamgreig:matrix.org> it's still 0% or 100% duty cycle though, pulses or no
<re_irc>
<@dirbaio:matrix.org> or "fn set_duty_cycle(u16)", "fn set_duty_cycle_fully_on()"
<re_irc>
<@adamgreig:matrix.org> it's a shame it's so long but I don't have any better suggestions, though it might be worth putting the new names in and giving it a day or two for comments before merging
<re_irc>
<@adamgreig:matrix.org> (I think set_duty_cycle_fully_on etc is clearest)
<re_irc>
<@explodingwaffle101:matrix.org> full_duty_cycle? not sure what the opposite would be though
<re_irc>
<@grantm11235:matrix.org> I read the word "fully" too many times, now it has lost all meaning
<re_irc>
<@therealprof:matrix.org> : "off duty" 😉
<re_irc>
<@dirbaio:matrix.org> renamed to names with "fully", I think I like them a bit better
<re_irc>
<@adamgreig:matrix.org> : haha yea same, and also duty
<re_irc>
<@adamgreig:matrix.org> "set_cycle_on" 😆
<re_irc>
<@romancardenas:matrix.org> Imho I'd stick to set_duty_cycle(u16) and just forward 0 or 100 and forget about these corner cases
<re_irc>
<@therealprof:matrix.org> : lol:" error: failed to select a version for the requirement `cortex-m-rt = "=0.7.1"` candidate versions found which didn't match: 0.7.3, 0.7.0, 0.6.15, ..."
<re_irc>
<@newam:matrix.org> I agree with delay being infallible to be useful.
<re_irc>
<@chrysn:matrix.org> Sorry for necrocommenting, just a line: having a defmt-0.3 feature sounds like the right way to go for me. I'm maintaining a crate with what is now some "minicbor_0_19" style features, and it seems to evolve fine.
<re_irc>
<@therealprof:matrix.org> : I don't see much difference in use TBH.
<re_irc>
<@adamgreig:matrix.org> : "minicbor_0_19" rather than "minicbor-0.19"?
<re_irc>
<@newam:matrix.org> : If you need to have a retry loop to use a delay then you can't really get a consistent delay.
<re_irc>
<@jannic:matrix.org> : "cortex-m-rt = "=0.7.1" # 0.7.2 bumped its MSRV higher than embedded-hal's"
<re_irc>
<@adamgreig:matrix.org> yea, it seems fine to tell hals to make sure the delay doesn't fail, one way or another
<re_irc>
<@chrysn:matrix.org> : The latter would have been the better choice.
<re_irc>
<@therealprof:matrix.org> : I don't think the idea is that a delay would fail sporadically (i.e. retry is not necessary). If it's infallible then basically it would panic!, you can get the same result by simply unwrapping the result.
<re_irc>
<@dirbaio:matrix.org> pending some redesigning the API
<re_irc>
<@dirbaio:matrix.org> and pending decision on what to do with APIs that must have all transactions upfront (Linux, and apparently esp-idf as well lol!)
<re_irc>
<@dirbaio:matrix.org> which I guess will be the same solution as SPI? (buffer writes, then allow max 1 read?)
<re_irc>
<@dirbaio:matrix.org> (though the esp-idf case seems to be a limitation of the C API, not of the hardware. The bare-metal esp-hal could impl the trait fully)
<re_irc>
<@adamgreig:matrix.org> that's all for today, thanks everyone!
<re_irc>
<@therealprof:matrix.org> : "error: package `cortex-m-rt v0.7.3` cannot be built because it requires rustc 1.59 or newer, while the currently active rustc version is 1.56.0"
<re_irc>
<@dirbaio:matrix.org> lol
<re_irc>
<@dirbaio:matrix.org> oh it was due to inline-asm, right?
<re_irc>
<@therealprof:matrix.org> I think so.
<re_irc>
<@dirbaio:matrix.org> bumped further
<re_irc>
<@dirbaio:matrix.org> the other option is to not bump, and pin "cortex-m-rt =0.7.0", but it's not worth it imo...
<re_irc>
<@dirbaio:matrix.org> 1.59 is 1 year old alreayd
<re_irc>
<@dirbaio:matrix.org> * already
<re_irc>
<@dirbaio:matrix.org> does linux i2cdev "predefine" the address?
<re_irc>
<@dirbaio:matrix.org> like, do you define it upfront in devicetree and then get a device with a fixed address, where you can do reads/writes without specifying the address?
<re_irc>
<@dirbaio:matrix.org> I wonder if the i2c device should have a predefined address or not
<re_irc>
<@dirbaio:matrix.org> like, you pass an i2c device to the driver with the predefined address, and the driver can only do reads/writes to that address
<re_irc>
<@grantm11235:matrix.org> I think you get a file handle, then you set the address for your specific file handle?
<re_irc>
<@grantm11235:matrix.org> So you can have multiple file handles for the same bus, but each handle can have the address set independently
rardiol has quit [Ping timeout: 252 seconds]
<re_irc>
<@firefrommoonlight:matrix.org> : I am not familiar with parallel busses. Is this a GPIO bitbang thing?
<re_irc>
<@firefrommoonlight:matrix.org> If so and from a skim of that link and the discussion, I would say no: The scope of the HAL here in this context is to provide an API for using the GPIO peripheral. I think this layer would fit on top, but I don't quite understand it
<re_irc>
<@firefrommoonlight:matrix.org> Unrelated: Is "cargo-flash" SWD, DFU (USB), or either?
<re_irc>
<@firefrommoonlight:matrix.org> If DFU-capable, how do you think it compares to "dfu_util" standalone exe? I suppose a key diff is the former works from within a Rust directory, while the later works using a binary, eg compiled by "objcopy"
<re_irc>
<@grantm11235:matrix.org> : Actually I don't think that address setting ioctl is relevant when you are using the transaction api
<re_irc>
<@grantm11235:matrix.org> When you use the "I2C_RDWR" ioctl, you pass it an array of "i2c_msg" structs, each of which has it's own address field