Adding support for ARINC429 into the Linux kernel

Adding support for ARINC429 into the Linux kernel

[Guenter Roeck]

Hi all,

I have been asked to explore options for adding ARINC 429 support [1]
into the Linux kernel, primarily to support devices from Holt Integrated
Circuits [2] (the request is unrelated to the chip manufacturer).

ARINC429 is a protocol which is widely used in commercial airplanes. 

There are various chips supporting this protocol available, as well as
out-of-tree Linux support. The drivers I have looked at implement it
either as character device or misc device and typically pass raw receive
data to userspace.

I can see a number of options for going forward:
1) Implement as character device (or possibly misc device) and pass
   raw data to/from user space
   1a) Just implement a driver for the specific chips
   2b) Implement some kind of generic infrastructure
2) Implement as network driver with a new address family, similar to,
   say, AF_CAN.

Any thoughts / suggestions which approach would be better and, most of all,
which approach might have a better chance of being accepted upstream ?

Thanks,
Guenter

--
[1] http://en.wikipedia.org/wiki/ARINC_429
[2] http://www.holtic.com/category/352-arinc-429.aspx

Re: Adding support for ARINC429 into the Linux kernel

[Arnd Bergmann]

On Wednesday 19 June 2013, Guenter Roeck wrote:
> I have been asked to explore options for adding ARINC 429 support [1]
> into the Linux kernel, primarily to support devices from Holt Integrated
> Circuits [2] (the request is unrelated to the chip manufacturer).
> 
> ARINC429 is a protocol which is widely used in commercial airplanes. 
> 
> There are various chips supporting this protocol available, as well as
> out-of-tree Linux support. The drivers I have looked at implement it
> either as character device or misc device and typically pass raw receive
> data to userspace.
> 
> I can see a number of options for going forward:
> 1) Implement as character device (or possibly misc device) and pass
>    raw data to/from user space
>    1a) Just implement a driver for the specific chips
>    2b) Implement some kind of generic infrastructure
> 2) Implement as network driver with a new address family, similar to,
>    say, AF_CAN.
> 
> Any thoughts / suggestions which approach would be better and, most of all,
> which approach might have a better chance of being accepted upstream ?

Since this is a standard protocol, a driver that just supports a specific
chip (1a) would be the worst option IMHO.

A character device and a network protocol both sound reasonable, but
it really depends on the use cases:

* Does Linux act both as the sender and receiver, or do you want to
  support just one of the cases (which?)?

* Would you expect to always just transfer a single 32-bit word, or
  are there larger chunks of logically contigous data? What are typical
  and maximum sizes for those?

* Would you expect the kernel to filter for specific data on the
  receiver side?

* Would a user space receiver want to always see all data from one
  sender, or only the latest word?

	Arnd

Re: Adding support for ARINC429 into the Linux kernel

[Guenter Roeck]

On Wed, Jun 19, 2013 at 11:45:30PM +0200, Arnd Bergmann wrote:
> On Wednesday 19 June 2013, Guenter Roeck wrote:
> > I have been asked to explore options for adding ARINC 429 support [1]
> > into the Linux kernel, primarily to support devices from Holt Integrated
> > Circuits [2] (the request is unrelated to the chip manufacturer).
> > 
> > ARINC429 is a protocol which is widely used in commercial airplanes. 
> > 
> > There are various chips supporting this protocol available, as well as
> > out-of-tree Linux support. The drivers I have looked at implement it
> > either as character device or misc device and typically pass raw receive
> > data to userspace.
> > 
> > I can see a number of options for going forward:
> > 1) Implement as character device (or possibly misc device) and pass
> >    raw data to/from user space
> >    1a) Just implement a driver for the specific chips
> >    2b) Implement some kind of generic infrastructure
> > 2) Implement as network driver with a new address family, similar to,
> >    say, AF_CAN.
> > 
> > Any thoughts / suggestions which approach would be better and, most of all,
> > which approach might have a better chance of being accepted upstream ?
> 
> Since this is a standard protocol, a driver that just supports a specific
> chip (1a) would be the worst option IMHO.
> 
It would not be optimal, but straightforward and easy to implement.

