I recently had a homework question that I got half credit on:

I said yes, if the data was kept in a set number of bits. For example, a text document is transferred from one computer to another using straight ASCII. Every eight bits constitutes a character, therefore only the data would have to be transmitted. The computer could process the incoming data in real-time by processing each byte that comes through into the appropriate character.

If the example document was sent from the receiving port to the hard drive (which then acts as a buffer), the computer could then read the document line by line and process it that way. As long as there were no extraneous bits in the data, the computer could process it in normal fashion.

However, I was told I was wrong due to the stop bit being needed so that the start bit can be recognized as such. When a start bit occurs, it is guaranteed to be different from the current state of the line.

From a programming perspective why couldn't you use my logic and just dump the data into buffer? If the data itself is formatted in a logical fashion, e.g. a text document that has "\n" for new lines, couldn't you just call a readlines() function to parse the file and then do your processing? I'm sure it wouldn't work for everything, but I still think there are some areas where a program could handle a raw data dump.

Or am I confusing data processing w/ the actual data transfer?

__________________
Common Sense v2.0-Striving to make the world a little bit smarter.

The point of asynchronous serial data transfer is that transmit timing reference and receive timing reference are approximately the same frequency but are not actually correlated (synchronized). For purposes of this discussion, I will assume that all data items have a fixed number of bits that are sent sequentially. The transmitter and receiver have agreed ahead of time on the duration of each bit (the "bit time"). Also, for simplicity, I will assume that the transmission medium allows a receiver to detect one of two logic values, called, naturally a '1' and a '0'.

We use start and stop bits around the data items so that we can get the bytes from transmitter to receiver under the following conditions: (See footnote.)

1. Bytes can be transmitted at any time, with no restriction on the elapsed time from the end of one transmitted byte to the beginning of the next.

2. There is no restriction on the length of "messages", that is: on the number of bytes that will be transmitted in a given spurt.

3. There is no restriction on the number of successive zeros or ones in any given spurt of bytes. That is, the message bytes can be anything.


First of all, we define logic states according to some characteristic of the physical transmission medium.

Typically a logic '1' might be defined as approximately +5 Volts on a logic line. Or, maybe, -12 Volts on an RS232 line. Or, maybe, current flowing in a loop. I'll just call it '1'.

The opposite state is '0', which may be 0 volts for a logic signal or +12 volts for RS232 data, or absence of current in a loop.

Now when no data are being sent, we define an "idle" state. I'll define "idle" to be logic '1', but it could be a '0'. The transmitter comes on, and makes sure the transmission line is in the idle state. The receiver comes on, and if there is some action on the line, it knows that it's in the middle of something, and, since it won't be able to tell much about what's happening, it waits until the line has been idle for at least the time a character would have been sent.

Here's how the transmission goes.

When the transmitter wants to send a byte, it causes the line to go to '0' for one bit time (It could be for some other period of time, but for simplicity I'll just say it is a bit time, and call it a "start bit".)

The receiver detects the start condition and sets itself up to sample the data line one and a half bit times later, so that it will be looking the approximate middle of the first transmitted data bit. The receiver shifts in the logic value at that time and repeats the sampling after each of the next seven bit times.

If the receiver time reference is not too different from the transmitter time reference, the eight transmitted data bits are now in the receiver so that it can do whatever it is supposed to do with received data. (Exercise for the student: What is the maximum difference in reference frequency, in percent, that is tolerable if the transmitted bytes have one start bit and eight data bits.)

Remember, at this time, the receiver is looking at the nominal middle of the last data bit. The question is: What next? Well, the receiver should wait at least one-half bit time to make sure that the most recent byte is completely off of the transmission line.

Actually, it would wait a little more, since the receiver's time reference is not guaranteed to be exactly the same as the transmitter's. Then what?

The conditions that I outlined above kind of imply that each byte has a start bit before the data bits (value '0', in my example). So, let's suppose that there is a start bit and eight data bits for each byte on the line.

If only one byte were sent this first time, then the line would return to its idle state, and the receiver would wait for the next start condition --- which could occur any time later. But, what if there is another data byte immediately after this one? And, furthermore, what if the last data bit from this byte is a '0'? Answer: we don't know exactly when the start bit occurs, since there is no transition from the last data bit.

Just to give a worst case (or, at least a bad case), lets suppose a long sequence of data bytes of all zeros are transmitted. After a certain number of receiver bit times (depending on the difference between transmitter time reference and receiver time reference), the receiver can no longer know that it is near the middle of a transmitted bit. It doesn't know where one bit ends and when another begins. It doesn't know how many zero bits were transmitted, and doesn't know when the start bit is, so it can't know when the next byte occurs, etc. Kablooie.

A solution: After the end of the data bits for each byte, make the line go to a logic value different from that of the start condition. Since the start bit was a '0', we make the stop bit equal to a '1'.

Therefore, the time references must be close enough that the receiver sampling circuit doesn't drift too far away from the middle of the last data bit time, then after a half-bit time, more-or-less, it waits for the '1' and '0' to indicate the start of the next byte. In other words, its timing is renewed at the beginning of every transmitted byte.

Note that the stop condition doesn't have to be a bit time, but it usually is. It does have to be long enough to allow the receiver to know for certain when the next start bit begins.

Old mechanical teletypes and early electronic serial devices used stop conditions that were one and a half or two bit times; nowadays one stop bit time is most common in electronic circuits.

That only works for long sequences of data if the receiver is, somehow, synchronized to the transmitter, or is accurate enough to make sure the timing differences do not drift more than a half of a bit time for the duration of a message (assuming the receiver knows when a message starts and stops). If transmitter and receiver frequency are carefully controlled but not necessarily synchronized with each other (atomic clocks or whatever), the transmission is called isonchronous, not asynchronous

Just to hammer the point home: Computers do not communicate with hard drives asynchronously. Either there is a clock signal separate from the data (IDE/EIDE) or the clock is derived from the serial data stream with Digital Signal Processing and/or a Phase-Locked Loops or some such thing. In the latter case, the data stream is conditioned so that there are no excessively long sequences of physical ones or no excessively long sequences of physical zeros on the transmission line, since that would interfere with the receiver's ability to derive the embedded clock and, therefore to remain synchronized.


Ya gotta get the bits in place before you can worry about data formatting. The first order of business is knowing when each transmitted byte starts. Everything else is just logic.

Regards,

Dave

Footnote: I call the data items "bytes". Nowadays, bytes are usually considered to consist of eight bits, but they don't have to be that way. Old teletype codes, for example, used characters that had five bits. Some old computer peripherals used six-bit characters. It doesn't matter.

I realized after I had asked the question that I was confusing ideas, hence the question at the end. I think I read too much into the question, thinking that the system had to process and do something with the data rather than just the simple idea of data transfer.

Thanks for the explaination though. It does makes sense why I got it wrong.

__________________
Common Sense v2.0-Striving to make the world a little bit smarter.