Traditional UART's talk to the host CPU via a parallel inteface, but it's wonderful how much space you can save using SPI or I2C instead. The UART pin count is reduced, and the devices themselves tend to be small -- like the 16is750 I purchased.

• Single full-duplex UART
• Selectable I2C-bus or SPI interface
• 3.3 V or 2.5 V operation
• Industrial temperature range: 40 C to +95 C
• 64 bytes FIFO (transmitter and receiver)
• Fully compatible with industrial standard 16C450 and equivalent
• Baud rates up to 5 Mbit/s in 16x clock mode
• Auto hardware flow control using RTS/CTS
• Auto software flow control with programmable Xon/Xoff characters
• Single or double Xon/Xoff characters
• Automatic RS-485 support (automatic slave address detection)

Due to the .65 mm lead pitch on the TSSOP package, PCB mounting is the norm. But for wire-wrap or breadboard applications I designed a breakout board to bring the connections onto a .1" grid. The design is slightly unusual because the 24-pin chip is accommodated on a breakout board only .3" wide. To accomplish this the chip is spun 90 degrees to what you might expect.Edit: although a 1.8432 MHz crystal is shown, much higher frequencies are possible. Crystals up to 24 MHz are permitted, and 24 MHz is acceptably close (.15% error) to thirteen times 1.8432 MHz. If an external clock signal is applied (no crystal) the limit at 3.3V is 80 MHz!

The 16is750 "speaks" SPI or I2C depending on whether pin 8 is low or high, respectively. The connections for some of the pins accordingly differ, as shown above. I provided a jumper for pin 8 but overlooked the need to un-ground pin 13 when in I2C mode -- doh! But 2 cuts and a wire patch will overcome that, as shown in the lower half of the diagram. Pin 13 (SDA) can be patched onto pin 17 (GPIO2). Someday I may do a revised design to fix the oversight but my main interest is SPI anyway, so...

The board will use a crystal in the skinny, cylindrical package, and three caps go on the bottom: a supply bypass, and a 22pF (0402ZK220GBSTR) and 33 pF (0402ZK330GBSTR) for the oscillator. The design is presently untested. Although I have some boards I haven't actually assembled a unit yet. But meanwhile I might as well share the info.

As shown, the board occupies the space of an 18-pin .3" DIP. But some applications won't require GPIO0 to GPIO3. Therefore the breakout pads for these are located at one end of the board, allowing the board to be shortened if the signals aren't required. With 4 GPIO's trimmed off, this UART breakout fits in the space of a 16-pin DIP!

-- Jeff

Very nice!

That's a bit bizzare, a serial interface to a serial interface device. Seems weird to use. What's next another serial interface ?
Why not just implement the RS232 in software on a microcontroller ?

Hi, Jeff. Well done. I assume you'd have to use the SPI interface on that device for the higher baud rates since the I2C interface tops out at 400-Kbits/s?

Not to detract from your post, but, you might be able to duplicate most of the capabilities of that device using relatively inexpensive PIC devices which still come in DIP-14 or DIP-20 packages.

I tested this on my little 3-chip design with its built-in high-speed (4-Mbit/s) SPI port using a 14-pin 16F1705 ($1.38). I used 256 byte Tx and Rx FIFO buffers and tested it up to 115,200 baud but it could theoretically support speeds up to 4-Mbit/s with the 32-MHz clock I was using at the time.

Have fun... Cheerful regards, Mike

<grin>That's not a bad way to go -- kinda fun, actually. I bit-banged a UART for 65C02, and another for 8741A (a sibling of the 8041 that's used as the keyboard controller in PC's). But the A in UART stands for asynchronous, and it means you can't take liberties with the timing. In contrast, with SPI or I2C it's OK if an interrupt occurs during the bit-bang sequence. Also, you have freedom to vary the system clock speed should you wish to do so.

Another consideration, with this particular UART at least, is that it offloads the host by managing a lot of stuff on its own, such as address recognition, transmit & receive FIFO's, and hardware handshaking.

