• 'You lost a bit in outer space'

    Ahhhh, . . . Yes thank you maze1980, any chance you have found it?

    'Make d a global variable. Add another setWatch() for the CS and set d=1; within this code'

    Var d is global in line 3   That is the entire code file

    This is what Gordon's #8 is doing. Will attempt to merge #15 into #8 and try with the global array I originally had. Not sure which of the two is more important to try first. Code cleanup for upload probably will take as much time as merging those two. Maybe I'll have time for both . . . .

  • Make d a global variable. Add another setWatch() for the CS and set d=1; within this code.

    @maze1980 sounds spot on here.

    Unfortunately it won't get it right 100% of the time especially with the odd interrupt conflict, and it looks like a bit got lost. Using cs in that way would help to always 're-frame' the data, and then you could use a CRC or similar to detect the rare transmit errors.

    RE: console.log - this goes into an output buffer of ~256 bytes if I recall. As long as you don't fill that buffer it can be fast however when you do that (especially if connected via USB on the WiFi) it's likely to cause a few interrupts for USB as it attempts to send the data, and there is a possibility (without diving into the USB stack I couldn't say before) that they have equal or higher priority to the pin watch and could displace it.

    ... but most likely the buffer got full and caused the event queue to get full - but that should have flagged up an interpreter error.

  • Tue 2019.08.06

    What is the command or method to reveal if any setIntervals are running in memory, despite the attempt to stop them with clearInterval?

    I remember seeing this in a post a while back, but Google isn't helping me out here.



    Update: There are several conflicting issues I have uncovered. Now I have a repeatable bad read data situation, bits stream is there, detection start is off caused by issue above, I'm pretty sure I'll be able to solve this. Code and docs to follow when done.

  • Just copying the code together I'd say it should look like this:

    //replace D0
    const CS_PIN = D0;
    const CLK_PIN = D0;
    const MOSI_PIN = D0;
    var isActive = false;
    var d=1;
    var toPrint = "Got: ";
    
    //CS_PIN
    setWatch(function() {
      isActive = true;
      d=1; //cleanup at start
    },CS_PIN,{edge:"rising", repeat: true});
    
    setWatch(function() {
      isActive = false;
      console.log(toPrint);
      toPrint = "Got: ";
      if (d!==1) {
        console.log("Bit error");
      }
    },CS_PIN,{edge:"falling", repeat: true});
    
    //CLK_PIN
    setWatch(function(e) {
      if (isActive) {
        d=(d<<1)|e.data;
        if (d>255) {
          toPrint = toPrint + (d&255);
          d=1; //cleanup after 8 bits
        }
      }
    },CLK_PIN,{edge:"rising", data:MOSI_PIN, repeat: true});
    
  • Thanks @maze1980, having another view is helpful.

    With the comment "I'd say it should look like" sounds like it hasn't been tested, which is okay don't get me wrong, any and all contributions are helping. That code block is pretty much what is being done and implemented right now based on Gordon's #8 snippets.

    As I pointed out in #28 from an observation you pointed out earlier in this thread, setTimeout and setInterval 'actual' execution time is getting in the way of the setWatch() read. Too much to detail right now, but on the horizon.



    Don't want #28 to get buried here with other updates:

    Fr #28
    What is the command or method to reveal if any setIntervals are running in memory, despite the attempt to stop them with clearInterval?

  • What is the command or method to reveal if any setIntervals are running in memory, despite the attempt to stop them with clearInterval?

    console.log(global["\xFF"].timers); //nice, less info
    trace(global["\xFF"].timers); //full info
    
  • Thank you for the quick response @maze1980, it is the latter I was after, and confirms my hunch. How did you locate that tid-bit?

    Now knowing what the syntax is, submitting to Google now provides the original article from two months ago. Memory still in tact, as I knew I saw it in a recent post.

    http://forum.espruino.com/comments/14763­137/

  • Post a reply
    • Bold
    • Italics
    • Link
    • Image
    • List
    • Quote
    • code
    • Preview
About

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

Posted by Avatar for Robin @Robin

Actions