[HIBIKE] Hotplugging

[brandonxxlee]

Currently hibike/runtime does not support hotplugging.

[baby-bell]

This also requires some support from Dawn.

[tingtingchiang]

A place to start would be to look into dmesg, and grepping information from there since Linux itself detects if something gets plugged in.

[baby-bell]

Yeah, looks like dmesg does show when a device is detected. I am a little bit worried about chaining the implementation to linux only, though. Might just try rescanning ports periodically.

[tingtingchiang]

That's true, it would also be a lot easier to figure out. Though, are we planning on moving off of linux? I can't imagine running Mac or Windows on a BBB, unless you're just talking about during development/testing.

[bodiddles]

Considering a lot of the stack relies on us having Linux on the BBB, I think it's fine to "chain" ourselves to linux. If we were to switch the OS, there would be a lot of other refactoring that would have to be done.

[dHutchings]

I'm not so sure about a dmesg-based solution. For the robot, we'll probably be sticking with linux for the forseeable future, no matter if we're on the BBB or some other SBC.

However, specifically tying the hibike stack to dmesg (and hence, linux) will limit developer's options. Right now, hibike_process.py can forseeably run on Mac (thanks to Ivan), and run on windows with very little changes. (Namely, just changing "dev/ttyACM" to "COM"). A dmesg based solution would preclude that option, unless we figured out the mac and windows equivalent of dmesg.

On Thu, Jul 20, 2017 at 10:03 AM, bodiddles notifications@github.com wrote:

Considering a lot of the stack relies on us having Linux on the BBB, I think it's fine to "chain" ourselves to linux. If we were to switch the OS, there would be a lot of other refactoring that would have to be done.

— You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub https://github.com/pioneers/PieCentral/issues/354#issuecomment-316767937, or mute the thread https://github.com/notifications/unsubscribe-auth/ACDvxjnq5-JLO8QvlpAech3x3HeMEyoQks5sP4hegaJpZM4OPBdj .

-- Douglas Hutchings Treasurer, Pioneers in Engineering Foundation (408) 489-1041 | douglashutchings@pioneers.berkeley.edu http://pioneers.berkeley.edu

[tingtingchiang]

Makes sense, it also slipped my mind that everything is done in python/C++ (been staring at bash scripts way to long oops). dmesg works on mac, and I don't think the current code works on windows anyways. Brose's solution sounds good though, do we have an idea on how often we want to check? And how much processing power that'd take?

[dHutchings]

Well, we get to choose the rate. It is true that we're busy-waiting here, but if we do so every ~250 or ~500 ms, it shouldn't be a problem.

I think? that hibike would actually work on windows, if we added "COM*" to the code. But that's either here nor there.

On Thu, Jul 20, 2017 at 3:07 PM, tingtingchiang notifications@github.com wrote:

Makes sense, it also slipped my mind that everything is done in python/C++ (been staring at bash scripts way to long oops). dmesg works on mac, and I don't think the current code works on windows anyways. Brose's solution sounds good though, do we have an idea on how often we want to check? And how much processing power that'd take?

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pioneers/PieCentral/issues/354#issuecomment-316843721, or mute the thread https://github.com/notifications/unsubscribe-auth/ACDvxsOEgRWDfGOMSIEsBELui7Qyo7Hdks5sP8-HgaJpZM4OPBdj .

-- Douglas Hutchings Treasurer, Pioneers in Engineering Foundation (408) 489-1041 | douglashutchings@pioneers.berkeley.edu http://pioneers.berkeley.edu

[nikitakit]

You may also want to consider using the linux udev system to notify you whenever devices are plugged in (or unplugged). This has the benefit of more quickly detecting new devices: I suspect that a ~250ms polling rate will introduce a quite noticeable delay, while a faster rate may use up too much CPU resources. An event-based system like udev has the advantage that code only runs when there is actually an event to respond to.

I think it's fine for the hotplugging features to be linux-specific (it may be possible to still support other systems, just disabling the udev-based hotplugging). For example runtime only runs on Linux (and not even Mac, for some odd reason).

Links:

• http://pyudev.readthedocs.io/en/latest/api/pyudev.html#pyudev.Monitor
• https://askubuntu.com/questions/508236/how-can-i-run-code-whenever-a-usb-device-is-unplugged-without-requiring-root

[baby-bell]

I think that's an interesting idea. I'll have to see how bad the latency on polling can get; as it is now, detecting a device can take a few seconds anyways, so 250ms doesn't seem that bad.

[nikitakit]

If detecting a device really does take a few seconds, then polling shouldn't be a problem. Have you verified that this is actually the case? I was always under the impression that the kernel can detect new devices quite fast, and it was the higher-level code (such as hibike) that introduced the seconds-long delays.

[baby-bell]

I should clarify; detecting a new USB device takes very little time. Detecting whether that new device is a smart sensor takes a few seconds at most. So yes, the delay is in Hibike.

[dHutchings]

To clarify: "Detecting whether that new device is a smart sensor takes a few seconds at most." --> Do you mean using your code that detects whether a COM port contains a smart sensor via sending messages and seeing if they give correct responses?

It would be very helpful to decide on a goal here - e.g. "It takes < N seconds for a new device to be detected".

I suggest that we set 1 second as a goal.

On Sat, Jul 22, 2017 at 1:09 PM, Brose Johnstone notifications@github.com wrote:

I should clarify; detecting a new USB device takes very little time. Detecting whether that new device is a smart sensor takes a few seconds at most.

— You are receiving this because you commented. Reply to this email directly, view it on GitHub https://github.com/pioneers/PieCentral/issues/354#issuecomment-317207466, or mute the thread https://github.com/notifications/unsubscribe-auth/ACDvxqnTdAsJQJgt-H3sTC6CvAzvKmgbks5sQlbsgaJpZM4OPBdj .

-- Douglas Hutchings Treasurer, Pioneers in Engineering Foundation (408) 489-1041 | douglashutchings@pioneers.berkeley.edu http://pioneers.berkeley.edu

[baby-bell]

Yes, it is already based on a timeout, for reads and writes. See IDENTIFY_TIMEOUT in hibike_process.

On another note, there is some work being done on a polling-based system on hibike/hotplug-poll.

[baby-bell]

Has been addressed in #369