Note that mk2-dbus already has a commandline flag to let it either keep retrying or exit, see the -e flag in the manual But for the raspberrypis it would be nice if USB connected MKx-es are also detected properly. the dedicated mk2 port is handled fine now.Either letting daemontools restart the service continuously, or, more elegant and saving a bit of CPU: adapting the vedirect-interface binary to have an option to keep retrying, instead of exiting when it does not find a connected device. those dedicated vedirect ports should be solved in a different way.Today, those VE.Direct ports are handled by serial-starter, and the MKx port is not: The CCGX and the Beaglebone-based product (named Venus GX) have a few dedicated ports: 2 x VE.Direct, and 1 x MKx (MK2/MK3/VE.Bus). Note that the dbus-redflow entry in serial starter can be ignored: it is obsolete. Which is now getting in our way: by using so much CPU it limits the amount of devices that can be connected. This is a simple but rather crude and CPU intensive solution (by design :-)). In essence it just iterates through all possible drivers, starting them one by one against all available serial-ports: a driver will exit when it does not detect a device, and also exits when it looses the connection. The plug & play implementation we have today is the famous serial-starter. There is a driver, not a kernel-driver, just a binary executable, for each different protocol, which bridges between the tty and D-Bus. The devices using those protocols can be connected to real UARTs and also via USB. Venus supports multiple different serial protocols.
0 Comments
Leave a Reply. |
AuthorWrite something about yourself. No need to be fancy, just an overview. ArchivesCategories |