On Tuesday 26 May 2015 13:33:59 Viironen Kalle wrote:
> Hi,
>
> We’d like to create a new Qt module for serial buses. At first stage this
> generic extendable module would include support for CAN-bus, but
> architecture should be such that supporting also other generally used
> serial buses like F
; > Viironen Kalle
> > Sent: 1. kesäkuuta 2015 12:46
> > To: development@qt-project.org
> > Subject: Re: [Development] New Module for Serial Buses
> >
> > Since there actually was no objections towards creating a new module for
> > serial buses I propose that
ect.org
> Subject: Re: [Development] New Module for Serial Buses
>
> Since there actually was no objections towards creating a new module for
> serial buses I propose that we’ll just go ahead and create a new Qt Serial Bus
> module and then continue discussion around first commits. Wo
Since there actually was no objections towards creating a new module for
serial buses I propose that we’ll just go ahead and create a new Qt Serial
Bus module and then continue discussion around first commits. Would this
be acceptable approach? I believe that getting actual code for the basis
of di
>
> QAbstactSocket is listed in the Wiki as a design mistake.
>
> Don't repeat it, please.
Also using Qt's event system for such low-level byte swinging is a bad choice:
https://codereview.qt-project.org/#/c/75708/
Peter
___
Development mailing list
On Friday 29 May 2015 16:27:59 Denis Shienkov wrote:
> 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
On Friday 29 May 2015 13:19:36 Al-Khanji Louai wrote:
> > I guess I was expecting something higher-level... :)
>
> One step at a time. :)
I'm all for it, but I think one should *first* implement the buses/protocols
before trying to put an abstraction on it. The latter requires insight that
only
On 05/29/2015 04:27 PM, Denis Shienkov wrote:
>
> 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::r
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 CA
I wonder if you also need hot-plug detection?
> On 29 May 2015, at 11:43, Viironen Kalle
> wrote:
>
>
>
> On 28/05/15 09:22, "Knoll Lars" wrote:
>
>> On 26/05/15 20:14, "Thiago Macieira" wrote:
>>
>>> On Tuesday 26 May 2015 17:40:05 Viironen Kalle wrote:
On 26/05/15 19:42, "Thiago Ma
> I guess I was expecting something higher-level... :)
One step at a time. :)
Louai
___
Development mailing list
Development@qt-project.org
http://lists.qt-project.org/mailman/listinfo/development
On Thursday 28 May 2015 18:19:32 Rutledge Shawn wrote:
> On 28 May 2015, at 13:35, Marc Mutz 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
On 28/05/15 09:22, "Knoll Lars" wrote:
>On 26/05/15 20:14, "Thiago Macieira" wrote:
>
>>On Tuesday 26 May 2015 17:40:05 Viironen Kalle wrote:
>>> On 26/05/15 19:42, "Thiago Macieira" wrote:
>>>
>>>
>>> >On Tuesday 26 May 2015 15:19:26 Hausmann Simon wrote:
>>> >
>>> >>Good point :)
>>> >>I
Am 28.05.15 um 18:19 schrieb Rutledge Shawn:
> On 28 May 2015, at 13:35, Marc Mutz 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,
> On 28 May 2015, at 18:16, Frederik Gladhorn
> wrote:
>
>> On Thursday, May 28, 2015 01:35:17 PM Marc Mutz wrote:
>>> On Tuesday 26 May 2015 15:33:59 Viironen Kalle wrote:
>>> For naming we have thought either QtBus or QtSerialBus. IMO name as such
>>> should already on it’s own describe the g
On 28 May 2015, at 13:35, Marc Mutz 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 (U
On Thursday, May 28, 2015 01:35:17 PM Marc Mutz wrote:
> On Tuesday 26 May 2015 15:33:59 Viironen Kalle wrote:
> > For naming we have thought either QtBus or QtSerialBus. IMO name as such
> > should already on it’s own describe the generalised idea of the module.
>
> What use-case do you have in m
On Tuesday 26 May 2015 15:33:59 Viironen Kalle wrote:
> For naming we have thought either QtBus or QtSerialBus. IMO name as such
> should already on it’s own describe the generalised idea of the module.
What use-case do you have in mind where the programmer doesn't know that he's
talking to a CAN
On 27/05/15 03:04, Thiago Macieira wrote:
> On Tuesday 26 May 2015 15:47:04 Simon Hausmann wrote:
>> My first suggestion is to give the module a better name. "Bus" is an
>> overloaded term with many meanings and it is IMO too close to our "DBus"
>> module. Why not go with what your first sentence i
On 26/05/15 20:14, "Thiago Macieira" wrote:
>On Tuesday 26 May 2015 17:40:05 Viironen Kalle wrote:
>> On 26/05/15 19:42, "Thiago Macieira" wrote:
>>
>>
>> >On Tuesday 26 May 2015 15:19:26 Hausmann Simon wrote:
>> >
>> >>Good point :)
>> >>I was under the assumption that the concepts are too di
On Tuesday 26 May 2015 17:40:05 Viironen Kalle wrote:
> On 26/05/15 19:42, "Thiago Macieira" wrote:
>
>
> >On Tuesday 26 May 2015 15:19:26 Hausmann Simon wrote:
> >
> >>Good point :)
> >>I was under the assumption that the concepts are too different, but if
> >>they
> >>aren't then maybe a joint
On 26/05/15 19:42, "Thiago Macieira" wrote:
>On Tuesday 26 May 2015 15:19:26 Hausmann Simon wrote:
>>Good point :)
>>I was under the assumption that the concepts are too different, but if
>>they
>>aren't then maybe a joint module would make sense.
>
>At the very least it's a superset and QtSeri
On Tuesday 26 May 2015 15:19:26 Hausmann Simon wrote:
> Good point :)
>
> I was under the assumption that the concepts are too different, but if they
> aren't then maybe a joint module would make sense.
At the very least it's a superset and QtSerialPort (the library) should be
moved into the new
Good point :)
I was under the assumption that the concepts are too different, but if they
aren't then maybe a joint module would make sense.
Simon
Original Message
From: Thiago Macieira
Sent: Tuesday, May 26, 2015 17:06
To: development@qt-project.org
Subject: Re: [Development] New Modul
On Tuesday 26 May 2015 15:47:04 Simon Hausmann wrote:
> My first suggestion is to give the module a better name. "Bus" is an
> overloaded term with many meanings and it is IMO too close to our "DBus"
> module. Why not go with what your first sentence in the email used:
>
> "We’d like to create
On Tuesday, May 26, 2015 01:33:59 PM Viironen Kalle wrote:
> Hi,
>
> We’d like to create a new Qt module for serial buses. At first stage this
> generic extendable module would include support for CAN-bus, but
> architecture should be such that supporting also other generally used
> serial buses l
26 matches
Mail list logo
