Searching \ for '[PIC]-Interrupt Return' 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/ints.htm?key=interrupt
Search entire site for: '-Interrupt Return'.

Exact match. Not showing close matches.
PICList Thread
'[PIC]-Interrupt Return'
2005\03\05@185323 by Jason Graham

picon face
Hi all

Just wondering if anyone knows how to return from an interrupt to a specific
location such as a label subroutine in the program? Can i just write that
location to the program stack?  Also, using the 18f452 to do this.

Jason


2005\03\05@192945 by Roy J. Gromlich

picon face
I'm not sure I understand what you are trying to do. Your interrupt can
occur
while your program is doing anything, anywhere in the code.  You want to
respond to the interrupt and rather than return to where the interrupt
occurred
you want to jump to some other specific location in the program.  Yes?  Why?

RJG

----- Original Message -----
From: "Jason Graham" <spam_OUTjgrahamcaTakeThisOuTspamhotmail.com>
To: <.....piclistKILLspamspam@spam@mit.edu>
Sent: Saturday, March 05, 2005 6:53 PM
Subject: [PIC]-Interrupt Return


> Hi all
>
> Just wondering if anyone knows how to return from an interrupt to a
specific
> location such as a label subroutine in the program? Can i just write that
> location to the program stack?  Also, using the 18f452 to do this.
>
> Jason


2005\03\05@193249 by Jan-Erik Soderholm

face picon face
Jason Graham wrote :

> Just wondering if anyone knows how to return from an
> interrupt to a specific location such as a label subroutine
> in the program? Can i just write that  location to the
> program stack?  Also, using the 18f452 to do this.

Hi.
Cold you describe better what problem you are trying
to solve by doing this ?

Don't you want to code that was "interrupted" to continue
from the point where it was interrupted ?

I'd guess that one might come up with something,
but you would probably very easy get into some real trouble...

But again, why do you think you have to do this ?

Jan-Erik.



2005\03\05@235124 by Jason Graham

picon face
To Roy,

I'm not sure I understand what you are trying to do. Your interrupt can
>occur
>while your program is doing anything, anywhere in the code.  You want to
>respond to the interrupt and rather than return to where the interrupt
>occurred
>you want to jump to some other specific location in the program.  Yes?  
>Why?


You got it...something wrong with that? It's just the way it has ta be.

Jason


2005\03\05@235826 by Jason Graham
picon face
>Jan-Erik wrote:

>Don't you want to code that was "interrupted" to continue
>from the point where it was interrupted ?

No, i don't. That's why i am asking.

>But again, why do you think you have to do this ?

Because i just do.

Jason


2005\03\06@004814 by Herbert Graf

flavicon
face
On Sat, 2005-03-05 at 23:51 -0500, Jason Graham wrote:
> To Roy,
>
> I'm not sure I understand what you are trying to do. Your interrupt can
> >occur
> >while your program is doing anything, anywhere in the code.  You want to
> >respond to the interrupt and rather than return to where the interrupt
> >occurred
> >you want to jump to some other specific location in the program.  Yes?  
> >Why?
>
>
> You got it...something wrong with that? It's just the way it has ta be.

First off, with an attitude and response like that you're giving people
VERY little reason to give up there time for free to help you.

Second, to answer your question, yes, it's possible there IS something
wrong with that. If that's the sort of behaviour you want it SOUNDS like
either you are approaching the problem in a non conventional way (not
always a bad idea) or you shouldn't be using an interrupt to begin with.

Can you at least elaborate as you WHY this behaviour is "just the way it
has ta be"?

Now, to get back to things, you say you want the interrupt to "return"
to a specific point. That makes it sound to me that you DON'T want
normal "interrupt" behaviour, you want more like a vectored jump. This
is certainly possible, and even useful in some circumstances, but to
call it an "interrupt" will confuse people.

Are you using assembler? If so the solution is easy: simply don't do a
RETFIE, instead do a GOTO (or BRA depending on your MCU of choice) to
your label. Be aware that this sort of structure will do BAD stuff with
your stack, so you must be VERY careful about ANY returns in your code
(i.e. disabling interrupts completely when doing a call). I'd actually
recommend avoiding returns completely if possible, just to much of a
recipe for disaster.

If you are using a compiled language I'd say you're stuck: I can't think
of a way to get most compilers I've see to do what you want. About the
only thing I can think of is to have the ISR set a flag that the main
routine samples and branches if set. This sort of behaviour is "common",
but I don't know if it'll do what you want.

In the future in might be a good idea to be a little nicer to the people
you are asking help from.


-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\03\06@005021 by Herbert Graf

