NT/95/98 Serial driver rewrite: Call for comments

0 views
Skip to first unread message

Rolf Schroedter

unread,
Jun 25, 1999, 3:00:00 AM6/25/99
to
Scott Redman wrote:
>
> None of the engineers at Scriptics, including myself, have enough
> time to fix and/or rewrite the serial drivers for NT/95/98. The one
> in 8.1.1 is (so far) the most stable version that provides support
> for fileevents, except that it does not return as much data as it
> could in the case Rolf is describing.

I would try to rewrite the serial port driver,
although I'm not very experienced in digging the Tcl sources.
But I am in the dilemma that the Tcl8.1's read-single-byte
implementation inhibits me to switch to 8.1.

On the other hand there are some open issues on Tcl's serial support
which need some discussion:

1. Problems, when [read $chan] return s 0/1 bytes
2. Is the 8.1 threaded implementation indeed safe/stable ?
3. What is wrong with a polled implementation (no reading thread) ?
4. Blocking read ?
5. Call for contributions to a serial test suite for NT/95/98

1. Problems, when [read $chan] return s 0/1 bytes
=================================================
This has been already discussed here in c.l.t.
I only underline, that it is a real performance issue
when we receive netto ~10 kBytes/sec at a baud rate of 115 kbps.
That means that we have 10 kilo-calls per second to the event-handler.
I am in doubt that every PC can follow that speed from Tcl.


2. Is the 8.1 threaded implementation indeed safe/stable ?
==========================================================
I am not sure that the curent threaded read-single-byte
implementation is as safe as we are assuming.
It reads data in a thread like:
while ( 1 )
if WaitCommEvent( char_received )
ReadFile( 1 character )
If there are arriving 3 or more characters very quickly,
the third event can be lost.
( see http://www.microsoft.com/win32dev/base/serial.htm )
Instead the reading thread should perform:
while ( 1 )
if WaitCommEvent( char_received )
while( ReadFile( 1 character ) )
save_character_to_buffer
That assumes:
1. a proper timeout setting (COMMTIMEOUTS),
2. The reading thread has to buffer the incoming data
it will be a 2nd driver above the system driver.
Shouldn't it as a driver have a higher priority ?


3. What is wrong with a polled implementation (no reading thread) ?
===================================================================
What is wrong if we implement a non-threaded serial driver ?
Tcl fileevents are anyway polled by the event-loop.
I assume that the windows serial driver receives and buffers
the incoming data interrupt-driven in real-time.
With my non-threaded tkWinCom (wrong name, should be tclWinCom)
extension I am able to receive even ~10 kBytes/sec at 115 kbps:
- Check for arrived characters with ClearCommEvents
- Generate a Tcl-event
- read all bytes within the Tcl-fileevent callback


4. Blocking read ?
==================
Tcl8.0 and 8.1 also behave different in blocking mode.
Tcl8.0 does not really block on a [read $chan $N],
but returns 0..N bytes without blocking.
Tcl8.1 really blocks until N bytes are received.

Which behaviour is requested for a new driver ?


5. Call for contributions to a serial test suite for NT/95/98
=============================================================
The heading says it all.

Any comments are welcome.

Regards,
Rolf.

---------------------------------------------------------------------
German Aerospace Center Rolf Schroedter
Inst. of Planetary Exploration Tel/Fax: +49 (30) 67055-416/384
Rudower Chaussee 5, D-12489 Berlin Internet: Rolf.Sc...@dlr.de

Reply all
Reply to author
Forward
0 new messages