[Gambas-user] Asking about a new Command

[nando]

Your example is a way.
If 'yourBufferCompleteText' is an involved process, then it will fall
behind and the buffer may overflow.  This was already tested.

This app uses 5 serial ports per each of hundreds of computers plus
servers plus multiple programs simultaneously running on each computer.
The 'same idea' example was tried initially and reworked many times.
It doesn't work properly.
Instead, a different and 'non-obvious' approach solved it
and full serial port speeds use only a few % CPU.  This is good.
Thanks everyone for your help.
-Fernando


---------- Original Message -----------
From: "Timothy Marshal-Nichols" <timothy.marshal-nichols at ...247...>
To: <gambas-user at lists.sourceforge.net>
Sent: Thu, 25 May 2006 06:48:23 +0100
Subject: RE: [Gambas-user] Asking about a new Command

> > -----Original Message-----
> > From: gambas-user-admin at lists.sourceforge.net
> > [mailto:gambas-user-admin at lists.sourceforge.net]On Behalf Of nando
> > Sent: Wednesday, 24 May 2006 19:33
> > To: gambas-user at lists.sourceforge.net
> > Subject: Re: [Gambas-user] Asking about a new Command
> > 
> > 
> > Thanks to everyone for your replies.
> > 
> > This project is over a year in the making at considerable cost
> > and is quite involved.  It operates as a set of concurrent multiple
> > programs and runs on hundreds of computers.  There is use of some
> > specialized communication equipment.
> > 
> > The particular problem is I need to wait a small amount of time
> > for a particular hardware condition to be ready.
> > 
> > In my case, with Serial Port characters streaming in, if I use
> > the WAIT 0.5, inside the _Read, it will recurse more _Reads while
> > the processing of the first is incomplete.
> > This actually makes the stream processed out of order because
> > the 'newer' _Read process the next char while the original _Read
> > that invoked the WAIT is still unfinished.
> > So, processing events is forbidden in this case.
> > 
> > A empty loop consumes CPU...other programs are running.
> > WAIT allows processing of things out of order.
> > Although the SHELL sleep works, it is too much overhead.
> > 
> > This problem exists in the VB world when using DoEvents.
> > My solution in the VB world is to use a Boolean inside
> > the critical SUBs that can recurse and simply exit when busy.
> > That too, still uses too much CPU because there are always
> > characters waiting and _Read will 'event' by the interpreter
> > just to do a quick exit.
> > 
> > A Delay statement sounded like a you might have been interested in.
> > Essentially it would be sleeping using the kernel.
> > 
> > Eventhough we use fast computers, managing and minimizing CPU usage
> > is still an important item.
> > 
> > Of course, I may be ignorant and uninformed of other ways and
> > overlooking something easy...to which you all have been helpful.
> > 
> > Thanks
> > -Fernando
> >
> 
> Surly the normal way to use a serial port is something like the following:
> 
> PRIVATE buffer AS String
> 
> PUBLIC SUB SerialPort1_Read()
>   DIM s AS String
> 
>   ' Read data from serial port
>   LINE INPUT #SerialPort1, s
> 
>   ' Add data to buffer
>   buffer = buffer & s
> 
>   ' Test if we have all the required data
>   IF yourBufferCompleteText THEN
> 
>     ' Process buffer
> 
>     ' Clear buffer
>     buffer = ""
>   END IF
> END
> 
> This way there is no need for a wait at all.
> 
> Thanks
> 
> 8-{)} Timothy Marshal-Nichols
> <mailto: timothy.marshal-nichols at ...247...>
> 
> -------------------------------------------------------
> All the advantages of Linux Managed Hosting--Without the Cost and Risk!
> Fully trained technicians. The highest number of Red Hat 
> certifications in the hosting industry. Fanatical Support. Click to 
> learn more
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=107521&bid=248729&dat=121642
> _______________________________________________
> Gambas-user mailing list
> Gambas-user at lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/gambas-user
------- End of Original Message -------