[Development] New Module for Serial Buses

Rutledge Shawn Shawn.Rutledge at theqtcompany.com
Thu May 28 18:19:32 CEST 2015

On 28 May 2015, at 13:35, Marc Mutz <marc.mutz at kdab.com> wrote:

> Please don't overengineer this. If this is about CAN, call it QtCanBus. If 
> it's about i2c, call it QtI2cBus. These are separate libraries. You get the 
> idea. This is not like the web (ftp, http, ...) where there's an established 
> abstraction (URLs) and the vast majority of applications shouldn't care about 
> the actual protocol underlying a URL (thus, QNAM is ok, even though I note 
> that it loses functionality compared to QHttp, just as QHostInfo lost 
> functionality compared to QDns).
> I don't know about CAN, but taking KNX as an example I know well, you want 
> (preferably static, as opposed to type-erased) access to the KNX data formats 
> and group addresses. Yes, all the way up to QML, not just C++.
> QAbstactSocket is listed in the Wiki as a design mistake.
> Don't repeat it, please.

Back before URLs were standardized, someone could have objected that it’s too hard because Windows uses drive letters and colons and backslashes in file paths, or that network addresses are different between TCP/IP, Novell and token-ring networks, or that making a namespace for so many protocols (file, http, ftp, telnet, ssh, gopher etc.) is hopeless.  But it got done anyway, and does anybody think it was a mistake?

So I disagree that trying to make up a standardized namespace abstraction for all the buses is necessarily a futile effort.  In fact it would be surprising if nobody had tried by now.

As a result of the IoT hype, the idea of assigning a URL to a network-accessible device is inevitable.  But now we are talking about the other end of some bridge device, which translates network requests into local bus requests.

Another common abstraction on Unix-like systems is that everything is a file.  One sensor-bus project I’m familiar with is http://owfs.org which is about communicating with sensors and other devices on one-wire networks, regardless how those networks are connected.  (There are USB adapters and serial-port adapters for PCs, GPIO hacks on various embedded systems, etc.)  The name comes from the fact that it started with a FUSE daemon to make possible “mounting” the network and then accessing each sensor as a virtual file: you can read from a particular path to get the temperature from a temperature sensor, for example.  Which is pretty cool because you need nothing more than your favorite shell to interact with anything on the network.  But pretty soon the project had defined a network protocol too, and also a way of accessing the same sensors over http, which means every sensor has a URL too.  “Mounted” networks are served up by a network daemon, and remote network-accessible sensor buses can also be “mounted” locally.

A similar thing was done for the X10 and Insteon home automation powerline remote-control systems: there’s a daemon to handle virtual files for the devices.  (But X10 doesn’t have any discovery capability, so the filesystem nodes needed to be created in advance.)  At my last house I had one-wire and X10 devices available as “files” on the same Linux box, and it was possible to do some home automation with nothing more than cron jobs echoing commands to certain paths.  Reacting to button presses from remote X10 panels required a tiny bit of scripting though.

Likewise a BlueZ serial link can be pre-configured at a particular file path so that when you open the “file”, you open a link to that device.

Of course the /dev/ttyS? tradition started much earlier.  RS-232 ports just need extra out-of-band configuration for baud rate, stop bits, flow control etc., but otherwise the file abstraction holds.  The main reason we have QtSerialPort is the serial port's lack of automatic configuration, which newer buses tend to have.

So to an extent, Qt wouldn't need extra code for communicating with diverse buses, as long as this tradition of mapping things to the filesystem continues.

More information about the Development mailing list