Parts bin UART receiver

[barnacle]

BigDumbDinosaur wrote:

So when will we be seeing the TxD side of your Frankenstein UART? 

Well, since you ask... untested, but checks out on the simulator.

discrete_uart_tx.pdf

(79.81 KiB) Downloaded 69 times

This needs only three and three-quarter chips, apart from the clock generator.

It's a bit weird; I offset the data into the '165 so that I can tie the first bit low, to generate the start pulse. Remember that UART data is low bit first and the '165 sends bit 7 first, so that's the one that's tied low and the others are all reverse order.

At the same time, D7 is latched into a d-type and the output fed to the serial in during clock 0, then set by the counter during clock 1 to provide the stop bit, and remains high thereafter so Q7 remains high when the clock pulses stop.

Neil

[BigDumbDinosaur]

barnacle wrote:

BigDumbDinosaur wrote:

So when will we be seeing the TxD side of your Frankenstein UART? 

Well, since you ask... untested, but checks out on the simulator...

When you see how much silicon is required, it kind of makes you appreciate a real UART. 

[barnacle]

Well indeed. For the real thing, you'd want rather more error checking, too, and probably at least one level of buffering, not to mention flow control and divisor selection... but sadly, small bus-driven UARTs appear to have gone the way of all flesh. Looks like most of what's out there is 16550-compatible parts with a zillion legs.

Still, if you don't have one to hand, either of these will work in a pinch. And at least they're understandable and don't need any programming

Neil

[Dr Jefyll]

barnacle wrote:

sadly, small bus-driven UARTs appear to have gone the way of all flesh. Looks like most of what's out there is 16550-compatible parts with a zillion legs.

Well, the 16is750 a 16550 register-compatible UART that's still around (although seemingly only in a HVQFN-24 package). But the reason it doesn't have a zillion legs is, it's not bus-driven. Instead, the host interface is SPI (or I2C, depending on whether a certain pin is tied high or low).

So, not quite the same animal. But it's possible to make a little module that plugs into a DIP site (as I did with this now-obsolete 24-TSSOP version)...

-- Jeff

[barnacle]

Yabbut... there's something a bit weird about using a serial interface to, um, talk to a serial interface... kinda non-intuitive.

Though I suppose the big advantage is the self-clocking nature of SPI (I'm not a fan of I2C).

I'd love a parallel memory interface with perhaps a couple of addresses for internal registers, one chip select, one interrupt output, rx and tx, none of the control signals - kind of a cut-down 6850 I suppose. Should fit easily in a 20 pin chip.

Neil

[barnacle]

Though I've just found an odd chip from HGSemi in China - HG82C51N (just about available and in stock at LCSC for a couple of dollars) which has a parallel interface though a maximum baud rate of 38.4k. There are a few spi controlled chips there from Chinese makers a lot cheaper than the usual suspects at Mouser and Digikey, too. They also offer the NXP SC16IS750 and some of its friends.

Neil

[GARTHWILSON]

barnacle wrote:

Though I suppose the big advantage is the self-clocking nature of SPI (I'm not a fan of I2C).

SPI and I²C have somewhat different purposes and applications.  I like them both.  I had to go look though to see if there are any I²C UARTs, because I hadn't heard of any.  Yep, NXP has them, but they have I²C and SPI, both, in the same part.

[plasmo]

ZDU0110.
Admittedly I have not got it to work. Need to look into it again. viewtopic.php?f=4&t=7899&p=105584&hilit=Zdu0110#p105531

[barnacle]

An interesting looking chip - though they do seem to have stuffed everything they can think of in there... but again, it's an I2C interface. At least it's claimed to have a 'works when turned on' function, but I found myself a little confused by their baud rate selection.

Neil

[Dr Jefyll]

barnacle wrote:

there's something a bit weird about using a serial interface to, um, talk to a serial interface...

I agree there's some irony there which may be amusing. But we know irony isn't seriously a factor when deciding how to provide UART capability in a given setting.

The pros and cons of various approaches will differ in importance according to circumstance. For example in a design which needs to be small, or which one intends to overclock, a parallel-interface UART loses points for complicating the address-decode glue, adding capacitance to the bus and increasing its length. In fact there'll be an incentive to de-populate the bus as much as possible (especially if it'll avoid wait states), so one might quite reasonably end up with just a single peripheral on the bus -- a VIA, perhaps -- which, using SPI, manages multiple I/O devices (not just the UART).

- Jeff