[fpc-pascal]Serial Port Programming under LINUX...
Maarten Bekers
elevator at planet.nl
Mon Apr 29 12:48:16 CEST 2002
hi,
> ObjCOM appears to be a logical next step. It is, what FOSSIL was at
> DOS time: Some kind of "Super-FOSSIL"; it implements "low level drivers"
for
> DOS (Fossil), Windoze, and LINUX. All this drivers are covered by a common
> object, so you do not have to change even one line inside your program
when
> moving between Linux and DOS/Windows. - It was primarily written for
EleBBS,
> if I understood right.
> -> Sounds perfectly, but there is a bug inside which I cannot locate, so
it
> is currently USELESS at all. :-/
ObjCom is not primarily written for EleBBS. ObjCom (originally) is based on
EleCOM - EleCOM is written for EleBBS. ObjCom is done for OpenXP - a Fidonet
mailer. I develop EleCOM - where parts - mainly the tcp/ip routines - are
also based upon previous work by others.
You seem to describe this bug in an earlier message as:
> But this unit has an unacceptable BUG inside: It stops any further
> communication when the DCD is dropped by the modem when the connection
> breaks. It seems that this causes a total loss of the internal file
> handle!
You also describe that you need both Win32, DOS and Linux communications in
an earlier message, if i recall. You do not, however, specify under which
platform this bug occurs.
The Win32 routines of EleCOM indeed will not talk to the comport if no
carrier is detected, to prevent it from hanging on a dropped user. You can
easily fix this by either changing com_SendBlock and com_ReadBlock which
looks something like:
--
if OutBuffer^.BufRoom < BlockLen then
repeat
Sleep(1);
until (OutBuffer^.BufRoom >= BlockLen) OR (NOT Com_Carrier);
--
by changing that to:
--
if OutBuffer^.BufRoom < BlockLen then
repeat
Sleep(1);
until (OutBuffer^.BufRoom >= BlockLen);
--
The read/write threads itself do (iirc) not check for carrier - only the
routines that manipulate the receive buffers.
The OS/2 routines have a same routine as the above in the same routines -
FOS_COM.PAS does not have any of these checks.
For the rest you have to fix ComBase.pas where Com_FlushBuffers will not
flush until DTR is up.
HTH,
Sincerely,
Maarten Bekers.
More information about the fpc-pascal
mailing list