Just tried this on my Upduino 2.1 which is the direct successor to, and compatible with Upduino 2.0.

This blinks the green led fine using the 01_blinky.py example as a template.

Thanks for the extra test, jchidley!

Okay, I copied the default test case from the 'icestick' board file, and I changed the local imports to use the same from .resources import * as the other files.

This is sort of embarrassing, though, I'm not quite sure how to run the board file to test it. When I try python3 upduino.py, I get a ModuleNotFoundError:

Traceback (most recent call last):
  File "nmigen_boards/upduino.py", line 6, in <module>
    from .resources import *
ModuleNotFoundError: No module named '__main__.resources'; '__main__' is not a package

But the same thing happens with the 'icestick' board file, so I figure I'm just running it wrong. It does work with a 'blinky' program that calls from nmigen_boards.upduino import * and UpduinoPlatform().build( Blinker(), do_program = True ).

I couldn't work it out either. I am glad that it's not just me!

@WRansohoff slight change: pin 39 should be led_g (led, 0), pin 40 led_b (led, 1), at least on UPduino v2.1

Oh, thank you - is that based on experimentation?

It's not what the schematic says, but I believe you; their readme does say that they switched LEDs because the one on the V2 board went end-of-life. I guess the board file needs renaming after all...

You might want to give the TinyVision people a PR too: https://github.com/tinyvision-ai-inc/UPduino-v2.1/blob/master/Board/upduino_v2.1_release.pdf

@WRansohoff it's based on using my board - delivered from their store a couple of weeks ago. That schematic is definitely not how my board is wired.

What is even weirder is that RGB0 is wired to LED_RED which is pin 41 and (led,2).

I assume that RGB0 refers to some internal definition and that there's a file (somewhere) that translates this to pin 41.

But the same thing happens with the 'icestick' board file, so I figure I'm just running it wrong.

Sort of. Try running it from the root of nmigen_boards checkout.

Ah yes. That's how I did it before but I just couldn't remember

Okay, so...I looked more closely at my Upduino_V2 board, and it looks like its green/blue LEDs are also swapped, with led_g on pin 39 and led_b on pin 40. Weird, does that mean the schematic was always wrong? I guess I don't usually look too closely at which direction a rainbow color is pulsing in.

But on the bright side, it looks like both versions are the same, so it's a small change :)

I still get a ModuleNotFoundError when I run python3 nmigen_boards/upduino.py from the root of the repository with Python 3.6.9. But maybe it's a version thing; it works when I specify the package module with -m, and apparently they made some changes to how imports work in Python 3.3:

python3 -m nmigen_boards.upduino nmigen_boards/upduino.py

I still get a ModuleNotFoundError when I run python3 nmigen_boards/upduino.py from the root of the repository with Python 3.6.9.

Sorry, I was unclear. The way to test a board is to run:

python3 -m nmigen_boards.upduino

from the root of nmigen_boards (or, assuming it's installed on your system, anywhere else).

Sure - I took a look at the 'Versa ECP5' file and tried to copy the formatting. I also noticed that it used inheritance to set up a similar '5G' board file, so I tried doing the same thing with the V1/V2 Upduino boards.

I don't have an Upduino V1 to test it with, but either commit seems to work with the V2 board. Whichever makes more sense, I guess.

Thanks! Normally I would say we shouldn't have completely untested boards, but in this case it seems all good.