Re: [Amforth-devel] Hello, and a question about interrupts

[Matthias T. <mt...@we...>]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Dave,


> I've been thinking about the problem somewhat, but haven't had time to 
> code up any alternatives.  I did a quick study of a bit vector approach, 
> where each interrupt maps to a bit in a double cell.  While it is quick 
> and simple to set the bit, I haven't yet found a fast, tight way to 
> dispatch interrupts off a bit vector in DO_INTERRUPT.

That approach work for Atmegas with less than 32 interrupt sources.
There are variants with more. Thats why I think that the bitmap
is the least better (uhm, well, difficult) way to improve the ISRs.

ISRs by nature interrupt at any time. Since the forth inner interpreter
is not re-entrant, the handling of the interrupts needs to be
synchronized with the DO_NEXT call. In that moment the state of
the forth system is well known and needs only a few pointers to be
saved/restored. The main task will be therefore to build a way
from the asynchronous interrupt to a synchronous forth interrupt.

Making the inner interpreter re-entrant is surely possible, but it
would need a lot more information to keep (just like a RTOS task or
the push/pop giants generated by the gcc).  In amforth I tried to
avoid such huge (and stupid) things...

> Another thought is to simply have ISR return with a RET instead of a 
> RETI, thus interrupts are still locked out.  DO_INTERRUPT would SEI just 
> before rjmp'ing to DO_EXECUTE.

DO_INTERRUPT is already part of the synchronous forth interrupt
handling.

> And a third idea that I haven't thought about much at all is to 
> essentially turn 'intcur' into a ring buffer instead of a simple 
> variable.  This should be nearly as quick at dispatching interrupts as 
> the current scheme and is no fundamental change to the architecture.  I 
> believe this method can preclude nested interrupts, which eliminates a 
> source of hard to find (hard to sensitize!) interrupt handler bugs.

That would indeed solve the problem of lost interrupts. There is only
one remaining point (beside coding of course): how long is the buffer?
Could be something different (a (return- ?) stack perhaps).

It would not solve the problem with the hardware interrupt
flags that need to be acknowledged within the "real" interrupt handler
(eg the usart flags) however. But it will be definitly better than now.

> In any case, I'll need to address interrupts in some way. For my 
> robotics applications, in addition to timers and serial comms, I want to 
> track the wheel encoders with a pin change interrupt.

These interrupts work similiar to the timer interrupts. They do not
need to be acknowledged. I tried them with some push buttons (see
the appl/pollin/blocks/hello-world.frt file). Therefore I think, that
the major redesign you've outlined at the beginning can still be avoided
;=)

> There are 4 of us now in the Homebrew Robotics Club trying out amforth. 
> It's a very nice fit for our projects.

I'm glad (and proud of) to hear. thank you all.

Matthias
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)

iD8DBQFIo+9P9bEHdGEMFjMRAtBzAKDJ7s3vfJtJrb0rqdm1lgfM8GboBACgoFBj
fPy25AeihzjZT7tNqDiDJnw=
=t3cy
-----END PGP SIGNATURE-----