Thread (1 message) 1 message, 1 author, 2011-09-22

Re: [PATCH net-next v2] candev: allow SJW user setting for bittiming calculation

From: Oliver Hartkopp <hidden>
Date: 2011-09-22 19:41:23

Hi Wolfgang,

i put Pavel and Andrey into CC, maybe they also have an opinion about this.
I just talked to a specialist who told me, that a higher SJW is better - if
possible. And if an expert told me so and i had a simple config interface to
fullfill it, it would be great for me ;-)

Here is a link to the patch and this discussion:

http://patchwork.ozlabs.org/patch/115932/

Regards,
Oliver

On 09/22/11 20:10, Wolfgang Grandegger wrote:
On 09/22/2011 06:26 PM, Oliver Hartkopp wrote:
quoted
On 09/22/11 15:07, Wolfgang Grandegger wrote:
quoted
Hi Oliver,

On 09/22/2011 12:28 PM, Oliver Hartkopp wrote:
quoted
This patch adds support for SJW user settings to not set the synchronization
jump width (SJW) to 1 in any case when using the in-kernel bittiming
calculation.

The ip-tool from iproute2 already supports to pass the user defined SJW
value. The given SJW value is sanitized with the controller specific sjw_max
and the calculated tseg2 value. As the SJW can have values up to 4 providing
this value will lead to the maximum possible SJW automatically. A higher SJW
allows higher controller oscillator tolerances.
(..)

quoted
As I already said, I expected "bt->sjw" to be always 0 when
can_calc_bittiming() is called. But the software somehow allows to
preset "bt->sjw", which is not intended as the help of the ip utility shows:

What was the technical reason for this 'not intended' that time?
Fiddling with SJW is something for *expert* only. You need to know
what's going on the bus (electrically). To be clear, I'm not such an expert.
quoted
quoted
I actually hesitate to extend can_calc_bittiming(). I suggest using an
external tool to calculate proper bit-timing parameters and set them
with "ip link set DEVICE type can tq ...".

Yes, i know the possibility to specify the bittiming via time-quanta (tq).
This is what we called the "expert mode".
quoted
But i think the in-kernel bittiming calculation is pretty good and solves most
usual cases. For me it's just an additional requirement to specify SJW as
What's your reason to increase SJW? Likely because you get bus errors
with the standard settings. How should it be set? Likely you need to
fiddle with other parameters as well. For sure, no business for a normal
CAN user.
quoted
MIN(tseg2, max_sjw) to extend the clock source tolerance - which can be
provided as an additional option to the bittiming calculation without pain
(IMO). If i can 'tune' the sample point, why should i not have any influence
to the synchronization jump width generation then?
Bitrate and sample point is something obvious for normal users.
quoted
And btw. a help text can really be changed easily ;-)

-        [ bitrate BITRATE [ sample-point SAMPLE-POINT] ] |
+        [ bitrate BITRATE [ sample-point SAMPLE-POINT] [sjw SJW] ] |
Well, I have stronger arguments against it ;-).

Any other opinions or suggestions?

Wolfgang.

--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo-u79uwXL29TY76Z2rM5mHXA@public.gmane.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help