* [ECOS] On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? @ 2008-04-02 16:48 Grant Edwards 2008-04-02 16:51 ` Chris Zimman 0 siblings, 1 reply; 22+ messages in thread From: Grant Edwards @ 2008-04-02 16:48 UTC (permalink / raw) To: ecos-discuss I've got an application where some low-level interrupt driven stuff needs to happen with minimal latency (a hard deadline of 20us). It's an ARM7 running at 22Mhz, and preliminary measurements indicate that the eCos ISR latency is going to be too large. One thought was to use IRQ for normal eCos stuff, and dedicate FIQ to the low-latency stuff. The theory was that since the FIQ service routine wouldn't do anything with any eCos data structures, it would be allowed to interrupt normal eCos ISRs. That would allow the FIQ latency to be kept low. From looking at the ARM/arch hal stuff, it looks like eCos expects to handle both IRQ and FIQ interrupts. AFAICT, all of the interrupt sources in my part (Samsung S3C4530) can be assigned to either IRQ or FIQ. Is there any reason why eCos has to have control of both interrupt sources if all of the peripherals which eCos is handling are on just one of them? -- Grant Edwards grante Yow! Nipples, dimples, at knuckles, NICKLES, visi.com wrinkles, pimples!! -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: [ECOS] On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 16:48 [ECOS] On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? Grant Edwards @ 2008-04-02 16:51 ` Chris Zimman 2008-04-02 17:23 ` [ECOS] " Grant Edwards 0 siblings, 1 reply; 22+ messages in thread From: Chris Zimman @ 2008-04-02 16:51 UTC (permalink / raw) To: Grant Edwards, ecos-discuss > From looking at the ARM/arch hal stuff, it looks like eCos > expects to handle both IRQ and FIQ interrupts. AFAICT, all of > the interrupt sources in my part (Samsung S3C4530) can be > assigned to either IRQ or FIQ. > > Is there any reason why eCos has to have control of both > interrupt sources if all of the peripherals which eCos is > handling are on just one of them? Just change the FIQ vector to point to your handler. I don't know of anything that uses FIQ right now anyhow. --Chris -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 16:51 ` Chris Zimman @ 2008-04-02 17:23 ` Grant Edwards 2008-04-02 17:39 ` Chris Zimman 0 siblings, 1 reply; 22+ messages in thread From: Grant Edwards @ 2008-04-02 17:23 UTC (permalink / raw) To: ecos-discuss On 2008-04-02, Chris Zimman <czimman@bloomberg.com> wrote: >> From looking at the ARM/arch hal stuff, it looks like eCos >> expects to handle both IRQ and FIQ interrupts. AFAICT, all of >> the interrupt sources in my part (Samsung S3C4530) can be >> assigned to either IRQ or FIQ. >> >> Is there any reason why eCos has to have control of both >> interrupt sources if all of the peripherals which eCos is >> handling are on just one of them? > > Just change the FIQ vector to point to your handler. I don't > know of anything that uses FIQ right now anyhow. I just double-checked the initialization code for my HAL (it's a custom one), and it is indeed configuring all of the interrupts currently in use to use IRQ, so nothing is using FIQ. However, there quite a few spots in the arm/arch interrupt and exception handling code where FIQ is being disabled. It looks like I'd have to fork the arch code and modify it to prevent it from disabling FIQ. I suppose the right thing to do would be to make the arm/arch stuff configurable via CDL so that it would use either FIQ or IRQ or both. -- Grant Edwards grante Yow! ... I want FORTY-TWO at TRYNEL FLOATATION SYSTEMS visi.com installed within SIX AND A HALF HOURS!!! -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 17:23 ` [ECOS] " Grant Edwards @ 2008-04-02 17:39 ` Chris Zimman 2008-04-02 18:48 ` Grant Edwards 2008-04-02 18:59 ` Andrew Lunn 0 siblings, 2 replies; 22+ messages in thread From: Chris Zimman @ 2008-04-02 17:39 UTC (permalink / raw) To: Grant Edwards, ecos-discuss > However, there quite a few spots in the arm/arch interrupt and > exception handling code where FIQ is being disabled. It looks > like I'd have to fork the arch code and modify it to prevent it > from disabling FIQ. Yes, there definitely is that issue. It's not too many places that have to be updated though. > I suppose the right thing to do would be to make the arm/arch > stuff configurable via CDL so that it would use either FIQ or > IRQ or both. I would think what you'd want to do is to provide a function to change the FIQ vector after eCos has started. If you start things without the FIQ vector assigned, and for whatever reason it fires, you're in trouble. With regards to CDL, I don't know that it would make sense to have a CDL option to not have eCos own the FIQ vector on startup. --Chris -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 17:39 ` Chris Zimman @ 2008-04-02 18:48 ` Grant Edwards 2008-04-02 19:21 ` Alexander Neundorf 2008-04-02 20:59 ` Paul D. DeRocco 2008-04-02 18:59 ` Andrew Lunn 1 sibling, 2 replies; 22+ messages in thread From: Grant Edwards @ 2008-04-02 18:48 UTC (permalink / raw) To: ecos-discuss On 2008-04-02, Chris Zimman <czimman@bloomberg.com> wrote: >> However, there quite a few spots in the arm/arch interrupt and >> exception handling code where FIQ is being disabled. It looks >> like I'd have to fork the arch code and modify it to prevent >> it from disabling FIQ. > > Yes, there definitely is that issue. It's not too many places > that have to be updated though. > >> I suppose the right thing to do would be to make the arm/arch >> stuff configurable via CDL so that it would use either FIQ or >> IRQ or both. > > I would think what you'd want to do is to provide a function > to change the FIQ vector after eCos has started. That's easy enough, but it'd be trickier to provide a run-time function to fix the places in vectors.S that are currently disabling FIQ. > If you start things without the FIQ vector assigned, and for > whatever reason it fires, you're in trouble. True. > With regards to CDL, I don't know that it would make sense to > have a CDL option to not have eCos own the FIQ vector on > startup. The main point of the CDL would be to avoid having to fork the arm/arch code. I don't really like maintaining my own separate versions of files unless I absolutely have to. Besides, somebody else might actually want to use the new "feature". -- Grant Edwards grante Yow! I feel ... JUGULAR ... at visi.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 18:48 ` Grant Edwards @ 2008-04-02 19:21 ` Alexander Neundorf 2008-04-02 19:30 ` Andrew Lunn 2008-04-02 19:33 ` Grant Edwards 2008-04-02 20:59 ` Paul D. DeRocco 1 sibling, 2 replies; 22+ messages in thread From: Alexander Neundorf @ 2008-04-02 19:21 UTC (permalink / raw) To: ecos-discuss On Wednesday 02 April 2008, Grant Edwards wrote: ... > The main point of the CDL would be to avoid having to fork the > arm/arch code. I don't really like maintaining my own separate > versions of files unless I absolutely have to. Besides, > somebody else might actually want to use the new "feature". Yes. I think providing an official way how to use the FIQ with lowest possible overhead under eCos would be good. Some kind of communication with eCos is required I think, e.g. a recommended way how to generate a regular interrupt so that if some condition is detected in the FIQ handler a regular ISR can overtake. Alex -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 19:21 ` Alexander Neundorf @ 2008-04-02 19:30 ` Andrew Lunn 2008-04-02 19:40 ` Grant Edwards 2008-04-02 19:33 ` Grant Edwards 1 sibling, 1 reply; 22+ messages in thread From: Andrew Lunn @ 2008-04-02 19:30 UTC (permalink / raw) To: Alexander Neundorf; +Cc: ecos-discuss On Wed, Apr 02, 2008 at 09:25:19PM +0200, Alexander Neundorf wrote: > On Wednesday 02 April 2008, Grant Edwards wrote: > ... > > The main point of the CDL would be to avoid having to fork the > > arm/arch code. I don't really like maintaining my own separate > > versions of files unless I absolutely have to. Besides, > > somebody else might actually want to use the new "feature". > > Yes. I think providing an official way how to use the FIQ with lowest possible > overhead under eCos would be good. Some kind of communication with eCos is > required I think, e.g. a recommended way how to generate a regular interrupt > so that if some condition is detected in the FIQ handler a regular ISR can > overtake. I've done this before, but it used hardware support. The Intel StrongARM interrupt controller had a bit you could set to cause an IRQ interrupt to happen. So in the FIQ you hit this bit and exit the FIQ. Once interrupts are re-enabled the IRQ goes off and you are in normal eCos interrupt context. I don't know of a generic way to do this. There is no standardised interrupt controller for ARMs. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 19:30 ` Andrew Lunn @ 2008-04-02 19:40 ` Grant Edwards 2008-04-02 19:47 ` Andrew Lunn 0 siblings, 1 reply; 22+ messages in thread From: Grant Edwards @ 2008-04-02 19:40 UTC (permalink / raw) To: ecos-discuss On 2008-04-02, Andrew Lunn <andrew@lunn.ch> wrote: >> Yes. I think providing an official way how to use the FIQ with >> lowest possible overhead under eCos would be good. Some kind >> of communication with eCos is required I think, e.g. a >> recommended way how to generate a regular interrupt so that if >> some condition is detected in the FIQ handler a regular ISR >> can overtake. > > I've done this before, but it used hardware support. > > The Intel StrongARM interrupt controller had a bit you could > set to cause an IRQ interrupt to happen. So in the FIQ you hit > this bit and exit the FIQ. Once interrupts are re-enabled the > IRQ goes off and you are in normal eCos interrupt context. How did eCos know where the interrupt came from? Did that bit you set have it's own unique hardware-generated ID value? > I don't know of a generic way to do this. There is no > standardised interrupt controller for ARMs. I think it's going to be target-dependent. -- Grant Edwards grante Yow! I'll eat ANYTHING at that's BRIGHT BLUE!! visi.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 19:40 ` Grant Edwards @ 2008-04-02 19:47 ` Andrew Lunn 2008-04-02 21:12 ` Grant Edwards 0 siblings, 1 reply; 22+ messages in thread From: Andrew Lunn @ 2008-04-02 19:47 UTC (permalink / raw) To: Grant Edwards; +Cc: eCos Disuss On Wed, Apr 02, 2008 at 07:36:21PM +0000, Grant Edwards wrote: > On 2008-04-02, Andrew Lunn <andrew@lunn.ch> wrote: > > >> Yes. I think providing an official way how to use the FIQ with > >> lowest possible overhead under eCos would be good. Some kind > >> of communication with eCos is required I think, e.g. a > >> recommended way how to generate a regular interrupt so that if > >> some condition is detected in the FIQ handler a regular ISR > >> can overtake. > > > > I've done this before, but it used hardware support. > > > > The Intel StrongARM interrupt controller had a bit you could > > set to cause an IRQ interrupt to happen. So in the FIQ you hit > > this bit and exit the FIQ. Once interrupts are re-enabled the > > IRQ goes off and you are in normal eCos interrupt context. > > How did eCos know where the interrupt came from? Did that bit > you set have it's own unique hardware-generated ID value? Yep. CYGNUM_HAL_INTERRUPT_SOFT_IRQ, So you just register an interrupt handler for this as normal. When the interrupt fires the interrupt controller say a soft IRQ has gone off when hal_IRQ_handler() asks it. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 19:47 ` Andrew Lunn @ 2008-04-02 21:12 ` Grant Edwards 0 siblings, 0 replies; 22+ messages in thread From: Grant Edwards @ 2008-04-02 21:12 UTC (permalink / raw) To: ecos-discuss On 2008-04-02, Andrew Lunn <andrew@lunn.ch> wrote: > On Wed, Apr 02, 2008 at 07:36:21PM +0000, Grant Edwards wrote: >> On 2008-04-02, Andrew Lunn <andrew@lunn.ch> wrote: >> >> >> Yes. I think providing an official way how to use the FIQ with >> >> lowest possible overhead under eCos would be good. Some kind >> >> of communication with eCos is required I think, e.g. a >> >> recommended way how to generate a regular interrupt so that if >> >> some condition is detected in the FIQ handler a regular ISR >> >> can overtake. >> > >> > I've done this before, but it used hardware support. >> > >> > The Intel StrongARM interrupt controller had a bit you could >> > set to cause an IRQ interrupt to happen. So in the FIQ you hit >> > this bit and exit the FIQ. Once interrupts are re-enabled the >> > IRQ goes off and you are in normal eCos interrupt context. >> >> How did eCos know where the interrupt came from? Did that bit >> you set have it's own unique hardware-generated ID value? > > Yep. CYGNUM_HAL_INTERRUPT_SOFT_IRQ, So you just register an interrupt > handler for this as normal. When the interrupt fires the interrupt > controller say a soft IRQ has gone off when hal_IRQ_handler() asks it. That's pretty much ideal. I don't remember seeing a feature like that on my part, but I believe I can manually set the interrupt request flag for one of the unused external interrupt/port pins. -- Grant Edwards grante Yow! Could I have a drug at overdose? visi.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 19:21 ` Alexander Neundorf 2008-04-02 19:30 ` Andrew Lunn @ 2008-04-02 19:33 ` Grant Edwards 2008-04-02 19:42 ` Andrew Lunn 1 sibling, 1 reply; 22+ messages in thread From: Grant Edwards @ 2008-04-02 19:33 UTC (permalink / raw) To: ecos-discuss On 2008-04-02, Alexander Neundorf <neundorf@kde.org> wrote: > On Wednesday 02 April 2008, Grant Edwards wrote: > ... >> The main point of the CDL would be to avoid having to fork the >> arm/arch code. I don't really like maintaining my own >> separate versions of files unless I absolutely have to. >> Besides, somebody else might actually want to use the new >> "feature". > > Yes. I think providing an official way how to use the FIQ with > lowest possible overhead under eCos would be good. Some kind > of communication with eCos is required I think, e.g. a > recommended way how to generate a regular interrupt so that if > some condition is detected in the FIQ handler a regular ISR > can overtake. I was thinking about that. We're not sure yet if we need to be able to do that or not -- I'm guessing we will probably want to. Is there a platform-independant way to trigger an ISR from software? IIRC, it's pretty easy to do so with the interrupt controller in the part I'm using, but that's platform dependent. That doesn't mean it can't be done, it just means that everybody who wants to do that would have to add support to the HAL that they're using. -- Grant Edwards grante Yow! I'm ANN LANDERS!! at I can SHOPLIFT!! visi.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 19:33 ` Grant Edwards @ 2008-04-02 19:42 ` Andrew Lunn 2008-04-02 20:23 ` Alexander Neundorf 0 siblings, 1 reply; 22+ messages in thread From: Andrew Lunn @ 2008-04-02 19:42 UTC (permalink / raw) To: Grant Edwards; +Cc: ecos-discuss > Is there a platform-independant way to trigger an ISR from > software? I don't think so. The function to actually handle the interrupt, hal_IRQ_handler() is in the platform package, not the architecture package. hal_IRQ_handler() asks the interrupt controller what triggered the interrupt and that is all platform dependent. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 19:42 ` Andrew Lunn @ 2008-04-02 20:23 ` Alexander Neundorf 0 siblings, 0 replies; 22+ messages in thread From: Alexander Neundorf @ 2008-04-02 20:23 UTC (permalink / raw) To: ecos-discuss On Wednesday 02 April 2008, Andrew Lunn wrote: > > Is there a platform-independant way to trigger an ISR from > > software? > > I don't think so. The function to actually handle the interrupt, > hal_IRQ_handler() is in the platform package, not the architecture > package. hal_IRQ_handler() asks the interrupt controller what > triggered the interrupt and that is all platform dependent. Could that be hidden by some HAL macro ? Alex -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* RE: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 18:48 ` Grant Edwards 2008-04-02 19:21 ` Alexander Neundorf @ 2008-04-02 20:59 ` Paul D. DeRocco 2008-04-02 21:20 ` Grant Edwards 1 sibling, 1 reply; 22+ messages in thread From: Paul D. DeRocco @ 2008-04-02 20:59 UTC (permalink / raw) To: ecos-discuss > From: Grant Edwards > > That's easy enough, but it'd be trickier to provide a run-time > function to fix the places in vectors.S that are currently > disabling FIQ. I think the issue is that there are lots of small critical sections scattered all over the place that mask interrupts in the CPU, and they currently mask both IRQ and FIQ. For the ARM, HAL_*_INTERRUPTS uses 0xC0 to manipulate both these bits. If all eCos ISRs are invoked via IRQ, and FIQ is reserved for a special bit of driver code that merely adds functionality to a piece of hardware (like adding a FIFO to a serial port) without invoking a DSR, then these macros really ought to use 0x80 instead. That would be a useful CDL option. -- Ciao, Paul D. DeRocco Paul mailto:pderocco@ix.netcom.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 20:59 ` Paul D. DeRocco @ 2008-04-02 21:20 ` Grant Edwards 0 siblings, 0 replies; 22+ messages in thread From: Grant Edwards @ 2008-04-02 21:20 UTC (permalink / raw) To: ecos-discuss On 2008-04-02, Paul D. DeRocco <pderocco@ix.netcom.com> wrote: >> From: Grant Edwards >> >> That's easy enough, but it'd be trickier to provide a run-time >> function to fix the places in vectors.S that are currently >> disabling FIQ. > > I think the issue is that there are lots of small critical sections > scattered all over the place that mask interrupts in the CPU, and they > currently mask both IRQ and FIQ. For the ARM, HAL_*_INTERRUPTS uses 0xC0 to > manipulate both these bits. If all eCos ISRs are invoked via IRQ, and FIQ is > reserved for a special bit of driver code that merely adds functionality to > a piece of hardware (like adding a FIFO to a serial port) without invoking a > DSR, then these macros really ought to use 0x80 instead. That would be a > useful CDL option. Exactly. We can leave the FIQ handler code there, and just overried it by pointing the VSR table entry elsewhere. But, the places (e.g. in vectors.S) that are disabling and enabling FIQ+IRQ need to be changed so that they only disable/enable the right one(s). -- Grant Edwards grante Yow! WHOA!! Ken and Barbie at are having TOO MUCH FUN!! visi.com It must be the NEGATIVE IONS!! -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 17:39 ` Chris Zimman 2008-04-02 18:48 ` Grant Edwards @ 2008-04-02 18:59 ` Andrew Lunn 2008-04-02 19:27 ` Grant Edwards 2008-04-02 20:01 ` David Roethig 1 sibling, 2 replies; 22+ messages in thread From: Andrew Lunn @ 2008-04-02 18:59 UTC (permalink / raw) To: Chris Zimman; +Cc: Grant Edwards, ecos-discuss > I would think what you'd want to do is to provide a function to change > the FIQ vector after eCos has started. It already exists. void cyg_interrupt_get_vsr(cyg_vector_t vector, cyg_VSR_t** vsr); void cyg_interrupt_set_vsr(cyg_vector_t vector, cyg_VSR_t* vsr); with the vector CYGNUM_HAL_VECTOR_FIQ. The vsr function needs to be written in assembly and save and restore all registers etc. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 18:59 ` Andrew Lunn @ 2008-04-02 19:27 ` Grant Edwards 2008-04-02 19:35 ` Andrew Lunn 2008-04-02 20:01 ` David Roethig 1 sibling, 1 reply; 22+ messages in thread From: Grant Edwards @ 2008-04-02 19:27 UTC (permalink / raw) To: ecos-discuss On 2008-04-02, Andrew Lunn <andrew@lunn.ch> wrote: >> I would think what you'd want to do is to provide a function to change >> the FIQ vector after eCos has started. > > It already exists. > > void cyg_interrupt_get_vsr(cyg_vector_t vector, cyg_VSR_t** vsr); > > void cyg_interrupt_set_vsr(cyg_vector_t vector, cyg_VSR_t* vsr); > > with the vector CYGNUM_HAL_VECTOR_FIQ. That would work. It would save a few clock cycles to set the vector in the actual vector table rather than in the secondary indirect one, but I don't know if it's worth the extra hassle. > The vsr function needs to be written in assembly and save and restore > all registers etc. Yup. -- Grant Edwards grante Yow! Don't SANFORIZE me!! at visi.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 19:27 ` Grant Edwards @ 2008-04-02 19:35 ` Andrew Lunn 2008-04-02 19:39 ` Grant Edwards 0 siblings, 1 reply; 22+ messages in thread From: Andrew Lunn @ 2008-04-02 19:35 UTC (permalink / raw) To: Grant Edwards; +Cc: ecos-discuss On Wed, Apr 02, 2008 at 07:26:25PM +0000, Grant Edwards wrote: > On 2008-04-02, Andrew Lunn <andrew@lunn.ch> wrote: > > >> I would think what you'd want to do is to provide a function to change > >> the FIQ vector after eCos has started. > > > > It already exists. > > > > void cyg_interrupt_get_vsr(cyg_vector_t vector, cyg_VSR_t** vsr); > > > > void cyg_interrupt_set_vsr(cyg_vector_t vector, cyg_VSR_t* vsr); > > > > with the vector CYGNUM_HAL_VECTOR_FIQ. > > That would work. It would save a few clock cycles to set the > vector in the actual vector table rather than in the secondary > indirect one, but I don't know if it's worth the extra hassle. It is directly in the vector table, normally at address 0x20 for the beginning of the table and the FIQ entry at 0x3C. You cannot put an address at 0x1C, it has to be an instruction, and you have limited branch range so cannot make it generic. Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 19:35 ` Andrew Lunn @ 2008-04-02 19:39 ` Grant Edwards 0 siblings, 0 replies; 22+ messages in thread From: Grant Edwards @ 2008-04-02 19:39 UTC (permalink / raw) To: ecos-discuss On 2008-04-02, Andrew Lunn <andrew@lunn.ch> wrote: >> > void cyg_interrupt_set_vsr(cyg_vector_t vector, cyg_VSR_t* vsr); >> > >> > with the vector CYGNUM_HAL_VECTOR_FIQ. >> >> That would work. It would save a few clock cycles to set the >> vector in the actual vector table rather than in the secondary >> indirect one, but I don't know if it's worth the extra hassle. > > It is directly in the vector table, normally at address 0x20 for the > beginning of the table and the FIQ entry at 0x3C. You cannot put an > address at 0x1C, it has to be an instruction, and you have limited > branch range so cannot make it generic. Ah, right. I had forgotten about the address vs. instruction piece of the puzzle. I was thinking you put an address at 0x1C. -- Grant Edwards grante Yow! if it GLISTENS, at gobble it!! visi.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 18:59 ` Andrew Lunn 2008-04-02 19:27 ` Grant Edwards @ 2008-04-02 20:01 ` David Roethig 2008-04-02 20:17 ` Andrew Lunn 2008-04-02 21:15 ` Grant Edwards 1 sibling, 2 replies; 22+ messages in thread From: David Roethig @ 2008-04-02 20:01 UTC (permalink / raw) To: ecos-discuss Andrew Lunn wrote: >> I would think what you'd want to do is to provide a function to change >> the FIQ vector after eCos has started. >> > > It already exists. > > void cyg_interrupt_get_vsr(cyg_vector_t vector, cyg_VSR_t** vsr); > > void cyg_interrupt_set_vsr(cyg_vector_t vector, cyg_VSR_t* vsr); > > with the vector CYGNUM_HAL_VECTOR_FIQ. > > The vsr function needs to be written in assembly and save and restore > all registers etc. > > Andrew > > We implemented a similar solution for a hard-time requirement of 300us. In our application, we read ADC values and store them away. Here are the notes for the setup: // ************************** // This exception handler replaces the standard FIQ handler // located in vectors.S. It is specific for the <name changed> // application. // // To use this replacement FIQ handler: // 1) modify linker file: // The linker file needs to be modified so that the HAL_VSR_SET() // macro works correctly. // In the file mlt_arm_lpc2xxx_<name changed>.ldi, change: // // SECTION_fixed_vectors (ram, 0x40000040, LMA_EQ_VMA) // to // SECTION_fixed_vectors (ram, 0x40000020, LMA_EQ_VMA) // // This locates hal_vsr_table at 0x40000020 (on-chip RAM). // hal_vsr_table is not used (except we are using it now!). // // this assumes running from flash with exception vector located // in on-chip RAM (MEMMAP=2). // // 2) HAL_VSR_SET // The initialization code needs to replace the existing FIQ // handler with the application specific one. This call is // located in hal_api_analog_init() which is called with // interrupts disabled (MUST!). // // extern void APPFIQ (void); // // /* set APPFIQ to be the FIQ handler */ // HAL_VSR_SET(CYGNUM_HAL_VECTOR_FIQ, APPFIQ, NULL); // // A timer is used to trigger the ADC to start sampling: /* *** *** */ /* set up timer for 300us reading cycle */ /* Disable and reset counter */ HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxTCR, 2); /* set prescale register to 0 */ HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxPR, 0); /* clear all interrupts */ HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxIR, 0xffffffff); /* clear all match/capture control settings */ HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxMCR, 0); /* */ HAL_READ_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxEMR, regTemp); HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxEMR, (2 << 4)); /* Set up match register (plus extra for first time) */ HAL_READ_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxTC, regTemp); HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxMR0, (regTemp + 17695 + 0x00ffffff)); /* add a fudge factor for initialization */ /* Enable counter */ HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_TIMER1_BASE+CYGARC_HAL_LPC2XXX_REG_TxTCR, 1); /* *** *** */ /* set up ADC divisor */ /* enable with a divisor of 14 (-> ~4.2MHz) */ /* With an input clock of ~58.98MHz, this results in a clock of ~4.2MHz. */ /* turn the adc 'on' */ /* *** *** */ /* set up ADC to sample channel 0 sample dependent upon MR0 of Timer1 */ /* set the timing, enable the power */ HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_AD_BASE+CYGARC_HAL_LPC2XXX_REG_ADCR, (CYGARC_HAL_LPC2XXX_REG_ADCR_PDN) | /* power enable */ (13 << 8) ); /* clkdiv (~4.2MHz) */ /* sample channel 0 */ HAL_READ_UINT32(CYGARC_HAL_LPC2XXX_REG_AD_BASE+CYGARC_HAL_LPC2XXX_REG_ADCR, regTemp); HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_AD_BASE+CYGARC_HAL_LPC2XXX_REG_ADCR, ((regTemp & 0xffffff00) | (1 << 6)) ); /* channel 6 */ /* START = '110' -> MR0 of Timer1 */ HAL_READ_UINT32(CYGARC_HAL_LPC2XXX_REG_AD_BASE+CYGARC_HAL_LPC2XXX_REG_ADCR, regTemp); HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_AD_BASE+CYGARC_HAL_LPC2XXX_REG_ADCR, ( (regTemp & (~(7<<24))) | ((6 << 24) ) ) ); /* 110 -> start MAT1.0 */ /* *** *** */ /* set up ADC interrupt as FIQ and enable */ /* set interrupt as FIQ */ HAL_WRITE_UINT32(CYGARC_HAL_LPC2XXX_REG_VIC_BASE+CYGARC_HAL_LPC2XXX_REG_VICINTSELECT, (1<<CYGNUM_HAL_INTERRUPT_AD)); /* enable interrupt */ cyg_interrupt_unmask(CYGNUM_HAL_INTERRUPT_AD); The APPFIQ code is written in assembler and just saves some stack and calls the handler routine. I hope this wasn't too much detail... - Dave -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* Re: [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 20:01 ` David Roethig @ 2008-04-02 20:17 ` Andrew Lunn 2008-04-02 21:15 ` Grant Edwards 1 sibling, 0 replies; 22+ messages in thread From: Andrew Lunn @ 2008-04-02 20:17 UTC (permalink / raw) To: David Roethig; +Cc: ecos-discuss > Here are the notes for the setup: > // ************************** > // This exception handler replaces the standard FIQ handler > // located in vectors.S. It is specific for the <name changed> > // application. > // > // To use this replacement FIQ handler: > // 1) modify linker file: > // The linker file needs to be modified so that the HAL_VSR_SET() > // macro works correctly. > // In the file mlt_arm_lpc2xxx_<name changed>.ldi, change: > // > // SECTION_fixed_vectors (ram, 0x40000040, LMA_EQ_VMA) > // to > // SECTION_fixed_vectors (ram, 0x40000020, LMA_EQ_VMA) > // > // This locates hal_vsr_table at 0x40000020 (on-chip RAM). > // hal_vsr_table is not used (except we are using it now!). Interesting. It looks like all lpc2xxx platforms are broken in the same way... Andrew -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
* [ECOS] Re: On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? 2008-04-02 20:01 ` David Roethig 2008-04-02 20:17 ` Andrew Lunn @ 2008-04-02 21:15 ` Grant Edwards 1 sibling, 0 replies; 22+ messages in thread From: Grant Edwards @ 2008-04-02 21:15 UTC (permalink / raw) To: ecos-discuss On 2008-04-02, David Roethig <droethig@cipher.com> wrote: > We implemented a similar solution for a hard-time requirement of 300us. > In our application, we read ADC values and store them away. > > > Here are the notes for the setup: Thanks! That'll be very helpful. -- Grant Edwards grante Yow! Am I in GRADUATE at SCHOOL yet? visi.com -- Before posting, please read the FAQ: http://ecos.sourceware.org/fom/ecos and search the list archive: http://ecos.sourceware.org/ml/ecos-discuss ^ permalink raw reply [flat|nested] 22+ messages in thread
end of thread, other threads:[~2008-04-02 21:20 UTC | newest] Thread overview: 22+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-04-02 16:48 [ECOS] On ARM7 can one of FIQ/IRQ be used for non-eCos stuff? Grant Edwards 2008-04-02 16:51 ` Chris Zimman 2008-04-02 17:23 ` [ECOS] " Grant Edwards 2008-04-02 17:39 ` Chris Zimman 2008-04-02 18:48 ` Grant Edwards 2008-04-02 19:21 ` Alexander Neundorf 2008-04-02 19:30 ` Andrew Lunn 2008-04-02 19:40 ` Grant Edwards 2008-04-02 19:47 ` Andrew Lunn 2008-04-02 21:12 ` Grant Edwards 2008-04-02 19:33 ` Grant Edwards 2008-04-02 19:42 ` Andrew Lunn 2008-04-02 20:23 ` Alexander Neundorf 2008-04-02 20:59 ` Paul D. DeRocco 2008-04-02 21:20 ` Grant Edwards 2008-04-02 18:59 ` Andrew Lunn 2008-04-02 19:27 ` Grant Edwards 2008-04-02 19:35 ` Andrew Lunn 2008-04-02 19:39 ` Grant Edwards 2008-04-02 20:01 ` David Roethig 2008-04-02 20:17 ` Andrew Lunn 2008-04-02 21:15 ` Grant Edwards
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).