flavicon
face
On Sat, 2005-03-05 at 23:58 -0500, Jason Graham wrote:
> >But again, why do you think you have to do this ?
>
> Because i just do.

Sorry, NOT good enough. If you want most people to help you have to
first convince them that YOU know what you are doing, and by your
response it SOUNDS like you don't. I'm NOT saying you don't, only that
it sounds like you don't, and it SOUNDS like another solution you're not
aware of may make more sense. Again, I'm not saying this is the case,
only that this is the way most here will read the case.

Can you at least explain WHY this behaviour is necessary?

-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\03\06@030742 by Jinx

face picon face
> > >But again, why do you think you have to do this ?
> >
> > Because i just do.
>
> Sorry, NOT good enough

I thought the question was asked perfectly correctly and civily in
the original post. Don't see why Jason is getting the third degree

Jason, you need to be very aware of what the stack is holding. You
can View/Hardware Stack in MPLAB. I've done stack manipulation
very successfully with other micros but not had need to do it on the
18F yet

AN818 specifically says

"Having access to the stack allows access to the return addresses
of interrupts and functtion calls. Thus, the program direction can be
changed"

http://ww1.microchip.com/downloads/en/AppNotes/00818a.pdf

Didn't hurt did it ?

2005\03\06@042321 by Marcel van Lieshout

flavicon
face
You can change the call/return stack while processing an interrupt. You can
even rebuild the entire stack. The retfie will jump to the location that is
on top of this stack. Setting STKPTR to zero clears the stack. Pushing your
addresses on it builds the new stack. You could also pop what you don't need
and push the new addresses.

I use this to implement a port of FreeRTOS to PIC18F using wizC as
development tool. Eg. for pre-emptive context-switching when eg. a task runs
out of it's timeslice (systemtick). The current stack is saved as part of
the current task and then the stack is rebuild with the contents the
new-to-run task expects it, followed by a retfie. So, I believe it's a valid
question. I am curious about the specific goal here, though.

Marcel

Jason Graham wrote:
> Hi all
>
> Just wondering if anyone knows how to return from an interrupt to a
> specific
> location such as a label subroutine in the program? Can i just write that
> location to the program stack?  Also, using the 18f452 to do this.
>
> Jason

2005\03\06@070204 by Thomas Sefranek

face picon face
I can not imagine why you would EVER do this.
The running program was interrupted...
Are you saying you would just ignore what it was doing?

 *
 |  __O    Thomas C. Sefranek   WA1RHPspamKILLspamARRL.NET
 |_-\<,_   Amateur Radio Operator: WA1RHP
 (*)/ (*)  Bicycle mobile on 145.41, PL 74.4

hamradio.cmcorp.com/inventory/Inventory.html
http://www.harvardrepeater.org  
> {Original Message removed}

2005\03\06@071854 by Jan-Erik Soderholm

face picon face
Jason Graham wrote :

> >Jan-Erik wrote:
>
> >Don't you want to code that was "interrupted" to continue
> >from the point where it was interrupted ?
>
> No, i don't. That's why i am asking.
>
> >But again, why do you think you have to do this ?
>
> Because i just do.

OK. Fine.
I must have missread you original post.
I thought that you was asking for help...

Best Regards,
Jan-Erik.



2005\03\06@151458 by olin_piclist

face picon face
Jason Graham wrote:
>> But again, why do you think you have to do this ?
>
> Because i just do.

Perhaps you could be a bit more specific?

*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\03\06@152332 by olin_piclist

face picon face
Herbert Graf wrote:
> Are you using assembler? If so the solution is easy: simply don't do a
> RETFIE, instead do a GOTO (or BRA depending on your MCU of choice) to
> your label.

That's fine on a PIC 16 since the stack is circular.  The interrupt return
address and any previous stuff on the stack won't cause problems as long as
no attempt is made to use that data.  It will get harmlessly overwritten as
new data is pushed.

On the PIC 18, however, things are a bit different.  It makes no sense to
vector into a subroutine asynchronously from an interrupt, so I'm therefore
assuming you are vectoring to top level code.  The PIC 18 stack is not
circular, and has overflow and underflow detection hardware.  You therefore
need to empty the stack before vectoring to top level code.  This means
executing POP instructions until the stack is exactly empty.

> I'd actually
> recommend avoiding returns completely if possible, just to much of a
> recipe for disaster.

There is no reason for this.  Within the limits I pointed out above, from
the foreground code point of view execution will just get suddenly reset to
some place in the top level code.  There is no reason to avoid calls or
returns.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\03\06@160322 by Jason Graham

picon face
Thank You Jinx,

