Just about any form of IO can be used to transfer data. The most common for many years has been Serial (aka RS232). It can be very simple or any number of layers of encoding, transmission, error detection, routing and interpretation can be added as needed. See: OSI Layers
Hyperterminal is the serial terminal program included with MS Windows. It can read the output from a serial port and display it on the computer screen. ASCII file transfer (using only the first 7 bits of each byte) is as simple as telling Hyperterminal to "Capture Text" from the serial port or to "Send Text File" to it. Note that in serial communications, errors often occur and this ASCII transfer does not include any means of detecting or correcting those errors. The idea is that since the data is probably human readable text, any errors will be seen (and probably compensated for) by the reader.
Binary (8 bit) transfers are a bit more complex. Hyperterminal supports most of the common protocols (e.g. XMODEM, YMODEM, ZMODEM, KERMIT, etc...) but the data is still send useing the first 7 bits (or less) of each byte and must be re-assembled at the other end to make each 8 bit byte from (slightly) more than one byte of transmitted data. A minimal approach is to convert each 8 bit byte into 2 hexidecimal digits in ASCII representation.
Now, "binary" protocals really need to include error detection (and correction, but that can be as simple as requesting a retransmision if they find an error). The most common error detection system is Cyclic Redundance Check (CRC). CRC methods can be of different widths (number of bits) and each use a different mathematical equation (called a "Polynomial") to calculate the "checksum" used to compare transmitted data with recieved.
The sender must calculate a checksum from the data in each packet that it sends and then send that checksum after the data to the reciever. The reciever must also be calculating a checksum based on the data it recieves and then it will compare its version of the checksum with the version from the sender. If they match, the data is (probably) good, and if they don't match, the reciever must NACK (Not ACKnowledge) the data and request that it be resent. The biggest trick with error detection from one processor to another, is to get the sending and recieving units to calculate the same checksum for the same data!
There is some code available for the XMODEM (and other) version of CRC16 over different processors on the CRC page. Besides the error detection, there is also a protocal in each method to request, acknowlege, or request re-transmision of data in chunks (called "packets") from the sender and, of course, methods to respond to requests from the reciever. There is some documentation on XMODEM and other protocols on the OSI-2 Data Link page. +
file: /Techref/uCdataXfer.htm, 3KB, , updated: 2002/11/29 12:00, local time: 2024/11/26 08:13,
owner: JMN-EFP-786,
13.58.207.196:LOG IN
|
©2024 These pages are served without commercial sponsorship. (No popup ads, etc...).Bandwidth abuse increases hosting cost forcing sponsorship or shutdown. This server aggressively defends against automated copying for any reason including offline viewing, duplication, etc... Please respect this requirement and DO NOT RIP THIS SITE. Questions? <A HREF="http://techref.massmind.org/techref/uCdataXfer.htm"> Data transfer between processors</A> |
Did you find what you needed? |
Welcome to massmind.org! |
Welcome to techref.massmind.org! |
.