reubenwilcock@hotmail.com wrote:
> 
> Yes well I eventually found the problem, by making another PIC
> read the first one, and a few of you were right - the PC was at
> fault. It was just dropping characters for no reason.
> 
> Thanks for all the help! I have doubled the interrupt period and
> it doesnt happen any more, but still, pretty pathetic if you ask
> me that a 2Gig PC cannot keep up with a PIC!

Of course we were right.  We have dealt with Micro$loth OSs
before.  It's not the PC, its the alleged programming of it.

-- 
"If you want to post a followup via groups.google.com, don't use
 the broken "Reply" link at the bottom of the article.  Click on 
 "show options" at the top of the article, then click on the 
 "Reply" at the bottom of the article headers." - Keith Thompson

Yes well I eventually found the problem, by making another PIC read the
first one, and a few of you were right - the PC was at fault. It was
just dropping characters for no reason.

Thanks for all the help! I have doubled the interrupt period and it
doesnt happen any more, but still, pretty pathetic if you ask me that a
2Gig PC cannot keep up with a PIC!

Reuben

"CBarn24050" <cbarn24050@aol.com> wrote in message
news:20050115110218.02088.00000022@mb-m14.aol.com...
> >Subject: Re: Strange behaviour in PIC18 interrupt
> >From: Jim Granville no.spam@designtools.co.nz
> >Date: 15/01/2005 02:27 GMT Standard Time
> >Message-id: <41e87f51$1@clear.net.nz>
> >
> >R. Wilcock wrote:
> >
> >> I am using a PIC18F4320 and have been trying to solve a very
strange
> >> problem..
>
> >> I have configured an interrupt using Timer1 which fires every 1ms.
In
> >> that interrupt an ascii character gets sent, and is incremented,
every
> >> time. Also, every 79 interrupts another section of the code gets
> >> executed, which just sends a '%' and resets the ascii code to '1'.
>
> I saw this post before but due to a glitch it got wiped before I had a
chance
> to reply. If I remeber right you were losing characters and your code
had no
> handshaking protocal.You might at first think that a high speed uart
with a
> fifo and a 3Ghz processor could keep up with a little PIC, sadly not.
You must
> implement some handshaking, xon/xoff is best as it needs less harware
but
> cts/rts is easier on the software.

I'm inclined to agree with this.  Even at only one character per mS, if
windows zones out for 16mS you have lost data.  It doesn't sound
sensible, but I could easily see windows being out to lunch and not
servicing interrupts for the 100mS needed to cause your data loss.  In
fact I've seen a PC freeze intermittently (due to a brain dead VXD
device driver) so badly that the clock lost hours per day because of all
the lost timer ticks (these only occur every 50 something mS).  If you
use OE for email and have large numbers of records in your folders,
win98 will freeze the machine (mouse even stops moving) while rifling
thru the database and toss timer ticks out.  It's really kinda sad.  I'd
trust a DOS terminal program or even another PIC long before believing
anything hyperterm showed me.

>Subject: Re: Strange behaviour in PIC18 interrupt
>From: Jim Granville no.spam@designtools.co.nz 
>Date: 15/01/2005 02:27 GMT Standard Time
>Message-id: <41e87f51$1@clear.net.nz>
>
>R. Wilcock wrote:
>
>> I am using a PIC18F4320 and have been trying to solve a very strange
>> problem..

>> I have configured an interrupt using Timer1 which fires every 1ms. In
>> that interrupt an ascii character gets sent, and is incremented, every
>> time. Also, every 79 interrupts another section of the code gets
>> executed, which just sends a '%' and resets the ascii code to '1'.

I saw this post before but due to a glitch it got wiped before I had a chance
to reply. If I remeber right you were losing characters and your code had no
handshaking protocal.You might at first think that a high speed uart with a
fifo and a 3Ghz processor could keep up with a little PIC, sadly not. You must
implement some handshaking, xon/xoff is best as it needs less harware but
cts/rts is easier on the software.

Interesting one... I don't know PIC in depth, but here are some 
obervations...

* I see you are using 8-N-1 in the screenshot, so this isn't a clock 
slip / parity failure, or you'd see garbage.  It'd seem the USART is not 
sending at all.

* The values keep incrementing, so clearly the ISR keeps firing.  Again, 
you need to focus on why the USART isn't sending.

* I only see 2 skips in the screen shot - one is ~63 characters, the 
other is ~73. They're ~882 characters apart.  Look for more patterns 
like this and see if you can find trends that hint at a cause.  (Like, 
is the number of milliseconds or characters consistant at different baud 
rates?)

* Does the USART support any hardware flow controls?  Are their inputs 
floating?

* Have you tried checking (halting on) USART status flags before / after 
loading the USART buffer?  Maybe it's reporting a condition that you're 
ignoring.  At 1mS & 115Kb, it shouldn't ever fill up, but this might 
narrow your search.

