setWatch Feature Requests

I'd like to suggest a couple feature requests for setWatch. I looked at making the code changes myself and while I think I could manage the JavaScript interface changes the event queuing and low level coding is beyond my pay grade, or at least my C++ competency. :)

1. It would be nice if the repeat parameter accepted an integer value rather than just a Boolean. That would allow one to look for a specific number of transitions and limit overwhelming the event queue for continuous frequency signals.

2. It would be nice to add a prescale parameter such that some number of transitions must occur for each generated event. My thought here is that this needs to be incorporated at the interrupt level. This would enable observing rapidly changing continuous signals again without overwhelming the event queue.

The thing I'd be worried about changing repeat is that I (and probably many others) do repeat:1 as a shorthand - and it'd break that.

Prescale could be an idea though (we'd just have to make sure we knew what data it should be reporting back) - to be honest I've wanted to do a more intelligent setWatch for a while.

Specifically:

• Ignoring small pulses in the IRQ
  
• Sampling another pin when one pin changes (so you can read clocked data)
  
• Maybe some kind of bit storage, so it can store multiple bits of data and then call back into JS just once
  
  

I've struggled to think of how best to expose that. I'm wondering whether it's actually better if I let you specify code to execute in the IRQ. I think it should be ok to use JS now - or obviously compiled code/assembler would work best.

Then at least it'd be easy enough to write libraries that handle the common cases...

I like those ideas too. setWatch offers a nice clean way to monitor I/O and generate events and embellishing it would open the door to more sophisticated events.

The thing I'd be worried about changing repeat is that I (and probably many others) do repreat:1 as a shorthand - and it'd break that.

Then perhaps a count parameter?

Yes, that could work. As I said above though it might make more sense to expose these things via the ability to execute custom code in an IRQ.

For instance things I can't do now that I'd like to:

• Reliably decode 315/433Mhz radio signals in different protocols, even when noisy
  
• Read in clocked data (eg. PS/2 keyboards/mice)
  
  

Neither of those is going to work desperately well with a general purpose solution...