>The reason i need this to happen is the program will be interrupted from a
>loop that is setting variables due to an A/D routine which is based on an
>incoming command character via. the USART. The incoming character is part
>of an USART interrupt routine that basically sets new variables for the
>main routine loop. If the main loop is setting variables based on the A/D
>i/p and and the old parameters aquired from the old USART interrupt, then
>it won't work properly. This is why i have to vector back to the beginning
>of the main loop when the new variables are set.

Again, thanks for recognizing the validity of the question

Jason


2005\03\06@160724 by Jason Graham

picon face
Thank you Marcel,

>The reason i need this to happen is the program will be interrupted from a
>loop that is setting variables due to an A/D routine which is based on an
>incoming command character via. the USART. The incoming character is part
>of an USART interrupt routine that basically sets new variables for the
>main routine loop. If the main loop is setting variables based on the A/D
>i/p and and the old parameters aquired from the old USART interrupt, then
>it won't work properly. This is why i have to vector back to the beginning
>of the main loop when the new variables are set.

Jason


2005\03\06@163033 by Jan-Erik Soderholm

face picon face
Jason Graham wrote :

> The reason i need this to happen is the program will be
> interrupted from a loop that is setting variables due to
> an A/D routine which is based on an incoming command
> character via. the USART. The incoming character is part
> >of an USART interrupt routine that basically sets new
> variables for the main routine loop.

I would make the USART ISR set a "new params available" flag
befor exiting (RETFIE) back to where it interrupted.

> If the main loop is setting variables based on the A/D
> i/p and and the old parameters aquired from the old USART
> interrupt, then it won't work properly.

I would then put a few checks of the "new params available" flag
in the main loop and/or in the A/D ISR. If the flag is set, just
loop back to the start of main (or whatever), clear the
flag and continue with whatever the main loop is doing.

> This is why i have to vector back to
> the beginning of the main loop when the new
> variables are set.

That's fine. But from your description of the problem I can't see
why you'd need to fiddle with the stack to do that. Anyway, you've
got other replies that showed how to do that...

Best Regards,
Jan-Erik.



2005\03\06@164134 by Wouter van Ooijen

face picon face
> This is why i have to vector back to
> the beginning of the main loop when the new variables are set.

Your 'resetting the loop' might work, but IMHO unless it is absolutely
the only way this can be done it is an extremely bad programming
technique.

Is it necessarry that the new settings take 'immediate' effect? Can't
they wait for one iteration? If so you could buffer the new settings,
and copy them at the top of the loop (disable interrupts to get a
consistent copy!).

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\03\06@165423 by Jinx

face picon face
> > This is why i have to vector back to the beginning of the main
> > loop when the new variables are set.

I was going to suggest a flag being set in the ISR to let the main loop
know that new parameters are available, which would be the easy
solution (not very adventurous though), but presumably setting new
variables is more urgent than that. You *could* pepper the main loop
with "is flag set ?" checks but why bother. The new data is going to
be at its freshest in the ISR and exiting to your choice of location to
use it straight away makes sense. With stable code and every loose
end tied up, manipulating the stack is no more problematic than any
other thing you can do with a PIC


2005\03\06@170530 by Jinx

face picon face
> Your 'resetting the loop' might work, but IMHO unless it is
> absolutely the only way this can be done it is an extremely bad
> programming technique

G'day Wouter. I disagree that this is "bad" technique ? An uncommon
technique perhaps, but not bad. Yes, the conventional way would be to
maybe set a flag, but I really don't see the problem with using the stack.
With proper management it's no different to setting PC or something
like a computed GOTO, which can get the careless user into all sorts
of difficulties. Ultimately you're simply over-riding where the PIC thinks
program flow goes next. I've been using this "bad" technique for many
years with the 68HCs and it's no big deal, truly. It's just one way of
skinning a cat

2005\03\06@174159 by Jason Graham

picon face
Olin wrote:

>On the PIC 18, however, things are a bit different.  It makes no sense to
>vector into a subroutine asynchronously from an interrupt, so I'm therefore
>assuming you are vectoring to top level code.  The PIC 18 stack is not
>circular, and has overflow and underflow detection hardware.  You therefore
>need to empty the stack before vectoring to top level code.  This means
>executing POP instructions until the stack is exactly empty.

Thats some good info. I will have to keep that in mind when i'm also using
priority interrupts. By the sounds of it, it will probably be a good idea to
clear the stack before i load it and vector back.

Jason


2005\03\06@181111 by Jan-Erik Soderholm

face picon face
Jason Graham wrote :

> By the sounds of it, it will probably be a good idea to
> clear the stack before i load it and vector back.

If you are clearing the stack anyway (POP'ing until
the STKUNF bit in STKPTR SFR is set), you probably just can
GOTO some label at the start of main (and re-set GIE).
You have POP'ed the interrupt "level" away anyway, so there
is realy no need to RETFIE anymore.

Make sure that all interrupts (both levels) are disabled
during the POP'ing of the stack, or else "interesting" things
might happen... :-)

Jan-Erik.



2005\03\06@192326 by Jason Graham

picon face
To Jan-Erik

>GOTO some label at the start of main (and re-set GIE).
>You have POP'ed the interrupt "level" away anyway, so there
>is realy no need to RETFIE anymore.
>
>Make sure that all interrupts (both levels) are disabled
>during the POP'ing of the stack, or else "interesting" things
>might happen.

Sounds good. I'll definetely have to add that in before i do any popping.

Thanks
Jason


2005\03\06@201047 by Andre Abelian

picon face
I remember when I was working with assembly whole day I was messing
with interrupt routines or how to handle other things in pic finally
I got that fixed as soon as more codes added suddenly surprises happened
timing off etc " I am not saying knowing assembly is bad" but knowing
C or any high level programming language will speed up your programming
time and compiler makers will take care of lots of things for you then
your question will be about programming only. After I worked on
electronic ignition project for harley Davidson I realized that assembly
is good for small projects only or it is even more power full to combine
with C.
To my opinion we all should fallow what datasheet requires.

Andre    






{Original Message removed}

2005\03\07@015627 by Wouter van Ooijen

face picon face
> G'day Wouter. I disagree that this is "bad" technique ?

I don't say that there are zero circumstances in which this would be the
preferred solution, I am just saying that the number of such
circumstances is IMHO very small.

Maybe *you* understand this technique thoroughly (including all its
possible associated problems), but will you always be the person who
maintains your code? And if you ever need help for a loosely related
part of your code most people will immediately bark on this creative
stack use.

And as nearly everyone has said by now: unless you have extremely strick
timing requirements there is a simple and commonly accepted alternative
(preparing the new values in the interrupt, set a flag to notify the
loop).

As for computed goto's etc: unless used in a very restricted way (RETLW
tables) or because no other solution exists (reducing the jitter in a
polling loop?) I would frown upon that too.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\03\07@022141 by Marcel van Lieshout

flavicon
face
Clearing the stack on pic18 is simply done by setting STKPTR to zero. There
is no need to pop the stack until empty.

Jason Graham wrote:
{Quote hidden}

2005\03\07@040622 by Jinx

face picon face

> > G'day Wouter. I disagree that this is "bad" technique ?
>
> I don't say that there are zero circumstances in which this would
> be the preferred solution, I am just saying that the number of such
> circumstances is IMHO very small.

(debating, not arguing)

Of course, and sometimes you have to do what you have to do. Which
doesn't make a technique inherently "bad', just necessary. A simple
ordinary maintainable solution is always the best answer _if possible_

> Maybe *you* understand this technique thoroughly (including all its
> possible associated problems), but will you always be the person who
> maintains your code? And if you ever need help for a loosely related
> part of your code most people will immediately bark on this creative
> stack use.

Well, that's maybe where we could have a philosophical difference

Say you accept that the end goal is a product that works reliably. Now,
that could be accomplished with the most appallingly amateurish code
imaginable. But wait, the PIC doesn't care how the human got the code
into it. It just does what it's told. No ifs ands or buts, the code could
be the most inelegant you ever saw, but it's complete, it works and was
written so basically it's maintainable.  The "professional", or indeed
anyone
with a sense of style, would gasp in horror at this "bad" technique, but in
effect would not be able to improve on the product's performance. So,
there are two perspectives - how we see code and how the PIC sees it

As for someone else maintaining s/w in the future, well, that's a case
for writing good documentation (it benefits the author too). My personal
opinion is that I wouldn't want someone unqualified/inexperienced out
of their depth with code they don't understand, even with adequate
documentation. Call it promoting and fostering standards if you like

For example, I am simply not experienced with the maths techniques
of Scott Dattalo or John Payson and (at the present time anyway)
wouldn't attempt to maintain or significantly alter any of their intricate
code. In fact, to be provocative, I would make a corollary between
that and your feelings about using the stack

