On 08/11/2010 05:59 PM, Marc Kleine-Budde wrote: > 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?
I have not committed any version of can-calc-bit-timing. I did not see your version due to some svn update problems. Sorry for the noise. > However, the improved algorithm may just find better (i.e. lesser) > sample point errors but the bit rate error stays the same. The improved algorithm is not what exactly what we have in the kernel, right? Anyway, the algorithm will not make anybody happy. > 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 The output is quite nice. > 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. Yes, there are limitations- >>>> 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 In case of bus errors, increasing SJW may help, IIRC. Wolfgang. _______________________________________________ Socketcan-users mailing list [email protected] https://lists.berlios.de/mailman/listinfo/socketcan-users
