-
Notifications
You must be signed in to change notification settings - Fork 1.3k
added .serial_bytes_available [was added timeout to input()] #1193
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
I see from the Travis build that this fails on some ports that don't have usb_bytes_available(). If there is a desire to go forward, I can add checks for particular architectures or features that work. For our (short-term) needs the M0 will work for us (which doesn't imply anything for accepting the PR of course - we can build from our fork) |
I don't want to add this as is because it breaks compatibility with CPython because input only takes in a prompt. https://docs.python.org/3/library/functions.html#input You could add this as a custom function in a custom module. It gets it closer to the second usb serial api that would be good in the long term. Let me know if you want help with that. |
I get it - I have no problem with that |
@tannewt (or whoever), I think I'd like to go ahead and add a module for this. It's trivial - just one method that checks whether there is input available on the console. In theory, it should be temporary as the updated async IO code would replace it. However, I think there are some use cases (including two of mine now) where this one feature is blocking other solutions. So, the question is where this code should live. My first thought was under ports/atmel-samd... but then I saw that the ESP8266 (and presumably the ESP32 and NRF) DO have the equivalent of "usb_bytes_available()" just implemented differently. So this COULD be done cross-platform (with IFDEFs). I think that means it should go under shared_bindings. Thoughts? |
Yes, please put something under shared-bindings and if it's not available, then it would throw an error that it's not implemented. Also would be done for the nrf port as well. You could use pyserial as an example of what the API might be. We added stuff to UART that mimics pyserial as well. |
Per request moved this to supervisor.runtime... This is just a simple attribute that can be tested before calling input()
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yay! Just a documentation request and then it'll be good. Thanks!
I have added the documentation as requested and pushed it to my fork - hopefully that's all that's needed (still figuring out this process) |
If there's anything else you need from me let me know asap - I'm headed to NYC for my 20th anniversary :-) |
I made one tweak to the location and will merge after travis gives the ok. |
I have added a second optional parameter to input() that acts like a timeout.
When input("PROMPT>", 10) is called with a timeout parameter, it will return in that number of milliseconds if there is no data available on the USB serial connection.
This is not a true async serial read, it's just a workaround to let allow other tasks to occur while waiting for serial input to start. Once a keystroke is read, the method drops into readline processing allowing for command history etc. And whatever activity is in the loop will stop.
However, this bridges a gap that caused problems for one of our projects. We want to be able to take serial commands over USB to change colors as well as have modes like blink, "throb", "wheel", "cycle" etc. that run between changes.
With this change, we can do that with the following code:
In our case, we used a timeout of zero, but any positive time works. Sending False is identical to sending 0. If the parameter is omitted, input() behaves exactly like the original.
An alternative approach (arguably better) would be to add a builtin function that is a passthrough to "usb_bytes_available()". I'm fine with that approach as well.
I'd love any feedback.