Searching \ for '[PIC] Noritake -T23A VFD connection' in subject line. ()
Make payments with PayPal - it's fast, free and secure! Help us get a faster server
FAQ page: www.piclist.com/techref/microchip/devices.htm?key=pic
Search entire site for: 'Noritake -T23A VFD connection'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Noritake -T23A VFD connection'
2004\10\13@215159 by Anthony Toft

flavicon
face
This is a long shot question, I am hoping someone here has done this...

I am trying to use a PIC to control a CU20045SCPB-T23A VFD from
Noritake. I can send characters to it at a fairly low rate without
problems however when I send it an escape sequence it sometimes gets
lost and not acted upon properly specifically the cursor movement, this
doesn't seem to be exactly the same everytime, sometimes it works. It
sounds like a timing problem, but I have tried to slow everything down,
but it didn't seem to approve the situation.

Any advice? Noritake aren't offering much at the moment.

Anthony
--
Anthony Toft <spam_OUTtoftatTakeThisOuTspamcowshed.8m.com>
    I'm Anton, and I approve this message

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\14@002738 by redtock8

flavicon
face
part 1 1823 bytes content-type:text/plain; (decoded 7bit)

Take a look at this page. Great LCD info and PIC
example. I used this info to write code for a Noritake
2x20 VFD. Also here is an old code snippet.
Hopes this helps

http://home.iae.nl/users/pouweha/lcd/lcd.shtml
-----------------------------------------------------------------------
-----------------------------------------------------------------
DXTron Technology Inc
PCB Assembly
PIC Chip Programming
-----------------------------------------------------------------
.....redrock8KILLspamspam@spam@dxtron.com
http://www.dxtron.com
-----------------------------------------------------------------
{Original Message removed}
part 2 10479 bytes content-type:application/octet-stream; (decode)

part 3 194 bytes content-type:text/plain; charset="us-ascii"
(decoded 7bit)

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist


part 4 1 bytes

2004\10\14@041815 by Jan-Erik Soderholm

face picon face
Anthony Toft wrote :

> This is a long shot question, I am hoping someone here has
> done this...
>
> I am trying to use a PIC to control a CU20045SCPB-T23A VFD from
> Noritake. I can send characters to it at a fairly low rate...

Serial or Parallel ?

> without
> problems however when I send it an escape sequence it sometimes gets
> lost and not acted upon properly specifically the cursor
> movement, this doesn't seem to be exactly the same everytime,
> sometimes it works. It sounds like a timing problem, but I have tried to slow
> everything down

How "slow"  ?

>, but it didn't seem to approve the situation.
>
> Any advice? Noritake aren't offering much at the moment.

Apart from the data sheet ?

Are you using "Quick Write Mode" or "Flickerless Mode" ?

The "TW" (busy time) for a cursor movment instruction
is about 400 us (or maybe 600us, it's not perfectly clear)
in Quick Write Mode. In Flickerless Mode is "2 to 15 times
longer", according to the data sheet, or 800 us (best case,
2 x 400 us) to 9 ms (worst case, 15 x 600 us).

I had no problem writing some text in serial mode to
the unit, but I didn't used any ESC seq. I have no
units left to test on...

Best Regards,
Jan-Erik.


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\14@044323 by Jan-Erik Soderholm

face picon face
B.t.w,

I currently wiring up a Noritake GU128X32-311
graphical VFD display to a 18F252 just as a test.

Has anyone used that one ?

Jan-Erik.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\14@060113 by Jan-Erik Soderholm

face picon face
Another thing...

> ...however when I send it an escape sequence it sometimes gets
> lost and not acted upon properly...

Are you monitoring the BUSY line from the VFD ?

Jan-Erik.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\14@073848 by Anthony Toft
flavicon
face
> Are you monitoring the BUSY line from the VFD ?

Yes, which is the most frustrating part, the datasheet says to do it. I
am using it in parallel mode, here is the function as it appears in my
code

#DEFINE WR PORTC,0
#DEFINE CS PORTC,1
#DEFINE BUSY PORTC,2

       ; Takes the contents of character and displays it.

DISPLAYCHAR        
       ; wait for BUSY to be low...
