Add OrangeCrab board.

[tdaede]

I have not tested this beyond the basic blinky/button test.

[miek]

There are also a bunch of r0.1 boards in the wild and it'd be nice to support those later, so maybe this should get a version number in the name before merging?

[tdaede]

Realized that LUNA has an OrangeCrab platform. I'll see if I can make the nmigen platform match. https://github.com/greatscottgadgets/luna/blob/master/luna/gateware/platform/orangecrab.py

[tdaede]

Updated to better match LUNA, but there are still some differences:

• RGB LEDs, button, and SPIFlash use dedicated resource type rather than generic Resource.
• DDR3 interface uses ecp5-versa names rather than LUNA names. Don't know which one is better.
• SD card uses SD interface names rather than SPI.
• User IO is exposed only via a Connector.

[gregdavill]

Would it be worth passing the version in as a default parameter, and call it the OrangeCrab platform, instead of embedding the revision number in the class name?

This is how we're handling it on litex: https://github.com/litex-hub/litex-boards/blob/master/litex_boards/platforms/orangecrab.py

[tdaede]

I looked at the schematics and they seemed to be quite different. Indeed looking at the litex platform, there's almost no shared code, so it's mostly a style choice.

[whitequark]

Would it be worth passing the version in as a default parameter, and call it the OrangeCrab platform, instead of embedding the revision number in the class name?

In nmigen-boards the convention is to have different classes for materially different platforms; parameters are reserved for things such as jumpers that change IO voltage and so on.

[whitequark]

Arguably the dfu-suffix step should be a part of the normal build process, but this is a complex change I wouldn't insist you make here.

[tdaede]

I have the option of running dfu-util on the un-suffixed binary as well by manually passing vid/pid, which I considered doing, though it doesn't yield a distributable .dfu which is slightly annoying.

[whitequark]

Meanwhile can you submit the RGB LED changes as a separate PR?

[whitequark]

@tdaede Okay, I think the last thing that's left is dfu-suffix. Can you do something similar to this:

def required_tools(self):
    super.required_tools + [
        "dfu-suffix"
    ]

def command_templates(self):
    super.command_templates + [
        r"""
        {{invoke_tool("dfu-suffix")}}
            -v 1209 -p 5af0 -a {{name}}.bit
        """,
    ]

and check that it works?

PS: I pushed to this branch, careful

[whitequark]

It's kind of weird to just have the DFU suffix on the bare bitstream file, but provided that (a) dfu-util is the primary method of programming this board and (b) this shouldn't inherently break other uses, we can just merge it and fix any breakage in the future should it arise.

[tdaede]

Annoyingly dfu-suffix has no -o option, and I don't want to put a dep on cp. There is still the bare bitstream into dfu-util option.

The main reason I could see this breaking in the future is if any sort of dependency tracking is added, as dfu-util will reject putting multiple DFU suffixes on.

[whitequark]

The main reason I could see this breaking in the future is if any sort of dependency tracking is added, as dfu-util will reject putting multiple DFU suffixes on.

Definitely not, the approach used by edalize was considered and rejected a long time ago.

[whitequark]

Thanks!