Because why not? Even though it's April first, this is serious... and probably the world's most brain dead UART receiver. It samples properly in the centre of the bit period but doesn't do exciting things like checking for a full start bit or stop bit, or indeed overflows if you fail to read it in time.
With no buffer you need to read the result within ten bit periods (86us for 115,200), so unless you're sitting in a tight loop waiting, an interrupt is probably the only practical option.
The intent is to use it as a receiver immediately after an FT232 so the signal will be clean and correctly timed (though the 16x master clock allows the usual 5% differential timing error).
<pdf removed; see below>
Enjoy
Neil
Edit: To clarify: the aim with this small design is to use standard 74 family parts, easily available in through hole or SOIC. So it's ended up with four ttl chips and a spare AND gate, all pretty common parts I think.
Last edited by barnacle on Mon Apr 01, 2024 11:28 am, edited 2 times in total.
Great job! Such a minimal serial receiver can go into a small CPLD while saving rest of macrocell resources for other functions. Minimal, yet functional is the way to pack lots of features into a small CPLD.
Bill
It's similar, but the '8153 requires two properly formatted UART words to give one eight-bit output. The received data contains three bits of target address which has to match the '8153 address pins. That's how I loaded my recent-ish romless SBC, with separate '8153s to store the data and address, using the data received output to write the data into memory.
But it takes a carefully crafted conversion from a hex/bin to an object file to get the right data in the right place.
This just takes a standard UART-232 stream (logic levels, not RS-232 levels) and outputs it one bit at a time. (Also this will work I suspect well in excess of 115,200 while the '8153 is restricted to about 20,000, and required a shade over four words per memory write in my application.)
So... I finally got round to building it, and it works.
Fifty percent of the time...
It looks like there's a race hazard I hadn't thought of. The idea is that the sequence starts when the low going edge of the start bit sets U2A, clearing the ~Q output and enabling the counter U1. Every time its Q3 output goes high, at count 8, the current input signal level is clocked into U3. When it goes low again, U1B increments its count. When that count is nine, it asynchronously resets U2A (and also triggers the data latch U4 and sets the ~RXF flag), which resets U1 back to zero.
So after nine counts, nine bits of data have been clocked in, including the start bit which by now has been discarded; the received byte has been latched, and the rx received bit has been set. Now we're waiting for the next start bit, since we're now looking at the stop bit.
Or are we? It appears that depending on the phase of the master (1.8MHz) clock at the time of the first start bit, and the relative speed of the data source clock, it is possible for the counters to reset a few nanoseconds before the rising edge of the stop bit. And that's a problem, because in that case, U2A is in an indeterminate state. Whichever of the ~S and ~R resets rises last will rule, and if the input is still low when the reset pulse rises, then things will immediately start counting again... straight into receiving an all-ones signal.
The issue is down to the relative timings of the serial clock and the count; one is in the middle of the bit and one at the end; sometimes the one at the end arrives too soon.
There is an easy answer, I think, which I'll check this morning; a three input NAND to replace U5A. That should inhibit the reset until the stop bit is high. If that doesn't work, I'll need to look at the count detection logic a little harder.
Nand that makes all the difference (sorry!)
Two words read due to the end of the last bit being read as a new start bit (so eighteen clocks).
And with the reset inhibited until the input goes high (i.e. the stop bit starts), just the nine clocks for a single read that we expect.
Here's the circuit built on my dual-mode proto board, the oscillator at the bottom, the serial chip is the only SOIC on here. I didn't bother with the latch at this point.
Not as small as a single chip solution, but as an input only serial port it's handy (and not limited by system clock speed) and cheap
Hmm... well that's the easy part, probably. Lemme think on it... I suspect the basic idea could be very similar, but I should really count to ten to include the stop bit to keep the far end happy. The start bit may be an issue.
