HIGH_INTS=true and HIGH interrupt keyword

meereck · Joined: 09 Nov 2006 Posts: 173

Hello, perhaps it is normal behaviour or it may be a bug within my compiler (3.242):
If i use "#device HIGH_INTS=true", I also have to put "HIGH" keyword in one interrupt definition - example "#int_CCP1 HIGH".
If I dont specify any interrupt routine to be "HIGH", the PIC behaves weird. Basically, data sent over the serial line gets corrupted, unless I use smthng like this:

Ken Johnson · Joined: 23 Mar 2006 Posts: 197 Location: Lewisburg, WV

Yes, I had that same issue with 3.249 - copied part of a project with "#device HIGH_INTS=true", but didn't have any high ints. Took a good while to find (actually, ccs found this for me).

Don't know if the problem persists in V4.xxx

Ken

Ttelmah · Guest

It is worth remembering, that if interrupt priority is turned 'on' (which is what the high_ints keyword does), _some_ interrupts are automatically 'high', so (on most chips) the 'INT_EXT' interrupt will always be HIGH, once this is set. Now, CCS normally handles this OK, but only builds the actual 'handler', when a high priority interrupt is 'met'. Without this, the RB interrupt will vector into an undefined area below the normal handler code, and will _really_ screw things up!.... This is part of the reason why they have the option in the device statement, rather than just enabling high priority interrupts 'automatically' if the fast, or high keywords are met. There are a whole sequence of possible problems, when changes like this are triggered without the right code being present.
Really (common with a lot of the CCS stuff), the manual ought to make it much more plain that this option should _only_ be enabled if you are using high priority interrupts.

Best Wishes