serial port drivers 
Author Message
 serial port drivers

Is there a problem with communicating via the serial port in faster
computers? I have been using a program to read a {*filter*} sugar meter
(Lifescan Profile) attached via the serial port to a ThinkPad 701cs, 486
DX2/50mhz for a few years with success. Using a ThinkPad 600e Pentium
II, 400mhz. communication is rarely, but sometimes, successful. Usually
the computer behaves as if no meter is attached. Sometimes there is
communication and the meter appears to be read (judging from its
display) but the computer seems to get caught in an endless loop.
Very occasionally everything seems O.K. The results are unpredictable.

I have had the problem using a driver published by O'Brien, Turbo Pascal
7, and also using a driver by Gary Syck, Turbo Pascal How To. I was
wondering if there is communication problem due to the higher machine
speed analogous to the known problem with the Crt unit?

Sent via Deja.com http://www.*-*-*.com/
Before you buy.



Wed, 18 Jun 1902 08:00:00 GMT  
 serial port drivers



Quote:
> Is there a problem with communicating via the serial port in faster
> computers?

Not only, but the signal quality may not be like specified in V24 / RS232,
possibly because of nowadays voltage 3V instead of 5V. Same problem
with parallel port is possible.

I have been using a program to read a {*filter*} sugar meter

Quote:
> (Lifescan Profile) attached via the serial port to a ThinkPad 701cs, 486
> DX2/50mhz for a few years with success. Using a ThinkPad 600e Pentium
> II, 400mhz. communication is rarely, but sometimes, successful. Usually

Is there some DELAY (or selfmade NOPs) in your source or the units from
outside?

Quote:
> the computer behaves as if no meter is attached. Sometimes there is
> communication and the meter appears to be read (judging from its
> display) but the computer seems to get caught in an endless loop.

"Reading from port until" without programmed timeout in case of no
characters ?

Quote:
> Very occasionally everything seems O.K. The results are unpredictable.

> I have had the problem using a driver published by O'Brien, Turbo Pascal
> 7, and also using a driver by Gary Syck, Turbo Pascal How To. I was
> wondering if there is communication problem due to the higher machine
> speed analogous to the known problem with the Crt unit?

Good luck
--
Georg O.F. Richter


Wed, 18 Jun 1902 08:00:00 GMT  
 serial port drivers


Quote:



> > Is there a problem with communicating via the serial port in faster
> > computers?

> Not only, but the signal quality may not be like specified in V24 / RS232,
> possibly because of nowadays voltage 3V instead of 5V. Same problem
> with parallel port is possible.

Would that not be the CPU voltage? The serial port voltages shouldn't have
changed, even if the CPU voltage has.

RS232 signals are supposed to be +5V to +15V if positive, and -5V to -15V if
negative. The receiver is supposed to recognise a positive signal as
anything from +3V up, and a negative signal as -3V down. There have been
some devices claiming to have "RS232" interfaces which actually use 0 and 5V
for negative and positive signals respectively. 0V wouldn't be defined, but
some or most PCs will define it to be a negative level - "undefined" can
mean "we can define it however we want", and recognising TTL-like levels
means that more stuff will work, without causing trouble for working
equipment which use the "legal" levels. It's just a more tolerant design
than the spec requires. But there have always been some manufacturers whose
PCs would not recognise devices whose output does not reach down to the
proper negative voltages. Not saying that this is likely here, but I suppose
it's possible.

Quote:
> I have been using a program to read a {*filter*} sugar meter
> > (Lifescan Profile) attached via the serial port to a ThinkPad 701cs, 486
> > DX2/50mhz for a few years with success. Using a ThinkPad 600e Pentium
> > II, 400mhz. communication is rarely, but sometimes, successful. Usually

> Is there some DELAY (or selfmade NOPs) in your source or the units from
> outside?

Given that communication sometimes works, this seems most likely. There may
be a timeout implemented by counting loops for the initial response from the
meter, which has become shorter due to the faster processor, and the meter
does not respond in time. Is the source code available? If such timeouts can
be implemented using the clock tick counter at $40:$6C then the delay will
be independent of the processor speed. It is possible to write code which
will work on faster processors, but if you start counting loops some
processor will eventually be too fast, if your program lives long enough.

FP



Wed, 18 Jun 1902 08:00:00 GMT  
 serial port drivers


(snip)

Quote:



> > > Is there a problem with communicating via the serial port in faster
> > > computers?

> > Not only, but the signal quality may not be like specified in V24 /

RS232,
sorry, V28 defines although.

Quote:
> > possibly because of nowadays voltage 3V instead of 5V. Same problem
> > with parallel port is possible.

> Would that not be the CPU voltage? The serial port voltages shouldn't have
> changed, even if the CPU voltage has.

