bit-timing and sample point

bit-timing and sample point

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 2215 bytes --]

Hello,

currently I'm reworking the bit timing algorithm. I've changed the
algorithm to minimize first the bit rate error and then the sample point
error within the best bit rate.

The old algorithm always picks a sample point less than the target
sample point. My question to the CAN exports: Is it better to stay below
the sample point or minimize the error (and pick a sample point slightly
above the nominal sample point)?

See the below table for the output of the calculation. There are three
entries per bit rate:
1) original algorithm
2) improved algorithm, smaple point is always below nominal sample point
3) improved algorithm, sample point error is minimized

> Bit timing parameters for mscan with 66.666666 MHz ref clock
> nominal                                 real Bitrt   nom  real SampP
> Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error BTR0 BTR1
> 1000000     90   3    4    3   1   6 1010101  1.0% 75.0% 72.7%  3.1% 0x05 0x26
> 1000000     90   3    4    3   1   6 1010101  1.0% 75.0% 72.7%  3.1% 0x05 0x26
> 1000000     45   8    8    5   1   3 1010101  1.0% 75.0% 77.2%  2.9% 0x02 0x4f

>  800000    180   2    2    2   1  12  793650  0.8% 80.0% 71.4% 10.8% 0x0b 0x13
>  800000     90   5    5    3   1   6  793650  0.8% 80.0% 78.5%  1.9% 0x05 0x29
>  800000     60   8    8    4   1   4  793650  0.8% 80.0% 80.9%  1.1% 0x03 0x3f

>  500000    285   2    2    2   1  19  501253  0.3% 87.5% 71.4% 18.4% 0x12 0x13
>  500000    105   7    8    3   1   7  501253  0.3% 87.5% 84.2%  3.8% 0x06 0x2e
>  500000    105   8    8    2   1   7  501253  0.3% 87.5% 89.4%  2.2% 0x06 0x1f

>  250000    570   2    2    2   1  38  250626  0.3% 87.5% 71.4% 18.4% 0x25 0x13
>  250000    285   5    6    2   1  19  250626  0.3% 87.5% 85.7%  2.1% 0x12 0x1a
>  250000    285   5    6    2   1  19  250626  0.3% 87.5% 85.7%  2.1% 0x12 0x1a

Which algorithm is preferred?

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: 455 bytes --]

Re: bit-timing and sample point

[Kurt Van Dijck]

Hey Marc,

> currently I'm reworking the bit timing algorithm.
Waauw, that's ambitious.

> I've changed the
> algorithm to minimize first the bit rate error and then the sample point
> error within the best bit rate.
> 
> The old algorithm always picks a sample point less than the target
> sample point. My question to the CAN exports: Is it better to stay below
> the sample point or minimize the error (and pick a sample point slightly
> above the nominal sample point)?

I haven't been doing this for a while :-)

The sample point is not put to 100% since nodes are not guaranteed to be
completely in sync. This may interfere when "slightly" in your
definition becomes more than expected. I'm not qualified anymore to
quantify "slightly" in terms of bittiming, yet the sample point is
specified to the back as far as possible for the wiring. Going "slightly"
above 'eats' the margin you have there, the margin which you may not need
for most wirings out there.

