Joe Giacobello skrev:
Jim and Billy, thanks for your inputs, but I'm continuing to have both an
exasperating and mysterious series of problems with the FW installation.
Apparently, those messages that I was receiving on the Orion screen were indicative of the FW code being loaded albeit at a very slow pace. I went back and tried it again several times and on some occasions the transfer would stop at an early line and the update software would close. The furthest I got before the transfer stopped was program flash 266. The speed seemed to be erratic, but it was generally quite slow. It made little difference whether I used hardware flow control or none and 57.6K speed or slower. Even though I usually received the error message that there was no communication between update software and the Orion, the Orion display showed
Snip snip snip
Dear Joe et al,
What you need to realize is, that we are using communication at its most
basic level here. Asynchronous communication (and RS232C) was invented
long before the advent of micro processsors, and was designed for (in
today's eyes) very primitive hard-wired logic. What's called "Handshake"
is barely that, it's more like waving a flag and hoping your partner
sees it.
Even today, the standards of those days applies, whether we use DOS or
Windows, Linux or Unix, or various other systems the drivers (the SW our
applications "talk" to when wanting to transmit or receive data) all
behave in a "send and forget" way or, on the receive side "wait forever"
mode. This is clearly not very conducive so a "time-out" mechanism has
been built into the driver: When the sender has presented the data (a
character) to the transport medium, it'll wait for a while for proper
signaling, before letting the application know thet it's ready for the
next character, if nothing happens, it'll clear its status and signal
that it's ready for the next anyway! Thus the sending application may
think that, although things are progressing at a snails pace, everything
is going well. Likewise on the receiving side: if nothing happens for a
while after signaling readiness for the next character it'll send a
"NULL" character upstream, reset itself and signal readiness for the
next character, and so on ad nauseam. Again the receiving application
will get a string of absolutely useless "NULLS" very slowly, but since
it doesn't know what it's supposed to receive, never realize that
anything is amiss.
This is exactly what you are seeing!
To sum it up: when using asynchronous serial communication, if what you
see is very slow (orders of magnitude) progress, it's a clear indicator
that the basic connection hasn't been made correctly!!!! Most likely
your cable, but possibly blown RS232C chips at either end (happens very
often - they are fragile beasts).
An easy way of testing you interface is to establish connection with a
Rig Control program like "Ham Radio Deluxe" or any other program that
suits you. If that works you are all set - the Flash process will also
work, if not find and fix you basic communication problem.
BTW: the most common way to blow an RS232C interface is to hot-plug a
cable between two devices, especially if neither has a good common
ground connection.
--
Vy 73 de OZ1PIF/5Q2M, Peter
** CW: Who? Me? You must be joking!! **
email: peter(no-spam-filler)@frenning.dk
http://www.frenning.dk/oz1pif.htm
Ph. +45 4619 3239
Snailmail:
Peter Frenning
Ternevej 23
DK-4130 Viby Sj.
Denmark
***********************************
|