CCS C Software and Maintenance Offers
FAQFAQ   FAQForum Help   FAQOfficial CCS Support   SearchSearch  RegisterRegister 

ProfileProfile   Log in to check your private messagesLog in to check your private messages   Log inLog in 

CCS does not monitor this forum on a regular basis.

Please do not post bug reports on this forum. Send them to CCS Technical Support

CCS Manual Problem..

 
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion
View previous topic :: View next topic  
Author Message
asmallri



Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

CCS Manual Problem..
PostPosted: Sun Oct 01, 2006 5:04 am     Reply with quote

I am trying to work out how to specify a specific interrupt handler is high, fast and no clear.

PCH v3.243 (had wrong version listed)

I have #device high_ints = true specified

I expect it to be of the form:
#int_timer3 high, fast, noclear

but the compiler spits the dummy for the high "macro" at the #int_timer3 line. The compiler will not accept high anywhere on the #int_timer3 line.

The #int section of the manual refers the reader to the #device section for building the high priority handlers but it does not provide any information on it.

Can someone enlighten me?
_________________
Regards, Andrew

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


Last edited by asmallri on Sun Oct 01, 2006 6:05 am; edited 1 time in total
Ttelmah
Guest







PostPosted: Sun Oct 01, 2006 5:25 am     Reply with quote

3.143, is _old_.
It predates the introduction of the '#device high_ints=true' command.
It only supports one 'high priority' keyword, 'fast'. You can spcify just _one_ interrupt as 'fast', and this wll then have the high priority control bit set. The compiler requires _you_ to do everything for this interrupt (it will not save the registers, and will not clear the interrupt for you).
Beware, that on most (all?) chips, if you specify any other interrupt as 'fast', the hardware will also make int_rb0 into a high priority interrupt, and if this interrupt is in use, you will need to add the code to work out which interrupt has occured, and call the required handler.

Best Wishes
asmallri



Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Sun Oct 01, 2006 6:04 am     Reply with quote

sorry typo - it was PCH 3.243
_________________
Regards, Andrew

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







PostPosted: Sun Oct 01, 2006 7:03 am     Reply with quote

OK.
You can only ever use 'one' of 'high', or 'fast' on an interrupt. 'high', triggers the interrupt to be set as high priority, but otherwise to be treated 'normally', with the compiler saving the registers, and clearing the flags. 'fast', also sets the interrupt as high priority, but uses 'retfie 1' on exit. To confuse things, 'high', will also use 'retfie 1', if it is not also in use elsewhere!...
On slightly older compilers, 'fast', would not save the registers (which the manual says), but on current versions, it behaves the same as 'high', including testing the interrupt flags.
Neither command supports 'noclear'....
At present, compiler support or using high priority interrupts, is _worse_ than it was a few versions ago. On older versions, you could just have used 'fast', and then saved the registers yourself, and cleared the interrupt flag yourself. On the current versions, the easiest (and safest...) way to use 'custom' high priority interrupt behaviour is to go completely DIY. Unfortunately, there is no equivalent to the 'int_global' command, for the high priority interrupt handler... Crying or Very sad
So, the easiest way to do what you want, would be to go 'back' to an older compiler, and just use the 'fast' keyword. Round about 3.191, allows this to work.
Sorry, this is an area that is very poor.

Best Wishes
asmallri



Joined: 12 Aug 2004
Posts: 1635
Location: Perth, Australia

View user's profile Send private message Send e-mail Visit poster's website

PostPosted: Sun Oct 01, 2006 7:17 am     Reply with quote

Bummer. No wonder I could not get this to work. It was the do it yourself method I use to use.
_________________
Regards, Andrew

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



Joined: 18 Mar 2004
Posts: 3680
Location: The Netherlands

View user's profile Send private message

PostPosted: Sun Oct 01, 2006 2:26 pm     Reply with quote

Ttelmah wrote:
On slightly older compilers, 'fast', would not save the registers (which the manual says), but on current versions, it behaves the same as 'high', including testing the interrupt flags.
Neither command supports 'noclear'....
I don't know about the behaviour in newer compiler versions like v3.249, but V3.191 added the NOCLEAR option for FAST interrupts. Usage is
Code:
#INT_EXT FAST NOCLEAR   // no comma's


Quote:
So, the easiest way to do what you want, would be to go 'back' to an older compiler, and just use the 'fast' keyword. Round about 3.191, allows this to work.
v3.191 is very old, I'm a happy user of the FAST interrupt in v3.226. My reasons for not upgrading to more recent versions has to do with v3.227 disabling the interrupts in several inbuilt functions. More info on this can be found in http://www.ccsinfo.com/forum/viewtopic.php?t=25535
Ttelmah
Guest







PostPosted: Sun Oct 01, 2006 2:49 pm     Reply with quote

Yes.
The problem is that on latter versions (not sure of the exact switch, but just below 3.200 somewhere), the behaviour of 'fast', was changed, making it nearly identical to 'high'. It therefore does all the register saving.
As an example, this is part of the listing from a 'fast' routine, which does it's own register saving, using 3.191:
Code:

0008:  GOTO   0162
...
0162:  MOVFF  F81,95
0164:  MOVF   x95,W
0168:  XORWF  x94,W
016A:  MOVWF  x96

While the same code, compiled with 3.249, generates:

Code:

0008:  GOTO   00C4
...
00C4:  MOVLB  0
00C6:  MOVFF  FE9,1D
00CA:  MOVFF  FEA,18
00CE:  MOVFF  FE1,19
00D2:  MOVFF  FE2,1A
00D6:  MOVFF  FD9,1B
00DA:  MOVFF  FDA,1C
00DE:  MOVFF  FF3,24
00E2:  MOVFF  FF4,25
00E6:  MOVFF  FFA,26
00EA:  MOVFF  00,1F
00EE:  MOVFF  01,20
00F2:  MOVFF  02,21
00F6:  MOVFF  03,22
00FA:  MOVFF  04,23
00FE:  BTFSS  FF2.3
0100:  GOTO   010A
0104:  BTFSC  FF2.0
0106:  GOTO   01E6
010A:  BTFSS  FF2.4
010C:  GOTO   0116
0110:  BTFSC  FF2.1
0112:  GOTO   02A4
0116:  MOVFF  1F,00
011A:  MOVFF  20,01
011E:  MOVFF  21,02
0122:  MOVFF  22,03
0126:  MOVFF  23,04
012A:  MOVFF  1D,FE9
012E:  MOVFF  18,FEA
0132:  MOVFF  19,FE1
0136:  MOVFF  1A,FE2
013A:  MOVFF  1B,FD9
013E:  MOVFF  1C,FDA
0142:  MOVFF  24,FF3
0146:  MOVFF  25,FF4
014A:  MOVFF  26,FFA
014E:  RETFIE 1
...
01E6:  MOVFF  F81,A6
01EA:  MOVF   xA6,W
01EC:  XORWF  xA5,W
01EE:  MOVWF  xA7

The last four lines are the start of the actual 'routine' (same as for the older compiler), but the earlier stuff is the 'handler' that is now added. There does not appear to be any way of actually turing this 'off', in the latter compilers...
The way I have worked, is to manually force a ROM drective to overwrite this area, or (like you), stick with an older compiler for applications that want this ability, but a tidier solution would be nice.

Best Wishes
Display posts from previous:   
Post new topic   Reply to topic    CCS Forum Index -> General CCS C Discussion All times are GMT - 6 Hours
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum


Powered by phpBB © 2001, 2005 phpBB Group