> 
> See the below table for the output of the calculation. There are three
> entries per bit rate:
> 1) original algorithm
> 2) improved algorithm, smaple point is always below nominal sample point
> 3) improved algorithm, sample point error is minimized
> 
> > Bit timing parameters for mscan with 66.666666 MHz ref clock
> > nominal                                 real Bitrt   nom  real SampP
> > Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error BTR0 BTR1
> > 1000000     90   3    4    3   1   6 1010101  1.0% 75.0% 72.7%  3.1% 0x05 0x26
> > 1000000     90   3    4    3   1   6 1010101  1.0% 75.0% 72.7%  3.1% 0x05 0x26
> > 1000000     45   8    8    5   1   3 1010101  1.0% 75.0% 77.2%  2.9% 0x02 0x4f
> 
> >  800000    180   2    2    2   1  12  793650  0.8% 80.0% 71.4% 10.8% 0x0b 0x13
> >  800000     90   5    5    3   1   6  793650  0.8% 80.0% 78.5%  1.9% 0x05 0x29
> >  800000     60   8    8    4   1   4  793650  0.8% 80.0% 80.9%  1.1% 0x03 0x3f
> 
> >  500000    285   2    2    2   1  19  501253  0.3% 87.5% 71.4% 18.4% 0x12 0x13
> >  500000    105   7    8    3   1   7  501253  0.3% 87.5% 84.2%  3.8% 0x06 0x2e
> >  500000    105   8    8    2   1   7  501253  0.3% 87.5% 89.4%  2.2% 0x06 0x1f
> 
> >  250000    570   2    2    2   1  38  250626  0.3% 87.5% 71.4% 18.4% 0x25 0x13
> >  250000    285   5    6    2   1  19  250626  0.3% 87.5% 85.7%  2.1% 0x12 0x1a
> >  250000    285   5    6    2   1  19  250626  0.3% 87.5% 85.7%  2.1% 0x12 0x1a
> 
> Which algorithm is preferred?

I prefer (2).
The improvement over (1) is significant!!

Kind regards,
Kurt

Re: bit-timing and sample point

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 4632 bytes --]

On 04/14/2016 12:26 PM, Kurt Van Dijck wrote:
>> currently I'm reworking the bit timing algorithm.
> Waauw, that's ambitious.

:D - The original algorithm is a simple bute force algorithm. My
improvement is to check all sample points (if the bitrate doesn't match
100%).

>> I've changed the
>> algorithm to minimize first the bit rate error and then the sample point
>> error within the best bit rate.
>>
>> The old algorithm always picks a sample point less than the target
>> sample point. My question to the CAN exports: Is it better to stay below
>> the sample point or minimize the error (and pick a sample point slightly
>> above the nominal sample point)?
> 
> I haven't been doing this for a while :-)

I've _never_ done this. :D

> The sample point is not put to 100% since nodes are not guaranteed to be
> completely in sync. This may interfere when "slightly" in your
> definition becomes more than expected. I'm not qualified anymore to
> quantify "slightly" in terms of bittiming, yet the sample point is
> specified to the back as far as possible for the wiring. Going "slightly"
> above 'eats' the margin you have there, the margin which you may not need
> for most wirings out there.

This example illustrates the "slightly":

>>>> nominal                                 real Bitrt   nom  real SampP
>>>> Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error BTR0 BTR1
>>>>  800000    180   2    2    2   1  12  793650  0.8% 80.0% 71.4% 10.8% 0x0b 0x13
>>>>  800000     90   5    5    3   1   6  793650  0.8% 80.0% 78.5%  1.9% 0x05 0x29
>>>>  800000     60   8    8    4   1   4  793650  0.8% 80.0% 80.9%  1.1% 0x03 0x3f

For 800kbit/s the nominal sample point is 80%.
The original algorithm chooses 71.4%.
The improved (but stays below) chooses 78.5% (error=1.9%).
But there exists a sample point with a smaller error: 80.9% (error=1.1%).

The error is calculated by:

    abs(nominal_sample_point - real_sample_point)
    ---------------------------------------------
                 nominal_sample_point

While iterating algorithm 3 picks configurations with "sample point
error" < "smallest sample point error so far". Algorithm 2 has an
additional "sample point < nominal sample point" to keep the
characteristics of the original algorithm. This code snippet shows the
algorithm 2:

> +               if ((spt <= spt_target) && (spt_error < best_spt_error)) {
> +                       best_spt = spt;
> +                       best_spt_error = spt_error;
> +                       *tseg1_ptr = tseg1;
> +                       *tseg2_ptr = tseg2;
> +               }

Algo 3 doesn't have the "(spt <= spt_target) && ".

