Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    rahix
    @rahix:matrix.org
    [m]
    alright, then I'll go ahead and get all those changes merged now
    enaut
    @enaut:matrix.org
    [m]
    And thank you so much for solving my problem immediately!
    rahix
    @rahix:matrix.org
    [m]
    heh, no problem :) if you need anything else let me know!
    enaut
    @enaut:matrix.org
    [m]
    I will get better and bother you with harder problems 😛
    rahix
    @rahix:matrix.org
    [m]
    haha, challenge accepted :p
    enaut
    @enaut:matrix.org
    [m]
    Rahix (Rahix) I have ported the blink and the adc example (the second without the temperature) see pr
    *ported to the atmega168
    rahix
    @rahix:matrix.org
    [m]
    nice, thanks! :)
    enaut
    @enaut:matrix.org
    [m]
    rahix - in the pr you requested to change the comment to Nano 168 - shouldn't that be consistent with the verbose naming in the feature doc: "Nano clone (ATmega168)"?
    or do you prefer the more readable variant?
    rahix
    @rahix:matrix.org
    [m]
    honestly it does not matter much at all - I just was a bit weary about reading "Arduino" in code related to a board which is not an official one
    so choose whatever you think is best, it's not important ;)
    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