Behaviour of setWatch on pin X after pin X has been set with digitalWrite

[espruino-discuss3]

Posted at 2015-07-29 by @yerpj

In order to achieve a bidirectional protocol (PS/2 mouse), I have to simultaneously monitor a pin with a setWatch, and drive it (open drain with external pull-ups).

I set this pin LOW with digitalWrite(X,false), and HIGH with pinMode(X,'input') (External pullup drives it HIGH ).

What is happening with the previously declared setWatch on this pin? Does it remains active or is it discarded as soon as I drive this pin with digitalWrite?

[espruino-discuss3]

Posted at 2015-07-29 by DrAzzy

I think it remains active, until you turn it off with clearWatch()

If it doesn't, I would characterize it as a bug.

---

Posted at 2015-07-29 by @yerpj

I had a doubt about it, but after a quick check, it seems that a setWatch remains active until it is explicitly cleared by clearWatch.
BTW, @gfwilliams, are you planning to implement an additional configuration of an IO, that could be set as "digital output, open-collector (== open-drain)" ? This is largely used in the low-level sensors<-->MCUs interfaces (typical bidirectionnal lines).
I believe this may be done by using some low-level function such as peek() and poke(),but this is a kind of dangerous method, as the memory does not seem to be protected at all.

---

Posted at 2015-07-29 by DrAzzy

what happens if you do pinMode(pin,"opendrain"); and then digitalWrite() to the pin?

Does that not give the desired effect? digitalWrite() should not change the pin mode if you've set it with pinMode().

---

Posted at 2015-07-30 by @yerpj

It works. I did a mistake. I assumed that at start up, every GPIO was set to "input", which is not the case (B6 is set to "af_output" by default on Pico). The control of a bidirectional line with pull-up seems alright now.
Unfortunately, I am still unable to decode a digital bitstream from a PS/2 device with Espruino. It seems that despite the use of event-triggered setWatch() function, the code is interpreted too slowly.

I remember that Espruino exposes a function to sample an analog bitstream (in & out). It may be really cool to have such a function for a digital bitstream, which can not be decoded by a UART nor a SPI. Whatever, Espruino is not meant to be efficient on sampling bitstreams. I would use an external MCU to interface my PS/2 device with Espruino (PS/2 <--> UART converter).

Thank you @drazzy for your support!

---

Posted at 2015-08-03 by @gfwilliams

Hi - sorry for the delay, I was off last week.

Pretty much all pins are inputs by default, but B6/B7 aren't as they're Serial1, which is the default console when USB isn't connected. I think that was probably what got you. digitalWrite/etc set the pin mode automatically, unless you set it explicitly with pinMode - which as @drazzy says can be used to get Open Drain.

My hunch is that setWatch would be fast enough (and there's a 128 event buffer that should handle a few bytes) but the data from the PS2 mouse is just coming in so fast that Espruino can't process it in time.

As I'd said in the other post, you can now use USART to sample serial data (as of 1v80 or recent GitHub builds) so that should work in this case. I'm hoping that when I sort out some reliability issues you'll also be able to run compiled code from an IRQ, which will hopefully be fast enough to work in these kind of cases.

... You can currently run assembly code from an IRQ using setWatch with irq:true, but realistically it's going to be a bit of a nightmare to do much with it.