headers
Ettore Pedretti | 1 Jun 2010 01:24
Picon
Picon

Re: How to generate a waveform / digital output (Alexis)

Hi Daniele,

Thanks very much for your help. It is very appreciated. I compiled
your programs. When I run them I get:

fangorn:~/control/CHAMP/analogy# ./analogy-waveform
amplitude=1.000000
offset=0.000000
analogy-waveform.c:364:main:DEBUG: device=analogy0 fd=0
analogy-waveform.c:365:main:DEBUG: subdevices=14
analogy-waveform.c:366:main:DEBUG: read subdevice=-1
analogy-waveform.c:367:main:DEBUG: write subdevice=1
analogy-waveform.c:368:main:DEBUG: sbsize=16456
analogy-waveform.c:374:main:DEBUG: subdevice=1
analogy-waveform.c:405:main:DEBUG: range=0 10000000 -10000000
analogy-waveform.c:411:main:DEBUG: min=-1.000000 max=1.000000
analogy-waveform.c:414:main:DEBUG: range=-1
analogy-waveform.c:419:main:ERROR: analogy get rngnfo

and dmesg:

Analogy: a4l_rt_ioctl: minor=0
Analogy: a4l_rt_ioctl: minor=0
Analogy: a4l_rt_ioctl: minor=0
Analogy: a4l_ioctl_cancel: minor=0
Analogy: a4l_ioctl_cancel: non functional subdevice
Analogy: a4l_rt_close: minor=0

What am I doing wrong? do I need to pass a parameter?
(Continue reading)

Permalink | Reply | 3 comments |
headers
Ettore Pedretti | 1 Jun 2010 03:37
Picon

Re: How to generate a waveform / digital output (Alexis)

Hi Daniele,

Thanks again for your code. It works when I select range=0

./analogy-waveform --r 0
./analogy-phasemod --r 0

I get a sine wave out of the card

Thanks a bunch!!

Ettore

On 31 May 2010 16:24, Ettore Pedretti <ep41 <at> st-and.ac.uk> wrote:
> Hi Daniele,
>
> Thanks very much for your help. It is very appreciated. I compiled
> your programs. When I run them I get:
>
> fangorn:~/control/CHAMP/analogy# ./analogy-waveform
> amplitude=1.000000
> offset=0.000000
> analogy-waveform.c:364:main:DEBUG: device=analogy0 fd=0
> analogy-waveform.c:365:main:DEBUG: subdevices=14
> analogy-waveform.c:366:main:DEBUG: read subdevice=-1
> analogy-waveform.c:367:main:DEBUG: write subdevice=1
> analogy-waveform.c:368:main:DEBUG: sbsize=16456
> analogy-waveform.c:374:main:DEBUG: subdevice=1
> analogy-waveform.c:405:main:DEBUG: range=0 10000000 -10000000
> analogy-waveform.c:411:main:DEBUG: min=-1.000000 max=1.000000
(Continue reading)

Permalink | Reply | 2 comments |
headers
Everett Wang | 1 Jun 2010 03:45
Picon

IRQ programming

Hi All,

I want to us an x86 machine to program IRQ from an externel signal
(GPS). The GPS device can send
a square pulse from precision timer. But I am not sure where this
signal should be connected to so an IRQ can be
generated. I googled this topics a little bit and found that parallel
port can be used. Since most embedded
X86 board now doesn't have any parallel port, I wonder if we have a
better way to sensor the signal? Can
I route the GPS pulse signal to serial port to generate IRQ? or use
GPIO that some of the boards have?

Any suggestions are welcome,

Everett
Permalink | Reply | 0 comments |
headers
Daniele Nicolodi | 1 Jun 2010 13:02

Linux kernel 2.6.32.14 and Xenomai 2.5.2 does not boot

Hello.

In the process of upgrading my data acquisition system from Xenomai
2.5.0 to Xenomai 2.5.2, I also upgraded the kernel from the 2.6.30
release to 2.6.32.14.

However the new kernel, compiled with the same options as the old one,
does not boot on my hardware, a x86 PC with a Celeron CPU. After the
boot loader I'm left with a black screen.

I have noticed that going from the 2.6.30 to the 2.6.32 kernel the Adeos
Ipipe patch goes from version 2.4 to 2.6. Can this be related to my problem?