> A character device and a network protocol both sound reasonable, but
> it really depends on the use cases:
> 
> * Does Linux act both as the sender and receiver, or do you want to
>   support just one of the cases (which?)?
> 
Both, depending on the use case. Some of those are

1) ACARS -
   http://en.wikipedia.org/wiki/Aircraft_Communications_Addressing_and_Reporting_System
   Rx and tx

2) CIDS - Cabin Intercommunication Data System
   Rx and tx

3) IRS (Inertial Reference System) and FMS (Flight Management System)
   Rx only

> * Would you expect to always just transfer a single 32-bit word, or
>   are there larger chunks of logically contigous data? What are typical
>   and maximum sizes for those?
> 
The raw protocol is chunks of 32 bit (Logical Data Unit, or LDU), which
the protocol refers to as 'physical layer'. Broadcast messages such as
those from IRS and FMS use this format.

There is also bit-oriented data. The two protocols I am aware of are "Bit-
Oriented File Transfer Protocol", and "Bit-Oriented Media Access Control
(MAC) Protocol", which is supposed to be IEEE 802 compliant. Packet size
is 3 to 255 LDUs for FTP and 3 to 1023 LDUs for the MAC protocol.
Both include a SOF and EOF marker, so the actual data size would be 1-253
or 1-1021 LDUs. Each LDU carries 20 bit, and partial words are possible
in 4-bit increments, which means the data transfer size is 4 to 20,420 bit
(2,552.5 bytes) for the MAC protocol, and 4 to 5,060 bit (632.5 bytes)
for FTP.

Bit-oriented data is commonly used for ACARS and CIDS, where bi-directional
communication is used.

Details are available in Specification ARINC-429P3-19-2009, sections 2.5 and 3.0.
You should be able to find it on the web if you are interested.

> * Would you expect the kernel to filter for specific data on the
>   receiver side?
> 
Each LDU has an 8-bit label. Applications listen for specific sets of labels.
The chips have a configurable hardware filter; if there are not enough hardware
filters, the kernel would have to do the filtering. Either case, the kernel
has to select protocol receivers (sockets or open file descriptors) based
on bind/registration information. For example, one aplication may register
for label 1,3,5, and 7, and another for labels 1, 3, 12, and 14. So there can
be overlaps.

> * Would a user space receiver want to always see all data from one
>   sender, or only the latest word?
> 
The receiver would want to receive all data for the labels it has registered
for.

Hope this helps. Note that, at least as first step, I only envision to handle
4-byte units and pass those to/from user-space. Implementing the two link layer
protocols would probably make sense, especially with the socket interface,
but that would be a second step.

Thanks,
Guenter

Re: Adding support for ARINC429 into the Linux kernel

[Arnd Bergmann]

On Thursday 20 June 2013, Guenter Roeck wrote:
> On Wed, Jun 19, 2013 at 11:45:30PM +0200, Arnd Bergmann wrote:
> > On Wednesday 19 June 2013, Guenter Roeck wrote:
> > 
> > Since this is a standard protocol, a driver that just supports a specific
> > chip (1a) would be the worst option IMHO.
> > 
> It would not be optimal, but straightforward and easy to implement.

The most important aspect would be the user interface: We should not
merge a driver that implements a character device (or something else)
in a way that would not be compatible with a general subsystem. I think
designing a generic interface is the hard part here, much more so than
implementing an abstraction layer.

> > A character device and a network protocol both sound reasonable, but
> > it really depends on the use cases:
> > 
> > * Does Linux act both as the sender and receiver, or do you want to
> >   support just one of the cases (which?)?
> > 
> Both, depending on the use case. Some of those are
> 
> 1) ACARS -
>    http://en.wikipedia.org/wiki/Aircraft_Communications_Addressing_and_Reporting_System
>    Rx and tx
> 
> 2) CIDS - Cabin Intercommunication Data System
>    Rx and tx
> 
> 3) IRS (Inertial Reference System) and FMS (Flight Management System)
>    Rx only