>> See the below table for the output of the calculation. There are three
>> entries per bit rate:
>> 1) original algorithm
>> 2) improved algorithm, smaple point is always below nominal sample point
>> 3) improved algorithm, sample point error is minimized
>>
>>> Bit timing parameters for mscan with 66.666666 MHz ref clock
>>> nominal                                 real Bitrt   nom  real SampP
>>> Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error BTR0 BTR1
>>> 1000000     90   3    4    3   1   6 1010101  1.0% 75.0% 72.7%  3.1% 0x05 0x26
>>> 1000000     90   3    4    3   1   6 1010101  1.0% 75.0% 72.7%  3.1% 0x05 0x26
>>> 1000000     45   8    8    5   1   3 1010101  1.0% 75.0% 77.2%  2.9% 0x02 0x4f
>>
>>>  800000    180   2    2    2   1  12  793650  0.8% 80.0% 71.4% 10.8% 0x0b 0x13
>>>  800000     90   5    5    3   1   6  793650  0.8% 80.0% 78.5%  1.9% 0x05 0x29
>>>  800000     60   8    8    4   1   4  793650  0.8% 80.0% 80.9%  1.1% 0x03 0x3f
>>
>>>  500000    285   2    2    2   1  19  501253  0.3% 87.5% 71.4% 18.4% 0x12 0x13
>>>  500000    105   7    8    3   1   7  501253  0.3% 87.5% 84.2%  3.8% 0x06 0x2e
>>>  500000    105   8    8    2   1   7  501253  0.3% 87.5% 89.4%  2.2% 0x06 0x1f
>>
>>>  250000    570   2    2    2   1  38  250626  0.3% 87.5% 71.4% 18.4% 0x25 0x13
>>>  250000    285   5    6    2   1  19  250626  0.3% 87.5% 85.7%  2.1% 0x12 0x1a
>>>  250000    285   5    6    2   1  19  250626  0.3% 87.5% 85.7%  2.1% 0x12 0x1a
>>
>> Which algorithm is preferred?
> 
> I prefer (2).
> The improvement over (1) is significant!!

Thanks,
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: 455 bytes --]

Re: bit-timing and sample point

[Kurt Van Dijck]

> :D - The original algorithm is a simple bute force algorithm. My
> improvement is to check all sample points (if the bitrate doesn't match
> 100%).
> 
> >> I've changed the
> >> algorithm to minimize first the bit rate error and then the sample point
> >> error within the best bit rate.
> >>
> >> The old algorithm always picks a sample point less than the target
> >> sample point. My question to the CAN exports: Is it better to stay below
> >> the sample point or minimize the error (and pick a sample point slightly
> >> above the nominal sample point)?
> > 
> > I haven't been doing this for a while :-)
> 
> I've _never_ done this. :D
> 
> > The sample point is not put to 100% since nodes are not guaranteed to be
> > completely in sync. This may interfere when "slightly" in your
> > definition becomes more than expected. I'm not qualified anymore to
> > quantify "slightly" in terms of bittiming, yet the sample point is
> > specified to the back as far as possible for the wiring. Going "slightly"
> > above 'eats' the margin you have there, the margin which you may not need
> > for most wirings out there.
> 
> This example illustrates the "slightly":
> 
> >>>> nominal                                 real Bitrt   nom  real SampP
> >>>> Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error BTR0 BTR1
> >>>>  800000    180   2    2    2   1  12  793650  0.8% 80.0% 71.4% 10.8% 0x0b 0x13
> >>>>  800000     90   5    5    3   1   6  793650  0.8% 80.0% 78.5%  1.9% 0x05 0x29
> >>>>  800000     60   8    8    4   1   4  793650  0.8% 80.0% 80.9%  1.1% 0x03 0x3f
> 
> For 800kbit/s the nominal sample point is 80%.
> The original algorithm chooses 71.4%.
> The improved (but stays below) chooses 78.5% (error=1.9%).
> But there exists a sample point with a smaller error: 80.9% (error=1.1%).

