#Aterm Problems
14 messages in this thread
Larry,
If your XMODEM is at 20 or 30 seconds then that's probably not the
problem as I doubt I've been waiting that long for a response. I'll try to
watch it more closely.
Also, I set XON/XOFF disabled in the term but not in preferences. I'll
try it there also and see what happens. It's a shame though, since even if I
press Ctrl-Q, the term still locks up. Hmmmm. I'll let you know what I find.
Todd
Todd,
Unless the terminal program takes over the serial port, the Xon/Xoff
setting in preferences can get you. A ^Q will not release it….it won't
receive the ^Q because it is locked until your modem receives the ^Q (in other
words..it has to be received as input, not output as the output is turned off
at this point). Obviously doing a binary transfer can easily include a ^S
character.
Don
Thanks Don, I'll hit preferences. I just got it to crash the machine somehow
(81000009.002CAD8A). I don't know why, but 7.2 never gave me problems and 7.3
gives me lots. Ugh!
Todd
Todd,
That number looks familiar, but looking through the docs I have, I see that
it isn'r listed in what I have handy. (81000006 is highest shown in RKM and
another text file I have). I'll see what I can find, perhaps in autodocs or new
includes.
Regards, Larry.
Larry,
According to Alerts.h (of 1.2) 81000009 is the value for "FreeTwice".
Hmmm. I didn't see anything other than a general description of an alert in
the autodocs.
Later,
Todd
Interesting.. I have just sent off for the updated includes/autodocs, since I
only have the Gamma 1 docs. I guess that's where you got the info, but I forgot
to look there. <blush>
FreeTwice sounds like it is trying to Free allocated memory twice. That should
narrow it down. Thanks. I'll take a look at it ASAP.
I will be in Toronto all next week (flying out in about 2 hrs), so I don't
think I'll be able to dig into it too deeply, but will get at it ASAP
Regards, Larry.
Larry,
No problem, I'll try to check into the download problem further (since
I've never succeeded in D/Ling the Aterm Source and I've tried about 4 times,
it should be a good test). You might also be freeing the serial port twice
somehow.
Later,
Todd
Larry,
I realized that RamSpeed is written in Manx and I only have the Lattice
compiler. Can you do me a favor and either email me a copy of the Manx object
module (if it can be made A|Blink compatible) or recompile it yourself so that
it will reside in chip memory and email me the resule?
Thanks,
Todd
I'll try to make a version that will load into CHIP and upload it. I don't
think the Manx Obj can be made A/Blink compatible.
Regards, Larry.
I didn't think so either, but I thought I'd mention it.
Thanks,
Todd
Todd, if you receive a spurious ^S from line noise or whatever, the ^Q you
type will not be sent, and therefor not echoed, to get you out of the lockup. I
think there must be a way (short of closing the serial port) to escape from
this condition, but I haven't seen it yet.
Use your judgement when disabling/enabling Xon/Xoff. If you are sending a
file to a host, the PROMPT character will normally be enough to throttle the
sending speed to a rate that the other side can handle, but not always.
Sometimes you just need to have it enabled so that the host can stop your
transmission if it starts to choke on it.
Regards, Larry.
Larry,
If I disable xoff/xon, I should still be able to slow down my receives
with a CtrlS, but not my transmits. Oy … The damn serial port should
recognize xon whether it comes from the terminal or the host! Jeez. By the
way, Aterm crashed with error # 81000009.002CAD8A tonight. I'm trying to avoid
lockups as it takes 3 or 4 minutes to load up my ram disk. Oy again. I swear
there must be some minor change that's causing some problems. If I can manage
to download the source code without crashing I'll try to take a look. But it's
probably gonna be a while before I can get to it.
Later,
Todd
Larry:
If the modem itself is handling the X-ON/X-0FF then a command string
would have to be sent to the modem. However, unless Aterm itself set the modem
up to operate that way then X-ON/X-OFF is a software function. I gather that
you were not involved in that part of the program. I would imagine that the
drivers protocol is what is used. I don't have my manuals with me and can't
remember if that was even discussed but there has to be a way to tell the
driver to 'pretend' that it received a ^Q!
Bill, it isn't the modem that handles the Xon/Xoff, but the serial.device
itself. As I said, there is undoubtedly a way to get it transmitting again
short of closing the serial port, but I don't know about it.
Regards, Larry.