Re: FTDI user space on Windows

[Lubomir I. Ivanov]

On 15 September 2018 at 01:48, Bill Perry  wrote:
> Yes, I can do PR. (once I figure out how to do signing)

feel free to ask any github related questions, if any.

> but I don't understand:
>
>> sleeping for small chunks of time can end up being better.
>
> The modification I did used the exact same constant 1ms sleep after each 
> ftdi_read_data() call that the current code does but it checked elapsed time 
> prior each 1ms sleep
> rather than counting the number of 1ms sleeps until they equaled the desired 
> millisecond timeout.
> Counting the number of 1ms sleeps done does not work since it does account for
> the time inside the loop (which can be significant like 100+ ms) since 
> sometimes the ftdi_read_data() doesn't return immediately
> when there is no data.
> That is why looking at elapsed time is required.
>
> Are you wanting something smarter than changing the way the loop exits by 
> checking elapsed time instead of blindly looping {timout} times?
>

ah, i misunderstood the initial comment, sorry.
i'd encourage you to send the PR so that we can have a look at the
code and discuss it.

thanks
lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: FTDI user space on Windows

[Lubomir I. Ivanov]

On 13 September 2018 at 21:44, Bill Perry  wrote:
> Just a reminder that last summer I saw that the code in serial_ftdi_read() 
> doesn't guarantee that a timeout occurs
> in the desired timeout period.
> Due to the way it is written, you can get MUCH longer delays when the bytes 
> don't stream in right away or
> This was an issue I was fighting last year when I was trying to get retries 
> to work on the Pelagic data cable with Android.
> It actually affects any ftdi device.
> This is likely an issue on Windows as well.
>
> ftdi_read_data() took a few milliseconds of time before returning and that 
> time is not accounted for.
> And on android the the LIBUSB_ERROR_INTERRUPTED was also happening.
> This caused the while loop to loop for several minutes before timing out.
> My solution (which I posted a patch for to the list back in Nov 2017) was to 
> get rid of slept and to always sleep for 1ms.
> Then rather than comparing slept >= timeout - which doesn't work, was to use 
> gettimofday()
> to check for the elapsed time to check for the desired timeout period.
>

sleeping for small chunks of time can end up being better.
would you like to submit a github PR to address this improvement as
per your experiments?

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: FTDI user space on Windows

[Bill Perry]

Just a reminder that last summer I saw that the code in serial_ftdi_read() 
doesn't guarantee that a timeout occurs
in the desired timeout period.
Due to the way it is written, you can get MUCH longer delays when the bytes 
don't stream in right away or
This was an issue I was fighting last year when I was trying to get retries to 
work on the Pelagic data cable with Android.
It actually affects any ftdi device.
This is likely an issue on Windows as well.

ftdi_read_data() took a few milliseconds of time before returning and that time 
is not accounted for.
And on android the the LIBUSB_ERROR_INTERRUPTED was also happening.
This caused the while loop to loop for several minutes before timing out.
My solution (which I posted a patch for to the list back in Nov 2017) was to 
get rid of slept and to always sleep for 1ms.
Then rather than comparing slept >= timeout - which doesn't work, was to use 
gettimofday()
to check for the elapsed time to check for the desired timeout period.

--- bill





smime.p7s
Description: S/MIME Cryptographic Signature
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: FTDI user space on Windows

[Dirk Hohndel]

> On Sep 11, 2018, at 5:46 PM, Lubomir I. Ivanov  wrote:
> 
> proposed patch:
> https://github.com/Subsurface-divelog/subsurface/pull/1668 
> 
> 

Oh how simple. I am traveling and don't have a Windows system and FTDI device 
with me, but I'll try this on Friday.

Thanks

/D

___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: FTDI user space on Windows

[Lubomir I. Ivanov]

On 10 September 2018 at 08:05, Dirk Hohndel  wrote:
>
> This should be so simple. libtfdi is available in MXE, so just build against
> it, right?
> Except this:
>
> static dc_status_t serial_ftdi_sleep (void *io, unsigned int timeout)
> {
> ftdi_serial_t *device = io;
>
> if (device == NULL)
> return DC_STATUS_INVALIDARGS;
>
> INFO (device->context, "Sleep: value=%u", timeout);
>
> struct timespec ts;
> ts.tv_sec  = (timeout / 1000);
> ts.tv_nsec = (timeout % 1000) * 100;
>
> while (nanosleep (, ) != 0) {
> if (errno != EINTR ) {
> SYSERROR (device->context, errno);
> return DC_STATUS_IO;
> }
> }
>
> return DC_STATUS_SUCCESS;
> }
>
> Turns out Windows doesn't have nanosleep. And I can't seem to find a
> function with comparable semantic, unless I use the one in the pthread
> library that is provided by MinGW which is not what we want to do.
> So the question becomes how to represent this with something that gives us
> the same semantic / functionality.
>

proposed patch:
https://github.com/Subsurface-divelog/subsurface/pull/1668

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

Re: FTDI user space on Windows

[Lubomir I. Ivanov]

On 10 September 2018 at 08:05, Dirk Hohndel  wrote:
>
> This should be so simple. libtfdi is available in MXE, so just build against
> it, right?
> Except this:
>
> static dc_status_t serial_ftdi_sleep (void *io, unsigned int timeout)
> {
> ftdi_serial_t *device = io;
>
> if (device == NULL)
> return DC_STATUS_INVALIDARGS;
>
> INFO (device->context, "Sleep: value=%u", timeout);
>
> struct timespec ts;
> ts.tv_sec  = (timeout / 1000);
> ts.tv_nsec = (timeout % 1000) * 100;
>
> while (nanosleep (, ) != 0) {
> if (errno != EINTR ) {
> SYSERROR (device->context, errno);
> return DC_STATUS_IO;
> }
> }
>
> return DC_STATUS_SUCCESS;
> }
>
> Turns out Windows doesn't have nanosleep. And I can't seem to find a
> function with comparable semantic, unless I use the one in the pthread
> library that is provided by MinGW which is not what we want to do.
> So the question becomes how to represent this with something that gives us
> the same semantic / functionality.
>
> I am anything but a Windows expert. Suggestions welcome.
>

i can have a look a bit later today.

lubomir
--
___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface

FTDI user space on Windows

[Dirk Hohndel]

This should be so simple. libtfdi is available in MXE, so just build against 
it, right?
Except this:

static dc_status_t serial_ftdi_sleep (void *io, unsigned int timeout)
{
ftdi_serial_t *device = io;

if (device == NULL)
return DC_STATUS_INVALIDARGS;

INFO (device->context, "Sleep: value=%u", timeout);

struct timespec ts;
ts.tv_sec  = (timeout / 1000);
ts.tv_nsec = (timeout % 1000) * 100;

while (nanosleep (, ) != 0) {
if (errno != EINTR ) {
SYSERROR (device->context, errno);
return DC_STATUS_IO;
}
}

return DC_STATUS_SUCCESS;
}

Turns out Windows doesn't have nanosleep. And I can't seem to find a function 
with comparable semantic, unless I use the one in the pthread library that is 
provided by MinGW which is not what we want to do.
So the question becomes how to represent this with something that gives us the 
same semantic / functionality.

I am anything but a Windows expert. Suggestions welcome.

Thanks

/D___
subsurface mailing list
subsurface@subsurface-divelog.org
http://lists.subsurface-divelog.org/cgi-bin/mailman/listinfo/subsurface