Download
Share
Print this page
Atmel AVR AVR350 Application Note
  1. Manuals
  2. Brands
  3. Atmel Manuals
  4. Microcontrollers
  5. AVR AVR350
  6. Application note
Atmel AVR AVR350 Application Note

Atmel AVR AVR350 Application Note

Xmodem crc receive utility, 8-bit
Hide thumbs
1
2
3
4
5
6
7

Advertisement

Quick Links

Download this manual
AVR350: Xmodem CRC Receive Utility for AVR
Features
• Programmable Baud Rate
• Half Duplex
• 128-byte Data Packets
• CRC Data Verification
• Framing Error Detection
• OverRun Detection
• Less than 1K Bytes of Code Space
• C High-level Language Code
1 Introduction
The Xmodem protocol was created years ago as a simple means of having two
computers talk to each other. With its half-duplex mode of operation, 128-byte
packets, ACK/NACK responses and CRC data checking, the Xmodem protocol has
found its way into many applications. In fact most communication packages found
in the PC today have a Xmodem protocol available to the user.
®
8-bit
Microcontrollers
Application Note
Rev. 1472D-AVR-01/08

Advertisement

loading

Related Manuals for Atmel AVR AVR350

Summary of Contents for Atmel AVR AVR350

  • Page 1 ® AVR350: Xmodem CRC Receive Utility for AVR Features 8-bit • Programmable Baud Rate Microcontrollers • Half Duplex • 128-byte Data Packets • CRC Data Verification • Framing Error Detection Application Note • OverRun Detection • Less than 1K Bytes of Code Space •...

  • Page 2: Theory Of Operation

    2 Theory of Operation Xmodem is a half-duplex communication protocol. The Receiver, after receiving a packet, will either acknowledge (ACK) or not acknowledge (NACK) the packet. The original Xmodem protocol used a standard checksum method to verify the 128-byte data packet. The CRC extension to the original protocol uses a more robust 16-bit CRC to validate the data block and is used here.

  • Page 3: Receiver Considerations

    AVR350 5 Receiver Considerations This protocol NACKs the following conditions: 1. Framing error on any byte 2. OverRun error on any byte 3. CRC error 4. Receiver timed out (didn't receive packet within one second) On any NACK, the sender will re-transmit the last packet. Items one and two should be considered serious hardware failures.
  • Page 4 7 Modifications to Receive Protocol Users may wish to count how many “C’s” were sent during synchronization and after “n” number of tries abort the receive attempt. For embedded applications it’s not mandatory to have a 128-byte packet. You could have 64, 32, or even a 16-byte packet.
  • Page 5 AVR350 9 Pseudo-Code 9.1 purge.c initialize timer1 counter for a 1 second delay read uart for 1 second 9.2 receive.c send a ’C’ character to sender until receive buffer is full validate received packet send an ACK or a NACK to sender if packet was bad then wait for new good packet while not end of transmission wait for buffer to fill...
  • Page 6 9.7 validate_packet.c if not timed out then if no uart framing or overrun errors then if first character in buffer is SOH then if second character in buffer is the next packet number then if second character in buffer plus the third character in buffer = 0xff then compute CRC on packet data...
  • Page 7 BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES. Atmel makes no representations or warranties with respect to the accuracy or completeness of the contents of this document and reserves the right to make changes to specifications and product descriptions at any time without notice. Atmel does not make any commitment to update the information contained herein.