Wolfgang Grandegger | 1 Jan 09:41 2009

Re: CAN support for TS_CAN1 (Technologic Systems)

Charlton, John wrote:
> I am testing CAN using a TS_CAN1 PC-104 card on an x86 Nano-7240.  It appears that none of the existing
SJA1000 drivers support this hardware so I created a new driver module from rtcan_isa.c and modified it to
work with the TS_CAN1 hardware.  I am working with linux-2.6.27.7  and xenomai-2.4.6.1 and have added the
new source module rtcan_tscan1.c to the ksrc/drivers/can/sja1000 directory. When I rerun
prepare-kernel.sh it creates the link for the new module in the linux kernel source tree, but there is no
checkbox in the kernel configuration.
> 
> How do I add the new module to the kernel configuration options?

You need to add Kconfig options to

http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/sja1000/Kconfig

Wolfgang,
Gilles Chanteperdrix | 1 Jan 14:34 2009

Re: pthread cancelation and scheduling magics

Wolfgang Grandegger wrote:
> Wolfgang Grandegger wrote:
>> Hi Gilles,
>>
>> Gilles Chanteperdrix wrote:
>>> Wolfgang Grandegger wrote:
>>>> I'm also puzzled why pthread_setschedparam() does make a mode switch
>>>> to secondary mode (sometimes).
>>> That is normal. The glibc caches threads priority value, so we have to
>>> call __real_pthread_setschedparam to update them. This issue has been
>>> solved differently on trunk, but unfortunately, we can not backport this
>>> modification on v2.4.x branch.
>> To get you right. With v2.4.x it is not possible with the POSIX skin to
>> change the priority of a real-time thread in the primary mode without
>> loosing determinism (because it will switch to secondary mode). What
>> options do I have?
> 
> I gave Xenomai trunk a try and pthread_setschedparam() does not switch
> to secondary mode any more on my PowerPC test system. Nice, I just get
> an Oops in thread_delete from time to time. More on that issue later.
> For my ARM i.mx31 system, a need a few patches to get the Xenomai src's
> compiled:
> 
> Index: include/asm-generic/bits/bind.h
> ===================================================================
> --- include/asm-generic/bits/bind.h	(revision 4450)
> +++ include/asm-generic/bits/bind.h	(working copy)
>  <at>  <at>  -72,7 +72,7  <at>  <at> 
>  	err = XENOMAI_SYSCALL1(__xn_sys_current, &current);
>  	if (err) {
(Continue reading)

Philippe Gerum | 1 Jan 18:07 2009

Re: pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote:
> Wolfgang Grandegger wrote:
>> Wolfgang Grandegger wrote:
>>> Hi Gilles,
>>>
>>> Gilles Chanteperdrix wrote:
>>>> Wolfgang Grandegger wrote:
>>>>> I'm also puzzled why pthread_setschedparam() does make a mode switch
>>>>> to secondary mode (sometimes).
>>>> That is normal. The glibc caches threads priority value, so we have to
>>>> call __real_pthread_setschedparam to update them. This issue has been
>>>> solved differently on trunk, but unfortunately, we can not backport this
>>>> modification on v2.4.x branch.
>>> To get you right. With v2.4.x it is not possible with the POSIX skin to
>>> change the priority of a real-time thread in the primary mode without
>>> loosing determinism (because it will switch to secondary mode). What
>>> options do I have?
>> I gave Xenomai trunk a try and pthread_setschedparam() does not switch
>> to secondary mode any more on my PowerPC test system. Nice, I just get
>> an Oops in thread_delete from time to time. More on that issue later.
>> For my ARM i.mx31 system, a need a few patches to get the Xenomai src's
>> compiled:
>>
>> Index: include/asm-generic/bits/bind.h
>> ===================================================================
>> --- include/asm-generic/bits/bind.h	(revision 4450)
>> +++ include/asm-generic/bits/bind.h	(working copy)
>>  <at>  <at>  -72,7 +72,7  <at>  <at> 
>>  	err = XENOMAI_SYSCALL1(__xn_sys_current, &current);
>>  	if (err) {
(Continue reading)

Wolfgang Grandegger | 1 Jan 18:10 2009

Re: pthread cancelation and scheduling magics

Gilles Chanteperdrix wrote:
> Wolfgang Grandegger wrote:
>> Wolfgang Grandegger wrote:
>>> Hi Gilles,
>>>
>>> Gilles Chanteperdrix wrote:
>>>> Wolfgang Grandegger wrote:
>>>>> I'm also puzzled why pthread_setschedparam() does make a mode switch
>>>>> to secondary mode (sometimes).
>>>> That is normal. The glibc caches threads priority value, so we have to
>>>> call __real_pthread_setschedparam to update them. This issue has been
>>>> solved differently on trunk, but unfortunately, we can not backport this
>>>> modification on v2.4.x branch.
>>> To get you right. With v2.4.x it is not possible with the POSIX skin to
>>> change the priority of a real-time thread in the primary mode without
>>> loosing determinism (because it will switch to secondary mode). What
>>> options do I have?
>> I gave Xenomai trunk a try and pthread_setschedparam() does not switch
>> to secondary mode any more on my PowerPC test system. Nice, I just get
>> an Oops in thread_delete from time to time. More on that issue later.
>> For my ARM i.mx31 system, a need a few patches to get the Xenomai src's
>> compiled:
>>
>> Index: include/asm-generic/bits/bind.h
>> ===================================================================
>> --- include/asm-generic/bits/bind.h	(revision 4450)
>> +++ include/asm-generic/bits/bind.h	(working copy)
>>  <at>  <at>  -72,7 +72,7  <at>  <at> 
>>  	err = XENOMAI_SYSCALL1(__xn_sys_current, &current);
>>  	if (err) {
(Continue reading)

Gilles Chanteperdrix | 1 Jan 19:00 2009

Re: pthread cancelation and scheduling magics

Philippe Gerum wrote:
> Gilles Chanteperdrix wrote:
>> Wolfgang Grandegger wrote:
>>> Wolfgang Grandegger wrote:
>>>> Hi Gilles,
>>>>
>>>> Gilles Chanteperdrix wrote:
>>>>> Wolfgang Grandegger wrote:
>>>>>> I'm also puzzled why pthread_setschedparam() does make a mode switch
>>>>>> to secondary mode (sometimes).
>>>>> That is normal. The glibc caches threads priority value, so we have to
>>>>> call __real_pthread_setschedparam to update them. This issue has been
>>>>> solved differently on trunk, but unfortunately, we can not backport this
>>>>> modification on v2.4.x branch.
>>>> To get you right. With v2.4.x it is not possible with the POSIX skin to
>>>> change the priority of a real-time thread in the primary mode without
>>>> loosing determinism (because it will switch to secondary mode). What
>>>> options do I have?
>>> I gave Xenomai trunk a try and pthread_setschedparam() does not switch
>>> to secondary mode any more on my PowerPC test system. Nice, I just get
>>> an Oops in thread_delete from time to time. More on that issue later.
>>> For my ARM i.mx31 system, a need a few patches to get the Xenomai src's
>>> compiled:
>>>
>>> Index: include/asm-generic/bits/bind.h
>>> ===================================================================
>>> --- include/asm-generic/bits/bind.h	(revision 4450)
>>> +++ include/asm-generic/bits/bind.h	(working copy)
>>>  <at>  <at>  -72,7 +72,7  <at>  <at> 
>>>  	err = XENOMAI_SYSCALL1(__xn_sys_current, &current);
(Continue reading)

Gilles Chanteperdrix | 1 Jan 19:11 2009

Re: pthread cancelation and scheduling magics

Wolfgang Grandegger wrote:
> Gilles Chanteperdrix wrote:
>> Wolfgang Grandegger wrote:
>>> Wolfgang Grandegger wrote:
>>>> Hi Gilles,
>>>>
>>>> Gilles Chanteperdrix wrote:
>>>>> Wolfgang Grandegger wrote:
>>>>>> I'm also puzzled why pthread_setschedparam() does make a mode switch
>>>>>> to secondary mode (sometimes).
>>>>> That is normal. The glibc caches threads priority value, so we have to
>>>>> call __real_pthread_setschedparam to update them. This issue has been
>>>>> solved differently on trunk, but unfortunately, we can not backport this
>>>>> modification on v2.4.x branch.
>>>> To get you right. With v2.4.x it is not possible with the POSIX skin to
>>>> change the priority of a real-time thread in the primary mode without
>>>> loosing determinism (because it will switch to secondary mode). What
>>>> options do I have?
>>> I gave Xenomai trunk a try and pthread_setschedparam() does not switch
>>> to secondary mode any more on my PowerPC test system. Nice, I just get
>>> an Oops in thread_delete from time to time. More on that issue later.
>>> For my ARM i.mx31 system, a need a few patches to get the Xenomai src's
>>> compiled:
>>>
>>> Index: include/asm-generic/bits/bind.h
>>> ===================================================================
>>> --- include/asm-generic/bits/bind.h	(revision 4450)
>>> +++ include/asm-generic/bits/bind.h	(working copy)
>>>  <at>  <at>  -72,7 +72,7  <at>  <at> 
>>>  	err = XENOMAI_SYSCALL1(__xn_sys_current, &current);
(Continue reading)

nourry | 5 Jan 14:55 2009
Picon

rt_printf and file writing


Hi all,

maybe another silly question but where is written string passed to rt_printf ?
My program compiled fine but nothing appears on the screen, the issue is that
i'm doing data acquisition and i need to check during progression values i get
(anyway i've been asked to print these values on the screen).

Another thing, in order to keep these data even if the computer may come to
crash, we would appreciate to save them in a file, is there a way to do so in
realtime ?

Thanks again for your work,
Antoine
Gilles Chanteperdrix | 5 Jan 15:53 2009

Re: rt_printf and file writing

nourry <at> free.fr wrote:
> Hi all,
> 
> maybe another silly question but where is written string passed to rt_printf ?
> My program compiled fine but nothing appears on the screen, the issue is that
> i'm doing data acquisition and i need to check during progression values i get
> (anyway i've been asked to print these values on the screen).
> 
> Another thing, in order to keep these data even if the computer may come to
> crash, we would appreciate to save them in a file, is there a way to do so in
> realtime ?

Printing on the screen or to a file uses Linux drivers, so is not a
real-time operation, at least up to now with Xenomai. What you can do is
get real-time tasks to use a buffering IPC of some sort to let a non
real-time task do the actual writing to file or to the screen.

This is what rt_printf does. So, maybe you do not see anything because
your real-time task is running all the time and does not let linux run?

--

-- 
                                                 Gilles.
Charlton, John | 5 Jan 16:53 2009

Re: CAN support for TS_CAN1 (Technologic Systems)

Thank you.  That got it into the linux kernel config. I also had to edit the xenomai Makefile in
ksrc/drivers/can/sja1000 to get the new module to build and install.

--John

-----Original Message-----
From: Wolfgang Grandegger [mailto:wg <at> grandegger.com]
Sent: Thursday, January 01, 2009 3:41 AM
To: Charlton, John
Cc: xenomai-help <at> gna.org
Subject: Re: [Xenomai-help] CAN support for TS_CAN1 (Technologic Systems)

Charlton, John wrote:
> I am testing CAN using a TS_CAN1 PC-104 card on an x86 Nano-7240.  It appears that none of the existing
SJA1000 drivers support this hardware so I created a new driver module from rtcan_isa.c and modified it to
work with the TS_CAN1 hardware.  I am working with linux-2.6.27.7  and xenomai-2.4.6.1 and have added the
new source module rtcan_tscan1.c to the ksrc/drivers/can/sja1000 directory. When I rerun
prepare-kernel.sh it creates the link for the new module in the linux kernel source tree, but there is no
checkbox in the kernel configuration.
>
> How do I add the new module to the kernel configuration options?

You need to add Kconfig options to

http://www.rts.uni-hannover.de/xenomai/lxr/source/ksrc/drivers/can/sja1000/Kconfig

Wolfgang,
Nikolaj Fogh | 7 Jan 12:49 2009
Picon

Blackfin serial port in Xenomai

Hi,

I am trying to interface with a serial port on a bluetechnics cm-bf537e
board (a blackfin chip). However, it seems that the serial port in the
blackfin is not compatible with a 8250 chip, so I cannot get the xenomai
rtdm serial driver working. Has anyone got a driver for the blackfin
serial port for hard real time.

Right now, I am just printf'ing to a serial console to print data. I
would like to avoid that.

Thanks
  - Nikolaj Fogh

Gmane