WAITBUSY
       BTFSC BUSY
       GOTO WAITBUSY
       ; lower WR
       BCF WR
       
       ; Load  data
       MOVFW character
       MOVWF PORTB
       
       ; raise wr
       BSF WR
       RETURN

Notice I _don't_ use CS, but the datasheet is ambiguous about it, could
that be the problem?

The POSCURSOR function calls this three times to output 0x1B, 'H' and
the position. I have also tried this with various amounts of delay in
here, using NOP anything from one to 255*255. This is on an 16F876A
using a 19.8806Mhz crystal. The circuit can be seen at
http://cowshed.8m.com/car/inputs.html  When I was echoing the serial RX
to screen then it worked flawlessly (in Quick write, no positioning) now
I am working on startup, and probably driving the display pretty fast.
The display is using flickerless mode at this time, but it happens
regardless to the mode. I always seem to display 0x9D, the integration
character, when it doesn't work quite right.

--
Anthony Toft <toftatspamKILLspamcowshed.8m.com>
    I'm Anton, and I approve this message

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\14@101812 by Jan-Erik Soderholm

face picon face
Anthony Toft wrote :

(First, we *are* talking about the Noritake CU20045SCPB-T23A, right ?)

> > Are you monitoring the BUSY line from the VFD ?
>
> Yes, which is the most frustrating part, the datasheet says
> to do it...
> I am using it in parallel mode,...

OK, my tests was done using the serial interface. I only
write "normal" characters to it and didn't use the BUSY line.

{Quote hidden}

Since you are running at (aprox) 20 Mhz, you have an Tcyc of 200 ns.
The mini setup time of the data lines before the rising edge of WR is
100 ns. It *should* be OK, but... There is also a slight delay
from the rising edge of WR until BUSY goes high. Just 200 ns "max"
according to the data sheet, so that should not be a problem. You
cold anyway try to put some NOP's to slow down the "clocking"
a little, just to be safe.

>
> Notice I _don't_ use CS, but the datasheet is ambiguous about
> it, could that be the problem?

I hope not :-)
I'm currently trying to get a similar unit (GU128X32-311) running,
and it also have a CS line that I was planning to set CS hard "low".

>
> The POSCURSOR function calls this three times to output 0x1B, 'H' and
> the position. I have also tried this with various amounts of delay in
> here, using NOP anything from one to 255*255. This is on an 16F876A
> using a 19.8806Mhz crystal. The circuit can be seen at
> http://cowshed.8m.com/car/inputs.html

Is there anything connected to the "Programming" connector ?

>  When I was echoing the
> serial RX
> to screen then it worked flawlessly (in Quick write, no
> positioning) now
> I am working on startup, and probably driving the display pretty fast.
> The display is using flickerless mode at this time, but it happens
> regardless to the mode. I always seem to display 0x9D, the integration
> character, when it doesn't work quite right.

Is in *only* when sending the ESC-sequence for setting the position
that you get problems ? Or just about anythime ?

/Jan-Erik.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\14@103627 by Charles Rogers

flavicon
face

I have a Noritake Gu140X32 being driven by an 18F252,
Haven't downloaded all info from CD as yet but it looks
very good so far.

Charlie R.

> I currently wiring up a Noritake GU128X32-311
> graphical VFD display to a 18F252 just as a test.
>
> Has anyone used that one ?
>
> Jan-Erik.

>

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\14@112619 by toftat

flavicon
face
> (First, we *are* talking about the Noritake CU20045SCPB-T23A, right ?)

Yes, that's the one.

> OK, my tests was done using the serial interface. I only
> write "normal" characters to it and didn't use the BUSY line.

My problem sometimes happens in normal characters, but much more pronounced as
ESC characters

> Since you are running at (aprox) 20 Mhz, you have an Tcyc of 200 ns.

201 and a little bit, I checked this just to make sure...

> The mini setup time of the data lines before the rising edge of WR is
> 100 ns. It *should* be OK, but... There is also a slight delay
> from the rising edge of WR until BUSY goes high. Just 200 ns "max"
> according to the data sheet, so that should not be a problem. You
> cold anyway try to put some NOP's to slow down the "clocking"
> a little, just to be safe.

