Interrupt Tutorials

[Micro_Guy]

Hey guys,

Could someone provide me with or point me to a good Interrupt tutorial. I would like to become more familiar with Interrupts. I understand the concept of interrupts what I feel I'm missing is a detailed example.

If possible I would like to see (With comments) how interrupts are used with timers/counters to execute time driven events, for example Blink and LED every few seconds.

Thank you in advance

[Mike Walne]

Do a search on this forum.

Set the "search all terms button"
Search for keyword "interrupts".
Search for author "One of the regulars(either Mr T, asmboy, me, etc)".

Mike

[temtronic]

key point on using interrupts..
1) never do any math (esp. FP !) inside the ISR
2) never print anything inside the ISR
3) never do any long, complicated 'switches' inside the ISR
4) never do any complicated 'if elses' inside the ISR

5) check out the CCS supplied examples
6) do as Mike say, search this forum
7) experiment ! start small,build on what you learn
8) problem? post small program here, others can help

Jay

[asmboy]

[asmallri]

13) if accessing a variable both inside the interrupt handler and in the mainline and the variable if not the same width as the Processor data bus width then disable the interrupt in the mainline before operating on the variable. For example if you are using an 8 bit processor such as a PIC16 or PIC18 and using an int16 variable inside and outside the interrupt handler then interrupts must be disabled in the mainline before accessing the variable.
_________________
Regards, Andrew

http://www.brushelectronics.com/software
Home of Ethernet, SD card and Encrypted Serial Bootloaders for PICs!!

[Micro_Guy]

These are all very helpful and greatly appreciated, Thanks everyone!

[Ttelmah]

Like all things, 'rules' can often be simplified, and are often wrong....

70% of the rules posted come down to one simple statement:

The interrupt handler should just do the task involved in handling the interrupt, and do it as quickly as possible. This covers all the 'print', 'delay', 'maths' etc., points. These are not quick.

This includes the critical thing that the handler must 'do the task involved'. So for INT_TBE, it must load a new character to send. INT_RBA, must receive a character. INT_RB, must read the port etc..

Then.

One disagreement here is on the "don't use large switches" line. In fact a state machine with a huge array of choices in a switch can be a very good way of handling events in an interrupt. Key is though, that you have to know how switches in CCS 'work'. If you only use sequential switch values, _and don't have a 'default'_, CCS will code switches for more than perhaps half a dozen cases, as a 'jump table'. Means that each switch takes the same time, and in fact is identical to the time needed for a single array access. Perfectly sensible and very acceptable in the interrupt. One of the few cases where you can have apparently very 'long' code in the interrupt safely.

Then there is the general comment 'keep the number of interrupts as low as possible'. Point here is that every interrupt present, increases the potential worst case latency of the other interrupts. If you need five timers, then consider instead having a single master 'tick', and using this to do all the timings. It always sounds so 'nice' to have a separate timer for eah thing, but it comes with dangers.

Unfortunately, CCS does not optimise the interrupt code, instead saving every register that 'might' be used in the handlers. For most things the difference is small (and in fact as soon as you do things like array accesses, things like the table pointers need to be saved, so this is not unreasonable). However for truly optimal responses, manual handling of what to save, is worthwhile.

On accessing a variable, there are two ways of doing this:

[Micro_Guy]

These tips have already proven very beneficial. Thanks for all your help. Always glad to learn more.