Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack

[Oliver Hartkopp <socketcan@hartkopp.net>]

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 socket receive local generate frames, too.
>>   This is interesting if you want to merge two ARINC node on single
>>   device.
> 
> I'd actually love having this for a simulator setup I use where I
> currently physically connect cables from a TX channel in one adapter
> to a RX channel in another adapter. But I'm not sure there's a
> specific real usecase for that apart from testing purposes.

Once you have ever used this functionalities you will start to think beyond.

It's a matter of (stress-)testing your applications after build on virtual
CAN/ARINC interfaces. You will start to use the can-gw to route and/or modify
frames between interfaces. You have all the tools to display/log/visualize and
replay data. There's a wireshark plugin for PF_CAN you can easily adapt to
present ARINC data, etc.

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 bit CAN_ID + EFF/RTR/ERR flags */
            __u8    can_dlc; /* frame payload length in byte (0 .. 8) */
            __u8    __pad;   /* padding */
            __u8    __res0;  /* reserved / padding */
            __u8    __res1;  /* reserved / padding */
            __u8    data[8] __attribute__((aligned(8)));
    };


So what about defining an arinc429_frame like this:

    struct a429_frame {
            __u32   label;   /* ARINC 429 label */
            __u8    length;  /* always set to 3 */
            __u8    __pad;   /* padding */
            __u8    __res0;  /* reserved / padding */
            __u8    __res1;  /* reserved / padding */
            __u8    data[8] __attribute__((aligned(8)));
    };

Don't know if your suggestion

+ * ARINC packet:
+ *
+ * .-.---.------.---.-----.
+ * |P|SSM| Data |SDI|Label|
+ * '-'---'------'---'-----'
+ *  3 3 2 2....1 1 9 8...0
+ *  1 0 9 8    1 0
+ */
+
+/**
+ * struct arinc429_frame - basic ARINC429 frame structure
+ * @label:	ARINC429 label
+ * @data:	ARINC429 P, SSM, DATA and SDI
+ */
+struct arinc429_frame {
+	__u8	label;		/* 8 bit label */
+	__u8	data[3];	/* Up-to 23 bits are valid. */
+};

is really handy to use for arinc application programmers.

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 */
            __u8    length;  /* always set to 8 */
            __u8    __pad;   /* padding */
            __u8    __res0;  /* reserved / padding */
            __u8    __res1;  /* reserved / padding */
            __u32   data __attribute__((aligned(8)));
            __u8    p;       /* p */
            __u8    ssm;     /* ssm */
            __u8    sdi;     /* sdi */
            __u8    __end;   /* padding */
    };

Good thing would be that you can directly see the content in logfiles and you
can easily modify the content on the fly by can-gw.

Of course the arinc netdevice driver would have to take care to do the correct
rx/tx whatever. But routing and processing arinc content through the CAN stack
does not seem to be a bad idea IMO.

Regards,
Oliver