Ok, I see.

> > * Would you expect to always just transfer a single 32-bit word, or
> >   are there larger chunks of logically contigous data? What are typical
> >   and maximum sizes for those?
> > 
> The raw protocol is chunks of 32 bit (Logical Data Unit, or LDU), which
> the protocol refers to as 'physical layer'. Broadcast messages such as
> those from IRS and FMS use this format.
> 
> There is also bit-oriented data. The two protocols I am aware of are "Bit-
> Oriented File Transfer Protocol", and "Bit-Oriented Media Access Control
> (MAC) Protocol", which is supposed to be IEEE 802 compliant. Packet size
> is 3 to 255 LDUs for FTP and 3 to 1023 LDUs for the MAC protocol.
> Both include a SOF and EOF marker, so the actual data size would be 1-253
> or 1-1021 LDUs. Each LDU carries 20 bit, and partial words are possible
> in 4-bit increments, which means the data transfer size is 4 to 20,420 bit
> (2,552.5 bytes) for the MAC protocol, and 4 to 5,060 bit (632.5 bytes)
> for FTP.
> 
> Bit-oriented data is commonly used for ACARS and CIDS, where bi-directional
> communication is used.
> 
> Details are available in Specification ARINC-429P3-19-2009, sections 2.5 and 3.0.
> You should be able to find it on the web if you are interested.

Ok, this sounds like it would make a network type interface more
practical, at least for the 802 specific parts.

> > * Would you expect the kernel to filter for specific data on the
> >   receiver side?
> > 
> Each LDU has an 8-bit label. Applications listen for specific sets of labels.
> The chips have a configurable hardware filter; if there are not enough hardware
> filters, the kernel would have to do the filtering. Either case, the kernel
> has to select protocol receivers (sockets or open file descriptors) based
> on bind/registration information. For example, one aplication may register
> for label 1,3,5, and 7, and another for labels 1, 3, 12, and 14. So there can
> be overlaps.

Ok

> > * Would a user space receiver want to always see all data from one
> >   sender, or only the latest word?
> > 
> The receiver would want to receive all data for the labels it has registered
> for.
> 
> Hope this helps. Note that, at least as first step, I only envision to handle
> 4-byte units and pass those to/from user-space. Implementing the two link layer
> protocols would probably make sense, especially with the socket interface,
> but that would be a second step.

My vote would be for a new socket family for the low-level protocol,
with room for extension later to support the advanced features.

This should be one of the simplest socket implementations possible, if
you just need to send and receive 32 bit words, and can bind to a
a set of labels for rx as you described above.

The only possible concern I see with that interface is slightly higher
latency than what you would be able to get with a straight read/write
based character device.

	Arnd

Re: Adding support for ARINC429 into the Linux kernel

[Guenter Roeck]

