[CCC DEV] The third button problem

[Matt Jadud]

On Sun, Feb 6, 2011 at 14:34, Steve Pretty
<steve.g.pretty at btinternet.com> wrote:
> A nicer solution would be to keep with interrupts, I think. This would mean
> supplying a PROC to deal with the three interrupts PCINT1, PCINT2, PCINT3.

Actually, the firmware seems to be ready to support these interrupts.
We just haven't ever written code that uses them.

To enable the PCINTn interrupts, you'll need to look at the file
"external.interrupts.module" in the "m328p" directory under "arch".
The PROC "set.interrupts" takes an AVR pin number (that is, the
actual, from-the-datasheet pin number), configures external interrupts
on that pin, and sets the variable "vintr" to the correct interrupt
constant. In this case, it would be VINTR.PCINT0, VINTR.PCINT1, or
VINTR.PCINT2. (These are already in the interrupt table and ready for
use.)

(Actually, you can (of course) write the code in your own PROC to
enable them. What I said is really only true if you're going to make
digital.input() work for these interrupts. Otherwise, you can enable
things, use wait.for.interrupt() directly, etc.)

> to one relationship would be needed for the PCINT1, PCINT2 and PCINT3  ( or
> could one PROC wait on an ALT of the three interrupts?)

Yes. It is possible to wait on those three separately with updates to
set.interrupts(). Setting up the mask and pulling apart the resulting
interrupt is the trick.

> PROC (VAL INT intID, mask, CHAN LEVEL out0, out1, out2, out3, out4, out5,
> out6, out7)
>
> where intID is the name of the interrupt (and hence the range of pins), mask
> is used to flag which bits of the port are of interest and should be
> reported, and then there are 8 CHANs for the output.   This is not very
> nice, as you would have to provide "black holes" for any unused outputs?

No, you won't need millions of black holes. You can leave channels
dangling, if you like. You could even do

[8]CHAN LEVEL out!

which would save some typing. Then, you can just pass parts of that
channel array to various PROCs.

[8]CHAN LEVEL pcint:
PAR
  pcint.input (PCINT0, #01, pcint!)
  level.to.signal (pcint[1]?, ...)

or something like that.

> Ideally, I would want a user interface identical to the current
> digital.input - where I can set up a PROC to handle one pin and associate it

I think we can get there. Getting interrupts PCINT0...2 working is step one.

> - I have no idea how to do that in occam (if it is even possible).  What I
> would really like to be able to do is pass a list of pin / CHAN tuples to
> the handler - but again, I don't think occam supports that kind of thing.

I think the biggest catch waiting for us here is that we cannot have
multiple instances of "wait.for.interrupt" waiting on the same
interrupt vector. Your initial "array-of-channels" solution, as a
first step, avoids this problem.

> Could I start a handler and then use a protocol to pass in the pin/CHAN
> pairs?  If I did that, can I somehow save the set of CHANs I want to use in

Yes. You would end up just updating the bitmask, and/or possibly
enabling/disabling interrupts entirely. This would end up looking like
the servo code.

> an array, and then send on the CHAN references in the array.  (Is this what
> Mobile CHANs are for?)

Ah. You *could* do this, but MOBILE types require dynamic allocation
of RAM. We have not turned that on at this point, because... well,
first, there's not much RAM. Second, it leads to the possibility of
runtime errors that are very hard to report the cause of back to the
user. (The Arduino dev community has spent the last several months
debating the String class for exactly this reason.)

> documentation - is there anything more comprehensive that the Peter Welch
> quick guide?

Given that you're (essentially) working in occam, and not -pi, you are
good with occam references for now. (Did I pass those along?) And,
sadly, no, there isn't a substantially better -pi reference.

> I would be interested to know what your thoughts are for the third button
> problem.

USE TWO BUTTONS!

(As the old joke goes: "Doctor, it hurts when I do this...")

It turns out the infrastructure for the interrupts is there. Christian
and I chatted earlier today about our respective workloads and
deadlines, and we're a bit slammed through the end of this month.
However, we'll do our best to help you get those interrupts working...
they're there, apparently, and ready to be used. The abstractions (for
pretty end-user code) aren't there yet, but you're thinking along
several lines that are all directions that make sense/fit with the
model.

I hope that helps. I have to record a video for Environmental Science
students explaining how to build a Really Bare Bones Board, so I can't
sit down and hack this tonight... nor, probably, for the rest of the
week. But, we'll all try and help remotely.

Cheers,
Matt