I understood the example :-)
What I meant with "slightly" being hard to quantify was especially with
regard to the bus characteristics. What is the maximal propagation delay
on the bus?
There is a point within a node's bit-time after which it is not certain
that remotes may have moved on to the next bit-time.
If you allow samplepoint deviations to both sides, then you assume that
the advertised sample point is in the middle of the time fragment where
sampling is ideal. If you allow samplepoint deviations only to below,
then you assume that the advertised sample point is the corner case and
raising it would introduce troubles.
Both assumptions are wrong, the truth is in between, and the advertised
sample points mostly are "rules of thumb".
IMHO, the assumption of going below only makes sense.
Of course, you can (easily) find examples where the sample point may
grow over it.
If I understand the algoritm correctly, there's no limitation in how far
beyond the advertised sample point you may get, as long as it's the
closest. And there, I think, you should put a limit, and until someone
comes up with a better one, I just take 0 as limit, meaning you go only
below :-)

Re: bit-timing and sample point

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 3499 bytes --]

On 04/14/2016 02:19 PM, Kurt Van Dijck wrote:
>> :D - The original algorithm is a simple bute force algorithm. My
>> improvement is to check all sample points (if the bitrate doesn't match
>> 100%).
>>
>>>> I've changed the
>>>> algorithm to minimize first the bit rate error and then the sample point
>>>> error within the best bit rate.
>>>>
>>>> The old algorithm always picks a sample point less than the target
>>>> sample point. My question to the CAN exports: Is it better to stay below
>>>> the sample point or minimize the error (and pick a sample point slightly
>>>> above the nominal sample point)?
>>>
>>> I haven't been doing this for a while :-)
>>
>> I've _never_ done this. :D
>>
>>> The sample point is not put to 100% since nodes are not guaranteed to be
>>> completely in sync. This may interfere when "slightly" in your
>>> definition becomes more than expected. I'm not qualified anymore to
>>> quantify "slightly" in terms of bittiming, yet the sample point is
>>> specified to the back as far as possible for the wiring. Going "slightly"
>>> above 'eats' the margin you have there, the margin which you may not need
>>> for most wirings out there.
>>
>> This example illustrates the "slightly":
>>
>>>>>> nominal                                 real Bitrt   nom  real SampP
>>>>>> Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error BTR0 BTR1
>>>>>>  800000    180   2    2    2   1  12  793650  0.8% 80.0% 71.4% 10.8% 0x0b 0x13
>>>>>>  800000     90   5    5    3   1   6  793650  0.8% 80.0% 78.5%  1.9% 0x05 0x29
>>>>>>  800000     60   8    8    4   1   4  793650  0.8% 80.0% 80.9%  1.1% 0x03 0x3f
>>
>> For 800kbit/s the nominal sample point is 80%.
>> The original algorithm chooses 71.4%.
>> The improved (but stays below) chooses 78.5% (error=1.9%).
>> But there exists a sample point with a smaller error: 80.9% (error=1.1%).
> 
> I understood the example :-)
> What I meant with "slightly" being hard to quantify was especially with
> regard to the bus characteristics. What is the maximal propagation delay
> on the bus?
> There is a point within a node's bit-time after which it is not certain
> that remotes may have moved on to the next bit-time.
> If you allow samplepoint deviations to both sides, then you assume that
> the advertised sample point is in the middle of the time fragment where
> sampling is ideal. If you allow samplepoint deviations only to below,
> then you assume that the advertised sample point is the corner case and
> raising it would introduce troubles.
> Both assumptions are wrong, the truth is in between, and the advertised
> sample points mostly are "rules of thumb".
> IMHO, the assumption of going below only makes sense.
> Of course, you can (easily) find examples where the sample point may
> grow over it.
> If I understand the algoritm correctly, there's no limitation in how far
> beyond the advertised sample point you may get, as long as it's the
> closest. And there, I think, you should put a limit, and until someone
> comes up with a better one, I just take 0 as limit, meaning you go only
> below :-)

Thanks for your thoughts I'll use algorithm 2 then.

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: 455 bytes --]

RE: bit-timing and sample point

[Ramesh Shanmugasundaram]

