-
Aside: You can pass in the CS pin to the send command like
var val = spi.send([0xC0,0xF4,3,4], PIN_CS);
Also, the setWatch docs say you can ask for the state of another pin, so you don't have to read it (might matter, as you don't have to spend the time to read it):
// Advanced: If specified, the given pin will be read whenever the
watch is called // and the state will be included as a 'data' field
in the callback data : pinI don't completely understand the snippets, for example, you don't call
setw
from B1's setWatch, but that call should be there, right?Why not just set up one setWatch once on the SCK pin, and ignore if the CS is not low? Ok, depends on how many other slaves are there, and how much CPU the watch uses...
So I guess you could
- use 1 setwatch on the SCK pin, pass the MOSI in as
data
- in the watch, check the state of CS, if not 0, just exit
- process the data as you wish :)
- use 1 setwatch on the SCK pin, pass the MOSI in as
Thr 2019.08.01
Seeking technique suggestions here. Individually, manual toggle of lines allows correct result from one pass of setWatch().
Continuation of threads:
Goal: After CS Chip Select goes low, on rising edge of SCK clock line, read state of MOSI
Setup: Espruino MDBT42Q as master sending software SPI to Espruino WiFi as slave
Data sent inside a setInterval() creating a CS pulse Low of ~200msec surounding 4 x 8bits of ~300usec clocked at 3usec:
Limited code for brevity
Verified: Using logic analyzer and protocol decoder am able to see and verify CS, SCK, MOSI, MISO and data as placed on MOSI
Individually, the setWatch() definitions execute as expected.
The idea is to only allow the second setWatch() to run after tripped by the setWatch() monitoring CS
When I manually set the state of MOSI using
function fetchBit() reads and stores manually, correctly.
Suspicion: A timing issue, starting technique or a different means to trigger the second setWatch() is needed.