USB VCP chip like CP210x but without UART?

[bson]

I have a vintage CPU without a serial port, but would like it to talk to a USB virtual com port.  I don't want to have to add a UART just for this, so would love to find something that *looks* like a UART to the CPU, so has a TX FIFO, an RX FIFO, interrupt on FIFO levels, etc.  Just like if it *were* a UART!  But of course the serial clocking etc doesn't really need to happen internally, just USB packets IN/OUT.  Preferably 3.3V SMT (the CPU is 5V but this goes on a 3.3V latched and buffered bus).  Does such an animal exist?

Edit: looks like the FT232H will do this, with parallel access to the FIFO... but I'd strongly prefer something other than FTDI!

[PCB.Wiz]

I have a vintage CPU without a serial port, but would like it to talk to a USB virtual com port.  I don't want to have to add a UART just for this, so would love to find something that *looks* like a UART to the CPU, so has a TX FIFO, an RX FIFO, interrupt on FIFO levels, etc.  Just like if it *were* a UART!  But of course the serial clocking etc doesn't really need to happen internally, just USB packets IN/OUT.  Preferably 3.3V SMT (the CPU is 5V but this goes on a 3.3V latched and buffered bus).  Does such an animal exist?

That's a bit vague - you have not said what connections you do have, just what you want to avoid.
You will need some wires ....

If you have a latched bus, there are USB chips that can attach to that,, that can look like a VCP to the PC side.
One example
https://ftdichip.com/products/ft240xq/

[PCB.Wiz]

Edit: looks like the FT232H will do this, with parallel access to the FIFO... but I'd strongly prefer something other than FTDI!

Perhaps look at the WCH CH341 ?

[bson]

That's a bit vague - you have not said what connections you do have, just what you want to avoid.
You will need some wires ....

CS#
RD#
WR#
D0-D7

[Postal2]

... but I'd strongly prefer something other than FTDI!

I agree. Use C8051F320/1.

[PCB.Wiz]

... but I'd strongly prefer something other than FTDI!

I agree. Use C8051F320/1.

In 2024, that would be the more active / newer variants of EFM8UB10 / EFM8UB20

[Postal2]

.... EFM8UB10 / EFM8UB20 ....

May be. But for C8051F320 I have starter kit.

[bson]

With a µC I'd have to latch the bus for it though, otherwise there's no way it could even react to a control register write...  and if I'm going to have multiple ICs I might as well just drop a 16C550 and a CP210x in there... Unless we're talking like 2000 wait states!

I decided neither of the two FT232H interface options really work.  In "CPU-like" mode it has no way to interrupt on rx high/tx low leading to polling and a timer set to 100Hz or something to keep checking it for rx and tx status.  In "FIFO" mode it can interrupt, but while writing or read there's no way to know how much is available (when tx is full or rx is empty), while the external status pins only signal rx full and tx empty, which is useless while draining/filling a FIFO...  Basically whoever designed this interface doesn't understand how software works; the only way it can work is read or writing (maybe both) a single byte per interrupt.  So why even have FIFOs.  The FT232H is a dead end for this, but I don't see anyone else who has even tried...

An FPGA could work, but I'd still be stuck trying to find a VCP implementation (some sort of softcore presumably) and then likely till need an external USB PHY.  But it could also do other useful things, like a software-friendly sdio interface and perhaps implement an RMII ethernet controller.  Perhaps one exists that has all these internally and I'd just need to present them via peripheral registers on an 8/16-bit 3.3V bus.  Still, lots of complexity and a project in itsel, very tangential to what I'm doing.  (A small NS32016 board to boot the last version of NetBSD to support it, cross built with the last version of gcc to support it, with a fair bit of driver work.)  Also, if I do put a bunch of basic peripherals in an FPGA I'd like to be able to update it over the serial port, which means the FPGA probably shouldn't implement it in the first place.  But maybe other things.

[langwadt]

..
In "FIFO" mode it can interrupt, but while writing or read there's no way to know how much is available (when tx is full or rx is empty), while the external status pins only signal rx full and tx empty, which is useless while draining/filling a FIFO...  Basically whoever designed this interface doesn't understand how software works; the only way it can work is read or writing (maybe both) a single byte per interrupt.  So why even have FIFOs.  The FT232H is a dead end for this, but I don't see anyone else who has even tried...

if that was the case many UARTs wouldn't work either, which is of course not the case

you are not limited to one byte per interrupt, you can keep writing as long as status pin doesn't signal full and you can keep reading as long as status pin doesn't signal empty. Just like many UARTs with FIFOs work ..

[quadtech]

Something like this?

https://www.morethantechnical.com/blog/2014/06/24/simple-attiny85-usb-board/