Electronics > Beginners
Sorry to interrupt ...
<< < (3/7) > >>
jpanhalt:
I am late to the party, sorry.  But since you are using an ehannced mid-range PIC, you can "pop" the last address just by decrementing STKPTR (Bank 31).

Here's an alternative I call MIB (Men in Black, if you remember the movie).  It erases all memory of the interrupt and lets you start
afresh.

--- Code: (asm) ---MIB                           ;erases interrupt return functionality
     movlb     31
     clrf      STKPTR
     movlb     2
     bcf       LATC,2         ;ensures LED is off when entering Command Mode 
     call      ClrScrn        ;call from any bank, returns |B0                  |B0
     btfss     INTCON,IOCIF
     bra       Event          ;not switch, must be Event
     movlb     7              ;                                                 |B7                                   
     btfsc     IOCBF,SW1      ;test for SW1                                     |B7
     bra       DoSW1          ;                                                 |B7
     bra       DoSW2          ;                                                 |B7

--- End code ---

Only the first 3 instructions are relevant.  The rest are to identify the source of the interrupt.  Of course, if you want to retain where  you were umpteen steps before the interrupt, change the clrf to decrf...

John
MarkF:

--- Quote from: PerranOak on May 31, 2018, 07:00:15 pm --- PA0PBZ:
Yes, you're right, I was doing it this way out of laziness. I just wondered if it was possible/allowable.

--- End quote ---

I agree with PAOPBZ on this one.

Yes, it's doable.  But, HIGHLY DISCOURAGED!  You are just asking for stack corruption and other mysterious problems.  I remember an occasion in my early years where one word was left on the stack by mistake.  It took 3 engineers over a week to find and correct.  When you start having these questions about a design, STOP and look at the big picture.  There will be a better way.

Just use the interrupt routine to read a new value and store it in a global variable.  Then, allow the main loop to display the value during its periodic update.  If you are NOT updating the entire display at a periodic rate, then set a flag in the interrupt routine to trigger an update in the main loop.
Brumby:
I cringed at the idea of playing with interrupt returns.  Like any common computer architecture, the fundamental execution is a linear one and every logical branch is - quite literally - a "go to".  So, yes, you can do it - but it's like lighting up a cigarette in a fireworks factory IMO.

Free use of the "go to", however, is not conducive to well structured, robust programs which is why the modular style with calls has been a fundamental mainstay in the programming sphere for a very long time.  Even in my first job writing application software in IBM assembler, this structural approach was the norm.
 Programming with interrupts is, perhaps, the quintessential example of this structured process.  Everything is built around the idea.

Most specific of the concerns I have is the state of execution when the interrupt occurs.  Whatever you were doing at the time stops while the interrupt is serviced and if you were part way through doing something, not allowing the return to that processing could leave you in an unknown condition.  Where this becomes a true minefield is if you have another interrupt fire off while you are still faffing around with the first.


Personally, I would avoid such programming like the plague - but if you really, really, really feel you need to, then think long and hard, tread very carefully and test the crap out of it.

Once you're happy with the testing, do it again ... and maybe get someone who doesn't like you to test it.  If you don't, the universe will find an edge case that will shoot you down in flames.
jpanhalt:
1) If you are just going to set a flag in the interrupt and then poll that flag as recommended by some, why have an interrupt to begin with?   Just poll the xyzIF.

2) I have other routines,  e.g., string print routines (macros), that use the stack to calculate a return with no interrupt.   Among other things, the da directive is used to pack two, 7-bit ascii into a single program memory location (Microchip reference manual), "• da "abcdef" will put 30E2 31E4 32E6 into program memory."   For routines that have a lot of "dialog" that can save hundreds of lines of code.  Try to do that concisely without using the stack.
For example:

--- Code: (asm) ---StrPrint  macro     label   
          call      PutText                 
          da        label,0         
          endm

--- End code ---

3)  Fears that that the world will end if you use the stack as a tool are greatly exaggerated.  They all sound a little like the warnings against flying ("if god had wanted man to fly he would have given him wings...").  Sure there are sincere believers in that, but the person writing the code is ultimately responsible for every line, not just the stack.  To put that another way, if Microchip hadn't wanted users to touch the stack, why did it give them the tools to do it?  Obviously, there is demand for the ability to push and pop the stack by programmers, and Microchip simply complied to compete.
Brumby:

--- Quote from: jpanhalt on June 01, 2018, 03:51:07 am ---1) If you are just going to set a flag in the interrupt and then poll that flag as recommended by some, why have an interrupt to begin with?   Just poll the xyzIF.

--- End quote ---
Really?  I can come up with a couple of reasons without even trying.
Navigation
Message Index
Next page
Previous page
There was an error while thanking
Thanking...

Go to full version
Powered by SMFPacks Advanced Attachments Uploader Mod