[Rxtx] Data loss in high ratio while reading event based with SerialPortEvent.DATA_AVAILABLE

Michael Erskine msemtd at googlemail.com
Wed Mar 30 02:28:44 MDT 2011


On 29 March 2011 16:22, Beyefendi <beyefendipass at yahoo.com> wrote:
>
> In my first post, I had sent my code.
> Below, I took a part of it.
> code-block-1
> //byte[] buffer = new byte[is.available()];
> String buffer;
> while (is.available() > 0) {
> //is.read(buffer);
> buffer = br.readLine();
> When I started to develop this program, I was reading with is.read(buffer).
> As you know, this method, reads what is available.
> I've mostly never read a complete packet in one read with it.
> So, I had to combine the packet parts.
> I was doing combination with string concatenate like lackingPacket += packet
> But this operation made lots of errornous packets.

OK, at this point I'd be asking myself "why does this operation make
lots of erroneous packets?"

Whilst I can't answer that for you, I suggest you debug your code, add
some logging, etc.

That particular ByteSink you found is unlikely to be the one I use --
AFAIK my code has never been publicly released - it's a very simple
interface so I'll include it here (sans javadoc)...

public interface ByteSink {
    public int processBytes(byte[] buf, int len);
    public void processEof();
    public void processException(IOException e);
}

In my SerialPortEvent.DATA_AVAILABLE event handler...

            try {
                int i = istrm.read(rawbuf);
                if (i == -1) {
                    sink.processEof();
                    return;
                }
                sink.processBytes(rawbuf, i);
                return;
            } catch (IOException e) {
                sink.processException(e);
                return;
            }

Here, rawbuf is a byte array of "reasonable" size for the expected
data rate, say 512 bytes.

The serial data reading functionality is entirely independent from
data processing functionality and is reused on all of our projects
that read serial data. I haven't had to change this code since we
moved to RXTX from the Sun Java Comm library some years back!



More information about the Rxtx mailing list