by
:
: > You know, of course, that the TRANSMIT command is a last resort, to be
: > used when an error-checking-and-correcting protocol is not available, and
: > that it is very likely to result in corrupted or missing data at the
: > receiving end, right?
:
: I do. That's why I'm using it to bootstrap a hex-encoded kermit server into
: a DS5000 microcontroller that has only a hex file reader in its boot rom.
:
(etc etc)... I'd be really surprised if the TRANSMIT command did not send
exactly the characters it was told to send -- otherwise I'd have heard about
it by now, in spades, and in any case this is a fairly stable chunk of code
that has barely changed at all in years -- so if transmitted characters are
not coming out the port, then the driver or the port hardware are the most
likely culprits.
There has been a lot of talk recently about Linux drivers -- e.g. the
ttyS devices versus the cu devices. Have you tried using a different driver
for the same device?
: > : I suppose I can't be totally sure of the reliability of the serial
: > : port, PC chipsets and UARTS being what they are.
: > :
: > You might have answered your own question right there.
:
: I might, though I'm a bit surprised that I haven't seen any problems in the
: other uses of the port if it's an especially unreliable one. Problems in
: the driver might be another matter, since its use by PPP is probably a
: lot different to its use by kermit.
:
Wouldn't PPP hide errors from you by repeatedly forcing retransmission of
damaged material until it gets through correctly?
: > : enabling local echo
: > : ( the whole file is echoed to the screen, but not sent to the
: > : line. There's another effect too : echo only works in binary
: > : mode, not text )
: > :
:
: > The relevant command is "set transmit echo on".
:
: And "set terminal echo on", and especially "set transmit prompt 0".
:
Note that when C-Kermit echos transmitted material, these are exactly the
same characters that it sends to the port. So if they are not coming out
the port -- and the driver is not reporting an error -- something is badly
amiss under the hood.
: Speed changing was interesting. I tried initially at 19200. I got the
: same, or very similiar results at 1200 and even at 300. The effect of
: speed changes is more noticeable in binary mode : i.e. characters are
: usually lost, but in binary mode higher speeds seem to cause wider
: variations.
:
Hmmm... If you look at the code (transmit() in ckuus4.c) you'll see that
completely different sections of code are used for text and binary mode.
Therefore if both of them fail for you, the chance that BOTH sections of code
are faulty is pretty slim.
Binary mode should not have to be used for transmitting an ordinary text
file, and especially not for transmitting one like this -- Intel Hex files
are just about the most transportable files on earth -- restricted safe
character set, short lines, etc.
: What did change the behaviour drastically was "transmit pause". Any
: non-zero setting would completely fix the problem in binary mode, but
: at the cost of severely limiting througput (probably due to a minimum
: useful value for msleep on this hardware). Below 12, the problem in
: text mode was not affected. At 12, the problem was fixed for text, too.
:
This is fairly clear evidence that the driver is allowing its output buffer
to be overrun. It's a good thing C-Kermit has so many controls, eh?
Btw, TRANSMIT PAUSE applies per character in binary mode, and per line in
text mode (as you knew, or discovered).
: Here's a script that illustrates the problem, and all the details of
: running it. Unfortunately, it may be machine-speed dependent, I
: suppose.
:
Well, as far as Kermit is concerned, the speed doesn't matter. The same
code is being executed at any speed, and the same bytes are being sent;
it's up to the driver to actually send them, and to take care of realtime
considerations like flow control, kernel buffering, checking the UART's
ready and overflow flags, etc. In any case, your hex file transmits
perfectly here in text mode.
: For what it's worth, this machine is a 100MHz PCI 486.
:
Beyond the driver, on any PC you need to be aware of buffered versus
unbuffered UART and interrupt conflict issues.
In any case, since this is a one-time-only bootstrapping operation, and
you seem to have a workaround, I think we can consider the case closed as
far as C-Kermit is concerned. Unless there is something wrong amongst the
many ioctls given to the driver to condition it for transmitting; these
are done in the ttpkt() routine in ckutio.c, and have worked fine in Linux
for many years, but again, C-Kermit can't see which driver you are using
-- it can only issue the appropriate and documented API calls and expect
them to work as advertised. However, if any Linux expert wants to take a
look and suggest corrections, perhaps based on changes in the APIs that
I don't know about, feel free!
- Frank