* What's your USART accuracy at 115Kb with 10MHz vs. 40MHz?  I'd suggest 
you're cutting your timing budget too close, but if it happens at lower 
baud rates too, this isn't likely the issue.  Have you checked your 
bit/byte timing with a scope to confirm the accuracy?

Cheers,
Richard

R. Wilcock wrote:

> I am using a PIC18F4320 and have been trying to solve a very strange
> problem..
> 
> I have configured an interrupt using Timer1 which fires every 1ms. In
> that interrupt an ascii character gets sent, and is incremented, every
> time. Also, every 79 interrupts another section of the code gets
> executed, which just sends a '%' and resets the ascii code to '1'.

  So you have two code blocks that want to use the UART, one of which is
a timerINT - or the UART is ONLY under the 1msINT control, which 78/79
does CH_TX, and 1/79 does %_TX ?

> 
> Nothing else is going on AT ALL in the program (i.e. no main routines
> at all). There are NO other interrupts running, just this one. The PIC
> is running at 40MHz and the serial comms are at 115,200 baud. Looking
> at the output on hyperterminal, it works fine streaming these lines of
> 79 ascending ascii characters and then a '%' then periodically, about
> every 13 lines of this some characters get missed. Its really odd.
> 
> Changing the baud rate makes no change at all to the problem. Changing
> the interrupt rate even just the tiniest bit either makes the problem
> never occur or occur much much less often. Changing the clock rate
> also makes the problem disappear (from 40MHz to 10MHz). 

There are clues there. Sounds like a classic aperture effect - hard
part is to figure out where/what the critical aperture is :)
You could very slowly sweep the timer rate, and try and track the 
failure pattern.
What about other clocks, between 10Mhz and 40MHz ?
-jg

On 13 Jan 2005 06:52:56 -0800, the renowned reubenwilcock@hotmail.com
(R. Wilcock) wrote:

>I am using a PIC18F4320 and have been trying to solve a very strange
>problem..
>
>I have configured an interrupt using Timer1 which fires every 1ms. In
>that interrupt an ascii character gets sent, and is incremented, every
>time. Also, every 79 interrupts another section of the code gets
>executed, which just sends a '%' and resets the ascii code to '1'.
>
>Nothing else is going on AT ALL in the program (i.e. no main routines
>at all). There are NO other interrupts running, just this one. The PIC
>is running at 40MHz and the serial comms are at 115,200 baud. Looking
>at the output on hyperterminal, it works fine streaming these lines of
>79 ascending ascii characters and then a '%' then periodically, about
>every 13 lines of this some characters get missed. Its really odd.
>
>Changing the baud rate makes no change at all to the problem. Changing
>the interrupt rate even just the tiniest bit either makes the problem
>never occur or occur much much less often. Changing the clock rate
>also makes the problem disappear (from 40MHz to 10MHz). 

This is a clue. Have you checked the errata for the chip? More
specifically, have you checked the errata for the chip you are using,
not for the latest silicon revision (or, alternately, tried the
silicon revision that is current). There were a number of "issues"
with early 18F parts running at full speed. 


Best regards, 
Spehro Pefhany
-- 
"it's the network..."                          "The Journey is the reward"
speff@interlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com

On 13 Jan 2005 06:52:56 -0800, reubenwilcock@hotmail.com (R. Wilcock)
wrote:
>I am using a PIC18F4320 and have been trying to solve a very strange
>problem..
>
>I have configured an interrupt using Timer1 which fires every 1ms. In
>that interrupt an ascii character gets sent, and is incremented, every
>time. Also, every 79 interrupts another section of the code gets
>executed, which just sends a '%' and resets the ascii code to '1'.
>
>Nothing else is going on AT ALL in the program (i.e. no main routines
>at all). There are NO other interrupts running, just this one. The PIC
>is running at 40MHz and the serial comms are at 115,200 baud. Looking
>at the output on hyperterminal, it works fine streaming these lines of
>79 ascending ascii characters and then a '%' then periodically, about
>every 13 lines of this some characters get missed. Its really odd.
>
>Changing the baud rate makes no change at all to the problem. Changing
>the interrupt rate even just the tiniest bit either makes the problem
>never occur or occur much much less often. Changing the clock rate
>also makes the problem disappear (from 40MHz to 10MHz). I literally
>have been stripping the program down to find the problem and its just
>one interrupt routine now, sending this data - note I even got rid of
>the context saving at the start and end to see if that helped...:
>
>int
>	btfsc	PIR1,0		; check if its the timer
>	goto	int_timer1	; in which case service the interrupt
>	goto	int_end		; else go to the end
>int_timer1		        ; comes here every 1.0002ms
>	incf	SPECIAL
>	movf	SPECIAL,W
>	addlw	0x30		; so we are in numbers
>	movwf	TXREG
>	movlw	Timer1L		; setup the timer period again
>	movwf	TMR1L		;
>	movlw	Timer1H		;
>	movwf	TMR1H		;
>	bcf	PIR1,0	        ; clear the flag
>	decfsz	INTDIV1		; divide the interrupt by 10
>	goto	int_end
>int_timer2
>	clrf	SPECIAL
>	movlw	'%'
>	movwf	TXREG
>	movlw	IntDiv				
>	movwf	INTDIV1		;
>int_end				;
>	retfie			; return from int
>
>Any suggestions? I couldn't paste the output from hyperterminal in
>here because the wrapping messed it up - go here for a screen shot:
>
>http://www.ecs.soton.ac.uk/~rw3/problems.jpg
>
>you can see the weird glitch happening three times in that window.
>
>Hope someone can help! I could of course just change the interrupt
>rate which solves it, but I would like to know the cause of the
>problem, Cheers, Reuben

