Interrupt Latency and Bus Clk frequency relationHC8/HCS08/HC12/HCS12 etc

[denny_george]

Hello All,

Is there any relationship between Interrupt Latency and Bus Clk frequency .

That is higher the Bus Clk, lesser is the latency.Something like this.Or it is fixed across the freq?

a) I'm asking you this because latency involves= interrupt identification+ Context saving(Pushing of CPU registers) +Jump to the interrupt vector+time just before first instr of ISR is executed.

b)Is Context saving(Pushing of CPU registers)  similar to normal push operation which has definite machine cycles.Or some HW logic sends to the stack on the reception of a trigger ?

From Instruction set I could see some machine cycles allocated for SWI.

[kef]

Faster clock helps reducing interrupt latency.

---

Geo*** wrote:

a) I'm asking you this because latency involves= interrupt identification+ Context saving(Pushing of CPU registers) +Jump to the interrupt vector+time just before first instr of ISR is executed.

Yes, but interrupt latency also depends on other interrupts. If you have more simultaneous interrupts, then interrupt latency is what you said plus roughly the sum of execution times of all simultaneous interrupts. For example you have 3 interrupts (that may happen at the same time), and each ISR takes 50us. Then the worst case latency is about 50+50us or (3-1)*50us. Of course faster bus clock helps reducing this delay, because usually code executes faster with faster clocks.

b)Is Context saving(Pushing of CPU registers)  similar to normal push operation which has definite machine cycles.Or some HW logic sends to the stack on the reception of a trigger ?

It depends. Some MCUs save/restore on the stack almost everything and you don't have to save/restore single byte. Others may require save/restore everything by hand. Speaking about S12, all CPU registers are saved/restored on interrupt, and in the most of applications you don't need to save/restore more than that. But if you need for example to do in ISR some manipulations to PPAGE register, then you need to save/restore PPAGE manually. Context saving is bit wider than just CPU registers.

[denny_george]

Kef,

I was wondering whether I could write a small section of code which is frequency independent and hence the question.I'm considering only one interrupt,exit from iSR, then next interrupt something like this.

SWI  (swi  ISR has no instructions)

SWI

SWI

SWI

SWI

SWI

Data Sheet gives some machine cycle time for SWI. In such a scenario bus clock affects the code execution period.I don't know whether its true or not.

---

kef wrote:

Some MCUs save/restore on the stack almost everything and you don't have to save/restore single byte. Others may require save/restore everything by hand. Speaking about S12, all CPU registers are saved/restored on interrupt, and in the most of applications you don't need to save/restore more than that. But if you need for example to do in ISR some manipulations to PPAGE register, then you need to save/restore PPAGE manually. Context saving is bit wider than just CPU registers.

---

My question in mind was whether any harware internal logic (super fast ??!!???) would put/place ( I would like to call this way rather than push, coz it might confuse one with executing PUSH instruction which executes with a definite machine cycle  time and hence dependent on frequency clock.) these CPU registers (like in HC/HCS) on stack.

If we have "harware internal logic " that would put/place  definite number of CPU registers on stack then this latency would be independent of any frequency , i.e. execute in a exact period of time.

Here again input clock frequency to the "harware internal logic "  should be independent of bus clock frequency.Isn't it.

And if context saving is happening with PUSH intructions, surely frequency inflences the time latency.

[peg]

Hi Geo,

---

Geo*** wrote:

SWI  (swi  ISR has no instructions)

---

Firstly a SWI ISR with no instructions is going to give you a lot of grief. You need at least a RTI there.

On a S08 you have got 11 cycles for the SWI and 9 for the RTI. Umm thats 20 cycles, hardly nothing.
Yes, there is efficiencies over doing all the operations manually but it hardly vapourises to nothing.

Giving may well be the soul of love, but here it costs 20 cycles.

[denny_george]

Hi Peg!

I said "SWI  (swi  ISR has no instructions) ", 

Well I forgot to say I use Cosmic C Compiler which itself inserts Push H on begining and Pull H and RTI at the end on its on.Programmers need not worry! Actual ISR contains those stuffs as it should be there.

And hence the statement.I never tried codewarrior.

One SWI costs 20 cycles.A block of SWI costs me much ! Its unacceptable.

I need a SW code which is independent of System clock, provide me a required  delay irrespective of clock freq.

Wanna give a try.Super contributer  ??!!???

[peg]

Hi,

You seem to be confusing what you input to your compiler with what your CPU actually executes.
When considering execution time what you input to your compiler or which one you use is fairly irrelevant.

What you consider unacceptable or what you need is not going to effect the way your MPU operates.

All instructions take a finite amount of cycles to execute, thus they will take an amount of time proportional to the clock speed.

Unless you use the timer with an independent clock source, then you are never going to achieve this on these MPU's. Even then this is not your answer as you said software.

[denny_george]

Hi Peg

You have confused a lot. Try to understand that my compiler will automatically insert (on seeing @interrupt keyword) PSHH,(user code here)PULH,RTI. Programmer only needs to write his ISR code.Ok.Understood till here?

Now I'll remove PSHH and PULH.Now ISR contains only RTI.Now you might be thinking why i'm explaining this.This is because you said without RTI it would be a problem is retreiving the context of th epreviously executing task.

Remember you said " Firstly a SWI ISR with no instructions is going to give you a lot of grief. You need at least a RTI there."

---

peg wrote:

All instructions take a finite amount of cycles to execute, thus they will take an amount of time proportional to the clock speed.

Unless you use the timer with an independent clock source, then you are never going to achieve this on these MPU's. Even then this is not your answer as you said software.

---

