applet.interface: Create the uart-pinout applet

[drosseau]

Adds a uart-pinout applet that functions similar to the JTAGulator implementation for determining UART pinouts. Essentially this just sends data to the selected pins at various baud rates and looks for an echo. The default just sends a carriage return (0x0d) if no data is set, but the user can send arbitrary binary data up to 0xFF bytes long.

To make this work I also made some changes to the default UART implementation so I could use it with arbitrary signals instead of just ports. Basically the old UART -> ExternalUART. This allows other applets to repurpose the UART without needing physical pins.

Some example runs against a simple echoing UART 115200 baud:

$ glasgow run uart-pinout -V A=1.8 --pins A0:4 --data-hex '0a0b0c0d'
I: g.hardware.device: generating bitstream ID 34111b9328a0c964f46244d32640a110
I: g.hardware.assembly: port A voltage set to 1.8 V
I: g.cli: running handler for applet 'uart-pinout'
TX[A1] RX[A0] BAUD[9600] DATA[ff80]
TX[A1] RX[A0] BAUD[19200] DATA[ffc4]
TX[A1] RX[A0] BAUD[38400] DATA[fea1fce1]
** TX[A1] RX[A0] BAUD[57600] DATA[0a0b0c0d]
** TX[A1] RX[A0] BAUD[115200] DATA[0a0b0c0d]
TX[A1] RX[A0] BAUD[230400] DATA[9e98]
TX[A1] RX[A0] BAUD[460800] DATA[80e0]
TX[A1] RX[A0] BAUD[921600] DATA[e080]

glasgow run uart-pinout -V A=1.8 --pins A0:4 --data-hex '0a'
I: g.hardware.device: device already has bitstream ID 34111b9328a0c964f46244d32640a110
I: g.hardware.assembly: port A voltage set to 1.8 V
I: g.cli: running handler for applet 'uart-pinout'
TX[A1] RX[A0] BAUD[9600] DATA[ff]
TX[A1] RX[A0] BAUD[19200] DATA[a1]
TX[A1] RX[A0] BAUD[38400] DATA[fe]
TX[A1] RX[A0] BAUD[57600] DATA[0b]
** TX[A1] RX[A0] BAUD[115200] DATA[0a]
TX[A1] RX[A0] BAUD[230400] DATA[ff]
TX[A1] RX[A0] BAUD[460800] DATA[80]
TX[A1] RX[A0] BAUD[921600] DATA[80]

[whitequark]

Thanks. This is a pretty big addition so I'd like it to be split into two PRs: one modifying the UART and one adding the new applet. Please also take a look at our contributing guide.

[drosseau]

Ok I'll split it up and write a better commit message; I forgot to update that for the pull request oops

[drosseau]

After thinking about it, this design is way more complicated than it had to be... way more logic is implemented on the FPGA side than needs to be. I have a different design I'm testing right now that is significantly simpler, but it will still require #1010 to work