> >> This example illustrates the "slightly":
> >>
> >>>>>> nominal                                 real Bitrt   nom  real
> SampP
> >>>>>> Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP
> Error BTR0 BTR1
> >>>>>>  800000    180   2    2    2   1  12  793650  0.8% 80.0% 71.4%
> 10.8% 0x0b 0x13
> >>>>>>  800000     90   5    5    3   1   6  793650  0.8% 80.0% 78.5%
> 1.9% 0x05 0x29
> >>>>>>  800000     60   8    8    4   1   4  793650  0.8% 80.0% 80.9%
> 1.1% 0x03 0x3f
> >>
> >> For 800kbit/s the nominal sample point is 80%.
> >> The original algorithm chooses 71.4%.
> >> The improved (but stays below) chooses 78.5% (error=1.9%).
> >> But there exists a sample point with a smaller error: 80.9%
> (error=1.1%).
> >
> > I understood the example :-)
> > What I meant with "slightly" being hard to quantify was especially
> > with regard to the bus characteristics. What is the maximal
> > propagation delay on the bus?
> > There is a point within a node's bit-time after which it is not
> > certain that remotes may have moved on to the next bit-time.
> > If you allow samplepoint deviations to both sides, then you assume
> > that the advertised sample point is in the middle of the time fragment
> > where sampling is ideal. If you allow samplepoint deviations only to
> > below, then you assume that the advertised sample point is the corner
> > case and raising it would introduce troubles.
> > Both assumptions are wrong, the truth is in between, and the
> > advertised sample points mostly are "rules of thumb".
> > IMHO, the assumption of going below only makes sense.
> > Of course, you can (easily) find examples where the sample point may
> > grow over it.
> > If I understand the algoritm correctly, there's no limitation in how
> > far beyond the advertised sample point you may get, as long as it's
> > the closest. And there, I think, you should put a limit, and until
> > someone comes up with a better one, I just take 0 as limit, meaning
> > you go only below :-)
> 
> Thanks for your thoughts I'll use algorithm 2 then.

If not done already, is it worth comparing the algorithm for dbitrates (fd case) too as same code is used? 

Thanks,
Ramesh

Re: bit-timing and sample point

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 871 bytes --]

On 04/14/2016 02:46 PM, Ramesh Shanmugasundaram wrote:
>> Thanks for your thoughts I'll use algorithm 2 then.
> 
> If not done already, is it worth comparing the algorithm for
> dbitrates (fd case) too as same code is used?

The reworked algorithm will not pick worse values than the original one.
However, I'll update the tool for dbitrates. Are there any common
dbitrates? The array if common bitrates is:

> static unsigned int common_bitrates[] = {
> 	1000000,
> 	800000,
> 	500000,
> 	250000,
> 	125000,
> 	100000,
> 	50000,
> 	20000,
> 	10000,
> };

regards,
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: 455 bytes --]

RE: bit-timing and sample point

[Ramesh Shanmugasundaram]

> On 04/14/2016 02:46 PM, Ramesh Shanmugasundaram wrote:
> >> Thanks for your thoughts I'll use algorithm 2 then.
> >
> > If not done already, is it worth comparing the algorithm for dbitrates
> > (fd case) too as same code is used?
> 
> The reworked algorithm will not pick worse values than the original one.
> However, I'll update the tool for dbitrates. 

Thanks. 

Are there any common
> dbitrates? The array if common bitrates is:

Not sure. I read in one of the NXP white paper 2 & 5Mbps are common data bitrates. I have tested 2Mbps only (transceiver capability). May be we can start with 2, 5 & 8Mbps. The tool already allows to print values for a specific bitrate. So we are covered.

Thanks,
Ramesh

Re: bit-timing and sample point

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 929 bytes --]

On 04/14/2016 03:05 PM, Ramesh Shanmugasundaram wrote:
>> Are there any common dbitrates? The array if common bitrates is:
> 
> Not sure. I read in one of the NXP white paper 2 & 5Mbps are common
> data bitrates. I have tested 2Mbps only (transceiver capability). May
> be we can start with 2, 5 & 8Mbps. The tool already allows to print
> values for a specific bitrate. So we are covered.

12 MBit/s seems to be the max.

