Discrete-Logic UART Keeps 8-Bit TTL Computer Connected

August 26, 2020 by Dan Maloney 18 Comments

Pity the poor TTL computer aficionado. It’s an obsession, really — using discrete logic chips to scratch-build a computer that would probably compare unfavorably to an 80s era 8-bit machine in terms of performance. And yet they still forge ahead with their breadboards full of chips and tangles of wire. It’s really quite beautiful when you think about it.

[Duncan] at Shepherding Electrons has caught the TTL bug, and while building his 8-bit machine outfitted it with this discrete logic UART. The universal asynchronous receiver-transmitter is such a useful thing that single-chip versions of the device have been available since the early 1970s. [Duncan]’s version makes the magic of serial communications happen in just 12 chips, all from the 74LS logic family.

As if the feat of building a discrete logic UART weren’t enough, [Duncan] pulled this off without the aid of an oscilloscope. Debugging was a matter of substituting the 2.4576 MHz crystal oscillator clock with a simple 1 Hz 555 timer circuit; the reduced clock speed made it easier to check voltages and monitor the status of lines with LEDs. Once the circuit was working, the full-speed clock was substituted back in, allowing him to talk to his 8-bit computer at up to 38,400 bps. Color us impressed.

For more TTL computer goodness, and to see where [Duncan] got his inspiration, check out [Ben Eater]’s many discrete logic projects — his scratch-built 6502, a low-end video card, or even his take on serial communications.

Asynchronous Routines For C

September 24, 2019 by Al Williams 35 Comments

[Sandro Magi] noted that the async/await idiom has become more prevalent in programming recently. According to him, he first encountered it in C# but has found examples of it in JavaScript and Rust, too. The idea is simple: allow a function to return but come back later to complete something that takes a long time. Of course, multithreading is one answer to this, but generally, this technique implies more of a coroutine setup where functions cooperate to some degree to get good behavior. [Sandro] took some ideas from the existing protothread library and used it to create a system to get this effect in C and, by extension, C++.

Adding this “library” is as simple as including a header file. All the magic occurs at the preprocessor and compiler. There’s no code to link. The async routines only need two bytes of overhead and — unlike proper threads — don’t need a preallocated private stack.

Continue reading “Asynchronous Routines For C” →

Serially, Are You Syncing Or Asyncing?

June 28, 2016 by Rud Merriam 25 Comments

I know you’ve heard of both synchronous and asynchronous communications. But do you really know the differences between the two?

Serial communication was used long before computers existed. A predecessor is the telegraph system using Morse Code, one of the first digital modes of communication. Another predecessor is the teletype, which set standards that are still used today in your Arduino or Raspberry Pi.

All you need is two wires for serial communications, which makes it simple and relatively robust. One wire is ground and the other the signal. By interrupting the power with predefined patterns, information can be transferred over both short and long distances. The challenge is receiving the patterns correctly and quickly enough to be useful.

I was a bit surprised to find out the serial port on the Arduino Uno’s ATmega328P microcontroller is a Universal Synchronous Asynchronous Transmitter Receiver (USART). I’d assumed it was only a UART (same name, just leave out synchronous) probably because my first work with serial communications was with the venerable Intel 8251 “Programmable Communication Interface”, a UART, and I didn’t expect the microcontroller to be more advanced. Silly me. Later I worked with the Zilog 8530 Serial Controller Chip, a USART, the term I’ll use for both device types.

All these devices function in the same way. You send a byte by loading it into a register and it is shifted out one bit at a time on the transmit (TX) line as pulses. The receiver accepts the pulses on a receive (RX) input and shifts them into a register, which is then read by the system. The transmitter’s job is pretty easy it just shifts out the bits at a known clock rate. The receiver’s task is more complex because it needs to know when to sample the incoming signal. How it does this is the difference between asynchronous and synchronous communications.

Continue reading “Serially, Are You Syncing Or Asyncing?” →

What Could Go Wrong: Asynchronous Serial Edition

June 22, 2016 by Elliot Williams 50 Comments

It’s the easiest thing in the world — simple, straightforward serial data. It’s the fallback communication protocol for nearly every embedded system out there, and so it’s one that you really want to work when the chips are down. And yet! When you need it most, you may discover that even asynchronous serial can cost you a few hours of debugging time and add a few gray hairs to your scalp.

In this article, I’m going to cover most (all?) of the things that can go wrong with asynchronous serial protocols, and how to diagnose and debug this most useful of data transfer methods. The goal is to make you aware enough of what can go wrong that when it does, you’ll troubleshoot it systematically in a few minutes instead of wasting a few hours.

Continue reading “What Could Go Wrong: Asynchronous Serial Edition” →

Receiving Asynchronous Data Bursts

April 27, 2012 by Mike Szczys 7 Comments

[Johan’s] been working on a chunk of code for about seven years and he thinks it’s ready to help you with your next project. He calls it D1 (The One) and it lets you receive asynchronous data without the need for a hardware USART. It’s capable of working with signals from an IR or RF remote, as well as tangentially related transmissions like RFID and magstripe readers.

It uses timer and port interrupts to sample the incoming data. Once it’s captured a transmission, the code sets a flag so that you can pull what it got into your own application. If you’re expecting to receive a protocol that sends packets several times in a row a verification module is also included which runs as a precondition of setting the received flag. The package is written in PIC assembly, but with all the information that [Johan] included in his post this shouldn’t be hard to port over to other chip architecture.