You are quite correct, that is not the issue. When I tested, I had
originally executed through Pycharm and it masked the problem. When
executing through a terminal console, the problem was still there even with
the -u and flush=True options.
I think I may have a better understanding now, and perhaps it is the
difference between the ProactorEventLoop and SelectorEventLoop. I slowed
down the speed that the Arduino is sending blocks of data from the original
rate of every 17 ms to a rate of every 30 ms and the problem disappears.
Luckily, this is easy to do through an API call I implemented and so I
will document this for Windows users. My code uses the default event loops
chosen for the operating system.
The amount of data coming through the USB serial port seems to be
overwhelming Windows. (But no so for Linux/Mac).
I am not sure if this is a Windows issue or a ProactorEventLoop issue, and
I am not sure if this would be considered a bug or not, but I really
appreciate your taking the time to address the issue.
Thanks.
Alan Yorinks
On Friday, November 27, 2015 at 3:25:49 PM UTC-5, Guido van Rossum wrote:
>
> From the looks of it this doesn't have anything to do with asyncio. It
> seems to be about the default buffering of sys.stdout, which asyncio
> doesn't touch. Does this program exhibit the same behavior?
>
> import time
> while True:
> print('hello')
> time.sleep(5)
>
> On Fri, Nov 27, 2015 at 5:44 AM, Alan Yorinks <[email protected]
> <javascript:>> wrote:
>
>> I forgot to mention this is Python 3.5
>>
>>
>> On Friday, November 27, 2015 at 8:43:24 AM UTC-5, Alan Yorinks wrote:
>>>
>>> I am the author of pymata-aio
>>> <https://github.com/MrYsLab/pymata-aio/wiki>, an asyncio library for
>>> communicating with Arduino boards. The example code below is a "fix" for a
>>> problem encountered only on Windows, and I don't know if this is expected
>>> behavior or a bug.
>>>
>>> The code uses pymata-aio to configure an Arduino for analog input on 2
>>> pins and digital input input on 2 other pins. The Arduino reports analog
>>> and digital input data updates asynchronously approximately every 17 ms. To
>>> have the code work properly on Windows, the user must start python with the
>>> -u option and in addition, add the flush=True option to the print
>>> statement. If this is not done, the data that is being printed lags behind
>>> the actual data changes.
>>>
>>> Neither the -u option nor the flush=True are required for Linux/Mac
>>> operation. I suspect the differences between the OS's event loop
>>> implementations is at the root of the problem.
>>>
>>> The code may be viewed here:
>>> https://gist.github.com/MrYsLab/c3a69625cf844cbeb9e0.
>>>
>>> Any thoughts if this is a bug or not?
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>
>
> --
> --Guido van Rossum (python.org/~guido)
>
