On Wednesday, November 18, 2015 at 05:38:02 PM, Aleksander Morgado wrote:
> On Tue, Nov 10, 2015 at 5:15 PM, Marek Vasut wrote:
> >> >> >>> > About the parity -- can we add some flag into the datagram to
> >> >> >>> > indicate we want hardware to calculate the parity for that
> >> >> >>> > particu
On Tue, Nov 10, 2015 at 5:15 PM, Marek Vasut wrote:
>> >> >>> > About the parity -- can we add some flag into the datagram to
>> >> >>> > indicate we want hardware to calculate the parity for that
>> >> >>> > particular datagram for us? And we'd also need to indicate what
>> >> >>> > type of parit
On Wednesday, November 04, 2015 at 04:45:20 PM, Aleksander Morgado wrote:
> On Wed, Nov 4, 2015 at 4:33 PM, Marek Vasut wrote:
> > On Wednesday, November 04, 2015 at 04:19:45 PM, Aleksander Morgado wrote:
> >> On Wed, Nov 4, 2015 at 4:18 PM, Vostrikov Andrey
> >>
> >> wrote:
> >> >>> > About the
On Wed, Nov 4, 2015 at 4:33 PM, Marek Vasut wrote:
> On Wednesday, November 04, 2015 at 04:19:45 PM, Aleksander Morgado wrote:
>> On Wed, Nov 4, 2015 at 4:18 PM, Vostrikov Andrey
>>
>> wrote:
>> >>> > About the parity -- can we add some flag into the datagram to
>> >>> > indicate we want hardware
On Wednesday, November 04, 2015 at 04:19:45 PM, Aleksander Morgado wrote:
> On Wed, Nov 4, 2015 at 4:18 PM, Vostrikov Andrey
>
> wrote:
> >>> > About the parity -- can we add some flag into the datagram to
> >>> > indicate we want hardware to calculate the parity for that
> >>> > particular datag
On Wed, Nov 4, 2015 at 4:18 PM, Vostrikov Andrey
wrote:
>>> > About the parity -- can we add some flag into the datagram to indicate we
>>> > want hardware to calculate the parity for that particular datagram for
>>> > us? And we'd also need to indicate what type of parity. I dunno if this
>>> > i
Hi, Marek.
>> > About the parity -- can we add some flag into the datagram to indicate we
>> > want hardware to calculate the parity for that particular datagram for
>> > us? And we'd also need to indicate what type of parity. I dunno if this
>> > is worth the hassle.
>>
>> This is HW configurat
On Wednesday, November 04, 2015 at 04:03:16 PM, Vostrikov Andrey wrote:
> Hi, Marek.
Hi,
> > About the parity -- can we add some flag into the datagram to indicate we
> > want hardware to calculate the parity for that particular datagram for
> > us? And we'd also need to indicate what type of par
Hi, Marek.
> About the parity -- can we add some flag into the datagram to indicate we
> want hardware to calculate the parity for that particular datagram for us?
> And we'd also need to indicate what type of parity. I dunno if this is worth
> the hassle.
This is HW configuration property, it do
On Wednesday, November 04, 2015 at 10:34:50 AM, Aleksander Morgado wrote:
> On Tue, Nov 3, 2015 at 10:43 PM, Marek Vasut wrote:
> > On Tuesday, November 03, 2015 at 08:28:43 PM, Oliver Hartkopp wrote:
> >> On 11/03/2015 08:19 PM, Marek Vasut wrote:
> >> > On Tuesday, November 03, 2015 at 07:03:26
Hi Marek,
On 03.11.2015 22:41, Marek Vasut wrote:
On Tuesday, November 03, 2015 at 10:24:23 PM, Oliver Hartkopp wrote:
Comparing to typical ethernet frames with 1500 bytes the 16 bytes for CAN
frames or 72 bytes for CAN FD frames are already too small in relation to
the socket buffer overhea
On Tue, Nov 3, 2015 at 6:01 PM, Oliver Hartkopp wrote:
>> Unrelated to all this, another key point in ARINC is the timing for
>> each label when transmitting. The common case you get is different
>> labels being sent continuously with a given rate for each. E.g. labels
>> 310 and 311 every 80ms, l
On Tue, Nov 3, 2015 at 10:43 PM, Marek Vasut wrote:
> On Tuesday, November 03, 2015 at 08:28:43 PM, Oliver Hartkopp wrote:
>> On 11/03/2015 08:19 PM, Marek Vasut wrote:
>> > On Tuesday, November 03, 2015 at 07:03:26 PM, Oliver Hartkopp wrote:
>> >> On 11/03/2015 06:41 PM, Marek Vasut wrote:
>> >>>
On Tue, Nov 3, 2015 at 6:33 PM, Marek Vasut wrote:
> On Tuesday, November 03, 2015 at 05:56:53 PM, Aleksander Morgado wrote:
>> On Tue, Nov 3, 2015 at 5:18 PM, Aleksander Morgado
>>
>> wrote:
>> > On Tue, Nov 3, 2015 at 4:19 PM, Marek Vasut wrote:
>> >>> , or the duplex TX/RX setup for channels
Hi, Oliver.
> Comparing to typical ethernet frames with 1500 bytes the 16 bytes for CAN
> frames or 72 bytes for CAN FD frames are already too small in relation to the
> socket buffer overhead.
Ok, if there is no big difference using 4-bytes structure or 16-bytes
structures, I do not have any obj
On Tuesday, November 03, 2015 at 08:28:43 PM, Oliver Hartkopp wrote:
> On 11/03/2015 08:19 PM, Marek Vasut wrote:
> > On Tuesday, November 03, 2015 at 07:03:26 PM, Oliver Hartkopp wrote:
> >> On 11/03/2015 06:41 PM, Marek Vasut wrote:
> >>> On Tuesday, November 03, 2015 at 06:32:12 PM, Oliver Hartk
On Monday, November 02, 2015 at 07:16:18 PM, Marek Vasut wrote:
> On Monday, November 02, 2015 at 12:14:27 PM, Oliver Hartkopp wrote:
> > On 02.11.2015 10:47, Marc Kleine-Budde wrote:
> > > On 11/02/2015 12:16 AM, Marek Vasut wrote:
> > >> The ARINC-429 is a technical standard, which describes, amo
On Tuesday, November 03, 2015 at 10:24:23 PM, Oliver Hartkopp wrote:
> Hi Andrey,
>
> On 11/03/2015 09:26 PM, Vostrikov Andrey wrote:
> > Hi, Oliver.
> >
> >> So when thinking about using PF_CAN as ARINC429 base ...
> >>
> >> This is the CAN frame structure:
> >>
> >> https://git.kernel.org/cgi
Hi Andrey,
On 11/03/2015 09:26 PM, Vostrikov Andrey wrote:
> Hi, Oliver.
>
>> So when thinking about using PF_CAN as ARINC429 base ...
>
>> This is the CAN frame structure:
>
>> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/networking/can.txt?h=linux-4.
Hi, Oliver.
> So when thinking about using PF_CAN as ARINC429 base ...
> This is the CAN frame structure:
> https://git.kernel.org/cgit/linux/kernel/git/stable/linux-stable.git/tree/Documentation/networking/can.txt?h=linux-4.2.y#n264
> struct can_frame {
> canid_t can_id; /* 32
Hi, Marek.
> So, considering that hi3593 which as 2x RX and 1x TX port, what about
> registering one device per port and be done with it ?
Yes, that is fine. It could be easily done.
Just drop tx requests on rx channel and vice versa.
--
Best regards,
Andrey Vostrikov
--
To unsubscribe from thi
On 11/03/2015 08:19 PM, Marek Vasut wrote:
> On Tuesday, November 03, 2015 at 07:03:26 PM, Oliver Hartkopp wrote:
>> On 11/03/2015 06:41 PM, Marek Vasut wrote:
>>> On Tuesday, November 03, 2015 at 06:32:12 PM, Oliver Hartkopp wrote:
>>>
>>> [...]
>>>
It looks like you need to shift the stuff
On Tuesday, November 03, 2015 at 07:03:26 PM, Oliver Hartkopp wrote:
> On 11/03/2015 06:41 PM, Marek Vasut wrote:
> > On Tuesday, November 03, 2015 at 06:32:12 PM, Oliver Hartkopp wrote:
> >
> > [...]
> >
> >> It looks like you need to shift the stuff in user space every time.
> >>
> >> So you m
On 11/03/2015 06:41 PM, Marek Vasut wrote:
> On Tuesday, November 03, 2015 at 06:32:12 PM, Oliver Hartkopp wrote:
>
> [...]
>
>> It looks like you need to shift the stuff in user space every time.
>>
>> So you might better think of something like this:
>>
>> struct a429_frame {
>>
On Tuesday, November 03, 2015 at 06:32:12 PM, Oliver Hartkopp wrote:
[...]
> It looks like you need to shift the stuff in user space every time.
>
> So you might better think of something like this:
>
> struct a429_frame {
> __u32 label; /* ARINC 429 label */
> _
On Tuesday, November 03, 2015 at 05:56:53 PM, Aleksander Morgado wrote:
> On Tue, Nov 3, 2015 at 5:18 PM, Aleksander Morgado
>
> wrote:
> > On Tue, Nov 3, 2015 at 4:19 PM, Marek Vasut wrote:
> >>> , or the duplex TX/RX setup for channels
> >>> (channels are either RX or TX, not both), or the loc
On Tuesday, November 03, 2015 at 05:47:54 PM, Aleksander Morgado wrote:
> On Tue, Nov 3, 2015 at 4:19 PM, Marek Vasut wrote:
> >> > I was thinking about this and I mostly agree with you. Obviously,
> >> > copying the code this way was dumb. On the other hand, ARINC and
> >> > CAN are t
On 11/03/2015 05:10 PM, Aleksander Morgado wrote:
>>> or the duplex TX/RX setup for channels
>>> (channels are either RX or TX, not both), or the local
>>> echoing/loopback (which wouldn't make much sense for TX-only
>>> channels).
>>
>> Local echo/loopback comes in two flavours:
>> - Other socke
On 11/03/2015 11:36 AM, Aleksander Morgado wrote:
> Unrelated to all this, another key point in ARINC is the timing for
> each label when transmitting. The common case you get is different
> labels being sent continuously with a given rate for each. E.g. labels
> 310 and 311 every 80ms, label 312
On Tue, Nov 3, 2015 at 5:18 PM, Aleksander Morgado
wrote:
> On Tue, Nov 3, 2015 at 4:19 PM, Marek Vasut wrote:
>>> , or the duplex TX/RX setup for channels
>>> (channels are either RX or TX, not both), or the local
>>> echoing/loopback (which wouldn't make much sense for TX-only
>>> channels).
>>
On Tue, Nov 3, 2015 at 4:19 PM, Marek Vasut wrote:
>> > I was thinking about this and I mostly agree with you. Obviously,
>> > copying the code this way was dumb. On the other hand, ARINC and CAN
>> > are two different sort of busses, so I'd propose something slightly
>> > differen
On Tue, Nov 3, 2015 at 4:19 PM, Marek Vasut wrote:
>> , or the duplex TX/RX setup for channels
>> (channels are either RX or TX, not both), or the local
>> echoing/loopback (which wouldn't make much sense for TX-only
>> channels).
>
> Aren't the RX-only/TX-only channels rather a special case ?
Th
>> or the duplex TX/RX setup for channels
>> (channels are either RX or TX, not both), or the local
>> echoing/loopback (which wouldn't make much sense for TX-only
>> channels).
>
> Local echo/loopback comes in two flavours:
> - Other socket receive local generate frames, too.
> This is interesti
On Tuesday, November 03, 2015 at 04:06:05 PM, Aleksander Morgado wrote:
> On Tue, Nov 3, 2015 at 12:36 PM, Marc Kleine-Budde
> wrote:
> > On 11/03/2015 11:36 AM, Aleksander Morgado wrote:
> >> On Mon, Nov 2, 2015 at 9:25 PM, Marek Vasut wrote:
> > I was thinking about this and I mostly agree
On 11/03/2015 04:06 PM, Aleksander Morgado wrote:
>> What about maintainability? Why take care of two almost identical
>> subsystems? With making one stack "simpler" you increase, from my point
>> of view, the costs of maintaining even more. If you fix problems in one
>> stack you have to adopt the
On Tue, Nov 3, 2015 at 12:36 PM, Marc Kleine-Budde wrote:
> On 11/03/2015 11:36 AM, Aleksander Morgado wrote:
>> On Mon, Nov 2, 2015 at 9:25 PM, Marek Vasut wrote:
> I was thinking about this and I mostly agree with you. Obviously, copying
> the code this way was dumb. On the other hand,
On 11/03/2015 11:36 AM, Aleksander Morgado wrote:
> On Mon, Nov 2, 2015 at 9:25 PM, Marek Vasut wrote:
I was thinking about this and I mostly agree with you. Obviously, copying
the code this way was dumb. On the other hand, ARINC and CAN are two
different sort of busses, so I'd prop
Hey!
On Mon, Nov 2, 2015 at 9:25 PM, Marek Vasut wrote:
>> > I was thinking about this and I mostly agree with you. Obviously, copying
>> > the code this way was dumb. On the other hand, ARINC and CAN are two
>> > different sort of busses, so I'd propose something slightly different
>> > here to
On Monday, November 02, 2015 at 09:15:21 PM, Vostrikov Andrey wrote:
> Hi,
Hi,
> > I was thinking about this and I mostly agree with you. Obviously, copying
> > the code this way was dumb. On the other hand, ARINC and CAN are two
> > different sort of busses, so I'd propose something slightly dif
Hi,
> I was thinking about this and I mostly agree with you. Obviously, copying the
> code this way was dumb. On the other hand, ARINC and CAN are two different
> sort
> of busses, so I'd propose something slightly different here to avoid confusion
> and prevent the future extensions (or protocol
On Monday, November 02, 2015 at 12:14:27 PM, Oliver Hartkopp wrote:
> On 02.11.2015 10:47, Marc Kleine-Budde wrote:
> > On 11/02/2015 12:16 AM, Marek Vasut wrote:
> >> The ARINC-429 is a technical standard, which describes, among others,
> >> a data bus used by airplanes. The standard contains much
On 11/02/2015 08:41 PM, Aleksander Morgado wrote:
> On Mon, Nov 2, 2015 at 12:14 PM, Oliver Hartkopp
> wrote:
>>
>> What about defining some overlay data structure to map ARINC-429 frames into
>> CAN frames?
>>
>> E.g. we could write the ARINC 32 bit data completely into data[0..3] and
>> additio
On Mon, Nov 2, 2015 at 12:14 PM, Oliver Hartkopp wrote:
>
> What about defining some overlay data structure to map ARINC-429 frames into
> CAN frames?
>
> E.g. we could write the ARINC 32 bit data completely into data[0..3] and
> additionally copy the 8 bit label information (or should it better b
On 02.11.2015 10:47, Marc Kleine-Budde wrote:
On 11/02/2015 12:16 AM, Marek Vasut wrote:
The ARINC-429 is a technical standard, which describes, among others,
a data bus used by airplanes. The standard contains much more, since
it is based off the ISO/OSI model, but this patch implements just th
On 11/02/2015 12:16 AM, Marek Vasut wrote:
> The ARINC-429 is a technical standard, which describes, among others,
> a data bus used by airplanes. The standard contains much more, since
> it is based off the ISO/OSI model, but this patch implements just the
> data bus protocol.
>
> This stack is d
The ARINC-429 is a technical standard, which describes, among others,
a data bus used by airplanes. The standard contains much more, since
it is based off the ISO/OSI model, but this patch implements just the
data bus protocol.
This stack is derived from the SocketCAN implementation, already prese
46 matches
Mail list logo
