Re: [ECOS] Testing interrupts ???

[Bart Veer <bartv at ecoscentric dot com>]

>>>>> "Matthieu" == Matthieu GIRARDIN <Matthieu.GIRARDIN@fr.thalesgroup.com> writes:

    Matthieu> Well, hello everybody !
    Matthieu> Try to imagine :
    Matthieu> 	I create a thread which create itself an interrupt
    Matthieu> (vector 29), attach it and then stand by (for(;;)).

You cannot just "create" an interrupt, even on the synthetic target.
The goal of the synthetic target is to emulate real hardware, for
example an ethernet device. If you want interrupts then you must
either interact with an existing emulated device, or you must write
some new device emulation code. Read the synthetic target
documentation at
http://sources.redhat.com/ecos/docs-latest/ref/hal-synth-arch.html
The overview explains a bit more about how things work. The sections
on writing new devices, both target and host, are also relevant.

Once you have read the documentation I suggest looking at the
implementation of an existing device, for example the synthetic
ethernet driver, and at the synth_intr.c file in the synthetic target
architectural HAL package.

If you need something quick and dirty, it may be possible to use
another signal like SIGUSR1 rather than going via the I/O auxiliary.
As an example of how to do that, look at the way the clock is
implemented in synth_intr.c and especially synth_alrm_sighandler().
However this is not how things are expected to work, so it is not a
long-term solution.

    Matthieu> 	My isr function might just do a little "printf("\nOK!\n");

This is a very bad idea. An interrupt handler is supposed to service
the hardware as quickly as possible and then return to higher-level
code. printf() can take a long time, and if some other code happened
to be calling printf() at the time the interrupt occurred then bad
things will happen. diag_printf() is slightly safer but only slightly,
and should still be avoided if at all possible. Take a look at the
kernel documentation, especially the section "Threads and Interrupt
Handling". 

    Matthieu> 	As it compiled well, I launched the application.
    Matthieu> 	I tried then to launch a "kill -s 29 my_pid" under Linux, where
    Matthieu> "my_pid" is the pid of my application eCos.

No. Signal 29 is SIGIO, and is reserved for use between the synthetic
target I/O auxiliary and the eCos application. What is likely to
happen is that the eCos code in synth_intr.c will detect this signal,
send a message to the I/O auxiliary to ask what emulated interrupt(s)
have happened, and things will get very confused because there have
not actually been any emulated interrupts.

    Matthieu> So if you understood my way of thinking :
    Matthieu> 	Can I do a printf in an isr or must I do it in my dsr
    Matthieu> ? (for the moment there is no dsr)

Neither. Both the ISR and the DSR should do whatever work is
appropriate for servicing the hardware. The DSR can also inform a
foreground thread that an event has happened, for example by posting a
semaphore. Operations like printf() should only happen at thread level.

    Matthieu> 	Can I send an signal from Linux to my eCos application
    Matthieu> 	? (if not how to test interrupts under Linux with a
    Matthieu> 	synthetic target ?)

It is not that simple. Read the documentation.

Bart

-- 
Bart Veer                       eCos Configuration Architect
http://www.ecoscentric.com/     The eCos and RedBoot experts

-- 
Before posting, please read the FAQ: http://sources.redhat.com/fom/ecos
and search the list archive: http://sources.redhat.com/ml/ecos-discuss