-
Notifications
You must be signed in to change notification settings - Fork 8
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
[linux_serial] unclear timeout behaviour #30
Comments
That's a bug. It should be both 0 like in
That makes sense. This package is mostly designed to handle as much as possible in dart rather than in the kernel, i.e. buffering is done in dart rather than the kernel (data from the serial port is read as soon as it's available and put into dart buffers / streams), so not sure how easy it is to integrate with the current API. |
I want to look into this again as soon as I find the time for it, not before next year unfortunately. Regarding "not sure how easy it is to integrate": With the current architecture, I would probably put a timeout on the streams, this function here: https://api.flutter.dev/flutter/dart-async/Stream/timeout.html. What do you think about the general idea, is it worth to proceed with it or do you have reservations about the approach? |
That works yeah. The difference between that and in-kernel timeout is that the dart-side timeout is not as reliable of course, i.e. when there's a lot of work for the dart vm (hot reloading, hot restarting), could be it just takes a long time to get to handling the serial port data, and it times out before it gets there. I'm doing a similar thing with linux_can, and after a hot restart it regularly takes like 10s till the CAN frame is seen by the main dart isolate, after it was received by the kernel. So if you really need reliable timeouts, using the in-kernel timeouts is better. But if you don't, |
I have a usecase where I need to communicate with devices to identify them, and I can't rule out that sometimes a device doesn't give me replies at all. This is where the timeout behaviour of the serial port becomes important, in order to not loose time and get performant behaviour.
So I tried to find out how this library behaves regarding timeouts.
In
makeRaw
you are setting:In
makeRawAndSetBaudrate
you are setting:According to https://man7.org/linux/man-pages/man3/termios.3.html -> noncanonical mode, the first case means polling read (give back what is available) while the second case means to block until the first character was received and then to have 10 seconds (unit is tenth's of seconds) timeout between characters. The second case is used as soon as a baudrate has been configured.
I'd like to understand the reasoning behind these settings - what did you have in mind here? Would you consider adding a configurable timeout to this library, or would you at least accept a PR that implements such a feature?
The text was updated successfully, but these errors were encountered: