New board: Fluff M0 Headless

[deshipu]

This is the same as Fluff M0, but disables the MSC, CDC and MIDI USB
endpoints. This is useful for devices like keyboards or mice running
CircuitPython, once we are happy with their code and don't want to
change it anymore.

I'm adding this board mostly so that we have a test for this case.

[ajs256]

Looks like you forgot to add it to build.yml.

[dhalbert]

Add the headless board to tools/ci_check_duplicate_usb_vid_pid.py; it's complaining right now that the two Fluff boards have the same PID.

[tannewt]

Are we sure we want this? This seems like a very board-specific change for a non-board specific problem. @dhalbert was recently talking about a way to disable the pieces of a USB descriptor from boot.py.

[deshipu]

There is no telling when the dynamic USB descriptors will be implemented — we have been talking about them for years, and they are not a very important feature, but there are few people with the expertise. On the other hand, I have a number of devices that rely on this, and that got broken with #4283 — if we had this earlier, we would have caught the problem. I suppose it's a trade-off between build times and coverage.

By the way, I did this with Fluff M0, because that's what I'm using, but I would be happy to do it with any other board instead, as long as we exercise the case with MSC disabled.

[dhalbert]

I think there are two reasons to have this:

1. You have a project used by multiple people that depends on no MSC (like the stenotype project I think you mentioned), and it is impractical to supply a custom build for that. That is what I though the original motivation was.
2. We need to test whether various compilation flags actually work or not. This particular flag is one of many. I could imagine adding a test build that compiles a single language and board multiple ways. I would do it different than adding a new board, because we don't need to generate builds for multiple translations to test a flag like this.

[deshipu]

Since I'm not actually selling those projects yet, I am mostly concerned with 2. If you think there is a better way to test this, please feel free to close this.

[dhalbert]

OK, I will close. I think the point you are bringing up is well-taken: we don't have a testing story for things like this, and we need to think about it in the long run.

[tannewt]

Do we have an issue to add these tests?