Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    quentin
    @quentinmit:matrix.org
    [m]
    Shouldn't Baudrate be a trait, with HAL-specific implementations?
    Why does that require a concrete type?
    As long as the HAL-specific type implements From<i32>...
    Here's what I'm noodling with:
    Introduce a UsartHal trait with associated types Event and Baudrate
    rahix
    @rahix:matrix.org
    [m]
    hm, it might work
    although there is this added complication with the BaudrateArduinoExt which implements some board-specific errata
    quentin
    @quentinmit:matrix.org
    [m]
    The problem I'm having is that I can't figure out how to shove CLOCK into that
    since Baudrate needs to be Baudrate<CLOCK>
    rahix
    @rahix:matrix.org
    [m]
    I think this should be a part of UsartOps
    quentin
    @quentinmit:matrix.org
    [m]
    it seems like that CLOCK needs to propagate up the type tree into UsartHal<CLOCK>
    but that also seems wrong to me because that's baking in the assumption that baud rate calculation is based on a clock
    I'm not sure we should assume that all usarts require a clock
    for example, a usart in synchronous mode does't need a clock
    rahix
    @rahix:matrix.org
    [m]
    right, but you could always set CLOCK to a placeholder type for those cases
    quentin
    @quentinmit:matrix.org
    [m]
    (I also think Usart is a bit misnamed... it seems to me like it only supports asynchronous mode right now)
    You could, but it feels like it's maybe the wrong abstraction layer
    I feel like there should be a HAL-specific UsartSettings type
    e.g. with bits/parity settings as well
    (currently hardcoded in raw_init)
    rahix
    @rahix:matrix.org
    [m]
    yeah, this could work well. So raw_init takes UsartSettings which is an associated type of UsartOps
    1 reply
    quentin
    @quentinmit:matrix.org
    [m]
    What is the reason most of these types take an H type parameter that is just an empty struct called Atmega?
    rahix
    @rahix:matrix.org
    [m]
    That's needed due to the orphan rule
    because were implementing a foreign trait for a foreign type...
    quentin
    @quentinmit:matrix.org
    [m]
    Because the peripheral is in a different crate?
    rahix
    @rahix:matrix.org
    [m]
    exactly
    quentin
    @quentinmit:matrix.org
    [m]
    Do you think you could take a look at the WIP branch I have with the ADC changes to see what you think?
    rahix
    @rahix:matrix.org
    [m]
    Currently on my way to work, but I can take a closer look this evening if that's alright with you
    quentin
    @quentinmit:matrix.org
    [m]
    Okay, what timezone are you?
    It's 01:50 here
    rahix
    @rahix:matrix.org
    [m]
    UTC+2
    quentin
    @quentinmit:matrix.org
    [m]
    Gotcha
    I... should be awake again by then :P
    rahix
    @rahix:matrix.org
    [m]
    Maybe open a draft PR already, that's the best way to keep track of everything :)
    quentin
    @quentinmit:matrix.org
    [m]
    It's definitely not mergeable :)
    Are you okay with that?
    1 reply
    rahix
    @rahix:matrix.org
    [m]
    That's what the "draft" status is for ;)
    and thanks a lot for helping with this work, I never had too much to do with the tinies, so that's why everything seems to fit so badly for them...
    quentin
    @quentinmit:matrix.org
    [m]
    rahix
    @rahix:matrix.org
    [m]
    thank you very much :)
    quentin
    @quentinmit:matrix.org
    [m]
    I also sent Rahix/avr-device#84 for the corresponding svd stuff.
    Is this the best Matrix room for discussing these crates, BTW?
    rahix
    @rahix:matrix.org
    [m]
    yes
    quentin
    @quentinmit:matrix.org
    [m]
    cool
    have a good day at work then :)
    my goal is to get to a hello world of a program that can do echo over serial
    I imagine SPI and I2C are both going to require similar work since the registers are so different
    rahix
    @rahix:matrix.org
    [m]
    yeah... the idea is that the Ops trait abstracts over all MCUs and then there's an impl_ macro for implenting it for each of the concrete peripheral blocks. So let's hope the *Ops traits for those are already close enough, otherwise we'll have to tweak them as well...
    quentin
    @quentinmit:matrix.org
    [m]
    (I mentioned arduino-hal only because that's where the board pin aliases live)