What a $15 FT232H can do on a bench

Most people meet the FT232H as "the USB-to-serial chip". It is, but it also has a mode FTDI calls MPSSE — a small synchronous serial engine that can be told to speak I2C, SPI or JTAG, with whatever pins are left over usable as plain GPIO. Adafruit's breakout is about $15. The FT2232H has two such channels; the FT4232H has two plus two extra UARTs. If you already own one of these for flashing something, it is quietly one of the most flexible instruments on your bench.

Scryglass drives all three, plus the FT232R and FT231X for UART. This post is what that looks like in practice.

One channel, four jobs

Each MPSSE-capable channel — the only channel on an FT232H, A and B on the 2232H and 4232H — can be set to one of four modes from the Devices page:

mode	bus pins	free GPIO
UART	TXD, RXD (+ flow control if you want it)	none
8 GPIOs	—	AD0–AD7
I2C + 5 GPIOs	AD0 SCL, AD1/AD2 SDA	AD3–AD7
SPI + 4 GPIOs	AD0 SCK, AD1 MOSI, AD2 MISO, AD3 CS	AD4–AD7

(Channels C and D on an FT4232H are UART only; the chip doesn't give them an MPSSE.)

Switching modes is a config change, not a driver reinstall — though the channel has to be idle, and Scryglass refuses the switch while anything is open on it rather than corrupt a transaction halfway through.

Whatever mode you pick, the result is a set of ordinary Scryglass channels: a UART channel, an I2C or SPI bus channel, and one GPIO channel per free pin. They show up next to your PPK2 current trace and your debug-probe RTT output on the same timeline, because that's the whole point.

GPIO

In full GPIO mode all eight pins are yours, each independently input or output. Outputs are driven from the GPIO widget, from a recipe, or from an MCP tool call, and each change lands on the timeline as an event. Inputs are polled every 500 µs and every level change is an edge on the timeline — so a button, a DRDY line, or a firmware's debug pin becomes something you can search, count, and measure latency against.

The more interesting case is the spare pins in I2C or SPI mode. They aren't second-class: AD3–AD7 (I2C) or AD4–AD7 (SPI) work as outputs and as continuously-monitored inputs while the bus is running. Polling on a shared MPSSE has to interleave with bus traffic, so the interval there is 2 ms rather than 500 µs, and the driver also samples the pins in-band at the end of every transaction. On the bench, with an FT4232H under continuous I2C load, that caught 100 out of 100 toggles on a spare input.

The practical upshot: an interrupt line from an I2C sensor, wired to AD7, gives you a GPIO edge on the timeline and the register write that caused it, from one $15 board and no extra hardware.

I2C

The FT232H is an I2C controller — it initiates transactions. Scryglass exposes scan, write, and write-then-read (the register read idiom), with clock presets from 1 kHz to 5 MHz and a 100 kHz default. Repeated start is supported; clock stretching is tolerated passively; addressing is 7-bit.

Every transaction is recorded with its address, direction, register pointer and bytes, so the I2C channel on the timeline is a log you can query: show me every write to 0x20 register 0x0A in the last ten minutes, or reconstruct what this device's register file looked like at 14:03:12. The bytes aren't decoded — that's your datasheet's job — but the hex is right there.

A few things worth knowing from experience. Above 1 MHz you need the pull-ups tuned or you'll see garbage. The 3.4 MHz and 5 MHz presets are write-only in practice. And on the FT4232H specifically, targets that stretch the clock hard (a Teensy in target mode, say) are unreliable at 100 kHz and above — drop to the 10 kHz preset for those.

SPI

Controller only, full duplex, all four SPI modes, MSB-first, 8-bit words, a single chip-select on AD3. Clock from about 458 Hz to 30 MHz, default 1 MHz; if you ask for a rate the divider can't hit exactly, you get the next one down, never an overclock. Each transfer records the bytes out and the bytes in.

The one-CS limit is the thing most likely to bite. If you have two SPI devices on the bus, the second one's chip-select is a spare GPIO you drive yourself before the transfer — which works, and is on the timeline, but it's manual.

Macros and recipes

Bus operations can be strung into macros — sequences of READ, WRITE, SCAN, TRANSFER and DELAY steps saved with the project — and run from the UI, from a recipe, or from an MCP client. Recipes can trigger on a GPIO edge. Put those together with the spare-pin input above and you get: when the sensor's INT pin on AD7 falls, run the macro that reads its status and data registers, and annotate the timeline with the result. No firmware on the host side, no scripting, and every step is a timestamped event you can scroll back to.

Which board is which

Cheap FTDI breakouts often ship with a blank EEPROM, which means no USB serial number, which means the operating system can't tell two identical boards apart — and neither can any software, reliably, across a replug. We hit this ourselves with two FT4232Hs: a project mapped to one board would end up driving the other after a re-enumeration.

Scryglass's fix is to offer to burn a serial. When it reads a genuinely blank EEPROM (not a failed read — those it leaves alone) it asks, generates one of the form FT plus six characters, writes it with FTDI's own library for that chip type, and asks you to unplug and replug once. After that the board is the same board forever, and your channel mappings survive.

Getting it talking

Scryglass uses FTDI's D2XX library, built in — nothing to install on Windows or macOS beyond what a plain FTDI board already needs. On Linux the kernel's ftdi_sio driver grabs FTDI devices first and blocks D2XX; Scryglass detaches it per interface when it opens the board and reattaches on release, so your /dev/ttyUSB* comes back when you're done. A udev rule for permissions ships with the package.

Timing, honestly

FTDI boards have no clock of their own and no hardware timestamping. Every GPIO edge and bus transaction is stamped with the host clock at the moment the driver saw it — which means the poll interval plus USB latency, so roughly a millisecond of uncertainty on a bitbang pin and a couple on a spare MPSSE pin. That is plenty for correlating a sensor interrupt with a UART line or a current spike. It is not a logic analyser, and edges narrower than the poll interval on a spare pin will be missed.

What it isn't

Being clear about this saves everyone time:

• Not a sniffer. The FT232H is a bus controller. It can't passively capture traffic between two other devices on the bus; for that you want a logic analyser.
• No JTAG or SWD through Scryglass. The MPSSE can do it, and probe-rs can drive FTDI boards, but Scryglass's FTDI driver claims the device first and the probe path isn't wired to it. An ESP-Prog works with probe-rs standalone, not as a Scryglass debug probe.
• ADBUS only. The ACBUS/CBUS pins aren't exposed.
• No PWM, no internal pull-ups, no hardware edge capture — the chip has none of these.
• I2C is 7-bit; SPI is MSB-first with one CS.

None of that is a knock on the chip. It's a $15 part doing four jobs; the list above is the price of the other three.