[Development] New Module for Serial Buses

[Marc Mutz]

On Thursday 28 May 2015 18:19:32 Rutledge Shawn wrote:
> 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.

Actually, reading the Wikipedia entry on the CAN bus diagonally, CAN only 
defines the frame format, addressing, arbitration and the physical layer. It 
doesn't specify any protocol for the payload. That would speak for a design as 
proposed, but is that really what users expect when they hear about a CAN 
implementation for Qt? Parsing the frame into address and payload and a few 
flags? And doing so though a plugin / virtual functions, so it ends up 100x 
slower than a direct CAN frame parser? Do we need a QSerialBusAddress instead 
of a QCanAddress?

But ok, KNX was probably a bad comparision, because it not only defines the 
access method (three of them: over TP, RF, and IP), but a rich protocol with 
typed data, structured addresses, and multiple communication objects per 
device. If CAN doesn't have something like that, then by all means, fit it in 
with QtSerialPort.

I guess I was expecting something higher-level... :)

Thanks,
Marc

-- 
Marc Mutz <marc.mutz at kdab.com> | Senior Software Engineer
KDAB (Deutschland) GmbH & Co.KG, a KDAB Group Company
Tel: +49-30-521325470
KDAB - The Qt Experts