How can I investigate, and eventually solve, this problem?

Thanks. Cheers,
--

-- 
Daniele
Permalink | Reply | 15 comments |
headers
Jan Kiszka | 1 Jun 2010 13:23
Picon

Re: Linux kernel 2.6.32.14 and Xenomai 2.5.2 does not boot

Daniele Nicolodi wrote:
> Hello.
> 
> In the process of upgrading my data acquisition system from Xenomai
> 2.5.0 to Xenomai 2.5.2, I also upgraded the kernel from the 2.6.30
> release to 2.6.32.14.

Latest Xenomai is 2.5.3, latest 2.6.32 patch is
adeos-ipipe-2.6.32.13-x86-2.6-04.patch [1]. Make sure you have both.

> 
> However the new kernel, compiled with the same options as the old one,
> does not boot on my hardware, a x86 PC with a Celeron CPU. After the
> boot loader I'm left with a black screen.
> 
> I have noticed that going from the 2.6.30 to the 2.6.32 kernel the Adeos
> Ipipe patch goes from version 2.4 to 2.6. Can this be related to my problem?
> 
> How can I investigate, and eventually solve, this problem?
> 
> Thanks. Cheers,

Jan

[1]http://download.gna.org/adeos/patches/v2.6/x86/adeos-ipipe-2.6.32.13-x86-2.6-04.patch

--

-- 
Siemens AG, Corporate Technology, CT T DE IT 1
Corporate Competence Center Embedded Linux
(Continue reading)

Permalink | Reply | 14 comments |
headers
Tschaeche IT-Services | 1 Jun 2010 15:50

Handling Linux Signals in primary domain context

Hi,

we have the following scenario:

A high priority periodic primary domain task (H), which calls
rt_task_suspend(L) in each even period and rt_task_resume(L)
in each odd period on a low priority primary domain task (L).
L-task consumes all available CPU resources (while(1)).
Thus, the rest of each cycle (after H has got the CPU) is used
alternately by L-task, ROOT-task, L-task,...

In our debugging implementation, we send a SIGTRAP to L-task.
H-task recognizes this by reporting EINTR when calling rt_task_suspend(L).
But, the while(1) in L-task is not interrupted although there is a SIGTRAP
pending.

Our workaround could be, to send a rt_signal when rt_task_suspend()
returns EINTR and, then, in the rt-signal handler migrate L-task
to secondary domain (calling rt_task_set_mode(T_PRIMARY,0))
initiating the Linux scheduler, which, then, initiates the SIGTRAP handling
in secondary domain context.

Is there a simpler way to get primary domain tasks interrupted
by Linux signals? Xenomai already knows about the pending signal
and, maybe, could initiate the secondary domain switch on a primary scheduler
event.

Thanks,

	Olli
(Continue reading)

Permalink | Reply | 26 comments |
headers
Gilles Chanteperdrix | 1 Jun 2010 15:52
Favicon

Re: Handling Linux Signals in primary domain context

Tschaeche IT-Services wrote:
> Hi,
> 
> we have the following scenario:
> 
> A high priority periodic primary domain task (H), which calls
> rt_task_suspend(L) in each even period and rt_task_resume(L)
> in each odd period on a low priority primary domain task (L).
> L-task consumes all available CPU resources (while(1)).
> Thus, the rest of each cycle (after H has got the CPU) is used
> alternately by L-task, ROOT-task, L-task,...
> 
> In our debugging implementation, we send a SIGTRAP to L-task.
> H-task recognizes this by reporting EINTR when calling rt_task_suspend(L).
> But, the while(1) in L-task is not interrupted although there is a SIGTRAP
> pending.
> 
> Our workaround could be, to send a rt_signal when rt_task_suspend()
> returns EINTR and, then, in the rt-signal handler migrate L-task
> to secondary domain (calling rt_task_set_mode(T_PRIMARY,0))
> initiating the Linux scheduler, which, then, initiates the SIGTRAP handling
> in secondary domain context.
> 
> Is there a simpler way to get primary domain tasks interrupted
> by Linux signals? Xenomai already knows about the pending signal
> and, maybe, could initiate the secondary domain switch on a primary scheduler
> event.

Could you send us a self-contained minimal program which exhibits this
behaviour?
(Continue reading)