> static unsigned int common_data_bitrates[] = {
> 	12000000,
> 	10000000,
> 	8000000,
> 	5000000,
> 	4000000,
> 	2000000,
> 	1000000,
> };

Can you give the the typical refclocks for the rcar canfd?

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: 455 bytes --]

RE: bit-timing and sample point

[Ramesh Shanmugasundaram]

> On 04/14/2016 03:05 PM, Ramesh Shanmugasundaram wrote:
> >> Are there any common dbitrates? The array if common bitrates is:
> >
> > Not sure. I read in one of the NXP white paper 2 & 5Mbps are common
> > data bitrates. I have tested 2Mbps only (transceiver capability). May
> > be we can start with 2, 5 & 8Mbps. The tool already allows to print
> > values for a specific bitrate. So we are covered.
> 
> 12 MBit/s seems to be the max.
> 
> > static unsigned int common_data_bitrates[] = {
> > 	12000000,
> > 	10000000,
> > 	8000000,
> > 	5000000,
> > 	4000000,
> > 	2000000,
> > 	1000000,
> > };
> 
> Can you give the the typical refclocks for the rcar canfd?

If external clock picked - 20 or 40MHz are typical OSC used on boards.
If external clock not available, internal CANFD clock is picked - 19999999Hz (if clk_get_rate() is used).

Thanks,
Ramesh

RE: bit-timing and sample point

[Ramesh Shanmugasundaram]

Hi Marc,

Any plans to upstream your algorithm fix[1]? It has been there in can-utils for a while now.

Thanks,
Ramesh

[1] http://comments.gmane.org/gmane.linux.can/9031

> -----Original Message-----
> From: Ramesh Shanmugasundaram
> Sent: 14 April 2016 15:13
> To: 'Marc Kleine-Budde' <mkl@pengutronix.de>; linux-can <linux-
> can@vger.kernel.org>
> Subject: RE: bit-timing and sample point
> 
> > On 04/14/2016 03:05 PM, Ramesh Shanmugasundaram wrote:
> > >> Are there any common dbitrates? The array if common bitrates is:
> > >
> > > Not sure. I read in one of the NXP white paper 2 & 5Mbps are common
> > > data bitrates. I have tested 2Mbps only (transceiver capability).
> > > May be we can start with 2, 5 & 8Mbps. The tool already allows to
> > > print values for a specific bitrate. So we are covered.
> >
> > 12 MBit/s seems to be the max.
> >
> > > static unsigned int common_data_bitrates[] = {
> > > 	12000000,
> > > 	10000000,
> > > 	8000000,
> > > 	5000000,
> > > 	4000000,
> > > 	2000000,
> > > 	1000000,
> > > };
> >
> > Can you give the the typical refclocks for the rcar canfd?
> 
> If external clock picked - 20 or 40MHz are typical OSC used on boards.
> If external clock not available, internal CANFD clock is picked -
> 19999999Hz (if clk_get_rate() is used).
> 
> Thanks,
> Ramesh

Re: bit-timing and sample point

[Marc Kleine-Budde]

[-- Attachment #1.1: Type: text/plain, Size: 495 bytes --]

On 06/17/2016 11:46 AM, Ramesh Shanmugasundaram wrote:
> Hi Marc,
> 
> Any plans to upstream your algorithm fix[1]? It has been there in can-utils for a while now.

Will be included in this pull reqeust.

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: 455 bytes --]

RE: bit-timing and sample point

[Ramesh Shanmugasundaram]

Thank you Marc.

> -----Original Message-----
> From: Marc Kleine-Budde [mailto:mkl@pengutronix.de]
> Sent: 17 June 2016 11:00
> To: Ramesh Shanmugasundaram <ramesh.shanmugasundaram@bp.renesas.com>;
> linux-can <linux-can@vger.kernel.org>
> Subject: Re: bit-timing and sample point
> 
> On 06/17/2016 11:46 AM, Ramesh Shanmugasundaram wrote:
> > Hi Marc,
> >
> > Any plans to upstream your algorithm fix[1]? It has been there in can-
> utils for a while now.
> 
> Will be included in this pull reqeust.
> 
> 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   |