Re: [RFC] can: Introducing CANFD for af_can & can-raw

[Marc Kleine-Budde <mkl@pengutronix.de>]

[-- Attachment #1: Type: text/plain, Size: 2497 bytes --]

On 03/22/2012 10:24 AM, Kurt Van Dijck wrote:
> On Wed, Mar 21, 2012 at 04:05:28PM +0100, Oliver Hartkopp wrote:
>> On 21.03.2012 15:56, Wolfgang Grandegger wrote:
>>
>>> Also DLC=9 means 12 bytes, DLC=10 means 16 bytes, DLC=15 means 64 bytes.
>>> This may even change in the final spec.
>>
>> Yep!
> 
> Although the precise coding is not final yet, I'd propose to not use that coding
> in the ABI for these reasons:
> * The reason of fitting a DLC in 4 bits makes sense on the wire
>   but not on the ABI. We still use an u8!
> * Decoding & encoding between real length & DLC IMO is best done next to the
>   chips register access.

Yes - probably with a helper function.

>>>>> 3. Will these differences be visible in the CAN registers? Is this relevant?
>>>> Without hardware, it's a bit early to predict. I guess it will be visible, but
>>>> not relevant since that's driver stuff.
>>>
>>> As CANFD controllers also supports CAN2.0 frames, they must provide the
>>> the relevant information somehow, similar to EFF and SFF.
> I doubt this.
> EFF & SFF share the same bus. CANFD vs. CAN2.0 is not a per-frame thing. You
> have configured it yourself at chip initialization time...

Although I haven't seen any data sheet nor hardware I suppose you have
to configure a chip for CANFD during initialisation.

Oliver can you ask at Bosch if we can get a manual for the upcoming CAN
FD chips?

>>>> I did not get into real drivers yet...
>>>>>
>>>>> What i got from the iCC was that when you have a partly migrated network and
>>>>> you want to run e.g. a fast firmware upload between two CAN FD capable nodes,
>>>>> the other (standard CAN 2.0b) nodes have to be in listen only mode to not jam
>>>>> the bus with error frames.
>>>
>>> Due to the bit-rate switching, a assume.
>>
>>
>> Yes - the 'old' controllers would put error frames on the fast payload data.
>>
> FYI: The bitrate switch is not the only cause.
> The bitstream on the wire for 'equal' CANFD & CAN2.0 frames is different.
> A regular CAN2.0 chip will signal protocol violations.

IIRC in the data phase CANFD doesn't use the prop seg anymore and some
reserved bits in the frame are now used.

Marc

-- 
Pengutronix e.K.                  | Marc Kleine-Budde           |
Industrial Linux Solutions        | Phone: +49-231-2826-924     |
Vertretung West/Dortmund          | Fax:   +49-5121-206917-5555 |
Amtsgericht Hildesheim, HRA 2686  | http://www.pengutronix.de   |


[-- Attachment #2: OpenPGP digital signature --]
[-- Type: application/pgp-signature, Size: 262 bytes --]