[Gambas-user] Issue/Problem with Serial Port Component

[Timothy Marshal-Nichols]

> -----Original Message-----
> From: gambas-user-bounces at lists.sourceforge.net
> [mailto:gambas-user-bounces at lists.sourceforge.net]On Behalf Of nando
> Sent: Sunday, 04 June 2006 23:52
> To: mailing list for gambas users
> Subject: Re: [Gambas-user] Issue/Problem with Serial Port Component
>
>
> There is no CR/LF
> The data is ASCII text
>
>
> ---------- Original Message -----------
> From: ron <ronstk at ...239...>
> To: nando_f at ...951..., mailing list for gambas users
> <gambas-user at lists.sourceforge.net>
> Sent: Mon, 5 Jun 2006 00:44:05 +0200
> Subject: Re: [Gambas-user] Issue/Problem with Serial Port Component
>
> > On Sunday 04 June 2006 23:52, nando wrote:
> > > I have tested this for hours...
> > >
> > > PUBLIC SPortReceiveString AS STRING
> > >
> > > SUB SPort_Read()
> > >
> > >   DIM s AS STRING
> > >   DIM ls AS INTEGER
> > >
> > >   ls = LOF(SPort)
> > >   'IF ls > 1 THEN DEC ls   '<---always read 1 less than what
> LOF offers
> > >
> > >   READ # SPort, s, ls
> > >
> > >   PRINT s  '<--help to debug
> > >
> > >   SPortReceiveString = SPortReceiveString & s  'accumulate input
> > >
> > >   'There is some testing of SPortReceiveString here
> > >
> > > END
> > >
> > > Comments:
> > > Serial Port data received is in groups of about 120 bytes
> every 10 minutes.
> > > Every READ event is a small bunch of characters received.
> > >
> > > I have found out that it consistently happens that
> > > the during the SPort_Read event of the second last bunch of chars,
> > > there are more data being receive by the kernel or SPort control
> > > but an event will not happen.
> > >
> > > If I unREM the REMed line...
> > >
> > >   IF ls > 1 THEN DEC ls   '<---always read 1 less than what LOF offers
> > >
> > > then it works perfect every time.
> > > An event will happen for the very past burst of serial data in.
> > >
> > > -Fernando
> > >
> >
>

Why are you not reading the complete serial port stream? This is one of your
problems. I showed you how to read a serial port in a previous email. So let
spell it out for you. Here is a demo serial port application. Something like
this is what you should be doing:

PRIVATE buffer AS String

PUBLIC SUB SerialPortDevice_Read()
  DIM s AS String
  DIM i AS Integer
  DIM lineItem AS String
  READ #SerialPortDevice, s, Lof(SerialPortDevice)
  buffer &= s
  i = InStr(buffer, "\r\n")
  WHILE (i > 0)
    ' Get next data item up to CrLf
    lineItem = Mid(buffer, 1, i + 1)
    ' Show last item in the label
    LabelLastDataItem.Text = lineItem
    ' Append data to text area
    TextAreaData.Pos = TextAreaData.Length
    ' The 'replace' in this line is simply because the text area
    ' does not look nice with a return char in it
    TextAreaData.Insert(Replace(lineItem, "\r", ""))
    ' Clear buffer up to CrLf
    buffer = Mid(buffer, i + 2)
    i = InStr(buffer, "\r\n")
  WEND
  TextAreaData.Pos = TextAreaData.Length
  TextAreaData.EnsureVisible()
END

Most devices you communicate with using a serial port append some kind of
terminating characters to the end of the data they send. This version of a
serial port read demo's this kind of serial communications. Here we are
looking for a DOS/Windows type of carriage return/line feed pair.
	Each time the serial port transmits data we can not guarantee we have a
complete line of data so we buffer the data received. We then look in the
buffer to check if we have found our terminating characters. If it is found
we process the line.
	If we are receiving lots of data we also need to be able to handle the
situation where we have more than one line in our buffer. This could happen
if a large text file was being sent to this application. For this reason we
process the buffer up to the CrLf pair. and then clear the buffer up to the
end of the CrLf pair. We place this in a loop to ensure all data is
processed.

A NOTE ON SPEED: When you are using this demo application you will find that
serial communication take almost no CPU time to process.

Try this with this demo application and with some utility running to see CPU
usage:

	1.Select the Settings tab. Send a large text file to this project.  You
will see CPU usage is very low.

	2.Select the Data tab. Send the same text file to this application. You
will see that CPU usage is a bit higher.

This shows that most CPU usage is take up with redrawing the TextArea
control AND NOT WITH SERIAL COMMUNICATIONS.

The lesson is if you are doing lots of serial communications then ensure you
are not continuously updating your user interface with each character
sent!!!!!!!!



Thanks

8-{)} Timothy Marshal-Nichols
<mailto: timothy.marshal-nichols at ...247...>



-------------- next part --------------
A non-text attachment was scrubbed...
Name: SerialPort.tar.bz2
Type: application/octet-stream
Size: 29936 bytes
Desc: not available
URL: <http://lists.gambas-basic.org/pipermail/user/attachments/20060605/019427ef/attachment.obj>