RFC: How should Adafruit's Feather M0 boards be organized

[BenBergman]

Adafruit's Feather line has something like 5-10 M0 variations depending on how you want to count the different radio variations. Should there just be one board module for all Feather M0 boards or should there be a new board folder for every single one?

[BenBergman]

I should add that the boards all have identical pin aliases for the exposed pins. They only differ in whatever the added external peripheral is (wireless radio, SD card, etc).

[sajattack]

I think just one for the Feather M0 Express and then people can use that with all the feather variants, adding on drivers for the peripherals as needed.

[sajattack]

I have a Feather M0 Express coming in the mail tomorrow :smile: Are you working on a Feather M0 PR? If so I can help test, otherwise I can do it.

[BenBergman]

Yup, PR #22. Note that the Feather M0 Express is the only one with an SPI flash chip, so maybe the Basic Proto one is the one that should act as the base?

[wez]

Targeting the basic proto as a base seems like a sane plan and should avoid proliferation of board crates.

We can perhaps add little helper crates for the peripherals; for example, the blefriend module is available as a breakout as well as bundled up with an M0 Feather. A crate for managing the SDEP protocol to speak with that seems like a fine idea and doesn't strictly require that we define a separate feather board crate just for that use case.

I know that @sajattack is interested in UF2 support, so it is probable that we'll end up with board crate for the Express variant to tie together the right features and easier to use out of the box.

Let's keep a watch on the amount of boilerplate in these crates and be prepared to use some macros or other techniques to keep it small.

[wez]

13 is a related issue that I haven't had bandwidth to think about so far, and I think this is a good time to consider both issues.

For this specific issue, I think defining macros like define_spi!, define_i2c! and define_usb! can help to reduce the boilerplate while allowing some flexibility to express the pins for the boards. I think the aspiration should be that the individual board crates will comprise of just the lib.rs file to define the pins and make it convenient to access the major peripherals/buses.

I'm thinking that using something like this would be helpful to replace eg: the current spi_master function that we have in feather_m0; we'd arrange for it to expand to the current function body:

/// Convenience for setting up the labelled SPI peripheral.
/// This powers up SERCOM4 and configures it for use as an
/// SPI Master in SPI Mode 0.
define_spi!(spi_master, SERCOM4, Pb11, Pb10, Pa1);

We could do something similar for the other buses.

[BenBergman]

That sounds great to me.

I'm also wondering if the SPI/I2C/etc initialization functions can somehow get a more ergonomic interface, perhaps via macros. From my I2C example in the itsybitsy_m0 module:

let i2c = hal::i2c_master(
        &mut clocks,
        KiloHertz(400),
        peripherals.SERCOM3,
        &mut peripherals.PM,
        pins.sda,
        pins.scl,
        &mut pins.port,
);

Setting that up for the first time, I had a hard time trying to figure out where to get SERCOM3 and PM from. Thankfully clocks was pretty straight forward, but it seems like it is always the same part of peripherals. Similarly the port will always be the same and, since the initializer is for a specific I2C configuration, the pins will always be the same too. This just leaves the speed as the only thing the user would want to set specifically.

Maybe that is just a necessary complexity for now given the current state of the embedded-hal and the fact that we can't borrow peripherals once clocks has been borrowed out of it, but if there is something we do to make it a bit more ergonomic that would be excellent.

[sajattack]

@BenBergman I have now tested your feather_m0 PR as well. Great work!