Groups | Search | Server Info | Keyboard shortcuts | Login | Register [http] [https] [nntp] [nntps]

Groups > linux.kernel > #1700687

Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN fixed transceiver bindings

Show all headers | View raw

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

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

I bet your physical layer specialist understands the details way better
than I do :-)

1 value it is then.

Kind regards,
Kurt

Back to linux.kernel | Previous | Next — Previous in thread | Find similar | Unroll thread

Thread

Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN  fixed transceiver bindings Oliver Hartkopp <socketcan@hartkopp.net> - 2017-07-31 19:10 +0200
  Re: [PATCH v2 2/4] can: fixed-transceiver: Add documentation for CAN  fixed transceiver bindings Kurt Van Dijck <dev.kurt@vandijck-laurijssen.be> - 2017-08-01 09:20 +0200

csiph-web