I put NOPs between the MOVWF PORTB and the BSF WR, I didn't put any after
figuring the RETURN and the following CALL are 2 cycles each, on top of
whatever I do between them in the calling function.

> I hope not :-)
> I'm currently trying to get a similar unit (GU128X32-311) running,
> and it also have a CS line that I was planning to set CS hard "low".

I have let this float, but I can set it hard one way or the other, I will do
this later tonight.

> Is there anything connected to the "Programming" connector ?

Most of the time my Wisp628 is connected, it makes no difference connected or
not, I usually leave it connected but have disconnected to see if it helped.

> that you get problems ? Or just about anythime ?

Just about anytime, but a lot more pronounced when I do the ESC. I have walked
a HERE GOTO HERE through the code and _not_ seen the problem. Until I started
looping to give the operator something to look at.

Thanks for your help.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\14@114849 by toftat

flavicon
face
I just got reply from Noritake, they say that WR and CS should follow each other

The modified code is below. I haven't tested this yet as I am at work and don't
have this home project in front of me.

#DEFINE WR PORTC,0
#DEFINE CS PORTC,1
#DEFINE BUSY PORTC,2
                                                                               
       ; Takes the contents of character and displays it.
                                                                               
DISPLAYCHAR
       ; wait for BUSY to be low...
WAITBUSY
       BTFSC BUSY
       GOTO WAITBUSY

       BCF CS    ;This is from the email from Noritake

       ; lower WR
       BCF WR
                                                                               
       ; Load  data
       MOVFW character
       MOVWF PORTB
                                                                               
       ; raise wr
       BSF WR

       BSF CS   ;This is from the email from Noritake

       RETURN

I hope this works out, the data sheet is painfully ambiguous, even as far as
saying 'Don't care' in the truth table regarding it, and a double line in the
timing chart.

Note that this is _not_ used for serial communication. I will test it out
tonight and report my findings

Thanks for the suggestions guys (especially Jan Erik)

Anthony

{Quote hidden}

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\14@123433 by Jan-Erik Soderholm

face picon face
toftat@cowshed.8m.com wrote :

> > I'm currently trying to get a similar unit (GU128X32-311) running,
> > and it also have a CS line that I was planning to set CS hard "low".
>
> I have let this float, but I can set it hard one way or the
> other, I will do this later tonight.

I would not let an input to the VFD module "float". If the input doesn't
have any pull up/down resistor (so it's high-Z), it will pick up
50/60 Hz "hum" and all kinds of nasty things could happen !
And MPLAB SIM would have a *very* hard time to simulate that :-) :-)


I have just got the GU128X32-311 running, using the CS line
connected hard to GND. Now, the par interface on this unit is a little
different then the one on the T23A. E.g the data lines are "lached"
on the falling edge of the WR line, so they have to be setup *before*
setting WR low. So we don't know if they "use" the CS line in the
same ways.

>
> > Is there anything connected to the "Programming" connector ?
>
> Most of the time my Wisp628 is connected, it makes no
> difference connected or
> not, I usually leave it connected but have disconnected to
> see if it helped.

OK. Didn't know what you had there. The Wisp628 usualy
does a god job in disconnecting itself from the target curcuit.

Currently I would strongly suspect the floating CS !


>From your other mail :
> I just got reply from Noritake, they say that WR and CS
> should follow each other...

Does that say that you can "feed" them from the same pin ?
That would save a pin...

Jan-Erik.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\14@171235 by Anthony Toft

flavicon
face
> Currently I would strongly suspect the floating CS !

