Proper technique needed to nest a setWatch() within a separate setWatch()

Fri 2019.08.20

'I don't completely understand the snippets'

It was extremely late as I posted the above, and not proud of it's brevity. Did so, as had I waited till morning for a more complete post, most that might respond would already be heading for bed in their timezone.

'After 10 clock cycles you would remove all watchers'

Yes that is it's intention as my note there indicates. There is no way to Ctrl+C out of this, forcing a WebIDE reboot at these speeds.

'You can pass in the CS pin to the send command like '

Thanks for that reminder. In this proof on concept phase, just trying to see if I can detect at least a few bits correctly.

'how many other slaves are there, and how much CPU'

Right now just proof of concept with two micros.

'Why not just set up one setWatch once on the SCK pin'

There are a bazillion pulses. I'm sure overflow would occur then. Also, since the master controls the clock, how does the slave know when to record which bit for which byte? I was relying on the rising edge detection of setWatch()

'So I guess you could' (with the three steps that follow)

The two functions are effectively doing just that. It is difficult to comprehend what the actual code execution is going on, when in single step mode it appears to work, but at full speed, the wrong data is returned. Maybe the SCK pulse width is just too narrow for setWatch()?

'recipe for Espruino's interrupt / event queue overflow'

As there are only 32, I felt that starting after CS goes low, might not be an issue. But as the responses are all zero during this sampling, it is quite possible that, that is in fact what is going on. Any idea on how to check for IRQ issues?

I'll continue to try slowing down the SPI bus, but don't know how slow below the default is reliable?