Kermit for downloading software in embedded system
Rene Falize
Hi.
I would like to use Kermit (preferably an earlier version) for
downloading software to an embedded system, but I can't find a detailed
description of the packets to be transferred. Can anybody help?
Thanks.
Paul A. Gramann
I "recommend Kermit, A File Transfer Protocol". See
http://www.columbia.edu/kermit/manuals.html
You can also download the kermit source from columbia.
See the kermit web page for more details. I found that
I needed to buy a book, even after I had all the code.
--paul;
charles copeland
In article <33B9EF...@best.ms.philips.com>,
Rene Falize <rfa...@best.ms.philips.com> wrote:
>Hi.
>
>I would like to use Kermit (preferably an earlier version) for
>downloading software to an embedded system, but I can't find a detailed
>description of the packets to be transferred. Can anybody help?
>
>Thanks.
Why Kermit? Its inefficient. Try z-modem. The current versions cost
money, but older version without the bells and whistles was
freeware. Search WWW for zmodem and you'll find it.
Tom Weber
Tim Kientzle's book "The Working Programmer's Guide to Serial Protocols"
contains a pretty decent discussion on Kermit. Software included also.
Rene Falize wrote:
>
> Hi.
>
> I would like to use Kermit (preferably an earlier version) for
> downloading software to an embedded system, but I can't find a detailed
> description of the packets to be transferred. Can anybody help?
>
> Thanks.
Tom
Marcus Else
Rene Falize wrote:
>
> Hi.
>
> I would like to use Kermit (preferably an earlier version) for
> downloading software to an embedded system, but I can't find a detailed
> description of the packets to be transferred. Can anybody help?
>
> Thanks.
There is a nice book:
Frank da Cruz: "KERMIT A File Transfer Protocol"; Digital Press;
ISBN 0-932376-88-6
Marcus
Don Yuniskis
In article <33bb901...@news.netcomuk.co.uk>, Peter <z...@dserve.com> wrote:
>
>Having seen the other replies, I ask: why use a protocol designed for
>modems?
Agreed! Are you planning on implementing all 27 gazillion different
switches for the protocol? User defined block sizes? CRC options?
Choice of characters to escape? Filename conversion? etc. Kermit
seems like a silly choice if you are just wanting to download code
into a system.
Presumably, you have some PC tool that can speak Kermit and think this
gives you leverage. I'd look to see if you can't just tell that
PC-based comm program (etc.) to use ZMODEM (or any other protocol)
instead.
>If you really are going to connect via a modem, then Zmodem is
>definitely the protocol of choice, IF you can get a known working
>source. (If you cannot get sources then it is damn complex to do and
>fully test and debug).
Agreed. Even with my comm programs, I find ZMODEM to be less hassle
than kermit. And it's pretty tiny, too.
>If you are NOT connecting via a modem, use something simple, like e.g.
>sending the data in one binary block, with a header containing
>filename, size, CRC value, and use a timeout at the receive end to
>detect end of data. Simple.
Even simpler: send Intel Hex records or Motogorilla S records, etc.
I've been doing that for years (even using embedded modems and relying
on the checksum in the Intel Hex Record for error detection).
KISS
>With modem connections, you get lots of errors and need something like
>Zmodem (or Kermit etc) but if you are connecting with a piece of wire,
>even if quite long, errors should be extremely rare.
This depends on the choice of modem, too! I routinely send large blocks
of ASCII text (i.e. no checksums, etc.) via error correcting modem
without any concern for errors creeping in.
--don
Mike Albaugh
Don Yuniskis (d...@rtd.com) wrote:
: In article <33bb901...@news.netcomuk.co.uk>, Peter <z...@dserve.com> wrote:
: >
: >Having seen the other replies, I ask: why use a protocol designed for
: >modems?
: Agreed!
: Even simpler: send Intel Hex records or Motogorilla S records, etc.
: I've been doing that for years (even using embedded modems and relying
: on the checksum in the Intel Hex Record for error detection).
Over a Modem, even, and if your available bandwidth is _way_
more than your needed bandwidth, you can (read: I have) just have your
widget respond to requests such as a block-number in ASCII followed
by a <CR>, with a checksummed hex string (I used TekHex, because I
had the code laying around from a linker). If the "master" doesn't like
the checksum, it just re-requests the block. If it gets no data at
all, it just hangs up and re-dials. This works a lot better if your
widget is robust enough to re-start itself via watchdog or whatever :-)
: KISS
: >With modem connections, you get lots of errors and need something like
: >Zmodem (or Kermit etc) but if you are connecting with a piece of wire,
: >even if quite long, errors should be extremely rare.
: This depends on the choice of modem, too! I routinely send large blocks
: of ASCII text (i.e. no checksums, etc.) via error correcting modem
: without any concern for errors creeping in.
OTOH, even just using a wire, if one end is a PC running some
less-than-industrial-strength O.S. (not to name any names) You can
drop bits between the comm card and your program. Sometimes the last
two inches of the "wire" are the most dangerous :-) If the connection
is fast enough, or your needs slow enough, you just timeout and re-try,
but a little data-framing and link-layer error detection (STX/ETX
and checksum or CRC, respectively) will go a long way toward making
your life better. As my bandwidth needs approach my available bandwidth,
I use a variant of the LLNL "Octopus" protocol, about the simplest
link-layer protocol I've had decent success with.
BTW: if you are going to "roll your own" protocol, _don't_
ignore packet numbering. email me for a long and dispiriting story of
what happened when the Atari 800 designers ignored this piece of advice...
Mike
| alb...@agames.com, speaking only for myself.
Jim Belesiu
There are many reasons for using a protocol like Kermit in a low-error
channel:
1) By using a standard protocol, you only have to focus on programming
the embedded side of the data channel. The host side (PC side) program
is already complete and debugged.
2) I have found in the past that by using a protocol that corrects for
channel errors, I don't need to be concerned about an occasional buffer
over-run on my embedded system. The protocol will corrrect for any
system timing deficiencies.
As an aside, someone else posted about the efficiency of Kermit v.
Zmodem. I have found that you can configure Kermit with large block
sizes and sliding windows that will give it near 100% channel bandwidth
utilization. This makes Kermit as efficient as Zmodem on low noise
channels.
Cheers,
Jim Belesiu
----
Peter wrote:
> Having seen the other replies, I ask: why use a protocol designed for
> modems?
>
> If you really are going to connect via a modem, then Zmodem is
> definitely the protocol of choice, IF you can get a known working
> source. (If you cannot get sources then it is damn complex to do and
> fully test and debug).
>
> If you are NOT connecting via a modem, use something simple, like e.g.
>
> sending the data in one binary block, with a header containing
> filename, size, CRC value, and use a timeout at the receive end to
> detect end of data. Simple.
>
George C. Lindauer
Rene Falize (rfa...@best.ms.philips.com) wrote:
: Hi.
:
: I would like to use Kermit (preferably an earlier version) for
: downloading software to an embedded system, but I can't find a detailed
: description of the packets to be transferred. Can anybody help?
:
: Thanks.
i think I have a book about it. email me and I'll try to find the ISBN
for you. There is probably info somewhere on the net too; you could
try a PC newsgroup because they get into *everything*.
David
Don Yuniskis
In article <33BBCED4...@spiritone.com>,
Jim Belesiu <ji...@spiritone.com> wrote:
>There are many reasons for using a protocol like Kermit in a low-error
>channel:
>
>1) By using a standard protocol, you only have to focus on programming
>the embedded side of the data channel. The host side (PC side) program
>is already complete and debugged.
Yes. But there are other "host side" tools available besides Kermit!
XMODEM, YMODEM, JMODEM, ZMODEM, SEALINK, etc.
>2) I have found in the past that by using a protocol that corrects for
>channel errors, I don't need to be concerned about an occasional buffer
>over-run on my embedded system. The protocol will corrrect for any
>system timing deficiencies.
Sounds like you have a system design problem if you get buffer
overruns -- someone isn't observing flow-control/handshaking
properly, etc. I'd sure hate to rely on that to receive data
from a deep space probe! :>
>As an aside, someone else posted about the efficiency of Kermit v.
>Zmodem. I have found that you can configure Kermit with large block
>sizes and sliding windows that will give it near 100% channel bandwidth
>utilization. This makes Kermit as efficient as Zmodem on low noise
>channels.
So, should he hard code all those parameters? And how much buffer
space should he set aside for the overhead imposed by Kermit in this
configuration?
Again, why "bend" kermit when other options already exist that
address all of these issues?
--don
George Varndell
Jim Belesiu wrote:
>
> There are many reasons for using a protocol like Kermit in a low-error
> channel:
>
> 1) By using a standard protocol, you only have to focus on programming
> the embedded side of the data channel. The host side (PC side) program
> is already complete and debugged.
>
True, but this is a dubious advantage.
Embedded development and debugging is expensive.
The more robust a protocol, the more expensive it's going to be to embed it.
Complexity is simply not needed so why pay for it?
> 2) I have found in the past that by using a protocol that corrects for
> channel errors, I don't need to be concerned about an occasional buffer
> over-run on my embedded system. The protocol will corrrect for any
> system timing deficiencies.
Use hardware handshaking and you won't have to worry about overruns.
The time spent making the embedded system's serial device driver
utilize handshaking would be a better investment than implementing
a robust protocol.
>
> As an aside, someone else posted about the efficiency of Kermit v.
> Zmodem. I have found that you can configure Kermit with large block
> sizes and sliding windows that will give it near 100% channel bandwidth
> utilization. This makes Kermit as efficient as Zmodem on low noise
> channels.
>
Channel bandwidth is one aspect of efficiency.
Code and data space in embedded systems, and a labor budget factor in too.
GV
Geoffrey Levand
I was asking for something specific and perfect for my city,
Whereupon lo! upsprang the post of char...@netcom.com (charles
copeland):
>Rene Falize <rfa...@best.ms.philips.com> wrote:
>>Hi.
>>
>>I would like to use Kermit (preferably an earlier version) for
>>downloading software to an embedded system, but I can't find a detailed
>>description of the packets to be transferred. Can anybody help?
>>
Didn't catch the original post, but I would think you're connecting to
a local PC with a cable. In this case I would recommend against using
Kermit, or any other telephone line protocol like ZModem -- they are
too slow, and you have to code all that handshaking stuff. If you
want to use a standard protocol, I would use YModem. If in fact, you
are doing this over a modem then maybe ZModem would be good.
Lately I've been working with a diskless hand held computer that I
download code to through an RS232 port. I was using XModem, but its
very inefficient, so I coded up my own transfer protocol that runs at
about 10 times the speed.
Basically, I send a header that has a command (download, upload, etc.)
and the number of bytes of extra data. Then I stream the data with a
16 bit CRC inserted after every 1K of data. After every 60K (the hand
held has a 8088 so that's a good buffer size) the hand held needs to
send an acknowledgment.
G. Levand
K. C. Lee
Geoffrey Levand (gle...@gol.com.NoSpamPlease) writes:
> Didn't catch the original post, but I would think you're connecting to
> a local PC with a cable. In this case I would recommend against using
> Kermit,
I would only use Kermit if there are no other protocol available. Some
time I might even take uuencoded file for ASCII download. Kermit only
uses 6-bit for transfer and is highly inefficient. I found it faster to
uuencode binary files first then kermit. This process adds about 50%
extra bytes to encode binary data, but it is still faster than transfering
binary data in kermit. This goes on to show how bad Kermit is with respect
to efficient.
> or any other telephone line protocol like ZModem -- they are
> too slow, and you have to code all that handshaking stuff. If you
What ?? Zmodem is doing pretty good. I usually get about 95% or so of the
raw bandwidth using Zmodem. Zmodem uses 32-bit CRC plus it has resume for
file transfer that got interrupted.
> want to use a standard protocol, I would use YModem. If in fact, you
> are doing this over a modem then maybe ZModem would be good.
I would use Zmodem over YModem. It is a much better protocol overall.
> download code to through an RS232 port. I was using XModem, but its
> very inefficient, so I coded up my own transfer protocol that runs at
> about 10 times the speed.
What ? I would complain more about kermit than xmodem. I don't think you
would be getting 10X speed of Xmode unless your Xmodem implementation is
really bad and you are communicating over a packet switch or something
that has a very long time lag. This is when non-sliding window protocol
(like older version of Kermit, Xmodem) suffers. Zmodem works just fine
for that.
At most you might be getting a factor of 2 or something.
> Basically, I send a header that has a command (download, upload, etc.)
> and the number of bytes of extra data. Then I stream the data with a
> 16 bit CRC inserted after every 1K of data. After every 60K (the hand
> held has a 8088 so that's a good buffer size) the hand held needs to
> send an acknowledgment.
>
> G. Levand
K. C. Lee
Will Rose
K. C. Lee (de...@FreeNet.Carleton.CA) wrote:
: Geoffrey Levand (gle...@gol.com.NoSpamPlease) writes:
: > Didn't catch the original post, but I would think you're connecting to
: > a local PC with a cable. In this case I would recommend against using
: > Kermit,
: I would only use Kermit if there are no other protocol available. Some
: time I might even take uuencoded file for ASCII download. Kermit only
: uses 6-bit for transfer and is highly inefficient. I found it faster to
: uuencode binary files first then kermit. This process adds about 50%
: extra bytes to encode binary data, but it is still faster than transfering
: binary data in kermit. This goes on to show how bad Kermit is with respect
: to efficient.
Well, no. I've found that Kermit and Zmodem, transferring binary data
over good lines, have about the same speed. Kermit has better fall-back
capabilities when used with limited hardware and poor line quality; Zmodem
has a restart protocol which AFAIK Kermit doesn't have.
K. C. Lee
Will Rose (c...@cts.com) writes:
>
> Well, no. I've found that Kermit and Zmodem, transferring binary data
> over good lines, have about the same speed. Kermit has better fall-back
That must be some newer versions of Kermit that supports sliding windows
and variable block sizes used in 8-bit transfer mode or something. The
Zmodem implementations on most terminal software also have automatic
upload/download capabilities and not needing to type in the filename on
both sides.
> capabilities when used with limited hardware and poor line quality; Zmodem
> has a restart protocol which AFAIK Kermit doesn't have.
Does kermit have CRC-32 or better error detection ? CRC is important for
bad line quality.
> Will
> c...@crash.cts.com
K. C. Lee
Will Rose
K. C. Lee (de...@FreeNet.Carleton.CA) wrote:
Yes and no, depending on the version. Check www.columbia.edu/kermit for
the full details. (The current terminal software also has auto up/down
load, btw.)
Jason T. Harris
George Varndell wrote:
>
> Jim Belesiu wrote:
> >
> > There are many reasons for using a protocol like Kermit in a low-error
> > channel:
> >
> > 1) By using a standard protocol, you only have to focus on programming
> > the embedded side of the data channel. The host side (PC side) program
> > is already complete and debugged.
> >
>
> True, but this is a dubious advantage.
> Embedded development and debugging is expensive.
> The more robust a protocol, the more expensive it's going to be to embed it.
> Complexity is simply not needed so why pay for it?
>
I've done both XMODEM and ZMODEM implementations for embedded systems.
XMODEM is about the simplest serial protocol that you can have to
move a file from one place to the other. I doubt if any proprietary
scheme would do the job with less code. (C code compiled to X86 opcodes
-> 582 bytes) I wouldn't want to use it over an actual modem link
because it is not a very robust protocol, but for direct serial links
I have never had a problem. I like it because I don't have to develop
any host side code, the field likes it because it is simple, they
already have the tool to use it (any serial terminal) and it works
reliably.
Someone complained about the efficiency of XMODEM. I'm not sure what
they're on about. XMODEM sends 128 bytes binary bytes per frame with
only a few bytes of overhead. Transfer time for a given file is
mostly a function of baud rate.
So: If you have a reasonably clean channel, XMODEM is a good choice.
--
Jason H.
To send me email replace nospam with jasonh.
K. C. Lee
"Jason T. Harris" (nos...@psd.symbol.com) writes:
>
> Someone complained about the efficiency of XMODEM. I'm not sure what
> they're on about.
> XMODEM sends 128 bytes binary bytes per frame with
> only a few bytes of overhead. Transfer time for a given file is
> mostly a function of baud rate.
Xmodem requires an acknowledgement before sending the next packet. The
latency involved is significant for the small packet size of XMODEM.
The efficiency drops further if there are delays in the path. An extreme
example is if you are sending packets via satellite (say at 1 sec or so
delay), your data rate drops like no tomorrow.
> So: If you have a reasonably clean channel, XMODEM is a good choice.
See above. It is a very simple implementation though.
I got a 2nd comment on XModem in embedded system. Since XModem protocol
doesn't transmit the filename of the file you are sending, how would you
specify the file name on the EMBEDDED side if you have more than 1 files
to work with ? Do you tranfer all of them including the ones you don't
need ? Or do you transfer the names of files in yet another transfer ?
Wouldn't this lower the transfer efficiency ?
> Jason H.
K. C. Lee
Jon Kirwan
>Someone complained about the efficiency of XMODEM. I'm not sure what
>they're on about. XMODEM sends 128 bytes binary bytes per frame with
>only a few bytes of overhead. Transfer time for a given file is
>mostly a function of baud rate.
The complaint about XMODEM efficiency may have stemmed from XMODEM's
use of line turn-around, each packet. ZMODEM almost "streams" the
data without the need for return responses (not exactly true, but
nearly so.) Every 128 byte group, the XMODEM transmitter must wait
for the receiver to receive, verify, and then return an ACK before
proceeding. Doing this with each 128 byte data group slows things
down noticeably. I've used both quite a bit and I have written both
types of drivers, too. You should know this is the reason for the
delays.
That said, an XMODEM driver takes a VERY short time to write. An hour
or two, if you aren't expecting a professional product. I like it a
lot for hacking up something fast.
Jon
Will Rose
: >
: > Someone complained about the efficiency of XMODEM. I'm not sure what
: > they're on about.
: > XMODEM sends 128 bytes binary bytes per frame with
: > only a few bytes of overhead. Transfer time for a given file is
: > mostly a function of baud rate.
: Xmodem requires an acknowledgement before sending the next packet. The
: latency involved is significant for the small packet size of XMODEM.
: The efficiency drops further if there are delays in the path. An extreme
: example is if you are sending packets via satellite (say at 1 sec or so
: delay), your data rate drops like no tomorrow.
Any non-windowing protocol (eg. the original Kermit) does this - the
advantage is that they are relatively easy to write and don't take
up as much memory for buffers.
Dmitry Obukhov
Will Rose <c...@cts.com> wrote in article <8687491...@optional.cts.com>...
Our ISDN TA support download over D-channel packet link. So all acknowledges
is to expensive. We using row-ASCII protocol (no protocol) for make download
faster. I tried all standard protocols and sure that it is FASTEST way.
Against
errors we using a format of file (binary image separated to packets with block
number, address, size, CRC).
Evandro Menezes
de...@FreeNet.Carleton.CA (K. C. Lee) wrote:
>"Jason T. Harris" (nos...@psd.symbol.com) writes:
>>
>> Someone complained about the efficiency of XMODEM. I'm not sure what
>> they're on about.
>> XMODEM sends 128 bytes binary bytes per frame with
>> only a few bytes of overhead. Transfer time for a given file is
>> mostly a function of baud rate.
>
>Xmodem requires an acknowledgement before sending the next packet. The
>latency involved is significant for the small packet size of XMODEM.
>The efficiency drops further if there are delays in the path. An extreme
>example is if you are sending packets via satellite (say at 1 sec or so
>delay), your data rate drops like no tomorrow.
If it's a wired serial link, the efficiency is more than 90% and depends
solely on the destination node speed to check the packet and acknowledge it,
positively or negatively.
>> So: If you have a reasonably clean channel, XMODEM is a good choice.
>
>See above. It is a very simple implementation though.
XMODEM-1K improves the efficiency by using 1KB packets, with fall down to
regular XMODEM in case the receiving end does not support it.
YMODEM is not more difficult to implement than XMODEM or XMODEM-1K, which
can fall down to XMODEM anyway. It's between X and ZMODEM as it has
XMODEM-1K's packet size and a special packet #0 for the file name, though it
does not support packet windowing.
>I got a 2nd comment on XModem in embedded system. Since XModem protocol
>doesn't transmit the filename of the file you are sending, how would you
>specify the file name on the EMBEDDED side if you have more than 1 files
>to work with ? Do you tranfer all of them including the ones you don't
>need ? Or do you transfer the names of files in yet another transfer ?
>Wouldn't this lower the transfer efficiency ?
It's application dependent: at one time it expects a certain file and at
another it expects another file. It's not a problem at all for an automated
system to send files in a specific order.
HTH
__________________________________________________________________
Evandro Menezes Sao Paulo, SP Brazil
TMTI/ENG/STM0 BOSCH Telecom
tel: +55-11-541-9555 #166 fax: +55-11-246-0016
evandro...@pcm.bosch.de www.geocities.com/SiliconValley/7263