I found the problem and it was indeed in my code. To read serial data, I wrap the pyserial read method in a future. This all works without issue. After retrieving a character using this future, I had added (incorrectly) an additional asyncio.sleep(.001). Because of the constant barrage of data, this became additive on Windows. Removing that sleep solved the problem. This still does not explain why Linux and Windows behaves differently, but at least both Python 3.5 and Windows are off the hook.
Thanks for your patient suggestions. On Sunday, November 29, 2015 at 1:15:31 PM UTC-5, Alan Yorinks wrote: > > I tried changing the loop type, but pyserial stopped functioning. I think > the best thing at this point is for me to create a simple application that > receives data from the Arduino, and then simply print out what is being > sent back every x number of seconds. This will eliminate the bulk of my > code from the picture. If things fail, it will be simpler to pinpoint > where, and if things work, then it points to something in my code. > > Hopefully I will be able to get it this week and will report back with any > findings. > > > > On Sunday, November 29, 2015 at 11:47:04 AM UTC-5, Guido van Rossum wrote: >> >> 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) >> >
