Re: bit-timing and sample point

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

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