Electrical Engineering Stack Exchange is a question and answer site for electronics and electrical engineering professionals, students, and enthusiasts. It only takes a minute to sign up.
Sign up to join this community
I have read that asynchronous data transfer is wasteful of CPU time for slow devices like keyboard or mouse.
Then how is it possible that it is suitable only for slow devices like keyboard or mouse for which the data transfer speeds are low?
Moreover I have also read that it cannot be used for high-speed devices.
Why?
Edit: Here is the link to the video DATA TRANSFER TECHNIQUES (9:38 to 13:42).
Since you are talking about keyboard and mouse, it is likely these devices use the USB protocol.
Keyboard and mice use the interrupt transfer since there is less data to transfer. Interrupt Transfer, or Interrupt Pipe, has a defined polling rate between:
So if a device requires the attention of the host, it must wait until the host polls it. An Interrupt request is queued by the device until the host polls the USB device asking for data.
For example, for a mouse, a data transfer rate at every 10 ms can be guaranteed. However, defining the polling rate does not guarantee that data will be transferred every 10 ms, but rather that the transaction will occur somewhere within the tenth frame. For this reason, a certain amount of timing jitter is inherent in an USB transaction.
The above figure of interrupt transfer is taken from https://www.keil.com/pack/doc/mw/USB/html/_u_s_b__interrupt__transfers.html . The interrupt transfer uses a handshaking process which consumes time.
On the other hand, for high-speed data transfer in USB, isochronous data transfer is used.
Meaning of isochronous transfer according to IEEE802.org: The applications in each device are synchronized to a common time, which is strictly monotonic and steadily increasing, without jumps or leaps. Devices synchronously sample inputs and apply outputs by exchanging data at a defined periodic rate or cycle.
USB isochronous data streams are allocated a dedicated portion of USB bandwidth to ensure that data can be delivered at the desired rate. An Isochronous pipe sends a new data packet in every frame, regardless of the success or failure of the last packet.
There is no handshaking in isochronous transfer, so it is much faster than interrupt transfer. In isochronous transfer, data integrity is not guaranteed since if error occurs, data transfer is not re-attempted if there is an error. In interrupt transfer, data transfer is re-attempted if there is an error. This is one more reason why interrupt transfer is slower than isochronous transfer.
The above figure of isochronous transfer is taken from https://www.keil.com/pack/doc/mw/USB/html/_u_s_b__isochronous__transfers.html .
Isochronous transfer is used in cameras and video devices for continuous periodic time sensitive information with guaranteed bandwidth ideal for video streams.
References:
Since you are talking about keyboards and mice it sounds like you specifically mean asynchronous serial communication. This communication is slower than synchronous serial communication because the receiver must synchronize the received data to its own clock. The system clocks in the transmitter and receiver can have slightly different frequencies. In asynchronous communications the transmitter clock is not sent along with the data, so the receiver must try to reliably detect the timing of the bits.
This is accomplished by oversampling: sampling the value of the incoming data at a much faster (usually 16x) frequency than the actual data rate. When the receiver sees that two successive samples are different (usually from high to low) it assumes that it has just seen the leading edge of a start bit. The receiver then uses its oversampling clock to try to wait and sample each successive bit right in the middle of its bit time. If you send something like 8 data bits plus a start bit and a stop bit, then the system clock frequencies in the receiver and transmitter can differ by about 5% and communication will still work.
Since the receiver must create the faster oversampling clock, the data rate is limited to something much lower than the system clock speed. Data rates are also limited by how accurately the system clock can be divided down to the exact data rate desired. In synchronous communication the clock is transmitted along with the data so these issues can be avoided and higher data rates are possible.
More information at https://en.wikipedia.org/wiki/Asynchronous_serial_communication
No handshaking is needed to make this work.
As said by Elliot Alderson, Asynchronous Serial communication has limited speed, because bit rate should be much smaller than system clock rate.
But exists other problem - Async also has limited length of message, because frequency could drift and because errors of timing during transfer are accumulated with each bit.
For example, on old systems, Async message length is limited by approximately 15 bits. And we have very high overhead, as each message should have some sort of start bit, plus some pause between messages, like one bit in best case.
For example in classic PC Serial interface mostly used format 8N1, means 8 bit data+none parity bits+1stop bit+1hidden pause state bit long (between messages)+1hidden start bit, so 8 bit data and 3bits technological, near 50% overhead.
As opposite example, Synchronous Serial transfer methods, could have virtually unlimited length of message (in reality used different lengths in different technologies, but much larger than with Async), because all Synchronous techniques use some method of transfer synchronization with data bits, so message overhead is much less.
Examples:
ATM used 64bits messages;
Ethernet classic uses up to ~1500 bytes of data messages (minimal IP header size 20 bytes, so just 160 bits minimal message, if just packet sent, without data, and 1522 bytes maximal size), and extended "jumbo frames" are up to ~9000 bytes (not all controllers support them and max sizes varies).
For simplicity I have not account for Ethernet header size, which could be from 18 bytes, but as you could see, 18 bytes divided by 1500 bytes is much smaller, than 3 bits divided by 8 bits.
That video seems to use the phrases "synchronous" and "asynchronous" communication in a bit of a different sense than I've usually seen. In a way, there seems to be some internal logic to it, but it's mixing matters up enough to be confusing.
If we talk about hardware signals, and someone mentions "asynchronous" transmission, what comes to mind is the common UART serial port related to RS232. (Though I understand RS232 actually defines connectors and voltages, not the parts interesting here, so there's likely room to argue about correct naming). Of course things like USB, SPI and SATA are also serial, but those aren't what we mean here.
UART communication basically amounts to sending bits of some length determined by the clock on the transmitter, and hoping the receiver gets the reception right. That is, the receiver has to be expecting data with that particular bit rate, and must be able to produce a clock that runs at the same speed as the transmitters clock. The transmitter and receiver aren't explicitly synchronized (within the definition of the low-level signalling, anyway), hence asynchronous communication.
With an ugly ASCII-art, a simplified UART transmission where the sender puts a new bit on the data line on each rising edge of its own clock, and the receiver samples the data line once on each falling edge of its clock. Here the receiver's clock is running fast (or the sender's is running slow), and it will eventually read garbled data when sampling point goes off the bit edges.
sender clock (internal)
+--------------+ +--------------+
| +--------------+ +--------------
data line:
<---bit 0--------------------><---bit 1-------------------->
^ ^ sampling points
+------------+ +------------+
| +------------+ +-------------
receiver clock (internal)
That's opposed, to say SPI, or "Serial Peripheral Interface", where the hardware contains both a data line (two, really), and an explicit clock line, and the timing of the data bits are in relation to that shared clock. Hence, the transmitter and receiver are synchronized, via that clock signal.
Here, there is only one clock, used both by the sender and the receiver:
clock signal
+----------+ +----------+
| +----------+ +----------
data line:
<---bit 0-------------><---bit 1------------>
^ ^
+-- sampling points --+
Between the two options of having no clock signal and having a dedicated clock line, is embedding the clocking on the signal itself. Regardless of the way it's done, the point is to ensure enough transitions on the data line to let the receiver correct for any clock drift against those transitions. That's mostly used by higher-speed interfaces and is likely to be more complex. Ethernet (with 8b/10b encoding and others), and USB (with bit stuffing) fall into this category.
What that video appears to be talking about at the point you refer to (around 11:44), is not really the hardware interface, but instead the software side. The way he describes "asynchronous" transmission is basically to have the CPU run in a busyloop, repeatedly asking the peripheral if there's more data to read, and processing that data when there is.
The slide in the video at 11:36 literally says:
- The CPU has to check the status of the I/O module to know when the device is ready to transfer the next word
- Characteristics
- While the CPU is checking whether the I/O module is ready, it cannot do anything else.
That's what I would call polling in a busy loop, and that's not really well suited for any I/O.
For serious applications, you very much want to avoid having the CPU do that, exactly because it means the CPU can't do useful work at the same time. You could have a lower-level device do the same on hardware, but that's much less of a problem, since a purpose-built device can probably do it with less power consumption, because it's simpler than a full CPU, and optimally would run with a lower clock rate.
The opposite for polling would usually be an interrupt-driven peripheral, where instead of the CPU repeatedly asking the peripheral if it's ready, the CPU can do other work in the meanwhile, and the peripheral comes to tell when it has new data. (What the CPU does after that is a matter for the operating system and the applications.) The video does actually mention interrupt-driven data transfer too, at 23:17 or so.
Polling by the CPU can be usefully done for slow devices (esp. ones that don't provide interrupts), like physical buttons on a microcontroller, or the old PC-style joystick port. But even then, it's not done by having the CPU run a busy loop, but by having a timer interrupt the CPU, which then manually interrogates the peripheral.
(USB uses polling on the protocol level, but that's done by the USB controller and the device, it's not something the main CPU needs to be involved with.)
The funny thing is that the video also uses UART as an example of asynchronous data transmission (at around 15:03), but neglects to mention that this time it's talking about the hardware, and not the interface between the CPU and the peripheral.
It also says:
The devices are asynchronous at the level of bytes, but are synchronous at the level of bits within the bytes
... which is pretty much opposite to how I would describe it. The UART receiver synchronizes to the start of the byte (the starting edge of the start bit), but there's nothing to synchronize the lengths of the individual bits.
Note that those are two separate things: polling vs. interrupts on the CPU aren't tied to synchronous vs. asynchronous communication on the hardware. It's entirely possible to have data from both UART (async) and SPI (sync) come to the CPU via interrupts. Or, if you want to do things the stupid way, to have the CPU poll the peripheral, which is again possible for both UART and SPI.
