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)
