Another thought: you can use the SelectorEventLoop even on Windows. That could help you narrow it down.
On Sun, Nov 29, 2015 at 5:09 AM, Alan Yorinks <[email protected]> wrote: > I agree that the USB port is not the problem and but I believe that it is > not my callback mechanism either. The reason I say this, is that if I run > pymata_iot , an application that wraps the pymata-aio library with Autobahn > WebSockets and exposes the pymata-aio API through a set of JSON messages, > and then bring up a webpage that implements the JSON protocol > (http://mryslab.github.io/pymata-aio/examples/uno_iot_tester.html), I can > enable all 5 analog inputs and no lag is exhibited at all. The same holds > true for another application, s2aio > <https://github.com/MrYsLab/s2aio/wiki>, that uses pymata-aio to > interface the Scratch programming language to Arduino boards. No lag > exhibited there either. > > I can't guarantee that the problem is not internal to pymata-aio, so I > will try to come up with an example independent of pymata-aio that > reproduces the problem. > > Again thanks. > > On Saturday, November 28, 2015 at 5:15:24 PM UTC-5, Guido van Rossum wrote: >> >> Hm, I don't know how much data your device sends every 17ms or how >> inefficient the hardware is, but it does sound a bit unlikely that the >> Windows USB port can't keep up. I certainly don't believe that the >> ProactorEventLoop itself can't keep up. >> >> But there may be other differences. One thing to know is that on Windows >> some important timers run only at (roughly) 17ms precision. Perhaps you are >> getting bursts of multiple callbacks and not handling them right? I haven't >> looked at the PyMata code itself, but you may want to dive into this >> further before just giving up and saying "it's Windows". >> >> >> >> On Sat, Nov 28, 2015 at 12:29 PM, Alan Yorinks <[email protected]> wrote: >> >>> 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]> >>>> 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) >>>> >>> >> >> >> -- >> --Guido van Rossum (python.org/~guido) >> > -- --Guido van Rossum (python.org/~guido)