I corrected this, it wasn't floating, it was an output that I didn't
set. It helped a little, but not much... I have slowed everything down a
little (my propeller isn't quite as fast) and it's a bit more well
behaved.

> Does that say that you can "feed" them from the same pin ?
> That would save a pin...

Well, I am not hurting for pins, so I don't know.

--
Anthony Toft <.....toftatKILLspamspam.....cowshed.8m.com>
    I'm Anton, and I approve this message

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\14@212607 by Anthony Toft

flavicon
face
Ok so I feel a bit silly now...

I finally realized that I have the Oshonsoft PIC emulator on my other
machine and I decided to simulate my code... I discovered that the
reason it's always 0x9D corrupting the display is because I was sending
it!

I had completely forgotten my acquisition interrupt which then loads a
TMR0 interrupt to schedule the next one starting at 0x9D ticks away.

Sorry to have wasted all of your time, and thanks for the suggestions on
the problem. I guess you just can't fix dozy programmer errors in
hardware...

On Thu, 2004-10-14 at 17:12, Anthony Toft wrote:
{Quote hidden}

--
Anthony Toft <EraseMEtoftatspam_OUTspamTakeThisOuTcowshed.8m.com>
    I'm Anton, and I approve this message

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\15@025137 by n/a

picon face
Anthony Toft wrote :

> Ok so I feel a bit silly now...

Don't worry, we understand... :-)

> I had completely forgotten my acquisition interrupt which then loads a
> TMR0 interrupt to schedule the next one starting at 0x9D ticks away.

OK, So you ISR currupted the value in W, right ?

This is one of the nice things with the 18-series,
automatic save and restore of W, STATUS and BSR on
interrupts (well, you have to specify "RETFIE 1" to
have them restored) with no extra cycles wasted...

Jan-Erik.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\15@104419 by Dave VanHorn

flavicon
face
At 01:51 AM 10/15/2004, TN/PAC wrote:

>Anthony Toft wrote :
>
> > Ok so I feel a bit silly now...
>
>Don't worry, we understand... :-)
>
> > I had completely forgotten my acquisition interrupt which then loads a
> > TMR0 interrupt to schedule the next one starting at 0x9D ticks away.
>
>OK, So you ISR currupted the value in W, right ?

Whoops.

My skeleton apps have, on each int vector, a skeleton ISR that saves and
restores SREG at minimum.  While it is possible to write ISR code (at least
in assember) that doesn't need to save anything, it is unusual, and
something you don't do casually.


>This is one of the nice things with the 18-series,
>automatic save and restore of W, STATUS and BSR on
>interrupts (well, you have to specify "RETFIE 1" to
>have them restored) with no extra cycles wasted...

Interrupts with training wheels?

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\15@135032 by Jan-Erik Soderholm

face picon face
Dave VanHorn wrote :

> My skeleton apps have, on each int vector,...

*each* int vector, is this for PIC18xxxx ?
Does the PIC16-series have more then one int vector ?

> a skeleton ISR that saves and restores SREG at minimum.
> While it is possible to write ISR code (at least in assember) that
> doesn't need to save anything, it is unusual, and
> something you don't do casually.

And if it is the PIC18, why save those regs yourself ?

> >This is one of the nice things with the 18-series,
> >automatic save and restore of W, STATUS and BSR on
> >interrupts (well, you have to specify "RETFIE 1" to
> >have them restored) with no extra cycles wasted...
>
> Interrupts with training wheels?

Yes, but without any lost (bi-) cycles  :-)

Jan-Erik.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\15@135606 by Dave VanHorn

flavicon
face
At 12:50 PM 10/15/2004, Jan-Erik Soderholm wrote:

>Dave VanHorn wrote :
>
> > My skeleton apps have, on each int vector,...
>
>*each* int vector, is this for PIC18xxxx ?
>Does the PIC16-series have more then one int vector ?

Sorry, no, I don't work in the pic family much, this is in the AVR
Still, the technique holds.


> > Interrupts with training wheels?
>
>Yes, but without any lost (bi-) cycles  :-)

How many clock cycles does it take to save them?

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\15@160636 by Jan-Erik Soderholm

face picon face
Dave VanHorn wrote :

> How many clock cycles does it take to save them?