It was only a tipp, because even ISA-Slots in that crippled PS's today are
supported
somtimes with 3V-signals (some won't work).
Quote:

> RS232 signals are supposed to be +5V to +15V if positive, and -5V to -15V
if
> negative. The receiver is supposed to recognise a positive signal as
> anything from +3V up, and a negative signal as -3V down. There have been
> some devices claiming to have "RS232" interfaces which actually use 0 and
5V
> for negative and positive signals respectively. 0V wouldn't be defined,
but
> some or most PCs will define it to be a negative level - "undefined" can
> mean "we can define it however we want", and recognising TTL-like levels
> means that more stuff will work, without causing trouble for working
> equipment which use the "legal" levels. It's just a more tolerant design
> than the spec requires. But there have always been some manufacturers
whose
> PCs would not recognise devices whose output does not reach down to the
> proper negative voltages. Not saying that this is likely here, but I
suppose
> it's possible.

Oh yes, they prevent us to pay much more money for PC's which are useable
like oldtime defined industrial standard, but that means not "legal" today
;-(

- Show quoted text -

Quote:
> > I have been using a program to read a {*filter*} sugar meter
> > > (Lifescan Profile) attached via the serial port to a ThinkPad 701cs,
486
> > > DX2/50mhz for a few years with success. Using a ThinkPad 600e Pentium
> > > II, 400mhz. communication is rarely, but sometimes, successful.
Usually

> > Is there some DELAY (or selfmade NOPs) in your source or the units from
> > outside?

> Given that communication sometimes works, this seems most likely. There
may
> be a timeout implemented by counting loops for the initial response from
the
> meter, which has become shorter due to the faster processor, and the meter
> does not respond in time. Is the source code available?

BTW: May be the time waiting for the answer of the BS-meter too short ?

Quote:
> If such timeouts can
> be implemented using the clock tick counter at $40:$6C then the delay will
> be independent of the processor speed. It is possible to write code which
> will work on faster processors, but if you start counting loops some
> processor will eventually be too fast, if your program lives long enough.

I forgot it: Was TP7 and/or BP7 ok for original DELAY(1000)=1 second until
200MHz
or above?

GR
--
Georg O.F. Richter
alias Hourdi



Wed, 18 Jun 1902 08:00:00 GMT  
 serial port drivers

Quote:
>> I have been using a program to read a {*filter*} sugar meter
>> > (Lifescan Profile) attached via the serial port to a ThinkPad 701cs, 486
>> > DX2/50mhz for a few years with success. Using a ThinkPad 600e Pentium
>> > II, 400mhz. communication is rarely, but sometimes, successful. Usually

>> Is there some DELAY (or selfmade NOPs) in your source or the units from
>> outside?

>Given that communication sometimes works, this seems most likely. There may
>be a timeout implemented by counting loops for the initial response from the
>meter, which has become shorter due to the faster processor, and the meter
>does not respond in time. Is the source code available? If such timeouts can
>be implemented using the clock tick counter at $40:$6C then the delay will
>be independent of the processor speed. It is possible to write code which
>will work on faster processors, but if you start counting loops some
>processor will eventually be too fast, if your program lives long enough.

IIRC the good way to avoid at least part of the problems is to readback
anything you write to a port if the specs allow it. I don't know if this
also goes for external ports, or only ports addresses defined by cards.


Wed, 18 Jun 1902 08:00:00 GMT  
 serial port drivers
Thanks to those who replied to my initial posting. The respondents
pointed to a time-out as the likely problem - and this seems to have
been the case. Anyway, I solved the problem as follows:
1) To initiate data transfer from the meter attached to the serial port
I had been sending a string 'DMP'. I changed this to send one character
at a time, with a delay after each, Delay(1000).
2) Raeeding the meter, the computer was reading the buffer between
characters sent (apparently obtaining ASCI 27). I read a character at a
time, testing for valid characters each time and discarding anything
else.


Quote:

> Is there a problem with communicating via the serial port in faster
> computers? I have been using a program to read a {*filter*} sugar meter
> (Lifescan Profile) attached via the serial port to a ThinkPad 701cs,
486
> DX2/50mhz for a few years with success. Using a ThinkPad 600e Pentium
> II, 400mhz. communication is rarely, but sometimes, successful.
Usually
> the computer behaves as if no meter is attached. Sometimes there is
> communication and the meter appears to be read (judging from its
> display) but the computer seems to get caught in an endless loop.
> Very occasionally everything seems O.K. The results are unpredictable.

> I have had the problem using a driver published by O'Brien, Turbo
Pascal
> 7, and also using a driver by Gary Syck, Turbo Pascal How To. I was
> wondering if there is communication problem due to the higher machine
> speed analogous to the known problem with the Crt unit?

> Sent via Deja.com http://www.*-*-*.com/
> Before you buy.

Sent via Deja.com http://www.*-*-*.com/
Before you buy.


Wed, 18 Jun 1902 08:00:00 GMT  
 
 [ 6 post ] 

 Relevant Pages 

1. Serial port probs/Flow control/Faxing

2. serial port software

3. serial port routines

4. Programming the Serial Port in D5

5. print to a serial port printer

6. How do I use the serial port

7. serialun.zip Turbo Pascal Object Oriented Serial Port Unit

8. Firing Serial Port Pins...

9. networks and serial ports

10. Simplying serial com port selection

11. Serial Port Monitor

12. addressing serial port?

 

 
Powered by phpBB® Forum Software