There are at least a couple of techniques for division. (1) subtract and
subtract and subtract and ....  Not very elegant, sometimes impractical,
but it works. (2) Shift-subtract is not immediately obvious to the
uneducated eye, but would be the commoner solution. Now, by your
reckoning, the first method is the preferred one because it's simpler and
not the second, which is not obvious and logically more complicated. Is
(2) therefore "bad" technique ? No, IMHO, because it acccomplishes
the task efficiently, speedily and succinctly. That is a parallel, I
believe,
with using the stack. It's a resource available to get a job done. After
all the PIC is just registers and numbers, that's all it is. Simply sticking
to the path most trod does not advance one's experience one little bit

2005\03\07@045924 by Michael Rigby-Jones

picon face
{Quote hidden}

Not wishing to take sides here, but the difference between the examples
you have given. i.e. different methods of division only center any
complexity in one place, i.e. the division routine.  As long as the
programmer knows what registers to put the divisor and dividends in, and
what register the result comes back in, the function can be treated as a
black box.

OTOH messing about with the stack and using absolute branching out of an
ISR is quite likely to have big implications on the rest of the code.
Unless the author/maintainer knows exactly what's happening and why an
innocuous looking change could completely screw up the whole operation,
which of course goes back to good documentation.  However, if another
method is available that does the same job in an obvious way, the
emphasis on documentation is removed, and a programmer can understand
what is happening just by looking at the code.  I would always favour
code that is "self documenting" unless an unusual or confusing code
construct is absolutely the only method to do achieve something, which
is fairly rare IME.

Regards

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\03\07@055113 by Jinx

face picon face

> but the difference between the examples
> you have given. i.e. different methods of division only center any
> complexity in one place, i.e. the division routine.  As long as the
> programmer knows what registers to put the divisor and dividends in,
> and what register the result comes back in, the function can be treated
> as a black box

Yes, a division routine could be identified as a contained testable routine
but I was using it as an alternate view on good/bad technique, not as an
example of a routine that could go faulty

> OTOH messing about with the stack and using absolute branching out
> of an ISR is quite likely to have big implications on the rest of the code

I appreciate what you're saying but programs and circuits are so diverse I
don't think you can say that any section of code is going to impact more or
less on the functionality of the program as a whole

> Unless the author/maintainer knows exactly what's happening and why
> an innocuous looking change could completely screw up the whole
> operation, which of course goes back to good documentation

I could answer caveat emptor (or whatever the programming equivalent
is) - if you don't know what you're doing or present it poorly then there's
potential for a problem in any code. Whatever code you write, it ideally
should be 100% correct. Problem with the stack routine, fix it. Problem
with the division routine, fix it. I realise though that a more involved
piece
of code would probably take more work, and time is often money

Working with the stack doesn't automatically mean a bad hair day. It
just takes proper preparation and a R of TFM

As another example, how many people get I2C right first time ? Why
would anyone thus use I2C ? Too hard, bit bang everything. Except
people cope and manage to use I2C quite successfully

> However, if another method is available that does the same job in an
> obvious way, the emphasis on documentation is removed

Agreed

2005\03\07@074816 by olin_piclist

face picon face
> Jason Graham wrote :
>> The reason i need this to happen is the program will be
>> interrupted from a loop that is setting variables due to
>> an A/D routine which is based on an incoming command
>> character via. the USART. The incoming character is part
>> of an USART interrupt routine that basically sets new
>> variables for the main routine loop.

For some reason I didn't get the original message, only several replies to
it.  I may be missing part of it.

In any case, this is a rather confusing description and suggests a confused
thought process.  One can only guess what "interrupted from a loop that is
setting variables due to an A/D routine which is based on an incoming
command character via. the USART." actually means.  I'll assume that data is
coming in on the UART, and this data effects the operation of the foreground
loop, which runs asynchronously to the incoming data stream.  If so, why
couldn't you just SAY so?  I still don't understand what the A/D has to do
with this or why it's relevent.  I'll assume it's not and ignore it.

If the above assumptions are correct (big if), then there are several ways
to handle this.  If the asynchronously updated state is a single byte, then
just grab the live copy whenever it's used.  If it is more than one byte,
then you can disable interrupts temporarily around code that uses the data
or takes a temporary snapshot of it.  This is the preferable method.

You could restart the main loop whenever the interrupt routine updated the
state, but there are some problems with that.  First, this doesn't work well
if the state is more than one byte.  What happens when partial new state has
been received but not the whole new state?  You can't let the main loop run
on partial state (probably), and you can't restart it for the same reason
either.  Second, you have to be very sure at all times in the main code that
it is doing something that can be asynchronously aborted at any time.  For
example, writing a multi-byte variable of persistent state will be trouble.
Third, this will be a nightmare to maintain.  It may not be obvious in the
future that some unusual restrictions must be considered in the main code.
Fourth, it will make it difficult to add other features that will require
other logical "threads" since ALL the code will necessarily be aborted to
the top level of execution when the right data comes in.