Reuben,
Can you post the entire program with initialization?
Any chance the watchdog time has been enabled?
How is int_timer2 accessed?
Do you have Timer1 configured for 8bit or 16bits writes?

"A write to the high byte of Timer1 must also take place
through the TMR1H Buffer register. Timer1 high byte is
updated with the contents of TMR1H when a write
occurs to TMR1L. This allows a user to write all 16 bits
to both the high and low bytes of Timer1 at once.
The high byte of Timer1 is not directly readable or writable
in this mode. All reads and writes must take place
through the Timer1 High Byte Buffer register. Writes to
TMR1H do not clear the Timer1 prescaler. The
prescaler is only cleared on writes to TMR1L."

Thanks for all the responses:

Iain: this is something I am trying to determine right now. I believe that 
it is not the computer, because I have tried different baud rates and 
exactly the same thing happens (even with very slow baud rates). I have 
tried 3 different serial monitors and all three show the same thing.

Thad: The timer registers are such that you update the high one then the low 
one and only when you have updated the low one, both are written (i.e. the 
regs you write to are not the actual timer regs). The idea of having another 
PIC to check the output is a good idea - I had planned to do this today.

CBFalconer: The problem was originally spotted when the normal program 
functionality was running, which contained plenty of end of regular 
terminated lines, so this is not the problem. I have tried it with 3 
terminal programs and all show the same response. This is direct to serial, 
not with USB VCP.

Ppelectron: I doubt that I am sending it too often - once every ms is 
nothing for a baud rate of 115,200. In any case, the original program had 
plenty of spaces and end of line characters etc.. and the problem was still 
there (this example I have put is just to try and nail down to the problem).

Any more suggestions?

Cheers,

Reuben

>I am using a PIC18F4320 and have been trying to solve a very strange
>problem..
>
>I have configured an interrupt using Timer1 which fires every 1ms. In
>that interrupt an ascii character gets sent, and is incremented, every
>time. Also, every 79 interrupts another section of the code gets
>executed, which just sends a '%' and resets the ascii code to '1'.
>
>Nothing else is going on AT ALL in the program (i.e. no main routines
>at all). There are NO other interrupts running, just this one. The PIC
>is running at 40MHz and the serial comms are at 115,200 baud. Looking
>at the output on hyperterminal, it works fine streaming these lines of
>79 ascending ascii characters and then a '%' then periodically, about
>every 13 lines of this some characters get missed. Its really odd.
>
>Changing the baud rate makes no change at all to the problem. Changing
>the interrupt rate even just the tiniest bit either makes the problem
>never occur or occur much much less often. Changing the clock rate
>also makes the problem disappear (from 40MHz to 10MHz). I literally
>have been stripping the program down to find the problem and its just
>one interrupt routine now, sending this data - note I even got rid of
>the context saving at the start and end to see if that helped...:
>
>int
>	btfsc	PIR1,0		; check if its the timer
>	goto	int_timer1	; in which case service the interrupt
>	goto	int_end		; else go to the end
>int_timer1		        ; comes here every 1.0002ms
>	incf	SPECIAL
>	movf	SPECIAL,W
>	addlw	0x30		; so we are in numbers
>	movwf	TXREG
>	movlw	Timer1L		; setup the timer period again
>	movwf	TMR1L		;
>	movlw	Timer1H		;
>	movwf	TMR1H		;
>	bcf	PIR1,0	        ; clear the flag
>	decfsz	INTDIV1		; divide the interrupt by 10
>	goto	int_end
>int_timer2
>	clrf	SPECIAL
>	movlw	'%'
>	movwf	TXREG
>	movlw	IntDiv				
>	movwf	INTDIV1		;
>int_end				;
>	retfie			; return from int
>
>Any suggestions? I couldn't paste the output from hyperterminal in
>here because the wrapping messed it up - go here for a screen shot:
>
>http://www.ecs.soton.ac.uk/~rw3/problems.jpg
>
>you can see the weird glitch happening three times in that window.
>
>Hope someone can help! I could of course just change the interrupt
>rate which solves it, but I would like to know the cause of the
>problem,
>
>Cheers,
>
>Reuben
>
>

Sounds like you are sending too quickly for hyperterminal. Try putting some
pauses into the stream, say every 16 bytes, or maybe implement XON/XOFF or
hardware handshaking.