Searching \ for '[PIC] Fast Return Usage?' 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: 'Fast Return Usage?'.

Exact match. Not showing close matches.
PICList Thread
'[PIC] Fast Return Usage?'
2005\12\18@233850 by Josh Koffman

face picon face
Hi all. I've just run across something weird. I'm fairly certian it's
my fault, but I don't know if my fix is correct.

Short story is I'm writing an ISR for the 18F4550. I want to use the
fast return, so at the end of my routine I wrote "RETFIE, FAST". The
assembler throws an error about the comma. If I take out the comma, it
assembles fine (haven't tested it yet though). The datasheet seems to
say that I need the comma. What's going on?

One thing that may or may not be pertinent is that I'm trying to use
relocatable code here.

Thanks!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\18@235843 by Rolf

face picon face

No comma in the 18F4320 Datasheet Instruction-set summary.

Syntax: [ label ] RETFIE [s]
Operands: s ∈ [0,1]
Operation: (TOS) → PC,
1 → GIE/GIEH or PEIE/GIEL,
if s = 1
(WS) → W,
(STATUSS) → STATUS,
(BSRS) → BSR,
PCLATU, PCLATH are unchanged.
Status Affected: GIE/GIEH, PEIE/GIEL.
Encoding: 0000 0000 0001 000s
Description: Return from Interrupt. Stack is
popped and Top-of-Stack (TOS) is
loaded into the PC. Interrupts are
enabled by setting either the high
or low priority global interrupt
enable bit. If ‘s’ = 1, the contents of
the shadow registers WS,
STATUSS and BSRS are loaded
into their corresponding registers,
W, Status and BSR. If ‘s’ = 0, no
update of these registers occurs
(default).

Rolf

Josh Koffman wrote:
{Quote hidden}

2005\12\19@000303 by Spehro Pefhany

picon face
At 11:38 PM 12/18/2005 -0500, you wrote:
>Hi all. I've just run across something weird. I'm fairly certian it's
>my fault, but I don't know if my fix is correct.
>
>Short story is I'm writing an ISR for the 18F4550. I want to use the
>fast return, so at the end of my routine I wrote "RETFIE, FAST". The
>assembler throws an error about the comma. If I take out the comma, it
>assembles fine (haven't tested it yet though). The datasheet seems to
>say that I need the comma. What's going on?

When you look at the disassembled code, does it have the correct opcode?
That's the bottom line.

The MPASM help file says the syntax is:

retfie s

where the default is s is 0, and 1 for fast

naturally, the 4550 include file contains this:  FAST EQU 1

I don't think there's ever a comma between the op-code and the first
argument; only to separate multiple arguments.

I think you're okay, just another minor datasheet blip.

>Best regards,

Spehro Pefhany --"it's the network..."            "The Journey is the reward"
spam_OUTspeffTakeThisOuTspaminterlog.com             Info for manufacturers: http://www.trexon.com
Embedded software/hardware/analog  Info for designers:  http://www.speff.com
->> Inexpensive test equipment & parts http://search.ebay.com/_W0QQsassZspeff


2005\12\19@003327 by Josh Koffman

face picon face
On 12/19/05, Spehro Pefhany <.....speffKILLspamspam@spam@interlog.com> wrote:
> When you look at the disassembled code, does it have the correct opcode?
> That's the bottom line.
>
> The MPASM help file says the syntax is:
>
> retfie s
>
> where the default is s is 0, and 1 for fast
>
> naturally, the 4550 include file contains this:  FAST EQU 1
>
> I don't think there's ever a comma between the op-code and the first
> argument; only to separate multiple arguments.
>
> I think you're okay, just another minor datasheet blip.

Thanks Spehro and Rolf. I just blanked out and didn't check the
Instruction Set Summary. It didn't even occur to me. This does seem to
be a little blip. In the text (at the end of the Interrupts section -
9.10 in the 18f4550 sheet) it refers to the fast return section in
5.3...which is actually in 5.1.3. In the example code there, it has
the comma. The comma is also in the text. Arg

Oh well...thanks again guys!

Josh
--
A common mistake that people make when trying to design something
completely foolproof is to underestimate the ingenuity of complete
fools.
       -Douglas Adams

2005\12\19@010859 by John Temples

flavicon
face
On Mon, 19 Dec 2005, Josh Koffman wrote:

> Thanks Spehro and Rolf. I just blanked out and didn't check the
> Instruction Set Summary. It didn't even occur to me. This does seem to
> be a little blip. In the text (at the end of the Interrupts section -
> 9.10 in the 18f4550 sheet) it refers to the fast return section in
> 5.3...which is actually in 5.1.3. In the example code there, it has
> the comma. The comma is also in the text. Arg

Be sure you've read the errata, since I believe the 4550 has the fast
register stack problem.

--
John W. Temples, III

2005\12\19@083456 by olin piclist

face picon face
Josh Koffman wrote:
> I wrote "RETFIE, FAST". The
> assembler throws an error about the comma. If I take out the comma, it
> assembles fine (haven't tested it yet though). The datasheet seems to
> say that I need the comma. What's going on?

I don't know what you saw in the data sheet, but there is never a comma
between a MPASM opcode and its operands.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\19@083922 by olin piclist

face picon face
Josh Koffman wrote:
> Thanks Spehro and Rolf. I just blanked out and didn't check the
> Instruction Set Summary. It didn't even occur to me. This does seem to
> be a little blip. In the text (at the end of the Interrupts section -
> 9.10 in the 18f4550 sheet) it refers to the fast return section in
> 5.3...which is actually in 5.1.3. In the example code there, it has
> the comma. The comma is also in the text. Arg

You can save yourself all these little troubles by using my PIC 18 interrupt
template QQQ_INTR18.ASPIC at http://www.embedinc.com/pic.  You configure it
at the top for single or high/low interrupt priorities and assembly time
magic takes care of the rest.  You only have to insert your
application-specific interrupt code.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\19@115949 by alan smith

picon face
dumb question...no I havent read the doc....but quck explanation for the difference between a regular return and a fast return?  What do you gain by using a fast return?



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2005\12\19@122801 by Jan-Erik Soderholm

face picon face
alan smith wrote :

> dumb question...no I havent read the doc....but quck
> explanation for the difference between a regular return and a
> fast return?  What do you gain by using a fast return?

Speed

Details are in the docs...

Jan-Erik.



2005\12\19@123344 by olin piclist

face picon face
alan smith wrote:
> dumb question

Given below, I agree.

> ...no I havent read the doc....

So you think it's better to have 1500 people take time out to answer your
question than to take 3 minutes and look up the answer?

RTFM!

If you don't understand something in the manual then ask here, but you've
got to do your homework first.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

2005\12\19@144258 by Mike Hord

picon face
> dumb question...no I havent read the doc....but quck
> explanation for the difference between a regular return
> and a fast return?  What do you gain by using a fast return?

Ease of execution and speed.  With a fast return, the PIC
assumes that the current values stored in the fast return
shadow registers for STATUS, BSR, and W are correct,
performs a return and restores those values.

Of course, it's up to you to ensure that those values ARE
correct, by only executing fast returns after a call which
caused the appropriate values to be stored in the shadow
registers and ensuring that, while the values in the shadow
registers are important, no other calls occur to overwrite
them.

This becomes important with multiple levels of interrupt.
If a low level interrupt occurs, and your program stores
W, BSR, and STATUS in the shadow registers, then a
high priority interrupt interrupts the low priority one, and
your code again causes the values to be stored in the
shadow registers, a fast return from the high priority
interrupt will work, but if your code then performs a
fast return from the low priority interrupt, the result is
not so certain, because the current state of the shadow
registers is unknown.  In systems with multiple interrupt
priorities, it is crucial that your code perform context
saving for lower priority interrupts without relying on
the fast return "stack" (can it be a stack with only one
level?) to do it for you.

Of course, if you don't have multiple priorities, or if
you do, but want to speed up your service of high
priority interrupts (which is usually why they are
high priority in the first place), the fast return feature
is handy.  It's also much easier to use and doesn't
require the extra registers that "manual" context
saving does.

Mike H.

2005\12\19@150504 by alan smith

picon face
Thanks Mike....excellent explanation (I am sure others were wondering but afraid to ask....fear of....being stung).  Sometimes it takes someone that has used them before to show the shortcomings or the gotcha's of using a particular opcode.



__________________________________________________
Do You Yahoo!?
Tired of spam?  Yahoo! Mail has the best spam protection around
http://mail.yahoo.com

2005\12\20@121221 by Peter

picon face


On Mon, 19 Dec 2005, Olin Lathrop wrote:

> alan smith wrote:
>> dumb question
>
> Given below, I agree.
>
>> ...no I havent read the doc....
>
> So you think it's better to have 1500 people take time out to answer your
> question than to take 3 minutes and look up the answer?

No, he knew that, but he thought that your inevitable response would
serve to mobilize him better ;-)

Peter

2005\12\20@163220 by John Ferrell

face picon face
Lets see if I understand this:
Don't ask any questions here that might be answered by some manual
somewhere.
Don't ask any questions here before assuring they are not in some archive.
Don't ask any questions here that might be found by Google...

The implied header to the question was: Would any one care to take a minute
to enlighten me further on this subject and save me several hours of library
work?

If your replies are too precious to waste on the simple answers, would it
not be easier for you to just ignore the post?
If you let these little things that annoy you to grow they become dangerous
to your well being...

Be aware that we all hold you to a higher standard due to your obvious
talent and skill. It would be a great loss if you chose not to participate
in the list. But other individuals should also be treated respectfully.

I am just a lone voice with no special authority...

John Ferrell
http://DixieNC.US

{Original Message removed}

2005\12\20@165507 by Maarten Hofman

face picon face
> Lets see if I understand this:
> Don't ask any questions here that might be answered by some manual
> somewhere.

Well, not somewhere. I believe it is on the microchip website, which,
to my experience, is very easily accessible, and its manuals are quite
clear (and you would need to read them to use the PICmicro anyway).

> Don't ask any questions here before assuring they are not in some archive.

Well, if you're posting to the PIClist, it would be good if you
checked the PIClist archive to see if the question was asked before.
Not sure if you would need to check other archives.

> Don't ask any questions here that might be found by Google...

Some answers are clearly answered on the first page of google
responses, so entering the question in google is not a bad idea.

> The implied header to the question was: Would any one care to take a minute
> to enlighten me further on this subject and save me several hours of library
> work?

If it was several hours, I don't see why you shouldn't post it.
However, if it is less than three minutes (which is what it would take
to look up the three methods described above) I would agree with Olin
that it is wiser to not bother 1500 people with it, especially since
these people provide a valuable resource.

> If your replies are too precious to waste on the simple answers, would it
> not be easier for you to just ignore the post?

Maybe, but to occasionally point out that there is a clear protocol
for getting free help to your problems (I think everything is quite
well explained in http://www.catb.org/~esr/faqs/smart-questions.html )
helps both the person asking, and the people that might be answering.

> If you let these little things that annoy you to grow they become dangerous
> to your well being...

I don't think it annoyed Olin. He basically answered the question, be
it in his usual abrupt way. I would say he was being nice. If I had
bothered, I would probably have just posted the link I mentioned in
this Email.

Greetings,
Maarten Hofman.

2005\12\20@171311 by olin piclist

face picon face
John Ferrell wrote:
> Lets see if I understand this:
> Don't ask any questions here that might be answered by some manual
> somewhere.

No, just not things that are readily and directly answered in the manual in
the place you'd expect the answer to be.  Even then it's OK to say I read
xxx but don't understand why they say yyy, etc.

> Don't ask any questions here before assuring they are not in some
> archive.

Probably reasonable, but I've never said that because I don't know what's in
the archive myself.

> Don't ask any questions here that might be found by Google...

At least not the ones that can be answered immediately using obvious search
keys.

Yes, I think people should do a few basic minimum things to find an answer
themselves before asking 1500 people for a favor.  Not doing that is just
lazy and arrogant since it essentially says "my time is a lot more valuable
than yours".

> The implied header to the question was: Would any one care to take a
> minute to enlighten me further on this subject and save me several
> hours of library work?

But that's nonsense.  It would only take a few minutes to crack the manual
and at least try to understand it.  If it still doesn't make sense, then
ask.

> If your replies are too precious to waste on the simple answers,
> would it not be easier for you to just ignore the post?

Then the poster might think it was OK.


******************************************************************
Embed Inc, Littleton Massachusetts, (978) 742-9014.  #1 PIC
consultant in 2004 program year.  http://www.embedinc.com/products

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