All in all you need a very good reason for doing it the way you proposed,
and so far I haven't heard one.

>> If the main loop is setting variables based on the A/D
>> i/p and and the old parameters aquired from the old USART
>> interrupt, then it won't work properly.

I don't know what an A/D i/p is, and don't feel like guessing anymore.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\03\07@075432 by olin_piclist

face picon face
Jason Graham wrote:
> By the sounds of it, it will probably be a
> good idea to clear the stack before i load it and vector back.

Are you on a dsPIC?  If so, you should have said so.  Otherwise, why do you
need to "load" the stack before vectoring back.  Something doesn't make
sense here.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\03\07@082658 by olin_piclist

face picon face
Marcel van Lieshout wrote:
> Clearing the stack on pic18 is simply done by setting STKPTR to zero.
> There is no need to pop the stack until empty.

I just checked the manual, and you are right.  I had forgotten that STKPTR
is writeable.


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\03\07@090800 by alan smith

picon face
hmmm...cuz it hasta?  OK..wierd but whatever...

First, if its something that has to happen EVERYTIME
you exit the interupt...why not do THE THING at the
end right before you exit?

Second, set a flag as you exit the ISR.  Then in your
main routine, constantly poll for that flag being set
and branch when it is....alot of overhead but then
again since you don't want to explain your super
secret sauce then its all a guess...


       
               
__________________________________
Celebrate Yahoo!'s 10th Birthday!
Yahoo! Netrospective: 100 Moments of the Web
http://birthday.yahoo.com/netrospective/

2005\03\07@100152 by Wouter van Ooijen

face picon face
> (debating, not arguing)

The subtleties if this difference are lost to me (as non-native English
speaker) but I think I agree :)

> Say you accept that the end goal is a product that works
> reliably.

I seldom accept that as the only goal. If I did any technique, including
waving dead fishes and shanting incatations, would of course be
acceptable.

> opinion is that I wouldn't want someone unqualified/inexperienced out
> of their depth with code they don't understand, even with adequate
> documentation.

There are levels of understanding, and even an experienced programmer
will require more effort to understand an obscure programming technique.

Summary: if it is for your eyes only it of course does not matter which
technique you use (as long as it fits the bill). But as soon as you
communicate about your code (and this thread was started by a question
about such code!) it does matter.

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\03\07@111300 by Bob Ammerman

picon face
> On the PIC 18, however, things are a bit different.  It makes no sense to
> vector into a subroutine asynchronously from an interrupt, so I'm
> therefore
> assuming you are vectoring to top level code.  The PIC 18 stack is not
> circular, and has overflow and underflow detection hardware.  You
> therefore
> need to empty the stack before vectoring to top level code.  This means
> executing POP instructions until the stack is exactly empty.

Actually, just stick a 0 in STKPTR to empty the stack.

Bob Ammerman
RAm Systems


2005\03\07@153058 by Jinx

face picon face

> > (debating, not arguing)
>
> The subtleties if this difference are lost to me (as non-native English
> speaker) but I think I agree :)

Debating is something that two gentlemen would do using their indoor
voices. Arguing is for pub carparks, just before someone gets a knuckle
sandwich

> There are levels of understanding, and even an experienced programmer
> will require more effort to understand an obscure programming technique.

To return to the original issue, stack manipulation is hardly obscure. It's
not an established procedure on the PICs because they've not had a
manipulatable (jeepers, I'll have to look that one up) stack for very long

If you really think SM is in some way unsound or inadvisable then that's
something you should take up with Microchip and the author of AN818

> Summary: if it is for your eyes only it of course does not matter which
> technique you use (as long as it fits the bill).

Although I'd make the point again that the PIC doesn't care about us. For
example, doesn't C produce "obscure" assembly code ?

> But as soon as you communicate about your code (and this thread was
> started by a question about such code!) it does matter.

Agreed, it does matter if you want help or a critique (the OP didn't
actually
cite any code though). The more intricate the code, the fewer people can
follow it easily. I'm not advocating hard-to-read code, but don't most
people want to improve their skills ? Sometimes you have to step out of
your comfort zone to do that and be innovative. You know the phrase
"Necessity is the mother of invention" ?

But, and this is a JLo-sized but, if a PIC is running solidly WITHIN SPEC
(carpark voice ;-)), as it always should be, with every routine humming
sweetly, who is to criticise ? And would anyone who can get a PIC into
that sought-after condition need much help anyway ?

2005\03\07@154909 by Jan-Erik Soderholm

face picon face
Jinx wrote :