Hmmm I'm speaking unnecessarily !!! First paragraph: I completely agree with you.But SWI is a special instruction. See my above reply for its working. There could be two options of saving/retreiving context from the stack.CPU individually executing Push instructions on register L,H,X,A ; Setting I flag 

loading PC.Second option could be hard wired logic which automatically does these sequentially one by one .Only HARDWARE delay involved and its fixed !!!!

I only wanted to confirm is it the second option.If it is, my task would be easy.continuosly call SWI till I get the required delay; Independent of clock frequency applied to MCU.One doesn't need a hardware timer for this!

"Unless you use the timer with an independent clock source, then you are never going to achieve this on these MPU's. "

This could be ideal thing to have in our MCUs: Accurate independent clock source.

Independent clock source( 1kHz) varies upto 30% in some HCS08 MCUs.And no trimming feature!!! I cannot use this.

If SWI behaves as I wished I could have got an easy SW solution.But alas, as you pointed out 20 machine cycles ; which is dependent on clock frequency.

There could be some SW solution,somewhere....One has to just find it out.

Message Edited by Geo*** on 2009-01-16 01:33 PM

[kef]

---

Geo*** wrote:

...Second option could be hard wired logic which automatically does these sequentially one by one .Only HARDWARE delay involved and its fixed !!!!

---

It's not clear what option you are talking about. It is not possible to write bus clock independent fixed time code without some special hardware. SWI won't halp you in any way.

[denny_george]

Kef,

Yes.

We are not sure if this special hardware is present inside the MCU.

See SWI takes 11 Bus Cycles.

Manual push of all registers will take you well above 11 Bus Cycles.

PC ← (PC) + $0001 // 1 cycle
Push (PCL); SP ← (SP) – $0001 // 2 cycles since all available push took 2.its an assumption made
Push (PCH); SP ← (SP) – $0001// 2 cycles since all available push took 2.its an assumption made
Push (X); SP ← (SP) – $0001 // // 2 cycles
Push (A); SP ← (SP) – $0001  // 2 cycles
Push (CCR); SP ← (SP) – $0001 // 2 cycles since all available push took 2.its an assumption made
I ← 1; // Assumption made is bitset instr used = 5 cycles
PCH ← Interrupt Vector High Byte // ?? average 3 or 4
PCL ← Interrupt Vector Low Byte  // ?? average 3 or 4

Already  18.

What about initial interrupt detection,recognition.It will add to this . Surely there is a special hardware which does in 11 cycles.( I doubt FSL regarding this i.e. 11 cycles.It should be some finite time like say some xxx nano seconds)

May be this method could be immpossible.What about some hidden things that is yet to be seen/found.

[kef]

Again. All HC08-HCS12X instructions including SWI, also the time needed to jump to ISR, take FIXED number of bus clocks. Execution time depends only on bus clock frequency and on response of MCU internal and external peripherals.

It is still not clear what you are trying to achieve. Do you want to determine the speed of external crystal? Then you have to use some other clock reference, for example internal RC clock.

[denny_george]

Kef,

I would say "HC08-HCS12X  SWI takes time needed to jump to ISR, take FIXED time measured in number of bus clocks. Bus clocks is used only as a reference for measuring time.

You say to a Amazon tribal your shirt cost xx USD.For him, difficult to understand also to remember.

You say it costs price of yyyyy SPEARS he is holding.Easy right.

Just like Hex Opcode and Mnemonic.

kef wrote:

It is still not clear what you are trying to achieve. Do you want to determine the speed of external crystal? Then you have to use some other clock reference, for example internal RC clock.

With only code, I want constant time duration code block.

---

kef wrote:

It is still not clear what you are trying to achieve. Do you want to determine the speed of external crystal? Then you have to use some other clock reference, for example internal RC clock.

---

Anyway since you asked, Internal RC clock has a deviation of +/- 2% after factory trim. Accuracy calculation of your crystal is compromised .And moreover RC oscillators' accuracy is dependent on  Vdd, Temperature applied to MCU .

Message Edited by Geo*** on 2009-01-16 02:41 PM

[denny_george]

Can someone take up this challenge ???!!!???

Giving is the soul of LOVE;unfortunately SWI takes 20 cycles.....   

Ake,

Where are you.

[Ake]

Hi,

You want to know the timing of an interrupt, is that correct?

(I have not read all the messages, so I might be wrong)

When an interrupt is received it takes, the 9S08 saves the CPU registers on the stack, except for reg H. That is it pushes A, X and CCR on the stack, 6 cycles.

It then pushes the PC on the stack, 2 * 2 cycles = 4 cycles.

It fetches the interrupt vector, that is 2 * 2 cycles or 4 cycles and modifies the PC.

So the interrupt takes 6 + 4 + 4 = 14 cycles to enter the interrupt routine.

To this must be added the time of the current instruction to be finished.

The slowest instruction is a version of  DBNZ. It takes 8 bus clocks.

So the time for the interupt is somwere between 14 and 14 + 8 = 22 clock cycles.

Was that what you wanted to know?

I saw that you were discussing the SWI instruction.

Regards,

Ake

[kef]

Execution time of SWI instruction is also bus clock dependent. It takes fixed amount of bus cycles. You can't write bus clock independent, fixed execution time code without some timing hardware.

Message Edited by kef on 2009-01-16 12:08 PM

[denny_george]

Hello All,

I forgot to add some more thing.

1) It is assumed background task is executing without any particular Interrupt disable.

  Simply means, at the end of the current instruction in the background task, interrupt is detected.

2)Only one interrupt has come. (No higher priority interrupt has accompained this interrupt of interest.)