Thanks, Mike! And you're right; I2C might have a problem dealing with the highest baud rates. But it's not actually the baud rate per se which limits you. It's the FIFO size, compared to the length of incoming messages. You can receive high baud rate transmissions successfully as long as the receive FIFO doesn't overflow. And, during transmit, the UART will be idle most of the time with its transmit FIFO empty. But it will work -- and there's no limit on the size of messages you transmit. So, the high baud rate itself is not a problem. Subject to certain limitations, even I2C lets you communicate with a system that uses a high baud rate.

(Come to think of it, this capability, albeit limited, for very high baud rates is another advantage over a bit-banged UART as discussed in the previous post.)

Yup. Nowadays there are lots of different options on how to get a job done, and inserting an entire system (CPU-memory-IO) into the signal chain is a trivial decision, cost-wise. Like, $1.38 -- holy cow! BTW maybe you'd like to describe your three-chip system for us.

Nice chart, BTW. But, um... "PIC SPBRG" ??? (Sounds like a pun on the name of a well-known city.)

Hi Jeff.

The more recent PIC 16F17xx series feature PPS (Peripheral Pin Select) which allows you to assign I/O pins to the SPI, I2C, EUSART, and other peripherals. Older 'legacy' devices wouldn't allow you to configure an SPI port along with a Serial port at the same time since those peripherals often shared 'hard-wired' I/O pins.

The "three chip" 65C02 design was described briefly over on 6502.org but I've not finished or published any details yet. It's basically a 65C02 running at 1-MHz (no clock stretching, no wait states), a 64K RAM, and a PIC. The latter provides reset, clock, loader, and decoder functions while mapping its serial peripherals (UART & SPI) into a single page in 65C02 address space. Actually, all 230 PIC "special function registers" show up in that page of memory so you have to be careful. For example, one pair of addresses belongs to the FSR0L and FSR0H registers which the PIC uses to access the 256 byte decoder map array at $0100..$01FF in PIC data memory. If you had multiple 256 byte decoder maps, the 65C02 could write the FSR0H register on-the-fly to affect a simple MMU. That is, you could have five different maps controlling chip select lines that you could use to map different 16K blocks from a 128K RAM into a particular section of 65C02 address space. Also, since the PIC firmware doesn't use the FSR2L/FSR2H/INDF2 registers, the 65C02 could use them to indirectly read/write PIC RAM memory ($000..$EFF). While there are potential hazards involved by exposing all 230 PIC SFRs to the 65C02, I had to do it that way to get it all to run at 1-MHz (with this particular PIC).

Have fun... Cheerful regards, Mike

I'm struck by the novelty of what's going on here! The PIC utterly controls the 'C02, interpreting the addresses it outputs and even providing the 'C02 with its clock source. But at the same time the 'C02 is very much in control of the PIC. The PIC in effect is saying, "here are my buttons -- you can push them if you like!"

Fun stuff, Mike!

Here's a quick update re the breakout board. As you can see, the entire board is the size of a DIP IC. In this case the socket on the motherboard is customized to accept four extra pins. The device is functional, and I've already begun using it to transfer some files -- even though I haven't bothered to establish the hardware handshaking yet. Instead, the software includes a delay loop to keep things sufficiently slow.

FWIW, the Wikipedia article on I²C says, "Recent revisions of I²C can host more nodes and run at faster speeds (400 kbit/s Fast mode, 1 Mbit/s Fast mode plus or Fm+, and 3.4 Mbit/s High Speed mode)." It also mentions a 5.0 Mbit/s max in the box near the top-right corner of the page. I suppose all the ICs on the I²C bus would have to be able to handle whatever rate you go though, to be able to detect the start and stop conditions and understand the address. I've seen SPI-interfaced UARTs, but until now, I have not seen an I²C-interfaced one (although I have not searched).

That turned out very nice, Jeff...

Thanks, Mike. I'm pleased with it. But it was designed in a hurry, and if I were to do it over again there'd be some minor changes.

As noted in the lead post, the mode selection mechanism (SPI vs I2C) is incomplete. I provided a jumper for pin 8 but overlooked the need to un-ground pin 13 when in I2C mode. (I described some PCB cuts to cure that.) Also, SDA got routed to one of the four pins along the bottom -- pins I intended to be optional, to perhaps be trimmed off as a space-saving measure. But if you wanna use I2C mode then SDA is mandatory, not optional.

Incidentally, the SMD capacitors for the crystal required me to boldly go where my soldering skills hadn't gone before.

-- Jeff