Re: Interrupts don't interrupt?!

Gerry Thonigs wrote:
> Hi, OK, I'm a little bit confused now...
>
> One of the main advantages of forth (which I am a newbie to) is the
> "interactive development". Now I receive an impression that this doesn't
> hold when developing applications with extensive use of interrupts...
> Hopefully I'm wrong with that?!

You are. :) Since you say you're a newbie, I'll give you a few newbie hints,
but I don't have time to dig into your target right now (I really don't have
time to write this, but I'm a softie for newbies.)

> Also, Leon says, the BDM is non-intrusive. But why does it fail when
> going into blocking loops for more than about 100.000 iterations? It
> should service it's interrupts and returning into my loop, shouldn't it?

It's most likely failing because of your interrupt code, which you still haven't
posted.

If you take the unmodified SwiftX and connect to your target, does COUNTER
increment every ms? If so, then you at least have one interrupt successfully
running.

You can do a PAUSE-less loop waiting for COUNTER to increment:

: MS-HOG ( n -- ) COUNTER +
    BEGIN DUP COUNTER - 0< UNTIL DROP ;

"HOG" referring to the fact that you're "hogging the CPU;" without a PAUSE, no
other round-robin tasks can run...but interrupts still can. LOCATE MS and
you'll see I wasn't very creative in building this word...I just ripped the
PAUSE out of the stock MS.

If you don't have the watchdog enabled, you should be able to do 100000 MS-HOG,
and get your "ok" prompt back in 100 seconds.

> To make a clear question of this: Do you recommend forth for developing
> hard real-time systems?

Absolutely. In my opinion, there's no better tool (and I've used others such as
IAR over the years.) SwiftX has no interrupt overhead that you don't put in
there. Also, with SwiftX, you have the complete source code for your target:
you can carefully examine every instruction out of reset.

But the #1 advantage of Forth is interactive development; don't squander that
advantage. Once you prove (using the above test) that the BDM will indeed work
under these conditions, then you can dig into your interrupt issue...but do it
one small shovelful at a time. You don't have to spin in a loop to test that
variable; you can just use your Forth interpreter. <up-arrow><Enter> is a
wonderful thing. So is LOCATE.

COUNTER . 240470234 ok
COUNTER . 240471546 ok
COUNTER . 240473078 ok

You can then examine any other relevant status interactively; you'll probably
then find something wrong, and then you can fix it.

I'm afraid I can't be more specific at this point. If you post your interrupt
code, though, someone may be able to spot your problem. You don't have to show
us anything proprietary; just try to increment a variable like the <TIMER>
interrupt does.

Once you get that little bit going, just remember to do baby steps, especially
in ISRs. F9 (debug, that is,) test, add a line, repeat until complete. Simple
as that. ;-)

Good luck!

-- 
Ron Oliver                 cell: 248.330.4446
Consulting Engineer        main: 310.491.3356 or 800.55.FORTH
FORTH, Inc.
www.forth.com
----------------------------------------------------------------------
swiftx_at_forth.com          The SwiftX programming discussion email list
To unsubscribe, send subject "unsubscribe" to swiftx-request_at_forth.com
For list command help, send subject "help" to swiftx-request_at_forth.com
Message archives are located at http://www.forth.com/archive/swiftx
----------------------------------------------------------------------
This list is a forum for SwiftX users.  For product support and bug 
reports, please send email to support_at_forth.com
----------------------------------------------------------------------