 |
 |
| View previous topic :: View next topic |
| Author |
Message |
bsodmike
Joined: 05 Aug 2006
Posts: 52
|
| CCS & Interrupts. |
 Posted: Mon Oct 02, 2006 1:51 am |
 |
|
Hi,
I was reading about this and it has me concerned as the interrupt I've setup is being neglected in many functions including 'delay_ms()' etc etc.
| Quote: | | Due to the limited hardware stack of the PIC a limitation of the CCS compiler is the disability to use recursion in functions. This drawback will affect customers if they try to call a function in an interrupt that is also called outside of an interrupt. When you see this warning message, the compiler is letting you know that you are calling a function inside an interrupt that is also called outside of the interrupt. To prevent accidental recursion the compiler will disable interrupts when you call that specific function outside of that interrupt. |
This is affecting my code as I have an implementation of TMR1, and since I want to use TMR1 to produce delays of under 5ms on 20Mhz PIC and with a 1/8th pre-scaler due to being a 16-bit counter/timer it would result in a 104.85ms before each overflow. With a 1:1 pre-scaler (as I have it now) it would result in a ~13ms timeout, which is still far too big.
Therefore, I'm manually re-writing the TMR1L/TMR1H to a known value to force the small delays I need, but due to the above problem once the PC is inside one of the functions that have the interrupts disabled, it could potentially allow the TMR1 interrupt to overflow but not cause an interrupt. Therefore, once it leaves one of those routines and interrupts are enabled, the interrupt may occur with an unknown delay...or never occur if it enters another routine in-which the interrutps are delayed in...
As you can see, it's causing a couple headaches...
(a) Is there anyway I can re-write the ISR dispatcher, i.e. have the compiler *not* do this? iirc 'org 0x04' was the interrupt vector and with Hi-Tech it was something along the lines of,
interrupt void ISR(void); // that sets up the int_vector.
...I could then setup the interrupts by managing the registers by hand
(b) is there anyway to disable this feature without having to attempt (a)?
Last edited by bsodmike on Mon Oct 02, 2006 2:00 am; edited 2 times in total |
|
 |
PCM programmer
Joined: 06 Sep 2003
Posts: 21708
|
|
|
bsodmike
Joined: 05 Aug 2006
Posts: 52
|
|
| Posted: Mon Oct 02, 2006 2:05 am |
|
|
Thanks PCM. For the delay that's ok, but what about the rest of the functions?
Most of the functions in the mainloop are going to be called inside the isr at least once, therefore all these functions would cause the interrupts to disable.
Does this mean that I would need to re-define all the other routines? Seems like it's going to result in a lot of wastage of ROM to the extent of not fitting in this 4K PIC anymore :S
The way I see it, what I will have to do is to clear the TMR1 at the end of each routine, so that TMR1 starts off from a known state once the interrupts are re-enabled? ...this still leaves me with the problem of not having interrupts while in the other routines hrm... |
|
|
Neutone
Joined: 08 Sep 2003
Posts: 839
Location: Houston
|
|
| Posted: Tue Oct 03, 2006 2:40 pm |
|
|
| You could always write your own delay routine. That would be easier than fooling with the interupts. |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Oct 04, 2006 2:43 am |
|
|
Seriously, you are approaching interrupts the wrong way, if you want to put calls to most of your code inside them.
Think instead, how things are done in the PC. The interrupt code corresponds to the hardware driver level, which is largely pre-written, and only touched if you are a hardware developer writing their own driver. At this level, things should never delay for more than a very few clock cycles needed to generate the right timings. All the actual 'program', is done in the external code, where if you want, you can implement a state machine that calls any required function, when it receives a 'message' from the interrupt code.
You need to rethink how your program is actually structured to make interrupts really work for you. The more you put into the interrupt handler, the less likely it is that the system will work...
Best Wishes |
|
|
bsodmike
Joined: 05 Aug 2006
Posts: 52
|
|
| Posted: Wed Oct 04, 2006 2:17 pm |
|
|
Ttelmah,
Thanks for the info, what you say makes quite a lot of sense and I'm thinking of shifting the routines from the maincode into the interrupt letting it be serviced on a timely basis.
| Quote: | | All the actual 'program', is done in the external code, where if you want, you can implement a state machine that calls any required function, when it receives a 'message' from the interrupt code. |
Hrm, I might give this some further thought and implement something similar 
Cheers,
Mike
Last edited by bsodmike on Wed Oct 04, 2006 2:47 pm; edited 1 time in total |
|
|
Ttelmah
Guest
|
|
| Posted: Wed Oct 04, 2006 2:30 pm |
|
|
Do it the other way. Shift the code from the interrupts into the main. Interrupt handlers want to be as small/fast as possible.
Best Wishes |
|
|
bsodmike
Joined: 05 Aug 2006
Posts: 52
|
|
| Posted: Wed Oct 04, 2006 2:47 pm |
|
|
| Ah gotcha, thanks for the tip |
|
|
|
|
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
|
FAQ 
Search
Register
Profile 
Log in to check your private messages 
Log in
