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 the
data bus protocol.
This stack is derived from the SocketCAN implementation, already present
in the kernel and thus behaves in a very similar fashion. Thus far, we
support sending RAW ARINC-429 datagrams, configuration of the RX and TX
clock speed and filtering.
The ARINC-429 datagram is four-byte long. The first byte is always the
LABEL, the function of remaining three bytes can vary, so we handle it
as an opaque PAYLOAD. The userspace tools can send these datagrams via
a standard socket.
A LABEL-based filtering can be configured on each socket separately in
a way comparable to CAN -- user uses setsockopt() to push a list of
label,mask tuples into the kernel and the kernel will deliver a datagram
to the socket if (<received_label> & mask) == (label & mask), otherwise
the datagram is not delivered.
What's difference compared to CAN besides a different MTU? The CAN stack
is already capable to handle CAN and CAN-FD frames. Would it make sense
to integrate the ARINC-429 into the existing CAN stack?
That was my first impression too.
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 be 10 bit
including the Source/Destination Identifiers?) additionally into the can_id.
From what I can see the filtering by label is similar to filtering by can_id.
And you would be able to use the can-gw functionality too.
The only real difference is the bitrate configuration of the ARINC interface.
I wonder if a similar approach would fit here as we discussed with the
University of Prague for a LIN implementation using the PF_CAN infrastructure:
http://rtime.felk.cvut.cz/can/lin-bus/
It could probably boil down to a 'CAN interface' that is named arinc0 which
implements the serial driver like in slcan.c or sllin.c ...
Regards,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majord...@vger.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
