Re: [Gambas-user] Serial port control

[Carl N. <ni...@ii...>]

G'day Guys (Nando, Randall and Mike):
Thanks for your helpful replies.  It's 5 am here and I woke up an 
hour ago with this matter running through my head, so your replies 
are welcome!  All good advice.  I realized that, first of all, I 
needed to get a handle on using the stream functions, which are quite 
new to me.  Secondly, as usual, there are many ways to skin a 
cat.  You are right, I need not be dependent on an RThreshold 
property.  I have been using this for years most successfully with 
MScomm in VB6.  It does exert efficient control, but sometimes my 
incoming packets vary in byte count..  So, early in the piece, I 
wrote code that would look for any remainder bytes or shortfall on 
the end of the designated input stream and put them onto the start of 
the next byte block to get back into synch.  The Windows kernel has a 
very efficient function called "MoveMemory" that can be called from 
VB6.  (I presume Linux has something similar).  It's very much faster 
than shifting bytes in Do loops.

Anyway, not being dependent on an totally accurate byte count prior 
to triggering an event suggested an alternate approach:  My principal 
data device is a decade-old  Microstrain Inertial Management Unit 
(IMU).that sends remorselessly at around 2356 bytes (sometimes plus a 
packet or two) per sec.  At the moment I'm doing all my processing on 
an old Advantech 9576F single board computer running Win 2K.  With 
about 8 serial ports in action and heaps of other processing to do, I 
wanted to ease things with some preprocessing of some data streams on 
one of these little new ARM boards like the Raspberry Pi or 
Beaglebone Black - the latter with at least 4 UARTS and running at 1 
GHz seems very attractive. They can run fully embedded under Linux 
with gambas for initial data processing.   I have an RPi now with 
gambas3 and wiring Pi installed to experiment with. Sometimes the IMU 
traffic is duplex when I change parameters in flight and additional 
data packets come back in addition to the normal data flow.  So I 
adjust the RThreshold value dynamically, but that's not vital.  All 
this adds up to the fact that another approach might be to trigger 
processing events simply with a timer - read the full stream each 
time and get the byte count approximately right.  With a "MoveMemory" 
function I can easily handle some unevenness in byte count.  As I 
said, I'm looking for the least drain on CPU load.   I don't really 
need the system tied up waiting and testing for an exact count.

Anyway, I thank you for all your comments.  I now know that what I 
need can be done and the next step is for me to 
experiment.  Yesterday I was having some doubts about choosing 
gambas.  Nice to talk with you guys.  I'll get back to you when I 
have something more useful to say or ask.
Merry Christmas, Carl

At 08:03 PM 23/12/2013, you wrote:
>My suggestion to reading 124 bytes from a serial stream....
>
>I use this technique mostly because I want to empty the buffer 
>provided by the control
>as much as possible.
>
>I would have one function which is the _read of the serial port.
>The only thing it does is accumulate bytes in an array.
>
>I have another function which will ask for 124 bytes from the 
>accumlating array.
>If there are not enough, it can block, or return an array of zero long
>which would mean not enough came in.
>In this case you could also do a small time delay (ie. WAIT 0.1)
>just to prevent the CPU from running 100% testing for 124 bytes.
>
>
>Both of these can be a Gambas Class and the second function is the 
>public function.
>You can use _new to instantiate the serial port control.
>You don't need to create it at design time.
>
>I used techniques like this and it works like a charm.
>-Nando
>
>
>---------- Original Message -----------
>From: Randall Morgan <rmo...@gm...>
>To: mailing list for gambas users <gam...@li...>
>Sent: Sun, 22 Dec 2013 23:35:33 -0800
>Subject: Re: [Gambas-user] Serial port control
>
> > I think the RTheshold of VB simply sets the byte count that must accumulate
> > in the receive buffer before a comm event is triggered. It doesn't do
> > anything else. In the background VB is still polling the buffer and looking
> > at the byte count. You can do this in GB but you will have to write it
> > yourself. You would need to simply use the read event on the comm object to
> > test the byte count. I believe it triggers at 1 byte. Then use that to
> > trigger your own custom event when your 124 bytes have arrived.
> >
> > You might also be able to talk Benoit into adding an RThreshold property.
> > Seems like it might be handy.... At the very least 4Hz is very very slow
> > for most computers. And setting up a 4Hz polling of the port wouldn't be
> > hard at all.
> >
> > On Sun, Dec 22, 2013 at 8:10 PM, Carl Nilsson <ni...@ii...> wrote:
> >
> > > Thanks Randall.  I guess it's time to try it and play around a
> > > little, which I can't do for a few days.  At the moment I'm trying to
> > > look ahead and see where problems might lie.

(snip)


Carl S Nilsson
137 Gordons Hill Road
Lindisfarne, Tas.
Australia 7015