Re: [rtl] interrupts
Hello again,
All sorted.
Another process had got hold of /dev/rtf3.
bios settings were incorrect - interrupt 7 was being snaffled
by the printer port.
This rtl stuff is really very good. Thanks lads.
Cheers,
Matt W.
On Fri, Mar 09, 2001 at 05:05:12PM +, Matthew Whillock wrote:
Hi all,
I am using rtlinux 2.2 and have come across a couple of problems...
When I try to get the sound example program going (by make; make test
as root) I get the error message "permission denied" when the line
'cat linus.au /dev/rtf3' executes. Any ideas why this should be?
ls -l /dev/rtf3 returns
crw-rw-rw- 1 root root 150, 3 Apr 19 2000 /dev/rtf3
I am developing my own module which uses interrupts 5 and 7. I think
I have enabled interrupt 7 correctly as folowing (STATUS_INT is defined
as 7):
#ifdef USE_INTS
case 4 :// mdp_enbl_stint
rtl_no_interrupts(old_irq_state);
// debug = rtl_request_global_irq(STATUS_INT, status_handler);
debug = rtl_request_irq(STATUS_INT, status_handler);
if(debug == 0) {
rtl_hard_enable_irq(STATUS_INT);
// next line initializes own hardware card
outb(ST_STAT_WR_CLR_STIRQ_B | ST_STAT_WR_EN_STIRQ_B, ST_STAT_RW);
rtl_allow_interrupts();
}
rtl_restore_interrupts(old_irq_state);
#ifdef DEBUG
rtl_printf("CONTROL_HANDLER: status int %d\n", debug);
#endif
break;
A logic analyser trace tells me that the interrupt is being generated by
the hardware under test in the isa slot but is not being picked up by rtl.
In the bios I have reserved interrupts 5 7 as ISA legacy.
I have tried rtl_request_global_irq and rtl_request_irq with no joy.
Can anyone point me in the right direction?
TIA
Cheers,
Matt W.
--
--
Matthew Whillock
[EMAIL PROTECTED] Dept. of Space and Climate Physics,
Tel: +44 1483 204181 Mullard Space Science Laboratory,
Fax: +44 1483 278312 University College London.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
[rtl] interrupts
Hi all,
I am using rtlinux 2.2 and have come across a couple of problems...
When I try to get the sound example program going (by make; make test
as root) I get the error message "permission denied" when the line
'cat linus.au /dev/rtf3' executes. Any ideas why this should be?
ls -l /dev/rtf3 returns
crw-rw-rw- 1 root root 150, 3 Apr 19 2000 /dev/rtf3
I am developing my own module which uses interrupts 5 and 7. I think
I have enabled interrupt 7 correctly as folowing (STATUS_INT is defined
as 7):
#ifdef USE_INTS
case 4 :// mdp_enbl_stint
rtl_no_interrupts(old_irq_state);
// debug = rtl_request_global_irq(STATUS_INT, status_handler);
debug = rtl_request_irq(STATUS_INT, status_handler);
if(debug == 0) {
rtl_hard_enable_irq(STATUS_INT);
// next line initializes own hardware card
outb(ST_STAT_WR_CLR_STIRQ_B | ST_STAT_WR_EN_STIRQ_B, ST_STAT_RW);
rtl_allow_interrupts();
}
rtl_restore_interrupts(old_irq_state);
#ifdef DEBUG
rtl_printf("CONTROL_HANDLER: status int %d\n", debug);
#endif
break;
A logic analyser trace tells me that the interrupt is being generated by
the hardware under test in the isa slot but is not being picked up by rtl.
In the bios I have reserved interrupts 5 7 as ISA legacy.
I have tried rtl_request_global_irq and rtl_request_irq with no joy.
Can anyone point me in the right direction?
TIA
Cheers,
Matt W.
--
Matthew Whillock
[EMAIL PROTECTED] Dept. of Space and Climate Physics,
Tel: +44 1483 204181 Mullard Space Science Laboratory,
Fax: +44 1483 278312 University College London.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
--
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
2. How can I find out which interrupt triggered the handler function ?
Very good question ! I was searching once and I was not able to find an
answer.
Define a capture function for each irq
catch_irq_10( ...){ common_irq(10); ...}
Why this would be necessary?
Three lines below you wrote, that isr routine CAN identify
the irq number. (And so use I it for a year.)
Regards
Gabor
Or, in V3 RTLinux us the sigaction call to install a handler and the
first argument is the irq#, or, in earlier versions of RTLinux
use rtl_request_irq and the first argument is the irq#, or you can
can extract the signal number from the pt_regs argument -- in x86 it is in
the eax field.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
On Tue, 25 Jul 2000 [EMAIL PROTECTED] wrote: 1. Can I use one funtion several times as interupt handler ? Yes, you can. 2. How can I find out which interrupt triggered the handler function ? Very good question ! I was searching once and I was not able to find an answer. Best regards, -- Tomek -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
IO boards usually have a status register that shows wether new data has arrived. If all your boards are on the same interrupt line, your routine should check every board for a status change and service each board that has data (in case multiple boards generated interrupts). Then you probably have to reset the status, although sometimes reading the data takes care of that. If the boards are on different interrupts, you can install the same routine on all - they will not interfere since the interrupt service routine (ISR) is uninterruptible. If your ISR is rather long, you should consider writing a top and bottom half and you will need to maintain seperate data for the bottom half for the different boards. So in short: yes and status register. Willem [EMAIL PROTECTED] wrote: Hello all, the next question may be stupid, but I just couldnt figure out how to do it :) I have several digital IO cards of the same type, all with interrupts enabled, and I want to use one handling function for all cards, with multiple calls to rt_request_global_irq. My question is: 1. Can I use one funtion several times as interupt handler ? 2. How can I find out which interrupt triggered the handler function ? Thanks in advance, Marco Schwarz. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/ -- ~~ Willem J. Atsma -[EMAIL PROTECTED] url: http://www.mech.ubc.ca/~watsma ~~ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
On Tue, Jul 25, 2000 at 07:15:43PM +0200, Tomasz Motylewski wrote:
On Tue, 25 Jul 2000 [EMAIL PROTECTED] wrote:
1. Can I use one funtion several times as interupt handler ?
Yes, you can.
2. How can I find out which interrupt triggered the handler function ?
Very good question ! I was searching once and I was not able to find an
answer.
Define a capture function for each irq
catch_irq_10( ...){ common_irq(10); ...}
Or, in V3 RTLinux us the sigaction call to install a handler and the
first argument is the irq#, or, in earlier versions of RTLinux
use rtl_request_irq and the first argument is the irq#, or you can
can extract the signal number from the pt_regs argument -- in x86 it is in
the eax field.
Best regards,
--
Tomek
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
--
-
Victor Yodaiken
FSMLabs: www.fsmlabs.com www.rtlinux.com
FSMLabs is a servicemark and a service of
VJY Associates L.L.C, New Mexico.
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
1. Yes, you can use a single ISR for every device in the system, assuming that you can tell which one generated the interrupt. 2. That depends on the card. Some cards have a bit which identifies a pending interrupt request. If so, you just read registers sequentially through a list until you find one that has that bit set. Depending on timing, you can find no bits set too, but don't necessarily treat that as an error condition if your ISR scans the whole list and services any pending IRQ's. If there's no interrupt-pending bit on your cards, you could do a hardware hack to feed all of the IRQ-lines into a new card which does a large AND or OR or NAND or NOR (depending on the logic of the line and the bus) and presents a single IRQ to the bus and at the same time remembers this in a clocked register which could be read by the ISR. Norm At 06:15 PM 7/25/2000 +0200, [EMAIL PROTECTED] wrote: Hello all, the next question may be stupid, but I just couldnt figure out how to do it :) I have several digital IO cards of the same type, all with interrupts enabled, and I want to use one handling function for all cards, with multiple calls to rt_request_global_irq. My question is: 1. Can I use one funtion several times as interupt handler ? 2. How can I find out which interrupt triggered the handler function ? Thanks in advance, Marco Schwarz. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/ -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
On Tue, Jul 25, 2000 at 05:25:40PM -0600, [EMAIL PROTECTED] wrote: On Tue, Jul 25, 2000 at 02:07:20PM -0700, David Schleef wrote: Why don't you just use a Linux-like void *dev_id? Is it the migration difficulties in changing function prototypes, or is there some fundamental reason? The lack of a callback handle really makes writing correct drivers a pain. sigaction provides the irq# -- so if you want that information, use the sigaction interface. I'd rather make the RTLinux environment look like Posix threads than like the interior of the Linux kernel. The interior Linux kernel is much more complex, much less familiar, and guaranteed to be not stable. I think it is a fundamental error to use Linux internal operations as an API. I agree about the inherint long-term stability of Linux interfaces (except that the irq prototype hasn't been changed since 1.1.17.) But not having Linux-like interfaces available means that it is much more difficult to port drivers from Linux to RTLinux. But I don't see the problem even with the rtl_request_irq interface. After all, it is a one line function to provide the functionality you want. Am I missing something? Maybe you can give me an example. It takes about 30 lines to get dev_id functionality. The irq number has to be converted to a dev_id using a lookup table, which means that you have to have functions to add/remove entries to/from the lookup table as well as the ISR wrapper. Even with this, you can't share interrupts because the irq is not unique. If you want the full cruft, look at the comedi source. Note that the RTL V1 prototype (void isr(void)) makes it completely impossible to have multiple devices using the same driver. I don't really care whether or not RTLinux supports dev_id, since the code in Comedi works as it is. I just copy the same code to new projects as necessary. dave... -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
On Thu, Jun 22, 2000 at 03:29:23PM +0100, Stuart Hughes wrote: What is a good complaint ??? doesn't the 'P' in POSIX stand for portable ? What you continually offer is non-portable extensions that make it impossible to run the same code on any environment other than RTLinux. Continually? Really, the API has been pretty dull for nearly a year. But RTLinux _is_ different than other environments. A better idea might be to use what exists so that we all have a chance of running our code on a number of operating systems. May I suggest that a SIGHUP may be construed as a wakeup signal to a thread (it has been used context before), this may be bogus too, but you get the idea: try to use something that has a chance of being portable. SIGHUP is fine. Actually, WAKEUP is defined as 1 so SIGHUP will do the same thing. I'm not sure if it is better, however, to pretend that we are doing something you can do in Chorus or PSOS. After all, you are sending an interrupt from the RTkernel to a Linux subthread and this is not something that "exists" or can be done on other operating systems. We've had this discussion before and I remain convinced (under the delusion?) that there are two different needs: 1. Pedal to metal, simple and appropriate APIs for RTLinux specific code: for this I like our LightWeight POSIX PThreads. Needs some fleshing out, but the technical soundness and coherency seem to me to have been proven out. 2. Compatibility libraries that make it easy to move code from legacy operating systems. What I most definitely do not want to do is to re-discover all the errors and ugliness in Chorus that made me want to have RTLinux in the first place. I realize that people who have huge Chorus or PSOS or ... programs will find it inconvenient that RTLinux native programs, designed using our idea of decoupling RT and non-RT will greatly outperform their code, but my theory is that the RTLinux approach to RT is fundamentally _better_ than prior programming models and I don't see any way to magically repair the damage created by mixing RT with non-RT in one incoherent mass of code. -- - Victor Yodaiken FSMLabs: www.fsmlabs.com www.rtlinux.com FSMLabs is a servicemark and a service of VJY Associates L.L.C, New Mexico. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
[rtl] Interrupts in another aspect
First of all I don't want to take sides in this hot debate. I'm interested in merely technial issues. You have a choice. a) enter ISR, wakeup thread, thread code runs, return to ISR, exit ISR pthread_wakeup_np(thread) if "thread" is higher priority than the current thread, whatever it may be, then we switch and run the thread, and return to this thread later and then exit the ISR. or: b) enter ISR, wakeup thread, exit ISR, thead code runs. pthread_kill(thread,RTL_SIG_WAKEUP) or pthread_mutex_unlock(m); executes pthread_kill on all waiting threads. But _when_ the scheduler will actually start the signalled thread? Is there any guarantee, that immediately at exit of ISR a rescheduling occurs? I'm saying that b) is more conventional, and I would like to have this facility available. Personally I think the concept of "interrupt routines are pseudo-threads with random priority" is not fortunate enough. Did I misunderstand something? AFAIK when an interrupt occurs its handler is started as an implicit thread inheriting its priority from the interrupted thread. The most possible interrupted thread is the the Linux itself which has minus infinite priority. That means that an ISR will run probably the lowest priority. OK, I accept the "ISR is a thread" concept. But why can't I set thread attributes? These routines might be ordinary threads and its ISR nature might be just an attribute. pthread_create would not start them immediately but they wait for the specified IRQ. If scheduler can start a thread with inherited priority it would do the same with predefined priority. Regards Gabor -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts in another aspect
Hi Gabor, [EMAIL PROTECTED] wrote: Personally I think the concept of "interrupt routines are pseudo-threads with random priority" is not fortunate enough. Did I misunderstand something? AFAIK when an interrupt occurs its handler is started as an implicit thread inheriting its priority from the interrupted thread. The most possible interrupted thread is the the Linux itself which has minus infinite priority. That means that an ISR will run probably the lowest priority. No, this is not a good assumption. Classically, an interrupt handler has a *hardware* priority, this is unrelated to the concept of the priority of threads. Usually, when an interrupt occurs, it interrrupts whatever is running provided that a) interrupts are enabled, b) if currently in an ISR, the hardware priority of the new interrupt is higher than the current interrupt priority (implementation is architecture dependant). This is why you should picture interrupts in a separate way to thread priority. Thread priority is implemented purely by the software scheduler (it decides which thread should run based on data in a per-thread structure). Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts in another aspect
Personally I think the concept of "interrupt routines are pseudo-threads with random priority" is not fortunate enough. I mean the _current_ concept. Did I misunderstand something? AFAIK when an interrupt occurs its handler is started as an implicit thread inheriting its priority from the interrupted thread. The most possible interrupted thread is the the Linux itself which has minus infinite priority. That means that an ISR will run probably the lowest priority. No, this is not a good assumption. Classically, an interrupt handler has Not good, but better than the current. a *hardware* priority, this is unrelated to the concept of the priority of threads. Usually, when an interrupt occurs, it interrrupts whatever is running provided that a) interrupts are enabled, b) if currently in an ISR, the hardware priority of the new interrupt is higher than the current interrupt priority (implementation is architecture dependant). This is your wish or the reality? ;-) We were speaking so far, that ISRs run long because threads awaken by them grabs the CPU. Now I have such an ISR. There can be occur such a situation, that it runs in two instances because the first one is delayed by a high priority thread, meanwhile the hardware IRQ is delivered again. Remember what Victor wrote: | You have a choice. | | | a) enter ISR, wakeup thread, thread code runs, return to ISR, exit ISR | | | pthread_wakeup_np(thread) | if "thread" is higher priority than the current thread, whatever | it may be, then we switch and run the thread, and return to this | thread later and then exit the ISR. | I repeat: "current thread" is generally has extreme low priority. (I.e. usually this is the Linux.) Therefore any other thread (waken up by ISR) will run sooner than ISR could exit. When I say ISR I mean the handler installed by rtl_request_irq(). Regards Gabor -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts in another aspect
Hi Gabor, [EMAIL PROTECTED] wrote: a *hardware* priority, this is unrelated to the concept of the priority of threads. Usually, when an interrupt occurs, it interrrupts whatever is running provided that a) interrupts are enabled, b) if currently in an ISR, the hardware priority of the new interrupt is higher than the current interrupt priority (implementation is architecture dependant). This is your wish or the reality? ;-) I think there is a miscommunication here. If you mean the 'current' as in Linux terms (e.g current-pid) then yes of course that may refer to a low priory (Linux) task/process. What I say above *is* reality, but I'm not referring to Linux in particular. I'm trying to point out that generally there is a marked difference in context between a true interrupt handler, and that which it interrupts (provided it is not already in an ISR). We were speaking so far, that ISRs run long because threads awaken by them grabs the CPU. I think I understand ? What was being said is that if you are in an hard interrupt handler, and you use pthread_wakeup_np (or similar in RTAI) to call the scheduler, the new RT thread runs before you exit the ISR. Victor was saying that depending an what you call, you can change the behavior to let the ISR finish and then have the RT task/thread run (pthread_mutex_unlock), this may be what you need. Now I have such an ISR. There can be occur such a situation, that it runs in two instances because the first one is delayed by a high priority thread, meanwhile the hardware IRQ is delivered again. You need to make sure that the thread is outside ISR context (I think ?). Fundamentally you need to make sure that you have time to complete the thread work before the next re-run request occurs (is that correct ?, I'm guessing you want to avoid reentrancy) Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts in another aspect
Dear Stuart, a *hardware* priority, this is unrelated to the concept of the priority of threads. Usually, when an interrupt occurs, it interrrupts whatever is running provided that a) interrupts are enabled, b) if currently in an ISR, the hardware priority of the new interrupt is higher than the current interrupt priority (implementation is architecture dependant). This is your wish or the reality? ;-) I think there is a miscommunication here. If you mean the 'current' as in Linux terms (e.g current-pid) then yes of course that may refer to a low priory (Linux) task/process. No. 'current' means the actual version of RT-Linux (2.x). difference in context between a true interrupt handler, and that which it interrupts (provided it is not already in an ISR). I speak about RT-Linux hard interrupt handlers. We were speaking so far, that ISRs run long because threads awaken by them grabs the CPU. I think I understand ? What was being said is that if you are in an hard interrupt handler, and you use pthread_wakeup_np (or similar in RTAI) to call the scheduler, the new RT thread runs before you exit the ISR. Yes, this is the situation. Victor was saying that depending an what you call, you can change the behavior to let the ISR finish and then have the RT task/thread run (pthread_mutex_unlock), this may be what you need. I use a "library function" that calls pthread_wakeup_np(). I do not want to rewrite everything. Now I have such an ISR. There can be occur such a situation, that it runs in two instances because the first one is delayed by a high priority thread, meanwhile the hardware IRQ is delivered again. You need to make sure that the thread is outside ISR context (I think All of my threads are interrupt driven. ?). Fundamentally you need to make sure that you have time to complete the thread work before the next re-run request occurs (is that correct ?, I'm guessing you want to avoid reentrancy) There is no time for it. However reentrancy is not a problem. I just dislike the concept. Sorry if I was confusing. I wrote my mail not for asking help to solve a given problem but I suggested a possible improvement of RTLinux IRQ handling scheme. Is this forum is not adequate for discussing principal issues? ;-) (My program works well since I realized what happens.) Regards Gabor -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts in another aspect
[EMAIL PROTECTED] wrote: I think there is a miscommunication here. If you mean the 'current' as in Linux terms (e.g current-pid) then yes of course that may refer to a low priory (Linux) task/process. No. 'current' means the actual version of RT-Linux (2.x). Ok, got it now :-) I think I understand ? What was being said is that if you are in an hard interrupt handler, and you use pthread_wakeup_np (or similar in RTAI) to call the scheduler, the new RT thread runs before you exit the ISR. Yes, this is the situation. Victor was saying that depending an what you call, you can change the behavior to let the ISR finish and then have the RT task/thread run (pthread_mutex_unlock), this may be what you need. I use a "library function" that calls pthread_wakeup_np(). I do not want to rewrite everything. Tricky, I'm not sure what your options are. Sorry if I was confusing. It's all clear now. I wrote my mail not for asking help to solve a given problem but I suggested a possible improvement of RTLinux IRQ handling scheme. Is this forum is not adequate for discussing principal issues? ;-) I think its a good forum for this. (My program works well since I realized what happens.) Well I think by now most people will know what to expect after all these mails :-) Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts in another aspect
Ther are two possibilities that occur to me: 1) pthread_delayed_reseched something that won't annoy Stuart that does run the scheduler to see if a higher priority thread is ready and to force a resched when any ISR exits, if this is true. e.g. isr does pthread_kill pthread_delayed_resched 2) Implement the Pthreads "execute the signal handler as a thread" idea. On Fri, Jun 23, 2000 at 04:47:01PM +0200, [EMAIL PROTECTED] wrote: Personally I think the concept of "interrupt routines are pseudo-threads with random priority" is not fortunate enough. I mean the _current_ concept. Did I misunderstand something? AFAIK when an interrupt occurs its handler is started as an implicit thread inheriting its priority from the interrupted thread. The most possible interrupted thread is the the Linux itself which has minus infinite priority. That means that an ISR will run probably the lowest priority. No, this is not a good assumption. Classically, an interrupt handler has Not good, but better than the current. a *hardware* priority, this is unrelated to the concept of the priority of threads. Usually, when an interrupt occurs, it interrrupts whatever is running provided that a) interrupts are enabled, b) if currently in an ISR, the hardware priority of the new interrupt is higher than the current interrupt priority (implementation is architecture dependant). This is your wish or the reality? ;-) We were speaking so far, that ISRs run long because threads awaken by them grabs the CPU. Now I have such an ISR. There can be occur such a situation, that it runs in two instances because the first one is delayed by a high priority thread, meanwhile the hardware IRQ is delivered again. Remember what Victor wrote: | You have a choice. | | | a) enter ISR, wakeup thread, thread code runs, return to ISR, exit ISR | | | pthread_wakeup_np(thread) | if "thread" is higher priority than the current thread, whatever | it may be, then we switch and run the thread, and return to this | thread later and then exit the ISR. | I repeat: "current thread" is generally has extreme low priority. (I.e. usually this is the Linux.) Therefore any other thread (waken up by ISR) will run sooner than ISR could exit. When I say ISR I mean the handler installed by rtl_request_irq(). Regards Gabor -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/ -- - Victor Yodaiken FSMLabs: www.fsmlabs.com www.rtlinux.com FSMLabs is a servicemark and a service of VJY Associates L.L.C, New Mexico. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
Victor Yodaiken wrote: On Tue, Jun 20, 2000 at 09:54:18AM -0700, Pascal Charest wrote: Hi, So, if I can't call Linux interrupt handler within an RTAI handler, can I use two independant handlers ; one from RTAI and the other from Linux? It is trivial to call a Linux interrupt handler from RTLinux. But in RTLinux you do: pthread_kill(rtl_get_linux_thread(cpunumber), RTL_LINUX_MIN_SIGNAL+irq) in pre 2.3 you need the simpler seeming, but nonstandard: rtl_global_pend_irq(irq); Hi Victor, pthread_kill may be standard, but AFAIK the signal you use here is not. Is this just not a 'smoke and mirrors' approach to appear like you are following the POSIX standard ?? If I'm wrong, please accept my apologies, if I'm right then shouldn't we *all* try to come up with an existing standard way that can be implemented for RTLinux/RTAI ?? Regards, Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
On Thu, Jun 22, 2000 at 11:49:52AM +0100, Stuart Hughes wrote: Victor Yodaiken wrote: On Tue, Jun 20, 2000 at 09:54:18AM -0700, Pascal Charest wrote: Hi, So, if I can't call Linux interrupt handler within an RTAI handler, can I use two independant handlers ; one from RTAI and the other from Linux? It is trivial to call a Linux interrupt handler from RTLinux. But in RTLinux you do: pthread_kill(rtl_get_linux_thread(cpunumber), RTL_LINUX_MIN_SIGNAL+irq) in pre 2.3 you need the simpler seeming, but nonstandard: rtl_global_pend_irq(irq); Hi Victor, pthread_kill may be standard, but AFAIK the signal you use here is not. That is because having Linux run as a thread is unique to RTLinux. Our aim is not to pretend to be a standard nonrealtime POSIX, but to make the api conform to POSIX standard as far as possible. POSIX permits any number of signals and this extension is therefore within the standard and seems to me to be a sensible extension. If you have a better idea or even a good complaint, I'd be happy to hear it. Is this just not a 'smoke and mirrors' approach to appear like you are following the POSIX standard ?? See above: POSIX mandates pthread_kill and a small number of signals. It explicitly permits other signals. "Following the POSIX standard" does not, according to POSIX, forbid extensions. My philosophy, with the V2 POSIX API is to provide an API that is clear and familiar. What I'd like is that if a new RTL programmer wants to send a signal, she thinks, "hmm, we are in a POSIX threads environment so it must work via pthread_kill or sigqueue, I'll check the man pages". Even if the manpages show a extended pthread_kill, this is much better than, "um, which one of 123 wierd RTOS APIs am I using now? is there a xmit_irq call, a send_sig, a ... ?" RTLinux provides a novel programming environment and hard realtime is itself different from standard programming environments. So new programmers have an adjustment that is inescapable if they are going to make good use of the system. By setting ourselves in the Pthread environment, we minimize the adjustment and, I hope, we make the API coherent instead of a patchwork of "hey, let's add a functions that does ...". If I'm wrong, please accept my apologies, if I'm right then shouldn't we *all* try to come up with an existing standard way that can be implemented for RTLinux/RTAI ?? Good ideas are in short supply. If you have 'em, I'd like to hear them. -- - Victor Yodaiken FSMLabs: www.fsmlabs.com www.rtlinux.com FSMLabs is a servicemark and a service of VJY Associates L.L.C, New Mexico. -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
[EMAIL PROTECTED] wrote: On Thu, Jun 22, 2000 at 11:49:52AM +0100, Stuart Hughes wrote: Victor Yodaiken wrote: Hi Victor, pthread_kill may be standard, but AFAIK the signal you use here is not. That is because having Linux run as a thread is unique to RTLinux. Our aim is not to pretend to be a standard nonrealtime POSIX, but to make the api conform to POSIX standard as far as possible. POSIX permits any number of signals and this extension is therefore within the standard and seems to me to be a sensible extension. If you have a better idea or even a good complaint, I'd be happy to hear it. What is a good complaint ??? doesn't the 'P' in POSIX stand for portable ? What you continually offer is non-portable extensions that make it impossible to run the same code on any environment other than RTLinux. A better idea might be to use what exists so that we all have a chance of running our code on a number of operating systems. May I suggest that a SIGHUP may be construed as a wakeup signal to a thread (it has been used context before), this may be bogus too, but you get the idea: try to use something that has a chance of being portable. Regards Stuart -- [rtl] --- To unsubscribe: echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED] --- For more information on Real-Time Linux see: http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
JunHyeok Heo wrote:
Hi! pascal.
First of all, I am sorry for missing your first letter and i had no experience of
RTAI.
I am going to explain what i am thinking as a solution in case of RTL.
I hope you can use RTL instead of RTAI.
You can do this in either system in almost the same way
But the following method is not verified.
1. Install your linux interrupt handler as a soft interrupt handler using
'rtl_get_soft_irq()'
2. In real-time interrupt handler, use 'rtl_global_pend_irq()' to call your linux
interrupt handler.
For RTAI (as Karim said)
rt_request_linux_irq()
rt_pend_linux_irq()
Regards, Stuart
- Original Message -
From: "Pascal Charest" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 21, 2000 1:54 AM
Subject: Re: [rtl] Interrupts
Hi,
So, if I can't call Linux interrupt handler within an RTAI handler, can
I use two independant handlers ; one from RTAI and the other from Linux?
I've a driver that uses Linux interrupt handler. Then, I want a
realtime process that is calling by the same interrupt. When I'm using
rt_request_global_irq() and doing nothing in my handler, the system
restart or all is ok ; it depends of the Linux driver I use.
How can I activate, if I can, Linux handler using the same irq? I've
used rt_pend_linux_irq() in my handler but it may crash too.
Pascal
Charest
Karim Yaghmour wrote:
Hello Pascal,
I beleive the problem comes from the fact that you are calling the
Linux interrupt handler from within an RTAI handler. Since Linux
interrupt handlers might call on lock mechanisms redirected by
RTAI, this is where things get messy.
Rather than using rt_request_global_irq(), try using rt_request_linux_irq().
What this will do is add your handler to the list of handlers linux
will call when the IRQ happens. Therefore, the normal handler gets
called and so does yours. Your handler can then use RTAI locking
mechanisms to do it's work.
This is actually currently used from within the RTAI schedulers to
try recovering lost jiffies (this is from start_rt_timer in the upscheduler):
rt_request_linux_irq(TIMER_8254_IRQ, recover_jiffies, "rtai_sched",
recover_jiffies);
The recover_jiffies function now gets called every time a timer
interrupt gets to Linux.
J'espere que ca pourra vous aider ...
Karim
Pascal Charest wrote:
Hi,
I'm trying to catch interruptions with rtai and forcing the linux
interrupt handler, but I don't know how to do it correctly. In fact, I
want to use different drivers with my rt_process and to make them
realtime without changing their code. There is a example of what I want
to do :
void handler(int irq)
{
... forcing linux interrupt handler
... doing my own work
}
int init_module()
{
...
rt_request_global_irq(IRQ, (void*)handler);
rt_startup_irq(IRQ);
...
}
When I try something, linux stops or the computer restarts when the
interrupt occurs ; it depends of the rt fonctions I use in my handler.
Do someone know how to do it?
Thanks in advance,
Pascal Charest
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
Hi! pascal.
First of all, I am sorry for missing your first letter and i had no experience of RTAI.
I am going to explain what i am thinking as a solution in case of RTL.
I hope you can use RTL instead of RTAI.
But the following method is not verified.
1. Install your linux interrupt handler as a soft interrupt handler using
'rtl_get_soft_irq()'
2. In real-time interrupt handler, use 'rtl_global_pend_irq()' to call your linux
interrupt handler.
- Original Message -
From: "Pascal Charest" [EMAIL PROTECTED]
To: [EMAIL PROTECTED]
Sent: Wednesday, June 21, 2000 1:54 AM
Subject: Re: [rtl] Interrupts
Hi,
So, if I can't call Linux interrupt handler within an RTAI handler, can
I use two independant handlers ; one from RTAI and the other from Linux?
I've a driver that uses Linux interrupt handler. Then, I want a
realtime process that is calling by the same interrupt. When I'm using
rt_request_global_irq() and doing nothing in my handler, the system
restart or all is ok ; it depends of the Linux driver I use.
How can I activate, if I can, Linux handler using the same irq? I've
used rt_pend_linux_irq() in my handler but it may crash too.
Pascal
Charest
Karim Yaghmour wrote:
Hello Pascal,
I beleive the problem comes from the fact that you are calling the
Linux interrupt handler from within an RTAI handler. Since Linux
interrupt handlers might call on lock mechanisms redirected by
RTAI, this is where things get messy.
Rather than using rt_request_global_irq(), try using rt_request_linux_irq().
What this will do is add your handler to the list of handlers linux
will call when the IRQ happens. Therefore, the normal handler gets
called and so does yours. Your handler can then use RTAI locking
mechanisms to do it's work.
This is actually currently used from within the RTAI schedulers to
try recovering lost jiffies (this is from start_rt_timer in the upscheduler):
rt_request_linux_irq(TIMER_8254_IRQ, recover_jiffies, "rtai_sched",
recover_jiffies);
The recover_jiffies function now gets called every time a timer
interrupt gets to Linux.
J'espere que ca pourra vous aider ...
Karim
Pascal Charest wrote:
Hi,
I'm trying to catch interruptions with rtai and forcing the linux
interrupt handler, but I don't know how to do it correctly. In fact, I
want to use different drivers with my rt_process and to make them
realtime without changing their code. There is a example of what I want
to do :
void handler(int irq)
{
... forcing linux interrupt handler
... doing my own work
}
int init_module()
{
...
rt_request_global_irq(IRQ, (void*)handler);
rt_startup_irq(IRQ);
...
}
When I try something, linux stops or the computer restarts when the
interrupt occurs ; it depends of the rt fonctions I use in my handler.
Do someone know how to do it?
Thanks in advance,
Pascal Charest
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
[rtl] Interrupts
Hi,
I'm trying to catch interruptions with rtai and forcing the linux
interrupt handler, but I don't know how to do it correctly. In fact, I
want to use different drivers with my rt_process and to make them
realtime without changing their code. There is a example of what I want
to do :
void handler(int irq)
{
... forcing linux interrupt handler
... doing my own work
}
int init_module()
{
...
rt_request_global_irq(IRQ, (void*)handler);
rt_startup_irq(IRQ);
...
}
When I try something, linux stops or the computer restarts when the
interrupt occurs ; it depends of the rt fonctions I use in my handler.
Do someone know how to do it?
Thanks in advance,
Pascal Charest
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
Re: [rtl] Interrupts
Hello Pascal,
I beleive the problem comes from the fact that you are calling the
Linux interrupt handler from within an RTAI handler. Since Linux
interrupt handlers might call on lock mechanisms redirected by
RTAI, this is where things get messy.
Rather than using rt_request_global_irq(), try using rt_request_linux_irq().
What this will do is add your handler to the list of handlers linux
will call when the IRQ happens. Therefore, the normal handler gets
called and so does yours. Your handler can then use RTAI locking
mechanisms to do it's work.
This is actually currently used from within the RTAI schedulers to
try recovering lost jiffies (this is from start_rt_timer in the upscheduler):
rt_request_linux_irq(TIMER_8254_IRQ, recover_jiffies, "rtai_sched", recover_jiffies);
The recover_jiffies function now gets called every time a timer
interrupt gets to Linux.
J'espere que ca pourra vous aider ...
Karim
Pascal Charest wrote:
Hi,
I'm trying to catch interruptions with rtai and forcing the linux
interrupt handler, but I don't know how to do it correctly. In fact, I
want to use different drivers with my rt_process and to make them
realtime without changing their code. There is a example of what I want
to do :
void handler(int irq)
{
... forcing linux interrupt handler
... doing my own work
}
int init_module()
{
...
rt_request_global_irq(IRQ, (void*)handler);
rt_startup_irq(IRQ);
...
}
When I try something, linux stops or the computer restarts when the
interrupt occurs ; it depends of the rt fonctions I use in my handler.
Do someone know how to do it?
Thanks in advance,
Pascal Charest
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
--
===
Karim Yaghmour
[EMAIL PROTECTED]
Operating System Consultant
(Linux kernel, real-time and distributed systems)
===
-- [rtl] ---
To unsubscribe:
echo "unsubscribe rtl" | mail [EMAIL PROTECTED] OR
echo "unsubscribe rtl Your_email" | mail [EMAIL PROTECTED]
---
For more information on Real-Time Linux see:
http://www.rtlinux.org/rtlinux/