> If you really think SM is in some way unsound or inadvisable...

Well, yes, actualy *I* do.
To much chains, whips and leather for my taste...
But I think there are some "SM-clubs" downtown for those
who fancy it...

Jan-Erik.



2005\03\07@164127 by Wouter van Ooijen

face picon face
> if a PIC is running solidly
> WITHIN SPEC
> (carpark voice ;-)), as it always should be, with every
> routine humming
> sweetly, who is to criticise ? And would anyone who can get a PIC into
> that sought-after condition need much help anyway ?

1. If the OP could get it to work this discussion would not exist.

2. If maintenace is not important I rest my case, but if it somehow is
then it is not a good idea to use a more difficult approach than needed.

Don't get me wong, if I get the change and a good reason I will fiddle
with the stack untill it can whistle a jig, but I would probably call
the result a tasking kernel with exception handling. That makes it
acceptable :)

Wouter van Ooijen

-- -------------------------------------------
Van Ooijen Technische Informatica: http://www.voti.nl
consultancy, development, PICmicro products
docent Hogeschool van Utrecht: http://www.voti.nl/hvu


2005\03\07@192129 by Jinx

face picon face
> > If you really think SM is in some way unsound or inadvisable...
>
> Well, yes, actualy *I* do.
> To much chains, whips and leather for my taste...

Hmmm, so are you like the masochist who liked a freezing cold
shower in the morning. So he didn't have one ?

2005\03\07@192136 by Jinx

face picon face
> 1. If the OP could get it to work this discussion would not exist.

True, but he hadn't attempted any coding yet AFAIK, he was just
soliciting ideas. But it's interesting to see how people feel about things

> 2. If maintenace is not important I rest my case, but if it somehow is
> then it is not a good idea to use a more difficult approach than needed.

Absolutely. The Principle Of Parsimony - don't go looking for wayout
causes or solutions if there's a simpler alternative

> Don't get me wrong, if I get the change and a good reason I will fiddle
> with the stack untill it can whistle a jig, but I would probably call
> the result a tasking kernel with exception handling. That makes it
> acceptable :)

Oh, I see, a rose by any other name.......... that's like glamourising
a rat-catcher by calling him an Enviromental Health Officer and a
dustman becomes a Refusal Disposal Operator ;-)

2005\03\07@213724 by Jason Graham

picon face
Hi all,

WOW, i didn't think the question would lead to all of this. I'll try not to
ask anymore difficult questions. To those who proposed solutions and
actually helped i thank you. To the rest, you might want to sit back, have a
few drinks and pull your egos out of your a.s.

Later
Jason


2005\03\07@220524 by Bob J

picon face
On Mon, 07 Mar 2005 21:37:23 -0500, Jason Graham <jgrahamcaspamspam_OUThotmail.com> wrote:

> actually helped i thank you. To the rest, you might want to sit back, have a
> few drinks and pull your egos out of your a.s.

Likewise.

Regards,
Bob

2005\03\07@224843 by Herbert Graf

flavicon
face
On Mon, 2005-03-07 at 21:37 -0500, Jason Graham wrote:
> Hi all,
>
> WOW, i didn't think the question would lead to all of this. I'll try not to
> ask anymore difficult questions. To those who proposed solutions and
> actually helped i thank you. To the rest, you might want to sit back, have a
> few drinks and pull your egos out of your a.s.

Hehe, wow, what a great response, I'll be sure I'll never offer my help
to you again, and I'm sure with that attitude many here won't either.

Talk about ego...


-----------------------------
Herbert's PIC Stuff:
http://repatch.dyndns.org:8383/pic_stuff/

2005\03\08@041304 by Alan B. Pearce

face picon face
> WOW, i didn't think the question would lead to all of this. I'll try not
to
> ask anymore difficult questions. To those who proposed solutions and
> actually helped i thank you. To the rest, you might want to sit back, have
a
> few drinks and pull your egos out of your a.s.

I think that the discussion has been more about the "why are you doing it
this way" aspect of it. From what you wrote somewhere in the middle of the
discussion about why you wanted to do it, I see that there is a "more
structured way" of doing it that produces cleaner code.

The method you are proposing has no real advantage over the interrupt
routine setting a flag to show that new parameters have arrived - in fact I
see your method as having a disadvantage, think about what happens when some
of the parameters have changed as the ADC portion does another conversion
when part way through a parameter change.

Essentially having the non-interrupt code check a parameter change flag at
some defined point in the loop, and update all parameters at that time will
actually keep your code more in sync than you realise. I seriously doubt
that you can send parameters to the PIC with such precision that you will
affect a specific conversion.

