Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
  • 21:57
    Gisleburt commented #418
  • 03:07
    bradleyharden synchronize #434
  • 03:04
    bradleyharden synchronize #434
  • 02:29
    bradleyharden synchronize #434
  • May 12 01:09
    bradleyharden synchronize #434
  • May 11 17:17
    kiranshila starred atsamd-rs/atsamd
  • May 11 16:49
    ewwaller closed #439
  • May 11 16:49
    ewwaller commented #439
  • May 11 15:12

    sajattack on master

    Add support for the P1AM-100 bo… (compare)

  • May 11 15:12
    sajattack closed #431
  • May 11 14:47
    Gisleburt synchronize #418
  • May 11 14:29
    bradleyharden commented #438
  • May 11 14:20
    VictorKoenders commented #438
  • May 11 14:19
    VictorKoenders commented #438
  • May 11 14:13
    VictorKoenders edited #438
  • May 11 14:12
    Gisleburt synchronize #418
  • May 11 13:01
    bradleyharden commented #438
  • May 11 01:01
    twitchyliquid64 commented #431
  • May 11 00:08
    quentinmit synchronize #431
  • May 10 07:40
    quentinmit commented #431
quentin
@quentinmit:matrix.org
[m]
Can you implement a trait for a tuple?
bradleyharden
@bradleyharden:matrix.org
[m]
For D21+ it's implemented directly on PinIds. For D11 it's implemented on tuples of PadNum and PinId
Yes
quentin
@quentinmit:matrix.org
[m]
Ah, makes sense.
bradleyharden
@bradleyharden:matrix.org
[m]
Now I just need to clean all that stuff up and document it. Unfortunately that's low on my priority list. The only reason I'm working on it now is because this is the fun/interesting part and I enjoy doing it. Documentation is less so
quentin
@quentinmit:matrix.org
[m]
:)
jessebraham
@jessebraham:matrix.org
[m]
The eternal struggle
quentin
@quentinmit:matrix.org
[m]
So you really don't like the idea of using Pin types for the arguments?
bradleyharden
@bradleyharden:matrix.org
[m]
No, because it's a pain if you don't already have aliases. Say I have a custom board and I want to swith my Pads struct to use SERCOM0 with PA08. I first have to go look up which peripheral function of PA08 corresponds to SERCOM0. Then I have to manually create my own alias for the pin, Pin<PA08, AlternateX>. Then I can use that alias to define the Pads type. But ultimately that AlternateX is redundant information. SERCOM0 and PA08 is enough information already
quentin
@quentinmit:matrix.org
[m]
Only on D21+ though
I wonder, could you support both at the same time?
bradleyharden
@bradleyharden:matrix.org
[m]
Hmm. Probably
I wouldn't be opposed to that
Wait, no that might be harder than I thought
quentin
@quentinmit:matrix.org
[m]
(I definitely love the pin type aliases, and I do think it makes a much cleaner experience, so I would encourage you to think about adding them to more BSPs...)
bradleyharden
@bradleyharden:matrix.org
[m]
Did you catch my comment about PinId aliases? I can add them alongside the pin aliases. So you could use Spi0MisoId, which would be the PinId for Spi0Miso
That's an easy addition to bsp_pins!
quentin
@quentinmit:matrix.org
[m]
Yeah, I still am not a fan of using less-specific types like that...
and it doesn't work for D11
bradleyharden
@bradleyharden:matrix.org
[m]
But you didn't want to include the PadNum when specifying the spi::Pads type
quentin
@quentinmit:matrix.org
[m]
I'm all for flexibility. Let people use whichever style they want.
bradleyharden
@bradleyharden:matrix.org
[m]
I'm not sure I follow your rationale
quentin
@quentinmit:matrix.org
[m]
Let me try to come up with a coherent rationale.
bradleyharden
@bradleyharden:matrix.org
[m]
It seems like you're optimizing for one narrow use case, the declaration of functions and type aliases in a BSP. But there are lots of other cases
quentin
@quentinmit:matrix.org
[m]
Only if the BSP provides type aliases.
As you pointed out (yesterday?), there are plenty of cases where users of BSPs also need to name the full types.
I want to keep the full type name as simple as possible. I think both spi::Pads<Sercom1, PA08, PA11, PA09> and spi::Pads<Sercom1, Spi0Miso, Spi0Mosi, Spi0Sck> meet that criteria.
If the user isn't defining their own board (which is hopefully the 90% case), I don't want the user to have to know that Spi0Miso or d14 is actually PA08.
A type alias would resolve that, but in BSPs that are using bsp_pins! now you have two confusingly-similar types, Spi0Miso and Spi0MisoId. The user is already probably going to be using the former when putting pins in variables.
quentin
@quentinmit:matrix.org
[m]
I think part of my reticence is coming from the fact that pin names and Pin types are separate and not obviously linked. So you could end up with D10Id, Spi0MisoId, and Adc5Id all being aliases for the same type.
bradleyharden
@bradleyharden:matrix.org
[m]
I think that's where we differ. I use the HAL at work, where I have a custom board with a bunch of header pins. There's no point in having a BSP, because the pinout and peripherals are constantly changing. I work from the pin names directly. Exclusively
quentin
@quentinmit:matrix.org
[m]
I guess it's worth pointing out that if the goal is to not have to worry about pad numbers, you've already lost if you're declaring something AlternateC, since the pad number is encoded in the choice of alternate.
I would wager that's a very small minority of the users for the atsamd crate.
bradleyharden
@bradleyharden:matrix.org
[m]
Sure, but I think you're also hyper optimizing for new BSP users. I don't think it's unreasonable for people to realize that the same pin could have different names and different uses. And that there is a difference in type between a PinId and a Pin. The latter is definitely a more subtle thing, but in your use case, the PinId aliases are only used within the BSP anyway
quentin
@quentinmit:matrix.org
[m]
My board might be a bit of a special case there, since there are both internal and external peripherals sharing the same chip pin.
(Certainly as I mentioned once upon a time, it still bugs me that pins only have one name in the pins struct, but I haven't come up with a decent way to avoid that yet.)
bradleyharden
@bradleyharden:matrix.org
[m]
I don't think we should define the API based on what is easiest to alias or explain to new users. We should define it based on the logic of the thing we're trying to encode. In this case, I'm claiming that a Sercom PinId pair is all the information you need to completely specify a Pad (for D21+), so why add extra, redundant information just to make it slightly easier for new users
quentin
@quentinmit:matrix.org
[m]
I like that it neatly solves the D11 case as well
I think the best thing would be if any of these work, if that's possible.
That way people could use pin aliases if they have them, pin ids if they're unique, and manual pad numbers if they don't want to use pin aliases.
bradleyharden
@bradleyharden:matrix.org
[m]
I think that would be possible, but not without completely ruining type inference in cases where you don't specify the type upfront (return value or static variable)
quentin
@quentinmit:matrix.org
[m]
Hm
Static variables have the type upfront, no?
I'm currently attempting to experiment with this. rustc doesn't like impl AnyPad for Pin<$PinId, Alternate<$Cfg>> because the AnyPad trait seems to explicitly check it's implemented on a Pad somehow.
quentin
@quentinmit:matrix.org
[m]
Also, it's late for you, you should probably go to sleep :)
bradleyharden
@bradleyharden:matrix.org
[m]
Have a read through the type-level docs I sent earlier. You shouldn't be implementing AnyPad anywhere else, especially not for a Pin. That goes against the purpose of AnyPad
I meant return value and static types are the cases when you do specify the type upfront
quentin
@quentinmit:matrix.org
[m]
I was hoping that by implementing AnyPad for Pin I could use a Pin in all the places that currently require a Pad.
bradleyharden
@bradleyharden:matrix.org
[m]
I'm not really sure that make sense. Pad is just a wrapper for Pin anyway. It exists to enforce that a Pin is properly configured as a SERCOM Pad.
You might want to go through and more fully understand the existing solution before you try to change it