Useful, efficient software
matches the user's needs, knowledge and skill. Don't buy a
swiss army knife when you need a wrench...
|
![]() |
|
About Us
|
![]() |
|
A young company still hungry for challenges, with 30+ years of experience with software development from small
embedded systems to distributed real time PC networks and SQL databases. A reasonable design effort to deliver
high-quality software e.g. for medical devices on schedule. |
|
External Links
|
![]() |
|
Customers
Other sites
|
|
![]() |
|
Symbol
set
In
embedded systems we will probably need to be able to transfer any byte
in the message plus maybe some extra symbols for protocol handling that
is not part of the message.
If one code is
reserved as Escape code the 256 symbol set expands into
a 510 symbol set (assuming ESC+ESC is illegal),
whereof 254 could be used for control.
In
a channel where it i only safe to transmit ASCII codes from 33 to 126
(printable, non-blank), we have 94 symbols. Using one as an escape
symbol we have 93+93=186 symbols available. With two different escape
codes we have 92+92+92=276 symbols available with one or two bytes
sent, enough to transmit any byte plus a few extras for protocol.
A
similar example is SLIP framing that reserves the bytes 300 and 333
(octal) for symbols END and ESC. This means these codes are not read
into the message buffer but has a meaning for the protocol only. To
deliver the code 300 (octal) to the message the combination 333+334
are transmitted over the channel, and to transmit 333, 333+335 are
transmitted. Thus all bytes can be transmitted though the END and ESC
byte values are transmitted double length.
Transmitted a message containing bytes 300 and 333 (quoted the reserved
END and ESC codes).
You can use as many control chars as feasible and
invent escape codes to replace them in the message. Escaped bytes have
double length so whether to use reserved byte codes or escaped codes
for control depends on whether some byte values are less frequent than
the escape codes. E.g. if bytes have random distribution the
probability of having the escape in the message is 1/256, and if
messages are 8 byte length on average you will use 32 single byte
control codes per dual byte escaped code, earning 31 bytes compared to
escaping the control code.
Longer messages give less benefit and when message length exceeds
symbol set size you gain by escaping the control byte.
There is also a risk having a multi-symbol combination for
framing that
with a fixed bit error rate the risk doubles to get a bit error in a
two-symbol code compared to a single-byte code, and control codes tend
to be more serious to miss than regular data bytes since you can add
error detection/correction codes to data but not to control symbols
since these are used to find the error detection codes.
In
some systems certain codes never are transmitted though they are
transmittable over the channel. Some systems need to send only ASCII
and the 8th bit can be used to signal control codes.
<
Previous
|
Escaped
symbols have the drawback of worst case transmission length twice the
length of the original message (imagine wanting to send a number of ESC
symbols as data). There are some ways to make message length
independent of content
of message is to use a subset of the byte bit-packed, similar to Base64
or the older UUEncode
or XXEncode.
that packages 2 bytes in 3, using 6 bits per byte for payload. With a
fully 256-code binary raw symbol set, Using 7 bits of payload per byte
allows us to send 7 full bytes in 8 transmitted bytes.
| 0aaaaaaa |
0abbbbbb |
0bbccccc |
1cccxxxx |
3
bytes encoded into 4 where the most significant bit indicates last byte
(x is don't care). Or you could send one byte of 8th bits like this:
| 0abcxxxx |
0aaaaaaa |
0bbbbbbb |
1ccccccc |
Slightly trickier is using 9 bit
symbols when we can only transfer 8 bits.
| aaaaaaaa |
abbbbbbb |
bbcccccc |
cccxxxxx |
Here
we can use 9 bit symbols and define several escape symbols, but if we
lose sync it is trickier to find the starting point since it can be any
bit in the byte. Also we need to eliminate any shifts of the framing
symbol(s) to guarantee that don't misinterpret data for framing. E.g.
if framing is nine consecutive ones, we could disallow codes starting
or ending with five or more ones thus nine ones can never be generated
by two adjacent symbols. We lose 32 codes out of the 512 which gives us
plenty of extras to play with. Shifting bits is a bit compute intensive
though so this would work for slow transmissions or be implemented in
hardware.
To gain even less overhead we could package several bytes
using e.g. 15 bytes out of 16 for data, or 31 out of 32. Note though
that we often want to send short messages and with longer codes we will
have more waste at end of communication. Also we lose a number of codes
to prevent the framing pattern to accidentally appeear in the input
stream.
Principally
the set of symbols including protocol symbols could be packed
arithmetically into a bit-streamed message similar to btoa utility.
Btoa generates a packet of 5 bytes computed with base-85 arithmetics
from 4 data bytes. With one escape code we could convert the whole
messagerequiring only one extra byte required per message up to 1415
bytes. This number n is determined from the inequality:
256^n <= 255^(n+1)
Using ESC, START, FRAME and ACK as reserved inequality becomes:
256^n <= 252^(n+1)
allowing one extra byte per 351 effective bytes.
The arithmetic message length requires a lot of computing
power though (base conversion with bignums
is tedious).
Next
>
|
|