As others have pointed out, there are times when stack manipulation is
desirable or necessary, but your application does not present itself as
being one of these times. A rethink about how the code interacts between the
parameter change code and the conversion code is clearly required. This is
why your original question invoked all this discussion.

2005\03\08@073724 by olin_piclist

face picon face
Jason Graham wrote:
> To the rest, you might want to sit back, have a few drinks
> and pull your egos out of your a.s.

Hey, that's well out of line.  You came here asking for free help.  If you
don't like the response you can get all your money back.

You also asked how to do something that was very unusual and a bad idea in
most circumstances.  Most people here don't just want to answer a question,
but get to the root of the problem and solve that.  That's because often
people who ask questions here also don't know enough to ask the right
question.  Therefore asking "why" is a legitimate response.  If you can't
handle that, go pay someone for advice.  By replying in uppity ways like
"because it just has to", you discourage people from wanting to help you, so
their only interest remains the theoretical discussion.  Once again, they
are doing this for free, so they get to do what they feel like, and it's
your job to make feel like wanting to help you.

So if you can't adjust your attitude, please go away (if James doesn't do it
for you).


*****************************************************************
Embed Inc, embedded system specialists in Littleton Massachusetts
(978) 742-9014, http://www.embedinc.com

2005\03\08@083132 by Michael Rigby-Jones

picon face


{Quote hidden}

I'll second that all the way.  Jason, that post was deliberately
intended to stir things up, as you stated. There is simply not room on
the list for such juvenile behaviour.  This is a group of professionals
and dedicated amateurs, if you want flame wars then please find
somewhere else.

Mike

=======================================================================
This e-mail is intended for the person it is addressed to only. The
information contained in it may be confidential and/or protected by
law. If you are not the intended recipient of this message, you must
not make any use of this information, or copy or show it to any
person. Please contact us immediately to tell us that you have
received this e-mail, and return the original to us. Any use,
forwarding, printing or copying of this message is strictly prohibited.
No part of this message can be considered a request for goods or
services.
=======================================================================

2005\03\08@133430 by Howard Winter

face
flavicon
picon face
Jinx,

On Tue, 08 Mar 2005 13:19:49 +1300, Jinx wrote:

> > 2. If maintenace is not important I rest my case, but if it somehow is
> > then it is not a good idea to use a more difficult approach than needed.
>
> Absolutely. The Principle Of Parsimony - don't go looking for wayout
> causes or solutions if there's a simpler alternative

If "maintenance is not important" then it's unlikely that the application is anything but trivial - the World
changes and often that means changing the systems we design to work in it, even if they worked perfectly when
written.  As I used to tell my team: "Any program worth writing will have more time spent on it being read
than written, so don't make it difficult to read, because that's easy to write!"

"The Principle Of Parsimony", also called Occam's Razor, or KISS!  :-)

Or:  Always try the simplest and most obvious solution first, and only go more complicated / less obvious, in
small steps, if that doesn't work.

> > Don't get me wrong, if I get the change and a good reason I will fiddle
> > with the stack untill it can whistle a jig, but I would probably call
> > the result a tasking kernel with exception handling. That makes it
> > acceptable :)
>
> Oh, I see, a rose by any other name.......... that's like glamourising
> a rat-catcher by calling him an Enviromental Health Officer and a
> dustman becomes a Refusal Disposal Operator ;-)

...or calling a Spade a manually operated agricultural implement... I prefer to call it a Spade!  :-)

Cheers,


Howard Winter
St.Albans, England


2005\03\08@172928 by Jinx

face picon face
> If "maintenance is not important" then it's unlikely that the application
is
> anything but trivial - the World changes and often that means changing
> the systems we design to work in it, even if they worked perfectly when
> written.

That's true. A for instance - two PIC projects that have basically the
same function, dealing with a coded waveform, needing completely
different approaches.

One is an IR Tx/Rx pair for counting cattle through a race (count
legs, divide by four, but that's just bullocks isn't it). Piece of trivial
cake and could be written very sloppily without affecting performance

The other is a LANC interface. Now, that could be (a) written using
discrete routines for each command. Requires not a lot of set-up
but adding eg switches or parameters in the future means writing
additional routines, although it is a simple system overall. More
economic in the long run is (b) to give some initial thought to and plan
for a sophisticated system that's more like an OS. The core routine,
more complicated than any individual discrete routine as in (a), can
handle any command and parameters by referencing an easily-updatable
table

I'm all for simplicity but there's sometimes more to it than that.
Professional
pride for example, or impressing and improving oneself

"If you do what you always did, you'll get what you always got"

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