UART 5/6bits char format

I don't think 5 or 6 bits were ever used for "embedded" systems. 7-bit was common for ASCII-only communication, and it's legacy is still with us in email attachment codings, ftp transfers, and certain serial protocols (such as some used by programmable logic controllers). Embedded systems are typically 8-bit, but are far more likely to use

9-bit than 7-bit or less, with an extra bit indicating addresses, start of telegram, control v.s. data, etc.

Having more than 1 stop bit is sometimes useful to give systems a little more time - it's especially helpful if you have a UART without double buffering, or software uarts, or need to turn drivers on and off at the end of characters or telegrams.

Agreed. By the minicomputer era of the late 60's

7-bit was pretty much standard with ASR-33's doing the brunt of the work.

I remember a minor upset between the deaf community and the nascent home computer crowd of the mid seventies. The deaf community were using cheap surplus

5-bit Baudot teletypes for communications and were unhappy that the home computer people were considering the use of the same machines as terminals for their computers. The machines were available essentially free to the deaf community and the concern was that another market would reduce the supply and/or increase the price of the machines.

None I'm aware of. But a single lifetime must still be considered very limited in scope.

There was a lot of excitement with the early teletypes. They went over very well for businesses large enough to afford them. The one I remember used either 5 or 6 bits (I was young then but can't recall any lower case on it or much punctuation but it was small and fit in my dad's office at home.)

Through experimentation years later I found that teletypes, such as the KSR35 and ASR33, consistently operated (unless they were broken) with 2 stop bits. But enough would have trouble with certain streams if 1.5 stop bits were used that I went back to consistently using 2.

One of the devices I modified to turn into a printer was an IBM model

85 electric typewriter. On that one, I carefully calibrated each printer action and inserted appropriate delays in the software, using software buffer controls to allow the host computer to know when to sent more text in order to make the whole thing work well.

The basic thing here is that if the serial stream is used with non- mechanical display systems (glass screens, for example) or host computers, you probably are just fine. If there is some likelihood of a mechanical device there, then 1.5 or 2 may be better. It may also help a little if you want to communicate with another embedded device that uses a software uart that doesn't use finely timed sampling divisions or where it's sampling may be inaccurate.

Depends on the circumstances. You need to weigh the likelihoods against the extra effort, documentation, or after sale phone calls asking "what does this mean?" and so on. Complexity in your device costs money after the sale, even if it is easy to code up, because it has to be supported and educating customers on something this arcane may cost way more than the feature is worth to a few. But if you can mitigate that part well, then why not keep the capability around?

Now, only glancing for a moment at your website, I gather this may be about VHDL functionality. That complicates questions about end use, as you are supplying suppliers and pretty much cannot say what some will care about. But you also can supply a version that supports 1,

1.5, and 2 stop bits as well as a version that only supports 1 stop bit and just see where your customers take you.

Jon

5 data bits + 1.5 stop bits might still be used in some radio amateur radio Teletype (RTTY) communication systems. 6 data bits was common with 36 bit computers (Univac etc.), with (6 bits/char), but I have not seen 6 bit chars in serial communication for more than three decades.

Paul

Cripes. I'd forgotten about 36-bit. PDP-10 comes to mind, now. But they packed them as 7-bit by then, as I recall, so a 36-bit word gave you 5 characters (plus a little.)

Jon

Thanks for all the replies, very helpful,

Hans

Oddly enough, I just ran across an application that requires 6 bit characters. It is an old Brown Boveri protocol from the 70's. Are you developing your driver as a commercial product?

Putting on my "Dilbert dinosaur suit", I did an embedded 5 bit interface in the mid 80's. The task was to make a baudot (5-bit) converter for an early HP inkjet printer that had ASCII (7/8-bit) serial and parallel interfaces. Done with a TI TMS7000 processor.

Look up radioteletype on Wikipedia and you will see that 5-bit is still in use.

Scott

You could almost do that with a UART, a ROM, and a little glue logic?

--
ArarghMail908 at [drop the 'http://www.' from ->] http://www.arargh.com
BCET Basic Compiler Page: http://www.arargh.com/basic/index.html

To reply by email, remove the extra stuff from the reply address.

While some radio amateurs might still use RTTY with 170 Hz frequency shift for historical reasons, most radio amateurs prefer PSK31 or similar more spectrally efficient modes for real time keyboard to keyboard communication.

Paul OH3LWR

Or an FPGA, or... Certainly lot's of solutions. At the time this was in a $500 printer that was "modified" and resold for about $7000. The chosen path was speed of implementation, although I can't remember why we chose that processor. Was not in the main stream of what we typically used.

Scott

Who said "amateurs"?