You are reading a single comment by @maze1980 and its replies.
Click here to read the full conversation.
-
console.log() takes a lot of time. If you call it once every 8 bit it's somewhat ok, but if you call it for every bit it'll slow down things significantly. But the read data should be still valid in my understanding.
For time critical functions it's better to store data you want to print in some variable or array and print it at a later point.
maze1980
Quick update as I realize it is late by you, . . . with more testing to do,
Okay humored! (sic US sp)
Took a bit to get up and running, determined PulseView software requires MISO to be included also, for the protocol decoder to work.
With using just the code from #15
First thing I noticed is the active state on the pins is not the same. Clock phase. As pinMode() isn't used, I'm guessing looking at default and setup will uncover that.
Added a setInterval() on send side MDBT42Q so I didn't have to keep pulsing that side, and kept the bus quiet for at least a full second.
Without the CS detect, the WiFi slave side does decode as in #15
MDBT sends out 8usec clock ~100KHz
I don't see any major differences, except for the CS state inclusion.
Speculation here: Sanity Check
Commented out strings, outside of functions are not included in the upload? (yes?)
Inside the CS setWatch() during development, I placed console.log() statements to see what was going on. Had a hunch that the update to the WebIDE console window was getting bogged down, as it took a while to Ctrl+C out. I commented out ~three debug statements, and the console updated fine.
HUNCH: Even though the console now appeared to be updating without noticeable delay, that in reality, the commented out lines were causing a delay in the setWatch() read perhaps?
Off for coding CS inclusion and more testing . . . .