Hi Kurt,
On 07/28/2017 09:41 PM, Kurt Van Dijck wrote:
The transceiver is an analog device that needs to support faster
switching frequency (FETs) including minimizing delay to support CAN-FD
ie higher bitrate. From the transceiver perspective the bits for
"arbitration" and "data" look exactly the same. Since it can't
differentiate between the two (at the physical layer) then the actual
limit isn't specific to which part/type of the CAN message is being
sent. Rather its just a single overall max bitrate limit.
I must disagree here.
The transceiver is an analog device that performs 2 functions:
propagate tx bits to CAN wire, and propagate CAN wire state
(dominant/recesive) to rx bits.
I'll rephrase the above explanation to fit your argument:
During arbitration, both directions are required, and needs to propagate
within 1 bit time. The transceiver doesn't know, it just performs to
best effort.
During data, the round-trip timing requirement of layer2 is relaxed.
The transceiver still doesn't know, it still performs to best effort.
Due to the relaxed round-trip timing requirement, the same transceiver
can suddenly allow higher bitrates. The transceiver didn't change, the
requirement did change.
This is what I meant earlier with "layer2 has been adapted to circumvent
layer1 limitations"
Was I successfull in transcoding my thoughts onto email :-) ?
Yes. But it's not relevant.
I talked to our CAN transceiver & CAN physical layer specialist who was
involved in the ISO activities too.
We just need ONE value: max-bitrate
The CAN transceiver is qualified to provide this bitrate. That's it.
There's nothing special with the arbitration bitrate - we don't even
need to outline any CAN FD capability.
The other things like 'loop delay compensation' are done in the CAN
controller. The better the transceiver get's the bits 'in shape' the
higher it can be qualified. But from the SoC/Controller/Linux view we
only need the max-bitrate value to double check with the CAN controllers
bitrate configuration request (which was Franklins intention).
Best regards,
Oliver
--
To unsubscribe from this list: send the line "unsubscribe devicetree" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
