UARTResource flow control signals direction mismatch for ICEStickPlatform

[igrr]

I've noticed that dtr and rts signals of UARTResource are defined as outputs, but on the IceStick they are actually inputs, according to the schematic.

I see two options for fixing this:

1. Add role argument (dce/dte) to UARTResource, similar to SPIResource; set the direction of the flow control pins based on the role; set correct role for ICEStickPlatform.
2. Assume that UARTResource is only going to be used with role=="dce", and reverse the direction of flow control pins. This might (?) break some designs.

I can submit a PR for either of the options, would appreciate some guidance which one to choose.

Thanks for maintaining this project!

[whitequark]

Option 1 seems ideal. Just to confirm, there is electrically no way to use the UART as currently defined on the icestick, right?

[whitequark]

Oh, and please submit the change to UARTResource and to the board as two separate PRs.

[igrr]

Just to confirm, there is electrically no way to use the UART as currently defined on the icestick, right?

This could be possible by storing custom FT2232H pin configuration into the EEPROM, but I haven't tried.

Is it possible to define two overlapping resources ("uart" and "uart_dte"), and let the user choose which one to claim? One resource would use dce role, the other one dte.

[whitequark]

Is it possible to define two overlapping resources ("uart" and "uart_dte"), and let the user choose which one to claim? One resource would use dce role, the other one dte.

Yes, but if this requires reflashing the devboard, it's probably best to leave this up to add to whoever uses the platform.

Speaking of which: do you think you could take a look at the other board and figure out if DTR/RTS are swapped on them, too? I think most FPGA boards are configured as DCE (correct me if I'm wrong), and you might actually be the first to care about the direction of those signals, so it's quite possible that our default is wrong and should be switched.

[igrr]

Sure, I can. There are only 3 boards so far which use the flow control signals. Will check the schematics and include the changes into the 2nd PR.

[igrr]

Turns out things get a bit complicated with some existing boards.

For example, nexys4ddr: the platform file defines rts="D3", cts="E5". This doesn't match the schematic, though (https://reference.digilentinc.com/_media/nexys4-ddr:nexys_4_ddr_sch.pdf — RTS is E5, CTS is D3). So the pins have likely been swapped in the platform definition to make it useable with signal directions defined in UARTResource. If i now restore the signal names used in the schematic, and set role="dce" in UARTResource, this would be "correct", but would break existing projects based on that board. This repository is pre-1.0, so I suppose some breaking changes are allowed, the question is, how much breakage is acceptable?

[igrr]

Same story with ice40_hx8k_b_evn: PR m-labs/nmigen-boards#41 has swapped DTR/RTS as a fix for incorrect direction. But the problem is, the direction is still incorrect for the remaining signals (like rts/cts). And for some signals (like ri), there is nothing to swap them with!

[whitequark]

This repository is pre-1.0, so I suppose some breaking changes are allowed, the question is, how much breakage is acceptable?

This is a clear screwup that we shouldn't be stuck forever. Let's just tear this bandage off early and do things properly; it's not that many boards.

Once we get nmigen-boards on PyPI I'm going to use package versions to indicate breaking changes so that people get a bit more visible notice.