This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

A way use isr_evt_set function by FIQ in ARTX

In the ARTX, since the isr_evt_set can not be use in the __fiq function, I use the __swi function set the task instead. for exampal:

void IsrSetFunction (void) __swi (8) {
isr_evt_set (0x0001, tskMyTask);
}

void FIQ_Handler (void) __fiq {
IsrSetFunction();
EXTINT = 0x00000002; // Clear the peripheral interrupt flag
}

But this way will do? You know, the ARTX using the swi to do something.
'Software interrupts 0-7 are used by the Advanced Real-Time Kernel (ARARM) and may not be used in your application.'
So if I use the swi to set a task, this will occur some problem in ARTX?

Parents
  • Yes it will. There are small code sequences, which should be ATOMIC, means never interrupted. But this might not be the case if the FIQ interrupt happens. For example. There is currently executing a protected __swi function. This does not prevent FIQs. So in the middle of this protected function, a FIQ starts another __swi function. This would most likely cause the system crash.

    Anyway, I suggest you design your software concept so that you do not use FIQ for task synchronization. Use FIQs only for time critical events, which require fast response. It is not possible to get response times for tasks below 1 usec. It is in general a few tens of usec. For this purpose an IRQ interrupt might be used as well.

    Franc

Reply
  • Yes it will. There are small code sequences, which should be ATOMIC, means never interrupted. But this might not be the case if the FIQ interrupt happens. For example. There is currently executing a protected __swi function. This does not prevent FIQs. So in the middle of this protected function, a FIQ starts another __swi function. This would most likely cause the system crash.

    Anyway, I suggest you design your software concept so that you do not use FIQ for task synchronization. Use FIQs only for time critical events, which require fast response. It is not possible to get response times for tasks below 1 usec. It is in general a few tens of usec. For this purpose an IRQ interrupt might be used as well.

    Franc

Children
  • In my system, I need the FIQ to do something fast but part of the program in the FIQ needn't do fast. Because I want the FIQ can end faster so I want to set a task in the FIQ to do that part of program. But my way to set task in the FIQ is a good way? Any more good suggest?

  • In my system, I need the FIQ to do something fast but part of the program in the FIQ needn't do fast. Because I want the FIQ can end faster so I want to set a task in the FIQ to do that part of program. But my way to set task in the FIQ is a good way? Any more good suggest?

  • We currently do not support FIQ interrupts for ARTX. IRQ's are powerfull enough to handle all of the critical events. For example the USB stack, which is very time critical application, uses IRQs and isr_xxx functions for task synchronization. FIQ interrupts may freely be used in paralell with IRQ interrupts with no limitation. The only restriction is that kernel isr_xxx functions may not be called from FIQ interrupt handlers.

    I would suggest you rearrange your software and not use FIQ interrupts for isr_xxx task synchronization.

  • I think so. But what about nesting irq? When I use Isr_XXX in a nesting irq and I use another Isr_XXX in another irq at the same time. Will that cause some problem? Because I have try that when I use two Isr_XXX in one irq, it will cause some problem. For example:

    void T0irq(void) __irq {
    ...
    isr_evt_set (0x0001, tskMyTask);
    ...
    isr_evt_set (0x0010, tskMyTask);
    ...
    T0IR=0xFF;
    VICVectAddr = 0x00000000;
    }
    two isr_XXX used in one irq, the program can not go normaly. Another question is why two isr_XXX can not be used in one irq?

    then if I use nesting irq, for example:
    #define IENABLE /* Nested Interrupts Entry */ \
    __asm { MRS LR, SPSR } /* Copy SPSR_irq to LR */ \
    __asm { STMFD SP!, {LR} } /* Save SPSR_irq */ \
    __asm { MSR CPSR_c, #0x1F } /* Enable IRQ (Sys Mode) */ \
    __asm { STMFD SP!, {LR} } /* Save LR */ \

    #define IDISABLE /* Nested Interrupts Exit */ \
    __asm { LDMFD SP!, {LR} } /* Restore LR */ \
    __asm { MSR CPSR_c, #0x92 } /* Disable IRQ (IRQ Mode) */ \
    __asm { LDMFD SP!, {LR} } /* Restore SPSR_irq to LR */ \
    __asm { MSR SPSR_cxsf, LR } /* Copy LR to SPSR_irq */ \

    void T0irq(void) __irq {
    IENABLE
    ...
    isr_evt_set (0x0001, tskMyTask);//isr_XX_A
    ...
    IDISABLE
    T0IR=0xFF;
    VICVectAddr = 0x00000000;
    }

    void T1irq(void) __irq {
    ...
    isr_evt_set (0x0010, tskMyTask); //isr_XX_B
    ...
    T1IR=0xFF;
    VICVectAddr = 0x00000000;
    }

    Just imagine that isr_XX_A just finish then T1irq come, the effect is just like two isr_XXX run in one irq.In this case, the program will do. The task can be set normally?

  • Using nesting interrupts with ARTX is not a good practice. I mean, why would somebody try to implement a "feature" which is already a part of ARTX Kernel. Nested interrupts may simply be avoided by using a good RTOS based concept.

    Calling two isr_xxx functions from one interrupt function is not a problem. This works because the request is queued and processed later, when the irq function has finished. Then the os_clock_demon() task scheduler is started to process the queued requests, reschedule tasks and start the ready one with the highest priority.

    ARTX Kernel has proven to be a good and stable RTOS, used in may aplications. In general ARTX Kernel should work also with nested interrupts.

    But, if you really want to use nested interrupts, then you probably do not need ARTX Kernel at all.