I just started to play with Riscy Pygness ( on target part of LPCXpresso 1769 board. The system works quite goodas interactive environment for experimenting with ARM CORTEXprocessor, and seems to be an efficient development platform.The only thing which seems to be lacking is interrupt support.Well, I can write the interrupt service routine in assembly and add itto the kernel, and it will be the most efficient solution. However forinteractive experiments it would be much nicer to have possibility toimplement ISR as a Forth word. Such functionality is available in thelatest version of amforth for ATmega's (Has anybody added this functionality to Riscy Pygness? Maybe someonecould suggest the best way to implement such functionality? Is itpossible to make use of multitasking functionalities providedby the kernel to service interrupts in a reasonable way?What are the traps, which may badly affect the interrupt servicinglatency?--TIA & Best Regards,Wojtek

I am not familiar with Riscy Pygness, but I can comment generally about interrupt handling.The problem with writing your interrupt handler in high-level Forth is that the interrupt must first instantiate a Forth environment: stacks, registers, whatever the implementation requires, and do so in such a way as to not affect whatever task was running when the interrupt occurred. This adds some inevitable overhead.IMO the faster approach is to write the interrupt handler itself in assembler, and make it do a bare minimum: only those things that absolutely have to be done *right now*, and let a high-level word do the less time-critical functions.For example, if you are doing some data acquisition, your application task can set up the operation and then go into a wait state. When the interrupt occurs, the ISR can read the value, store it somewhere, and set the task to wake up again to do whatever additional processing is necessary.Of course, I am viewing this from a multitasking...

Has someone tried to add interrupt support to Riscy Pygness?

May 21, 2011 22 Replies

Rate this thread:

Arlet Ottens 15 years ago

Sure, but there are also different problems. For example, a stepper motor hooked up to a bit-bang SPI bus that needs to be advanced 2000 times per second. You don't want too much jitter, so doing it in the timer ISR itself becomes a viable option.

It would be nice to have the option so you could choose to run the ISR in assembly, or a higher level language, depending on the particular circumstances. In my experience, I've written 90% of my ISR code in a higher level language.

If it only takes a half-dozen instruction to do a context switch, I'm sure it doesn't have to take more to set up an environment to run Forth in an interrupt context.

Vote

Brad 15 years ago

I don't see any problem with having the inner interpreter poll for interrupts, as long as you carefully review words that alter stack pointers such as THROW and PAUSE. You may need to disable interrupts in parts of such words. I remember a story of someone who modified the inner interpreter on an early single-interrupt computer to emulate a multi-interrupt machine and it was a great success.

-Brad

Vote

Jean-Francois Michaud 15 years ago

We're in trouble then because thoughts are abstractions so talking in the abstract cannot be overcome ;-).

[SNIP]

Jean-Francois Michaud

Vote

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required