The saving and restoring of WREG, STATUS and BSR on the
"fast return stack" are made on the fly and is transparent
to the application ("no extra cycles", didn't I say that ?).

Now, *if* you use priority interrupts (high/low int), this doesn't
realy work, since the fast return stack is just one level...

Jan-Erik.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\15@161541 by Dave VanHorn

flavicon
face
At 03:06 PM 10/15/2004, Jan-Erik Soderholm wrote:

>Dave VanHorn wrote :
>
> > How many clock cycles does it take to save them?
>
>The saving and restoring of WREG, STATUS and BSR on the
>"fast return stack" are made on the fly and is transparent
>to the application ("no extra cycles", didn't I say that ?).

Well, I'm still fuzzy. From the finish of the last instruction, to the
start of the first instruction of the ISR, how many xtal clocks happen?

>Now, *if* you use priority interrupts (high/low int), this doesn't
>realy work, since the fast return stack is just one level...

Hmm.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\15@164801 by Jan-Erik Soderholm

face picon face
Dave VanHorn wrote :

> >Dave VanHorn wrote :
> >
> > > How many clock cycles does it take to save them?
> >
> >The saving and restoring of WREG, STATUS and BSR on the
> >"fast return stack" are made on the fly and is transparent
> >to the application ("no extra cycles", didn't I say that ?).
>
> Well, I'm still fuzzy. From the finish of the last
> instruction, to the start of the first instruction of the ISR,
> how many xtal clocks happen?

Oh, you mean in general ? Don't know exactly...

I was only pointing out that the builtin saving/restoring
of the three "key" registers do not *add* any additional
cycles.

Jan-Erik.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\15@220106 by Bob Ammerman

picon face
I believe that taking an interrupt is only two instruction cycles on PICs.
It is effectively a forced 'call' instruction.

Bob Ammerman
RAm Systems

{Original Message removed}

2004\10\16@105939 by Jan-Erik Soderholm

face picon face
Bob Ammerman wrote :

> I believe that taking an interrupt is only two instruction
> cycles on PICs.  It is effectively a forced 'call' instruction.

It depends on the source of the interrupt.
>From the 18F252 data sheet (page 73) :

"...For external interrupt events, such as the INT pins or
the POSRTB input change interrupt, the interrupt latency
will be three or four instruction cycles. ..."

Regards,
Jan-Erik.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\16@150427 by Bob Ammerman

picon face
> Bob Ammerman wrote :
>
>> I believe that taking an interrupt is only two instruction
>> cycles on PICs.  It is effectively a forced 'call' instruction.
>
> It depends on the source of the interrupt.
>>From the 18F252 data sheet (page 73) :
>
> "...For external interrupt events, such as the INT pins or
> the POSRTB input change interrupt, the interrupt latency
> will be three or four instruction cycles. ..."
>
> Regards,
> Jan-Erik.

There is a difference between 'interrupt latency' and the overhead for
entering the interrupt handler. The extra instruction cycle(s) are due to a
synchronizing flip-flop on the interrupt source.

Bob Ammerman
RAm Systems

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\16@151154 by Dave VanHorn

flavicon
face

>
>There is a difference between 'interrupt latency' and the overhead for
>entering the interrupt handler. The extra instruction cycle(s) are due to
>a synchronizing flip-flop on the interrupt source.

It's the overhead, that I'm wondering about.

Basically, I'm wondering if they are storing these registers in paralell,
or series, and just "hiding" that activity from you.  

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\16@153951 by Bob Ammerman

picon face
>>There is a difference between 'interrupt latency' and the overhead for
>>entering the interrupt handler. The extra instruction cycle(s) are due to
>>a synchronizing flip-flop on the interrupt source.
>
> It's the overhead, that I'm wondering about.
>
> Basically, I'm wondering if they are storing these registers in paralell,
> or series, and just "hiding" that activity from you.

The registers are being stored in parallel.

If I understand it correctly, when a synchronous (internal) interrupt occurs
then, at the same time, the PIC18 does all of the following within two
instruction cycle times:

stacks the return address
copies the W, STATUS and BSR into their shadow register
fetches the instruction at the interrupt vector
executes the instruction at the interrupt vector

Bob Ammerman
RAm Systems


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\16@154138 by Jan-Erik Soderholm

face picon face
Dave VanHorn wrote :

> > There is a difference between 'interrupt latency' and the
> > overhead for
> > entering the interrupt handler. The extra instruction
> > cycle(s) are due to
> > a synchronizing flip-flop on the interrupt source.
>
> It's the overhead, that I'm wondering about.
>
> Basically, I'm wondering if they are storing these registers
> in paralell, or series, and just "hiding" that activity from you.

You are talking about the three "shadow" registers that holds
the values of W, STATUS and BSR during the interrupt, right ?
(In the data sheets they are called WS, STATUSS and BSRS, but
they are not normal SFRs or memory mapped, so you can not "see" them.)

You could call it "hiding", since it's done behind the curtains.
There are no additional cycles wasted, the interrupt as such
takes as much time as it does on the PIC16, but there you have
to save those regs yourself and *that* will take a number of
cycles.

The net effect is that interrupts on the PIC18's are faster then
on the PIC16's (in general). If it's a very short ISR, the difference
could be significant.

Note also that you do not have the option to *not* save them.
You *do* have the option to *not* restore them (see description
of RETFIE), but that will not save any cycles anyway...

Regards,
Jan-Erik.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\16@154807 by Dave VanHorn

flavicon
face

>
>You are talking about the three "shadow" registers that holds
>the values of W, STATUS and BSR during the interrupt, right ?

Yes

{Quote hidden}

You've lost me.

If the regs are saved in parallel in hardware, then I wouldn't call that
"hiding" anything, and it would be faster.

If the regs are saves sequentially in microcode, and there's no timing
difference between you doing it in the ISR and the automatic version, then
I would call that "hiding" the save/restore overhead.

_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\16@160622 by Jan-Erik Soderholm

face picon face
Bob Ammerman wrote :

> > It's the overhead, that I'm wondering about.
> >
> > Basically, I'm wondering if they are storing these
> > registers in paralell,
> > or series, and just "hiding" that activity from you.
>
> The registers are being stored in parallel.
>
> If I understand it correctly, when a synchronous (internal)
> interrupt occurs then, at the same time, the PIC18 does all
> of the following  within two instruction cycle times:
>
> stacks the return address
> copies the W, STATUS and BSR into their shadow register
> fetches the instruction at the interrupt vector
> executes the instruction at the interrupt vector

(I think that the *fetch* happens during this 2 cycles, but the
*execution* happens on the next. The "interrupt latancy"
is the time up to the *begining* of the actual cycle that executes
the instruction at the interrupt vector address.)

Anyway...

And if the interrupt is async (external event), it takes an
additional 1-2 cycles (giving the total of 3-4 cycles the
data sheet talks about) to do exactly the same.

The big deal is that on the 16-series this would have taken
6-8 cycles (using the "context saving" code in the 12F629/675
data sheet at least). And an additional 4 cycles before RETFIE
to restore them, for a total overhead of 8 cycles in the PIC16
compared with the PIC18. For a very short ISR, this could be
a significant part of the total execution time of the ISR...

Jan-Erik.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\16@161149 by Jan-Erik Soderholm

face picon face
Dave VanHorn wrote :

> You've lost me.

Sorry, I must have been unclear :-)

> If the regs are saved in parallel in hardware, then I
> wouldn't call that "hiding" anything, and it would be faster.

I might call that "hide". You might not. Just fine with me.

> If the regs are saves sequentially in microcode, and there's
> no timing difference between you doing it in the ISR and the automatic
> version,

But there is.

> then  I would call that "hiding" the save/restore overhead.

Fine with me, let's just forget about what "hide" might mean...
See my other post...

Jan-Erik.
_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

2004\10\16@185901 by Bob Ammerman

picon face
> And if the interrupt is async (external event), it takes an
> additional 1-2 cycles (giving the total of 3-4 cycles the
> data sheet talks about) to do exactly the same.

It is important to understand that the number of cycles 'stolen' from normal
execution is no more for an external interrupt than it is for an internal
one. It is just the the start of the processing of the external interrupt is
delayed for one or two instruction cycles to syncronize it with the internal
processing of the PIC.

In other words, a syncronizing circuit turns the asynchronous (external)
interrupt into a synchronous signal, and it is the delay in that latch that
adds to the latency for external interrupts.

Bob Ammerman
RAm Systems


_______________________________________________
http://www.piclist.com
View/change your membership options at
http://mailman.mit.edu/mailman/listinfo/piclist

More... (looser matching)
- Last day of these posts
- In 2004 , 2005 only
- Today
- New search...