8us timer

[eaton_remote]

Hi,
I'm running a pic18f2525 at 40 mhz. I need a timer that will interrupt every 8 microseconds. Any body have any thoughts?

Thanks in advance

[Ttelmah]

Forget it.
The chip will execute just 80 instructions in this time interval. The 'overhead' of an interrupt handler, is typically in excess of 70 instructions (to branch to the global handler, save the registers, call the required handler subroutine, reset the interrupt flag, restore the registers, and return). Doesn't leave any time to really 'do' anything.
There are methods of writing fast handlers (If the handler is very simple, write your own int_global, and just save a much smaller set of registers), but these require very careful programming, and even with these, if this event is continuously at this rate, there will be no margin to do anything else. I have written a 'quadrature' decoder in the past, that could work for a few seconds up to about half this rate, but 125KHz, interrupt driven, is really beyond the abilities of the chip, if anything else is to be done at the same time.

Best Wishes

[Gerrit]

What do you have to do in this interupt.

80 instruction is a lot.

Gerrit

[tavioman]

It is possible I believe.
Just load the timer with the value for 8us.
After ISR is done load-it again.
Ex:

[Ttelmah]

80 instructions, is not a lot, when 70 of them are already used...
The 'point' of having an interrupt event, is normally to allow other things to carry on operating 'in the gaps'. If this is not needed, then you can have the full '80 instructions', by simply polling the event, rather than using interrupt handling (for example, using the state of the interrupt _flag_, and when this goes true, clearing it, and then doing your own code. This then gives perhaps 75+ instructions available for use. The problem is that using an interrupt driven 'event', with the assumption that other things need to happen between the interrupts, brings with it the need to save the system state when the interrupt occurs. This (unfortunately), takes a lot of work (and is even worse on the 18 chips), leaving very little time at this rate, to actually do anything...
A quick 'count', on a 18F chip, with just one interrupt source enabled, gives the overhead as 73 instructions.
So an 8uSec hardware event, with the flag 'polled', is a much more practical solution.

Best Wishes

[Gerrit]

80 instructions is mutch.
use the high level interupt, own handler no globals in interupt, fast save work registers, I think this woud leave you 60-70 instructions for software.

regards,

Gerrit

[Ttelmah]

The 'retfie 1', only saves three things (W, status, and the BSR). Now this allows a very simple interrupt routine (just incrementing a single register for example), but as soon as you do more, more saving becomes needed. If (for instance), you want to access an array, you immediately have to save and restore the table select registers. Similarly, many normally used operations, will involve extra registers. The actual act of calling the interrupt handler, takes two instruction times, as does the retfie.
It is possible with care, to check exactly what registers are used inside your routine, and save just these, but each save, typically takes two instruction times, and another two for the restore, so even if you cut the number of registers saved down to just a very few, you will typically end up with 40+ instruction times needed. Yes, much better than the default situation, but not as much as it may seem. This was the approach used in my handler already mentioned.
The PIC, is 'poor' in this regard. The retfie 1 instruction, is an improvement, but in terms of fast interrupt handling, and approach like that on the old Z80 micro, with a complete duplicate 'set' of all the main registers, switchable in a single instruction, is much nicer.
It is _possible_ to handle events at this sort of frequency, but if this is to be routine, forget doing most of the things that 'C' offers you. At the end of the day, printf, arithmetic, etc. etc., are all going to raise the need to save yet more registers, and the lack of support for re-entrancy, means that what can be done in the interrupt handler itself, will be extremely limited. Hence, if somebody is thinking in terms of needing to handle things at this speed, they should be considering other options before starting...

Best Wishes

[sjbaxter]

Just curious ...

What is the general application ?
Are you measuring something or generating something (i.e. a waveform) ?
What is it that you need to do every 8uS ?
_________________
Regards,
Simon.

[Gerrit]

Hi Ttelmah,

This was just for going the discusion going. I know that 80 instructions is not mutch for the interrupt handler and the main program.
But I'm confinsed that you can do a lot of stuff in just 40 instructions, but you mostly have to leave C and write the handler in #asm. (I think that is nessasery for an interrupt handler, not using high level program language)

I have 4 independed 8 bits software PWM at +200Hz, also a full loaded (+- 95%) DMX channel at 250 kbit, interupt handler for rotary encoder and a lot of large array handling in the main program.

the software PWM's is running in high level interrupt the rest in normal interrupt.

I think for most 'C' users your explanation is correct, and you do not have time to do anythink in the interupt it self.


regards,

Gerrit

[tavioman]

What kind of rotary decoder do you use?

[Gerrit]

Hi Tavioman,

Maybe the wrong text but this is the rotary switch I use.
just software decoding.


http://www.farnell.com/datasheets/48122.pdf


Gerrit.

[tavioman]

There is LS7366 made by LSI/CSI with SPI interface.
If you are still working with a project that needs rotary decoder you can do the decoding much easier and gain processor time..