Timer interrupt with RTOS-II

[Altera_Forum]

Hi all, 

 I'm working with RTOS-II and I need a very precise timing for a simple function. I have a dedicated timer which can trigger an interrupt every 1ms. So I used alt_irq_register(MY_TIMER_IRQ, 0,handle_timer_interrupt); and placed my simple code in the handle function (actually it simply changes a pio status and post an OS semaphore) All works. But I have two questions:  Q1: Is this correct and safe under RTOS? Can I use alt_irq_register() without corrupting anything is OS? Is there any other way to achieve this in a better way? Maybe the CreateTimer function?  Q2 I use an oscilloscope to monitor the pio setting performed by isr and I see a jitter up to 40us when OS tasks are quite loaded with work. Is this normal? Can I improve it? My timer use the highest priority irq, so I expected very high precision and then very low jittering of the 1ms period. Note that I don't care irq latency, provided it is constant. I only want generate these events at the exact 1ms period.  Thank you  Cris

[Altera_Forum]

Q1) yes, that is the way you register IRQs with the provided uCOSII RTOS 

 Q2) Not really sure you can improve on this. The jitter you see is the differnce in time it takes the RTOS to respond to your IRQ, this is normal. If you want IO lines toggled at very precise time intervals, you need to move the logic into hardware. Nios is just a micro controller, it shouldn't be used to generate clock signals etc.

[Altera_Forum]

--- Quote Start ---  The jitter you see is the differnce in time it takes the RTOS to respond to your IRQ, this is normal. If you want IO lines toggled at very precise time intervals, you need to move the logic into hardware. Nios is just a micro controller, it shouldn't be used to generate clock signals etc.  --- Quote End ---    I don't understand this point. I thought the irq handler should be indipendent from OS: I expected a jitter in the semaphore pending task but not here.  In this irq handler only deterministic hardware is apparently involved: timer has the highest priority and should be serviced immediately when timer elapses. I made these hypothesis to explain the behaviour: - OS uses OS_ENTER/EXIT_CRITICAL macros which sometimes disable IRQs for a while - OS has an own interrupt dispatcher, so that isr are not called directly - irq nesting is disabled At the moment the precision I get is quite enough for my needs, so I didn't verify which one is correct, if any. However any advice is greatly welcome. Thanks  Regards.

[Altera_Forum]

yes, you are right sort of. I think it depends on what instruction you were executing at the time of the interrupt. that instruction has to complete then the program counter is pushed and the ISR routine is executed. If the instruction you were executing was fetching data offchip or doing a divide vs just doing an add it could explain the jitter.

[Altera_Forum]

--- Quote Start ---  I made these hypothesis to explain the behaviour: - OS uses OS_ENTER/EXIT_CRITICAL macros which sometimes disable IRQs for a while   --- Quote End ---    This is definitely so, the others, not so much.  Once upon a time, on another processor (far, far away) I changed the behavior of the OS_ENTER/EXIT_CRITICAL to not disable all interrupts, but masked all except my own high priority timer interrupt. This was for just the reason you are seeing. You have to be sure to save/restore everything you use, and you can't use any main program or operating system variables/services/etc., but it gets you interrupts that only jitter by the time of the longest instruction (CISC processors have variable instruction times).  Another option would be to just read a free-running counter in the interrupt. Even though the interrupt is not time consistent, the free-running counter would let you know what time it is, or you could then stall in the ISR till a time reachable by all possible jitters finally arrives.

[Altera_Forum]

Thank you for your answer dong 

   --- Quote Start ---   Once upon a time, on another processor (far, far away) I changed the behavior of the OS_ENTER/EXIT_CRITICAL to not disable all interrupts, but masked all except my own high priority timer interrupt.    --- Quote End ---   In this case I understand I simply need to modify the OS_ENTER/EXIT_CRITICAL macros, isn't it? I'm not that expert on interrupt configuration on Nios II. Can you tell me how did you selectively disable interrupts? ... or am I asking something too far far away?    --- Quote Start ---   Another option would be to just read a free-running counter in the interrupt. Even though the interrupt is not time consistent, the free-running counter would let you know what time it is, or you could then stall in the ISR till a time reachable by all possible jitters finally arrives.  --- Quote End ---   Infact I considered this option, but it would imply the processor must stall for a while waiting for the required time. This would be not very efficient.  Thanks Cris

[Altera_Forum]

--- Quote Start ---  In this case I understand I simply need to modify the OS_ENTER/EXIT_CRITICAL macros, isn't it?  --- Quote End ---    Yes, but remember that 'exclusive access' then becomes your responsibility.   Haven't worked a lot with NIOS interrupts yet (soon), but I know that each separate device has an interrupt mask bit in a register, and I would be fairly certain that the interrupt controller has a mask register too. The interrupt controller would be the obvious place to do it, if available, but a longer version could be done with each device.    --- Quote Start ---  Infact I considered this option, but it would imply the processor must stall for a while waiting for the required time. This would be not very efficient.  --- Quote End ---    Yes, but assuming an even distribution, you would only be stalling for average=1/2 jitter; max=jitter. I think you said 40 uS jitter on a 1 mS interrupt. That seems to work out to an average of 2%, better if your jitter is skewed toward the low side (reasonably likely). If it's important enough for your time, it should be important enough for the processors.