On Thu, Jun 20, 2013 at 10:52:53AM +0200, Arnd Bergmann wrote:
> On Thursday 20 June 2013, Guenter Roeck wrote:
> > On Wed, Jun 19, 2013 at 11:45:30PM +0200, Arnd Bergmann wrote:
> > > On Wednesday 19 June 2013, Guenter Roeck wrote:
> > > 
> > > Since this is a standard protocol, a driver that just supports a specific
> > > chip (1a) would be the worst option IMHO.
> > > 
> > It would not be optimal, but straightforward and easy to implement.
> 
> The most important aspect would be the user interface: We should not
> merge a driver that implements a character device (or something else)
> in a way that would not be compatible with a general subsystem. I think
> designing a generic interface is the hard part here, much more so than
> implementing an abstraction layer.
> 
> > > A character device and a network protocol both sound reasonable, but
> > > it really depends on the use cases:
> > > 
> > > * Does Linux act both as the sender and receiver, or do you want to
> > >   support just one of the cases (which?)?
> > > 
> > Both, depending on the use case. Some of those are
> > 
> > 1) ACARS -
> >    http://en.wikipedia.org/wiki/Aircraft_Communications_Addressing_and_Reporting_System
> >    Rx and tx
> > 
> > 2) CIDS - Cabin Intercommunication Data System
> >    Rx and tx
> > 
> > 3) IRS (Inertial Reference System) and FMS (Flight Management System)
> >    Rx only
> 
> Ok, I see.
> 
> > > * Would you expect to always just transfer a single 32-bit word, or
> > >   are there larger chunks of logically contigous data? What are typical
> > >   and maximum sizes for those?
> > > 
> > The raw protocol is chunks of 32 bit (Logical Data Unit, or LDU), which
> > the protocol refers to as 'physical layer'. Broadcast messages such as
> > those from IRS and FMS use this format.
> > 
> > There is also bit-oriented data. The two protocols I am aware of are "Bit-
> > Oriented File Transfer Protocol", and "Bit-Oriented Media Access Control
> > (MAC) Protocol", which is supposed to be IEEE 802 compliant. Packet size
> > is 3 to 255 LDUs for FTP and 3 to 1023 LDUs for the MAC protocol.
> > Both include a SOF and EOF marker, so the actual data size would be 1-253
> > or 1-1021 LDUs. Each LDU carries 20 bit, and partial words are possible
> > in 4-bit increments, which means the data transfer size is 4 to 20,420 bit
> > (2,552.5 bytes) for the MAC protocol, and 4 to 5,060 bit (632.5 bytes)
> > for FTP.
> > 
> > Bit-oriented data is commonly used for ACARS and CIDS, where bi-directional
> > communication is used.
> > 
> > Details are available in Specification ARINC-429P3-19-2009, sections 2.5 and 3.0.
> > You should be able to find it on the web if you are interested.
> 
> Ok, this sounds like it would make a network type interface more
> practical, at least for the 802 specific parts.
> 
> > > * Would you expect the kernel to filter for specific data on the
> > >   receiver side?
> > > 
> > Each LDU has an 8-bit label. Applications listen for specific sets of labels.
> > The chips have a configurable hardware filter; if there are not enough hardware
> > filters, the kernel would have to do the filtering. Either case, the kernel
> > has to select protocol receivers (sockets or open file descriptors) based
> > on bind/registration information. For example, one aplication may register
> > for label 1,3,5, and 7, and another for labels 1, 3, 12, and 14. So there can
> > be overlaps.
> 
> Ok
> 
> > > * Would a user space receiver want to always see all data from one
> > >   sender, or only the latest word?
> > > 
> > The receiver would want to receive all data for the labels it has registered
> > for.
> > 
> > Hope this helps. Note that, at least as first step, I only envision to handle
> > 4-byte units and pass those to/from user-space. Implementing the two link layer
> > protocols would probably make sense, especially with the socket interface,
> > but that would be a second step.
> 
> My vote would be for a new socket family for the low-level protocol,
> with room for extension later to support the advanced features.
> 
> This should be one of the simplest socket implementations possible, if
> you just need to send and receive 32 bit words, and can bind to a
> a set of labels for rx as you described above.
> 
> The only possible concern I see with that interface is slightly higher
> latency than what you would be able to get with a straight read/write
> based character device.
> 
Any further feedback on this ?

Key question: Would a new address family have a chance of being accepted ?

Guenter

Re: Adding support for ARINC429 into the Linux kernel

[Pavel Machek]

Hi!

> > My vote would be for a new socket family for the low-level protocol,
> > with room for extension later to support the advanced features.
> > 
> > This should be one of the simplest socket implementations possible, if
> > you just need to send and receive 32 bit words, and can bind to a
> > a set of labels for rx as you described above.
> > 
> > The only possible concern I see with that interface is slightly higher
> > latency than what you would be able to get with a straight read/write
> > based character device.
> > 
> Any further feedback on this ?
> 
> Key question: Would a new address family have a chance of being accepted ?

Yes... that seems like cleanest way to implement it.

									Pavel
-- 
(english) http://www.livejournal.com/~pavelmachek
(cesky, pictures) http://atrey.karlin.mff.cuni.cz/~pavel/picture/horses/blog.html