guyeeba commented 8 years ago

When I try to use this lib in a UWP app, it throws an EndOfStreamException at System.IO.BinaryReader.ReadByte() at BinarySerialization.Graph.ValueGraph.ValueValueNode.Deserialize(EndianAwareBinaryReader reader, SerializedType serializedType, Nullable1 length)`

The exception is thrown at the very beginning of the process, during FindAndOpen()... actually it happens the first time ReadByte() is called.

The same thing happens with an FTDI-based XBee board, and with a Leonardo-based serial passthrough device. The XBees are accessible from XCTU through both adapters. I tried with a simple S2, and an S2C Pro TH module, both set to 9600 baud, AO=1, and the result was the same: EndOfStreamException.

Do you have any idea what might be wrong?

jefffhaynes commented 8 years ago

It might be a side-effect of UWP but let me take a look tomorrow. I've been porting to .net core and should have something by the end of the week, which might help. Thanks

On Mon, Mar 21, 2016 at 10:40 AM -0700, "guyeeba" notifications@github.com wrote:

When I try to use this lib in a UWP app, it throws an EndOfStreamException

at System.IO.BinaryReader.ReadByte()

at BinarySerialization.Graph.ValueGraph.ValueValueNode.Deserialize(EndianAwareBinaryReader reader, SerializedType serializedType, Nullable1 length)`

The exception is thrown at the very beginning of the process, during FindAndOpen()... actually it happens the first time ReadByte() is called.

The same thing happens with an FTDI-based XBee board, and with a Leonardo-based serial passthrough device. The XBees are accessible from XCTU through both adapters. I tried with a simple S2, and an S2C Pro TH module, both set to 9600 baud, AO=1, and the result was the same: EndOfStreamException.

Do you have any idea what might be wrong?

— You are receiving this because you are subscribed to this thread. Reply to this email directly or view it on GitHub

jefffhaynes commented 8 years ago

Sorry, I'm still working on porting the underlying serializer to .net core. Hope to have something soon...

randomcapital commented 8 years ago

It's okay, thanks for your effors, it's really appreciated.

guyeeba commented 8 years ago

I managed to get closer to solution (once again, UWP app issue).

1) the default value of SerialDevice.DataBits is 7. Explicitly setting it to 8 makes the serial port work perfectly:

        public static async Task<XBeeController> FindAndOpen()
        {
            var controller = new XBeeController();

            string aqs = SerialDevice.GetDeviceSelector();
            var devices = await DeviceInformation.FindAllAsync(aqs);

            foreach (var device in devices)
            {
                try
                {
                    var serialDevice = await SerialDevice.FromIdAsync(device.Id);
                    if (serialDevice == null)
                        return null;
                    else
                    {
                        serialDevice.DataBits = 8;

                        await controller.OpenAsync(serialDevice);
                        return controller;
                    }
                }
                catch (InvalidOperationException)
                {
                }
                catch (UnauthorizedAccessException)
                {
                }
                catch (ArgumentOutOfRangeException)
                {
                }
                catch (ArgumentException)
                {
                }
                catch (TimeoutException)
                {
                }
                catch (IOException)
                {
                }
            }

            return null;
        }

2) The way SerialDevice works in UWP does not allow you to close the port, therefore the open-getHV-close-reopen logic you use in XBeeController.OpenAsync does not work (BinarySerializer is blocked in Stream.Read as the underlying port cannot be closed). Restructuring BinarySerializer to support CancellationTokens would be way too much work for me, so my workaround was to insert an additional Stream layer into the SerialDevice-FrameSerializer path (warning, ugly code, proof-of-concept only!):

SerialConnection.Open:

[...]
                        try
                        {
#if NETCORE
                            _serialReadStream = new ClosableInputStream(_serialPort.InputStream, cancellationToken);

                            Frame frame = _frameSerializer.Deserialize(_serialReadStream);
#else
                            Frame frame = _frameSerializer.Deserialize(_serialPort.BaseStream);
#endif
[...]

where ClosableInputStream is

    public class ClosableInputStream : Stream
    {
        public ClosableInputStream(IInputStream stream, CancellationToken cancellationToken)
        {
            Source = stream;
            _cancellationToken = cancellationToken;
            dataReaderObject = new DataReader(stream);
        }

        public IInputStream Source { get; }
        public CancellationToken _cancellationToken { get; }
        public DataReader dataReaderObject { get; }

        public override bool CanRead => true;
        public override bool CanSeek => false;
        public override bool CanWrite => false;
        public override long Length => 0;
        public override long Position
        {
            get
            { return 0; }
            set
            { }
        }

        public override void Flush()
        {
            throw new NotImplementedException();
        }

        public override int Read(byte[] buffer, int offset, int count)
        {
            _cancellationToken.ThrowIfCancellationRequested();

            dataReaderObject.InputStreamOptions = InputStreamOptions.Partial;

            try
            {
                Task<UInt32> loadAsyncTask = dataReaderObject.LoadAsync((uint)count).AsTask(_cancellationToken);

                loadAsyncTask.Wait(_cancellationToken);
                UInt32 bytesRead = loadAsyncTask.Result;

                if (bytesRead > 0)
                {
                    IBuffer buff = dataReaderObject.ReadBuffer((uint)count);
                    buff.CopyTo(0, buffer, offset, count);
                }

                return (int)bytesRead;
            }
            catch
            {
                throw;
            }
        }

        public override long Seek(long offset, SeekOrigin origin)
        {
            throw new NotImplementedException();
        }

        public override void SetLength(long value)
        {
            throw new NotImplementedException();
        }

        public override void Write(byte[] buffer, int offset, int count)
        {
            throw new NotImplementedException();
        }
    }

So it seems to implement (production-ready) support for UWP needs some restructuring of underlying libraries to support cancellation. Or do you have a better idea how to workaround this issue?

jefffhaynes commented 8 years ago

That's funny, I was just cursing myself a few days ago for going with the open-and-stay-open approach. Let me digest all this and get back to you. Thanks.

On Thu, Apr 21, 2016 at 3:02 AM, guyeeba notifications@github.com wrote:

I managed to get closer to solution (once again, UWP app issue).

1) the default value of SerialDevice.DataBits is 7. Explicitly setting it to 8 makes the serial port work perfectly:

    public static async Task<XBeeController> FindAndOpen()
    {
        var controller = new XBeeController();

        string aqs = SerialDevice.GetDeviceSelector();
        var devices = await DeviceInformation.FindAllAsync(aqs);

        foreach (var device in devices)
        {
            try
            {
                var serialDevice = await SerialDevice.FromIdAsync(device.Id);
                if (serialDevice == null)
                    return null;
                else
                {
                    serialDevice.DataBits = 8;

                    await controller.OpenAsync(serialDevice);
                    return controller;
                }
            }
            catch (InvalidOperationException)
            {
            }
            catch (UnauthorizedAccessException)
            {
            }
            catch (ArgumentOutOfRangeException)
            {
            }
            catch (ArgumentException)
            {
            }
            catch (TimeoutException)
            {
            }
            catch (IOException)
            {
            }
        }

        return null;
    }

