Find the answer to your Linux question:
Results 1 to 8 of 8
Hi all, I just started on embedded linux (uclinux).However I am new to Linux, so I need to clarify myself the interrupt & signal usage in driver & application. If ...
Enjoy an ad free experience by logging in. Not a member yet? Register.
  1. #1
    Just Joined!
    Join Date
    May 2009
    Posts
    11

    Interrupts and Signals in embedded linux


    Hi all,

    I just started on embedded linux (uclinux).However I am new to Linux, so I need to clarify myself the interrupt & signal usage in driver & application. If any expert or any developer can comment, I would feel great.

    Scenario:-
    Application keeps running some algorithm. Upon an asynchronous event (say gpio event), it should jump to some 'handler', and do some house keeping. (could be changing the IOP/DMA start add etc. Or some control operation).

    What I think I understood:-
    Interrupt Sub Routines can run only in Kernel context. It has to be initialized from device driver only. An application (right now im not visualizing a thread/process - it has just a main function in a while loop) can be 'notified' only through 2 ways:

    1. Reading the file device status. This would be like 'polling or 'not completely asynchronous in terms of the flow'

    2. Have some signal sent from within the isr (running in kernel driver) to the user process. That signal should have some handler. That handler would be executed in user process, then moment the signal is triggered. This can be asynchrnous.

    Along with any comments or info that you can share, I would also like to know where to find info on 2nd point. A small code which shows how to trigger from ISR and how the signal handler should look, how to initialize signal etc would be great (havent found the right material yet).


    Thank you all.
    Have a nice day.
    JA.

  2. #2
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,397
    You could have a thread using an ioctl to communicate with your kernel module. It waits for the ioctl to return, when it has the event information it needs to process. If the processing will likely take too long, it can pass that to another thread and go back to waiting for the next event from the kernel.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  3. #3
    Just Joined!
    Join Date
    May 2009
    Posts
    6
    it is not necessary to write device driver to have ISR
    what u can do is write signal handeller using sigaction or signal system call and put this in loop so that it will go on .or do sigpending to wait for perticular signals

    but if u want to write write device driver then u need to write module .register ur device and then request for interrupt line.here the problem is device will generate interrup of some conditions only .eg.if u r using parallel port then only when pin 10 goes from high to low with condition 4th bit of control line is set interrupt is generated.so some messy stuff if u are new

    so better use sigaction method along with sigpending to wait for perticular signal .in sigaction we need to pass structure sigaction which has one member as sa_handel which will contain name of ISR.If u want to see action without this trouble u can directly use signal system call .Here u can specify signal name and associated signal handeller.

    VIshal

  4. #4
    Just Joined!
    Join Date
    May 2009
    Posts
    11

    HI Vishal

    In non-unix environment I have used ISRs directly in the user code. This was intended for asynchronous events. I want see how to do the same in Linux. I do not want to wait for something (no pending).

    Now, isn't that possible with SIGNUSR1 and SIGNUSR2 signal types? I am just starting to work on signals, and not sure how to use the above. Isnt it possible that some signal can be sent from driver ISR to user, asynchronously? I cannot have the signal type restricted to something.

  5. #5
    Just Joined!
    Join Date
    May 2009
    Posts
    6
    first i want to know what u want to actually write
    a device driver or appliction having signal haneller.
    1.for device driver :
    suppose u r using parallel port for ur device .Then parallet port generats interrupt when pin 10 goes from high to low.and if u have use irq_request and in that call specified ISR it will get executed.
    These are executed at kernel level.Liabraris availabel to user program generally exist at /usr/include where as kernel lib at /usr/src/kernelversion/kernls/linux/
    so they contain different set of function for iff env and can not be used in different environments.
    2.Application using signal handeller:
    Normally in user env.
    here u need to use sigaction() function.
    here u can spcify sig_set that is set of signals for which u are using sigaction function.In sigfunction u can also specify signal handeller or ISR which will be executed when ever signal in sig_set occur.

    As per SIGUSER1 are concerned these are just like another signals by not defined by system.a process if wants to talk to another process can send signal using kill()
    where it can specify signal type.Normally we will use SIGUSR1 and 2 to notify anothr process which will have handeller or ISR associated with these signals.

    But if u use signal instead of sigaction u would b able to use sig_set and will ned to specify ISR for all signals u want to capture individually.So better use sigaction .

    There r function available to fill sig_set .

  6. #6
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,397
    Signals are not really the best way to handle asyncronous events, especially for C++ applications where bypassing object scoping easily leads to memory leaks and other sort of resource violations. It's OK for C programs, but not particularly safe. As an example, signals can be masked, so even if the kernel module raises the signal, the user code still has to either unmask them or check pending signals.

    Often, some bit of global memory, such as a semaphore, can be associated with an event. That is easily checked for a non-zero value to determine if an event of the specified type has been raised. It can be triggered from a kernel module or externally if necessary. I'm not saying this is your best option, but it is a possible one, and one that won't cause problems such as a signal will with C++ programs. The main problem here is that it won't work asyncronously in that you either need to poll for the event(s), or you need to have a thread that polls for the event(s) and then raises a signal (C) or exception (C++) on the other threads.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

  7. #7
    Just Joined!
    Join Date
    May 2009
    Posts
    11

    Hi Rubberman

    Everywhere I see the polling mechanism.......

    1. User has to poll for event occurrence in driver.

    2. Shell polls the command line...

    Just trying to understand, is polling a great idea (I am coming from non-Unix background)? Or Am I missing something to visualize?

    Isnt there a way that asynchronous events can interact with user world? I was happy with ISRs in user space, in non-Unix environments...

  8. #8
    Linux Guru Rubberman's Avatar
    Join Date
    Apr 2009
    Location
    I can be found either 40 miles west of Chicago, in Chicago, or in a galaxy far, far away.
    Posts
    11,397
    Quote Originally Posted by blackfin_dsp_uclinux View Post
    Everywhere I see the polling mechanism.......

    1. User has to poll for event occurrence in driver.

    2. Shell polls the command line...

    Just trying to understand, is polling a great idea (I am coming from non-Unix background)? Or Am I missing something to visualize?

    Isnt there a way that asynchronous events can interact with user world? I was happy with ISRs in user space, in non-Unix environments...
    One can wait for an event, which in Linux/Unix systems is often the select() mechanism, or one can poll for an event when it is convenient. In a multi-threaded system, one thread can wait for an event, and then spawn or dispatch a thread to process it, reducing the latency that is inherent in polling-based systems. Alternatively, one process can wait for an event, and then spawn another process to handle it (fork/exec). There are situations where any of these may be a better solution. Function (requirements) dictates design, and design impacts function.

    As for point #2, a shell does not typically uss a polling mechanism waiting for input. It waits for a key press or signal event and then deals with the event.
    Sometimes, real fast is almost as good as real time.
    Just remember, Semper Gumbi - always be flexible!

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •