Avatar for billsalt


Member since Jan 2017 • Last active Sep 2023
  • 24 conversations

Also known as "billsalt"
Bill Saltzstein
Code Blue Consulting/Code Blue Communications
Bluetooth and Medical Device Consultant

Most recent activity

  • Avatar for billsalt

    I tried the 'cutting edge build' and have verified that it is working with my 8uS pulse using


    Thanks @Gordon and @allObjects

  • Avatar for billsalt

    Thanks @Gordon! I'll flash the bleeding edge firmware and give it a go, and report back.

    I thought the flip flop solution inventive, but certainly am not interested in the flying chip circus longer term :-}

  • Avatar for billsalt

    Close enough; actually a positive 8uS pulse (see the earlier scope image). I think the nRF processor was triggering, but the additional processing with setWatch was too much. Per one of your earlier posts, I was getting stack overflow after a few cycles, so it wasn't keeping up potentially because it was triggering on both edges internally and logging time for each. I don't know enough about the internals, but from what you and Gordon have described it makes sense.

    Since the toggle flip/flop only has the one edge each cycle, and there is a significant amount of time, it resolves the issue and Espruino can 'keep up'. I had J-K flip flops available since they are a general purpose 1-bit memory and easy to convert to lots of uses. A couple of connections and it becomes a toggle, for example. I don't keep standard logic gates around anymore, especially since I'd need a whole new family to do 1.8V logic work that has become the norm.

    Thanks again!

  • Avatar for billsalt

    @Gordon and @allObjects: solved! I used a J-K flip flop (74AC109) inline configured as a toggle. Then changed the setWatch to edge: 'both'. Pretty simple hardware solution.

    Doing my SPI transfers in the setWatch with enough time, helps confirm that the issue was the narrow pulse.

  • Avatar for billsalt

    The pulse is fine. That scope output is at the pin on the MDBD42Q module. That is the way this part works, and is just fine with microprocessors running native code.

  • Avatar for billsalt

    @Gordon and @allObjects thanks for your assistance and advice. I tried the inline C (below) and had almost identical behavior. The 8uS pulse width just is not working. I'll take a look at the PPI function, but my guess is at this point it would be more reliable to go directly to nRF native coding.

    var c = E.compiledC(`
    // void press(bool)
    // int get()
    volatile int data;
    void press(bool state){
    int get() {
     int r = data;
     data = 0;
     return r;
    setWatch(c.press, D16, {repeat: true, edge:'both', irq: true});
    console.log("watch set");
  • Avatar for billsalt

    Using the PWM method how; could you explain? Your idea of using a counter and resetting it on a timer would be completely asynchronous to the acquisition chip A/D; that's not going to work. I need to synchronize on the interrupt pulse and don't see how Espruino can be used in this way as a 'pulse stretcher' without additional hardware.

  • Avatar for billsalt

    @allObjects sorry about that; used to typing the 'k'. If you look at that scope image, you'll see that it is actually 222 Hz. Plenty of time. I'd already run the numbers to make sure I had the time to do the SPI operations, even with Espruino timing on the SPI enable.

    I think I either need to do a bit of pulse stretching hardware, or just ditch Espruino and head directly to C. I was hoping to avoid that since I'm just prototyping, but alas.

    My other thought was whether it would be possible to so some inline C to trigger setWatch with a shorter pulse. Any thoughts on that?

    Appreciate your insights!

  • Avatar for billsalt

    No, I do not have control of the timing. This comes from an acquisition chip.