View previous topic :: View next topic |
Author |
Message |
EdWaugh
Joined: 07 Dec 2004 Posts: 127 Location: Southampton, UK
|
Timer1 interrupt affected by fprintf %lu |
Posted: Thu May 01, 2008 8:19 am |
|
|
Hi guys,
I've found a little problem, it is not critical to my design but it would be nice to understand it...
I using compiler version 3.249 with a PIC18f6723. I had to create a new processor file for this which I made identical to the PIC18f6722 but I removed the tag for the high interrupt workaround. Any comments on this plan would be appreciated but it seems to be working.
My problem is that I am using a timer1 overflow to trigger an external A2D conversion. This data is chucked into a buffering system and then written to an MMC card as required. This seems to work great, the problem is when I put a debug statement in the mmc write function that includes two 32bit uints:
fprintf(STRM,"stuff= %lu, more stuff= %lu", stuff, mstuff);
When I scope my timing test lines I can see that during this statement I get two periods where the timer1 interrupt is slow (5kHz down to 3.8KHz). Its execution time is the same but it's like it is delayed. If I replace the line with a pure string then I do not see the effect.
Are CCS disabling interrupts during their fprintf routine? If so, why would they do that? It seems crazy!
Any comments are welcome.
cheers
ed |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu May 01, 2008 10:52 am |
|
|
Enable the compiler warnings. Re-compile and see what it says. |
|
|
EdWaugh
Joined: 07 Dec 2004 Posts: 127 Location: Southampton, UK
|
|
Posted: Thu May 01, 2008 11:00 am |
|
|
I'm sorry but I don't know how to do that. Are compiler warnings not enabled by default? It never seems to warn me about anything, I thought I was just brilliant! |
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu May 01, 2008 11:07 am |
|
|
In MPLAB, you go to the Project menu, then to Build Options, and on
the compiler tab there is a tickbox for "Show Warnings". I don't know
how to do it in the CCS IDE. |
|
|
EdWaugh
Joined: 07 Dec 2004 Posts: 127 Location: Southampton, UK
|
|
Posted: Thu May 01, 2008 11:17 am |
|
|
The best I could find was to add the line:
#ignore_warnings NONE
which I have put in a header called at the start of my code. I still get no reports tho. I can't find anything within the IDE and adding +EA to the ccsc.ini file had no effect either...
Maybe someone else knows! |
|
|
ckielstra
Joined: 18 Mar 2004 Posts: 3680 Location: The Netherlands
|
|
Posted: Thu May 01, 2008 11:30 am |
|
|
Quote: | Are CCS disabling interrupts during their fprintf routine? If so, why would they do that? It seems crazy! | Is this stream using a hardware or software UART? Disabling interrupts for a soft UART makes sense, but as far as I know the default behaviour is to allow interrupts unless you have specified DISABLE_INT in the #use rs232 setup. |
|
|
EdWaugh
Joined: 07 Dec 2004 Posts: 127 Location: Southampton, UK
|
|
Posted: Thu May 01, 2008 3:40 pm |
|
|
It's a hardware UART stream and I haven't disable interrupts. I don't think it is the actual outputting that is the problem tho as when I remove the %lu and just output a fixed string of the same length the effect does not occur.
Maybe it is not interrupts being disabled. Could anything else cause the Timer1 overflow to be delayed? |
|
|
Jerry I
Joined: 14 Sep 2003 Posts: 96 Location: Toronto, Ontario, Canada
|
Re: Timer1 interrupt affected by fprintf %lu |
Posted: Thu May 01, 2008 4:20 pm |
|
|
EdWaugh wrote: | Hi guys,
I've found a little problem, it is not critical to my design but it would be nice to understand it...
I using compiler version 3.249 with a PIC18f6723. I had to create a new processor file for this which I made identical to the PIC18f6722 but I removed the tag for the high interrupt workaround. Any comments on this plan would be appreciated but it seems to be working.
My problem is that I am using a timer1 overflow to trigger an external A2D conversion. This data is chucked into a buffering system and then written to an MMC card as required. This seems to work great, the problem is when I put a debug statement in the mmc write function that includes two 32bit uints:
fprintf(STRM,"stuff= %lu, more stuff= %lu", stuff, mstuff);
IS THIS FPRINTF STATEMENT IN YOUR INTERRUPT ROUTINE. THIS WILL DELAY THE EXIT OF THE INTERRUPT ROUTINE AND MAY THROW OFF TIMING.
When I scope my timing test lines I can see that during this statement I get two periods where the timer1 interrupt is slow (5kHz down to 3.8KHz). Its execution time is the same but it's like it is delayed. If I replace the line with a pure string then I do not see the effect.
Are CCS disabling interrupts during their fprintf routine? If so, why would they do that? It seems crazy!
Any comments are welcome.
cheers
ed |
|
|
|
PCM programmer
Joined: 06 Sep 2003 Posts: 21708
|
|
Posted: Thu May 01, 2008 4:27 pm |
|
|
Post a very short program that shows the problem. Cut out every line
of code that isn't needed to show the problem. Test the program in
hardware to make sure that it still shows the problem. But it must be
compilable with no errors. Then post it. |
|
|
EdWaugh
Joined: 07 Dec 2004 Posts: 127 Location: Southampton, UK
|
|
Posted: Thu May 01, 2008 4:38 pm |
|
|
Hi guys,
No the line is not in the interrupt it is serviced as part of a polling system that responds to a flag.
As my code works when I eliminate this I'm not sure I've got the time to play with it too much but if I get round to it I'll try and post something. |
|
|
|