View previous topic :: View next topic |
Author |
Message |
ljb
Joined: 19 Nov 2003 Posts: 30
|
Hardware uart and rtcc ? |
Posted: Mon Jul 26, 2004 11:05 am |
|
|
I have a time stamp being updated using the RTCC interrupting on overflow which works fine when left alone.
When data is being sent over the h/w uart the time freezes (noticable when sending large amounts of data).
A loop is executed reading data from ext ram over an i2c bus and sent using printf, until all data are sent.
It looks like the RTCC is being reset each time round the loop, but I have selected NOWDT. Does the h/w uart clear the RTCC for some reason?
Is this correct? and is there a way around it?
I am using a 16f876 @ 16mhz.
Many thanks
Les |
|
|
Haplo
Joined: 06 Sep 2003 Posts: 659 Location: Sydney, Australia
|
|
Posted: Mon Jul 26, 2004 5:17 pm |
|
|
Even with NOWDT selected, a CLRWDT will probably still clear the watchdog prescaler. Do you have the word 'restart_wdt' in your #use rs232 statement by any chance? |
|
|
ljb
Joined: 19 Nov 2003 Posts: 30
|
|
Posted: Tue Jul 27, 2004 2:42 am |
|
|
There are no reference to the wdt, either setting up or to clear.
I was wondering if the h/w uart has some direct connection to rtcc which is implemented when used, how else would it know to clear the wdt if :-
printf("some text");
or
ch=getc();
are used ?
cheers
Les |
|
|
Ttelmah Guest
|
Re: Hardware uart and rtcc ? |
Posted: Tue Jul 27, 2004 3:08 am |
|
|
ljb wrote: | I have a time stamp being updated using the RTCC interrupting on overflow which works fine when left alone.
When data is being sent over the h/w uart the time freezes (noticable when sending large amounts of data).
A loop is executed reading data from ext ram over an i2c bus and sent using printf, until all data are sent.
It looks like the RTCC is being reset each time round the loop, but I have selected NOWDT. Does the h/w uart clear the RTCC for some reason?
Is this correct? and is there a way around it?
I am using a 16f876 @ 16mhz.
Many thanks
Les |
It shouldn't do.
Check though, that you do not have th option 'restart_wdt', in the 'delay' definition.
I'd suggest adding a serial transmit buffer, and implementing the transmit using the transmitter empty interrupt. Sending a reasonable length string, will involve the processor sitting and waiting on the UART for quite long periods. It may be that CCS uses one of the 'delay' functions somewhere in that loop, and even without this option, may be defaulting to clearing the RTCC.
Best Wishes |
|
|
treitmey
Joined: 23 Jan 2004 Posts: 1094 Location: Appleton,WI USA
|
|
Posted: Tue Jul 27, 2004 8:03 am |
|
|
I'm no expert in this area,... perhaps someone else can confirm this...
but if your sending data real real fast, would the #int_TBE for the serial send could be interupting so fast as to not let the timer funtion interupt.
??
maybe a ((fast interupt))) [[scary new area for me : ) ]] that could get in an interupt even as #int_TBE interupt was working.
That is if you are using a TX buffer and interupt driven Tx. |
|
|
Ttelmah Guest
|
|
Posted: Tue Jul 27, 2004 8:10 am |
|
|
treitmey wrote: | I'm no expert in this area,... perhaps someone else can confirm this...
but if your sending data real real fast, would the #int_TBE for the serial send could be interupting so fast as to not let the timer funtion interupt.
??
maybe a ((fast interupt))) [[scary new area for me : ) ]] that could get in an interupt even as #int_TBE interupt was working.
That is if you are using a TX buffer and interupt driven Tx. |
Yes, this could apply, if the priority of the TBE interrupt is below that of the timer interrupt (use the #priority statement to change this), and if the TBE interrupt was rather slow, with a fast data rate. However in general, it shouldn't be a problem (even at 115200 bps, there should be 87uSec between successive interrupts). If the processor clock was slow (like 4MHz), and the TBE interrupt has a lot of code, it is well worth considering.
Best Wishes |
|
|
Ttelmah Guest
|
|
Posted: Tue Jul 27, 2004 8:12 am |
|
|
Change this to say if the priority of the TBE interrupt is _above_ that of the timer interrupt...
:-)
Best Wishes |
|
|
Mark
Joined: 07 Sep 2003 Posts: 2838 Location: Atlanta, GA
|
|
Posted: Tue Jul 27, 2004 8:24 am |
|
|
Actually a problem could occur no matter what the data rate if the programmer does not disable the TBE int when all the data has been transmitted since the flag bit is controlled by hardware. |
|
|
|