macOS: use baud rate of 3,000,000 (supported by Apple driver)

[tony-iqlusion]

4 megabaud is not supported by the Apple-supplied driver is used for FT4232H (AppleIntelCNLUSBXHCI). Per the discussion on #63, installing the FTDI driver is basically unworkable because the signature fails to verify, which has been reproduced by several other people. It seems the options are:

1. If you have an Apple Developer ID, sign it yourself (we don't but maybe we should!)
2. Disable system protections 😱
3. Give up and accept the limitations of the Apple driver

We can look into the first option but for now I just tried to make things work with the Apple driver.

I semi-arbitrarily picked 128 kbaud as a standard baud rate and one which divides evenly into the 80MHz reference clock (by 625), and that appears to be working:

Testing of standard baud rates shows it caps out at 3,000,000 baud:

Running `usd-runner target/armv7a-none-eabi/debug/examples/hello`
Hello, world!
(device has reset)

I didn't experiment with making it faster than that as the other standard baud rates higher than that do not divide evenly into 80MHz (and doing non-integer division with UBMR/UBIR was breaking my brain), but otherwise this is at least a PoC that the runner works on macOS at a lower baud rate.

[tony-iqlusion]

I think it'd be interesting if we could make this "just work" so it uses a lower baud rate if the host is a Mac.

[japaric]

Below is a table with standard baud rates and the UBIR / UBMR values they map to. formula: baud_rate = 5e6 * (UBIR+1) / (UBMR+1) where: UBIR < 16 && UBMR < 65536

baud rate	UBIR	UBMR
115200	9	433
230400	9	216
460800	6	75
500000	15	159
576000	2	25
921600	6	37
1000000	0	4
1152000	2	12
1500000	2	9
2000000	1	4
2500000	0	1
3000000	2	4
3500000	6	9
4000000	15	19

I'm not sure how to check which baud rates are supported on macOS but at least on Linux you can do this:

$ stty -F /dev/ttyUSB2 115200 && echo OK
OK

and if it prints OK then 115200 is a baud rate the device supports

[tony-iqlusion]

I tried the stty method of probing and for whatever reason it fails after 115200.

Using the table above and trying various settings, the Apple driver seems to work all the way up to 3_000_000 but fails at 3_500_000. I'll update the PR to use that.

Perhaps that's good enough to merge for now (i.e. take a 1Mbaud performance hit on Linux) and then we can look into ways of using 4_000_000 on Linux in a follow-up?

[japaric]

Perhaps that's good enough to merge for now (i.e. take a 1Mbaud performance hit on Linux)

Sounds good to me! I'm going to merge this.

and then we can look into ways of using 4_000_000 on Linux in a follow-up?

PR #66 is one way to do that.