On Wed, 16 Feb 2011 10:53:32 +0100, Michael Schnell <[email protected]> wrote:
>On 02/15/2011 01:49 AM, Paulo Costa wrote: >> >> The SdpoSerial component creates a thread to listen and generates an >> event when bytes are received. So reading can be non-blocking. >> The write methods are direct calls to the Synaser ones and they are >> blocking. >> >So I feel that SdpoSerial needs a buffer to hold the data read from the >interface until the main thread is inclined to bother. The size of this >buffer should somehow be configurable. > In my application I use an object that encapsulates the communication with the instrument. I create an SdpoSerial object to do the actual serial comm, but I also had to create a TCommBuffer class to handle the data *from* the RS232 receive. So in the receive event of the SdpoSerial I just dump incoming characters into this TCommBuffer object, which keeps track of write and read indices. The data are stuffed into a dynamic byte array, which is enlarged on demand (but in large chunks so the overhead of expansion will not be noticed). I did this for receive in order to handle the "strange" protocol used by the instrumentation. Maybe I should expand this and use the same for transmit also, such that the main application merely adds data to the buffer and a thread sends the data onwards into the blocking WriteData method? That way I can monitor the difference of the read and write indices as a "remaining to be sent" value in a wait loop in my main application. I might even let the thread create the SdpoSerial object so it is only touched by the thread itself... But I don't know what would happen because the SdpoSerial object has internal threads of its own, I believe. -- Bo Berglund Developer in Sweden -- _______________________________________________ Lazarus mailing list [email protected] http://lists.lazarus.freepascal.org/mailman/listinfo/lazarus
