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

[nando]

Thank you.

Many (other) things also communicate without CR/LF
especially if a device (like a radio, or machine, etc)

The things I use for communication do not use CR/LF for delineation.
Humans like CR/LF though because it visually separates lines.

For example, Chr$(2) and Chr$(3) are used by many devices for message
delineation.

Some devices are a binary stream and continuous parsing is the only
method possible especially when messages arrive at unknown bursts and
with varying formats.  CR/LF or ONE specific sequence would certainly
make things easiest, but this is not the case.

Add to the mix that if a SUB does not exit because it is waiting for
mor input to the delineator, there is no (other) event processing.

Perhaps Benoit is thinking of a multi-threaded Gambas which would
really be wild.  Having each coded event a possible separate thread
is a very new way to program.  Each SUB would have the keyword THREADED
to signify this and when the event fires..a new thread happens.




---------- Original Message -----------
From: "Timothy Marshal-Nichols" <timothy.marshal-nichols at ...247...>
To: <nando_f at ...951...>, "mailing list for gambas users"
<gambas-user at lists.sourceforge.net>
Sent: Mon, 5 Jun 2006 10:19:58 +0100
Subject: Re: [Gambas-user] Issue/Problem with Serial Port Component

> I have just remembered you have version 1 of Gambas. The demo in the
> previous email was of a Gambas 2 project. Here is a version of the project
> in version 1.0.16.
> 
> Thanks
> 
> 8-{)} Timothy Marshal-Nichols
> <mailto: timothy.marshal-nichols at ...247...>
> 
> > -----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
> > > >
> > >
> > > What is the real content of those 120 bytes and what program
> > > send the data?
> > >
> > > I'm thinking on a CR/LF problem.
> > > *nix use normal only one of them and if both are used
> > > the are CR/LF (or LF/CR).
> > > Windows use always both but reverse to *nix.
> > >
> > > One of them is the line terminator in gambas and when I'm right
> > > not returned in the string
> > > With  READ # SPort, s, ls you use a binairy transfer and this
> > > should include all bytes.
> > >
> > > >From the doc for READ
> > >   If Variable is a string, you can specify a length that indicates the
> > >   number of bytes to read. If the length is negative, then (- Length)
> > >   bytes are read up to the end of stream.
> > >
> > >   If no length is specified for a string, it is is read from the
> > > stream.  The string then must have been written with the WRITE
> > instruction.
> > >
> > > Maybe it helps to PRINT ASC(LEFT(s)) and PRINT ASC(left(s,-1))
> > > after each READ.
> > >
> > > Ron
> > >
> > > _______________________________________________
> > > Gambas-user mailing list
> > > Gambas-user at lists.sourceforge.net
> > > https://lists.sourceforge.net/lists/listinfo/gambas-user
> > ------- End of Original Message -------
> >
> >
> >
> > _______________________________________________
> > Gambas-user mailing list
> > Gambas-user at lists.sourceforge.net
> > https://lists.sourceforge.net/lists/listinfo/gambas-user
> >
------- End of Original Message -------