Re: [SocketCan] Problem of accuracy

[Wolfgang Grandegger <wg@grandegger.com>]

On 07/09/2012 10:14 AM, Mohamed HAMZAOUI wrote:
> I cannot use the 2.6.33 kernel version because it's not support my
> board and, until this moment only, the kernel version 2.6.32*  can be
> found for my board for which i can not find any adeos patch or
> preempt-rt patch

I was thinking about Linux > 3.4. Anyway, I understand your problem.
Xenomai will not help without extra effort because there is no RT-CAN
driver for the TI HECC. What are your real-time requirements?

> I will test the patch for ti_hecc.c and i will return for you.
> * (TI provide a 2.6.37 kernel version but with problem Kernel PANIC !)

:(

Wolfgang.

> On Mon, Jul 9, 2012 at 9:18 AM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>> On 07/08/2012 10:30 PM, Mohamed HAMZAOUI wrote:
>>> The other transeiver is a KVASER USBCan II (HS,HS) it's an usb gateway
>>> CAN and it's accurate because i use it with other CAN transeiver
>>> (IXXAT PCI or Vector CanboardXL) and i have always the same result.
>>
>> Well, I would not use a USB CAN controller for accurate timing (if it
>> does not use hardware time stamps). Anyway, I think that's not the
>> problem, as Kurt already pointed out.
>>
>>> My board is Craneboard "AM3517-crane" and i compiled my system with
>>> OpenEmbedded which done : (cat /proc/version) Linux version 2.6.32
>>> (requinham@pearl) (gcc version 4.5.3 20110311 (prerelease) (GCC) ) #1
>>> PREEMPT Fri Jul 6 21:46:07 CEST 2012
>>
>> OK, then you use the ti_hecc driver, which hit mainline in 2.6.33! Could
>> you show as the source of your "drivers/net/can/ti_hecc.c"? There is at
>> least one issue in the early driver version, which makes sense to fix:
>>
>> http://git.kernel.org/?p=linux/kernel/git/torvalds/linux.git;a=commit;h=e3f240f460a36b158217944b52a85f304914c1a6
>>
>> If that doesn't help, you should use ftrace to understand what's going
>> on. Well, not sure if ftrace already works with 2.6.32 on ARM... that
>> would be another good reason to update to a more recent version of the
>> kernel. Would that be an option for you?
>>
>> Wolfgang.
>>
>>> On Sun, Jul 8, 2012 at 10:13 PM, Wolfgang Grandegger <wg@grandegger.com> wrote:
>>>> On 07/08/2012 09:43 PM, Mohamed HAMZAOUI wrote:
>>>>> Hi,
>>>>>
>>>>>> This problem is not CAN related. Anyway, you can read/try/check:
>>>>>>
>>>>>> - are high-resolution timers enabled in your kernel?
>>>>>
>>>>> My high resolution timers is enabled in Kernel and i activate
>>>>> Preemptible kernel (low latency desktop)
>>>>>
>>>>>> - use cyclictest [1] to measure user-space timing accuracy.
>>>>>
>>>>> the cyclictest mesure with 0% load is 307 in maximum
>>>>
>>>> You mean 302 us? Did you generate some load? That normally makes a big
>>>> difference.
>>>>
>>>>>
>>>>>> - use clock_nanosleep for periodic tasks.
>>>>>
>>>>> i use clock_nanosleep with (1000000 ns = 1ms) and the result mesured
>>>>> with another CAN transeiver is an average of 1.30 ms (delta = 300 盜)
>>>>> !
>>>>
>>>> That means that you see a period of 1.3ms instead of 1ms? That's really
>>>> strange. I assume that the timing on the system with the other CAN
>>>> transceiver is accurate.
>>>>
>>>>>> - try to start cangen with "chrt -f 10 cangen can0".
>>>>>
>>>>> no effect.
>>>>>
>>>>>> - read "man sched_setscheduler" for a description of the Linux
>>>>>>   scheduling scheme.
>>>>>
>>>>> I test with two type of SCHED : RR and FIFO but the result is same
>>>>>
>>>>> Maybe i need to pass to Xenomai or PREEMPT-RT ?
>>>>
>>>> What system, kernel and CAN controller do you use? Is it an MCP25xx?
>>>>
>>>> Wolfgang.
>>>>
>>> --
>>> To unsubscribe from this list: send the line "unsubscribe linux-can" in
>>> the body of a message to majordomo@vger.kernel.org
>>> More majordomo info at  http://vger.kernel.org/majordomo-info.html
>>>
>>>
>>
>>
> 
>