View previous topic :: View next topic |
Author |
Message |
cerr
Joined: 10 Feb 2011 Posts: 241 Location: Vancouver, BC
|
General debugging question |
Posted: Thu Mar 03, 2011 11:38 am |
|
|
Hi There,
My program works fine so far. I'm using a set of 16bit timers to set a outputs in a frequency of approx 50Hz and the use a second set of 8bit timers to reset the ouput after X us - right now I set it up to reset after 200uS. I look at it with the Parallax USB oscilloscope - not sure if anyone here has experience with that. The problem with it is, it is cheap and i'm not sure how much i can trust it. My worries are that my output signals seem choppy, meaning if i set the time base to 10ms i see spikes every 20ms (at 50Hz) but every now and then (every 2nd sample or so), one of these spikes disappears but then they come back in the correct phase....
The code in the ISRs looks like this:
Code: |
#INT_TIMER0
void TIMER0_isr() {
set_timer0(timval);
output_high(MCU1_SYNC);
set_timer6(0); // set timer6 to reset sync pulse
}
|
Nothing fancy and to set the pin, it doesn't depend on anything, just set it, PERIOD! And timval doesn't change unless I change the frequency in my config, that's a sure!
The "reset isr" looks like this:
Code: |
#INT_TIMER6
void TIMER5_isr()
{
set_timer6(0);
output_low(MCU1_SYNC);
}
|
I don't really see what could be wrong here other than the Parallax thingy...any ideas, clues, hints?
What I could do, is increment a count variable and show it when it reaches 3000 to verify it actually showed up after 1 min but i don't know how exact that is as i can only stop the time "by hand" any other debugging ideas?
Thanks! |
|
|
sseidman
Joined: 14 Mar 2005 Posts: 159
|
|
Posted: Thu Mar 03, 2011 3:57 pm |
|
|
I don't know anything about the Parallax USB scope, but if I were worried about whether it was working or not, and there were a second analog channel available, I'd run a function generator onto the second channel, with a sine wave of appropriate frequency. If the sine wave is distorted, the USB scope is failing you.
Other than that, its a bit hard to advise you. You gotta have some bench gear you can trust. |
|
|
cerr
Joined: 10 Feb 2011 Posts: 241 Location: Vancouver, BC
|
|
Posted: Thu Mar 03, 2011 5:23 pm |
|
|
I have figured something out, besides that my scope might be messing up things, it seems as if my RS-232 communication would be interferring with my timers as well, is there a way to lower the priority of the hardware USART when sending out characters? I mean, is there a posibility to slow down the way data are being transmitted in order to give time to the interrupt in between characters? |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Fri Mar 04, 2011 1:41 am |
|
|
cerr wrote: | I have figured something out, besides that my scope might be messing up things, it seems as if my RS-232 communication would be interferring with my timers as well, is there a way to lower the priority of the hardware USART when sending out characters? I mean, is there a posibility to slow down the way data are being transmitted in order to give time to the interrupt in between characters? |
If your USART routine is just software plugging of chars to TXREG, then the USART routine is at the mercy of the interrupts that do take priority. _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
cerr
Joined: 10 Feb 2011 Posts: 241 Location: Vancouver, BC
|
|
Posted: Fri Mar 04, 2011 11:12 am |
|
|
Uh, but i'm using the hardware USARTs (18F87k22):
Code: | #use rs232(baud=9600,parity=N,xmit=PIN_G1,rcv=PIN_G2,stream=MCU1)
#use rs232(baud=9600,parity=N,xmit=PIN_C6,rcv=PIN_C7,bits=8,stream=DEBUG) |
Shouldn't the actual send out of characters happen independently from processing the rest of the code (ISRs)? |
|
|
cerr
Joined: 10 Feb 2011 Posts: 241 Location: Vancouver, BC
|
Re: General debugging question |
Posted: Fri Mar 04, 2011 11:24 am |
|
|
cerr wrote: |
Code: |
#INT_TIMER6
void TIMER6_isr()
{
set_timer6(0);
output_low(MCU1_SYNC);
}
|
|
Okay, I just realized that above piece of code is responsible for the twitching of the 8 bit timer values! The problem line here is set_timer6(0); - once I removed that line, the twitching stopped. Would that be because when timerX has reached its value, it'll go back to 0 anyways when calling the ISR and "double set"-ting it to 0 doesn't seem to be something it necessarily likes - any explenations?
Thanks |
|
|
bkamen
Joined: 07 Jan 2004 Posts: 1615 Location: Central Illinois, USA
|
|
Posted: Fri Mar 04, 2011 12:50 pm |
|
|
I don't think I would code up timers to operate at different intervals that assert control over the same thing.
You should figure out how to do what you want inside *1* timer routine.. not 2.
Doing it the way you are now is asking for some form of contention. _________________ Dazed and confused? I don't think so. Just "plain lost" will do. :D |
|
|
cerr
Joined: 10 Feb 2011 Posts: 241 Location: Vancouver, BC
|
|
Posted: Fri Mar 04, 2011 12:58 pm |
|
|
bkamen wrote: | I don't think I would code up timers to operate at different intervals that assert control over the same thing.
You should figure out how to do what you want inside *1* timer routine.. not 2.
Doing it the way you are now is asking for some form of contention. |
Huh okay, I have three "sync pins" and they all need to be controllable in different frequencies and be able to have different pulse length.
So what I did, I assigned 3 timers as frequency timers and 3 timers as "reset timers". The frequency timers would kick in, and set a pin at given frequency and then start the associated "reset timer" that would reset the pin after time X. I'm finding out the offsets of the timers to each other and start the frequency timers using simple delay() calls to offset them to each other. Once they're started with their frequency, they happily can do their stuff from point 0 on as they're all working independently. Do you have any recommendation how to solve this differntly?
Hints & suggestions are as always appreciated! |
|
|
|