Permalink | Reply | 0 comments |
headers
Daniele Nicolodi | 1 Jun 2010 15:54

Re: Linux kernel 2.6.32.14 and Xenomai 2.5.2 does not boot

On 01/06/10 13:23, Jan Kiszka wrote:
> Daniele Nicolodi wrote:
>> Hello.
>>
>> In the process of upgrading my data acquisition system from Xenomai
>> 2.5.0 to Xenomai 2.5.2, I also upgraded the kernel from the 2.6.30
>> release to 2.6.32.14.
> 
> Latest Xenomai is 2.5.3, latest 2.6.32 patch is
> adeos-ipipe-2.6.32.13-x86-2.6-04.patch [1]. Make sure you have both.

This adeos patch does not apply cleanly to 2.6.32.14 kernel sources.
Looks like a hunk in include/linux/modules.h has been applied upstream.
However this was easy to merge.

Using the latest xenomai and adeos patch however results again in a
kernel that does not boot on my hardware. This problem is present since
the first time I have been trying to use xenomai on this box, as I wrote
in an email to the list on the 17th February early this year, it is thus
not a recent regression.

Further suggestions?

Thanks. Cheers,
--

-- 
Daniele
Permalink | Reply | 13 comments |
headers
Gilles Chanteperdrix | 1 Jun 2010 15:59
Favicon

Re: Handling Linux Signals in primary domain context

Tschaeche IT-Services wrote:
> Hi,
> 
> we have the following scenario:
> 
> A high priority periodic primary domain task (H), which calls
> rt_task_suspend(L) in each even period and rt_task_resume(L)
> in each odd period on a low priority primary domain task (L).
> L-task consumes all available CPU resources (while(1)).
> Thus, the rest of each cycle (after H has got the CPU) is used
> alternately by L-task, ROOT-task, L-task,...
> 
> In our debugging implementation, we send a SIGTRAP to L-task.
> H-task recognizes this by reporting EINTR when calling rt_task_suspend(L).
> But, the while(1) in L-task is not interrupted although there is a SIGTRAP
> pending.

That is expected, the automatic migration from primary mode to secondary
mode when recieving a signal only works if the task emits syscall.

> 
> Our workaround could be, to send a rt_signal when rt_task_suspend()
> returns EINTR and, then, in the rt-signal handler migrate L-task
> to secondary domain (calling rt_task_set_mode(T_PRIMARY,0))
> initiating the Linux scheduler, which, then, initiates the SIGTRAP handling
> in secondary domain context.
> 
> Is there a simpler way to get primary domain tasks interrupted
> by Linux signals? Xenomai already knows about the pending signal
> and, maybe, could initiate the secondary domain switch on a primary scheduler
(Continue reading)

Permalink | Reply | 0 comments |
headers
Philippe Gerum | 1 Jun 2010 16:32
Favicon

Re: Handling Linux Signals in primary domain context

On Tue, 2010-06-01 at 15:50 +0200, Tschaeche IT-Services wrote:
> Hi,
> 
> we have the following scenario:
> 
> A high priority periodic primary domain task (H), which calls
> rt_task_suspend(L) in each even period and rt_task_resume(L)
> in each odd period on a low priority primary domain task (L).
> L-task consumes all available CPU resources (while(1)).
> Thus, the rest of each cycle (after H has got the CPU) is used
> alternately by L-task, ROOT-task, L-task,...
> 
> In our debugging implementation, we send a SIGTRAP to L-task.
> H-task recognizes this by reporting EINTR when calling rt_task_suspend(L).
> But, the while(1) in L-task is not interrupted although there is a SIGTRAP
> pending.

Using SIGTRAP will badly conflict with GDB. Hope this is ok.

> 
> Our workaround could be, to send a rt_signal when rt_task_suspend()
> returns EINTR and, then, in the rt-signal handler migrate L-task
> to secondary domain (calling rt_task_set_mode(T_PRIMARY,0))
> initiating the Linux scheduler, which, then, initiates the SIGTRAP handling
> in secondary domain context.
> 
> Is there a simpler way to get primary domain tasks interrupted
> by Linux signals? Xenomai already knows about the pending signal
> and, maybe, could initiate the secondary domain switch on a primary scheduler
> event.
(Continue reading)

Permalink | Reply | 23 comments |

Gmane