* RE: [ECOS] generating interrupts in ARM-PID (SID simulator) [not found] <20030627094625.GN341@biferten.ma.tech.ascom.ch> @ 2003-06-27 13:40 ` Robert Cragie 2003-07-01 20:50 ` Partha Palit 0 siblings, 1 reply; 4+ messages in thread From: Robert Cragie @ 2003-06-27 13:40 UTC (permalink / raw) To: Andrew Lunn, Partha Palit; +Cc: ECOS, SID > > I am trying to generate external interrupts and handle > > it on a ARM-PID configuration. I am using SID as the > > simulator for ARM PID.Ofcourse, eCos is my RTOS. > > > > >From the SID configuration file, I understand that > > there is a interrupt controller which can be > > associated with 32 interrupts.One of the output pins > > of the interrupt controler is connected to the "nirq" > > pin of the processor. > > I use one the the interrutpt sources numbered "16" to > > associate with an event whose occurance I want to > > count. Only interrupts up to 15 can be handled by the interrupt controller (well, according to the PID manual anyway). Try connecting to interrupt number 11. This corresponds to the ASB0 interrupt, which seems to be unconnected in SID. So in configrun-sid: connect-pin sensor-sched 1-event -> intrctrl source-11 However, note that the inputs to the ARM interrupt controller are level interrupts. If the scheduler generates a pulse, it could either get missed (short pulse) or cause continuous interruption problems (long pulse). So ideally in either case you'd want to latch the rising edge of the scheduler output and have some mechanism to clear the it in the DSR somehow. I'm not sure how you'd do this is SID, though. > > Now, the problem is that I am unable to catch the > > interrupt and process it using an ISR. Specifically, I > > register my own ISR at the the vector 16. However, it > > seems that I am unable to catch the interrupt. > > > > Could anyone kindly advise where I am making the > > mistake? Also, I m unable to figure out that if and > > how eCos can be configured to use the 32 interrupts. > > Afterall, there is only one nirq line. How are the 32 > > interrupts mapped? When, I check the hal_intr.h file, > > I find that at max there can be 8 interrupts. Try something like the following to add a handler for interrupt number 11 (ASB0): #include <cyg/kernel/kapi.h> #include <cyg/hal/hal_intr.h> /* IRQ handler object */ typedef struct tagIRQ_s { CYG_WORD tNum; cyg_interrupt sIRQrsrc; cyg_handle_t hIRQ; } IRQ_s; static IRQ_s s_sMyIRQ; /* snip */ cyg_uint32 myISR(cyg_vector_t tVector, cyg_addrword_t tData) { /* Nothing to do in ISR apart from the mandatory procedures */ /* Stop any further interrupts until handled */ cyg_interrupt_mask(tVector); /* Acknowledge to system (this MUST be done) */ cyg_interrupt_acknowledge(tVector); /* Cause DSR to be run */ return CYG_ISR_CALL_DSR; } cyg_uint32 myDSR(cyg_vector_t tVector, cyg_ucount32 u32Count, cyg_addrword_t tData) { /* DO YOUR INTERRUPT PROCESSING HERE */ /* Finally reenable interrupts */ cyg_interrupt_unmask(tVector); } /* snip - somewhere in your initialisation .... */ s_sMyIRQ.tNum = CYGNUM_HAL_INTERRUPT_ASB0; /* 11 */ /* First, create and attach the Interrupt handlers */ cyg_interrupt_create(s_sMyIRQ.tNum, /* Interrupt number */ 99, /* Priority - what goes here? */ (cyg_addrword_t)&s_sMyIRQ, /* Data item passed to interrupt handler - whatever you want */ myISR, /* ISR */ myDSR, /* DSR */ &s_sMyIRQ.hIRQ, /* (ptr. to) Handle - filled in */ &s_sMyIRQ.sIRQrsrc); /* (ptr. to) Resource reqd. by interrupt */ cyg_interrupt_attach(s_sMyIRQ.hIRQ); /* Finally, enable the interrupt */ cyg_interrupt_unmask(s_sMyIRQ.tNum); ----------------------- Hope this helps Robert Cragie, Design Engineer _______________________________________________________________ Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK http://www.jennic.com Tel: +44 (0) 114 281 2655 _______________________________________________________________ ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [ECOS] generating interrupts in ARM-PID (SID simulator) 2003-06-27 13:40 ` [ECOS] generating interrupts in ARM-PID (SID simulator) Robert Cragie @ 2003-07-01 20:50 ` Partha Palit 2003-07-01 23:53 ` Frank Ch. Eigler 2003-07-02 10:10 ` Robert Cragie 0 siblings, 2 replies; 4+ messages in thread From: Partha Palit @ 2003-07-01 20:50 UTC (permalink / raw) To: Robert Cragie, Andrew Lunn; +Cc: ECOS, SID Hello, I am back again with questions on generating interrupt. As recommened by Robert, I tried using the interrupt 11.It seemed to work, but it showed up as spurious interrupt which is not handled by the ARM Hal. I guess this is becuase ARM recognizes level triggered interrupts as pointed out by Robert. -->Q: Could anyone kindly tell how to generate pulses of definite time period using sid-sched? I guess a timer can be used, but in the SID configuration file I see that the timers have inputs from the cpu itself. Is there anything simpler? Also I had to manually generate the interrupt in the SID tksm GUI. Otherwise it was not working. -->Q: What am I doing wrong ? Can the duration of the pulse be controlled in the GUI? Presently, I am just changing the value in the sched-event field..and I get a spurious interrupt. Thanks a lot. -Partha --- Robert Cragie <rcc@jennic.com> wrote: > > > I am trying to generate external interrupts and > handle > > > it on a ARM-PID configuration. I am using SID as > the > > > simulator for ARM PID.Ofcourse, eCos is my RTOS. > > > > > > >From the SID configuration file, I understand > that > > > there is a interrupt controller which can be > > > associated with 32 interrupts.One of the output > pins > > > of the interrupt controler is connected to the > "nirq" > > > pin of the processor. > > > I use one the the interrutpt sources numbered > "16" to > > > associate with an event whose occurance I want > to > > > count. > > Only interrupts up to 15 can be handled by the > interrupt controller (well, > according to the PID manual anyway). Try connecting > to interrupt number 11. > This corresponds to the ASB0 interrupt, which seems > to be unconnected in > SID. > > So in configrun-sid: > > connect-pin sensor-sched 1-event -> intrctrl > source-11 > > However, note that the inputs to the ARM interrupt > controller are level > interrupts. If the scheduler generates a pulse, it > could either get missed > (short pulse) or cause continuous interruption > problems (long pulse). So > ideally in either case you'd want to latch the > rising edge of the scheduler > output and have some mechanism to clear the it in > the DSR somehow. I'm not > sure how you'd do this is SID, though. > > > > Now, the problem is that I am unable to catch > the > > > interrupt and process it using an ISR. > Specifically, I > > > register my own ISR at the the vector 16. > However, it > > > seems that I am unable to catch the interrupt. > > > > > > Could anyone kindly advise where I am making the > > > mistake? Also, I m unable to figure out that if > and > > > how eCos can be configured to use the 32 > interrupts. > > > Afterall, there is only one nirq line. How are > the 32 > > > interrupts mapped? When, I check the hal_intr.h > file, > > > I find that at max there can be 8 interrupts. > > Try something like the following to add a handler > for interrupt number 11 > (ASB0): > > #include <cyg/kernel/kapi.h> > #include <cyg/hal/hal_intr.h> > > /* IRQ handler object */ > > typedef struct tagIRQ_s > { > CYG_WORD tNum; > cyg_interrupt sIRQrsrc; > cyg_handle_t hIRQ; > } IRQ_s; > > static IRQ_s s_sMyIRQ; > > /* snip */ > > cyg_uint32 myISR(cyg_vector_t tVector, > cyg_addrword_t tData) > { > /* Nothing to do in ISR apart from the mandatory > procedures */ > > /* Stop any further interrupts until handled */ > cyg_interrupt_mask(tVector); > > /* Acknowledge to system (this MUST be done) */ > cyg_interrupt_acknowledge(tVector); > > /* Cause DSR to be run */ > return CYG_ISR_CALL_DSR; > } > > cyg_uint32 myDSR(cyg_vector_t tVector, cyg_ucount32 > u32Count, cyg_addrword_t > tData) > { > /* DO YOUR INTERRUPT PROCESSING HERE */ > > /* Finally reenable interrupts */ > cyg_interrupt_unmask(tVector); > } > > /* snip - somewhere in your initialisation .... */ > > s_sMyIRQ.tNum = CYGNUM_HAL_INTERRUPT_ASB0; /* 11 > */ > > /* First, create and attach the Interrupt > handlers */ > cyg_interrupt_create(s_sMyIRQ.tNum, > /* Interrupt number > */ > 99, > /* Priority - what > goes here? */ > (cyg_addrword_t)&s_sMyIRQ, > /* Data item passed > to interrupt handler - whatever you want */ > myISR, > /* ISR */ > myDSR, > /* DSR */ > &s_sMyIRQ.hIRQ, > /* (ptr. to) > Handle - filled in */ > &s_sMyIRQ.sIRQrsrc); > /* (ptr. to) > Resource reqd. by interrupt */ > > cyg_interrupt_attach(s_sMyIRQ.hIRQ); > > /* Finally, enable the interrupt */ > cyg_interrupt_unmask(s_sMyIRQ.tNum); > > ----------------------- > Hope this helps > > Robert Cragie, Design Engineer > _______________________________________________________________ > Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK > http://www.jennic.com Tel: +44 (0) 114 281 2655 > _______________________________________________________________ > __________________________________ Do you Yahoo!? SBC Yahoo! DSL - Now only $29.95 per month! http://sbc.yahoo.com ^ permalink raw reply [flat|nested] 4+ messages in thread
* Re: [ECOS] generating interrupts in ARM-PID (SID simulator) 2003-07-01 20:50 ` Partha Palit @ 2003-07-01 23:53 ` Frank Ch. Eigler 2003-07-02 10:10 ` Robert Cragie 1 sibling, 0 replies; 4+ messages in thread From: Frank Ch. Eigler @ 2003-07-01 23:53 UTC (permalink / raw) To: Partha Palit; +Cc: ECOS, SID Hi - On Tue, Jul 01, 2003 at 01:50:14PM -0700, Partha Palit wrote: > [...] > As recommened by Robert, I tried using the interrupt > 11.It seemed to work, but it showed up as spurious > interrupt which is not handled by the ARM Hal. I guess > this is becuase ARM recognizes level triggered > interrupts as pointed out by Robert. I would be surprised if that were the case. At the time that the interrupt is first asserted, the OS has no way of knowing whether it was an edge or level type interrupt. If it never even dispatches to your handler, on account of spuriousity, then there is a software problem. I would expect an edge- vs level-triggering problem would show itself by having an interrupt refusing to be masked off. > -->Q: Could anyone kindly tell how to generate pulses > of definite time period using sid-sched? [...] First thing, one must be aware of how sid models signals like this. The basic signalling primitive takes a 32-bit value, and can be interpreted as a pulse, an edge, or an abstract event - the interpretation depends on the sender and receiver. Modules that want to model level-sensitive phenomena sometimes use a 1-valued signal for the leading edge and a 0-valued one for the trailing edge of the entire pulse. It turns out that the scheduler sends a 0-valued abstract signal when an event fires. This does not seem appropriate after all for direct connection to the hw-interrupt-arm/ref inputs, which appears to prefer 1-/0- type signal pairs to delimit pulses. I suspect a reasonable way to go is to extend the scheduler to allow the driven event signal to have a configurable value. Then, one can send a proper 1-valued leading edge of a pulse from the scheduler. (This would require some very minor code extensions to sid/component/sched.) The trailing edge is normally caused by target software action (the interrupt handler acknowledging it), so this could be modelled by use of the hw-glue-probe-bus component. This little widget can be memory-mapped anywhere, and transmits on pins the parameters of an incoming memory access. It could map a "write 0x0 to 0xA8000040" to a single pin event of value 0x0, suitable to connect to the same interrupt controller input. It needs a dummy downstream memory object too: new hw-glue-probe-bus uninterruptor new hw-memory-ram/rom-basic dummy connect-bus cpu-mapper unint:[0xA800040,0xA8000043] uninterruptor upstream connect-pin uninterruptor data-low -> intctrl interrupt-signal-11 set dummy size 4 connect-bus uninterruptor downstream dummy read-write-port connect-pin target-sched 888-event -> intctrl interrupt-signal-11 set target-sched 888-value 1 # not yet implemented set target-sched 888-time 8888 > Also I had to manually generate the interrupt in the > SID tksm GUI. Otherwise it was not working. [...] I'm glad you found your way around the GUI. - FCHE ^ permalink raw reply [flat|nested] 4+ messages in thread
* RE: [ECOS] generating interrupts in ARM-PID (SID simulator) 2003-07-01 20:50 ` Partha Palit 2003-07-01 23:53 ` Frank Ch. Eigler @ 2003-07-02 10:10 ` Robert Cragie 1 sibling, 0 replies; 4+ messages in thread From: Robert Cragie @ 2003-07-02 10:10 UTC (permalink / raw) To: Partha Palit; +Cc: ECOS, SID > As recommened by Robert, I tried using the interrupt > 11.It seemed to work, but it showed up as spurious > interrupt which is not handled by the ARM Hal. I guess > this is becuase ARM recognizes level triggered > interrupts as pointed out by Robert. A spurious interrupt is simply one which is not handled by the software interrupt handling mechanism. It is nothing to do with level or edge-triggered interrupts. All processors essentially work on level-triggered interrupts. An edge-triggered interrupt is where an edge is simply latched to assert a level, and then cleared in a defined way to negate a level, usually by writing to some register. So if you are getting a spurious interrupt, you are at least seeing the interrupt, which is progress. Put a breakpoint on hal_IRQ_handler and see what it's doing. I would guess you are not installing the interrupt handler properly or the numbers are not corresponding or something - did you try the sample source code I included? You could also look at the Interrupt Controller registers on the PID simulator to give you a clue as to what's going on, e.g. reading IRQStatus will tell you active interrupts (i.e. where there is an interrupt and it is also enabled) and reading IRQRawStatus will tell you actual interrupts (i.e. where there is an interrupt even if it is disabled) (note I am assuming the SID model matches this exactly): Address Read Write 0x0A000000 IRQStatus Reserved 0x0A000004 IRQRawStatus Reserved 0x0A000008 IRQEnable IRQEnableSet 0x0A00000C Reserved IRQEnableClear 0x0A000010 Reserved IRQSoft(Programmed IRQ Interrupt) 0x0A000100 FIQStatus Reserved 0x0A000104 FIQRawStatus Reserved 0x0A000108 FIQEnable FIQEnableSet 0x0A00010C Reserved FIQEnableClear 0x0A000110 Reserved Reserved 0x0A000114 FIQSource FIQSource Note that these will normally be manipulated by the HAL when interrupts are enabled/disabled/handled etc. and should not be tampered with unless you are specifically trying to debug something. > -->Q: Could anyone kindly tell how to generate pulses > of definite time period using sid-sched? I guess a > timer can be used, but in the SID configuration file I > see that the timers have inputs from the cpu itself. > Is there anything simpler? Over to Frank and the SID guys, where you seem to have got a comprehensive answer. Robert Cragie, Design Engineer _______________________________________________________________ Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK http://www.jennic.com Tel: +44 (0) 114 281 2655 _______________________________________________________________ ^ permalink raw reply [flat|nested] 4+ messages in thread
end of thread, other threads:[~2003-07-02 10:10 UTC | newest] Thread overview: 4+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- [not found] <20030627094625.GN341@biferten.ma.tech.ascom.ch> 2003-06-27 13:40 ` [ECOS] generating interrupts in ARM-PID (SID simulator) Robert Cragie 2003-07-01 20:50 ` Partha Palit 2003-07-01 23:53 ` Frank Ch. Eigler 2003-07-02 10:10 ` Robert Cragie
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for read-only IMAP folder(s) and NNTP newsgroup(s).