Column: Embedded design
assuming that the transmitter timing error is zero. Practically (as there is always a sender and a receiver) that comes down to a maximum of 2.5% error at each end. In a world of cheap 50ppm accurate
crystals and even cheaper 0.5% ceramic resonators, 2.5% is not an unreasonable specification, unless you are using the internal-to-the-chip oscillator on a Microchip PIC, or similar processor. These oscillators are pretty good, but, at between 2-3% nominal and 5% at extremes, not quite good enough for a totally reliable RS232 link – despite the fact that many engineers take the risk and use them anyway. This calls for a better solution.
Serial port timing There are several methods that derive the serial port timing from the incoming data byte, but this usually requires a specially formatted data message, with an identifiable first character from which bit-edge to bit-edge timing measurements can be extracted. Entirely feasible, but complex. I am proposing a different method:
Only use the first (for example) six data bits, and ignore D6, D7 and the stop bit. Then we only need to retain ±0.5 bit accuracy over 6.5 bit periods, and that’s just 7.7%. This means that – if the accuracy at the sending end is good – we can use a 5% accuracy clock at the RX end. Take a look at a table of ASCII
characters in Table 1. If looking closely at the binary values, something becomes evident. Providing you are only trying to recover numerical and upper case alpha, you can ignore the upper two bits and just work with the lower six. However, there are limitations: The
control codes (column 1) become indistinguishable from column 3 – a
In a world of cheap 50ppm accurate crystals and even cheaper 0.5% ceramic resonators, 2.5% is not an unreasonable specification
particular case is the <CR> control code, that maps through onto the M character. Also, the punctuation and numerics in column 2 relate similarly to the lower case letter in column 4. But, provided that this limitation can be accepted, then a perfectly usable “6 bit ASCII set” can be realised; see Table 2. To convert back to “real” ASCII, it
is only necessary (after trapping any relevant control codes) to set bit 6 if bit 5 is a zero.
Framing There is one final problem, and that is framing. The observant reader will have noticed that we have quietly ignored the stop bit along with the “un-timed” data bits. So how do we frame the character and be ready for the next start bit? The key is to realise that the 8th bit (D7) is always zero for normal ASCII codes. This allows us to use a bit of a trick: After sampling the midpoint of D5, wait for 2.5 bit periods (the juncture between D7 and the stop bit) and then wait until a logic 1 level is seen, which is the stop bit. At 7.7% error this timing point can have shifted by 0.7 of a bit, which still puts us either in D7 (always zero) or ¾ of the way into the stop bit, but still with enough timing slack to handle the received character and be ready for the next start bit edge. This is a limited technique, but
it works and overcomes the clock accuracy limitations of inexpensive microcontrollers.
Table 2: Perfectly usable “6 bit ASCII set” can be realised
Tis column on embedded design prepared by Myk Dormer continues in the next month’s edition of Electronics World.
www.electronicsworld.co.uk October 2025 13
Page 1 |
Page 2 |
Page 3 |
Page 4 |
Page 5 |
Page 6 |
Page 7 |
Page 8 |
Page 9 |
Page 10 |
Page 11 |
Page 12 |
Page 13 |
Page 14 |
Page 15 |
Page 16 |
Page 17 |
Page 18 |
Page 19 |
Page 20 |
Page 21 |
Page 22 |
Page 23 |
Page 24 |
Page 25 |
Page 26 |
Page 27 |
Page 28 |
Page 29 |
Page 30 |
Page 31 |
Page 32 |
Page 33 |
Page 34 |
Page 35 |
Page 36 |
Page 37 |
Page 38 |
Page 39 |
Page 40 |
Page 41 |
Page 42 |
Page 43 |
Page 44
