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
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
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
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
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
