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] > <javascript:>> 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) >
