Wolfgang Grandegger wrote:
[...]

>>> However the mainline driver only supports the bus clock.
>> and with this clock, if it is 66.5 MHz, one Mbit/s can not be reached.
> 
> OK. Another problem might be that 66.5 MHz does not give *good*
> bit-timing parameters as confirmed by my can-calc-bit-timing:
> 
>  $ ./can-calc-bit-timing -c 66500000 flexcan
>  Bit timing parameters for flexcan using 66500000Hz
>  Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP SampP Error
>  1000000     90   4    3    3   1   6 72.7%  0.8% !!
>   800000    180   2    2    2   1  12 71.4%  1.0%
>   500000    105   8    7    3   1   7 84.2%  0.0%
>   250000    285   8    3    2   1  19 85.7%  0.0%
>   125000    571   8    3    2   1  38 85.7%  0.0%
>   100000    526   8    7    3   1  35 84.2%  0.0%
>    50000   1428   8    3    2   1  95 85.7%  0.0%
>    20000   2631   8    7    3   1 175 84.2%  0.0%
> 
> It it's even worse with worse with 24.576MHz:
> 
>  $ ./can-calc-bit-timing -c 24576000 flexcan
>  Bit timing parameters for flexcan using 24576000Hz
>  Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP SampP Error
>  1000000     40   8    8    8   1   1 68.0%  1.7% !!!!
>   800000    122   5    2    2   1   3 80.0%  2.4%
>   500000    284   2    2    2   1   7 71.4%  0.3%
>   250000    569   2    2    2   1  14 71.4%  0.3%
>   125000   1139   2    2    2   1  28 71.4%  0.3%
>   100000   1424   2    2    2   1  35 71.4%  0.3%
>    50000   1668   7    2    2   1  41 83.3%  0.1%
>    20000   5004   5    2    2   1 123 80.0%  0.1%
>    10000   7690   8    2    2   1 189 84.6%  0.0%
> 
> Marc, what's happened with your optimized version of
> can-calc-bit-timing? Does it find better values?

I just noticed that the can-calc-bit-timing is in can-test and an
improved version is in can-utils. I commited the improved version to
can-utils, but shame on me, 2 month after you've commited the initial
version to can-test. What should we do?

However, the improved algorithm may just find better (i.e. lesser)
sample point errors but the bit rate error stays the same.

The bitrate is defined by clock frequence / brp * (sum of segments).
I've added some flexcan definitions with a fixed brp of 1, 2 and 3:

Bit timing parameters for flexcan with 24.576000 MHz ref clock
nominal                                 real Bitrt   nom  real SampP
Bitrate TQ[ns] PrS PhS1 PhS2 SJW BRP Bitrate Error SampP SampP Error   CAN_CTRL
1000000     40   8    8    8   1   1  983040  1.7% 75.0% 68.0%  9.3% 0x003f0007
1000000     81   4    4    3   1   2 1024000  2.4% 75.0% 75.0%  0.0% 0x011a0003
1000000    122   2    3    2   1   3 1024000  2.4% 75.0% 75.0%  0.0% 0x02110001

Manually:
-> 24576000 / 1000000
 = 24.576000

So the divider must be (surprisingly) 24.576.

Try 24:
-> 24576000 / 24
 = 1024000.000000
-> 1024000.000000 / 1000000
 = 1.024000

==> 2.4% error

Try 25:
-> 24576000 / 25
 = 983040.000000
-> 1 - 983040.000000 / 1000000
 = 0.016960

==> 1.7% error

So a brp of "1" with 25 timequanta is the best: the algorithm calculates
3x8 (PrS, PhS1, PhS2) + 1 (SyncSec) == 25.

For a better sample point the PhS2 must be smaller, but this means PrS1
and PhS1 must be bigger. But they are already at they maximal values.

>>> Patches are, as
>>> always, welcome.
>> Once I know how to do it, than let's  see.
> 
> It should be selectable via platform data.

ACK. Add a flag that selects the clock. The clock names, for clk_get,
if needed should stay in the driver.

>> For now it's really difficult to dive into such system internals.
>> It's difficult to read the hardware manual describing the clocks and even 
>> more 
>> difficult to find and _use_ the already available BSP functions and consider 
>> all side effects. That is may problem. Only setting bit 13 in the clock 
>> control register seems not to be the solution. Doing it, my system freezes 
>> completely (kernel 2.6.32.)
> 
> Just setting bit 13 is not enough. You also need to provide the proper
> CAN clock frequency. Nevertheless, real CAN hardware experts are *able*
> to analyze the CAN signals with an oscilloscope and find proper
> bit-timing parameters. me == software guy!

/me, too

Cheers, 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: signature.asc
Description: OpenPGP digital signature

_______________________________________________
Socketcan-users mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/socketcan-users

Reply via email to