[CCC DEV] The third button problem - update

[Matt Jadud]

Hi Steve,

Short version: awesome.

Longer version: I'm just rambling/thinking out loud. I wanted to
externalize my thoughts, so others could respond/critique/ignore.

On Thu, Feb 10, 2011 at 07:13, Steve Pretty
<steve.g.pretty at btinternet.com> wrote:
> A thought - the pattern where you need to define the placed ports and then
> read from or write to them is found in many places in the code. It might be

Could do. It's not a bad idea, and just because it isn't "functional"
for execution doesn't mean it isn't functional for
maintenance/development.

> PROC set.pci.interrupts (VAL INT port, VAL BYTE mask, RESULT INT vintr)
>  PLACED [MAX.PORT]BYTE ports 0:
>  #PRAGMA DEFINED ports
>  #PRAGMA DEFINED vintr

Ah. So, the problem with "set.interrupts" is that it takes a pin
number... and, in some cases, the same pin can be used for different
interrupts, no? Otherwise, we could use the pin number to look up the
port, and integrate it into set.interrupts. This would allow it to be
used with digital.input, because we could construct the mask...

Although... that gets us into the "multiple interrupt handlers on one
interrupt" problem. It might be time to look at the interrupt
abstraction layer, and see if it is worth having multiple handlers for
a single interrupt. Or, we can keep building around that in occam.

Another way could be, I think, like you suggested before, Steve: if we
have a single process that carries some state, then you can tell it
(dynamically) what mask to watch.

PAR
  pcint (CHAN PCINT.REQ config?, CHAN PCINT.RSP beeps!)
  SEQ
    config ! add.pin ; 4
    config ! add.pin ; 6
    WHILE TRUE
      -- Code that does stuff, sending out on beeps!

This way, there is just one handler for the port. However... hm. Er.
Then, it gets ugly... because there are more than 8 pins total that
can handle PCINT requests. Ah. This gets us away from big arrays of
channels (which consume RAM). (My example, up until a moment ago, said
[8]CHAN LEVEL instead of CHAN PCINT.RSP.)

PROTOCOL PCINT.RSP
  beep ; INT ; INT
  ... and so on ...
:

or something similar... we could have a single channel that has a few
responses, one of which is the level. (It could have others.) This
carries with it the pin that changed as a variable. Then, instead of
listening to element four of the channel array, you just ask "was this
pin 4?"

INT pin.num:
LEVEL lvl:
  SEQ
  pcint ? pin.num ; lvl
  CASE pin.num
    ...

I'm thinking out loud here, Steve. I like your code, but I'm now
thinking about how to refactor some of it so that we 1. compress RAM
usage and 2. perhaps simplify some of the API for the developer.
("Simplify" is a bit of a loaded term here...) Mostly, I'm concerned
that every time I want to use PCINTs, I might bring (up to) 24
channels into existence... possibly just for three interrupt pins.
It's not efficient.

Basically... your first pass is how I'd do it in the first instance.
I'm just brainstorming regarding some refinement. Very nice work, and
thank you.

Cheers,
Matt