YMODEM hyperterminal

Go To Last Post
11 posts / 0 new
Author
Message
#1
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello all,

I would like to use Hyperterminal's YMODEM to send and receive files between PC and my micro. Sending to PC goes ok, but now I am making the receive from PC routines. Problem is that I need 128 byte packets (header starts with SOH) but Hyperterminal send the first packet as 128 bytes and after that it switches to 1024 (header starts with STX). I found many descriptions of the XMODEM/YMODEM protocols on the net, including the original ones but I cannot find out how to force 128-byte packages from the receive side.

Someone ?

Thanks

Patrick

Last Edited: Wed. Mar 10, 2010 - 08:30 AM
  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

According to Programmer's Guide to Serial Communications by Richard Grier Y modem pads extra null chars to make sure the block is exactly 1024 bytes. Visual C had an example source program some years ago called MyTTY which may still be around.

EDIT:

Here is a good link to Microsoft tech for Y modem..

http://msdn.microsoft.com/en-us/library/ms817599.aspx

EDIT2: From Y modem G
The HyperTerminal Ymodem-G File Transfer protocol provides simple serial file transfer between server and client across a point-to-point link using fixed-length packets. Each server packet contains either 128 bytes (the start of header character (SOH) = 0x01) or 1024 bytes (SOH = 0x02) of file data. Multiple files can be sent per transmission, and the transmission must be restarted from the beginning if it fails.

perhaps your start char is switching from 0x1 to 0x2?

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

You might want to consider a better comms program than the excrable Hyperterminal. If it can do anything wrong it probably will. There have been several threads here over the years listing folks favourite alternatives.

(mine is TeraTerm 4.61 - YMMV)

[currently at 4.65 in fact: http://ttssh2.sourceforge.jp/ ]

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Try XMODEM instead of YMODEM. At least there it is the receiver that forces the packet size, but the receiver must recognize it. You can have 128 byte packets with checksum, 128 byte packets with CRC-16 and 1024 byte packets with CRC-16. Should be similar enough with YMODEM.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Hello,
First of all thanks for these answers. Some remarks :

Quote:
@Alwelch : Thats nice I just found the book you refer to in our company library. I know about the difference between SOH (0x01) and SOH(0x02), this last one is sometimes refered as STX (ETX in my first message was a type failure). When I send a block I use 0x01 but when receiving hypterminal it send me 0x02 (1024 byte) blocks. I found several mistakes in the MSDN-ZMODEM protocol description

Quote:
@clawson : Terraterm looks great but there is one protocol not supported : YMODEM

Quote:
@Japael : Using XMODEM does not give me the possibility to do batch transfers and send the filename

All in all I am considering using another protocol, probably ZMODEM but whis will take more time to implement, but has some advantages like not using characters below 0x20 IIRC.

Cheers !

Patrick

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Paddy,

If you are communicating on a fixed link, you should not really get any glitches or errors. So your protocol only has to worry about the correct # packets rather than failures due to noisy telephone lines etc.

So any of these protocols will do you fine, even xmodem.

If you do have a noisy link, avoid xmodem. xmodem-crc is a bit more robust. zmodem is better.

David.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

The only downside of Xmodem/Xmodem-CRC is that the protocol does not include a way to pass filename and filesize so, because the packets are 128 bytes the file will inevitably be a multiple of this unless you carry your own protocol over Xmodem itself where, for example, you always use the first packet to carry a filename and length or you do an old MS-DOS style 0x1A end of file marker in the data (but this precludes 0x1A being in the data)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

[Solved]
Thanks for the help,
I solved it for now by using the 1024 byte buffer, costs lots of memory but by using the malloc functions I get better control of the memory.
Future expansion will probably be another protocol, no time for it now.

Thanks

Patrick

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Good thing it sorted out.

Yes YMODEM basically is like XMODEM but first transmission sends the filename, but I thought it is still possible to use 128 byte packets and be compatible with XMODEM. Weird.

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

Quote:

but by using the malloc functions I get better control of the memory.

Surely malloc() is the very worst thing for "better control". If you want a temporary allocated buffer why not just put it on the stack

void start_protocol(void) {
  uint8_t buffer[1024];
  call_everything_involved in the protocol();
}

buffer[] is created on entry to start_protcol() and freed on exit.

Using malloc you have yet another memory pool to consider (in GCC it lies between the end of .bss and the low water mark of the stack) and you face issues (especially in error handling) where the protocol might finish without free() being used correctly if there are multiple exit routes.

I'd have said malloc() in a limited resource MCU was the very worst idea. Even more so if you ever malloc() blocks of more than one size in which case the alloc/free order can lead to heap fragmentation.

Just IMAO ;-)

  • 1
  • 2
  • 3
  • 4
  • 5
Total votes: 0

@clawson
Thanks for the comment, but I have had several cases where I got too much variables on the stack, no warning and just having unpredicted program execution.

I dont see the problem using malloc.
As you say when using malloc must always be ended with free, thats no problem. Same for a file you opened it must be closed.

Also for a copy routine I use a buffer as large as possible, to speed-up copying from one file to another.

ok the fraqmentation is an issue but at least with malloc I can check wether the memory is free or not.

Thanks

Patrick