readString on SerialPort

Ned Konz ned at bike-nomad.com
Wed Aug 28 00:11:20 UTC 2002


On Tuesday 27 August 2002 04:20 pm, Scott Jaderholm wrote:
> Hi,
>
> I just had a few questions on serial ports in squeak.  I read the
> code for SerialPort>>readString but I'm not sure I understand it
> completely yet.  I'm thinking that the serial port keeps a cache of
> all the data it receives and then when you run readString it will
> give you up to the last 1000 characters it has received.  Is that
> correct?

The Squeak serial port code doesn't cache (unless someone did that in 
some non-Unix OS; I didn't do it in Unix). However, the OS probably 
does, and that's what the Squeak code is counting on.

You're right that readString returns up to the last 1000 characters 
(or until the end of the OS buffer, whichever is smaller).

> Then the next time you run readString it will only give you the
> characters since the last time readString was run?

Yes.

> Say I am downloading data over the serial port and I run
> readString, get part of my data, then 1005 characters of data comes
> in before I run readString
> again, I would have lost those 5 characters of data?

Depends on how much of a buffer there is at the OS level. If there are 
> 1000 characters of OS buffer, then you won't lose data in 
readString.

>  What kind of
> code would I use so readString gets run at the right time during a
> large download
> process as to not lose any data?

Ordinarily, the receiver has to transmit some periodic 
acknowledgements (and will be receiving well-defined buffer sizes); 
this defines a logical period for doing these things (see, for 
instance, the various ZModem variants). Otherwise, you need to poll 
at a rate that's high enough not to lose data (and you should also do 
this polling in a Process that isn't going to get starved very 
often).

-- 
Ned Konz
http://bike-nomad.com
GPG key ID: BEEA7EFE




More information about the Squeak-dev mailing list