|
|
View previous topic :: View next topic |
Author |
Message |
asmallri
Joined: 12 Aug 2004 Posts: 1635 Location: Perth, Australia
|
CCS Manual Problem.. |
Posted: Sun Oct 01, 2006 5:04 am |
|
|
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
|
|
Posted: Sun Oct 01, 2006 5:25 am |
|
|
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
|
|
Posted: Sun Oct 01, 2006 6:04 am |
|
|
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
|
|
Posted: Sun Oct 01, 2006 7:03 am |
|
|
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...
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
|
|
Posted: Sun Oct 01, 2006 7:17 am |
|
|
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
|
|
Posted: Sun Oct 01, 2006 2:26 pm |
|
|
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
|
|
Posted: Sun Oct 01, 2006 2:49 pm |
|
|
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 |
|
|
|
|
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
|