[Development] New Module for Serial Buses

Fri May 29 16:27:59 CEST 2015

Hi All,

> Actually, reading the Wikipedia entry on the CAN bus diagonally, CAN only
defines the frame format, addressing, arbitration and the physical layer.

I don't know what is in Wiki, but on real world (from the user point of
view), to communicate between the CAN devices are used the usual CAN
messages.
For example, there are some CAN adapters (USB-CAN) from the different
vendors (e.g. as PeakCAN and TinyCAN, at least).

So, usual message format is:

1) For PeakCAN:

typedef struct tagTPCANMsg
{
    DWORD             ID;      // 11/29-bit message identifier
    TPCANMessageType  MSGTYPE; // Type of the message
    BYTE              LEN;     // Data Length Code of the message (0..8)
    BYTE              DATA[8]; // Data of the message (DATA[0]..DATA[7])
} TPCANMsg;

2) For TinyCAN:

struct TCanFlagsBits
  {
  unsigned Len:4;   // Dlc
  unsigned TxD:1;   // TxD -> 1 = Tx CAN Message, 0 = Rx CAN Message
  unsigned Res:1;   // Reserviert
  unsigned RTR:1;   // remote transmition request bit
  unsigned EFF:1;   // extended frame bit
  unsigned Res2:8;
  };

union TCanFlags
  {
  struct TCanFlagsBits Flag;
  uint32_t Long;
  };

union TCanData
  {
  char Chars[8];
  unsigned char Bytes[8];
  uint16_t Words[4];
  uint32_t Longs[2];
  };

struct TTime
  {
  uint32_t Sec;
  uint32_t USec;
  };

struct TCanMsg
  {
  uint32_t Id;
  union TCanFlags Flags;
  union TCanData Data;
  struct TTime Time;
  };

So, any payload of data is in 8 bytes.. and all of input/output is carried
out by messages, but not separate bytes (as in sockets/pipes/serialport).

I don't know as how will look the CanDevice (derived from QIODevice),
because QIODevice::read/write methods has not sense. Because, what is
happens in case I want to write half (or part) of CAN message?

IMHO, this is non-trivial issue to try to unify all interfaces to
QIODevice..  :)

PS: So, can someone show a concrete implementation (set of classes) for
this new QtBus idea, e.g. for the CAN as example?

BR,
Denis

2015-05-29 14:41 GMT+03:00 Marc Mutz <marc.mutz at kdab.com>:

> 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
> _______________________________________________
> Development mailing list
> Development at qt-project.org
> http://lists.qt-project.org/mailman/listinfo/development
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/development/attachments/20150529/4ed67c2e/attachment.html>