What might be running in the background that might interfere with the clock source to TimerA? As in, something that would suspend perclk? I'm looking for an error, and I'm seeing a loss of many microseconds on the input capture module. I modified my ISR, to flip a bit whenever I see an edge; the bit flips when it should. Always. But the time recorded is is wrong, oh half the time. It looks like around 24us, and sometimes 48us, low. As if perclk/2 stops for 24us.

What am I looking for? I'm sitting in a while loop, waiting for either 3 edges (it's a PWM measurement) or TimerB timeout. The only thing I can think of, is that I adjusted TimerA1 to ff for the TimerB timeout function; but I want to say that Serial Port A (used for stdio) runs from the perclk/2, not from TimerA1. [Otherwise, I'd be having more issues than just this!] I just tried setting the interupt status to 2 around this while loop; no change. The ISR runs at interupt priority 3; but since the input capture module is set to latch on stop command, jumps to the ISR should not be critical.

?

Shawn

------------------------------------



(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )

Shawn wrote:
> What might be running in the background that might interfere with the clock source to TimerA? As in, something that would suspend perclk? I'm looking for an error, and I'm seeing a loss of many microseconds on the input capture module. I modified my ISR, to flip a bit whenever I see an edge; the bit flips when it should. Always. But the time recorded is is wrong, oh half the time. It looks like around 24us, and sometimes 48us, low. As if perclk/2 stops for 24us.
>
> What am I looking for? I'm sitting in a while loop, waiting for either 3 edges (it's a PWM measurement) or TimerB timeout. The only thing I can think of, is that I adjusted TimerA1 to ff for the TimerB timeout function; but I want to say that Serial Port A (used for stdio) runs from the perclk/2, not from TimerA1. [Otherwise, I'd be having more issues than just this!] I just tried setting the interupt status to 2 around this while loop; no change. The ISR runs at interupt priority 3; but since the input capture module is set to latch on stop command, jumps to the ISR should not be

try running without the debugger. DC is real intrusive and disables
interrups for considerable lengths of time. The standard I/O code is
horribly slow and disables ints while the PC reads the stdio text.

Look at the stdio.lib; there are defines to rout stdio to a serial port.
It can be the programming port if you have a cable with a "Diag"
connector. The new USB and cables with a single connector will not work.

I found getting rid of the debugger a big help as timing is more
consistent; it also runs afaster with smaller code as youc an disable
all the code and RST 28 instructions. I use my network debugger to look
at variables and view stdio as it is low overhead. Only when I have to
single-step through code do I use the DC debugger.

--
------------------------------------------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------------------------------------------

today's fortune
You know what we need, Hobbes? We need an attitude. Yeah, you can't be cool
if you don't have an attitude. -- Calvin

------------------------------------



(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )

--- In r...@yahoogroups.com, Scott Henion wrote:
>
> try running without the debugger. DC is real intrusive and disables
> interrups for considerable lengths of time. The standard I/O code is
> horribly slow and disables ints while the PC reads the stdio text.
>
> Look at the stdio.lib; there are defines to rout stdio to a serial port.
> It can be the programming port if you have a cable with a "Diag"
> connector. The new USB and cables with a single connector will not work.
>
> I found getting rid of the debugger a big help as timing is more
> consistent; it also runs afaster with smaller code as youc an disable
> all the code and RST 28 instructions. I use my network debugger to look
> at variables and view stdio as it is low overhead. Only when I have to
> single-step through code do I use the DC debugger.
>
> --
> ------------------------------------------
> | Scott G. Henion| shenion@... |
> | Consultant | Stone Mountain, GA |
> | SHDesigns http://www.shdesigns.org |
> ------------------------------------------
>
> today's fortune
> You know what we need, Hobbes? We need an attitude. Yeah, you can't be cool
> if you don't have an attitude. -- Calvin
>

Thanks, will look into that today. I've always wondered what that "Diag" connector was for. I just can't find any reference in the documentation yet for it!

Shawn

------------------------------------



(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )

I have a suggestion about the 2 connectors. Get the schematic of the
programming connector and figure out how to put a switch (2 pole) in the
wire before the connectors. You can use the switch to change from PROG
to DIAG (using only the PROG connector) without taking the connector on
and off. These connectors have a limited life and the strain on the
cable taking it off and on can shorten it's life and will cause failures
when you can least afford it.

I haven't had to add a switch to a cable in years, so I don't remember
the wire numbers, but it is well worth the effort. Also, make sure you
always have a spare programming cable anyway!

-Pete

-----Original Message-----
From: r...@yahoogroups.com [mailto:r...@yahoogroups.com]
On Behalf Of Shawn
Sent: Monday, June 22, 2009 9:08 AM
To: r...@yahoogroups.com
Subject: [rabbit-semi] Re: Dynamic C Question

--- In r...@yahoogroups.com, Scott Henion wrote:
>
> try running without the debugger. DC is real intrusive and disables
> interrups for considerable lengths of time. The standard I/O code is
> horribly slow and disables ints while the PC reads the stdio text.
>
> Look at the stdio.lib; there are defines to rout stdio to a serial
port.
> It can be the programming port if you have a cable with a "Diag"
> connector. The new USB and cables with a single connector will not
work.
>
> I found getting rid of the debugger a big help as timing is more
> consistent; it also runs afaster with smaller code as youc an disable
> all the code and RST 28 instructions. I use my network debugger to
> look at variables and view stdio as it is low overhead. Only when I
> have to single-step through code do I use the DC debugger.
>
> --
> ------------------------------------------
> | Scott G. Henion| shenion@... |
> | Consultant | Stone Mountain, GA |
> | SHDesigns http://www.shdesigns.org |
> ------------------------------------------
>
> today's fortune
> You know what we need, Hobbes? We need an attitude. Yeah, you can't
be cool
> if you don't have an attitude. -- Calvin
>

Thanks, will look into that today. I've always wondered what that
"Diag" connector was for. I just can't find any reference in the
documentation yet for it!

Shawn

------------------------------------



(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )

Will look into that.

I turned off the debug kernal option, now it it gives a "no communcation error" right after programming. I close close the connection, change to the diag connector, and I can talk through Hyperterminal. Haven't figured out how to use the stdio window in Dynamic C yet. Of course, that random error is still there, so either I didn't turn off debug, or it's something else...

Shawn

--- In r...@yahoogroups.com, "Fournier, Pete" wrote:
>
> I have a suggestion about the 2 connectors. Get the schematic of the
> programming connector and figure out how to put a switch (2 pole) in the
> wire before the connectors. You can use the switch to change from PROG
> to DIAG (using only the PROG connector) without taking the connector on
> and off. These connectors have a limited life and the strain on the
> cable taking it off and on can shorten it's life and will cause failures
> when you can least afford it.
>
> I haven't had to add a switch to a cable in years, so I don't remember
> the wire numbers, but it is well worth the effort. Also, make sure you
> always have a spare programming cable anyway!
>
> -Pete
>

------------------------------------



(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )

Also, to help reduce the intrusiveness of the Dynamic C Debugger I
precede all functions with "nodebug". You could also use a #define at
the beginning of the file and turn debugging in a file on and off.

//debugging turned on in the function
//#define _DEBUG_SWITCH debug

//debugging turned off in the function
#define _DEBUG_SWITCH nodebug
_DEBUG_SWITCH void fnTest(void)
{

}
-----Original Message-----
From: r...@yahoogroups.com [mailto:r...@yahoogroups.com]
On Behalf Of Scott Henion
Sent: Friday, June 19, 2009 3:52 PM
To: r...@yahoogroups.com
Subject: Re: [rabbit-semi] Dynamic C Question

Shawn wrote:
> What might be running in the background that might interfere with the
clock source to TimerA? As in, something that would suspend perclk?
I'm looking for an error, and I'm seeing a loss of many microseconds on
the input capture module. I modified my ISR, to flip a bit whenever I
see an edge; the bit flips when it should. Always. But the time
recorded is is wrong, oh half the time. It looks like around 24us, and
sometimes 48us, low. As if perclk/2 stops for 24us.
>
> What am I looking for? I'm sitting in a while loop, waiting for
either 3 edges (it's a PWM measurement) or TimerB timeout. The only
thing I can think of, is that I adjusted TimerA1 to ff for the TimerB
timeout function; but I want to say that Serial Port A (used for stdio)
runs from the perclk/2, not from TimerA1. [Otherwise, I'd be having
more issues than just this!] I just tried setting the interupt status
to 2 around this while loop; no change. The ISR runs at interupt
priority 3; but since the input capture module is set to latch on stop
command, jumps to the ISR should not be

try running without the debugger. DC is real intrusive and disables
interrups for considerable lengths of time. The standard I/O code is
horribly slow and disables ints while the PC reads the stdio text.

Look at the stdio.lib; there are defines to rout stdio to a serial port.
It can be the programming port if you have a cable with a "Diag"
connector. The new USB and cables with a single connector will not work.

I found getting rid of the debugger a big help as timing is more
consistent; it also runs afaster with smaller code as youc an disable
all the code and RST 28 instructions. I use my network debugger to look
at variables and view stdio as it is low overhead. Only when I have to
single-step through code do I use the DC debugger.

--
------------------------------------------
| Scott G. Henion| s...@shdesigns.org |
| Consultant | Stone Mountain, GA |
| SHDesigns http://www.shdesigns.org |
------------------------------------------

today's fortune
You know what we need, Hobbes? We need an attitude. Yeah, you can't
be cool
if you don't have an attitude. -- Calvin

------------------------------------



(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )

--- In r...@yahoogroups.com, "Shawn" wrote:
>
> Will look into that.
>
> I turned off the debug kernal option, now it it gives a "no communcation error" right after programming. I close close the connection, change to the diag connector, and I can talk through Hyperterminal. Haven't figured out how to use the stdio window in Dynamic C yet. Of course, that random error is still there, so either I didn't turn off debug, or it's something else...
>
> Shawn
>
I don't know if the new versions of DC have fixed this or not, but if you make too many functions nodebug and only have a few functions marked debug that you want to set breakpoints in, then you get this no communication error because the debug kernel needs to be called often enough to keep it serviced. One solution to this is to lower the debug baud rate so that what few calls do make it into the debug kernel can keep up with what the computer is sending you. You do need to make certain that in the normal routine flow of things, that you are regularly executing debuggable functions.

------------------------------------



(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )

Most of the code has neither debug or nodebug, as it isn't critical. I've tried to keep it mostly debuggable. Plus, at the moment, with no debugging running (turn off debug, set stdio to serial port A, compile to processor, use hyperterminal to talk to the board), I still get this 20us random error. I don't enable RTC options, I'm not running any cofunctions, nothing of the sort. But something is messing with the darn perclk...

I'm back to running with the debugging options on, just for the faster compiling. I wish there was some sort of pre-compile output, where I could see if the RTC was enabled or something. There's something somewheres that sets the processor to run with the clock doubler (as the crystal is 11MHz but the processor is sold as running at 22MHz), and I'm wondering if some sort of interupt is running in the background also.

Shawn

--- In r...@yahoogroups.com, "Robert Richter" wrote:
>
> --- In r...@yahoogroups.com, "Shawn" wrote:
> >
> > Will look into that.
> >
> > I turned off the debug kernal option, now it it gives a "no communcation error" right after programming. I close close the connection, change to the diag connector, and I can talk through Hyperterminal. Haven't figured out how to use the stdio window in Dynamic C yet. Of course, that random error is still there, so either I didn't turn off debug, or it's something else...
> >
> > Shawn
> >
> I don't know if the new versions of DC have fixed this or not, but if you make too many functions nodebug and only have a few functions marked debug that you want to set breakpoints in, then you get this no communication error because the debug kernel needs to be called often enough to keep it serviced. One solution to this is to lower the debug baud rate so that what few calls do make it into the debug kernel can keep up with what the computer is sending you. You do need to make certain that in the normal routine flow of things, that you are regularly executing debuggable functions.
>

------------------------------------



(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )

Just to clarify, _nothing_ ever messes with perclk; it's always there. You can change its frequency, or disable its use by the various peripherals, but that's about it.

But as has been mentioned already, there are all sorts of things that can mess with interrupts -- mainly blocking them with other interrupts :v) Do you have other interrupts (besides the debug serial interrupt) enabled?

You've debugged via scope by flipping a bit; have you checked the count registers at those moments to see if they make sense? Also, have you checked whether the counter overflow bit is set?

-Lynn
--- In r...@yahoogroups.com, "Shawn" wrote:
>
> Most of the code has neither debug or nodebug, as it isn't critical. I've tried to keep it mostly debuggable. Plus, at the moment, with no debugging running (turn off debug, set stdio to serial port A, compile to processor, use hyperterminal to talk to the board), I still get this 20us random error. I don't enable RTC options, I'm not running any cofunctions, nothing of the sort. But something is messing with the darn perclk...
>
> I'm back to running with the debugging options on, just for the faster compiling. I wish there was some sort of pre-compile output, where I could see if the RTC was enabled or something. There's something somewheres that sets the processor to run with the clock doubler (as the crystal is 11MHz but the processor is sold as running at 22MHz), and I'm wondering if some sort of interupt is running in the background also.
>
> Shawn
>
> --- In r...@yahoogroups.com, "Robert Richter" wrote:
> >
> > --- In r...@yahoogroups.com, "Shawn" wrote:
> > >
> > > Will look into that.
> > >
> > > I turned off the debug kernal option, now it it gives a "no communcation error" right after programming. I close close the connection, change to the diag connector, and I can talk through Hyperterminal. Haven't figured out how to use the stdio window in Dynamic C yet. Of course, that random error is still there, so either I didn't turn off debug, or it's something else...
> > >
> > > Shawn
> > >
> > I don't know if the new versions of DC have fixed this or not, but if you make too many functions nodebug and only have a few functions marked debug that you want to set breakpoints in, then you get this no communication error because the debug kernel needs to be called often enough to keep it serviced. One solution to this is to lower the debug baud rate so that what few calls do make it into the debug kernel can keep up with what the computer is sending you. You do need to make certain that in the normal routine flow of things, that you are regularly executing debuggable functions.
>

------------------------------------

______________________________
controlSUITE™ software. Comprehensive. Intuitive. Optimized.
Real-world software for real-time control. Details Here!


(You need to be a member of rabbit-semi -- send a blank email to rabbit-semi-subscribe@yahoogroups.com )