Post by thread:[PIC] Noritake -T23A VFD connection

'[PIC] Noritake -T23A VFD connection'

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_OUTtoftatTakeThisOuTcowshed.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

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

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

.....redrock8KILLspam@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

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

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

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

> 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 <toftatKILLspamcowshed.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

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}> 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

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

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

> (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

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}> 

> 

> 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

> mailman.mit.edu/mailman/listinfo/piclist

> 

_______________________________________________

http://www.piclist.com

View/change your membership options at

http://mailman.mit.edu/mailman/listinfo/piclist

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

> 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 <.....toftatKILLspam.....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

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}> > 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 <EraseMEtoftatspam_OUTTakeThisOuTcowshed.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

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

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

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

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

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

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

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

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}
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

> 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

>

>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

>>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

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

>

>You are talking about the three "shadow" registers that holds

>the values of W, STATUS and BSR during the interrupt, right ?

Yes

{Quote hidden}>(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.

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

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

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

> 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