Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    enaut
    @enaut:matrix.org
    [m]
    either me or my git allways gets confused... sometimes both... :) I work too much alone...
    but now it should be as desired in the pr (force pushed)
    enaut
    @enaut:matrix.org
    [m]
    what are good settings for rust-analyzer? Currently it is allways failing with the macros like ufmt::uwriteln! so whenever I open a project or file depending on avr-hal it is complaining about so many problems.
    rahix
    @rahix:matrix.org
    [m]
    I just disabled the lint complaining about those macros
    enaut
    @enaut:matrix.org
    [m]
    ok
    quentin
    @quentinmit:matrix.org
    [m]
    I'm trying to add attiny support to arduino-hal and I was wondering if there's anyone who could help with some of the trickier generics/trait bounds
    rahix
    @rahix:matrix.org
    [m]
    👋
    Although I am not quite sure, what you want to do? attinies by themselves belong into attiny-hal
    quentin
    @quentinmit:matrix.org
    [m]
    rahix: The main thing is that avr-hal-generic makes a bunch of mega-specific assumptions
    So I need to figure out how to move the mega-specific stuff into atmega-hal and make avr-hal-generic generic to allow a corresponding implementation in attiny-hal
    rahix
    @rahix:matrix.org
    [m]
    what in particular? the only mega-specific things should be contained in the impl_* macros
    so for tiny, the idea would be to write a second impl_* macro in avr-hal-generic which can then be used in attiny-hal
    quentin
    @quentinmit:matrix.org
    [m]
    (e.g. I filed Rahix/avr-hal#201 with slightly more specifics for the usart types.)
    rahix
    @rahix:matrix.org
    [m]
    hmm, I see
    quentin
    @quentinmit:matrix.org
    [m]
    Likewise the adc module has ReferenceVoltage baked into avr-hal-generic, though I think I've already successfully teased that apart.
    rahix
    @rahix:matrix.org
    [m]
    well Baudrate should stay a type valid for all supported MCUs, not a HAL specific one, IMO. But I agree that we need to maybe move the calculation logic into the mega-specific impl_ macro instead, to accommodate for attinies
    quentin
    @quentinmit:matrix.org
    [m]
    If it's a generic type then it shouldn't have ubrr and u2x fields.
    1 reply
    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