[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <5638EF9C.9070503@hartkopp.net>
Date: Tue, 03 Nov 2015 18:32:12 +0100
From: Oliver Hartkopp <socketcan@...tkopp.net>
To: Aleksander Morgado <aleksander@...ksander.es>,
Marc Kleine-Budde <mkl@...gutronix.de>
CC: Marek Vasut <marex@...x.de>,
Vostrikov Andrey <andrey.vostrikov@...entembedded.com>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
"David S. Miller" <davem@...emloft.net>,
Wolfgang Grandegger <wg@...ndegger.com>,
Andrew Lunn <andrew@...n.ch>
Subject: Re: [RFC][PATCH] net: arinc429: Add ARINC-429 stack
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
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists