software reset
electronic
Posts: 16
hi SXers
I have written an SX28 general purpose pulse generator program that functions as expected. I now wish to use the interrupt routine to modify the program parameters (ie pulse on and off times) while the program is running. My program uses two different pulse generating subroutines depending on the output pulse times; one subroutine uses 8bit time constants (the first 8bits of 32bit word) for narrow/fast pulses, the other subroutine uses 32bit (the complete 32bit word) time constants for wider/slower pulses. The program decides which subroutine to use depending on the number of populated bits in the 32bit word time constants after reading the user input from the up/down keys. I do not wish to check the keyboard during the pulse generating subroutines because this will reduce the maximum frequency and increase the minimum pulse width that can be generated. If the program returns from an interrupt with time constants out of range (after user modification) for the calling subroutine a problem occurs !!!!
Is it possible to return from the interrupt routine to a different point than called from?
or
Is it possible to software reset the processor during the interrupt subroutine to clear the stack and interrupt status?
I have written an SX28 general purpose pulse generator program that functions as expected. I now wish to use the interrupt routine to modify the program parameters (ie pulse on and off times) while the program is running. My program uses two different pulse generating subroutines depending on the output pulse times; one subroutine uses 8bit time constants (the first 8bits of 32bit word) for narrow/fast pulses, the other subroutine uses 32bit (the complete 32bit word) time constants for wider/slower pulses. The program decides which subroutine to use depending on the number of populated bits in the 32bit word time constants after reading the user input from the up/down keys. I do not wish to check the keyboard during the pulse generating subroutines because this will reduce the maximum frequency and increase the minimum pulse width that can be generated. If the program returns from an interrupt with time constants out of range (after user modification) for the calling subroutine a problem occurs !!!!
Is it possible to return from the interrupt routine to a different point than called from?
or
Is it possible to software reset the processor during the interrupt subroutine to clear the stack and interrupt status?
Comments
· I'm assuming that the up/down buttons cause interrupts ?
· Why can't you check the time constants in the interrupt before returning ?
· Usually the interrupt is used to generate the pulses, and the main code handles the user interface. But maybe you have good reason to do it the way you are ?
· If you could post your code it would make it easier to assist you without having to guess.
Bean.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Cheap used 4-digit LED display with driver IC·www.hc4led.com
Low power SD Data Logger www.sddatalogger.com
SX-Video Display Modules www.sxvm.com
Stuff I'm selling on ebay http://search.ebay.com/_W0QQsassZhittconsultingQQhtZ-1
"USA Today has come out with a new survey - apparently, three out of every four people make up 75% of the population." - David Letterman
Yes, I am using the up/down keys to trigger the interrupt routine.
I can check the time constants before returning but I need to return to different routines depending on actual values of the time constants. Hence my first question.
I am using the main code to generate the pulses in order to allow me to generate very narrow/fast pulses without interrupt routine latency delays of 5 cycles. Using my main code subroutine I can generate pulses 5 cycles wide (or less with extra subroutines). I am trying to optimise the code to take full advantage of the SX28.
Many thanks for your help.
electronic
Yes, it is POSSIBLE to return from interrupt to a place different than the spot where the interrupt occurred ...... but it's not simple and involves the 'secret SX instructions' with quite a bit of trickery to get that reliable.
Unless you are well up on your SX assembly coding I would recommend against it; it's certainly NOT for beginners.
Search for 'secret SX instructions' on the Parallax site to find some threads on the subject.
Probably another approach is more reasonable. If you gave some more details as to your quest, we could provide some better guidance.
Cheers,
Peter (pjv)
Many thanks for this information on secret SX instructions. I may be able to POP/PUSH the stack as on the Z80 to solve my problem.
Best regards
electronic
Or perhaps not, it's not as easy as you might think.
As Bean and I both suggested, more information would be very useful. Without that, you are just keeping us guessing, and there's not much point in that ..... at least not for us !
Cheers,
Peter (pjv)
I expect that assembling these secret SX instuctions will require manual assembly of the final code by replacing inserted 'nop' instructions with the required secret POP/PUSH code bytes. Plenty of chances to make silly mistakes! I will experiment with this method and report if it is sucessful.
The main pulse generator program itself is nothing special at all, just standard practice; i.e. a simple closed loop containing two time delay sections seperated by output port write instructions copied from an old Z80 program I wrote back in the 1980's . My efforts to use the interrupt routine are solely to remove the extra time in the loop required to check the keys for user input. If the interrupt routine method is unworkable I will just revert to checking the keys inside the loop. This will result in a pulse generator with wider minimum pulse width and lower maximum PRF. In practice this may not be a big problem for a general purpose pulse generator product.
Best regards
electronic
I think I know what you are trying to do, but I'm still guessing. While buttons are being pushed, the pulses cease or get messed up, and that's OK then ?
If you could 'zoom out' a bit, and give us an overview or set of specs you are trying to meet, it would be helpful.
Cheers,
Peter (pjv)
there is another "tricky" way to soft-reset an SX: The watchdog timer. If you activate it together with a prescaler setting of your choice, make sure that a CLR !WDT instruction is executed often enough in the "regular" program loop. In case you want a soft-reset, just keep the program running in an endless loop without clearing the watchdog timer, and it will reset the SX after it has timed out. There is no problem, placing the endless loop inside the ISR code, as further interrupts are disabled as long as no RETI, or RETIW instruction is executed.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
jumping to any location outside of the ISR, like to the top of program memory would mess up the shadow registers, as the RETI, or RETIW instruction is not executed. The same is true for the return stack when you try to jump to some address outside of a subroutine without executing a RET, RETW, or RETP instruction.
I have tried SXSim together with a jump to the top of program memory from within an ISR. SXSim stays in an endless loop, always jumping to the top of program memory. I'm not sure if the "real silicon" behaves the same but at least, SXSim does not simply ignore this "illegal" code.
BTW: You can also soft-reset the SX w/o using the watchdog by connecting a free port pin to the *MCLR pin. Configure this port pin as an input (high Z) by default. In case you want to soft-reset the SX, make this pin an output with low level. This will pull low the *MCLR pin, and cause a reset. As a reset automatically configures all port pins as inputs (high Z), *MCLR will be released automatically after the soft-reset.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
Many thanks for your information on jumping to the end of program memory in a crude attempt to reset the SX. Your hardware "tunnel" solution (MCLR wired to a port pin) looks very interesting for many applications.
I have now tried the secret stack instructions popPC/pushPC ($04F/$04B) in an attempt to force a return from interrupt to my required program entry point instead of the interrupted program location. Unfortunately my experiments show this does not work because the PC interrupt stack is different from the PC subroutine stack; the secret instructions popPC/pushPC ($04F/$04B) operate on the PC subroutine stack.
Does anybody know secret instructions that modify the single layer PC interrupt stack ?
Best regards
electronic
The secret PUSHPC/POPPC operate on the two level program counter shadow stack..... NOT on any subroutine/call/ret stack.
In order to return from interrupt to a place different than the interrupted code, ALL the shadow stacks (PC, STATUS, FSR, W) need to be primed with the desired or appropriate contents, and then a RETI is issued. That then pops the primed shadow contents into the real registers.
There are some other non-trivial issues such as what happens when an interrupt occurred during a SKIP instruction, and what about the M register.
As I stated earlier, in its full implementation there is a fair bit of complexity to this, and is not for beginners .... not to imply that you are a beginner, just a caution.
Cheers,
Peter (pjv)
one more note on the secret instructions: These instructions were implemented by the SX designers mostly for supporting on-chip debugging. When you use them, you can't correctly debug your application anymore with the SX-Key, or any other device.
▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔▔
Greetings from Germany,
G
One thing I've always wondered about using a port pin, as you describe, to pull /MCLR low: When the port pins are tri-stated, thus releasing /MCLR, is the reset process far enough along at that point to continue reliably without /MCLR having to remain low? Or would a more prudent approach involve driving one of those undervoltage reset chips with a built-in time delay?
I've always used the WDT method to do a software a reset. The WDT should be part of any a well-written SX program anyway. Using it to force a reset is just a bonus! Plus, you can tell at reset that that's what caused it and take, perhaps, a different course of action on restart.
-Phil
You are correct the secret stack instructions popPC/pushPC ($04F/$04B) operate on the interrupt stack.
Sorry for this confusion. I made the silly mistake of programing a single DW byte incorrectly !!!
My program now functions as required.
Many thanks for your valuable help and advice.
Best regards
electronic
I guess electronic, the originator of this thread, has his program working now which is good. However, all this talk about secret instructions, etc. has me wondering, “Is it not possible to call other subroutines from within the ISR?” I am fairly certain I have done this, though I do not remember when. And if this is possible, would it not solve the whole problem to call a few subroutines that insure the counters are within range before returning from the interrupt?
Maybe I did not follow what was trying to be done. It just did not seem to me like it should require such a complex solution.
Would anyone care to comment further on this?
- Sparks
Sure, subroutines can be called while in ISR..... the ISR stack is not the same as the subroutine stack, hence there is no interference.
What 'electronic' was asking, could one RETURN (permanently) from an interrupt to a place different from where the interrupt originated. And the answer is YES, but with some caution and some issues.
Cheers,
Peter (pjv)
I have used the SX interrupt routine for all user interface. On power up the SX jumps to the interrupt routine by RTTC interrupt. All programs are run and program data modified by this interrupt routine. This simple method allows the user selected program to run without the need to waste valuable CPU time checking for user input from the keys.
Best regards