2) The way SerialDevice works in UWP does not allow you to close the port, therefore the open-getHV-close-reopen logic you use in XBeeController.OpenAsync does not work (BinarySerializer is blocked in Stream.Read as the underlying port cannot be closed). Restructuring BinarySerializer to support CancellationTokens would be way too much work for me, so my workaround was to insert an additional Stream layer into the SerialDevice-FrameSerializer path (warning, ugly code, proof-of-concept only!):

SerialConnection.Open:

[...] try {

if NETCORE

                        _serialReadStream = new ClosableInputStream(_serialPort.InputStream, cancellationToken);

                        Frame frame = _frameSerializer.Deserialize(_serialReadStream);

else

                        Frame frame = _frameSerializer.Deserialize(_serialPort.BaseStream);

endif

[...]

where ClosableInputStream is

public class ClosableInputStream : Stream
{
    public ClosableInputStream(IInputStream stream, CancellationToken cancellationToken)
    {
        Source = stream;
        _cancellationToken = cancellationToken;
        dataReaderObject = new DataReader(stream);
    }

    public IInputStream Source { get; }
    public CancellationToken _cancellationToken { get; }
    public DataReader dataReaderObject { get; }

    public override bool CanRead => true;
    public override bool CanSeek => false;
    public override bool CanWrite => false;
    public override long Length => 0;
    public override long Position
    {
        get
        { return 0; }
        set
        { }
    }

    public override void Flush()
    {
        throw new NotImplementedException();
    }

    public override int Read(byte[] buffer, int offset, int count)
    {
        _cancellationToken.ThrowIfCancellationRequested();

        dataReaderObject.InputStreamOptions = InputStreamOptions.Partial;

        try
        {
            Task<UInt32> loadAsyncTask = dataReaderObject.LoadAsync((uint)count).AsTask(_cancellationToken);

            loadAsyncTask.Wait(_cancellationToken);
            UInt32 bytesRead = loadAsyncTask.Result;

            if (bytesRead > 0)
            {
                IBuffer buff = dataReaderObject.ReadBuffer((uint)count);
                buff.CopyTo(0, buffer, offset, count);
            }

            return (int)bytesRead;
        }
        catch
        {
            throw;
        }
    }

    public override long Seek(long offset, SeekOrigin origin)
    {
        throw new NotImplementedException();
    }

    public override void SetLength(long value)
    {
        throw new NotImplementedException();
    }

    public override void Write(byte[] buffer, int offset, int count)
    {
        throw new NotImplementedException();
    }
}

So it seems to implement (production-ready) support for UWP needs some restructuring of underlying libraries to support cancellation. Or do you have a better idea how to workaround this issue?

— You are receiving this because you commented. Reply to this email directly or view it on GitHub https://github.com/jefffhaynes/XBee/issues/4#issuecomment-212773392

If you want to build a ship, don't drum up people together to collect wood and don't assign them tasks and work, but rather teach them to long for the endless immensity of the sea.

Antoine de Saint-Exupery

jefffhaynes commented 8 years ago

If you get a chance take a look at my latest check-in and see if it solves anything. I need to load up your code I just haven't had time yet.

guyeeba commented 8 years ago

The latest check-in is not really UWP-aware, I'm going to mess with it in the evening.

I noticed that you added XBeeProS2C to HardwareVersion with value of 0x21. Well, actually I use XBee Pro S2C modules (through-hole mounting scheme), but my devices have hardware version 0x2D (or 0x2D41 to be exact). You might add them, too... :)

jefffhaynes commented 8 years ago

Yeah, I'm actually surprised you got it working on UWP at all. I didn't think BinarySerializer would work yet. I really need to devote more time to it. Thanks for the hardware info. I'll add it.

On Thu, Apr 21, 2016 at 11:33 PM -0700, "guyeeba" notifications@github.com wrote:

The latest check-in is not really UWP-aware, I'm going to mess with it in the evening.

I noticed that you added XBeeProS2C to HardwareVersion with value of 0x21. Well, actually I use XBee Pro S2C modules (through-hole mounting scheme), but my devices have hardware version 0x2D (or 0x2D41 to be exact). You might add them, too... :)

— You are receiving this because you commented. Reply to this email directly or view it on GitHub